1 INFO-VAX	Sun, 12 Aug 2001	Volume 2001 : Issue 446       Contents:# Re: (v. cheap) used vax kit wanted?  Re: Alpha-IA64 FAQ  Re: BACKUP (was Re: Red Code...)  Re: BACKUP (was Re: Red Code...)6 RE: Backup disk on one system to tape drive on anotherP Conference: Compaq Enterprise Technology Conference 2001 - Update 8/13/2001 (www	 Re: HSD10 = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel = Re: I just have to post this - and apoligse later Alpha/Intel 1 Re: Looking for a Pine.exe for TCPIP 5.x services & Re: open vms hobbist tcpip license????2 Re: OpenVMS apps and Compaq committment story here2 Re: OpenVMS apps and Compaq committment story here Re: Press Release  Re: Press Release D Re: Problems installing Hobbyist Version of Vax OpenVMS - Any Ideas?* Pseudo Terminals to emulate LAT Terminals?. Re: Pseudo Terminals to emulate LAT Terminals?. Re: Pseudo Terminals to emulate LAT Terminals?! Re: Red Code: where are we going? ! Re: Red Code: where are we going?  Re: SYS$LOGIN:[some.directory]$ Re: Terry Shannon Tech Talk on Tru64$ Re: Terry Shannon Tech Talk on Tru64$ Re: Terry Shannon Tech Talk on Tru64A Re: The Alpha Systems Customer Update will no longer be published A Re: The Alpha Systems Customer Update will no longer be published  Unix Shell Ports Re: Unix Shell Ports' Re: URGENT: Ada position in Switzerland ! Re: VAX/ALPHA FORTRAN and me! :-) ! Re: VAX/ALPHA FORTRAN and me! :-) ! Re: VAX/ALPHA FORTRAN and me! :-) ! Re: VAX/ALPHA FORTRAN and me! :-) ! Re: VAX/ALPHA FORTRAN and me! :-) ! Re: VAX/ALPHA FORTRAN and me! :-) ! Re: VAX/ALPHA FORTRAN and me! :-) ! Re: VAX/ALPHA FORTRAN and me! :-) ! Re: VAX/ALPHA FORTRAN and me! :-) ! Re: VAX/ALPHA FORTRAN and me! :-) , Re: VMS 7.3 experiences? - Cache Performance Re: We've launched TAPESYS v6.0  what a what  4546   F ----------------------------------------------------------------------  % Date: Sat, 11 Aug 2001 16:38:21 +0100  From: Roy Omond <Roy@Omond.net> , Subject: Re: (v. cheap) used vax kit wanted?) Message-ID: <3B75516D.EB56DA5A@Omond.net>    Douglas Hall wrote:    > Hi there,  > @ > My old vaxen are dying on me atm, maybe it is the hot weather. > C > DSSI drive and ethernet on the 3600 have failed and my vaxstation  > power supply has blown.  > G > Does anyone know of anywhere in the UK that I might be able to get my $ > hands on any vax hardware cheaply? > H > I finally got a vaxcluster working at home after hoarding all the bits > for years and then it breaks!  > E > If not, then I guess I have a complete collection of VMS5.5 manuals C > and an assortment of broken vaxstation 3100's and a uvax 3600 for  > sale!    Hmm...  H I sold a VAX 4000-200 some time back (2 years ago ?) to a guy in IpswichH (Brian ?).  I gave him an extra RF31 (?) for which there was no space in the G system box.  Maybe he's still got it and if it's only gathering dust he  might : pass it on to yourself.  Sorry I don't have any more info.  F As for actual machines:  I recently posted here that I would soon haveA a few Alpha 3000-600, 128 Mbytes memory, (at least) 1 Gbyte disk, G configured with VMS 7.3 ready for hobbyist usage.  If you're interested C get in touch.  Just to make sure nobody expects these for free, I'm  askingA round about 200 for each one (I can't afford to be a charity !).   C I might also have a reasonably complete set of VMS 7.0 manuals that < I could throw in for a few extra pennies/bottles of wine ...  > I'm near Saffron Walden in Essex, 10 miles south of Cambridge.  	 Roy Omond  Blue Bubble Ltd.   ------------------------------  # Date: Sun, 12 Aug 2001 06:38:37 GMT . From: "mulp" <michaelpettengill@earthlink.net> Subject: Re: Alpha-IA64 FAQ D Message-ID: <Nvpd7.3788$ZM2.310768@newsread2.prod.itd.earthlink.net>  1 "Ken Farmer" <kfarmer@tru64.org> wrote in message 6 news:q7wb7.9210$xj.1504287@typhoon.southeast.rr.com...H > I've started a FAQ with information about the Alpha to IPF transition. > 5 > http://www2.tru64.org/pages.php?page=Alpha-IA64-FAQ  > J > Feel free to offer any questions or suggestions.  I'll do my best to get > them answered. >   L What applications will be ported to Tru64 on Alpha in the next several yearsI and what support is Compaq providing ISVs in these efforts?  If I have an F application that might be ported to Tru64, what incentives does Compaq offer?  G What resources will be available to ISVs to support porting and testing : applications on IA64?  How do ISVs apply for this support?  E Current Tru64 clusters support Memory Channel; will Memory Channel be F supported on IA64 and will mixed Alpha and IA64 clusters be supported?  F Have the plans for Alpha HPTC systems changed?  How?  Will Quadrics be supported with IA64 systems?  = When will 64 (and greater) CPU SMP IA64 systems be available?   F Approximately half the IA64 instructions are SIMD (Single Instruction,C Multiple Data); when will compiler and/or library support for these  instructions be available?  G Over two thirds of the instructions of an IPF chip are IA32; will Tru64 I support execution of IA32 unix programs using the IA32 hardware execution  mode?   L Compaq produced a convincing paper that explained why Alpha would exceed theJ performance of IS64 for many years to come.  Alpha roadmaps emphasized SMPL scalability of EV7 the SMT capabilities of EV8, indicating that they offeredG more realistic opportunities for high performance well into the future. ? These are the same strategies being pursued byIBM in its Power4 L implementation.  What has changed in the past few months that invalidate theH argument that Alpha would be competitive with IA64 well into the future?J Why isn't a switch to IBM's Power4 in the next year a better strategy thanI staying with Alpha and waiting for an uncertain level of performance with  IA64?   E The IA64 instruction set is very complex with many instruction forms; L current compiler technology does not seem to be able to convert non-floatingL point code to a form that exploits the complexity of the architecture.  ThisG suggests that IA64 will need to invest in significant logic to spped up L cycle time and at the same time invest in out of order execution.  This willL lead to larger chips and more power consumption, keeping the cost of systemsF up, or driving them higher.  Do you have information that refutes this6 reasoning and when will if be presented to the public?   ------------------------------  # Date: Sat, 11 Aug 2001 13:50:47 GMT ' From: Steve Thompson <smt@twcny.rr.com> ) Subject: Re: BACKUP (was Re: Red Code...) J Message-ID: <Pine.LNX.4.33.0108110950550.16615-100000@ibmbox.vgersoft.com>  & On 10 Aug 2001, Larry Kilgallen wrote:  g > In article <g2Yc7.28$bB1.4624@news.cpqcorp.net>, hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes: C > > "Michael D. Ober" <mdo.@.wakeassoc.com.nospam> wrote in message / > > news:hdRc7.349$4_4.48825@news.uswest.net...  > > G > >   I have not seen the earlier portions of this thread, as I was not F > >   particularly interested in Code Red discussions.  I now see that# > >   the discussions have changed.  > > 	 > > : ... N > > : Amazing statement, since I have lost data with the VMS backup due to theP > > : complexity of it's command line, yet I have never lost data with the builtM > > : in NT4 or W2K backup software - and yes, I've had to restore from both.  > > :... > > 	 > >   So?  > > > > >   The following BACKUP command causes all data to be lost: > > = > >     $ BACKUP criticaldisk:[*...]*.* NLA0:SAVESET.BCK/SAVE  >  > You left off the /DELETE :-)  D Maybe his point was that it erases the previous contents of the null device?    steve    ------------------------------    Date: 12 Aug 2001 01:21:12 -0700) From: P.Young@unsw.EDU.AU (Patrick Young) ) Subject: Re: BACKUP (was Re: Red Code...) = Message-ID: <55f85d77.0108120021.3c9c9c29@posting.google.com>   j hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) wrote in message news:<g2Yc7.28$bB1.4624@news.cpqcorp.net>...A > "Michael D. Ober" <mdo.@.wakeassoc.com.nospam> wrote in message - > news:hdRc7.349$4_4.48825@news.uswest.net...  > E >   I have not seen the earlier portions of this thread, as I was not D >   particularly interested in Code Red discussions.  I now see that! >   the discussions have changed.  >  > : ... L > : Amazing statement, since I have lost data with the VMS backup due to theN > : complexity of it's command line, yet I have never lost data with the builtK > : in NT4 or W2K backup software - and yes, I've had to restore from both.  > :...  C YMMV. I don't know about the "built in" software. However I _would_ A have lost data using Veritas Backup Exec under NT had it not been D for OpenVMS. Backup Exec reserves for itself a couple of evil tricksF after stating the backup is complete and 100% successful A restore may@ result in failure after a search to the end of the tape (with noD particular error message given). It's other trick on a restore is toE simply read the tape label then do nothing (literally) further. Using B OpenVMS I managed the restore of the file required by hacking some- code out of the UNIX open source mtf utility.   F I have never lost data with BACKUP when using it as documented (except0 of course on damaged, missing, or broken media).  E The one time I did was when I used some weird or old gzip to compress @ a save set since I was out of disk space. When unzipped and file@ attributes/record size set properly it had a large number of CRCB errors. Lucky it was my data, not someone elses, and not importantB anyway. That would be my own stupidity for not trying the exerciseC first as a test. Not that using gzip on a backup save set is a good  idea anyway.   ------------------------------   Date: 11 Aug 2001 14:16:38 CDT= From: wayne@tachysoft.xxx.580099.killspam.0160 (Wayne Sewell) ? Subject: RE: Backup disk on one system to tape drive on another . Message-ID: <xqKuaR0u+iFm@tachxxsoftxxconsult>   In article <BE56C50EA024184DAF48F0B9A47F5CF4D55FB9@kaoexc01.americas.cpqcorp.net>, "Main, Kerry" <Kerry.Main@compaq.com> writes:	 > Robert,  > J >>> 4. Software Partners has/had a remote tape product called Thruway if IL > remember correctly.  It made remote tape drives appear local.  When I lastJ > used it, it needed DECnet, but I suspect it can also use tcpip by now.>> >  > Fyi - F > http://www.sp32.com/products/index.php (Software Partners Home Page)3 > Click on "Thruway" for the following description:  > K > "THRUway, The OpenVMS Remote Device Access System, bridges the gap from a H > remote VAX or AXP to a central VAX or AXP, simplifies file access, andN > provides easy and safe management of remote data from the main site. THRUwayJ > does this by, among other things, making clustered tape drives appear asJ > local drives to remote users, and by making remote disk drives appear as > local drives. "  >     M As long as thruway is the topic of discussion, I might mention another aspect I of the product that most people might not be aware of, even those who are N current customers.  Thruway goes to a lot of effort to still work when the twoL sides of the link are different vms versions.  This doesn't sound like a bigA deal, but you won't believe how much work I had to put into this.   N Thruway works by creating a virtual device, emulating either a tape drive or aN disk drive.  Applications, including backup, mount, init, and any applicationsN using rms or lower level access, issue qios to the virtual device.  These qiosO are transferred across the network link, where they are then issued to the real L device.  The status code and resultant data, if any, are transferred back toI the original node where the qio to the virtual device is posted complete.   N This is *comparatively* simple when both sides are running the same version ofN vms.  However, when you have the machine where the physical device is located L running an older version of vms than the machine where the virtual device isL located, you can confuse the older i/o system by using features it has never	 heard of.       I The following except from the thruway buglog illustrates this problem (in N thruway terminology, the client is the machine with the virtual device and the, server is the machine with the real device):      P --------------------------------------------------------------------------------N DLK 5-MAR-1999  BUG: Using THRUway v3.1.2 with VMS 7.2 on AXP, a connection is: 		successful, but typing a remote file over the connection/ 		yields errors. Here is part of the operation:   ; 		$  thruway connect/system disk adxp01"thruway":: DSA500:   		DECW_BKRDR= 		%THRUWAY-I-SPAWNED, process DECW_BKRDR created, id 0000025B A 		%THRUWAY-S-CONNECTED, ADXP01::_DSA500: connected as DECW_BKRDR  
 		(_SAC4:); 		$ typ decw_bkrdr:[KITS_VAX.UCX]UCXVAX_E02042_CVRLET.TXT;1   		%TYPE-W-OPENIN, error opening > 		DECW_BKRDR:[KITS_VAX.UCX]UCXVAX_E02042_CVRLET.TXT;1 as input$ 		-RMS-E-ACC, ACP file access failed0 		-SYSTEM-F-ILLIOFUNC, illegal I/O function code  M EWS 15-FEB-1999   Fixed.    The vms 7.2 version of RMS open appears to do an  ; 		acpcontrol operation with a fib control function code of  > 		FIB$C_CACHING_OPTIONS.  The Thruway client is not expecting : 		this operation, and the server, which may be running an @ 		earlier version of vms, may not be able to handle it anyway.  = 		Return SS$_UNSUPPORTED so that RMS will understand that it  = 		can't use this functionality.  This particular return code  . 		will not be treated as an error by rms open.    P --------------------------------------------------------------------------------          N Even if the older file system is familiar with the operation, some of the file attributes may have changed:        P --------------------------------------------------------------------------------N DLK 9-APR-1999	BUG: A THRUway connection (using TW v3.1.3) from VAX VMS 7.2 toA  		AXP VMS 6.2 works well. Copying files and issuing various DIR  ? 		commands also works well. However, backing up files from the  < 		AXP 6.2 node to a tape drive on the VAX 7.2 node over the A 		THRUway connection (logical name FLIP) fails with the following 	 		errors:   0 		OSCARS => backup/rewind/log flip:[000000]*.*;* 		mkb400:douger.bck/sav : 		%BACKUP-E-OPENDIR, error opening directory FLIP:[000000]1 		-SYSTEM-F-BADATTRIB, bad attribute control list ? 		%BACKUP-E-OPENIN, error opening FLIP:[000000]000000.DIR;1 as   		input 1 		-SYSTEM-F-BADATTRIB, bad attribute control list > 		%BACKUP-W-NOFILES, no files selected from FLIP:[000000]*.*;*  ; 		An image backup of the remote disk to local tape over the A 		THRUway connection using VMS BACKUP fails in a similar fashion.   > 		ADDENDUM: Using VMS BACKUP over the THRUway connection fails? 		similarly when connected to VAX VMS 6.1, 6.2, and 7.1 nodes,  8 		and when connected to AXP VMS 7.1 using PATHWAY as the@ 		transport. A similar backup of remote files on an AXP 7.2 node 		worked fine.   		A 		Using AXP VMS 7.2 THRUway connected to AXP 6.2, AXP 7.1 (DECnet @ 		transport this time), VAX 6.1, VAX 6.2 and VAX 7.1 failed on aA 		similar backup. VMS BACKUP of remote VAX 7.2 files worked fine.   K EWS 21-APR-1999   Fixed.    The ATR$C_ASCNAME attribute (file name, type &  @ 		version in ascii) had a size of 86 in 7.1.  However, the size 6 		for 7.2 is 252, probably related to the changes for ? 		windoze-compatible filenames.   When this much larger string  A 		was passed back to the 7.1 server, the XQP choked on it.  From  @ 		its viewpoint, the length was invalid.  The result was a "bad > 		attribute list" error.  So the server will now truncate the  		attribute to the 7.1 size.    P --------------------------------------------------------------------------------P --------------------------------------------------------------------------------N MMB 12-mar-2001 When connecting from a 7.2 AXP client to a disk on an earlier 8 		version of VMS and performing an image backup it backs= 		up the data twice, doubling the size of the savesets. This  @ 		does not happen when backing up 7.2 to 7.2. It does not happen= 		when any version of vms is backed up from any other version.@ 		except for 7.2 clients. Diag logs have been ftp'd in zip files* 		to Tachyon for "good" and "bad" backups.     EWS 21-mar-2001 fixed -- e  ; 		There is a problem when the server is running an earlier c? 		version vms than the client.  Attributes are often longer on h= 		later versions of vms.  Therefore the client may ask for annA 		attribute that is longer than the server is equipped to handle.e  A 		This was partially fixed in 3.1.4 (21-APR-99).  The server was  > 		modified to downgrade the size of attributes to the maximum A 		size the server version of vms can handle.  This prevented the t8 		server from choking on what appeared to be an invalid = 		attribute.  The server returns the smaller attribute to thesA 		client, which is then placed into the calling routine's buffer.i  A 		This appeared to be the solution.  However, it turns out there  @ 		is a problem for ascii attributes such as atr$c_ascname.  The ? 		pad value is blank rather than zero.  The XQP is supposed to e@ 		pad the field with blanks before returning it to the caller.  ? 		The thruway client does do that, or rather the qio issued by  @ 		the server does, which is then transferred back to the client.= 		The problem is that the padding is only to the *truncated* d9 		length, which is all the server node knows about.  The  < 		remainder of the user's buffer, that beyond the truncated # 		length, is not set to anything.     @ 		Therefore, the buffer returned to the user contains blanks up @ 		to the truncated length, followed by the original contents of ; 		the buffer, which is all binary zeros in the case of vms n< 		backup and could be absolute garbage in the case of other = 		programs.  The *entire* attribute buffer is supposed to be -6 		ascii and should be *completely* padded with blanks.  ; 		In the case of vms backup 7.2 and later, the presence of B> 		binary zeros in the ascname buffer causes weird behavior on > 		the part of vms backup.  The routine check_alias explicitly 5 		uses the ascname and the following comments appear:,  9 			Determine the length of the header filename to ensure  1 			exact matches.  This assumes that the ASCNAME o  			continues to be space filled.  ? 		The trailing zeros cause the check to fail.  This causes the tA 		file to be incorrectly flagged as an alias file.  The ultimate b> 		result is that every file on the disk gets backed up twice, B 		first in the normal way, then as a lost file (disk:[]xxx.yyy).  , 		Obviously, customers do not care for this.  @ 		The solution is to pad the entire buffer with the fill value, = 		not just the truncated length returned by the server.  The r9 		sp32lib routine copy_attribute_w_pad will perform this n= 		function, basing the fill value on the attribute type.  Thet< 		client has been modified to call this routine rather than & 		simply copying the truncated buffer.      P --------------------------------------------------------------------------------P --------------------------------------------------------------------------------P --------------------------------------------------------------------------------    O Anyway, as you can see from all this, thruway has had a lot of modifications toaN allow different versions of vms on both sides of the link.  There's a limit toN how far apart the versions can be, but I think it is greater than that allowedO with some competing products.  Even clustering expects that the versions of the ) various nodes be fairly close together.  e     -- dO ===============================================================================iM Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxa: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)sO ===============================================================================eH Randolph Duke (in Trading Places): "Mother always said you were greedy.". Mortimer Duke: "She meant it as a compliment!"   ------------------------------  # Date: Sat, 11 Aug 2001 22:46:20 GMTr& From: "Jeff Killeen" <Jeff@IDM-IO.com>Y Subject: Conference: Compaq Enterprise Technology Conference 2001 - Update 8/13/2001 (wwwc9 Message-ID: <0Bid7.6504$cv6.1486332@typhoon1.gnilink.net>    Dear Fellow IT Professional:  I Our goal for the Compaq Enterprise Technical Symposium 2001 is to deliver-K solid in-depth technical content for the Tru64, OpenVMS, and/or ProLiant IT J professional. After having reviewed the content I am delighted to say that? goal has been definitely achieved! The details are available ateF http://www.cets2001.com - please select "Session Catalog" on the left.  , You can still register for the conference atL http://www.cets2001.com/cets/reg/registration.jsp. I am happy to report thatJ Encompass members are registering at a faster rate for this Symposium thanH we experienced last year but because of the summer vacations and currentF economic conditions we have decided to extend the Early Bird discountsA through August 27 at midnight central USA time. Depending on whatsL registration options you choose those discounts can combine up to a total of $300.n    @ In-depth Technical Seminars - A classroom educational experience  K Our Pre-conference seminars are designed to provide more in-depth technicalsL information than an individual can receive in a breakout session. We provideF some seminars in 'lecture only' format while others offer the attendeeK 'hands-on experience'. These seminars are scheduled for Saturday, September C 8 and/or Sunday, September 9, and have a separate fee from the main- conference fees.    J Techworks Bootcamps - The fast track to learning a "new to you" technology  H This year I am pleased we have added a new feature to the Pre-conferenceE program. The Techworks bootcamps are intense classroom style Seminars K designed to assist an IT professional ramp up on a new technology. They arerL your fastest way to jump start learning a new technology. Selected Bootcamps include:  L 1459 Tru64/TruClusters 101 Bootcamp (Saturday and Sunday) - An Intro for the OpenVMS Professional  G 1640 Windows 2000 Bootcamp (Saturday and Sunday) - Windows 2000 for theA Windows NT 4 Administrator  G 1639 Exchange 2000 Bootcamp (Saturday and Sunday) Exchange 2000 for theg Exchange 5.x Administrator  F 1592 PMDF 101 Bootcamp (Saturday and Sunday) PMDF for Mail and Systems Administrators  F 1455 SAN 101 Bootcamp (Saturday only) - Intro to Storage Area Networks  D 1577 SAN 101 Bootcamp (Sunday only) - Intro to Storage Area Networks    G Detailed information and how to register for Pre-conference Seminars ora Techworks Bootcamp  ( For detailed information please download3 http://www.cets2001.com/privatedocs/Seminars.pdf orn0 http://www.cets2001.com/privatedocs/Seminars.txt  H If you have not yet registered - Log in and select "Register Now" on theH menu at the left side of the screen. Next, click "Edit" (near bottom) toJ bring up the screen with tabs showing sessions for which you can register.E Click on a tab, and select "add to cart" for the sessions you wish to  attend.i  F If you have already register for Symposium - Log in and select "UpdateL Registration" on the menu at the left side of the screen. Next, click "Edit"I (near bottom) to bring up the screen with tabs showing sessions for which K you can register. Click on a tab, and select "add to cart" for the sessionst you wish to attend.g  E NOTE: You do not need to register for the Symposium to register for a	K Seminar! If you are local to the Anaheim California area you can still gainiL the benefits of a Pre-Conference Seminar even if you can't take advantage of the Symposium during the week.     A very unique opportunity!  F I recently attended a workshop at MIT on bringing innovation into yourG organization. A key point of the workshop was that most true innovation2H comes from interactions with peers from outside your organization. It isA this external person to person interaction that gives you the new B perspectives that allows you to think outside of the box that yourI organization may be locked within. This Symposium is an especially unique D example of this opportunity. Because the Compaq Enterprise TechnicalG Symposium brings together fellow Compaq focused customers facing issuesaK similar to yours, Compaq development engineers, Compaq application providersF partners, Compaq Accredited Professionals like ASE's, and Compaq fieldL engineers, you will have the opportunity to interact with very knowledgeableD IT professionals who are approaching today's issues from 5 differentI perspectives. We believe this is unique in the industry and an incredibleo opportunity.   Joe Pollizzi	 President  Encompass, A Compaq User Group  6 A PDF version of the registration kit is available at:6 http://www.cets2001.com/privatedocs/CETS2001RegKit.pdf   ------------------------------  # Date: Sat, 11 Aug 2001 17:32:50 GMTs3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk>a Subject: Re: HSD10/ Message-ID: <3B756A8F.14DBC0B8@cableinet.co.uk>s   Steve Reece wrote: >  > Mike,tJ > Given that the HSD10 would need to be in either a BA350 or a BA356 shelfI > (the BA353 may be supported, but it's unlikely) then your better optiontJ > would be to use the backplane connectors on the shelf to connect through > to your MicroVAX 3100 system.I   yup.   > H > Your best bet would be to procure a TopGun blue BA356 shelf since thisF > should have the uprated fans to be able to take faster disks.  You'dG > then require a DS-BA356-MG 8-bit I/O Personality module to be able toUG > connect a cable such as the BA21R (50-pin high density male to 50-pinsG > low density recepticle) or BC10U (50-pin high density male both ends) F > since the personality module, like the shelf itself, has 50 pin high' > density female SCSI connectors on it.  > J > Using the BA356 shelf would allow you to use 8-bit (-VA) or 16-bit (-VW) > Storageworks disks.-  H However the SCSI on a MicroVAX 3100 is not wide, even on the M80, unlessE my memory is getting vague. So, BA350 or BA356 with 8 bit personalityr module.   G I have done just what is requested with MicroVAX 3100 M30 and M80, with-G BA350 and appropriate cable (which can be a bit fiddly with to insert).0D Also works on VAX 4000-100, and certainly faster than the same disks' served via DSSI on a HSD05 on the 4100.    > HTH. > Steve.   regards    -- a Tim.Llewellyn@cableinet.co.uk     C Standard disclaimer applies. My views in no way represent those of  ! my employers or service provider.0   ------------------------------  % Date: Sat, 11 Aug 2001 10:08:30 -0400y2 From: rdeininger@mindspring.com (Robert Deininger)F Subject: Re: I just have to post this - and apoligse later Alpha/IntelL Message-ID: <rdeininger-1108011008300001@user-2ive6an.dialup.mindspring.com>  5 In article <3B74B2B9.222ED4B5@videotron.ca>, JF Mezeic% <jfmezei.spamnot@videotron.ca> wrote:a   > Robert Deininger wrote:nL > > The wildfire replacement systems will work with EV7, and will be able to6 > > accept IPF replacement CPUs, from what I've read.  > P > Has such a commitment been made public ? Would Compaq actually commit on paper > for this ?  E I've either read it in something from Compaq, or in the trade press. eC Since I'm not shopping for this stuff, I didn't keep track.  Sorry.r  nO > Unless both Alpha and IA64 can co-exist on the same Wildfire equivalent "box"(  3 I believe I have read that co-existance is planned.      > > EV7 really means EV7x,? > > since there will be several generations if there is demand.  > K > Are you sure ? I was under the impression that Compaq was to send all EV7rN > engineers to Compaq as soon as EV7 is done. Who would be there to make those > new generation EV7x ?f  F I believe the transfer is after EV7x, not EV7, is done, with Compaq toG decide what "done" means.  I'm pretty sure one of the Compaq higher-ups-@ said as much a day or two after the announcement.  The number ofI generations of EV7 was explicitly left open-ended.  EV7 improvements neede; not stop until Compaq feel IPF is a worthwhile replacement..  ? (OpenVMS engineering has said they are porting to _current_ IPFwI processors. But nobody I've heard has talked about shipping systems usingn the current CPUs.)  K > Also, unless there are massive changes in Compaq management, it is to the-J > advantage of the existing Compaq heads to allow IA64 to surpass Alpha asP > quickly as possible. Remember that their excuse for killing Alpha is that IA64! > would become faster than Alpha.h  H ... in your surreal world, perhaps.  I suspect Compaq management is veryI interested in revenue and profit.  Despite their not checking with you in I advance, they apparently believe they are better off with IPF in the longpF term.  Meanwhile, I expect they will continue to ship the best systems, they can, using whatever CPUs are available.   -- l Robert Deininger rdeininger@mindspring.coma   ------------------------------    Date: 11 Aug 2001 08:32:47 -0700+ From: mend0070@tc.umn.edu (Phil Mendelsohn) F Subject: Re: I just have to post this - and apoligse later Alpha/Intel= Message-ID: <9fffd0d8.0108110732.4a160f51@posting.google.com>M  p mend0070@tc.umn.edu (Phil Mendelsohn) wrote in message news:<9fffd0d8.0108101316.62d9d250@posting.google.com>...F > The real issue here, is that Compaq appears to be in the business of. > making rather than that of making computers.   That should have read:    F "Compaq appears to be in the business of making money rather than that of making computers."    So much for being pithy.   ------------------------------  % Date: Sat, 11 Aug 2001 12:47:14 -0400c- From: JF Mezei <jfmezei.spamnot@videotron.ca>dF Subject: Re: I just have to post this - and apoligse later Alpha/Intel, Message-ID: <3B756190.FE97624C@videotron.ca>   Robert Deininger wrote:lJ > ... in your surreal world, perhaps.  I suspect Compaq management is veryK > interested in revenue and profit.  Despite their not checking with you insK > advance, they apparently believe they are better off with IPF in the long 	 > term.  a  H Compaq depends on Microsoft and Intel for survival. The later pays a bigM amount of money to help Compaq's marketing. As a result, guess where Compaq'st loyalties are ?t  L Compaq killed Alpha as part of its 180 restructuring plan in order to reduceM the number of platforms it had to 1-lower operating costs, 2-get enough moneyiH to do what it wants to do (develop NT solutions/support infrastructure).  J Compaq beleives that they are better off without VMS in the long term. TheH murder of Alpha is just a small step in that direction. And since CompaqN learned from Digital's mistake, it won't actively kill VMS like Palmer did, it will just slowly let it retire.-   ------------------------------  % Date: Sat, 11 Aug 2001 12:51:10 -0400m- From: JF Mezei <jfmezei.spamnot@videotron.ca>RF Subject: Re: I just have to post this - and apoligse later Alpha/Intel, Message-ID: <3B75627C.93D82A8E@videotron.ca>   Phil Mendelsohn wrote:H > "Compaq appears to be in the business of making money rather than that > of making computers."   L If that were truly the case, shouldn't Compaq be ditching is less profitable8 products and instead focus on its more profitable ones ?  J How do you explain that Compaq is so adament about its wintel products and/ hides its more profitable enterprise products ?t  K Compaq has positioned itself as a dependant of Intel and Microsoft.  CompaqnH was the only large company to openly support Microsoft in its anti-trustK trial, even though Compaq should have been the first one to testify AGAINST4@ microsoft since there is plenty of examples of microsoft forcingP digital/compaq to cancel products that would have otherwise competed against MS.  K If a company supports the guilty party so much, isn't it normal to questionK8 what sort of relationship it ahs with the guilty party ?   ------------------------------  % Date: Sun, 12 Aug 2001 01:19:44 -0700 % From: GreyCloud <wholland@tscnet.com>aF Subject: Re: I just have to post this - and apoligse later Alpha/IntelO Message-ID: <EB417F664E76E323.247E6F6CDC86084D.39F0B13BDAFD0B03@lp.airnews.net>3   JF Mezei wrote:g   > Rob Young wrote:9 > >  No.  You are wrong.  It is an industry standard, as:s > >e > >  HP  > >  SGI > >  Compaqx > >  IBM	 > >  Dell  > >  etc. etc. > >t6 > >   Will be manufacturing and selling IA64 hardware. >.K > *WILL* is the keyword. It isn't an industry standard right now. Alpha hasuP > greater market share than IA64 so ALpha is more of industry standard than IA64 > right now. >oO > Of course, killing of Alpha will just give IA64 "industry standard" status as O > soon as it comes out and it will get it without a fight because Compaq killed-C > Alpha (and never wanted to make Alpha a mainstream chip anyways).s  2 Hopefully, there's a little room for my 2 cents...Q I agree with your views on this... Could it be time for stockholders of Compaq toaQ take a firm hand if they knew what was really going on inside Compaq??  From whatcN I've gathered so far, it looks like some exec inside has sold out.  But I feelN that these business arrangements have gotten into a very complicated tangle of? agreements and I can almost smell microsoft in there somewhere.r   ------------------------------  % Date: Sun, 12 Aug 2001 11:32:43 -0400i2 From: rdeininger@mindspring.com (Robert Deininger)F Subject: Re: I just have to post this - and apoligse later Alpha/IntelL Message-ID: <rdeininger-1208011132440001@user-2iveame.dialup.mindspring.com>  D In article <Cqnd7.3411$Kl2.337679@newsread1.prod.itd.earthlink.net>,/ "mulp" <michaelpettengill@earthlink.net> wrote:h  A > "Robert Deininger" <rdeininger@mindspring.com> wrote in messageeH > news:rdeininger-1008011054100001@user-2ivec3b.dialup.mindspring.com...L > > These have been answered also.  The current servers will not support EV7N > > via board swap; a system swap will be required. (This was known before theJ > > big announcement.)  Compaq does plan a generation of EV7-based systemsL > > that will allow in-cabinet upgrades to IPF.  The server design groups atI > > Compaq are merging together, and will work together on these systems.c > . > Where is the statement supporting the above?  I Sorry, I haven't been keeping track, since I'm not shopping for systems. m I thought I mentioned that.e   I can only narrow it down to:e 1. Compaq's web pages, 2. Recent emails from Compaq,A' 3. Something recent from Terry Shannon,.) 4. The May NYC Alphaserver Diamond forum, 8 5. or maybe something similar that I saw in a newsgroup.  @ Since I'm not a journalist, I don't have to remember my sources.   --   Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Sun, 12 Aug 2001 15:42:16 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>t: Subject: Re: Looking for a Pine.exe for TCPIP 5.x services) Message-ID: <3B7687B8.1B616369@gtech.com>o   Jan-Erik Sderholm wrote:r
 > NS 4.61.4 > And I'm now getting "Contact" with the server, but6 > the DIR screen don't show any files, just the "upper > directory" link.   Very weird.t  ; I tested it from my home with NS 4.77 and no proxy. Worked.-5 And from wotk with NS 4.77 and a Squid proxy. Worked.-   Arne   ------------------------------  % Date: Sun, 12 Aug 2001 15:02:03 +0200-< From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@home.com>/ Subject: Re: open vms hobbist tcpip license????u( Message-ID: <3B767E4B.36A39A8F@home.com>  ; AFAIK, The licenses are *not* delivered on any Hobbyist CD.'  You get them by registering on :7 http://www.montagar.com/hobbyist/register_license.html.d  5 Then, after the validation, you'll get the liceses byt5 email. This email are in fact DCL scripts that can be 9 copied into your VMS system. If you are running with some=> VT-emulator on a PC, it just a cut-n-paste operation from your! email client into the VT-session.7   Jan-Erik Sderholm.a   rob merritt wrote: > E > hmm its was the montagar cd i got not dcl licensing scripts (like aoF > cslg pak any way) so i will poke arounfd at the site under licensing > and see what turns up= >=   ------------------------------  % Date: Sun, 12 Aug 2001 00:17:37 -0700d% From: GreyCloud <wholland@tscnet.com> ; Subject: Re: OpenVMS apps and Compaq committment story here O Message-ID: <D48B70053FF38C96.0856BDD8205CEA29.A45B110004D87112@lp.airnews.net>u   "David J. Dachtera" wrote:   > GreyCloud wrote: > >eJ > > I would think that it would be the natural thing to do... to progress. >iC > Yes - PROgress, not REgress. Understand the difference and you're ? > half-way there. From a tested and proven 64-bit platform to ahI > beta-quality, protoype model in early adoption is hardly a step-up, andl > rather a step back, I_M_NSHO.n > I > Remember: "general availability = Gamma Test". We'll see how IPF shakese0 > out. The news so far is less than encouraging. >cI > > Compaq does need to keep on top of competition.  Costs are increasingc > > ...p >w6 > ...for everyone. Why should Compaq be any different? >pC > By the end of their first year in a business curriculum, most all E > students know that one of the best ways to conquer cost and enhancetH > revenue is to increase volume. However, Compaq has vehemently resistedB > all such efforts, claiming some kind of "premium" justifies such/ > self-defeating pricing and lack of marketing.h >  > > but then what do I know??o > 2 > Good question. Can you provide some credentials? >o  G Me?  No.  I'm just an old retired ex vms admin/programmer from the Navyv Dept.eK I've been watching Compaq for three years now, wondering if I should investt or not. L Their advertising dept. seems to not know much or lacks the understanding inI basic marketing principles,... or they've been told something else that ItK don't know about.  Sun seems to have a somewhat better marketing dept., but  not that much better.eI There's only one company that I know of that knows how to market and that L ol' MS. Actually, my wife done a lot of analyzing MSs stock and doesn't likeL how things are handled... to her it looks too much like a pyramid scheme and won't invest there.s  K HP has put a lot of time and their own expertise into the Ia64, which makesaI me wonder whats wrong the PA-risc.  I can only ask simple questions whicheK may lead to difficult questions with no reasonable answer. Anyway, from alllJ aspects it still looks like it's primarily a money issue, and maybe even aH gamble on Compaqs' part.  In the 37 years I've worked in the electronicsJ industry, things have gotten smaller and faster and condensed... also lessL expensive.  However, maybe someone can shed some light as to the benefits of	 the Ia64.B     > F > As for my credentials, the info. is rather stale, but you can review# > http://www.djesys.com/resume.htmle >e. > > Intel puts out quite a bit of advertising. >rJ > Compaq needs to take a lesson from them - or just about ANYone! ...other& > than their current gurus and such... >oG > Sorry if this all sounds rather pompous - it's not intended that way.aH > However, since Compaq has been less than forthcoming with the supposedI > "logic" of not only doing this, but doing it the way it was done, well,tI > their credibility is shot to hell anyway - so whatever they say at thisgA > point is subject to a great deal of scrutiny and investigation.o >i > -- > David J. Dachterah > dba DJE Systemsr > http://www.djesys.com/ >e* > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/l   ------------------------------  % Date: Sat, 11 Aug 2001 17:11:06 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>o; Subject: Re: OpenVMS apps and Compaq committment story hereo) Message-ID: <3B754B0A.6AE29E93@gtech.com>r   Larry Kilgallen wrote:4 > I am not convinced that any decisionmakers either: >  >         a. read comp.os.vms- >    or:' >         b. are upset about Alpha-IA64   9 I doubt many real decision-makers read comp.os.vms - theyn" get their info from other sources.  < I am pretty sure, that 50% of decision-makers has read about5 the Alpha to IA-64 switch and has ordered the companyo% immediatetly to stop buying Alpha's !u   Arne   ------------------------------  % Date: Sat, 11 Aug 2001 22:28:37 +0200e& From: John McLean <mcleanj@dplanet.ch> Subject: Re: Press Release* Message-ID: <3B759575.7CCEDDD3@dplanet.ch>   Larry Kilgallen wrote: > X > In article <3B752CF6.513FD7CD@bigfoot.com>, Hamlyn Mootoo <univms@bigfoot.com> writes: > >u  	 .. snip !t   > B > Several people posting in this newsgroup seem to feel a majority@ > of customers prefer an all-Alpha future to IA64.  If that wereB > truly the case, Compaq could be made to feel the impact.  I have > doubts that it is true.r  B Sorry but you are not comparing apples with apples.  You should beG talking about an all-Alpha future compared to an IPF future.  Remember, G whatever processor appears in 2004 it will be different to the IA64 andi> at the moment that nature of that difference is a big unknown.   We don't know ...   - if it will be faster than IA64E - if it will be pin-compatible with Alpha or existing IA64 or neither-1 - how the VMS-to-processor issues will be handled   ) In short we know almost nothing about it.u  F Compaq's statements about improved performance may be true or they mayB be false.  Compaq's "donation" of the Alpha engineers and compilerC people may be beneficial to Compaq or may be detrimental because itbE might help the competition.  Compaq's statements about increasing thelH demand for VMS may be true or they may be complete hogwash.  Compaq haveE also said that customers want an industry-standard but have curiously 7 failed to state what advantage this will bring anyone.    G With that amount of uncertainty about the Intel-based future I can tellO< you that if I had a choice, I know what processor I would be
 preferring.  i     John McLeanl   ------------------------------  % Date: Sun, 12 Aug 2001 17:04:45 +0200b& From: John McLean <mcleanj@dplanet.ch> Subject: Re: Press Release* Message-ID: <3B769B0D.83249197@dplanet.ch>   Rob Young wrote: > Z > John McLean <mcleanj@dplanet.ch> wrote in message news:<3B759575.7CCEDDD3@dplanet.ch>... >  > > Compaq haveoI > > also said that customers want an industry-standard but have curiouslyg: > > failed to state what advantage this will bring anyone. > > I >     Some of them are obvious, maybe they don't want to bore us with the5M >     obvious (but they will when marketing mavens get cranking). They shoulds >     include: > : >         1)  Value.  Cheaper than high-end servers today.? >         2)  Shared components.   Racks.  Power Supplies, etc..B >         3)  Purchasing decisions.  Simple across the board here.4 >         4)  Support.  No specializations required.  ? I'm puzzled.  On what basis do you make the above assumptions ?u   In order ...  H 1 - Yes, the processor might be cheaper but I don't think that will makeA a big difference to the total cost of the hardware.  Licenses and H maintenance charges are unlikely to drop and suddenly encourage a lot ofD new customers.  If this was the case Compaq should already have made
 this move.  D 2 - Shared components ?  Again I don't see any substantial change or advantage.    C 3 - Simple purchasing decisions ?  Why should any simplification oftA decision-making change the picture ?  Are you suggesting that theCG freedom to dump VMS and move to unix on the same hardware will become am big factor in sales ?i  @ 4 - Support will not require specializations.  Maybe not for theH processor but perhaps it will remain so for the various other components (eg. GS series pieces).n    H Rob, you seem to be suggesting that mid to high-end computing is headingE towards generic hardware with only a label to distinguish between theeG manufacturers.  You are also suggesting that it will be possible to run = VMS or any of the various flavours of Unix on these machines.o  A As far as I am aware, Compaq have not said anything about ceasingeE manufacturing at any level.  I believe they will continue with the GSiE series and the various other machines, and as far as I know Compaq isaF already working with generic components where this is feasible from an engineering or quality aspect.  E Sure power supplies might change (I can't recall the respective poweroH supply for Alpha or for the undesigned IA64 derivative machine coming inD a few years) but I can't see that a change of processor will have anH impact on any other componentry, unless we are really talking of generic boxes.  E Do you have better information about their future directions with thep( whole box (ie. not just the processor) ?     John   ------------------------------  # Date: Sun, 12 Aug 2001 07:24:36 GMT $ From: family.entwisle@btinternet.comM Subject: Re: Problems installing Hobbyist Version of Vax OpenVMS - Any Ideas?e1 Message-ID: <3b762e6b.324997@news.btinternet.com>k  8 Thanks to everyone who helped, either here, or by email.  E It appears that the Vaxstation didn't like the harddrive I was tryingn to install to.  E I've noticed that the drive only disappears when I do a "SHOW DEV" ife= it has a SCSI id of 0.  Why this should happen I don't known.-  A I went to pick up my 3800 yesterday, and ended up walking with an.C AlphaServer 1000 as well.  This had a CD-ROM drive, so I managed topB get my 4000/60 up and running from that (the other harddrive I was@ previously using for the CD image works fine as a target drive).  % Thanks again for everyone who helped.d Duncan.t    @ On Sun, 05 Aug 2001 18:32:35 GMT, family.entwisle@btinternet.com wrote:   >Hi,< >	I'm trying to install the Hobbyist version of OpenVMS on a
 >4000/60 Vax.: > 9 >	My CD-ROM player didn't work (probably not 512bytes perh? >sector), so I copied it to a hard-drive.  I can boot from this D >harddrive, and install the save set onto the disk I want to installF >to.  However, when I try to boot the second disk, I'm simply returnedG >to the chevrons after about 10 seconds, with just a few blank lines on9F >the screen.  If I do a SHOW DEV after this, the second hard drive has3 >disappeared from the list (it was there before :-)e > > >	Has anyone got any idea what extremely dense thing I'm doing
 >wrong :-) > D >P.S.  Just won a MicroVAX 3800 on ebay (I know, I probably could ofF >gotten it cheaper else where - but I'm too lazy to hunt around the UKG >- sorry!) and I'm looking forward to playing with that, I just want tosF >pre-empt its arrival by getting the 4000/60 up and running.  The 3800F >- beautiful looking thing, I just want to wrap my arms around it - am >I sad?h >t >Cheers, >Duncan.   ------------------------------    Date: 12 Aug 2001 05:48:11 -0700, From: JanWermusch@hotmail.com (Jan Wermusch)3 Subject: Pseudo Terminals to emulate LAT Terminals?t< Message-ID: <c8f6eefa.0108120448.343b3e1@posting.google.com>   Hi,   C is it possible to use pseudo terminals on AXP OpenVMS 7.x to "fake"S LAT devices?  C We have a third party software that talks to peripheral devices via-B LAT (devices connected to terminal server ports). We would like toF replace the devices currently attached to the terminal servers by PCs.E Those PCs would talk to the AXP via TCP/IP. On the AXP side, we could E then write a communication server that handles the communication withk9 the PCs and redirects the messages to "pseudo terminals".t   Thanks in advances Jan Wermusch RCS  Germanyn   ------------------------------    Date: 12 Aug 2001 08:22:12 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)o7 Subject: Re: Pseudo Terminals to emulate LAT Terminals?e3 Message-ID: <rvIvj6GPpnxl@eisner.encompasserve.org>   k In article <c8f6eefa.0108120448.343b3e1@posting.google.com>, JanWermusch@hotmail.com (Jan Wermusch) writes:i  E > is it possible to use pseudo terminals on AXP OpenVMS 7.x to "fake"f > LAT devices? > E > We have a third party software that talks to peripheral devices viaqD > LAT (devices connected to terminal server ports). We would like toH > replace the devices currently attached to the terminal servers by PCs.G > Those PCs would talk to the AXP via TCP/IP. On the AXP side, we could-G > then write a communication server that handles the communication withy; > the PCs and redirects the messages to "pseudo terminals".t  G I presume you are comparing section 5.4.4.2 of the I/O User's ReferenceFB Manual to Chapter 6 of the same manual and finding things missing.   So the real question is:  7 	Does your third party software use the special calls ?   @ 	Does your third party software fail if the special calls fail ?  H Absent cooperation from the third party, experimentation seems to be the best approach.  C If the answer is "no" for your particular software, it is certainlysC possible to write a VMS driver to simulate the desired environment.h But that takes work.   ------------------------------    Date: 12 Aug 2001 10:57:48 -0700, From: JanWermusch@hotmail.com (Jan Wermusch)7 Subject: Re: Pseudo Terminals to emulate LAT Terminals?w= Message-ID: <c8f6eefa.0108120957.1118f5f4@posting.google.com>t  t Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote in message news:<rvIvj6GPpnxl@eisner.encompasserve.org>...m > In article <c8f6eefa.0108120448.343b3e1@posting.google.com>, JanWermusch@hotmail.com (Jan Wermusch) writes:t > G > > is it possible to use pseudo terminals on AXP OpenVMS 7.x to "fake"r > > LAT devices? > > G > > We have a third party software that talks to peripheral devices viasF > > LAT (devices connected to terminal server ports). We would like toJ > > replace the devices currently attached to the terminal servers by PCs.I > > Those PCs would talk to the AXP via TCP/IP. On the AXP side, we couldlI > > then write a communication server that handles the communication witho= > > the PCs and redirects the messages to "pseudo terminals".h > I > I presume you are comparing section 5.4.4.2 of the I/O User's ReferencenD > Manual to Chapter 6 of the same manual and finding things missing. >  > So the real question is: > 9 > 	Does your third party software use the special calls ?  > B > 	Does your third party software fail if the special calls fail ? > J > Absent cooperation from the third party, experimentation seems to be the > best approach. > E > If the answer is "no" for your particular software, it is certainlyeE > possible to write a VMS driver to simulate the desired environment.k > But that takes work.    B Thanks, for the quick response. Yes, I just read those sections...  C Actually, we cannot expect any cooperation from the third party. Soh= you are right, we will have to experiment. But this is an oldaF store-room application, we should better not play with too much... <g>  F Did I get it right: if the software uses the LAT-specific calls, there" is no way to simulate the devices?   Thanks.  Regards  Jan    ------------------------------   Date: 12 Aug 2001 07:32:16 GMT- From: djweath@attglobal.net (Dave Weatherall)-* Subject: Re: Red Code: where are we going?5 Message-ID: <DTiotGxQ0bj6-pn2-4nyS6VqueSnm@localhost>=  ? On Sat, 11 Aug 2001 06:40:30, Paul Sture <paul@sture.ch> wrote:   O > In article <y48zgsovno.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>, Jan m > Vorbrueggen wrote:R > > I think the problem with NT backup is that you cannot restore a working systemR > > from tape, i.e., there is no such thing as standalone backup (and we know thatR > > in 99.99% of all cases, a backup of a live system will yield a bootable system > > damn near to the original).- > > R > There _is_ such a thing as standalone backup/restore (sort of). All it takes is N > to have another installation of NT on another disk and boot to that for the H > restore. Granted, not many folks think of it, but it definitely works.  F Preferably on A FAT partition so you can fix it from DOS before movingE on  to fix the main partition. It can also be used to defragment the h7 main partition (especially if its running NT Server...)i   -- n Cheers - Dave.   ------------------------------   Date: 11 Aug 2001 17:05:49 CDT= From: wayne@tachysoft.xxx.580099.killspam.0160 (Wayne Sewell)o* Subject: Re: Red Code: where are we going?. Message-ID: <nJDMPI+ylDte@tachxxsoftxxconsult>   In article <y48zgsovno.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>, Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:P > I think the problem with NT backup is that you cannot restore a working systemP > from tape, i.e., there is no such thing as standalone backup (and we know thatP > in 99.99% of all cases, a backup of a live system will yield a bootable system > damn near to the original).s >   B Even better than the original disk, since it is defragmented.  :-)     --  O ===============================================================================oM Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxe: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)_O ===============================================================================aH Randolph Duke (in Trading Places): "Mother always said you were greedy.". Mortimer Duke: "She meant it as a compliment!"   ------------------------------    Date: 11 Aug 2001 08:59:28 -0400/ From: jordan@lisa.gemair.com (Jordan Henderson)r' Subject: Re: SYS$LOGIN:[some.directory]t* Message-ID: <9l3a7g$htr$1@lisa.gemair.com>  5 In article <01K6PHQRAHJM003IO3@tgmail.tg.nsw.gov.au>,H)  <paddy.o'brien@zzz.tg.nsw.gov.au> wrote:l >Arne wrote: >l >>JF Mezei wrote: N >>> I beleive that Unix has a construct which uses the tilde ~ to point to theO >>> login directory so that something such as ~/some/directory/myfile.txt wouldi7 >>> work no matter what the currect directory would be.n >>> 0 >>> Shouldn't VMS have some way to do the same ? >>  C >>> I realise that one can define a rooted logical that would allowdQ >>> MY$LOGIN:[some.directory] but it would be nice if it were to become somethingn >>> that is standard.y >>@ >>Send a suggestion to Compaq VMS Engineering for such a logical' >>(I think it should be SYS$LOGINROOT).u >  >I support Arne's proposal.' >nQ >Yep, I did jump in and throw all of my n feet into my mouth in an earlier reply.  >wS >Where I did get confused was because I make a rooted logical in my LOGIN.COM from h+ >SYS$LOGIN to generate other path logicals.d >o >Apologies.e >s >Regards, Paddyl >o  F I create a rooted logical in my LOGIN.COM named HOME for this purpose.  K I find it very handy to be able to create and work with project directoriesc quickly.  H I suppose Compaq could come up with something here, but it's pretty easy to do yourself.a  J I would like to see something like the ~user convention on Unix systems inF VMS.  Perhaps a logical USER$<user> could be a rooted logical for eachI user defined in the system.  This would create a large number of logicals E on big systems.  Perhaps a change to DCL or RMS that would cause suchn0 logicals to spring into life on use?  I dunno...   -Jordan Hendersony jordan@greenapple.com    ------------------------------    Date: 12 Aug 2001 08:11:05 -0000+ From: Doc.Cypher <doc_cypher@nym.alias.net>e- Subject: Re: Terry Shannon Tech Talk on Tru64.6 Message-ID: <20010812081105.25855.qmail@nym.alias.net>  " -----BEGIN PGP SIGNED MESSAGE-----  G On 11 Aug 2001, wayne@tachysoft.xxx.580099.killspam.0160 (Wayne Sewell)n wrote:> >In article <2de05464.0108091215.33970e1b@posting.google.com>,6 >utlonghornsrule@yahoo.com (Newbie JrSysAdmin) writes:  ? >> oh, yes, i'm "hiding" while saying my own words, rather thaniF >> bullshitting you by wrapping my name around a compaq press release.I >> gotta hand it to shannon, though- compaq's lackeys could not have spunw+ >> it any better. simply an amazing grovel.- >-K >You're still hiding.  We still don't know your real name, do we?  Okay, soaP >you're "saying your own words".  But whose words are they?  Anonymous posts can >be regarded as irrelevant.3  H Junior isn't hiding very well. He's not anonymous, posts are coming from+ 1400 Smith St. Houston. Tel (713) 853-6161.   K Alternatively, the matter could be taken up with postmaster@enron.com. That + is the originating domain for the messages.v  = Now Jr, please refrain from personal attacks in your posting.e     Doc. - -- i6 The bigger the humbug, the better people will like it.K ~ Phineas Taylor Barnum.                              http://vmsbox.cjb.net    -----BEGIN PGP SIGNATURE-----  Version: 2.6.2  @ iQEVAwUBO3W48sriC3SGiziTAQGtTAf7B7YCTP3uauv1kbYmNHUwqwnDI/8cpyKF@ dURBjO7ipFB7uoEYI5vfCDnuZZ9V81QpCTcdqZ1fcv5bfY2wx3sAcQSd15NTwENe@ S3V9+/EPY39f8JLRu7ByTXhpBfdrobQimFwRAV+EJRwXZEr25W88/mJfq42j/mZe@ 59qN/UZTjxxAWEPa5EXQWsr7Mu59a+adrPCzAKsQTlIq7a+9Vh+U3E8xSKQbUPrD@ mwuDc8sb99ek6Ge+7TPmCMh1zHiKoTOTYrJjM76rzFvlqMihae1jTXWKHbjHEwnE8 WG0ihzfFYADcPFK5hEKMlGw0azaD821tALg0q/iKW7FUWolI3dOSzA== =fh7a6 -----END PGP SIGNATURE-----    ------------------------------   Date: 11 Aug 2001 13:19:07 CDT= From: wayne@tachysoft.xxx.580099.killspam.0160 (Wayne Sewell)p- Subject: Re: Terry Shannon Tech Talk on Tru64a. Message-ID: <2hvw7fIKC80b@tachxxsoftxxconsult>  i In article <iDtc7.107157$TM5.15799642@typhoon.southeast.rr.com>, "Ken Farmer" <kfarmer@tru64.org> writes:iA > "Robert Deininger" <rdeininger@mindspring.com> wrote in messageaH > news:rdeininger-0808012318320001@user-2iveb8l.dialup.mindspring.com...@ >> In article <2de05464.0108081502.56624985@posting.google.com>,7 >> utlonghornsrule@yahoo.com (Newbie JrSysAdmin) wrote:s >> >> > ">u& >> > > Copyright 2001 Terry C. Shannon; >> > > Not affiliated with ... Compaq Computer Corporation.  >> >I >> > lackey, do you even know what a good hotel room in anaheim costs, orb6 >> > did your "non-affiliate" take care of it for you? >>9 >> What's happened to people's manners in this newsgroup?p >> >> --h >> Robert Deiningers >> rdeininger@mindspring.com >  > H > Plus he's/she's hiding in the shadows behind some alias.  Come out Jr. >   M As a Texan, I find it rather embarrassing that (s)he appears to be associatedOL with the University of Texas in some way.  Given the "newbie" and "Jr" part,; not to mention the obnoxious attitude, probably a freshman.      -- uO ===============================================================================sM Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxx : http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)eO ===============================================================================aH Randolph Duke (in Trading Places): "Mother always said you were greedy.". Mortimer Duke: "She meant it as a compliment!"   ------------------------------   Date: 11 Aug 2001 16:38:12 CDT= From: wayne@tachysoft.xxx.580099.killspam.0160 (Wayne Sewell) - Subject: Re: Terry Shannon Tech Talk on Tru64.. Message-ID: <v36kH2GbUt2q@tachxxsoftxxconsult>  s In article <2de05464.0108091215.33970e1b@posting.google.com>, utlonghornsrule@yahoo.com (Newbie JrSysAdmin) writes:ep > "Ken Farmer" <kfarmer@tru64.org> wrote in message news:<iDtc7.107157$TM5.15799642@typhoon.southeast.rr.com>...B >> "Robert Deininger" <rdeininger@mindspring.com> wrote in messageI >> news:rdeininger-0808012318320001@user-2iveb8l.dialup.mindspring.com...aB >> > In article <2de05464.0108081502.56624985@posting.google.com>,9 >> > utlonghornsrule@yahoo.com (Newbie JrSysAdmin) wrote:c >> >	 >> > > ">n( >> > > > Copyright 2001 Terry C. Shannon= >> > > > Not affiliated with ... Compaq Computer Corporation.  >> > >K >> > > lackey, do you even know what a good hotel room in anaheim costs, orC8 >> > > did your "non-affiliate" take care of it for you? >> >; >> > What's happened to people's manners in this newsgroup?q >> > >> > --t >> > Robert Deiningere >> > rdeininger@mindspring.com >> n >> oI >> Plus he's/she's hiding in the shadows behind some alias.  Come out Jr.  > > > oh, yes, i'm "hiding" while saying my own words, rather thanE > bullshitting you by wrapping my name around a compaq press release.tH > gotta hand it to shannon, though- compaq's lackeys could not have spun* > it any better. simply an amazing grovel.  J You're still hiding.  We still don't know your real name, do we?  Okay, soO you're "saying your own words".  But whose words are they?  Anonymous posts cans be regarded as irrelevant.     -- aO =============================================================================== M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxh: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)cO ===============================================================================,H Randolph Duke (in Trading Places): "Mother always said you were greedy.". Mortimer Duke: "She meant it as a compliment!"   ------------------------------  % Date: Sat, 11 Aug 2001 22:53:21 +0200-< From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@home.com>J Subject: Re: The Alpha Systems Customer Update will no longer be published( Message-ID: <3B759B41.1A1856E9@home.com>   HI.2@ I suppose you have to MIME enocde the PDF to be able to mail it.B And then use a tool that allows you to send MIME mails out of VMS.: PDF might be a bit to "binary" to be mailed as plain text.7 I'll take a closer look at GS. Thanks for the pointer !"  	 Jan-Erik.a   "Bradford J. Hamilton" wrote:a > . > Is there anything that prevents someone fromT > sending a PDF file using VMS Mail? (I've never tried it myself; when I get to work > on Monday, I can try it.)y >0   ------------------------------  % Date: Sat, 11 Aug 2001 22:02:24 +0200f< From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@home.com>J Subject: Re: The Alpha Systems Customer Update will no longer be published( Message-ID: <3B758F50.75CD3221@home.com>   Larry Kilgallen wrote: > G > I was under the impression that the VMS enewsletter only came in PDF.y4 > There is no supported PDF reader shipped with VMS.  ; It would suprise me *a lot* if not the vast majority of thei< VMS managers also happens to have an PeeCee somewhare, maybe even right on there own desk !  @ What I'm missing, is some tool to convert text and PS files into9 PDF that run on VMS, so I could mail pretty reports in an @ easy-to-use format directly from VMS to my users. Something like4 the "Acrobat Distiller". But that's another issue...   Jan-Erik Sderholm.h   ------------------------------    Date: 11 Aug 2001 07:33:54 -0700% From: drseuss@gwu.edu (Luke Bonanomi)l Subject: Unix Shell Portsp= Message-ID: <5331c4c2.0108110633.461a4ea8@posting.google.com>y   Greetings comp.os.vms,  D I'm looking for any information on Unix shells that have been portedB to the VMS operating system. If anyone could point me in the right$ direction, i'd be most appreciative.   Regards, ~LBt   ------------------------------  % Date: Sat, 11 Aug 2001 17:21:13 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>u Subject: Re: Unix Shell Portsa( Message-ID: <3B754D69.61CE123@gtech.com>   Luke Bonanomi wrote:F > I'm looking for any information on Unix shells that have been portedD > to the VMS operating system. If anyone could point me in the right& > direction, i'd be most appreciative.  ( I think the only current option is bash.   (http://gnv.sourceforge.net/)h   Arne   ------------------------------  % Date: Sat, 11 Aug 2001 12:37:18 +0200t, From: Didier Morandi <Didier.Morandi@gmx.ch>0 Subject: Re: URGENT: Ada position in Switzerland& Message-ID: <3B750ADF.D13BD874@gmx.ch>   Paul Sture wrote:t  o > And if this is the position I am thinking of, folks could contact _me_ for a full and proper job description.e   It is.   D.   ------------------------------   Date: 12 Aug 2001 07:32:09 GMT- From: djweath@attglobal.net (Dave Weatherall)L* Subject: Re: VAX/ALPHA FORTRAN and me! :-)5 Message-ID: <DTiotGxQ0bj6-pn2-yRxyEZvOzdvP@localhost>0  D On Sat, 11 Aug 2001 14:17:37, Paul Lentz <plentz@airmail.net> wrote:     > BETH20::HYPERMAN!> link 6 > ctif_create_daily_fraud_axp,sys$library:SQL$USER/LIB' > %LINK-W-NUDFSYMS, 1 undefined symbol:o# > %LINK-I-UDFSYM,         GET_ARGS e   leads to ...   > Here's the code at 2767... >  >  )J >            2767         STAT = GET_ARGS (ARGS, MAX_ARGS, NUM_ARGS)      8 >            2768         IF (STAT .NE. SS$_NORMAL) THENC >            2769             PRINT *, MODULE,'Error encountered in  > GET_ARGS func`A >            2770             PRINT *, ' Fortran status = ', STAT ( >            2771             GO TO 8000> >            2772         ELSEIF (NUM_ARGS .NE. MAX_ARGS) THENF >            2773             PRINT *, MODULE,' Wrong # of arguments.'( >            2774             GO TO 8000 >            2775         ENDIF   E So as the others have pointed out, this is a 'nomal' response to the e; CALL 000000 that the lack of the GET_ARGS routine leads to.   @ Now I don't remember whether GET_ARGS was a generic VMS FORTRAN E routine. However, there was something along those lines that changed rE during the move from VAX to Alpha. What it would be doing is to walk -F the argument list to ensure that the required number of arguments haveF been passed. If not,  it  returns an error status allowing the caller E to issue an error message instead of crashing when the routine tries eA to access the non-existent argument at effective address 0. (not r$ unlike the ACCVIO you're getting...)  D I'll try to remember to find some documentation about it when I get  back to work tomorrow.   -- h Cheers - Dave.  B PS  On VAX you checked the current argument list and the previous F argument frame by using the AP and FP registers. On Alpha the calling F mechanism changed and this why the the VAX inbuilt 'get_args' (IWICR) F feature ceased to work IIRC. Is it really nearly 10 years since I did  this VAX to AXP transition...?  F PPS I must get some experience with the F90 variant. It's something I - completely overlook as a cause of problems...h  $ IWICR = I Wish I Could Remember :-)    ------------------------------  % Date: Sat, 11 Aug 2001 09:17:37 -0500 % From: Paul Lentz <plentz@airmail.net>O* Subject: Re: VAX/ALPHA FORTRAN and me! :-)O Message-ID: <BA47920012F27FBA.04E654E12AA94986.E5B5460BF3EFAF4A@lp.airnews.net>   & paddy.o'brien@zzz.tg.nsw.gov.au wrote: > L > >> The problem is I can read FORTRAN and maybe even almost write it, but IK > >> can't get the it to re-compile and run properly on the ALPHA. I'm alsot  M > >> I've tried FORTRAN/EXTEND/ALIGN and managed to get it to compile, but itaJ > >> blows up when I try to run it, and even got linker errors a couple of > >> times.t  M > Phil's suggested URL is a good starting point, but you're implying problemst/ > at all levels: compiler, linker and run-time.y > 3 > O.K., easiest first, what are your linker errors?   H A couple of times I got reference errors like I wasn't linking up to theC right run time libraries. I'm used to compiling C and telling it...e  % LINK MY_APP,SYS$LIBRARY:VAXCRTL/LIB  e   or n  5 LINK MY_APP,SYS$LIBRARY:VAXCRTL/LIB,SQL$USER60/LIB      B but I'm not even sure what the main run-time-library is called for FORTRAN. ????? g   [SEE SNIP BELOW]  a > N > Secondly, try adding /warn=uninitialized to your Fortran command.  Hmm, thatK > is the default, so are you getting any?  Are you using the F90 or the F77c > compiler on Alpha?  ( I think it's the F77, but I'm not sure.    > N > Thirdly, at run-time, how does it "blow-up"?  Different results or an accessK > violation?  If so, look at the line of code highlighted in the traceback.i   Always access violations.    k  (? BETH20::HYPERMAN!> MCR SQL$PRE /FORTRAN/LIST/EXTEND/ALIGN -    s3 _BETH20::HYPERMAN!> ctif_create_daily_fraud_axp.sfot BETH20::HYPERMAN!>    % Well... it compiled with no errors...a     BETH20::HYPERMAN!> linkt4 ctif_create_daily_fraud_axp,sys$library:SQL$USER/LIB% %LINK-W-NUDFSYMS, 1 undefined symbol: ! %LINK-I-UDFSYM,         GET_ARGS i6 %LINK-I-UDFSYM,         VMH$FIXEDQ_UR (Weak Reference)6 %LINK-I-UDFSYM,         VMH$FIXEDQ_UW (Weak Reference)= %LINK-I-UDFSYM,         VMHDEB$TRACE_FREE_VM (Weak Reference)tA %LINK-I-UDFSYM,         VMHDEB$TRACE_FREE_VMLIST (Weak Reference)-< %LINK-I-UDFSYM,         VMHDEB$TRACE_GET_VM (Weak Reference)= %LINK-I-UDFSYM,         VMHDEB$TRACE_RET_VMH (Weak Reference)s6 %LINK-W-USEUNDEF, undefined symbol GET_ARGS referenced)         in psect $LINK$ offset %X000001B0h.         in module CTIF_CREATE_DAILY_FRAUD file! BILL00:[CTIF.SRC]CTIF_CREATE_DAILc Y_FRAUD_AXP.OBJ;4e    C hmmmm... it got linker errors but create an exe file anyway, but it 7 looks like it should blow up on this GET_ARGS thingy...o  C BETH20::HYPERMAN!> CDF :==$CTIF_SRC:CTIF_CREATE_DAILY_FRAUD_AXP.EXEa+ BETH20::HYPERMAN!> CDF A10809 TEST_CCDR.DATs; %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual  address=000000000000& 0000, PC=0000000000000000, PS=0000001B/ %TRACE-F-TRACEBACK, symbolic stack dump follows G   image    module    routine             line      rel PC           abs= PC      >                                             0 0000000000000000 00000000000000006  CTIF_CREATE_DAILY_FRAUD_AXP  CTIF_CREATE_DAILY_FRAUD  CTIF_CREATE_DAILY_FRAUDa>                                          2767 0000000000000164 0000000000030164>                                             0 FFFFFFFF8346D118 FFFFFFFF8346D118   Here's the code at 2767...     H            2767         STAT = GET_ARGS (ARGS, MAX_ARGS, NUM_ARGS)      6            2768         IF (STAT .NE. SS$_NORMAL) THENA            2769             PRINT *, MODULE,'Error encountered inG GET_ARGS func`?            2770             PRINT *, ' Fortran status = ', STAT1&            2771             GO TO 8000<            2772         ELSEIF (NUM_ARGS .NE. MAX_ARGS) THEND            2773             PRINT *, MODULE,' Wrong # of arguments.'&            2774             GO TO 8000            2775         ENDIFu    E Like you said, I think my main problem is that I'm not by any means acG FORTRAN programmer, and frankly don't know the "normal" compiler/linkera qualifiers that one would use. e   *Paul*   ------------------------------  % Date: Sat, 11 Aug 2001 09:25:30 -0500w% From: Paul Lentz <plentz@airmail.net>h* Subject: Re: VAX/ALPHA FORTRAN and me! :-)O Message-ID: <CA8A304373198C0C.5686B75EA98B070F.B41BF2BF7731D06B@lp.airnews.net>Y   Dave Weatherall wrote: > F > On Sat, 11 Aug 2001 01:50:31, Paul Lentz <plentz@airmail.net> wrote: >  > > Help!!!! > >i  K > > The problem is I can read FORTRAN and maybe even almost write it, but InJ > > can't get the it to re-compile and run properly on the ALPHA. I'm also > Been there...g > H > The first thing that will cause problems is Alignment. By default, theE > compiler will try to put all data items on natural boundaries. i.e. G > Real*4 on mod(4), R*8 on Mod(8) etc. Structure/record/arrays are doneeE > in a similar way. Your code may may not like this, especially wheree; > assumptions about memory layout (EQUIVALENCE's) are made.. > D > You can override this with a compiler switch or with CDEC$ OPTIONSB > directive. Start with the former. You'll need to check with HELPG > FORTRAN /ALIGN (IIRC) 'cos I can't remember the correct syntax. Years G > ago I created myself a  command file (COMPILE_MODULE) that determinesoE > which architecture I'm on and applies the relevant switches so I've2" > 'forgotten' the precise wording.  D I tried a few of the variations of the /ALIGN= qualifier but none ofF them seemed to work and gave me compiler errors until I tried straight /ALIGN.    *Paul*   ------------------------------  % Date: Sat, 11 Aug 2001 09:21:15 -0500e% From: Paul Lentz <plentz@airmail.net>1* Subject: Re: VAX/ALPHA FORTRAN and me! :-)O Message-ID: <A8F4CF8A67A9B1B1.72BED07F08372C3C.897794E13D0A1A21@lp.airnews.net>i   Phil Howell wrote:  K > > The problem is I can read FORTRAN and maybe even almost write it, but IeJ > > can't get the it to re-compile and run properly on the ALPHA. I'm also > >wL > > I've tried FORTRAN/EXTEND/ALIGN and managed to get it to compile, but itI > > blows up when I try to run it, and even got linker errors a couple ofn
 > > times.  K > One thing that can cause problems is the change in the default for commonu > blocks' > on vax the default psect_attr was shrs > on alpha it is noshrJ > to use the debugger you need to compile and link and run with the /debug > qualifieri( > then just type HELP at the dbg> promptI > you should also consult http://www.compaq.com/fortran/migrating-va.htmla9 > and if that doesn't help then post in comp.lang.fortranh; > dec/compaq/intel fortran support people will often assistu  D Thanks Phil... I'll check this stuff out. (don't we all hate it when" somebody writes a Thanks message).   *Paul*   ------------------------------  % Date: Sat, 11 Aug 2001 10:34:31 -0400f2 From: rdeininger@mindspring.com (Robert Deininger)* Subject: Re: VAX/ALPHA FORTRAN and me! :-)L Message-ID: <rdeininger-1108011034320001@user-2ive6an.dialup.mindspring.com>  
 In articleD <BA47920012F27FBA.04E654E12AA94986.E5B5460BF3EFAF4A@lp.airnews.net>, plentz@airmail.net wrote:7    J > A couple of times I got reference errors like I wasn't linking up to theE > right run time libraries. I'm used to compiling C and telling it...0 > ' > LINK MY_APP,SYS$LIBRARY:VAXCRTL/LIB  : >  > or n > 7 > LINK MY_APP,SYS$LIBRARY:VAXCRTL/LIB,SQL$USER60/LIB   x > D > but I'm not even sure what the main run-time-library is called for > FORTRAN. ????? a  G The linker will generally find the libraries Fortran needs on its own. w9 Just link with the libraries that your application needs.i   >  > [SEE SNIP BELOW] >    > > P > > Secondly, try adding /warn=uninitialized to your Fortran command.  Hmm, thatM > > is the default, so are you getting any?  Are you using the F90 or the F77. > > compiler on Alpha? > * > I think it's the F77, but I'm not sure.   H Make sure.  The listing file will tell you.  You'll probably want to useF F77. F90 is not source-code compatible with VAX Fortran in some cases.  E Recent Fortran installation kits make F90 the default for the FORTRANr1 verb, unless the installer overrides this choice.     P > > Thirdly, at run-time, how does it "blow-up"?  Different results or an accessM > > violation?  If so, look at the line of code highlighted in the traceback.t >  > Always access violations.    G >  tA > BETH20::HYPERMAN!> MCR SQL$PRE /FORTRAN/LIST/EXTEND/ALIGN -    p5 > _BETH20::HYPERMAN!> ctif_create_daily_fraud_axp.sfo= > BETH20::HYPERMAN!> = > ' > Well... it compiled with no errors...l >  >  > BETH20::HYPERMAN!> link)6 > ctif_create_daily_fraud_axp,sys$library:SQL$USER/LIB' > %LINK-W-NUDFSYMS, 1 undefined symbol:e# > %LINK-I-UDFSYM,         GET_ARGS u8 > %LINK-I-UDFSYM,         VMH$FIXEDQ_UR (Weak Reference)8 > %LINK-I-UDFSYM,         VMH$FIXEDQ_UW (Weak Reference)? > %LINK-I-UDFSYM,         VMHDEB$TRACE_FREE_VM (Weak Reference)rC > %LINK-I-UDFSYM,         VMHDEB$TRACE_FREE_VMLIST (Weak Reference)-> > %LINK-I-UDFSYM,         VMHDEB$TRACE_GET_VM (Weak Reference)? > %LINK-I-UDFSYM,         VMHDEB$TRACE_RET_VMH (Weak Reference):8 > %LINK-W-USEUNDEF, undefined symbol GET_ARGS referenced+ >         in psect $LINK$ offset %X000001B040 >         in module CTIF_CREATE_DAILY_FRAUD file# > BILL00:[CTIF.SRC]CTIF_CREATE_DAILn > Y_FRAUD_AXP.OBJ;4r >  > E > hmmmm... it got linker errors but create an exe file anyway, but ito9 > looks like it should blow up on this GET_ARGS thingy...i  E That's normal.  Unresolved references at link time only cause a fatal2E error at run time if you reference them.  Then they show up as access5 violations.n   > E > BETH20::HYPERMAN!> CDF :==$CTIF_SRC:CTIF_CREATE_DAILY_FRAUD_AXP.EXE>- > BETH20::HYPERMAN!> CDF A10809 TEST_CCDR.DAT.= > %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtualo > address=000000000000( > 0000, PC=0000000000000000, PS=0000001B1 > %TRACE-F-TRACEBACK, symbolic stack dump followsaI >   image    module    routine             line      rel PC           absm
 > PC      @ >                                             0 0000000000000000 > 00000000000000008 >  CTIF_CREATE_DAILY_FRAUD_AXP  CTIF_CREATE_DAILY_FRAUD  > CTIF_CREATE_DAILY_FRAUDr@ >                                          2767 0000000000000164 > 0000000000030164@ >                                             0 FFFFFFFF8346D118 > FFFFFFFF8346D118 >  > Here's the code at 2767... >  >  nJ >            2767         STAT = GET_ARGS (ARGS, MAX_ARGS, NUM_ARGS)      8 >            2768         IF (STAT .NE. SS$_NORMAL) THENC >            2769             PRINT *, MODULE,'Error encountered ins > GET_ARGS func`A >            2770             PRINT *, ' Fortran status = ', STAT=( >            2771             GO TO 8000> >            2772         ELSEIF (NUM_ARGS .NE. MAX_ARGS) THENF >            2773             PRINT *, MODULE,' Wrong # of arguments.'( >            2774             GO TO 8000 >            2775         ENDIF   E What is "GET_ARGS" supposed to do?  It's not a Fortran call, that I'm=G aware of.  (It might be newish, and I missed it.)  If it is supplied byrC Fortran, the manual should explain the steps needed to link it in. -E Otherwise, you or some third party is supposed to supply the routine.-    G > Like you said, I think my main problem is that I'm not by any means asI > FORTRAN programmer, and frankly don't know the "normal" compiler/linker8! > qualifiers that one would use. o  F The most "normal" Fortran command is just FORTRAN, and the most normalE link command is LINK.   No qualifiers.  You may need more if you haveb@ nonstandard source formatting (long lines) or external routines.  G Your SQL$PRE thingy is obviously adding another layer, but I don't know  anything about that.   -- p Robert Deininger rdeininger@mindspring.comi   ------------------------------  % Date: Sat, 11 Aug 2001 17:13:59 +0200I= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>a* Subject: Re: VAX/ALPHA FORTRAN and me! :-)) Message-ID: <3B754BB7.ED8F74C2@gtech.com>.   Paul Lentz wrote:e > Can anybody help me?  . Very difficult based on the information given.   Arne   ------------------------------  % Date: Sun, 12 Aug 2001 18:58:21 +0010i% From: paddy.o'brien@zzz.tg.nsw.gov.aun* Subject: Re: VAX/ALPHA FORTRAN and me! :-)5 Message-ID: <01K722ATVOHU003SU2@tgmail.tg.nsw.gov.au>t   Dave Weatherall wrote:  A >Now I don't remember whether GET_ARGS was a generic VMS FORTRAN gF >routine. However, there was something along those lines that changed F >during the move from VAX to Alpha. What it would be doing is to walk   K To my knowledge, there has never been a GETS_ARGS "intrinsic" on VMS.  The AE only ways that I know are to use the CLI routines or LIB$GET_FOREIGN.   M Is this really a port from VAX, or from some other platform?  It looks Unixy.s   Regards, Paddy   Paddy O'Brien, Transmission Development,-
 TransGrid, PO Box A1000, Sydney South,  NSW 2000, Australiai& (Street address, 201 Elizabeth Street)     Tel:   +61 2 9284-3063 Fax:   +61 2 9284-3050& Email: paddy.o'brien@zzz.tg.nsw.gov.au  M Either "\'" or "\s" (to escape the apostrophe) seems to work for most people, ; but that little whizz-bang apostrophe gives me little spam.:   ------------------------------  % Date: Sun, 12 Aug 2001 19:27:37 +0010u% From: paddy.o'brien@zzz.tg.nsw.gov.aug* Subject: Re: VAX/ALPHA FORTRAN and me! :-)5 Message-ID: <01K723B4NKIA003UMI@tgmail.tg.nsw.gov.au>i   Paul,   M O.K.  Let's try another tack, after you've had various responses  (this *is* t a great newsgroup).,  @ The compiler warnings regarding alignment were just warnings or I informationals.  Even on a VAX, this would slug performance, but is more - critical on Alpha.  N Your main problem is the GET_ARGS.  As I replied to Dave Weatherall, I do not J believe this has ever been a VMS intrinsic.  If it had on VAX, they would N have continued it on Alpha (it does not appear in $help fortran intrinsic, on < either platform).  Their policy being not to break old code.  K So, do you have a separate source file (or one of your own libraries) that GI contains this?  If so, this will have to be compiled and included in the F linker command.)  G Since you have compiled successfully your Fortran code, this is now no 2K different from having object files from any other language.  The linker is >L either your best friend or your worst enemy.  Find where GET_ARGS lives and N you're home and dry.  Perhaps on the VAX you had an OPT file or a COM file to 3 perform the linkage.  These should give you a clue.    Regards, Paddy   Paddy O'Brien, Transmission Development, 
 TransGrid, PO Box A1000, Sydney South,  NSW 2000, Australia & (Street address, 201 Elizabeth Street)     Tel:   +61 2 9284-3063 Fax:   +61 2 9284-3050& Email: paddy.o'brien@zzz.tg.nsw.gov.au  M Either "\'" or "\s" (to escape the apostrophe) seems to work for most people, ; but that little whizz-bang apostrophe gives me little spam.    ------------------------------  % Date: Sun, 12 Aug 2001 12:37:48 +0100 2 From: Steve Parker <steve@abandonhope.demon.co.uk>* Subject: Re: VAX/ALPHA FORTRAN and me! :-)6 Message-ID: <07BIdIAMqmd7EwZ4@abandonhope.demon.co.uk>  H In article <01K723B4NKIA003UMI@tgmail.tg.nsw.gov.au>, paddy.o'brien@zzz. tg.nsw.gov.au writes >Paul, o >nN >O.K.  Let's try another tack, after you've had various responses  (this *is*  >a great newsgroup). > A >The compiler warnings regarding alignment were just warnings or eJ >informationals.  Even on a VAX, this would slug performance, but is more  >critical on Alpha.e >lO >Your main problem is the GET_ARGS.  As I replied to Dave Weatherall, I do not aK >believe this has ever been a VMS intrinsic.  If it had on VAX, they would CO >have continued it on Alpha (it does not appear in $help fortran intrinsic, on t= >either platform).  Their policy being not to break old code.  > L >So, do you have a separate source file (or one of your own libraries) that J >contains this?  If so, this will have to be compiled and included in the  >linker command. >VH >Since you have compiled successfully your Fortran code, this is now no L >different from having object files from any other language.  The linker is M >either your best friend or your worst enemy.  Find where GET_ARGS lives and sO >you're home and dry.  Perhaps on the VAX you had an OPT file or a COM file to -4 >perform the linkage.  These should give you a clue. >  >Regards, Paddyz >l >Paddy O'Brien,O >Transmission Development, >TransGrid,: >PO Box A1000, Sydney South, B >NSW 2000, Australia' >(Street address, 201 Elizabeth Street)' >e >z >Tel:   +61 2 9284-3063  >Fax:   +61 2 9284-3050a' >Email: paddy.o'brien@zzz.tg.nsw.gov.aue >,N >Either "\'" or "\s" (to escape the apostrophe) seems to work for most people,< >but that little whizz-bang apostrophe gives me little spam. >t  G Just to add my 2p worth to all the comments above I've just fired up myeH trusty old VAX and cannot find any intrinsic GET_ARGS function so I'd beD inclined to agree with the above. However I am using F77 and have noF experience of F90 so if it is something added at that stage I could be wrong.  A "Britney Spears has been romantically linked with Prince William. = If they got married she could be the next Queen of England...e3 Get your pen out Elton - I feel a crash coming on."e  ' Mark Lamarr - Never Mind the Buzzcocks./   ------------------------------  % Date: Sat, 11 Aug 2001 16:35:28 -0700a% From: GreyCloud <wholland@tscnet.com>S* Subject: Re: VAX/ALPHA FORTRAN and me! :-)O Message-ID: <2FD3E80F033E3F6A.E50609201E94F28A.DDB8E64D8DBFD874@lp.airnews.net>a   Paul Lentz wrote:A  ( > paddy.o'brien@zzz.tg.nsw.gov.au wrote: > >lN > > >> The problem is I can read FORTRAN and maybe even almost write it, but IM > > >> can't get the it to re-compile and run properly on the ALPHA. I'm alsoo >tO > > >> I've tried FORTRAN/EXTEND/ALIGN and managed to get it to compile, but itkL > > >> blows up when I try to run it, and even got linker errors a couple of
 > > >> times.t >cO > > Phil's suggested URL is a good starting point, but you're implying problemsr1 > > at all levels: compiler, linker and run-time._ > >_5 > > O.K., easiest first, what are your linker errors?  >eJ > A couple of times I got reference errors like I wasn't linking up to theE > right run time libraries. I'm used to compiling C and telling it...W > % > LINK MY_APP,SYS$LIBRARY:VAXCRTL/LIBD >T > or >_4 > LINK MY_APP,SYS$LIBRARY:VAXCRTL/LIB,SQL$USER60/LIB >ED > but I'm not even sure what the main run-time-library is called for > FORTRAN. ????? >) > [SEE SNIP BELOW] >  > >DP > > Secondly, try adding /warn=uninitialized to your Fortran command.  Hmm, thatM > > is the default, so are you getting any?  Are you using the F90 or the F77E > > compiler on Alpha? >0) > I think it's the F77, but I'm not sure.B >e > > P > > Thirdly, at run-time, how does it "blow-up"?  Different results or an accessM > > violation?  If so, look at the line of code highlighted in the traceback._ >: > Always access violations.X > = > BETH20::HYPERMAN!> MCR SQL$PRE /FORTRAN/LIST/EXTEND/ALIGN - 5 > _BETH20::HYPERMAN!> ctif_create_daily_fraud_axp.sfo0 > BETH20::HYPERMAN!> >0' > Well... it compiled with no errors...K >y > BETH20::HYPERMAN!> link 6 > ctif_create_daily_fraud_axp,sys$library:SQL$USER/LIB' > %LINK-W-NUDFSYMS, 1 undefined symbol: " > %LINK-I-UDFSYM,         GET_ARGS8 > %LINK-I-UDFSYM,         VMH$FIXEDQ_UR (Weak Reference)8 > %LINK-I-UDFSYM,         VMH$FIXEDQ_UW (Weak Reference)? > %LINK-I-UDFSYM,         VMHDEB$TRACE_FREE_VM (Weak Reference)0C > %LINK-I-UDFSYM,         VMHDEB$TRACE_FREE_VMLIST (Weak Reference)3> > %LINK-I-UDFSYM,         VMHDEB$TRACE_GET_VM (Weak Reference)? > %LINK-I-UDFSYM,         VMHDEB$TRACE_RET_VMH (Weak Reference) 8 > %LINK-W-USEUNDEF, undefined symbol GET_ARGS referenced+ >         in psect $LINK$ offset %X000001B0L0 >         in module CTIF_CREATE_DAILY_FRAUD file# > BILL00:[CTIF.SRC]CTIF_CREATE_DAILn > Y_FRAUD_AXP.OBJ;4  > E > hmmmm... it got linker errors but create an exe file anyway, but itR9 > looks like it should blow up on this GET_ARGS thingy..., >DE > BETH20::HYPERMAN!> CDF :==$CTIF_SRC:CTIF_CREATE_DAILY_FRAUD_AXP.EXE - > BETH20::HYPERMAN!> CDF A10809 TEST_CCDR.DAT,= > %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtualA > address=000000000000( > 0000, PC=0000000000000000, PS=0000001B1 > %TRACE-F-TRACEBACK, symbolic stack dump follows-I >   image    module    routine             line      rel PC           abs  > PC@ >                                             0 0000000000000000 > 00000000000000007 >  CTIF_CREATE_DAILY_FRAUD_AXP  CTIF_CREATE_DAILY_FRAUDe > CTIF_CREATE_DAILY_FRAUD @ >                                          2767 0000000000000164 > 0000000000030164@ >                                             0 FFFFFFFF8346D118 > FFFFFFFF8346D118 >  > Here's the code at 2767... >t >eD >            2767         STAT = GET_ARGS (ARGS, MAX_ARGS, NUM_ARGS)8 >            2768         IF (STAT .NE. SS$_NORMAL) THENC >            2769             PRINT *, MODULE,'Error encountered inl > GET_ARGS func`A >            2770             PRINT *, ' Fortran status = ', STATe( >            2771             GO TO 8000> >            2772         ELSEIF (NUM_ARGS .NE. MAX_ARGS) THENF >            2773             PRINT *, MODULE,' Wrong # of arguments.'( >            2774             GO TO 8000 >            2775         ENDIFo >lG > Like you said, I think my main problem is that I'm not by any means ahI > FORTRAN programmer, and frankly don't know the "normal" compiler/linkerO  > qualifiers that one would use. >t > *Paul*   Hi.   J To start with, the undefined symbol message means just that.... undefined.< Look thru your source code for a function named GET_ARGS(...R It has to exist somewhere, and is no different than C in regards to its existence.  L I'm sure you know that you have to clear the very first error message before continuing.rN There may be the include of  '($clidef)' missing, but I think you need to hunt down the function first.   ------------------------------  $ Date: Tue, 7 Aug 2001 06:48:10 -0400/ From: "IanPercival" <IanPercival@email.msn.com> 5 Subject: Re: VMS 7.3 experiences? - Cache Performancet) Message-ID: <#CBkx#yHBHA.340@cpmsnbbsa09>A   Nice work Rob!   Some other thoughts....N  J When comparing overall performance between VIOC and XFC one has to be veryJ careful about "like for like" comparisons.   Cache needs memory.   VIOC onK Alpha is NOT a dynamic cache - it permanently allocates memory for itself -nE I call this a "permanent" cache.  XFC by default is a dynamic cache -tK returning memory whenever requested.  The memory management subsystem is byiI default configured to favour the modified page list as its primary cache./F The only TRUE method you would have for comparing performance, as VIOCJ doesn't have dynamic capability, would be to configure XFC to have exactlyK the same amount of permanently allocated memory.  This is achieved by usingaK a reserved memory section as described in the documentation - make this the-J same size as VCC_MAXCACHE (I forget the exact parameter name used by VCC -L not logged onto a system right now).  Then compare.  I'd be surprised if the  results differed so much then...   Regards,   Iani ex XFC Project Leader   3 "Rob Young" <robyoung@my-deja.com> wrote in messageF7 news:9c40b5bf.0108062058.744bcc53@posting.google.com... # > cmcgav@ionet.net wrote in messager4 news:<bbltmt44uv2t2njmqmch61b59d457lnnqm@4ax.com>...G > > On 2 Jul 2001 12:08:23 -0500, young_r@encompasserve.org (Rob Young),
 > > wrote: > >T9 > > >In article <C2256A7D.004AA3C1.00@jklh21.valmet.com>,/" norm.raphael@jamesbury.com writes: > > >> > > >> > > >> Tom,  > > >>K > > >> According to the cover letter for V7.3, V6.2 is _not_ supported in at > > >> migration-modeeH > > >> (or any other mode) with V7.3.  I have been told this is at least partly because	 > > >> of]K > > >> mount hangs with volume shadowing on one of the Field Test releases.m > > >>B > > >> Do you have any experience with this, positive or negative. > > >> > > > H > > > Last week I booted an Alpha into a VAX 6.2 cluster.  Alpha runningC > > > 7.2-1 with latest SYS patch (but not the very latest, the onenA > > > updated Thursday or so?).  Mounted disks not in use, copiednL > > > those files, that's easy.  But I also mounted and copied all files offL > > > a VAX based shadowset.  Worked like a charm.  One datapoint does not aL > > > case make.  Your mileage may vary.  And the Alpha was removed from the# > > > cluster after this operation.d > > >i	 > > > Robe > >e > >tH > > Well, we are installing a new DS20E system, and did some simple timeE > > trials with a batch application that does a good mix of reads andt > > writes._ > >f= > > The disks were served by an HSG80 dual controller system.r > >. > > HSG caching turned off > >l  > > 7.2-1    No VIOC        6min > > 7.2-1    VIOC cache   4min% > > 7.3      New XFC cache   9min!!!!  > >- > > HSG caching turned onu > >L@ > > 7.2-1   VIOC cache, HSG cache                      2min 1sec? > > 7.3      New XFC cache, HSG cache               2min 20 sec  > > G > > Needless to say we were surprised and disappointed by the results..T > >FI > > Plus the IO's reported by the 7.3 runs were much higher than the IO's E > > from the 7.2-1 runs. CPU time and buffered were nearly identical.R > >nB > > Also all drives would only mount under VIOC compatibilty mode. > > E > > Any ideas? I used the same settings for the 7.3 test as it was anL+ > > upgraded copy of the 7.2-1 system disk.D >n; > There is so much here... first, XFC will do pre-fetching:r >uB > http://www.openvms.compaq.com:8000/73final/6017/6017pro_077.html > G > In an OpenVMS Cluster, different nodes can use different data caches. F > This allows mixed architecture clusters to benefit from XFC. OpenVMSH > Alpha nodes can use either XFC or VIOC. OpenVMS VAX nodes can use only' > VIOC, as described in Section 18.5.6.> > G > XFC improves I/O performance and contains the following features thatv > are not available with VIOC: >  > Read-ahead caching! > Automatic resizing of the cache0 > Larger maximum cache size ; > No limit on the number of closed files that can be cached 9 > Control over the maximum size of I/O that can be cached 8 > Control over whether cache memory is static or dynamic >  > ---0 >0C > So this tells us all your I/O is random.  Or is it?  When you sayT > "cacheH > turned off on the HSG80s", you mean write-back cache?  You didn't turn > off ) > read cache?  When using XFC, what does:  >  > $ analyze/system > SDA> XFC SHOW SUMMARYF >6	 > reveal?  >e > I am peeling through:  > : > http://www.decus.gr.jp/decus99/sessioncd/NOTES/OV166.PDF >NG > Slide seventeen shows how you can zoom in on individual files, locate  > the + > file id on a directory/full filename.ext;e >u > then in SDA: >RF > SDA> XFC SHOW FILE/ID=xxx  ! Converted to hex, see slide for details >=G > With both VIOC and XFC, what are your hit rates:  show memory/cache ?E >( > To a another PDF of Ian's: > : > http://www.decus.gr.jp/decus99/sessioncd/NOTES/OV167.PDF >sD > look at individual files with less detail, but mostly good enough: >N8 > $ show mem/cache/file=(device:[directory]filename.ext) >n1 > Slide 32 shows that IO latency is less for XFC.n > H > However, on slide 33, we see VIOC outperforming XFC for reads to smallB > files, 1000 block file , 100000 I/Os and VIOC takes 3 minutes 54
 > seconds,! > XFC takes 4 minutes 14 seconds.y >sC > The tables are turned drastically in slide 34.  1.5 million blockA > file,mC > 300000 I/Os and XFC takes 17 minutes, 36 seconds... VIOC takes 50s	 > minuteso
 > 24 seconds.h >oH > So what is going on?  You have small files, guess #1.  Second guess is > thatG > you somehow aren't doing the same thing.  To report that you had muche > higher< > I/Os on the 7.3 runs on the face of it doesn't make sense. >vH > Outline what you are doing, how you are doing it , size of files , XFC > statst > before and after, etc. etc.n >oH > Basically, not enough to go on.  By the time there is, you may have it	 > figured 	 > out :-)8 >- > Robh   ------------------------------   Date: 11 Aug 2001 11:06:27 CDT= From: wayne@tachysoft.xxx.580099.killspam.0160 (Wayne Sewell)n( Subject: Re: We've launched TAPESYS v6.0. Message-ID: <2QgAR7hA2SdR@tachxxsoftxxconsult>  a In article <3b723268$1@aerostar>, "Technical Support" <Tech_Support@SoftwarePartners.com> writes:zL > I don't mean to spam one of my favorite news groups.  I just thought thereN > might be some TAPESYS users out there who would be interested in V6.0.  I amL > particularly proud of the new communications transports that are supportedM > such as icc and tcpip.  The database has been revamped and made more objectAM > oriented.  Lots of other nice stuff as well, including a simplified installeJ > and automated backup load balancing across drives.  The next phase is to > implement a web gui. >      > ' > New features in TAPESYS V6.0 include:o >    [feature list deleted]  I Dave forgot to mention the parallel backups feature in the detailed list,rH though it is referenced in the overview paragraph (load balancing acrossL drives).  In tapesys 5.x, the system manager was required to do his own loadN balancing.  For instance, if you had x disks to back up and y tape drives, youO had to split the disks up into several .sbk files, one for each tape drive, and L assign the disks so that the amount of data to back up was roughly equal for all of the drives.  J With parallel backups, you can put *all* of the disks in one .sbk file andK specify how many drives are to be used to work them off.  sysbak will clone.N copies of itself, one for each tape drive, and will dynamically assign backupsO of individual disks to the clones.  As each clone finishes its assigned backup,sK it asks for another assignment from the master sysbak.  All drives are kepteI fully busy until there are no more backups left to do.  The master sysbakt9 terminates after all clones have completed their backups.V   Waynes -- IO ===============================================================================hM Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxo: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)pO ===============================================================================lH Randolph Duke (in Trading Places): "Mother always said you were greedy.". Mortimer Duke: "She meant it as a compliment!"   ------------------------------  % Date: Sun, 12 Aug 2001 10:34:45 +0200o From: vice2012@hotmail.com Subject: what a what  45461 Message-ID: <9l5f35$43s$04$417@news.t-online.com>h   nothing hereb leudnfuxtuoiyknjgrnfkieonhpovwqkwmwsxkieoudvrhnlndhlblbkqbdyduokojlfyvhiuvxxxyjjqghgfdjeijcdgkuqsb   ------------------------------   End of INFO-VAX 2001.446 ************************ 2 9284-3063 Fax:   +61 2 9284-3050& Email: paddy.o'brien@zzz.tg.nsw.gov.au  M Either "\'" or "\s" (to escape the apostrophe) seems to work for most people, ; but that little whizz-bang apostrophe gives me little spam.    ------------------------------  % Date: Sun, 12 Aug 2001 12:37:48 +0100 2 From