1 INFO-VAX	Sun, 01 Oct 2006	Volume 2006 : Issue 538       Contents:  Re: 2006-09 Distrbution CD-ROMS?' Re: A .DIR files vanishes into thin air   Re: BACKUP locks up a directory?  Re: BACKUP locks up a directory?  Re: BACKUP locks up a directory?  Re: BACKUP locks up a directory?  Re: BACKUP locks up a directory?  Re: BACKUP locks up a directory?  Re: BACKUP locks up a directory?  Re: BACKUP locks up a directory?  Re: BACKUP locks up a directory?3 Re: Bugcheck 3C4 Alpha 7.2-2 $audit_event User Mode $ Re: Converting VAX licences to Alpha$ Re: Converting VAX licences to Alpha Re: Graphic options for DS10L  Re: Graphic options for DS10L  Re: hsz40 firmware question  Re: hsz40 firmware question $ Re: Hub vs Switch : SCS, LAT, DECNET  IDE (DQ) devices served to VAX ?$ Re: IDE (DQ) devices served to VAX ?$ Re: IDE (DQ) devices served to VAX ?$ Re: IDE (DQ) devices served to VAX ?5 Re: In the Land of the Blind, the Hoff is truly King! 5 Re: In the Land of the Blind, the Hoff is truly King! 5 Re: In the Land of the Blind, the Hoff is truly King!  Re: Java Error. Re: Mild warning: TCPIP Services UIC/Usernames" Re: Normal temperature for DS10L ?" Re: Normal temperature for DS10L ?7 Re: OpenVMS support contracts for hobbyists: A scenario ? Re: Options for the future of VMS systems after last order date ? Re: Options for the future of VMS systems after last order date   F ----------------------------------------------------------------------    Date: 30 Sep 2006 16:43:33 -0700) From: "DaveG" <david.gudewicz@abbott.com> ) Subject: Re: 2006-09 Distrbution CD-ROMS? C Message-ID: <1159659813.566899.316680@c28g2000cwb.googlegroups.com>    Neil Rieck wrote: L > Question to people with software support contracts. Have you received your > fall kit yet?  >  > Neil Rieck > Kitchener/Waterloo/Cambridge,  > Ontario, Canada.# > http://www3.sympatico.ca/n.rieck/   , We received our 2006 Q3 Alpha kit last week.   Dave...    ------------------------------    Date: 30 Sep 2006 19:10:28 -0700$ From: "AEF" <spamsink2001@yahoo.com>0 Subject: Re: A .DIR files vanishes into thin airB Message-ID: <1159668627.938240.162710@e3g2000cwe.googlegroups.com>   glen herrmannsfeldt wrote: > JF Mezei wrote:  >  > > glen herrmannsfeldt wrote: >  > >>Something like:  >  > >>RENAME X.DIR [-.X] > L > > Neat ! Just like the vacuum cleaner that sucks itself out of existance ! > I > Not completely out, though.  The blocks still count against your quota.  > 	 > -- glen   # Hmmm. More like a black hole then.     AEF    ------------------------------  # Date: Sat, 30 Sep 2006 18:51:24 GMT ( From: Alan Greig <greigaln@netscape.net>) Subject: Re: BACKUP locks up a directory? < Message-ID: <M0zTg.64023$wg.23842@fe1.news.blueyonder.co.uk>  
 AEF wrote: > E > Is this normal BACKUP behavior? The backup takes so long that it is I > difficult to avoid the EOD job. I've done this before several times and F > never had this problem. I assume I am a victim of bad timing. But isH > this normal, that a "hot backup" can lock up directories and/or files?# > Is there a better way to do this?   H IIRC, if you  $ BACKUP/IGNORE=INTERLOCK then BACKUP should not lock any  files as it backs them up.   --  
 Alan Greig   ------------------------------  % Date: Sat, 30 Sep 2006 21:54:31 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> ) Subject: Re: BACKUP locks up a directory? J Message-ID: <paul.sture.nospam-E0F91C.21543130092006@mac.sture.homeip.net>  < In article <M0zTg.64023$wg.23842@fe1.news.blueyonder.co.uk>,*  Alan Greig <greigaln@netscape.net> wrote:   > AEF wrote: > > G > > Is this normal BACKUP behavior? The backup takes so long that it is K > > difficult to avoid the EOD job. I've done this before several times and H > > never had this problem. I assume I am a victim of bad timing. But isJ > > this normal, that a "hot backup" can lock up directories and/or files?% > > Is there a better way to do this?  > J > IIRC, if you  $ BACKUP/IGNORE=INTERLOCK then BACKUP should not lock any  > files as it backs them up.  I I believe you are correct. Unfortunately applying /IGNORE=INTERLOCK to a  H backup which takes a long time may not be appropriate for all the other  files in the backup selection.  . Maybe something like the following would work:  1 Assuming the files concerned are in directory [A]   < 1. Once a file is completed by the application, rename it to9    directory [B] (BACKUP/DELETE may be appropriate here). ? 2. Modify procedures which send those files to other systems to     use directory [B]8 3. Exclude directories [A] and [B] from the main backup C 4. Do a separate BACKUP/IGNORE=INTERLOCK on directory [B]. You know A    that these files are complete, so inconsistency shouldn't be a     problem.   G And as always, test the various permutations of commands to achieve the 
 above. :-)   --  
 Paul Sture   ------------------------------    Date: 30 Sep 2006 14:27:09 -0700$ From: "AEF" <spamsink2001@yahoo.com>) Subject: Re: BACKUP locks up a directory? C Message-ID: <1159651629.377545.121800@m73g2000cwd.googlegroups.com>    Dave Froble wrote: > AEF wrote: > > Richard B. Gilbert wrote:  > >> AEF wrote: M > >>> I was doing an image backup of an 18-GB disk. During this backup one of M > >>> my market servers was running the end-of-day job. At the end of the job K > >>> it copied certain files created the same day to another VAX system. A K > >>> total of 24 files are normally copied. These range in size from a few I > >>> blocks to a couple thousand. Anyway, the first 15 files were copied I > >>> okay but the next 15 failed with the following error (actual sample  > > 7 > > Uh, that should have read "...the next 9 failed..."  > >  > >>> from the log file):  > >>> . > >>> %COPY-E-OPENOUT, error opening NODE16"FTI > >>> password"::FT_STORAGE_DISK:[FT.ARC.EQUITIES]FTOATTRN060929.SEQ;0 as  > >>> output7 > >>> -RMS-E-FLK, file currently locked by another user G > >>> %COPY-W-NOTCOPIED, _NODE2$DKA400:[FT.DAT]FTOATTRN060929.SEQ;1 not  > >>> copied > >>> 8 > >>> I assume that the "other user" was the backup job. > >>>  > >>> The DCL command was  > >>> E > >>> $ COPY/LOG FTDAT:FT*060929*.*;0/EXCLUDE=(FTGVT*.DAT,FTSYS*.DAT) A > >>> NODE16"FT XXXXXXXX"::FT_STORAGE_DISK:[FT.ARC.EQUITIES]*.*;0  > >>> M > >>> So I got 15 success messages, followed by 9 error messages like the one - > >>> above, followed by the summary message.  > >>> K > >>> I aborted the backup job at this point and re-ran the EOD job. It ran I > >>> fine and copied all 24 files successfully. I looked at the tape and I > >>> sure enough, the backup job had just started copying files from the " > >>> [FT.ARC.EQUITIES] directory. > >>> I > >>> Some more possibly relevant information: NODE2 is running VMS v6.1. J > >>> NODE16 is running VMS v6.2. The directory [FT.ARC.EQUITIES] containsF > >>> about 24000 files. The EQUITIES.DIR file is 2751 blocks in size. > >>> L > >>> NODE2 is a MicroVAX 3100 Model 95. NODE16 is a MicroVAX 3100 Model 80. > >>> I > >>> Is this normal BACKUP behavior? The backup takes so long that it is M > >>> difficult to avoid the EOD job. I've done this before several times and J > >>> never had this problem. I assume I am a victim of bad timing. But isL > >>> this normal, that a "hot backup" can lock up directories and/or files?' > >>> Is there a better way to do this?  > >>> 
 > >>> Thanks.  > >>> 	 > >>> AEF  > >>> M > >> With a directory 2751 blocks in size, it's no wonder things are a little L > >> slow!  Later versions of VMS are not quite so sensitive but at VMS V6.2L > >> any file added to or deleted from an oversize directory could create anD > >> incredible amount of overhead.  Directory entries are stored inH > >> alphanumeric order.  When an entry is inserted in or deleted from aM > >> directory, blocks get shuffled up or down to make room or reclaim space. D > >> It's no big deal if you keep your directories under 100 blocks. > >>E > >> If you really need to have all 24,000 files on line, I'd suggest M > >> spreading them over a LOT more directories.  Maybe a directory for 2006, I > >> one for 2005, 2004, . . . or a directory for each month or whatever.  > > # > > Thanks for your quick response.  > > ' > > Performance is not really an issue.  > J > You indicate that the BACKUP performance is an issue.  Your statement is > wrong.  D Well, it is and it isn't. I have A LOT OF TROUBLE with these blasted@ TLZ tape drives. (I'm the one who wrote "I Lost It with the TapeD Drive".) Currently, I'm happy if I just end up with tapes that I canE read back later. Sure, I'd like it to go faster, but that's the least F of my problems. In fact, I switched from DDS-2 tapes to DDS-1 tapes onB the hope that it would it would greatly increase the likelihood ofA making tapes that are readable when I need them later. Until this F episode, it seemed to be working, which is ANOTHER problem I'm having.C The stupid drive is having trouble verifying the tape it just made! C Arrrggh. The problem here is that the backup somehow screwed up the G file-copy operation requiring me to rerun the EOD job (which because of G other screwy stuff forces me to manually run and adjust the report job, F but never mind that now) and I'd just like to understand better what's	 going on.   ' > > The files normally copy over rather G > > quickly even though the directory is so huge. I suspect that BACKUP F > > started reading the .DIR file in the middle of the copy operation.I > > Could it be that the copying instigated a .DIR-file expansion and the H > > shuffling of the directory data screwed up the copy? Or does it haveG > > something to do with BACKUP? (If I needed to delete selected files, - > > that would certainly go rather slowly!!!)  > > F > > Actually, I suppose the backup would run faster if I combined eachJ > > day's files into BACKUP save sets. I actually do that before I archiveE > > them to CD's, but I prefer to have the individual files available I > > online, at least for stuff this year (I need the current year's files . > > in order to run occasional usage reports). > > J > > Re spreading files over more directories -- I guess that would greatlyJ > > reduce the odds of this problem happenning again. But it would be more > > work than it's worth.  > J > No, it's not.  If you have any method of identifying files by time, thenG > the work is rather trivial.  Retrival may also require some work, but    Retrival? What is that?   J > defining a logical with a list of values handles that.  A directory thatF > large is obscene even on VMS V7.2 and later.  On V6.2 it's very muchI > worse.  You've been given excellent advice and you've decided to ignore  > it.  Why did you ask?   E Still pissed off at me, huh, aren't you Dave? Anyway, I didn't ignore # the answer, I just commented on it.   F Anyway**2, it's not worth the trouble because I've been doing this forE the last 5 years or so and have only once had this problem. It is far E easier to rerun and end-of-day once every 5 years than to rewrite the E EOD code to deal with a new-fangled directory structure and QA it and E get management approval and install it and debug it. I'd also have to F rewrite some other code that moves each day's files into a single save; set for transference to a CD-R. I'd also have to rewrite my D usage-report command procedures. OK, that wouldn't be too hard given logical names.  D Yes, the directories are rather large. But it's not really a problemG because I am the only one who ever uses these files. If I had to delete A them, there are several tricks available to speed it up. WIldcard E lookups are a bit slow, but I can do other things while they run. Why E do I even have these file online? I was told that they should be made C available just in case someone needed them for auditing purposes or E checking something or whatever. Guess how many times that's happened? D ZERO! And that covers at least 5 years. I'm also supposed to archiveG them all to CD's, but that's a real pain, and I've read that CD-R's may D not last more than a few years. Taping is far easier except that the5 TLZ tape drives make write-probably/read-maybe tapes!   A Your comments may be applicalbe in other situations, but I really & didn't want to go into so much deatil.  F Why did I ask? I didn't ask the question whose answer you speak about.A I asked if BACKUP locking up a directory is normal behavior or if  something else is happening. 7   >  > > Thanks for your input. > >  > > AEF  > >  >  >  > --6 > David Froble                       Tel: 724-529-0450@ > Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com > DFE Ultralights, Inc.  > 170 Grimplin Road  > Vanderbilt, PA  15486    Lighten up, dude.    AEF    ------------------------------    Date: 30 Sep 2006 14:28:26 -0700$ From: "AEF" <spamsink2001@yahoo.com>) Subject: Re: BACKUP locks up a directory? C Message-ID: <1159651705.928903.173470@b28g2000cwb.googlegroups.com>    Bob Blunt wrote: > AEF wrote:K > > I was doing an image backup of an 18-GB disk. During this backup one of K > > my market servers was running the end-of-day job. At the end of the job I > > it copied certain files created the same day to another VAX system. A I > > total of 24 files are normally copied. These range in size from a few G > > blocks to a couple thousand. Anyway, the first 15 files were copied G > > okay but the next 15 failed with the following error (actual sample  > > from the log file):  > > , > > %COPY-E-OPENOUT, error opening NODE16"FTG > > password"::FT_STORAGE_DISK:[FT.ARC.EQUITIES]FTOATTRN060929.SEQ;0 as 
 > > output5 > > -RMS-E-FLK, file currently locked by another user E > > %COPY-W-NOTCOPIED, _NODE2$DKA400:[FT.DAT]FTOATTRN060929.SEQ;1 not 
 > > copied > > 6 > > I assume that the "other user" was the backup job. > >  > > The DCL command was  > > C > > $ COPY/LOG FTDAT:FT*060929*.*;0/EXCLUDE=(FTGVT*.DAT,FTSYS*.DAT) ? > > NODE16"FT XXXXXXXX"::FT_STORAGE_DISK:[FT.ARC.EQUITIES]*.*;0  > > K > > So I got 15 success messages, followed by 9 error messages like the one + > > above, followed by the summary message.  > > I > > I aborted the backup job at this point and re-ran the EOD job. It ran G > > fine and copied all 24 files successfully. I looked at the tape and G > > sure enough, the backup job had just started copying files from the   > > [FT.ARC.EQUITIES] directory. > > G > > Some more possibly relevant information: NODE2 is running VMS v6.1. H > > NODE16 is running VMS v6.2. The directory [FT.ARC.EQUITIES] containsD > > about 24000 files. The EQUITIES.DIR file is 2751 blocks in size. > > J > > NODE2 is a MicroVAX 3100 Model 95. NODE16 is a MicroVAX 3100 Model 80. > > G > > Is this normal BACKUP behavior? The backup takes so long that it is K > > difficult to avoid the EOD job. I've done this before several times and H > > never had this problem. I assume I am a victim of bad timing. But isJ > > this normal, that a "hot backup" can lock up directories and/or files?% > > Is there a better way to do this?  > >  > > Thanks.  > >  > > AEF  > >  > F > Let me guess...  you've got some permutation of /ignore=interlock inE > that BACKUP command?  I know that the time required to perform disk   B Nope. I did not use /IGNORE=INTERLOCK. I'll post the exact command# later. I don't have time right now.   H > BACKUPs is sometimes restrictive, but this is like the UNHoly Grail ofE > BACKUP...  /ignore=interlock is a "you get what you get" situation. C > Failures due to locked files during BACKUP with /ignore=interlock F > processing CAN HAPPEN, and the best of luck to ya!  I hate to be theJ > harbinger of doom, but *THIS* IS HOW IT WORKS and you're not making your@ > own job easier if you have to recover from a saveset made withJ > /ignore=interlock.  /IMAGE also has it's own set of restrictions and how > it handles file locking. > I > Bottom line?  If you MUST use BACKUP with /ignore=interlock while other G > activity is occurring, you may or may not get a usable, viable set of D > valid data in your saveset.  You might get really lucky and have aI > recoverable dataset.  You might get "half" lucky and have a recoverable H > dataset with partially updated (aka corrupt) data in it.  This is YOURF > decision to make and your problem to uncover and fix.  I've made theH > same choices to satisfy time restrictions and my own limitations, it'sF > the best you can do sometimes, but please understand the exposure... >  > bob    AEF    ------------------------------    Date: 30 Sep 2006 14:33:42 -0700$ From: "AEF" <spamsink2001@yahoo.com>) Subject: Re: BACKUP locks up a directory? C Message-ID: <1159652022.656600.271950@i42g2000cwa.googlegroups.com>   
 AEF wrote: > Dave Froble wrote: > > AEF wrote: > > > Richard B. Gilbert wrote:  > > >> AEF wrote: O > > >>> I was doing an image backup of an 18-GB disk. During this backup one of O > > >>> my market servers was running the end-of-day job. At the end of the job M > > >>> it copied certain files created the same day to another VAX system. A M > > >>> total of 24 files are normally copied. These range in size from a few K > > >>> blocks to a couple thousand. Anyway, the first 15 files were copied K > > >>> okay but the next 15 failed with the following error (actual sample  > > > 9 > > > Uh, that should have read "...the next 9 failed..."  > > >  > > >>> from the log file):  > > >>> 0 > > >>> %COPY-E-OPENOUT, error opening NODE16"FTK > > >>> password"::FT_STORAGE_DISK:[FT.ARC.EQUITIES]FTOATTRN060929.SEQ;0 as  > > >>> output9 > > >>> -RMS-E-FLK, file currently locked by another user I > > >>> %COPY-W-NOTCOPIED, _NODE2$DKA400:[FT.DAT]FTOATTRN060929.SEQ;1 not  > > >>> copied > > >>> : > > >>> I assume that the "other user" was the backup job. > > >>>  > > >>> The DCL command was  > > >>> G > > >>> $ COPY/LOG FTDAT:FT*060929*.*;0/EXCLUDE=(FTGVT*.DAT,FTSYS*.DAT) C > > >>> NODE16"FT XXXXXXXX"::FT_STORAGE_DISK:[FT.ARC.EQUITIES]*.*;0  > > >>> O > > >>> So I got 15 success messages, followed by 9 error messages like the one / > > >>> above, followed by the summary message.  > > >>> M > > >>> I aborted the backup job at this point and re-ran the EOD job. It ran K > > >>> fine and copied all 24 files successfully. I looked at the tape and K > > >>> sure enough, the backup job had just started copying files from the $ > > >>> [FT.ARC.EQUITIES] directory. > > >>> K > > >>> Some more possibly relevant information: NODE2 is running VMS v6.1. L > > >>> NODE16 is running VMS v6.2. The directory [FT.ARC.EQUITIES] containsH > > >>> about 24000 files. The EQUITIES.DIR file is 2751 blocks in size. > > >>> N > > >>> NODE2 is a MicroVAX 3100 Model 95. NODE16 is a MicroVAX 3100 Model 80. > > >>> K > > >>> Is this normal BACKUP behavior? The backup takes so long that it is O > > >>> difficult to avoid the EOD job. I've done this before several times and L > > >>> never had this problem. I assume I am a victim of bad timing. But isN > > >>> this normal, that a "hot backup" can lock up directories and/or files?) > > >>> Is there a better way to do this?  > > >>>  > > >>> Thanks.  > > >>>  > > >>> AEF  > > >>> O > > >> With a directory 2751 blocks in size, it's no wonder things are a little N > > >> slow!  Later versions of VMS are not quite so sensitive but at VMS V6.2N > > >> any file added to or deleted from an oversize directory could create anF > > >> incredible amount of overhead.  Directory entries are stored inJ > > >> alphanumeric order.  When an entry is inserted in or deleted from aO > > >> directory, blocks get shuffled up or down to make room or reclaim space. F > > >> It's no big deal if you keep your directories under 100 blocks. > > >>G > > >> If you really need to have all 24,000 files on line, I'd suggest O > > >> spreading them over a LOT more directories.  Maybe a directory for 2006, K > > >> one for 2005, 2004, . . . or a directory for each month or whatever.  > > > % > > > Thanks for your quick response.  > > > ) > > > Performance is not really an issue.  > > L > > You indicate that the BACKUP performance is an issue.  Your statement is
 > > wrong. > F > Well, it is and it isn't. I have A LOT OF TROUBLE with these blastedB > TLZ tape drives. (I'm the one who wrote "I Lost It with the TapeF > Drive".) Currently, I'm happy if I just end up with tapes that I canG > read back later. Sure, I'd like it to go faster, but that's the least H > of my problems. In fact, I switched from DDS-2 tapes to DDS-1 tapes onD > the hope that it would it would greatly increase the likelihood ofC > making tapes that are readable when I need them later. Until this H > episode, it seemed to be working, which is ANOTHER problem I'm having.E > The stupid drive is having trouble verifying the tape it just made! E > Arrrggh. The problem here is that the backup somehow screwed up the I > file-copy operation requiring me to rerun the EOD job (which because of I > other screwy stuff forces me to manually run and adjust the report job, H > but never mind that now) and I'd just like to understand better what's > going on.  > ) > > > The files normally copy over rather I > > > quickly even though the directory is so huge. I suspect that BACKUP H > > > started reading the .DIR file in the middle of the copy operation.K > > > Could it be that the copying instigated a .DIR-file expansion and the J > > > shuffling of the directory data screwed up the copy? Or does it haveI > > > something to do with BACKUP? (If I needed to delete selected files, / > > > that would certainly go rather slowly!!!)  > > > H > > > Actually, I suppose the backup would run faster if I combined eachL > > > day's files into BACKUP save sets. I actually do that before I archiveG > > > them to CD's, but I prefer to have the individual files available K > > > online, at least for stuff this year (I need the current year's files 0 > > > in order to run occasional usage reports). > > > L > > > Re spreading files over more directories -- I guess that would greatlyL > > > reduce the odds of this problem happenning again. But it would be more > > > work than it's worth.  > > L > > No, it's not.  If you have any method of identifying files by time, thenI > > the work is rather trivial.  Retrival may also require some work, but  >  > Retrival? What is that?  > L > > defining a logical with a list of values handles that.  A directory thatH > > large is obscene even on VMS V7.2 and later.  On V6.2 it's very muchK > > worse.  You've been given excellent advice and you've decided to ignore  > > it.  Why did you ask?  > G > Still pissed off at me, huh, aren't you Dave? Anyway, I didn't ignore % > the answer, I just commented on it.  > H > Anyway**2, it's not worth the trouble because I've been doing this forG > the last 5 years or so and have only once had this problem. It is far G > easier to rerun and end-of-day once every 5 years than to rewrite the G > EOD code to deal with a new-fangled directory structure and QA it and G > get management approval and install it and debug it. I'd also have to H > rewrite some other code that moves each day's files into a single save= > set for transference to a CD-R. I'd also have to rewrite my F > usage-report command procedures. OK, that wouldn't be too hard given > logical names.  G On second thought, it is only over the last year or so that I've had to D do 3-tape backups because of using DDS-1 instead of DDS-2. Before, IF could get the backup done starting Friday evening, after the last EOD,C and continue it with tape 2 on Monday morning, but I think it still G overlapped at least one EOD. I'm not really sure. But this is the first ' time I've EVER had a problem like this.    [...]    AEF    ------------------------------  % Date: Sat, 30 Sep 2006 21:20:34 -0400 ' From: Dave Froble <davef@tsoft-inc.com> ) Subject: Re: BACKUP locks up a directory? 9 Message-ID: <tsudnUvG2ptDiILYnZ2dnUVZ_r-dnZ2d@libcom.com>   
 AEF wrote: > Dave Froble wrote:
 >> AEF wrote:  >>> Richard B. Gilbert wrote:  >>>> AEF wrote: M >>>>> I was doing an image backup of an 18-GB disk. During this backup one of M >>>>> my market servers was running the end-of-day job. At the end of the job K >>>>> it copied certain files created the same day to another VAX system. A K >>>>> total of 24 files are normally copied. These range in size from a few I >>>>> blocks to a couple thousand. Anyway, the first 15 files were copied I >>>>> okay but the next 15 failed with the following error (actual sample 7 >>> Uh, that should have read "...the next 9 failed..."  >>>  >>>>> from the log file):  >>>>> . >>>>> %COPY-E-OPENOUT, error opening NODE16"FTI >>>>> password"::FT_STORAGE_DISK:[FT.ARC.EQUITIES]FTOATTRN060929.SEQ;0 as  >>>>> output7 >>>>> -RMS-E-FLK, file currently locked by another user G >>>>> %COPY-W-NOTCOPIED, _NODE2$DKA400:[FT.DAT]FTOATTRN060929.SEQ;1 not  >>>>> copied >>>>> 8 >>>>> I assume that the "other user" was the backup job. >>>>>  >>>>> The DCL command was  >>>>> E >>>>> $ COPY/LOG FTDAT:FT*060929*.*;0/EXCLUDE=(FTGVT*.DAT,FTSYS*.DAT) A >>>>> NODE16"FT XXXXXXXX"::FT_STORAGE_DISK:[FT.ARC.EQUITIES]*.*;0  >>>>> M >>>>> So I got 15 success messages, followed by 9 error messages like the one - >>>>> above, followed by the summary message.  >>>>> K >>>>> I aborted the backup job at this point and re-ran the EOD job. It ran I >>>>> fine and copied all 24 files successfully. I looked at the tape and I >>>>> sure enough, the backup job had just started copying files from the " >>>>> [FT.ARC.EQUITIES] directory. >>>>> I >>>>> Some more possibly relevant information: NODE2 is running VMS v6.1. J >>>>> NODE16 is running VMS v6.2. The directory [FT.ARC.EQUITIES] containsF >>>>> about 24000 files. The EQUITIES.DIR file is 2751 blocks in size. >>>>> L >>>>> NODE2 is a MicroVAX 3100 Model 95. NODE16 is a MicroVAX 3100 Model 80. >>>>> I >>>>> Is this normal BACKUP behavior? The backup takes so long that it is M >>>>> difficult to avoid the EOD job. I've done this before several times and J >>>>> never had this problem. I assume I am a victim of bad timing. But isL >>>>> this normal, that a "hot backup" can lock up directories and/or files?' >>>>> Is there a better way to do this?  >>>>> 
 >>>>> Thanks.  >>>>> 	 >>>>> AEF  >>>>> M >>>> With a directory 2751 blocks in size, it's no wonder things are a little L >>>> slow!  Later versions of VMS are not quite so sensitive but at VMS V6.2L >>>> any file added to or deleted from an oversize directory could create anD >>>> incredible amount of overhead.  Directory entries are stored inH >>>> alphanumeric order.  When an entry is inserted in or deleted from aM >>>> directory, blocks get shuffled up or down to make room or reclaim space. D >>>> It's no big deal if you keep your directories under 100 blocks. >>>>E >>>> If you really need to have all 24,000 files on line, I'd suggest M >>>> spreading them over a LOT more directories.  Maybe a directory for 2006, I >>>> one for 2005, 2004, . . . or a directory for each month or whatever. # >>> Thanks for your quick response.  >>> ' >>> Performance is not really an issue. K >> You indicate that the BACKUP performance is an issue.  Your statement is 	 >> wrong.  > F > Well, it is and it isn't. I have A LOT OF TROUBLE with these blastedB > TLZ tape drives. (I'm the one who wrote "I Lost It with the TapeF > Drive".) Currently, I'm happy if I just end up with tapes that I canG > read back later. Sure, I'd like it to go faster, but that's the least H > of my problems. In fact, I switched from DDS-2 tapes to DDS-1 tapes onD > the hope that it would it would greatly increase the likelihood ofC > making tapes that are readable when I need them later. Until this H > episode, it seemed to be working, which is ANOTHER problem I'm having.E > The stupid drive is having trouble verifying the tape it just made! E > Arrrggh. The problem here is that the backup somehow screwed up the I > file-copy operation requiring me to rerun the EOD job (which because of I > other screwy stuff forces me to manually run and adjust the report job, H > but never mind that now) and I'd just like to understand better what's > going on.   H 4 MM DAT was a crap shoot since the day it first came out.  That's just F the way things are.  There have been many posts in the past, with the I usual recommendation to pick up a DLT drive.  DLT4 and subsequent models  F store significant data, and suffer many more passes than 4 MM DAT.  I : understand new tapes for the older drives can be an issue.  ' >>> The files normally copy over rather G >>> quickly even though the directory is so huge. I suspect that BACKUP F >>> started reading the .DIR file in the middle of the copy operation.I >>> Could it be that the copying instigated a .DIR-file expansion and the H >>> shuffling of the directory data screwed up the copy? Or does it haveG >>> something to do with BACKUP? (If I needed to delete selected files, - >>> that would certainly go rather slowly!!!)  >>> F >>> Actually, I suppose the backup would run faster if I combined eachJ >>> day's files into BACKUP save sets. I actually do that before I archiveE >>> them to CD's, but I prefer to have the individual files available I >>> online, at least for stuff this year (I need the current year's files . >>> in order to run occasional usage reports). >>> J >>> Re spreading files over more directories -- I guess that would greatlyJ >>> reduce the odds of this problem happenning again. But it would be more >>> work than it's worth. K >> No, it's not.  If you have any method of identifying files by time, then H >> the work is rather trivial.  Retrival may also require some work, but >  > Retrival? What is that?  > K >> defining a logical with a list of values handles that.  A directory that G >> large is obscene even on VMS V7.2 and later.  On V6.2 it's very much J >> worse.  You've been given excellent advice and you've decided to ignore >> it.  Why did you ask? > G > Still pissed off at me, huh, aren't you Dave? Anyway, I didn't ignore % > the answer, I just commented on it.   	 ?????????   H When was I ever upset with you.  I know I'm getting old, crotchety, and I senile, but the only person I remember that caused frothing at the mouth  * was JF, and now I don't let him bother me.  G Large directories on V6.2 are a greater problem than just what you see  E on the surface.  It's not just deletions that cause problems, though   those are rather visable.   H > Anyway**2, it's not worth the trouble because I've been doing this forG > the last 5 years or so and have only once had this problem. It is far G > easier to rerun and end-of-day once every 5 years than to rewrite the G > EOD code to deal with a new-fangled directory structure and QA it and G > get management approval and install it and debug it. I'd also have to H > rewrite some other code that moves each day's files into a single save= > set for transference to a CD-R. I'd also have to rewrite my F > usage-report command procedures. OK, that wouldn't be too hard given > logical names. > F > Yes, the directories are rather large. But it's not really a problemI > because I am the only one who ever uses these files. If I had to delete C > them, there are several tricks available to speed it up. WIldcard G > lookups are a bit slow, but I can do other things while they run. Why G > do I even have these file online? I was told that they should be made E > available just in case someone needed them for auditing purposes or G > checking something or whatever. Guess how many times that's happened? F > ZERO! And that covers at least 5 years. I'm also supposed to archiveI > them all to CD's, but that's a real pain, and I've read that CD-R's may F > not last more than a few years. Taping is far easier except that the7 > TLZ tape drives make write-probably/read-maybe tapes!  > C > Your comments may be applicalbe in other situations, but I really ( > didn't want to go into so much deatil. > H > Why did I ask? I didn't ask the question whose answer you speak about.C > I asked if BACKUP locking up a directory is normal behavior or if   > something else is happening. 7  H I'd be real surprised if BACKUP locked a directory, unless you used the H /RECORD switch (I think that's the one that sets the last backup date). F   It's mainly a read only operation.  However, if it was reading, and H another process wanted exclusive access, that might be an issue.  Don't 2 know enough about the details to be more specific.  H Not picking on anyone, just emphasizing that very large directory files  are a serious problem.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------    Date: 30 Sep 2006 19:02:22 -0700$ From: "AEF" <spamsink2001@yahoo.com>) Subject: Re: BACKUP locks up a directory? B Message-ID: <1159668142.623593.41230@m73g2000cwd.googlegroups.com>   Dave Froble wrote: > AEF wrote: > > Dave Froble wrote: > >> AEF wrote:  > >>> Richard B. Gilbert wrote:  > >>>> AEF wrote:  [...] G > >>>> If you really need to have all 24,000 files on line, I'd suggest O > >>>> spreading them over a LOT more directories.  Maybe a directory for 2006, K > >>>> one for 2005, 2004, . . . or a directory for each month or whatever. % > >>> Thanks for your quick response.  > >>> ) > >>> Performance is not really an issue. M > >> You indicate that the BACKUP performance is an issue.  Your statement is  > >> wrong.  > > H > > Well, it is and it isn't. I have A LOT OF TROUBLE with these blastedD > > TLZ tape drives. (I'm the one who wrote "I Lost It with the TapeH > > Drive".) Currently, I'm happy if I just end up with tapes that I canI > > read back later. Sure, I'd like it to go faster, but that's the least J > > of my problems. In fact, I switched from DDS-2 tapes to DDS-1 tapes onF > > the hope that it would it would greatly increase the likelihood ofE > > making tapes that are readable when I need them later. Until this J > > episode, it seemed to be working, which is ANOTHER problem I'm having.G > > The stupid drive is having trouble verifying the tape it just made! G > > Arrrggh. The problem here is that the backup somehow screwed up the K > > file-copy operation requiring me to rerun the EOD job (which because of K > > other screwy stuff forces me to manually run and adjust the report job, J > > but never mind that now) and I'd just like to understand better what's
 > > going on.  > I > 4 MM DAT was a crap shoot since the day it first came out.  That's just G > the way things are.  There have been many posts in the past, with the J > usual recommendation to pick up a DLT drive.  DLT4 and subsequent modelsG > store significant data, and suffer many more passes than 4 MM DAT.  I < > understand new tapes for the older drives can be an issue.  A I wish I could get DLT drives, but my VAX systems and the trading F system that runs on them is to be phased out. :-( I'm not going to getD the funds to get DLT drives. One thing, perhaps, that could save theB day is to NetBackup to our existing DLT drives. If things continue- going sour, I think I'll explore that option.   E Are you saying getting DDS-1 tapes is problematic? Well, our supplier E had to back-order my favorite brand recently. And if the DDS-1 format G were discontinued, our Stratus would also be in trouble. Its drive uses E ONLY DDS-1. My company wants to phase that out, too, but we have many  desks using it currently.    > ) > >>> The files normally copy over rather I > >>> quickly even though the directory is so huge. I suspect that BACKUP H > >>> started reading the .DIR file in the middle of the copy operation.K > >>> Could it be that the copying instigated a .DIR-file expansion and the J > >>> shuffling of the directory data screwed up the copy? Or does it haveI > >>> something to do with BACKUP? (If I needed to delete selected files, / > >>> that would certainly go rather slowly!!!)  > >>> H > >>> Actually, I suppose the backup would run faster if I combined eachL > >>> day's files into BACKUP save sets. I actually do that before I archiveG > >>> them to CD's, but I prefer to have the individual files available K > >>> online, at least for stuff this year (I need the current year's files 0 > >>> in order to run occasional usage reports). > >>> L > >>> Re spreading files over more directories -- I guess that would greatlyL > >>> reduce the odds of this problem happenning again. But it would be more > >>> work than it's worth. M > >> No, it's not.  If you have any method of identifying files by time, then J > >> the work is rather trivial.  Retrival may also require some work, but > >  > > Retrival? What is that?  > > M > >> defining a logical with a list of values handles that.  A directory that I > >> large is obscene even on VMS V7.2 and later.  On V6.2 it's very much L > >> worse.  You've been given excellent advice and you've decided to ignore > >> it.  Why did you ask? > > I > > Still pissed off at me, huh, aren't you Dave? Anyway, I didn't ignore ' > > the answer, I just commented on it.  >  > ?????????  > I > When was I ever upset with you.  I know I'm getting old, crotchety, and J > senile, but the only person I remember that caused frothing at the mouth, > was JF, and now I don't let him bother me.  D Maybe I'm thinking of someone else. Maybe I'm thinking about anotherD Dave. Maybe it was the way you wrote about my "ignoring a solution". Sorry.   > H > Large directories on V6.2 are a greater problem than just what you seeF > on the surface.  It's not just deletions that cause problems, though > those are rather visable.   F Well, if this problem becomes a recurring one or if I get to, somehow,9 understand better what's going on, then I'll consider the E multiple-directory solution. But with a 2751-block directory, getting @ it down to 128 blocks or less per new directory would require 22> directories! To keep things simple, I'd have to have dedicatedE directory for each month's worth of data. With more than three years' E worth of data for two markets, that's going to be 72 directories just 4 for 2003 - 2005! That will take a while to set up!!!  G One think I'd prefer to do, perhaps, is to put each month's data into a F save set and extract any currently needed files to a scratch area. I'mE doing that now on an as needed basis (as needed to keep the disk from G filling up!) when I archive them. The files consist of data files and a C save set contiaining log files, so for each month (for each desk) I @ copy an archive save set and the log-files save set to the CD's.   > J > > Anyway**2, it's not worth the trouble because I've been doing this forI > > the last 5 years or so and have only once had this problem. It is far I > > easier to rerun and end-of-day once every 5 years than to rewrite the I > > EOD code to deal with a new-fangled directory structure and QA it and I > > get management approval and install it and debug it. I'd also have to J > > rewrite some other code that moves each day's files into a single save? > > set for transference to a CD-R. I'd also have to rewrite my H > > usage-report command procedures. OK, that wouldn't be too hard given > > logical names. > > H > > Yes, the directories are rather large. But it's not really a problemK > > because I am the only one who ever uses these files. If I had to delete E > > them, there are several tricks available to speed it up. WIldcard I > > lookups are a bit slow, but I can do other things while they run. Why I > > do I even have these file online? I was told that they should be made G > > available just in case someone needed them for auditing purposes or I > > checking something or whatever. Guess how many times that's happened? H > > ZERO! And that covers at least 5 years. I'm also supposed to archiveK > > them all to CD's, but that's a real pain, and I've read that CD-R's may H > > not last more than a few years. Taping is far easier except that the9 > > TLZ tape drives make write-probably/read-maybe tapes!  > > E > > Your comments may be applicalbe in other situations, but I really * > > didn't want to go into so much deatil. > > J > > Why did I ask? I didn't ask the question whose answer you speak about.E > > I asked if BACKUP locking up a directory is normal behavior or if " > > something else is happening. 7 > I > I'd be real surprised if BACKUP locked a directory, unless you used the I > /RECORD switch (I think that's the one that sets the last backup date).   D Yes, I used /RECORD. Why would that lock the directory? I think thatB isn't the case because of the order in which the recording pass isG done. It goes in (perhaps approximately) reverse backup order, which is D not a directory at a time but a continual traversing up and down theB levels of subdirectory-space (or directory-tree) space. (Look at aB BACKUP save set listing to see the order.) But even if it is, this' problem happened during the save phase.   G >   It's mainly a read only operation.  However, if it was reading, and I > another process wanted exclusive access, that might be an issue.  Don't 4 > know enough about the details to be more specific.  / Well, maybe next week someone can tell us more.    > I > Not picking on anyone, just emphasizing that very large directory files  > are a serious problem.  9 OK. Thanks for your help. All friendly advice is welcome.    >  > --6 > David Froble                       Tel: 724-529-0450@ > Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com > DFE Ultralights, Inc.  > 170 Grimplin Road  > Vanderbilt, PA  15486    AEF    ------------------------------    Date: 30 Sep 2006 23:05:34 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) ) Subject: Re: BACKUP locks up a directory? 3 Message-ID: <MMGNHPT3nwGw@eisner.encompasserve.org>   g In article <M0zTg.64023$wg.23842@fe1.news.blueyonder.co.uk>, Alan Greig <greigaln@netscape.net> writes:  > AEF wrote: >>F >> Is this normal BACKUP behavior? The backup takes so long that it isJ >> difficult to avoid the EOD job. I've done this before several times andG >> never had this problem. I assume I am a victim of bad timing. But is I >> this normal, that a "hot backup" can lock up directories and/or files? $ >> Is there a better way to do this? > J > IIRC, if you  $ BACKUP/IGNORE=INTERLOCK then BACKUP should not lock any  > files as it backs them up.  D Whereas my recollection is that, at least at some point in the past,C /IGNORE=INTERLOCK did not affect how BACKUP tried to access a file, D it just caused BACKUP to try a less contentious mode if the file wasA already opened by another application.  If BACKUP got to the file 1 first, the other application might have problems.    ------------------------------    Date: 30 Sep 2006 21:24:34 -0700$ From: "AEF" <spamsink2001@yahoo.com>) Subject: Re: BACKUP locks up a directory? C Message-ID: <1159676674.932997.140160@m73g2000cwd.googlegroups.com>    Bob Blunt wrote: > AEF wrote:K > > I was doing an image backup of an 18-GB disk. During this backup one of K > > my market servers was running the end-of-day job. At the end of the job I > > it copied certain files created the same day to another VAX system. A I > > total of 24 files are normally copied. These range in size from a few G > > blocks to a couple thousand. Anyway, the first 15 files were copied G > > okay but the next 15 failed with the following error (actual sample  > > from the log file):  > > , > > %COPY-E-OPENOUT, error opening NODE16"FTG > > password"::FT_STORAGE_DISK:[FT.ARC.EQUITIES]FTOATTRN060929.SEQ;0 as 
 > > output5 > > -RMS-E-FLK, file currently locked by another user E > > %COPY-W-NOTCOPIED, _NODE2$DKA400:[FT.DAT]FTOATTRN060929.SEQ;1 not 
 > > copied > > 6 > > I assume that the "other user" was the backup job. > >  > > The DCL command was  > > C > > $ COPY/LOG FTDAT:FT*060929*.*;0/EXCLUDE=(FTGVT*.DAT,FTSYS*.DAT) ? > > NODE16"FT XXXXXXXX"::FT_STORAGE_DISK:[FT.ARC.EQUITIES]*.*;0  > > K > > So I got 15 success messages, followed by 9 error messages like the one + > > above, followed by the summary message.  > > I > > I aborted the backup job at this point and re-ran the EOD job. It ran G > > fine and copied all 24 files successfully. I looked at the tape and G > > sure enough, the backup job had just started copying files from the   > > [FT.ARC.EQUITIES] directory. > > G > > Some more possibly relevant information: NODE2 is running VMS v6.1. H > > NODE16 is running VMS v6.2. The directory [FT.ARC.EQUITIES] containsD > > about 24000 files. The EQUITIES.DIR file is 2751 blocks in size. > > J > > NODE2 is a MicroVAX 3100 Model 95. NODE16 is a MicroVAX 3100 Model 80. > > G > > Is this normal BACKUP behavior? The backup takes so long that it is K > > difficult to avoid the EOD job. I've done this before several times and H > > never had this problem. I assume I am a victim of bad timing. But isJ > > this normal, that a "hot backup" can lock up directories and/or files?% > > Is there a better way to do this?  > >  > > Thanks.  > >  > > AEF  > >  > F > Let me guess...  you've got some permutation of /ignore=interlock inE > that BACKUP command?  I know that the time required to perform disk   ; Nope. Here's the BACKUP command I used (from the log file):    $ L BACK/IMAGE/NOALIAS/VERIFY/RECORD/LIST=SYS$SYSDEVICE:[FELDMAN]STOR-060929.LIS - 6          /JOURNAL=SYS$SYSDEVICE:[FELDMAN]STOR-060929 -          DISK$STORAGE: -  J TAPE_DRIVE:STOR-060929.IMG/LABEL=(STOR50,STOR51,STOR52,STOR53)/EXACT_ORDER - 2          /BLOCK=32256/COMM="Full backup of STORAGE' disk"/MEDIA=COMPACTION/REWIND/GROUP=100 - %JBC-F-JOBABORT, job aborted during execution   D Note that the problem occurred during the save portion of the BACKUP? operation. The BACKUP list file had the first 78 files from the E [FT.ARC.EQUITIES] directory listed. I also listed the tape itself and  it gave the same result.   AEF    ------------------------------  $ Date: Sun, 1 Oct 2006 07:22:11 +08003 From: "Richard Maher" <maher_rj@hotspamnotmail.com> < Subject: Re: Bugcheck 3C4 Alpha 7.2-2 $audit_event User Mode1 Message-ID: <efmu0j$3os$1@news-02.connect.com.au>    Hi Richard,   K > Most of this discussion has been way above my head but surely a condition  codeI > of C is exactly an ACCVIO? And an address of 8610D500 distinctly dodgy.   J Looks like you're right and I was wrong. If you have any ideas on why thatJ address is dodgy (and how nsa$validate_table gets mapped near it sometimesK and others not) then I'd also like to hear 'em.  I had thought that reading K memory at Kernel Mode and IPL 0 was pretty unflappable (But clearly not :-)   L I had a quick loook at on of those memory layout diagrams in the Programming; Concepts Manual and it says that, on a VAX that location is G unreachable/invalid but on a Alpha is in P2 space (or maybe shared page L tables) so why does it ACCVIO? Sign-extension stuff? Choice of ones or zeros in the other longword?  J As a read only Psect why doesn't nsa$validate_table get loaded into System
 Space anyway?    Whatsagohon?   Cheers Richard Maher  5 "Richard Brodie" <R.Brodie@rl.ac.uk> wrote in message & news:eebpsk$h52$1@south.jnrs.ja.net... > @ > "Richard Maher" <maher_rj@hotspamnotmail.com> wrote in message- > news:eebl6c$k0r$1@news-02.connect.com.au...  > < > > I think not in this case, but let us move on. A BUGCHECK SSRVEXCEEPT,FATAL L > > is surely a programmatically triggered logic trap? It's not an ACCVIO or > > dodgy address  > K > Most of this discussion has been way above my head but surely a condition  codeI > of C is exactly an ACCVIO? And an address of 8610D500 distinctly dodgy.  > A > > Signal Array:                            64-bit Signal Array: = > > Arg Count    = 00000005                  Arg Count      =  00000005= > > Condition    = 0000000C                  Condition      =  00000000.0000000C = > > Argument #2  = 00000000                  Argument #2    =  00000000.00000000 = > > Argument #3  = 8610D500                  Argument #3    =  FFFFFFFF.8610D500 = > > Argument #4  = 801C0758                  Argument #4    =  FFFFFFFF.801C0758  >  >    ------------------------------  % Date: Sat, 30 Sep 2006 21:09:21 -0400 * From: "YourNameGoesHere" <someone@foo.com>- Subject: Re: Converting VAX licences to Alpha - Message-ID: <bzETg.1330$K15.425@newsfe04.lga>   5 "Neil Rieck" <n.rieck@sympatico.ca> wrote in message  5 news:451e5ab6$0$5683$9a6e19ea@news.newshosting.com...    <snip>  L > To the best of my knowledge, there is no way to convert a license from VAX > to Alpha.    <snip>  L VAX layered product software licenses can still be transfered to Alphas for G a fee based on processor from-to model.   I worked on a transfer for a  D commercial customer a couple of weeks ago that was a simple process.   From: Q http://licensing.hp.com/swl/view.slm;jsessionid=aaaQ6qZUeD27hxbUlNZ?page=contacts         In the U. S. please contact:         John Sant-Angelo       Telephone: 516-628-0320 $       Email: John.Sant-Angelo@hp.com       In Canada please contact:          Brenda Daoust        Telephone: 905-948-3300 !       Email: brenda.daoust@hp.com   = The same URL also says that general questions can be sent to   softwarelicensing@hp.com     ------------------------------  % Date: Sat, 30 Sep 2006 22:53:52 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> - Subject: Re: Converting VAX licences to Alpha , Message-ID: <451F2DC0.A0A26B15@teksavvy.com>   YourNameGoesHere wrote:  > From: S > http://licensing.hp.com/swl/view.slm;jsessionid=aaaQ6qZUeD27hxbUlNZ?page=contacts  >  >       Brenda Daoust  >       Telephone: 905-948-3300 # >       Email: brenda.daoust@hp.com  > > > The same URL also says that general questions can be sent to > softwarelicensing@hp.com    Many thanks for the information.   ------------------------------  % Date: Sat, 30 Sep 2006 18:28:48 -0600  From: Kevin Handy <kth@srv.net> & Subject: Re: Graphic options for DS10L2 Message-ID: <1159662587_3817@sp6iad.superfeed.net>   johnhreinhardt@yahoo.com wrote:   A > Another video option that is often overlooked is the ATI Radeon E > 7000/7500.  Since you now have an EV6 class system you can use that I > card also.  I've got one in each of my XP1000's and haven't noticed any H > problems yet.  But it's only been about two months since I swapped outF > the previous cards.  You have to use the PCI version with is getting? > harder to find, but there are several people selling the 7500 H > "All-in-Wonder" version for between $50-$85 US on Ebay.  Some are evenA > new, still sealed in boxes.  The PCI 7000 is a bit more common. H > Performance wise I believe it is comparable to a Powercolor 300/350 inI > 2D graphics, but is somewhat in 3D performance.  This works fine for me E > since I don't do much 3D work.  Mine are just programming/sys admin 
 > systems.  ; I have an ALL-IN-WONDER VE card (7500), and a DS10L running < VMS 7.3, with recent hobbyest licenses. Putting the graphics9 card into the DS10L still gives me a "no graphics devices < found" error on bootup. The card works for text/booting, but+ then so does most any cheaper VGA PCI card.   = Does this card really work with VMS/Graphical mode? Do I need 9 need something else, some configuration magic, or a later  version of VMS?   Q ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- S http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups K ----= East and West-Coast Server Farms - Total Privacy via Encryption =----    ------------------------------    Date: 30 Sep 2006 20:07:05 -0700; From: "johnhreinhardt@yahoo.com" <johnhreinhardt@yahoo.com> & Subject: Re: Graphic options for DS10LB Message-ID: <1159672025.922072.27920@c28g2000cwb.googlegroups.com>   Kevin Handy wrote:! > johnhreinhardt@yahoo.com wrote:  > C > > Another video option that is often overlooked is the ATI Radeon G > > 7000/7500.  Since you now have an EV6 class system you can use that K > > card also.  I've got one in each of my XP1000's and haven't noticed any J > > problems yet.  But it's only been about two months since I swapped outH > > the previous cards.  You have to use the PCI version with is gettingA > > harder to find, but there are several people selling the 7500 J > > "All-in-Wonder" version for between $50-$85 US on Ebay.  Some are evenC > > new, still sealed in boxes.  The PCI 7000 is a bit more common. J > > Performance wise I believe it is comparable to a Powercolor 300/350 inK > > 2D graphics, but is somewhat in 3D performance.  This works fine for me G > > since I don't do much 3D work.  Mine are just programming/sys admin  > > systems. > = > I have an ALL-IN-WONDER VE card (7500), and a DS10L running > > VMS 7.3, with recent hobbyest licenses. Putting the graphics; > card into the DS10L still gives me a "no graphics devices > > found" error on bootup. The card works for text/booting, but- > then so does most any cheaper VGA PCI card.  > ? > Does this card really work with VMS/Graphical mode? Do I need ; > need something else, some configuration magic, or a later  > version of VMS?  >   ; You need to go up one sub-version of VMS.  According to the  installation guide (D http://h18002.www1.hp.com/alphaserver/download/ek_r7500_ig_a01.pdf )G OpenVMS support of the Radeon 7500 begins with V7.3-1.  You just missed  the cutoff.    ------------------------------  % Date: Sat, 30 Sep 2006 13:48:11 -0400 3 From: "Richard B. Gilbert" <rgilbert88@comcast.net> $ Subject: Re: hsz40 firmware question: Message-ID: <2eSdneSd-atDMIPYnZ2dnUVZ_rydnZ2d@comcast.com>   Bob Blunt wrote:   > Jim Mehlhop wrote: > H >> We have 4 hsz40's 2 have a recent version of the firmware and 2 have B >> older versions which do not support 18.2 GB disks.  Is there a E >> documented procedure to copy the firmware from the good hsz's and  $ >> migrate it to the older version?? >> > I > Jim, there's no software or tools on the HSx controller itself to copy  K > the PCMCIA card and migrate the firmware around.  Getting cards with the  , > firmware already resident is the only way. >  > bob  >   H I believe that there is, or was, hardware and software available on the G open market that is capable of writing or maybe rewriting these cards.  H The blank cards are, or were, available on the open market.  Whether it 2 is legal to copy the firmware is another question.  G The question (technical, not legal) arose many years ago in a contract  I position.  The HSJ40 contollers had the nasty habit of damaging the card  G every time the contoller lost power.  The manager asked someone, in my  D presence, if it was possible for him to "roll his own" replacements.  F DEC/Compaq dropped support for the HSZ50 controllers firmware four or F five years ago so I imagine the HSZ40s have been unsupported for even  longer than that.    ------------------------------  % Date: Sat, 30 Sep 2006 20:18:20 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> $ Subject: Re: hsz40 firmware questionJ Message-ID: <paul.sture.nospam-E34993.20182030092006@mac.sture.homeip.net>  : In article <2eSdneSd-atDMIPYnZ2dnUVZ_rydnZ2d@comcast.com>,5  "Richard B. Gilbert" <rgilbert88@comcast.net> wrote:     H > DEC/Compaq dropped support for the HSZ50 controllers firmware four or H > five years ago so I imagine the HSZ40s have been unsupported for even  > longer than that.   F A similar story with HSJ40s five or so years ago too. Under heavy I/O H they would throw a problem which was down an acknowledged firmware bug, * but they were out of their support period.  D The official Compaq recommendation was to purchase newer, supported D controllers. Having quite a lot of them at the time, we shifted our ? workload so that the I/O intensive apps ran on more up to date  E controllers, and carried on using the HSJ40s for less intensive work.    --  
 Paul Sture   ------------------------------  % Date: Sat, 30 Sep 2006 20:06:35 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> - Subject: Re: Hub vs Switch : SCS, LAT, DECNET < Message-ID: <451f04b3$0$24178$9a6e19ea@news.newshosting.com>  + "Pete" <None@nospam..com> wrote in message  2 news:nn4th2p7obarh0rf4ea4mmodq0pe1ffno8@4ax.com.... > On Fri, 29 Sep 2006 00:45:13 -0400, JF Mezei' > <jfmezei.spamnot@teksavvy.com> wrote:  > 4 I've noticed two hub flavours in the past few years:  F 1) real dumb - they pass anything and are great for debugging network  problems, snooping + hacking  L 2) semi-intelligent - these contain a CPU and can perform Ethernet bridging K functions etc. Some can cause problems if you forget to cycle the power on  M them after you've reconfigured your network (like moving a NIC from one port   to another)       ###  G Ethernet switches work like a hub except logic on each port makes sure  M non-broadcast packets are only delivered to one destination. This also foils   promiscuous snooping.   K All routers are intelligent and can do various things you wouldn't expect.  I The cheap ones usually will only support TCP/IP while others may support  K things like DECnet, IPX, AppleTalk, depending upon what software is loaded  M into them and how they are configured. Some very expensive routers allow you  G to load and run additional programs to support things Proxy-ARP, stats  ? collection, and the design of new or private network protocols.        ###   C As others have already pointed out, LAT, MOP, NetBIOS etc. are all  L non-routable protocols. Any properly designed router should just pass along ? unrecognized packets but the cheaper ones don't always do this.   H So to get past the afore mentioned obstacles programmers have developed = methods to stuff DECnet and NetBIOS inside of TCP/IP packets.   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/    ------------------------------  % Date: Sat, 30 Sep 2006 15:08:12 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ) Subject: IDE (DQ) devices served to VAX ? , Message-ID: <451EC09B.4752724B@teksavvy.com>  & My alpha has a DQ device (DQA0:) fisk.  < My alpha sees all my vax disk devices. (and can mount them).  H None of my 3 vaxes see the alpha's DQ devides (there are actually 4, butH only one is "real" then other probably refer to the empty slots and each have 1 error).  ) on the alpha, MSCP_SERVE_ALL is set to 1.   G Looking at google, it seems that DQ device support appears circa 7.1. I F am at 7.2 on VAX. But on VAX, DQ device support  happened in the 1930s< with some ancient RL02 tape devices if I read correctly :-)   D Does the VAX node have to have a driver to know how to MSCP access aH remote IDE device ? Or can a remote node present to a VAX a list of disk? drives whose designations are totally unknown and the VAX still B succesfully create those devides in its table of available disks ?  F In other words, can my problem of the vases not seeing the DQA0 deviceG be solved with a simple SYSGEN CONNECT command ? Or is that a sign of a  greater problem ?    ------------------------------  + Date: Sat, 30 Sep 2006 18:02:04 -0500 (CDT) * From: sms@antinode.org (Steven M. Schweda)- Subject: Re: IDE (DQ) devices served to VAX ? 2 Message-ID: <06093018020477_2020028F@antinode.org>  - From: JF Mezei <jfmezei.spamnot@teksavvy.com>   ( > My alpha has a DQ device (DQA0:) fisk.  J > None of my 3 vaxes see the alpha's DQ devides (there are actually 4, butJ > only one is "real" then other probably refer to the empty slots and each > have 1 error).  + > on the alpha, MSCP_SERVE_ALL is set to 1.   6    write sys$output f$getdvi( "DQA0", "SERVED_DEVICE")  " There's ALL, and then there's ALL.  F > Does the VAX node have to have a driver to know how to MSCP access a > remote IDE device ?  [...]  E    Why would it?  It's talking to the MSCP server, not to the device.   H > In other words, can my problem of the vases not seeing the DQA0 deviceI > be solved with a simple SYSGEN CONNECT command ? Or is that a sign of a  > greater problem ?   !    "SYSGEN CONNECT" what?  Where?       HELP SET DEVICE /SERVED  H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------  % Date: Sat, 30 Sep 2006 20:37:21 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> - Subject: Re: IDE (DQ) devices served to VAX ? , Message-ID: <451F0DC0.90128647@teksavvy.com>   "Steven M. Schweda" wrote:  5 $ write sys$output f$getdvi( "DQA0", "SERVED_DEVICE")  TRUE     >    HELP SET DEVICE /SERVED   $ show dev/served :        MSCP-Served Devices on BIKE 30-SEP-2006 20:32:44.52  ;                                              Queue Requests E Device:           Status      Total Size     Current    Max     Hosts E     $2$DQA0        Avail        58633344           0      0         0 E     $2$DQA1        Avail             512           0      0         0 E     $2$DQB0        Avail             512           0      0         0 E     $2$DQB1        Avail             512           0      0         0      $ show dev $2$dqa0/full   K Disk $2$DQA0: (BIKE), device type Maxtor 53073H6, is online, mounted, file- P     oriented device, shareable, served to cluster via MSCP Server, error logging     is enabled.   H     Error count                    0    Operations completed               6279O     Owner process                 ""    Owner UIC                      [SYSTEM] O     Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W H     Reference count              137    Default buffer size                 512H     Total blocks            58633344    Sectors per track                    87H     Total cylinders             7659    Tracks per cylinder                  88O     Logical Volume Size     58633344    Expansion Size Limit         2148466688 $     Allocation class               2  H     Volume label         "FREEWHEEL"    Relative volume number                0H     Cluster size                  16    Transaction count                   327O     Free blocks             56573312    Maximum files allowed          16711679 H     Extend quantity                5    Mount count                           1O     Mount status              System    Cache name          "_$2$DQA0:XQPCACHE" O     Extent cache size             64    Maximum blocks in extent cache  5657331 O     File ID cache size            64    Blocks in extent cache          5656960 H     Quota cache size               0    Maximum buffers in FCP cache       1040O     Volume owner UIC           [1,1]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD   L   Volume Status:  ODS-5, subject to mount verification, protected subsystemsF       enabled, file high-water marking, write-through caching enabled.    @ So, it appears that from the Alpha's point of view, that disk isE definitely served and offered to the rest of the cluster. But none of  the VAXes see a $2$dqa0 device.   C BTW, is there a way to avoid DQA1, DQB0 DQB1 from being created  if 7 nothing is physically attached to those logical slots ?    ------------------------------  + Date: Sat, 30 Sep 2006 23:32:16 -0500 (CDT) * From: sms@antinode.org (Steven M. Schweda)- Subject: Re: IDE (DQ) devices served to VAX ? 2 Message-ID: <06093023321677_2020028F@antinode.org>  - From: JF Mezei <jfmezei.spamnot@teksavvy.com>   7 > $ write sys$output f$getdvi( "DQA0", "SERVED_DEVICE")  > TRUE      Ok.  B > So, it appears that from the Alpha's point of view, that disk isG > definitely served and offered to the rest of the cluster. But none of ! > the VAXes see a $2$dqa0 device.   C    Not that it matters here, but why the non-zero allocation class?   >    Is there a "CONFIGURE" process running on all the systems? G Suppressing automatic configuration in the start-up procedures can have & the side effect of skipping around theH sys$startup:vms$initial-050_configure.com step, and that can prevent theC list of available disks fron being updated when a new guy joins the E cluster.  (As I recall, if that's the problem, then rebooting the VAX % might clear the problem temporarily.)   E > BTW, is there a way to avoid DQA1, DQB0 DQB1 from being created  if 9 > nothing is physically attached to those logical slots ?   C    Suppress automatic configuration in the start-up procedures?  In  SYS$MANAGER:SYCONFIG.COM:   E $!      Remove the comment from the line below if you wish to prevent C $!      VMS from configuring devices with a SYSMAN IO AUTOCONFIGURE F $!      command.  This is typically only required if you are debugging $!      new device drivers.  $!& $!      STARTUP$AUTOCONFIGURE_ALL == 0  G Then add all the necessary stuff to SYCONFIG.COM to get configured what E you want configured.  See also SYS$STARTUP:VMS$DEVICE_STARTUP.COM for F what would have happened if STARTUP$AUTOCONFIGURE_ALL were still set. ? (Like, for example, configuring FTA0 and MPA0, and starting the  "CONFIGURE" process.)   H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------  $ Date: Sun, 1 Oct 2006 07:27:19 +08003 From: "Richard Maher" <maher_rj@hotspamnotmail.com> > Subject: Re: In the Land of the Blind, the Hoff is truly King!1 Message-ID: <efmukc$4i4$1@news-02.connect.com.au>    Hi Toby,   >  > In V.B. veritas. NOT.   / I dunno; it seems to work for Russell Crowe :-)    Regards Richard Maher   I PS. Not sure if your post was meant to be a social comment or critique of I the Australian male, or a pooh-ppoh of my theory in the previous post. If J the latter then I have a mate who downloaded the 7.2-2 sources, matched upH the code streams in the crash dump, and says you're talking through your arse!   2 "toby" <toby@telegraphics.com.au> wrote in message= news:1159146958.585606.152640@m73g2000cwd.googlegroups.com...  > Richard Maher wrote: > > Hi Dave, > > 8 > > "Dave Froble" <davef@tsoft-inc.com> wrote in message7 > > news:ZumdnXXX0vajcpfYnZ2dnUVZ_t2dnZ2d@libcom.com... L > > > Is that a tease?  I'm sure I'm not the only one following this thread.I > > > Some of us may be interested in what caused the problem.  Since you  say G > > > it takes priviledge to cause the crash, you wouldn't be causing a 2 > > > problem in going public with what you found. > > G > > I can't promise you an answer but FWIW here are my thoughts on what  may've > > happened. ... L > > PS. Anyone see bits of the Steve Irwin memorial the other day? When JohnJ > > Williamson sang Steve's favourite song? You used to be able to hear it ringK > > out through the suburbs after a bbq when the blokes had had just enough  beer >  > In V.B. veritas. NOT.  > ! > > that they'd start babling ...  >    ------------------------------  $ Date: Sun, 1 Oct 2006 07:51:18 +08003 From: "Richard Maher" <maher_rj@hotspamnotmail.com> > Subject: Re: In the Land of the Blind, the Hoff is truly King!1 Message-ID: <efmvn7$61g$1@news-02.connect.com.au>    Hi John,  I > I've chewed through the restraints enough to type this with one finger.   J Great to see you're alive and well! (I was getting milk cartons printed up' with your photo on them and everything)   B > BLOCK have no builtin support for such things like /CHECK=BOUNDSC > . . .Traditionally, most people haven't gone to this extreme when  > writing BLISS code.   I For those who may read this in years to come, yes, I was being facetious. J The "Trainer-Wheels" jibe, and lesson in humility, obviously meant for the8 pompous, the infallible, and those with their own blogg.   Cheers Richard Maher  J PS> Don't forget to pass on a Big "F" to VMS Engineering from "PunksatawnyH Bill" of the faculty of "Systems Design and Real-World avoidance" at BFUI Pennsylvania. There's just no way he'd let one of his pizza-faced urchins I develop an operating system for the next 30 years in Bliss or Macro! What 5 the hell were you guys thinking of? (I blame the 60s)   K PPS> Oh and for the other mantra-chanters let me just point out a couple of K restrictions you should be aware of before suggesting alternative languages L for the nsa$size_nsab routine (or VMS re-write, if you prefer) : - 1) It hasF to be able to operate in Kernel mode without any language specific RTL1 support and 2) It has to be available on Itanium.   3 "John Reagan" <john.reagan@hp.com> wrote in message * news:U0dSg.377$_b5.234@news.cpqcorp.net... > Richard Maher wrote:8 > > Maybe Bliss needs some /CHECK=BOUNDS trainer-wheels? > > J > > But I don't know Bliss so maybe it just knows, and I'm jumping the gunJ > > again. If only John Reagan hadn't been bound, gagged and thrown in theE > > basement then *he* could've told us :-( Off to find another Bliss 	 person. .  > > .  > >  > I > I've chewed through the restraints enough to type this with one finger.  > H > The predeclared BLISS structure constructs like BITVECTOR, VECTOR, andC > BLOCK have no builtin support for such things like /CHECK=BOUNDS.  > I > However, if one desired, you can declare your own structure with a name G > like CHECKED_VECTOR that could execute code at run-time to verify the I > bounds.  However, you would have to modify the BLISS source to get that H > benefit.  Traditionally, most people haven't gone to this extreme when > writing BLISS code.  >  >  > --  
 > John Reagan 7 > HP Pascal/{A|I}MACRO/COBOL for OpenVMS Project Leader  > Hewlett-Packard Company    ------------------------------  $ Date: Sun, 1 Oct 2006 08:34:51 +08003 From: "Richard Maher" <maher_rj@hotspamnotmail.com> > Subject: Re: In the Land of the Blind, the Hoff is truly King!1 Message-ID: <efn28r$9cn$1@news-02.connect.com.au>    Hi Ian,    > have you read this?   L You've posted so many pointers to it up and down the web (And in Wednesday'sK Evening Standard, I believe) that it would be almost impossible not to have G stumbled across it :-( How about posting a pointer to my reply with the L answer in it, for those who seek more the technical details and facts rather> than another opportunity to worship at the feet of their guru?  H Yes, I read it (all 10 fact-devoid volumes of it) and found it to be theI greatest work of fiction since Saddam's WMD enquiry! (You should get Hoff H working on the Iranian report. You'd be "nuking those towel-heads" in noJ time.) At least to me, the Mills and Boon prose betrayed a naivety usuallyD found only in one with very little development access to a keyboard.  F > "As for the resolution of the failure, a small reorganization to theI > $audit_event[w] source code has blocked the particular exposure and the H > vulnerability within the itemlist processing, and this change has been7 > implemented within the source code pool for OpenVMS."  > D > sounds like what you are describing (doing validation in the wrong > order) is parhaps correct.  H You're right! I added *no* value and introduced *no* new information andK just regurgitated what Hoff had already said. I've included *my* post below J so everyone can see how clever Ian was in sussing it. Hoff said "SomethingK has changed to fix it". It's pretty hard to argue with that. EXCEPT that he K made the fatal mistake of naming the code to be changed. Confidence must've I been high that if $audit_event was causing the bug-check then this is the @ code that would be changed, but if I was right and the subscriptL out-of-range bug with nsa$validate_table was causing the crash then the codeG to be changed would be nsa$size_nsab and *not* $audit_event. "Splitting I Hairs" you might say? Well this is where I usually slipp into a couple of G paragraphs of self-indulgance and wax lyrical about modular programming H techniques as if you're all dickheads, but I must end the digression. IfJ nsa$size_nsab *is* causing the crash then it can also be caused by $chkproC and $check_privilege that thankfully also seem to need Audit privs.   K But before I rush out the door let's look at a few other things Hoff had to C say (the varacity of which I leave as a conundrum for the reader):-   9 > The OpenVMS code review also showed nothing remarkable, 8 > the contents of the itemlist were apparently verified.  A > In the case of the failing $audit_eventw call, it was literally = > the specific detritus on the stack -- the random data bytes B > in the right spot in the right range of addresses just after the< > (missing) end of the itemlist got just far enough into and/ > just past the existing itemlist verification.   $ > into what amounted to random data.  6 > When the itemlist processing hit the particular (and) > effectively the "just wrong") detritus,   : > In this case, it was the "just wrong" data after the endB > of the unterminated itemlist, and data that's not deterministic.   Cheers Richard Maher  K PS. How's your question about Shareable image SOGW protections coming along  Ian?  + "Ian Miller" <ijm@uk2.net> wrote in message < news:1159290851.627324.38710@k70g2000cwa.googlegroups.com... > have you read this?  > F > http://h20325.www2.hp.com/blogs/hoffman/archive/2006/09/16/1609.html > F > "As for the resolution of the failure, a small reorganization to theI > $audit_event[w] source code has blocked the particular exposure and the H > vulnerability within the itemlist processing, and this change has been7 > implemented within the source code pool for OpenVMS."  > D > sounds like what you are describing (doing validation in the wrong > order) is parhaps correct. >  Hi Dave,  4 "Dave Froble" <davef@tsoft-inc.com> wrote in message3 news:ZumdnXXX0vajcpfYnZ2dnUVZ_t2dnZ2d@libcom.com... H > Is that a tease?  I'm sure I'm not the only one following this thread.I > Some of us may be interested in what caused the problem.  Since you say C > it takes priviledge to cause the crash, you wouldn't be causing a . > problem in going public with what you found.  J I can't promise you an answer but FWIW here are my thoughts on what may'veK happened. (Given the reported truth and integrity vacuums that appear to be J prevailing, this is probably the best you'll get. I can't tell you whetherJ my theory it's right or wrong (until the next source code release), but ifG you (or anyone) can tell me why it's not possible, or correct, then I'm " happy to have another look at it.)  F [Or I could just wait for the dump to complete again, and see if I canJ convert the System Dump PC into the line number/address in the VMS source,C or reverse engineer the last macro-64 instructions into their Bliss J counterparts; that too would be good :-) Must be a Fine Manual around here on Reading a System Dump.]   In the meantime: -  J 1) As reported, an item list to $audit_event (when left un terminated) was1 observed to crash the system from User Mode code.   L 2) On Planet Dickie, Item Lists are passed By Reference, therefore I believeJ that everything following the Audit_List in the same Cobol PSECT up to theH first occuring aligned or coded zero-lognword (in the correct terminatorH offset) will be processed by $audit_event in situ, and that something in7 that compiler initialized memory is causing the problem   E 3) I wrote a subroutine to mimic the Item_List parse by receiving the I Item_List By Reference and dumping out its contents until I found a valid H terminating longword. (The complete output of which is below. As you canG see, my program says there are now 27 item list entries rather than the  expected 12) "  J 4) If my theory was correct then item 13 (unlucky for some :-) should failH any validation check 'cos surely 20526 is greater than nsa$_max_itm_codeI which  is 279 on my box but 283 on later versions. For those of you ASCII I buffs, I once again submit that this is the contents of audit_object_name F (ie: St.Peter blah blah . . . all the way to the end of the Uai_List.)  D 5) As a test, I added these items to the end of the Audit_List after Item_Time_Stamp: -     03  item_crash. 2         05  pic s9(4)       comp    value   29779.2         05  pic s9(4)       comp    value   20526.7         05  pic s9(9)       comp    value   1919251557. 7         05  pic s9(9)       comp    value   1953841440. .     03  item_terminate   pic s9(9)       comp.J And guess what? It still crashed; so I think we're doing ok so far! Off to look at the code again.   K 6) If you look at the nsa$size_nsab routine in security_auditing_64.lis  at K line 1085, you will see that it does in fact check that the item code is in F the valid range of 1 to nsa$_max_itm_code. So why isn't that simple IF returning ss$_baditmcod?  K 7) Hold everything! What do we have lurking up there at line 1079? Could it  be: -   ?     if .nsa$validate_table[.item_code, itm_size_min] eql ignore   L But if nsa$validate_table is only nsa$max_itm_code big, then what happens if8 VMS engineering attempts to reference element (20526)???  K Elsewhere in the source lines (711, 721) and nsa$itmlst_to_pktlst (283) the K order of the checks is reversed, as expected. But what about the comment on H line 101 on 20-Nov-1997 "Reorder parameter checking to avoid bogus array index values in NSA$SIZE_NSAB."   D Unfortunately, I don't have the resources to assemble the previouslyL convened dream-team of Hoffman, Plato, Socrates, Da Vinci and Einstein to doJ a code review, but at face value (at least to me) it looks decidedly fishyK to do a table lookup for an element before validating that the subscript is > in range. Maybe Bliss needs some /CHECK=BOUNDS trainer-wheels?  F But I don't know Bliss so maybe it just knows, and I'm jumping the gunF again. If only John Reagan hadn't been bound, gagged and thrown in theK basement then *he* could've told us :-( Off to find another Bliss person. .  .   B 8) A mate tells me that the "uplit" part of the nsa$validate_tableL declaration materializes it in a read-only Psect at compile-time. (Just likeI Macro and Cobol can. These 3 great languages have much in common!) So I'm G guessing that the "ignore" flag lookup for item list entry 13 with just K calculate an address that is nsa$validate_table+(20526*bytes_per_entry) and L try to read it. Couldn't see enough after nsa$validate_table in the listingsJ to cover it so that probably explains why it varies from sysgen parameters to machines to quotas to . . .  E Anyway, the footy's back on and the Eagles are getting thrashed (were I consistent over here :-() Let me no if it doesn't stand up or if you like  it.   I If you think of it, I can't be right because this would warrant an urgent L fix as *any* call to $audit_event is now a time-bomb just waiting for a userG mode ponter to set it off. Or is it a case of "She'll be right"? hasn't G happened all these years and we don't want to panic anyone with another L security release. (Anyone seen the release note for $create_user_profile andG the user-mode corruption of exec-mode memory? Nah must've been dreaming  there too.)   L YES, This is all tongue in cheek! If it is a bug then it's just that; a bug!I Fix it and move on - no big deal. I've gone out of my way to sound like a I pompous arse here (not much trouble really :-)  because that is what your 4 superior, arrogant, self-indulgent crap sounds like.   Cheers Richard Maher  I NB: I must stress at this point that no thorough review of any VMS source F code including, but not limited to, $audit_event and any subroutine it> invokes, has taken place. I do not offer any opinion as to theF merchantability of said software nor to its fitness for any particularK purpose. If I have identified a bug then all well and good (and soon may it J be fixed) but I by no means warrant that is the last bug in these modules,K nor that the probing of arguments covers multiple page boundries, an yadda,  yadda yadda. . .  H PS. Anyone see bits of the Steve Irwin memorial the other day? When JohnK Williamson sang Steve's favourite song? You used to be able to hear it ring L out through the suburbs after a bbq when the blokes had had just enough beerK that they'd start babling and telling everyone just how much "I love yous!" H (In a Perth sense and not the Sydney sense :-) Anyway, you don't hear it3 much anymore and I for one had to wipe away a tear!    Is it standin by your mate when he's in a fi-ight?  Or just "She'll be right"?  % Tru-oo-oo-blue, I'm arrrskin YOUUUUU!    Item_list Dump: - > Item (1) code = 89 len = 4 addr_1 = 000200A0 addr_2 = 00000000> Item (2) code = 90 len = 4 addr_1 = 000200B8 addr_2 = 00000000= Item (3) code = 3 len = 8 addr_1 = 00020228 addr_2 = 00000000 = Item (4) code = 6 len = 8 addr_1 = 00020228 addr_2 = 00000000 @ Item (5) code = 189 len = 16 addr_1 = 00020218 addr_2 = 00000000? Item (6) code = 29 len = 31 addr_1 = 000201F8 addr_2 = 00000000 > Item (7) code = 48 len = 4 addr_1 = 00020150 addr_2 = 00000000? Item (8) code = 192 len = 4 addr_1 = 0002035C addr_2 = 00000000 ? Item (9) code = 190 len = 4 addr_1 = 00020028 addr_2 = 00000000 ? Item (10) code = 56 len = 6 addr_1 = 000204F4 addr_2 = 00000000 ? Item (11) code = 80 len = 6 addr_1 = 0002051C addr_2 = 00000000 ? Item (12) code = 50 len = 8 addr_1 = 00020300 addr_2 = 00000000 F Item (13) code = 20526 len = 29779 addr_1 = 72657465 addr_2 = 74754120F Item (14) code = 29806 len = 25960 addr_1 = 74616369 addr_2 = 206E6F69F Item (15) code = 30322 len = 25939 addr_1 = 00207265 addr_2 = 61746544F Item (16) code = 25701 len = 26723 addr_1 = 6F725020 addr_2 = 73736563F Item (17) code = 21827 len = 17747 addr_1 = 59544952 addr_2 = 00160001@ Item (18) code = 2 len = 672 addr_1 = 00000000 addr_2 = 00150002@ Item (19) code = 2 len = 680 addr_1 = 00000000 addr_2 = 00120008@ Item (20) code = 2 len = 720 addr_1 = 00000000 addr_2 = 00130008@ Item (21) code = 2 len = 728 addr_1 = 00000000 addr_2 = 00230004@ Item (22) code = 2 len = 688 addr_1 = 00000000 addr_2 = 00190008@ Item (23) code = 2 len = 744 addr_1 = 00000000 addr_2 = 00140002@ Item (24) code = 2 len = 840 addr_1 = 00000000 addr_2 = 001E0008@ Item (25) code = 2 len = 760 addr_1 = 00000000 addr_2 = 001D0008@ Item (26) code = 2 len = 752 addr_1 = 00000000 addr_2 = 00000000> Item (27) code = 0 len = 3 addr_1 = 00000000 addr_2 = 0000E95C    4 "Dave Froble" <davef@tsoft-inc.com> wrote in message3 news:ZumdnXXX0vajcpfYnZ2dnUVZ_t2dnZ2d@libcom.com...  > Hoff Hoffman wrote:  > > K > > As it happens, the working theory was not the actual trigger here (data J > > often has a habit of derailing theories), but what was recently postedJ > > had sufficient data within to allow the identification of the specificG > > trigger from amid all the stack detritus that was located after the A > > (missing) termination within your particular OpenVMS run-time  environment. > H > Is that a tease?  I'm sure I'm not the only one following this thread.I > Some of us may be interested in what caused the problem.  Since you say C > it takes priviledge to cause the crash, you wouldn't be causing a . > problem in going public with what you found. >  > --  6 > David Froble                       Tel: 724-529-0450@ > Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com > DFE Ultralights, Inc.  > 170 Grimplin Road  > Vanderbilt, PA  15486    ------------------------------  % Date: Sat, 30 Sep 2006 20:21:03 -0400 6 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> Subject: Re: Java Error + Message-ID: <NRDTg.1112$2g4.359@dukeread09>    benitos wrote:G > The dev team is having problems running a new SCT provided .com file. C > It uses Java. We basically get a "java.lang.NoClassDefFoundError: ; > com/sct/messaging/bif/banner/BannerBatchProcessor" error.  > 	 > Running  > GONZO|BANNER  >java -version > java version "1.3.1"2 > Java(TM) 2 Runtime Environment, Standard EditionC > Classic VM (build 1.3.1-7, 12/15/2003-21:59, native threads, jit)  > " > GONZO|BANNER  >sho log classpath >    "CLASSPATH" =B > ".:/jdbc_lib/classes12.zip:/jdbc_lib/jta.zip:/jdbc_lib/jndi.zip" > (LNM$PROCESS_TABLE)  > GONZO|BANNER  >   D > .JAR file is located in another disk and other jar files are beingF > used. Do I need to move these sys$common files over there?? Redefine > classpatch?     , What command do you use to run the program ?  6 Not the command used to run the COM file, but the Java command inside the COM file.  1 It sounds as if classpath is not setup correctly.    Arne   ------------------------------    Date: 30 Sep 2006 22:51:32 -02006 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)7 Subject: Re: Mild warning: TCPIP Services UIC/Usernames * Message-ID: <451ef4f4@news.langstoeger.at>  \ In article <451B36E2.B2E0295D@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:C >While consolidating two separate UAF files, I've hit a snag: TCPIP ? >Services does not necessarily create all its own UICs equally.   7 And so it does for a decade now. Welcome to the club...   H >For instance, on one node, [3655,2] is for TPCIP$POP while on the other >node, it is for TCPIP$BIND  > H >And if you configure TCPIP$BIND on the first node, it obviously doesn'tD >get [3655,2], it gets [3655,x] where "x" is some semi random number. >(first unused UIC in that group is my guess).  I It depends it which order you configure your services. Yes, you're right.   H >Makes for some interesting issues when you move directories from a nodeG >to be decommissioned to one which will take over its services when the " >file ownership no longer matches.  B How about consolidating the RIGHTSLIST at the same time as SYSUAF?B Or in fact, as one cannot create integer identifiers with a numberB at its will, use one system as a source for RIGHTSLIST and copy itD over to the other systems regularly (if security is no problem then)E especially before you install the same software on the next node (you $ already did on the "source node")...  8 >Not the end of the world, but something to be aware of.  / Yup. And AFAIK, it is still not in the VMS FAQ.   I >Personally, I think that the TCPIP group should have assigned fixed UICs E >for each service, and allocated a group of UICs for "floating" ones.    Yup.  I >For instance, reserve 1 to 50 for Digital provided services, and 200-300 < >for customer/3rd party TCPIP services to be added later on. > A >This way, no matter in which order to confifuyre TCPIP, the main @ >services would always have the same UICs on all nodes that haveA >disparate SYSUAF files. (not all nodes would be in a cluster for 5 >instance, some might use DECNET for file transfers).   , UICs are not the only problem with TCPIP/UCX   --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Sat, 30 Sep 2006 14:41:29 -0500 ! From: John <norad869@comcast.net> + Subject: Re: Normal temperature for DS10L ? * Message-ID: <451EC869.8070902@comcast.net>  , This is a multi-part message in MIME format.& --------------070309020302030406040908; Content-Type: text/plain; charset=ISO-8859-1; format=flowed  Content-Transfer-Encoding: 8bit   F The 44 seems high - 111 degrees F ... even if Island says they do run 7 hotter ... I just think that that is too high... (IMHO)   F I have an DS20 that would flake out around 86 degrees F...  over time I and each time that the server got that HOT the temperature that it would  H flake out decreased - to the point where it started to flake out around  76 degrees.   B Though I could not measure the temperature directly I was able to H measure the temperature of the server (ES40) immediately above the DS20  using   . $ temp_vector = f$getsyi("temperature_vector")  ) I am not sure this will work on the DS10.   - The ES40 would flake out around 92 degrees F.   H If you would like to monitor this - go to www.ibuttonlink.com and get a G LINKTH and MS-T sensor - plugs into your serial port of your DS10 - or  I with a DB9 adapter it will plug into a DECserver (one w/RS232 attributes   - power in other words).       JF Mezei wrote:   I >When powered off, my new DS10L is about 25  (STATUS at the RMC> prompt,  >or SHOW POWER at >>> prompt)  > H >When powered on, it quickly rises to 44 and then slowly rises to about >49 in a couple of hours. > 7 >An alert is set to be made at 55 and shutdown at 60.  >  > ' >Are there temperatures pretty normal ?  > H >All fans seems to be operating. And the air coming out the back is hot. >  >    >   & --------------070309020302030406040908) Content-Type: text/html; charset=us-ascii  Content-Transfer-Encoding: 7bit   ? <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">  <html> <head>I   <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">    <title></title>  </head> ' <body bgcolor="#ffffff" text="#000000"> E The 44 seems high - 111 degrees F ... even if Island says they do run ; hotter ... I just think that that is too high... (IMHO)<br>  <br>J I have an DS20 that would flake out around 86 degrees F...&nbsp; over timeB and each time that the server got that HOT the temperature that itF would flake out decreased - to the point where it started to flake out around 76 degrees.<br> <br>A Though I could not measure the temperature directly I was able to G measure the temperature of the server (ES40) immediately above the DS20 	 using<br>  <b><br> 6 $ temp_vector = f$getsyi("temperature_vector")</b><br> <br>- I am not sure this will work on the DS10.<br>  <br>1 The ES40 would flake out around 92 degrees F.<br>  <br> If you would like to monitor this - go to <a class="moz-txt-link-abbreviated" href="http://www.ibuttonlink.com">www.ibuttonlink.com</a> and get a F LINKTH and MS-T sensor - plugs into your serial port of your DS10 - or= with a DB9 adapter it will plug into a DECserver (one w/RS232 ' attributes - power in other words).<br>  <br> <br> <br> JF Mezei wrote: A <blockquote cite="mid451C4FD3.96315F70@teksavvy.com" type="cite"> ^   <pre wrap="">When powered off, my new DS10L is about 25&deg;  (STATUS at the RMC&gt; prompt,% or SHOW POWER at &gt;&gt;&gt; prompt)   K When powered on, it quickly rises to 44&deg; and then slowly rises to about  49&deg; in a couple of hours.   > An alert is set to be made at 55&deg; and shutdown at 60&deg;.    & Are there temperatures pretty normal ?  G All fans seems to be operating. And the air coming out the back is hot.      </pre>
 </blockquote>  </body>  </html>   ( --------------070309020302030406040908--   ------------------------------  * Date: Sun, 1 Oct 2006 03:45:03 +0000 (UTC), From: Michael Moroney <moroney@TheWorld.com>+ Subject: Re: Normal temperature for DS10L ? ( Message-ID: <efndjv$6hd$1@pcls6.std.com>  # John <norad869@comcast.net> writes:   G >The 44 seems high - 111 degrees F ... even if Island says they do run  8 >hotter ... I just think that that is too high... (IMHO)  H Mine goes back and forth between 45 and 46 C.  This is chip temperature,) not temp. of the box or room temperature.   C >Though I could not measure the temperature directly I was able to  I >measure the temperature of the server (ES40) immediately above the DS20   >using  / >$ temp_vector = f$getsyi("temperature_vector")   * >I am not sure this will work on the DS10.  , It does, and this is the temperature I gave.  G For those wondering what it is or how to interpret it, it's a very long J hex number, for the DS10L the last two hex digits are the temperature, allG the other digits (all F's) are reserved for the 31 CPU expansion option  :-) .    ------------------------------  % Date: Sat, 30 Sep 2006 22:06:50 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> @ Subject: Re: OpenVMS support contracts for hobbyists: A scenarioJ Message-ID: <paul.sture.nospam-E92EBD.22065030092006@mac.sture.homeip.net>  9 In article <NaudnSShuYzbN4PYnZ2dnUVZ_u6dnZ2d@libcom.com>, )  Dave Froble <davef@tsoft-inc.com> wrote:    > Paul Sture wrote:  > > F > > Cough... At one period SPRs were the only things I _didn't_ ask a F > > secretary to type for me, due to the errors invariably introduced. > > M > > Extremely professional business letters and memos, complete with correct  L > > spelling and grammar were one thing, snippets of code or error messages  > > were something else :-)  > >  > I > Didn't you enjoy it when a non-technical person attempted to 'correct'  ( > your spelling and other mistakes?  :-)   Definitely :-)  H Once I discovered RUNOFF, provided I had access to the console printer, E a bit of creative work with scissors and a photocopier was the way I   went.   A And before you ask, getting multipart SPRs through a tractor fed  ; dot-matrix printer was tried, without satisfactory results.    --  
 Paul Sture   ------------------------------  % Date: Sat, 30 Sep 2006 13:47:59 -0400 ' From: Dave Froble <davef@tsoft-inc.com> H Subject: Re: Options for the future of VMS systems after last order date9 Message-ID: <J-ydnfL2q4hXNoPYnZ2dnUVZ_vmdnZ2d@libcom.com>    JF Mezei wrote:  > Dave Froble wrote:I >> Ok, the second statement is mine, but the first is William Webb.  Note M >> that I don't call you an idiot, just question the expectations of another.  > I > OK, I am sorry then.  Since you appear to be the champion of JF-bashing E > here, I tended to automatically assume that statement had come from < > you....  Seems you lost your exclusivity on JF-bashing...   $ And I've complained about that.  :-)  H > Anyone else taking you up on your offer to use aliminIum baseball batsJ > to reshape my head ?  :-) Maybe Gantanamo bay might be safer for me than > the bootcamp :-)  * Ah well, maybe time to burst your balloon.  E Your usage of '8086' and such doesn't bother me nearly as much as it  E appears to bother some.  The threat of the bats doesn't exist.  It's  F just a momentary 'virtual' thought that allows me to continue smiling.  G I just don't let too many things really affect me.  Let off steam, and  3 the pressure never rises to a dangerous level.  :-)   H However, the latest news out of VMS Engineering did get to me.  I think E I suspected that eventually such would happen, but I was hoping some  4 reason would prevail.  Apparently not in this world.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Sat, 30 Sep 2006 13:54:44 -0400 3 From: "Richard B. Gilbert" <rgilbert88@comcast.net> H Subject: Re: Options for the future of VMS systems after last order date: Message-ID: <2eSdneed-av7MoPYnZ2dnUVZ_rydnZ2d@comcast.com>   Dave Froble wrote:   > Dave Weatherall wrote: > @ >> On Fri, 29 Sep 2006 10:46:18 UTC, etmsreec@yahoo.co.uk wrote: >>" >>> Dear BBC, Why oh why oh why... >>> D >>> JF, there are no modern 8086 servers.  Only modern IA32 servers. >>>  >>> *bangs head against wall*  >>>  >>> JF Mezei wrote:  >>> H >>>> Another option is to get modern 8086 servers and emulate Alpha with >>>> Charron Alpha product.  >> >> >>I >> Guys            this banging on about JF's use of 8086 instead of x86  E >> or Ia32(e) is beginning to become tiresome and a serious waste of  G >> bandwidth. We _all_ know what he means so can't we just accept that  I >> that is the way he refers to the non-itanium 'industry standard' Intel  >> CPU architecture. >  >  > Do I really have to quit?  > F >> We all have shortcuts that are not wholly accurate. Some bug other H >> people, some bug us. I, for example, have given up trying to stop my G >> users calling the Alpha/VMS platform they've been using for over 10  H >> years as 'the VAX'.  There's only me left using the two VAXen in our  >> cluster.  >>! >> No offense intended to anyone.  >> > B > JF won't thank you for this.  He seems to enjoy the 'attention'. >   ( Oh great sage, I bow to your wisdom. ;-)   ------------------------------   End of INFO-VAX 2006.538 ************************                                                                                                                                                                                                                                                                                                                                                                                                    `X     P V !p  (( H    C `!
&H2 B` 
0  $0    
0L   $ #             P V !p  0  CH( !0 H$         `A
&	  H    `X     hP V !p  0  C $  H      L`2% @    `a
&	  H     `X     P V !p  0  C $  H      L`2% @    `
&	  H     `X     ȵP V !p  0  C $  H      L`2% @    `
&	  H     `X     xP V !p  0  C $  H      L`2% @    `
&	  H     `X     (P V !p  0  C $  H      L`2% @      $ B P V !p  0  C $0  H      L`2
 @    `
&	  H     `X     P V !p  0  C $0  H      L`2
 @    `&	  H     `X     HP V !p  
 CQ $0  H     L`2
 @ 
 @`!&	  H    `X     P8 D8    C $ !P2 B@d 
@ $ 8
 # @ P ` B          C`A&	  H    `X     P V !p  (p  C `a&0`2 B   0F !0           HP V !p  0  C4 !`* B             `&	  H    `X     P8 D8    C	  $ 8 # @ P
@F   8 #`
@ $ @
 #4         C`&	  H    `X     P V !p  (`  C `&	  H     L`2 @     `X     HP V !p     C  L`2 @    `&	  H     `X     P  J8  B0  C	  $ 8 #    0F          H D8   0  C $  H      L`2) @    @
&00K   
@P B             xP  F8  B@  C   $0 B@         hP V !          $BL    