1 INFO-VAX	Mon, 11 Dec 2000	Volume 2000 : Issue 690       Contents:+ Re: "process crash" vs. "application crash" , Re: ??== Allocating only one block per file. Re: acl's and identifiers  ADV: Search Engine Registration  Re: Automated RMS tuning script & Digital KBD01-AA - What is this thing?* Re: Digital KBD01-AA - What is this thing?" Re: Dismount/abort for tape drives. Re: Getting dump files from detached processes Re: INITIALIZE/MAXIMUM_FILES" Re: Kernel Overhead for Direct I/O" Re: Kernel Overhead for Direct I/O Re: New OpenVMS  Education site  RE: One world, one processor. Re:TECO, and how to make meaningful line noise Re: Very weird DCL behavior ! WTB: XL266 Alpha CPU daughtercard ) [FREEWARE] a nice replacement of SH DEV D   F ----------------------------------------------------------------------    Date: 10 Dec 2000 22:27:12 +0100) From: maulis@ludens.elte.hu (Maulis Adam) 4 Subject: Re: "process crash" vs. "application crash"! Message-ID: <Zvmj4fl0OHtj@ludens>   K In article <90n6i8$l3n$1@nnrp1.deja.com>, david_dawkins@my-deja.com writes:  [...] B > Right, in effect, I'm the developer; I'm certain none of my codeA > is going into executive mode (I don't even know how to do that,  > or why I would want to);    3 If the runner process has NO cmkrnl, cmexec, setprv 3 privilege then you cannot go to the executive mode. 9 (except calling RMS or RDB as described by somebody else)     / > however we do link with third-party libraries   / If no 3rd party shared libraries installed with 1 cmkrnl, cmexec, setprv privileges then you cannot  reach the executive mode.   5 I suggest you not use any privs that you not have to. 9 Especially: do NOT use the share, cmkrnl, cmexec, syslck,  shmem, pfnmap privileges.          > David Dawkins      Regards, Adam Maulis    ------------------------------  % Date: Sun, 10 Dec 2000 14:51:17 -0500 , From: Howard S Shubs <hshubs@mindspring.com>5 Subject: Re: ??== Allocating only one block per file. > Message-ID: <hshubs-3C70E6.14511710122000@news.mindspring.com>  @ In article <87lmtotdal.fsf@k9.prep.synonet.com>, Paul Repacholi  <prep@prep.synonet.com> wrote:  > >Ah well you could be totally outrageuse and do a merged image? >activation of directory :| Yes, I know, but it needs no spawn.   % Well, so long as you -know-... <grin>          EWwwwwwwwwwwww!!!  --   Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------    Date: 10 Dec 2000 21:53:26 +0100) From: maulis@ludens.elte.hu (Maulis Adam) " Subject: Re: acl's and identifiers! Message-ID: <yMxs1RPedkN8@ludens>   c In article <976111440.890988@news.puk.ac.za>, "Phillip du Plooy" <itbpjdp@puknet.puk.ac.za> writes:  > Hallo,  / > I had to reinstall VMS on the Axp 1000. Now I 5 > want to put back my users. I did this by getting my K > [sys0.syscommon.sysexe]sysuaf.dat file from my image backup of the ES40 . < > But now all the /identifiers of all the users are missing.  8 You may want copy or not copy another interesting files:9 SYS$SYSTEM:RIGHTSLIST.DAT               ! the identifiers ; SYS$SYSTEM:SYSALF.DAT			! auto login facility (SYSMAN> ALF) 0 SYS$SYSTEM:NETPROXY.DAT			! Decnet PhaseIV proxy= SYS$SYSTEM:NET$PROXY.DAT                ! Decnet PhaseV proxy K SYS$SYSTEM:NETOBJECT.DAT                ! network objects & their passwords F SYS$SYSTEM:NETNODE_REMOTE.DAT           ! decnet 'host name' database O SYS$SYSTEM:VMSMAIL_PROFILE.DATA         ! user's forward, new mail counters,etc N SYS$SYSTEM:VMS$OBJECTS.DAT              ! permanent security charasteristic of 					! non-file objects I SYS$MANAGER:VMS$AUDIT_SERVER.DAT        ! audit server configuration file < SYS$SYSTEM:VMS$PASSWORD_HISTORY.DATA    ! nomen-est-omen :-)   the queue databases 9 SYS$SYSTEM:QMAN$MASTER.DAT		!queue system master database ' (if you use the default queue manager:) > SYS$QUEUE_MANAGER.QMAN$QUEUES		!definition of queues and forms: SYS$QUEUE_MANAGER.QMAN$JOURNAL		!current state (jobs, etc)    B you may want copy this file but you have no right to copy that :-) SYS$SYSTEM:LMF$LICENSE.LDB   >  > Thank you  > Phillip du Plooy > DBA & SysAdmin > Potchefstroom University > South Africa > dbaph@axp3.puk.ac.za     Regards, Adam Maulis  Hungary, Center Europe :-)" Eotvos Roland University of Sience   ------------------------------  % Date: Mon, 11 Dec 2000 12:07:31 +0800  From: mike823@arabia.com( Subject: ADV: Search Engine Registration, Message-ID: <200012110407.MAA08757@ywii.com>   Removal instructions below.   # I saw your listing on the internet.   % I work for a company that specializes # in getting clients web sites listed ! as close to the top of the major   search engines as possible.   # Our fee is only $29.95 per month to ! submit your site at least twice a ! month to over 350 search engines   and directories.  $ To get started and put your web site$ in the fast lane, call our toll free
 number below.      Mike Bender  888-532-8842    & To be removed call: 888-800-6339 X1377   ------------------------------  % Date: Sun, 10 Dec 2000 15:51:40 -0600 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> ( Subject: Re: Automated RMS tuning script- Message-ID: <3A33FAEC.5CFBD932@earthlink.net>    "Thomas H. Pauli" wrote: >  > Dear Stan, > I > I still have such a piece running and will send a copy to you on Monday 
 > morning.  / Is this something you can share with the group?    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/   F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.    ------------------------------  # Date: Sun, 10 Dec 2000 20:45:23 GMT / From: atlas@world.std.com (Alexander R Svirsky) / Subject: Digital KBD01-AA - What is this thing? & Message-ID: <G5DDnt.L2G@world.std.com>  I A Digital KBD01-AA has been kicking around my parts stash for nearly four J years now since I paid $2 for it at MIT.  I thought I had gotten rid of itG a long time ago until it showed up behind a box on a shelf.  Until this E afternoon, it had never been opened or powered up.  The sticker still , sealed the opening over the power connector.  H It's a small steel cabinet about 4"H x 15"W x 14"L.  The front panel hasF four positions selectable by keyswitch, Program, Local, Remote/Secure,F Remote.  The rear has a DB-25 male connector, apparently RS-232, and a DC-37 female connector.   E Opening the cabinet reveals what is apparently a mini-QBus with three G dual-height slots occupied by, top to bottom, M7366, an unlabelled card ? connected to the front panel, and M7364.  The M7366 has an 8085 < microprocessor.  The Field Guide knows not of these modules.  G Powering the unit while connected to a 9600bps console shows no output, I and no response to input.  An rs-232 checker connected to the DB-25 shows D the expected signals.  Altering the position of the keyswitch with aF paperclip (of course I don't have the matching key) shows no change in= function other than changing the front panel indicator lamps.   I Any ideas?  Minimal available information indicates that this is a remote G diagnostic port for a PDP-11.  I have an LSI-11/73, can the KBD01-AA do D any useful tricks?  Can I put other dual-height QBus modules in this cabinet?   --  C Alexander_R_Svirsky_____________________________atlas@world.std.com    ------------------------------  # Date: Sun, 10 Dec 2000 21:58:36 GMT % From: hg/jb <shsrms@bellatlantic.net> 3 Subject: Re: Digital KBD01-AA - What is this thing? . Message-ID: <3A33FC47.5FA347@bellatlantic.net>   Alexander R Svirsky wrote: > K > A Digital KBD01-AA has been kicking around my parts stash for nearly four L > years now since I paid $2 for it at MIT.  I thought I had gotten rid of itI > a long time ago until it showed up behind a box on a shelf.  Until this G > afternoon, it had never been opened or powered up.  The sticker still . > sealed the opening over the power connector. > J > It's a small steel cabinet about 4"H x 15"W x 14"L.  The front panel hasH > four positions selectable by keyswitch, Program, Local, Remote/Secure,H > Remote.  The rear has a DB-25 male connector, apparently RS-232, and a > DC-37 female connector.  > G > Opening the cabinet reveals what is apparently a mini-QBus with three I > dual-height slots occupied by, top to bottom, M7366, an unlabelled card A > connected to the front panel, and M7364.  The M7366 has an 8085 > > microprocessor.  The Field Guide knows not of these modules. > I > Powering the unit while connected to a 9600bps console shows no output, K > and no response to input.  An rs-232 checker connected to the DB-25 shows F > the expected signals.  Altering the position of the keyswitch with aH > paperclip (of course I don't have the matching key) shows no change in? > function other than changing the front panel indicator lamps.  > K > Any ideas?  Minimal available information indicates that this is a remote I > diagnostic port for a PDP-11.  I have an LSI-11/73, can the KBD01-AA do F > any useful tricks?  Can I put other dual-height QBus modules in this
 > cabinet? >  > --E > Alexander_R_Svirsky_____________________________atlas@world.std.com   @ From what you describe, it is a remote diagnosis capable box but0 I would only be speculating as to what it is....B K was designation for processor, BDO1, implies Boot, Diagnostic if4 I recall my translations that Dick Best taught me.../ Maybe a remote boot device for some system..... 
 just a guess.  bob    ------------------------------  % Date: Sun, 10 Dec 2000 18:18:53 -0500  From: Ray <lists@aik.tec.sc.us> + Subject: Re: Dismount/abort for tape drives - Message-ID: <3A340F5D.20EEA049@aik.tec.sc.us>   ( > P.S. The dismount/abort command had no, > effect, but I may have left something out.  I It is absurd that there is no way to force a dismount.  Yes, I know about Q reasons not to do it.  But, in this case, when you have to dismount immediately,  J the only way I know is to reboot.  (I've heard of the program you request,( but don't know where to find it either.)   Ray    ------------------------------    Date: 10 Dec 2000 20:47:16 +0100) From: maulis@ludens.elte.hu (Maulis Adam) 7 Subject: Re: Getting dump files from detached processes ! Message-ID: <tEMvo1xL75YS@ludens>   + In article <90jq79$sva$1@nnrp1.deja.com>, :    S. Hoffman writes:G >>   Watch the virtual memory and the process quotas -- ever-increasing ' >>   values would tend to imply a leak.   ! david_dawkins@my-deja.com writes: C > OK, the sysadmins eliminated this problem. Don't appear to be any  > quota leaks. >    [...]   & >  when we send the "crash" command itC > creates .DMP files beautifully. when it dies it produces nothing.   ; It seems for me isufficient fillm quota. (RUN/FILE_LIMIT=). B please check that sysgen parameter called CHANNELCNT large enough.  ; or possible insufficient DIOlm, ASTlm or (extrem situation) A enqlm quota. (The process has no enough resource to pruduce dump)   A I saw smilar when a buggy program eat all of the p0 and p1 space. > (Under VMS 6.2-1H3 and VIRTPAGECNT was large enough to do it.)     Regard,  Adam Maulis       ? in an extremly heavy used process situation, performance tipps: F Fillm must be less than CHANNELCNT -2 (why 2?? possible image rundown)# DIOlm must be greather than 3*Fillm ( Biolm must be greather or equal to Fillm" Enqlm must be greather than Fillim9 ASTlm must be greather than DIOlm + BIOlm + Enqlm + TQElm ; Bytelm must be greater than  256*Fillm + 6*DIOlm + 6 *BIOlm    ------------------------------  # Date: Mon, 11 Dec 2000 03:59:59 GMT * From: Alan E. Feldman <alan48@my-deja.com>% Subject: Re: INITIALIZE/MAXIMUM_FILES ) Message-ID: <911jft$f5i$1@nnrp1.deja.com>   0 In article <877l59lg8i.fsf@k9.prep.synonet.com>,/   Paul Repacholi <prep@prep.synonet.com> wrote: . > helbig@astro.rug.nl (Phillip Helbig) writes: > F > > In article <90t2v6$cjb$1@info.service.rug.nl>, helbig@astro.rug.nl > > (Phillip Helbig) writes: > > E > > Is there any way to get the values of /HEADERS and /MAXIMUM_FILES  withG > > which a disk was initialised?  There is MAXFILES in F$GETDVI, which C > > returns the default for my disk, which is probably what I used.  Why ? > > isn't there something similar to get the value of /HEADERS?  > B > Because it is not explicitly recorded anywhere. You MAY find theA > size from dumpimg the header and seeing the size of the extent, E > but you can't be sure that indexf.sys was not extended contiguously $ > before it created an extra extent. > 9 > I look at the header size in [0,0] and punt from there.   G Also, you don't *need* the initial value of /HEADERS. Just estimate the C largest number of file headers you'll ever need on that disk. Also, A according to what COMPAQ told me at my last job, the algoritm for A extension of INDEXF.SYS has been greatly improved. So even if you C grossly understimate the value for /HEADERS, you should stay out of B trouble, provided your version of VMS is recent enough or you have applied the relevant patch kit.  --F NOTE: If you wish to e-mail me, please do NOT use the deja address. ItE is broken. Instead, use one of the addresses below, removing the long  wrong part first. Thanks.    Disclaimer: JMHO Alan E. Feldman  &-)+ w: afeldman@gfigroup.ButItSaidItPrinted.com 5 h: alan48@dellnet.YouCantBelieveEverythingYouRead.com     & Sent via Deja.com http://www.deja.com/ Before you buy.    ------------------------------  % Date: Sun, 10 Dec 2000 14:53:31 -0500 , From: Howard S Shubs <hshubs@mindspring.com>+ Subject: Re: Kernel Overhead for Direct I/O > Message-ID: <hshubs-3B18DA.14533110122000@news.mindspring.com>  = In article <3A33C7F4.A66EF2FB@mmaz.com>, "Barry Treahy, Jr."   <treahy@mmaz.com> wrote:  K >Yes, but I cannot move to Alpha; its a legacy system, TDMS in particular,   >and now that CA  6 Why did you yank the older drives, on a legacy system? --   Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------  % Date: Sun, 10 Dec 2000 19:40:32 -0700 + From: "Barry Treahy, Jr." <treahy@mmaz.com> + Subject: Re: Kernel Overhead for Direct I/O ( Message-ID: <3A343EA0.9101D492@mmaz.com>   Howard S Shubs wrote:    > 8 > Why did you yank the older drives, on a legacy system?  M I couldn't get enough sustained I/O throughput.  The RZ's in the storageworks 8 could never give me more than 30 to 35 I/O's per second.   Barry    --  ? Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028    ------------------------------    Date: 10 Dec 2000 22:59:05 +0100) From: maulis@ludens.elte.hu (Maulis Adam) ( Subject: Re: New OpenVMS  Education site! Message-ID: <BbQu3cWHEktU@ludens>   [ In article <90lnn3$edl$1@info.service.rug.nl>, helbig@astro.rug.nl (Phillip Helbig) writes:  [...] J > Let's face it: the primary reason for the demise of VMS in some sectors F > was that bad marketing took VMS out of academia, and thus people in . > academia didn't get exposed to VMS and so a)  	 What? :-)   C At our university the software enginier - computer science students F have to learn a bit of VMS (almost dcl and some security); our centralC computer (more than 12 000 users) is an ES40 with VMS; we have some  very popular VMS course.  J You right, unfortunately we are the only one institution that educate VMS.    E > It looks like I'll be leaving academia soon, for financial reasons.   ? Yes, I worked a few years outside of university but I left the  ( "Business Market" for freedom reasons...     Good Luck:-)     Adam Maulis   - proud board member of Hungarian Decus Chapter + senior VMS system manager in our university  one of the our VMS teachers  and simply 27 years old.   ------------------------------  % Date: Sun, 10 Dec 2000 21:46:43 -0600 + From: "Main, Kerry" <Kerry.Main@compaq.com> % Subject: RE: One world, one processor N Message-ID: <910612C07BCAD1119AF40000F86AF0D805284AC7@kaoexc3.kao.cpqcorp.net>   Rob,  L I always find articles from this person and his many "P7/Merced/Itanium will8 dominate" the industry views to be quite "interesting".    LOL. :-)  - Here is a few quotes from him over the years:o4 <http://www8.zdnet.com/eweek/news/0715/19echip.html>L "Linley Gwennap, editor of The Microprocessor Report, in Sebastapol, Calif.,* said he expects to see samples of the chipK during the first half of 1998 at around 500MHz. PCs with the chip should bef2 available to the public late that year, he added."  J Oh, by the way - in case anyone did not notice, the article is dated "July 19, 1996 5:30 PM ET"   Here is another one:7 <http://news.cnet.com/news/0-1003-200-331956.html?tag=>iJ "If Merced slips another couple of quarters...this could lead Intel to notJ market Merced as a product but use it only as a development vehicle," saidG Linley Gwennap, publisher of Microprocessor Report, writing in the mostrK recent issue of the respected industry newsletter." [article date August 6,p 1998]o   :-)"  
 Kerry Main Senior Consultants Compaq Canada Inc. Professional Serviceso Voice: 613-592-4660d Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----@ From: young_r@eisner.decus.org [mailto:young_r@eisner.decus.org] Sent: December 8, 2000 1:56 PM To: Info-VAX@Mvb.Saic.Comr% Subject: Re: One world, one processorr    : In article <20001207210658.08136.00002406@ng-mi1.aol.com>,) dashw459@aol.comeatspam (Doug W.) writes:eK > The following quote was taken from an article ONE WORLD, ONE PROCESSOR byh/ > Linley Gwennap in the December LINUX JOURNAL.e > L > ..."Compaq, HP and SGI have slowed the pace of their architectures (Alpha,K > PA-RISC and MIPS, respectively) to the point that they have fallen behindl XeonE > in performance in many key applications.  This decline has caused a  downward' > spiral in the sales for RISC vendors.- > G >   As a result, HP and SGI have already announced they will eventuallymE > discontinue their RISC lines, and Compaq is likely to follow suit."  >  > L > I hope someone from Compaq replies to this article.  I think it would have af@ > good chance of being published in a future LINUX JOURNAL.         ? 	He misses the mark for several reasons.  The PA8700 rolls soonaD 	or has rolled.  When it does, it will be more than competitive withD 	Itanium so then the great hope is McKinley.  Also, HP is developingD 	the PA8900.  The transition to IA64 will be painful regardless evenC 	if it runs native binaries, the performance won't be 1:1 and therec isA 	the small matter of testing and verification.  Sadly, SGI boughtcD 	the Merced revolution hook, line and sinker.  They killed off their> 	high-end processor project Beast and are now limping along onD 	tweeks of the R12000 architecture.  Linley also overlooks the smallE 	fact that Tru64 marketshare is growing nicely and their year to yearg@ 	revs are up , not down as I am sure Terry could concur... also,+ 	Linley speakeath with "fork -  ed" tongue:e  * From: young_r@eisner.decus.org (Rob Young)6 Subject: Re: Measured ILP from EPIC Compilers on SPEC? Date: 03 Dec 2000 00:00:00 GMT Newsgroups: comp.arch   I In article <3A2973E4.D64ED92D@gmx.de>, Bernd Paysan <bernd.paysan@gmx.de>T writes :	 > Rob Young wrote:7 >>         Yes they have.  Half McKinley's performance.e > I > And "Uuh-ooh. We can't tell the SPEC numbers". Remember that Merced wassD > touted to be faster than anything else, and definitely faster thanI > Alpha. If they meant the time it's going to be replaced after delivery,lG > it's not a good sign ;-). In the meantime, the Pentium 4 is in a veryiF > good shape, and if Compaq and Samsung struggle a bit longer to get a? > real .18u shrink of the 21264 out, it might overtake it soon.S >     F         But if you read enough you would venture to guess the traderagG         writers and high paid? anal-ists must think we are collectivelylC         a bunch of half-wits or totally not paying attention.  LookuB         again at what Linley "Merced" Gwennap penned in another of1         his many odes to Merced .. in March 2000:n  / http://www.linleygroup.com/columns/itanium.htmlB  J We have increased our projections of the chips SPEC_base performance to 50 intiJ and 80 fp. We expect it to achieve 45,000 tpmC on the TPC-C benchmark in aJ four-processor system based on Intels 460GX chip set and Lion motherboard.L These scores should give Itanium performance leadership when it is released,K but its performance could be surpassed by Compaqs Alpha processors within aA matter of months.     I         Alpha will overtake it in a matter of months... perhaps.  Sheesh.f  B         But sadly, Linley must perform a climb down at the end of          October 2000:t  6 http://www.eetimes.com/story/pipeline/OEG20001025S0051  H Itanium will still make a splash in the server market. But I expect mostJ Itanium systems sold next year will be used for software development or inJ customer validation; volume deployment will occur only at a limited number of sites.    G This slow ramp is due in part to the long buying cycles common in large C servers. But dampening the excitement is that Itanium is simply notd
 deliveringL the standout performance expected of the first fundamentally new instruction set in nearly 20 years.t    D         But Linley, you just told us in March about outstanding SPECB         performance and great tpmC marks.  What happened?  Did the outstanding J         SPEC performance and tpmC performance evaporate or wasn't it ever C         really there?  Which is it?  You were shovelled a bunch of PJ         crapola and went and ran with it didn't you?  I guess credibility L         matters a smidgen so now you tell us:  "dampening the excitement is G         that Itanium is simply not delivering the standout performance e         expected."  >         Were you surprised?  If so, you might have been alone!  E         Guess the Merced hubbub is losing steam.  They could wish andMF         a want and attempt to market it all they want but many factorsE         are again' 'em.  Merced ain't dead.  It's just "mostly dead." L         But wait until McKinley!  Twice the performance of Merced!  Whatever         that is...   ---o  @ 	Just as importantly Linley leaves out Sun.  By leaving out Sun,? 	he is ignoring the best counterpoint to his very weak argumenti; 	(gosh, maybe he has a future as a Democratic Lawyer).  SuneC 	is growing leaps and bounds even today and their "somewhat" anemicnB 	performance hasn't hurt their stellar growth.  So why no slide inD 	Sun, Linley?  Might also want to consider Sun killed off an Itanium 	port/product.  ? 	And finally, Linley is taking advantage of the fact that spins A 	on 21264 are long delayed but they won't be delayed forever (noreC 	much longer).  When they ship, Alpha will firmly establish itself dA 	once again as world performance champ - bar none - and will nail8 downC 	even more HTPC bids and similar bids that require high performanceiB 	until IBM ships Power4 and things begin another round of wins for both r 	IBM and Compaq.  B 	Watch what Linley pens... way too many of his articles are little@ 	more than Intel marketing pieces.  It only becomes obvious whenA 	you read them about a year out and they still haven't born fruithA 	(read the entire http://www.linleygroup.com/columns/itanium.htmli 	for example).   				Rob    ------------------------------  + Date: Mon, 11 Dec 2000 07:06:38 +0100 (MET)/ From: system@physik.uni-bonn.def7 Subject: Re:TECO, and how to make meaningful line noiseh/ Message-ID: <00121107063857@physik.uni-bonn.de>_  > for example: http://www.finseth.com/~fin/craft/Appendix-D.html  	 good lucka   Peter1   ------------------------------  # Date: Mon, 11 Dec 2000 05:17:56 GMT:* From: Alan E. Feldman <alan48@my-deja.com>$ Subject: Re: Very weird DCL behavior) Message-ID: <911o22$ie0$1@nnrp1.deja.com>   ) In article <90ot4j$1ia$1@nnrp1.deja.com>,d-   Alan E. Feldman <alan48@my-deja.com> wrote:i7 > In article <heOX5.783$He.10598@wagner.videotron.net>,o >[...]  B Oops, I forgot an important detail. See the new comments below the quoted material.   >  > Use the "I got it!" method:. >hH > One way to do it with DCL would be to make a .COM file for each backupD > which contains only the BACKUP/NOREWIND command. Call them b1.com,E > b2.com, etc. Have each process do each backup thusly: Find the nextrF > bn.com (where n is 1,2,3, etc.) Rename it to bn.gotit. Run bn.gotit.F > You can then optionally rename bn.gotit to bn.done. Have one process( > (could be a batch job) for each drive. >l? > This way, you won't have to wait thru rewinds, you don't needrC > subprocesses, you don't need mailboxes, you don't need SYNCH, you  don'trG > need BASIC, and the backups will be distributed evenly (more or less)tF > among your drives/tapes, or at least according to your algorithm. InF > the morning, check if the jobs completed okay, and if so, rename theH > bn.done's (or bn.gotits) to bn.com's. (or instead of bn.com's, perhaps
 > bn.ready's)r >IF > The rename is to "allocate" that particular backup so that the otherH > processes don't try to run it. You'll have to write some DCL to run inF > a loop and check for the error from renaming a non-existent file and4 > then try to rename the next one, etc. For example: >  > -- >l	 > $ N = 0a	 > $_LOOP:e
 > $ N = N + 1B" > $ IF (N .GT. whatever) THEN EXIT > $ ON ERROR THEN GOTO _LOOP > $ RENAME B'N'.COM .GOTITH > $ ON SEVERE_ERROR THEN EXIT !Don't let *regular* errors stop the show. > $ @B'N'.GOTIToH > $! <resume your favorite error checking, e.g. ON WARNING THEN EXIT, or' > $! SET NOON, whatever is appropriate>  > $ RENAME B'N'.GOTIT .DONEi > $ GOTO _LOOP' >[...error checking comment omitted...]   # I should have said just a bit more:-  G Make one of the above command procedures for each tape drive, but add am> command like $ DEFINE TAPE_DRIVE MKAn: to each one (before theG @bn.gotit command, of course) where n is the value appropriate for eachd6 tape drive. Then, in each bn.com, write something like  E $ BACKUP disk:[*...]/SINCE=BACKUP TAPE_DRIVE:save-set-name.B/NOREWINDn  B plus any other qualifiers you require. This way, the tape drive isG determined by the LNM from the main job, the bn.com's can be run by any(H of the four jobs, and each will be run once according to your algorithm.  D Possibly-bad pun alert!: Programmers do it with Al Gore Rhythms. :-)0 (No endorsement, or anything else, is intended.)  H > There are other ways to do this. The general idea is to make a "singleB > source list" of BACKUP commands and have each process "allocate"# > or "mark" the next one and do it.h  D This rename method should be safe and reliable. Other variations are# left as an exercise for the reader.a   >a > >@ --F NOTE: If you wish to e-mail me, please do NOT use the deja address. ItE is broken. Instead, use one of the addresses below, removing the longa wrong part first. Thanks.D   Disclaimer: JMHO Alan E. Feldman  &-)+ w: afeldman@gfigroup.ButItSaidItPrinted.com 5 h: alan48@dellnet.YouCantBelieveEverythingYouRead.comg    & Sent via Deja.com http://www.deja.com/ Before you buy.n   ------------------------------  # Date: Sun, 10 Dec 2000 23:44:25 GMT / From: atlas@world.std.com (Alexander R Svirsky) * Subject: WTB: XL266 Alpha CPU daughtercard& Message-ID: <G5DLy1.5L0@world.std.com>  G Anyone know a reasonable source for an XL266 or XL233 CPU daughtercard?    -- xC Alexander_R_Svirsky_____________________________atlas@world.std.comb   ------------------------------    Date: 11 Dec 2000 01:02:05 +0100) From: maulis@ludens.elte.hu (Maulis Adam)r2 Subject: [FREEWARE] a nice replacement of SH DEV D! Message-ID: <FPA9jnx9DjM5@ludens>a   Hello,  - I glad to inform you about my 'new' freeware.a  ) The kit is avaiable with anonymous ftp at-  + ftp://ludens.elte.hu/vms/freeware/shdev.zip0  8 (Of course I can also post here all of the 110 lines :-)     Here is the freeware_readme:    d SHDEV.COM, SYSTEM_MANAGEMENT, A DCL ``programlet'' that provides a nice brief display of disk usage.      ! Installation and user's guidelet:e  	AAAREADME.TXT (English version)  ?         A DCL ``programlet'' that provides a nice brief display.C         of disk usage. (type, label, free blocks, percent of usage)t?         The major advantage is processing of shadow sets and/oriE         volumesets: displays only one line for each shadow/volumesetsh-         with count of total free/used blocks.h    1    Author:	Maulis, Adam	( maulis@ludens.elte.hu )h  3    Copyright:	GNU General Public License version 2.s         Regards, Adam Maulis    ------------------------------   End of INFO-VAX 2000.690 ************************