1 INFO-VAX	Mon, 20 Feb 2006	Volume 2006 : Issue 101       Contents:" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX"" Re: "A Historical Look at the VAX" Re: 4000 vlc motherboardP Re: A gripe just posted to HP's VMS ITRC forum (for those with a foot in both caH Re: How to copy the top level of a website to get rid of Javascript etc?H Re: How to copy the top level of a website to get rid of Javascript etc?H Re: How to copy the top level of a website to get rid of Javascript etc?P Re: How to copy the top level of a website to get rid of Javascript etc? Javascr7 Re: KZPEA in ES45 with serial console only -- run bios? 6 Re: LD devices in shadowsets on fault tolerant cluster6 Re: LD devices in shadowsets on fault tolerant cluster More VMS & DCL wish list items" RE: More VMS & DCL wish list items Re: Mosaic v3.9 compile 4 Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering4 Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering4 Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering4 Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering  F ----------------------------------------------------------------------  % Date: Sun, 19 Feb 2006 13:49:54 -0500 ' From: Dave Froble <davef@tsoft-inc.com> + Subject: Re: "A Historical Look at the VAX" 9 Message-ID: <NZKdnQq7YMzoIGXenZ2dnUVZ_tqdnZ2d@libcom.com>    Neil Rieck wrote:   J > p.s. I loved VAX as much as the next guy but when you see a replacement M > technology emerge with 10 times more power, at one-tenth the price, you've  & > got to give yourself a realty check.  E The same technology could have been used to produce VAX CPUs with 10  H times more power.  Don't know about 1/10 the price, since that's due to  volume.    --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Sun, 19 Feb 2006 15:15:37 -0500 ( From: Bill Todd <billtodd@metrocast.net>+ Subject: Re: "A Historical Look at the VAX" = Message-ID: <1N6dnaMde5txTGXeRVn-hg@metrocastcablevision.com>    Dave Froble wrote: > Neil Rieck wrote:  > ? >> p.s. I loved VAX as much as the next guy but when you see a  H >> replacement technology emerge with 10 times more power, at one-tenth 9 >> the price, you've got to give yourself a realty check.  > G > The same technology could have been used to produce VAX CPUs with 10   > times more power.   G People whose knowledge in that area may be close to infinitely greater  E than yours would disagree.  First, of course, the DEC architects who  I decided in the first place that the VAX architecture, even if widened to  I 64 bits, could not be extended to address the needs of more than another  D decade or so; second, people like John Mashey (formerly of SGI), an F unabashed admirer of DEC, Alpha, and even VAX, who at least partially I explained why in comp.arch a while ago (from part of which the cited RWT  I article was created):  the instruction set of even a two-address machine  E like the PDP-11 is significantly more complex than IA32, and the VAX  I instruction set makes IA32 look so svelte as to be almost RISC-like - so  H what was done to speed up IA32 would not have come close to speeding up  VAX to any similar degree.  F Just a reality-check:  myths like yours tend to exhibit unconstrained   growth if not subjected to them.   - bill   ------------------------------  % Date: Sun, 19 Feb 2006 16:24:14 -0500 , From: "Richard Tomkins" <tomkinsr@istop.com>+ Subject: Re: "A Historical Look at the VAX" = Message-ID: <43f8e31e$0$27800$6d36acad@titian.nntpserver.com>    Interesting article.  J The last VAX in fact shipped out in 2000, from Kanata, Custom Systems, not 1992 as the article says. 0 I worked for Custom Systems from 1998 till 2001.  D The VAX architecture was originally designed to run Cobol. The CobolG compiler produced VAX instruction ocde directly. Further, one could add J instructions to the system dynamically by writing their own microcode. theG 11/780 and 11/750 and other models supported loading microcode from the ? console, in the case of the 11/750, this was a small TU58 tape.   B Digital did make chips in our own Fab's. we also developed the FabJ Technology for making chips which we sold to other firms such as Intel andH IBM. We were typically one to two years ahead of the competition in CMOS design.   G Digital had extremely knowledgeable staff all over the world. In Kanata I there was a small group of guys that had a little design lab and they did J special chip designs for disk drives. When Quantum purchased the business,K they told these folks that they'd be moving or leaving if they didn't go to L California. They in turn told Quantum to suck eggs and they were staying putK in Ottawa. Quantum, realizing the these guys were the finest in their field L and that they were the secret to reliable disk drive data kept them employedL in Ottawa, for years they just stayed in the Digital Kanata facility rentingI space and then after Compaq bought Digital, they acquired their own space I and moved and continued to design and work here until the last two years, H Anyone ever used a DLT? Ever found a better or more reliable technology? Nope, didn't think so.  L The major problem I find with the article in question is that it is based onG thoughts and principles that people in the know feel are the norm. This I applies probably well to firms like Dell, and Compaq, and maybe even Sun, $ but the rules never did fit Digital.  L Why did Digital build so many different products in so many countries around the world? We didn't have to.   H We designed and built chips, modules, metal and plastic enclosures, tapeK drives, media, disk drives, magnetic heads for disks and tape drives, chips L for all these storage systems, printers, stepper motors, wiring, connectors,H Kanata was the connector foundry for Digital, backplanes and we designedK some pretty impressive backplanes in Kanata, PDP-8 to VAX 9000 High Density E Interconnect, terminals, specialized stuff still in use in sconce and H technology labs all over the world, Fault Tolerant VAX systems, a simpleI little chip to do that, Operating Systems, Compilers, and Applications of 
 all kinds.  J Why did we do all this and more. We did it because we could. We had peopleL and we had technology. Think about it for a moment. We had the capability toG take an order from a customer for a complete system. CPU, Disks, Tapes, L Terminals, Printers, Interfaces, Cables and all the other stuff that makes aL system. We could put that order into our management systems and all over theF world the buyers would go into action, purchasing the raw materials weH needed to build everything in that order, scheduling parts and componentJ builds around the world in our facilities and that of our vendors and thenH getting it all put together in all of our plants and then getting it allI shipped to the customer site on the day of delivery and installing it and J putting all together and making it run. As we built in all those differentL countries and we purchased materials locally we had the capability to handleG all the different currencies, the exchange rates, the duty drawbacks on L material content, and if anyone reading this know anything at all about partK numbers and material management you know how complex all this is and we did K it, every single day. Bob Palmer didn't get it, He never understood that we H did this because we could. We had the highest level of sophistication inK manufacturing systems world wide bar none. Add to the fact that we were ISO L 9000 compliant worldwide. We could issue an ECO for a component, a product a? system and have it incorporated in that build around the world.   K When Compaq bought the firm, they changed all this. They started purchasing K manufactured sub-assemblies form outside vendors. A lot of industry pundits J will tell you that this is cheaper than the way we did it. They are wrong.K But when you negotiate  a contract for 10,000 widgets, you do so at a fixed K price and delivery time. You put the cost of warehousing on your vendor and J he sucks up all the risk of inventory management and costs with that untilK the point where the contract pays him out for delivery. Compaq then brought K almost all of their manufacturing back into a single site, because they did G not have systems that could manage distributed manufacturing around the I world. That is the manufacturing model used today, because, possibly with H the exception of IBM, no one else in the world has the requisite systemsC capable of such large international project management that we had.   H So, as far as the article is concerned, sorry, we ran by different rulesI than the rest of the industry so an analysis of the designs and decisions G made by Digital in what they did and why must be made in the context of D understanding the business model of Digital which as I have tried toF demonstrate was quite different from that of the rest of the industry.  8 "Chip Coldwell" <coldwell@gmail.nospam> wrote in message; news:Pine.LNX.4.61.0602190713540.17424@frank.harvard.edu...  > A > http://www.realworldtech.com/page.cfm?ArticleID=RWT012406203308  >  > --   > Charles M. "Chip" Coldwell > "Turn on, log in, tune out"  >     . *** Free account sponsored by SecureIX.com ***X *** Encrypt your Internet usage with a free VPN account from http://www.SecureIX.com ***   ------------------------------  % Date: Sun, 19 Feb 2006 16:52:51 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> + Subject: Re: "A Historical Look at the VAX" , Message-ID: <43F8E8B1.DF8E8491@teksavvy.com>   Chip Coldwell wrote: > A > http://www.realworldtech.com/page.cfm?ArticleID=RWT012406203308   J Thanks for the pointer. Glad to see Sue's name in there as a contributor !  E There is one very important message here:  Intel can justify spending F huge amounts of money for the high volume 8086, but one canbnot affordG to spend the same amounts for a low volume chip unless you are a system C maker and can subsidize the high cost of the chip with other stuff.    ------------------------------  % Date: Sun, 19 Feb 2006 17:22:49 -0500 ( From: Bill Todd <billtodd@metrocast.net>+ Subject: Re: "A Historical Look at the VAX" = Message-ID: <LaadnVscIbogcmXe4p2dnA@metrocastcablevision.com>    Richard Tomkins wrote:   ...   < > The VAX architecture was originally designed to run Cobol.  I That statement is so laughably misleading that I just can't let it stand   without comment.  E Without question VAX was designed to run COBOL well, but pretty much  E just as it was designed to run other languages (e.g., Fortran) well.  F So-called 'commercial instructions' such as decimal arithmetic, which F had (at least early-on) been optional on the PDP-11, were standard on I VAX, but that represents more making COBOL an equal with other languages  > in terms of hardware support than giving it any real priority.     The Cobol 2 > compiler produced VAX instruction ocde directly.  G Just as most other DEC compilers of that era did.  The common back-end  E came a bit later, IIRC as part of Cutler's PL/1 compiler development.      Further, one could addH > instructions to the system dynamically by writing their own microcode.  A A technique borrowed from (or perhaps shared with:  the two were  H somewhat contemporary) the PDP-11/60, IIRC.  And hardly COBOL-specific: H   most such use went to specialized (often scientific) applications (or C to hacks:  ISTR that Richie Lary used it to turn an 11/60 into the   world's fastest PDP-8).    ...   N > The major problem I find with the article in question is that it is based onI > thoughts and principles that people in the know feel are the norm. This K > applies probably well to firms like Dell, and Compaq, and maybe even Sun, & > but the rules never did fit Digital.  B Horseshit.  While DEC beyond doubt enjoyed many relatively unique G attributes at least through the late '80s, simple economics applied to  D DEC as much as it did to anyone else.  Perhaps you need to read the  article again, more carefully.   - bill   ------------------------------  % Date: Sun, 19 Feb 2006 17:43:38 -0500 ' From: Dave Froble <davef@tsoft-inc.com> + Subject: Re: "A Historical Look at the VAX" / Message-ID: <1YydndoPrL7SaWXeRVn-vA@libcom.com>    Bill Todd wrote: > Dave Froble wrote: >  >> Neil Rieck wrote: >>@ >>> p.s. I loved VAX as much as the next guy but when you see a I >>> replacement technology emerge with 10 times more power, at one-tenth  : >>> the price, you've got to give yourself a realty check. >> >>H >> The same technology could have been used to produce VAX CPUs with 10  >> times more power. >  > I > People whose knowledge in that area may be close to infinitely greater  G > than yours would disagree.  First, of course, the DEC architects who  K > decided in the first place that the VAX architecture, even if widened to  K > 64 bits, could not be extended to address the needs of more than another  F > decade or so; second, people like John Mashey (formerly of SGI), an H > unabashed admirer of DEC, Alpha, and even VAX, who at least partially K > explained why in comp.arch a while ago (from part of which the cited RWT  K > article was created):  the instruction set of even a two-address machine  G > like the PDP-11 is significantly more complex than IA32, and the VAX  K > instruction set makes IA32 look so svelte as to be almost RISC-like - so  J > what was done to speed up IA32 would not have come close to speeding up  > VAX to any similar degree. > H > Just a reality-check:  myths like yours tend to exhibit unconstrained " > growth if not subjected to them. >  > - bill  D Look at the numbers Bill.  Do you think that CPUs today are only 10 F times faster than the best VAX?  Me thinks you'd need another decimal G place.  10 times a VAX still would be rather slow today.  With process  G shrinks and a few more enhancements even the VAX architecture could be  F speeded up that much.  The maximum clock speed (which is far from the 3 whole picture) the N-VAX ran at was around 100 MHz.   D I guess I could have added that little bit, so as not to get anyone E thinking that the VAX could have remained competitive.  You're right   about that.    --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Sun, 19 Feb 2006 17:36:18 -0500 ) From: "Neil Rieck" <n.rieck@sympatico.ca> + Subject: Re: "A Historical Look at the VAX" 8 Message-ID: <up6Kf.2982$%14.80715@news20.bellglobal.com>  6 "Bill Todd" <billtodd@metrocast.net> wrote in message 7 news:1N6dnaMde5txTGXeRVn-hg@metrocastcablevision.com...  > Dave Froble wrote: >> Neil Rieck wrote: >>L >>> p.s. I loved VAX as much as the next guy but when you see a replacement H >>> technology emerge with 10 times more power, at one-tenth the price, / >>> you've got to give yourself a realty check.  >>H >> The same technology could have been used to produce VAX CPUs with 10  >> times more power. > I > People whose knowledge in that area may be close to infinitely greater  G > than yours would disagree.  First, of course, the DEC architects who  K > decided in the first place that the VAX architecture, even if widened to  K > 64 bits, could not be extended to address the needs of more than another  F > decade or so; second, people like John Mashey (formerly of SGI), an H > unabashed admirer of DEC, Alpha, and even VAX, who at least partially K > explained why in comp.arch a while ago (from part of which the cited RWT  K > article was created):  the instruction set of even a two-address machine  G > like the PDP-11 is significantly more complex than IA32, and the VAX  K > instruction set makes IA32 look so svelte as to be almost RISC-like - so  J > what was done to speed up IA32 would not have come close to speeding up  > VAX to any similar degree. > H > Just a reality-check:  myths like yours tend to exhibit unconstrained " > growth if not subjected to them. >  > - bill  L I agree that IA32 technology is mostly junk (compared to VAX and ALPHA) but I the RWT article does contain some valid points about economies of volume.   J I'm not sure what you mean by "myth" though. When I moved my own programs L from a used VAX-6430 to a used AS-4100 the apparent speed up of my apps was M approximately "times 10". (Even faster on a DS20e). Back in 1992 my employer  J purchased a dual hosted uVAX-4300 with 4 expansion cabinets containing 24 J hard drives. This system cost us $1.2 Million. Exactly ten years later we H purchased a brand new AS-DS20e (two CPUs with 24 drives connected to an ! HZ22) and this system cost $110K.   E When system speed increases by an order of magnitude while the price  L decreases by an order of magnitude, people usually take notice. The problem J with Alpha sales (at least in Canada) is that DEC and Compaq never really F got this information out to the masses. We'll have to see how HP does.  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.9 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html     ------------------------------  % Date: Sun, 19 Feb 2006 17:45:05 -0500 ) From: "Neil Rieck" <n.rieck@sympatico.ca> + Subject: Re: "A Historical Look at the VAX" 8 Message-ID: <Fx6Kf.2988$%14.82056@news20.bellglobal.com>  8 "Richard Tomkins" <tomkinsr@istop.com> wrote in message 7 news:43f8e31e$0$27800$6d36acad@titian.nntpserver.com...  > Interesting article. > L > The last VAX in fact shipped out in 2000, from Kanata, Custom Systems, not > 1992 as the article says. 2 > I worked for Custom Systems from 1998 till 2001. > F > The VAX architecture was originally designed to run Cobol. The CobolI > compiler produced VAX instruction ocde directly. Further, one could add L > instructions to the system dynamically by writing their own microcode. theI > 11/780 and 11/750 and other models supported loading microcode from the A > console, in the case of the 11/750, this was a small TU58 tape.  > I This brings back old memories. I remember standing in one of the labs in  G Kanata (1984?) watching a DEC technician attempting to diagnose a very  H unusual 11/780 problem. So he wrote, then ran, some custom microcode to H generate signals which he code then scope throughout the CPU. Very cool  times.  A On a related note, wasn't support for Indexed-RMS built into VMS  M specifically to support COBOL? (If memory serves, it was an optional layered   product in earlier OSs)   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.9 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html     ------------------------------  % Date: Sun, 19 Feb 2006 16:32:06 -0700 % From: Dan O'Reilly <dano@process.com> + Subject: Re: "A Historical Look at the VAX" A Message-ID: <6.1.2.0.2.20060219163058.025d1ec0@raptor.psccos.com>   ( At 03:45 PM 2/19/2006, Neil Rieck wrote:  8 >"Richard Tomkins" <tomkinsr@istop.com> wrote in message8 >news:43f8e31e$0$27800$6d36acad@titian.nntpserver.com... > > Interesting article. > > N > > The last VAX in fact shipped out in 2000, from Kanata, Custom Systems, not > > 1992 as the article says. 4 > > I worked for Custom Systems from 1998 till 2001. > > H > > The VAX architecture was originally designed to run Cobol. The CobolK > > compiler produced VAX instruction ocde directly. Further, one could add N > > instructions to the system dynamically by writing their own microcode. theK > > 11/780 and 11/750 and other models supported loading microcode from the C > > console, in the case of the 11/750, this was a small TU58 tape.  > > I >This brings back old memories. I remember standing in one of the labs in G >Kanata (1984?) watching a DEC technician attempting to diagnose a very H >unusual 11/780 problem. So he wrote, then ran, some custom microcode toH >generate signals which he code then scope throughout the CPU. Very cool >times.  > A >On a related note, wasn't support for Indexed-RMS built into VMS M >specifically to support COBOL? (If memory serves, it was an optional layered  >product in earlier OSs)  L If memory also serves, the original VAX 8600 microcode had a flaw in it, in H that it was missing what was considered to be a very obscure addressing L mode of some sort (I never did find out the details).  Turned out the COBOL / compiler generated code using it extensively...    ------J +-------------------------------+----------------------------------------+J | Dan O'Reilly                  |  "There are 10 types of people in this |J | Principal Engineer            |   world: those who understand binary   |J | Process Software              |   and those who don't."                |J | http://www.process.com        |                                        |J +-------------------------------+----------------------------------------+   ------------------------------  % Date: Sun, 19 Feb 2006 18:47:21 -0500 ( From: Bill Todd <billtodd@metrocast.net>+ Subject: Re: "A Historical Look at the VAX" = Message-ID: <A8CdnccJzN0RnmTeRVn-rg@metrocastcablevision.com>    Neil Rieck wrote: 8 > "Bill Todd" <billtodd@metrocast.net> wrote in message 9 > news:1N6dnaMde5txTGXeRVn-hg@metrocastcablevision.com...  >> Dave Froble wrote:  >>> Neil Rieck wrote:  >>> M >>>> p.s. I loved VAX as much as the next guy but when you see a replacement  I >>>> technology emerge with 10 times more power, at one-tenth the price,  0 >>>> you've got to give yourself a realty check.I >>> The same technology could have been used to produce VAX CPUs with 10   >>> times more power. J >> People whose knowledge in that area may be close to infinitely greater H >> than yours would disagree.  First, of course, the DEC architects who L >> decided in the first place that the VAX architecture, even if widened to L >> 64 bits, could not be extended to address the needs of more than another G >> decade or so; second, people like John Mashey (formerly of SGI), an  I >> unabashed admirer of DEC, Alpha, and even VAX, who at least partially  L >> explained why in comp.arch a while ago (from part of which the cited RWT L >> article was created):  the instruction set of even a two-address machine H >> like the PDP-11 is significantly more complex than IA32, and the VAX L >> instruction set makes IA32 look so svelte as to be almost RISC-like - so K >> what was done to speed up IA32 would not have come close to speeding up   >> VAX to any similar degree.  >>I >> Just a reality-check:  myths like yours tend to exhibit unconstrained  # >> growth if not subjected to them.  >>	 >> - bill  > I > I agree that IA32 technology is mostly junk (compared to VAX and ALPHA)   H Then you appear to be agreeing with a sentiment which was not expressed # in the post to which you responded.    ...   . > I'm not sure what you mean by "myth" though.  F Your following comments strongly suggest that this is because you did C not understand what I was saying (or even that I was responding to  " Dave's post rather than to yours).   - bill   ------------------------------  % Date: Sun, 19 Feb 2006 18:56:13 -0500 ( From: Bill Todd <billtodd@metrocast.net>+ Subject: Re: "A Historical Look at the VAX" = Message-ID: <2Pidnf7QOZc9mGTeRVn-sg@metrocastcablevision.com>    Dave Froble wrote: > Bill Todd wrote: >> Dave Froble wrote:  >> >>> Neil Rieck wrote:  >>> A >>>> p.s. I loved VAX as much as the next guy but when you see a  J >>>> replacement technology emerge with 10 times more power, at one-tenth ; >>>> the price, you've got to give yourself a realty check.  >>>  >>> I >>> The same technology could have been used to produce VAX CPUs with 10   >>> times more power.  >> >>J >> People whose knowledge in that area may be close to infinitely greater H >> than yours would disagree.  First, of course, the DEC architects who I >> decided in the first place that the VAX architecture, even if widened  G >> to 64 bits, could not be extended to address the needs of more than  F >> another decade or so; second, people like John Mashey (formerly of H >> SGI), an unabashed admirer of DEC, Alpha, and even VAX, who at least H >> partially explained why in comp.arch a while ago (from part of which F >> the cited RWT article was created):  the instruction set of even a J >> two-address machine like the PDP-11 is significantly more complex than H >> IA32, and the VAX instruction set makes IA32 look so svelte as to be G >> almost RISC-like - so what was done to speed up IA32 would not have  7 >> come close to speeding up VAX to any similar degree.  >>I >> Just a reality-check:  myths like yours tend to exhibit unconstrained  # >> growth if not subjected to them.  >>	 >> - bill  > F > Look at the numbers Bill.  Do you think that CPUs today are only 10 ! > times faster than the best VAX?   I Do you think that Alphas today are only 10x faster than the fastest VAX?  F   Neil's comment appeared to me to be referring to the speed of VAXen G compared with the Alphas that were *contemporary* with them:  while it  E may have been a bit of an exaggeration, that's the spirit in which I  " took it, and in which I responded.   ...       With process I > shrinks and a few more enhancements even the VAX architecture could be   > speeded up that much.   D But the process shrinks sped up the competition just as much.  'The B technology' that made the *real* difference between VAX and Alpha H performance in comparable processes was not nearly as transferable, and  that was my point.   - bill   ------------------------------  % Date: Sun, 19 Feb 2006 19:17:07 -0500 ( From: Bill Todd <billtodd@metrocast.net>+ Subject: Re: "A Historical Look at the VAX" G Message-ID: <xJadnQK7Qq8bl2TenZ2dnUVZ_v-dnZ2d@metrocastcablevision.com>    Neil Rieck wrote:    ...   /   wasn't support for Indexed-RMS built into VMS   > specifically to support COBOL?  F No:  while native support for RMS indexed files did not ship with VMS A V1.0 (RMS-11 indexed support in compatibility mode was used as a  E substitute), that was only because it could not be completed in time.   /   (If memory serves, it was an optional layered  > product in earlier OSs)   I I'm pretty sure that indexed-file support was standard across all RMS-11  I releases (though the RMS emulator developed much later for RT-11 may not  ; have included it).  I do know that by the time I wrote the  L memory-resident library implementations it was included in them as standard.  F But I'm less sure about RMS-20:  where's Seth Cohen when you need him B (perhaps a visit to trailing-edge could turn up that information)?  G RMS was designed by Ed Marison, who had previously worked with indexed  E file support for MUMPS - and that's where a great deal of the design  H came from (though majorly altered).  Without indexed files, there would B have been relatively little need for anything beyond what already F existed in FCS-11 (and DATATRIEVE - which turned out to be one of the E most prolific users of RMS indexed files - might never have existed).   G The part of RMS indexed files (everywhere, not just on VMS) that *was*  H specifically tailored for COBOL semantics was the order-preservation of H duplicate key values in alternate indexes (and possibly alternate index D support as a whole, since most other uses did not require multi-key G capability).  Then again, competition with DG's INFOS and Prime's KSAM  G was considered important at the time, and just another single-key ISAM  C might not have been considered adequate even without the desire to  ( support COBOL alternate-index semantics.   - bill   ------------------------------  % Date: Sun, 19 Feb 2006 19:32:41 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> + Subject: Re: "A Historical Look at the VAX" , Message-ID: <43F90E1B.EFFFCDD1@teksavvy.com>   Bill Todd wrote:H > capability).  Then again, competition with DG's INFOS and Prime's KSAMH > was considered important at the time, and just another single-key ISAMD > might not have been considered adequate even without the desire to* > support COBOL alternate-index semantics.  F DG cames along much later. The real competition was IBM's VSAM. It was" the one with multiple indexes etc.  F I've had the misfortune to work with DG's attempt at indexed files. ItB was rather pathetic and certaintly not something ready for missionH critical applications. Power failure would require you rebuild the filesA (yes, an indexed file was stored on multiple physical files). You & couldn't type a indexed files etc etc.   ------------------------------  % Date: Sun, 19 Feb 2006 19:48:04 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> + Subject: Re: "A Historical Look at the VAX" , Message-ID: <43F911B4.56415D2C@teksavvy.com>   A question:   B Much has been said about the VAX's inability to scale up in speed.  C While I understand that fancy chip logic such as pipelining, branch F prediction etc is made much harder with variable length instructions, F wouldn't raw clock speeds be more dependant on the FAB process than on the instruction formats ?   H When looking at the 8086 in the 1990s, how much of its added performanceG came from just process shrinks and higher clock speeds versus improving A the actual architecture implementation to require fewer cycles to  execute instructions ?  E Based on HP's web site, there are a number of VAXes whose TPM exceeds  that of early Alpha models.   E I don,t think that one would ever debate that Alpha, having a sleeker H instruction set, had greater potential than VAX. But i am wondering justH how fast DEC could have made VAX if it had decided to stick with VAX. InE the end, being superior is what killed Alpha because Intel desperatly A wanted it dead so its own failed chip woudln't look so bad. SPARC M managed to stay under the radar because it isn't seen as a threath to anyone.   F One must also keep in mind something very important: Alpha came to theH market at a time when Palmer started its slash and burn policies. So oneH cannot really judge Alpha's true potential in the marketplace because it was never leveraged.  H Same with DEC's FAB which Palmer refused to allow to be used to capacity+ by selling FAB services to folks like AMD.    G Look at DEC's disk drive business which was doing well. Had DEC kept it D though, DLT would have never become an industry standard because DECG would have not taken the stapes to make it available to many companies.   D And in hindsight, look at what DEC *could* have done during the .COMC period with its networking products. It *could* have become a majro H player being in the game with experienced and probably able to become #2E after Cisco. (But of course, DEC's management wouldn't have made that B happen with their policies, it would have taken smart management).   ------------------------------  % Date: Sun, 19 Feb 2006 18:14:20 -0700 % From: Dan O'Reilly <dano@process.com> + Subject: Re: "A Historical Look at the VAX" A Message-ID: <6.1.2.0.2.20060219181236.025a12e0@raptor.psccos.com>   & At 05:48 PM 2/19/2006, JF Mezei wrote: >A question: > C >Much has been said about the VAX's inability to scale up in speed.  > D >While I understand that fancy chip logic such as pipelining, branchF >prediction etc is made much harder with variable length instructions,G >wouldn't raw clock speeds be more dependant on the FAB process than on  >the instruction formats ?  = One of the big problems with the VAX was the instruction set  I itself.  Instructions are variable length, which makes it much harder to  > pipeline (among other things) than a system with fixed-length H instructions.  It was a very powerful and rich instruction set, but all  that came at a price.    ------J +-------------------------------+----------------------------------------+J | Dan O'Reilly                  |  "There are 10 types of people in this |J | Principal Engineer            |   world: those who understand binary   |J | Process Software              |   and those who don't."                |J | http://www.process.com        |                                        |J +-------------------------------+----------------------------------------+   ------------------------------  % Date: Sun, 19 Feb 2006 20:31:04 -0500 ( From: Bill Todd <billtodd@metrocast.net>+ Subject: Re: "A Historical Look at the VAX" G Message-ID: <jO-dnbi9QvJBhmTenZ2dnUVZ_sadnZ2d@metrocastcablevision.com>    JF Mezei wrote:  > Bill Todd wrote:I >> capability).  Then again, competition with DG's INFOS and Prime's KSAM I >> was considered important at the time, and just another single-key ISAM E >> might not have been considered adequate even without the desire to + >> support COBOL alternate-index semantics.  >  > DG cames along much later.  D Please try not to correct people who know a great deal more about a L subject than you do:  it just annoys them, and makes you look like an idiot.  C INFOS was developed for the 16-bit DG Nova, and (unlike RMS on the  ? PDP-11) ran as part of the kernel.  This made it more flexibly  > packageable in some ways, less so in others - but it had some $ interesting features that I admired.  -   The real competition was IBM's VSAM. It was $ > the one with multiple indexes etc.  H Right:  the PDP-11 was competing tooth and nail with IBM's VSAM systems.   > H > I've had the misfortune to work with DG's attempt at indexed files. ItD > was rather pathetic and certaintly not something ready for missionJ > critical applications. Power failure would require you rebuild the filesC > (yes, an indexed file was stored on multiple physical files). You ( > couldn't type a indexed files etc etc.  @ I can't speak to the quality of the implementation, only to its 5 existence and some interesting aspects of its design.    - bill   ------------------------------  % Date: Sun, 19 Feb 2006 21:07:19 -0500 ( From: Bill Todd <billtodd@metrocast.net>+ Subject: Re: "A Historical Look at the VAX" = Message-ID: <osydnUsitKrGuWTeRVn-gA@metrocastcablevision.com>    JF Mezei wrote: 
 > A question:  > D > Much has been said about the VAX's inability to scale up in speed. > E > While I understand that fancy chip logic such as pipelining, branch H > prediction etc is made much harder with variable length instructions, H > wouldn't raw clock speeds be more dependant on the FAB process than on > the instruction formats ?   H No:  they interact.  When you have to do something complex (like handle H instructions with complex interactions, rather than RISC instructions), C you can't break up a pipeline into arbitrarily fine stages - i.e.,  G you're stuck with some stages that are intrinsically messier than they  F are in a RISC implementation, and hence can't sustain as fast a clock = when running in the same process.  A great deal of the Alpha  D architecture was specifically aimed at *avoiding* instructions that F would slow down any pipeline stage, whereas the VAX architecture gave G virtually no thought whatsoever to this (instead, it had been designed  $ to facilitate compiler development).  F And even if you could increase the fineness of the pipeline stages to G compensate, the fact that there would then be a lot *more* stages than  H in the RISC equivalent would mean that you'd get less throughput in the K same process (not to mention a great deal more power consumption and heat).    > J > When looking at the 8086 in the 1990s, how much of its added performanceI > came from just process shrinks and higher clock speeds versus improving C > the actual architecture implementation to require fewer cycles to  > execute instructions ?  G When you look at that decade's worth of process development, virtually  D *no* single enhancement (or even set of enhancements) can equal the H increase you got from process improvements.  (This may not be true now, @ though, since physical limits involving things like leakage and @ heat-generation per unit area have started to put the brakes on E single-core performance improvements resulting from process shrinks.)   E However, a very significant portion of x86's performance improvement  ; during the 1990s came when Pentium went to an out-of-order  I implementation - which not coincidentally is the point where it overtook  E Alpha in SPECint performance.  And IIRC an earlier major improvement  C came when both Intel and AMD (I forget which came first - or AMD's  E implementation may have come from NextGen) cracked IA32 instructions   into simpler internal formats.   > G > Based on HP's web site, there are a number of VAXes whose TPM exceeds  > that of early Alpha models.   I Because VAXes had become as fast as they'd ever get well before any even  * moderately high-end Alpha systems existed.   > G > I don,t think that one would ever debate that Alpha, having a sleeker J > instruction set, had greater potential than VAX. But i am wondering justG > how fast DEC could have made VAX if it had decided to stick with VAX.   E Not fast enough, and not soon enough.  The very bright and competent  C people who designed PRISM and Alpha didn't do so just because they  I *wanted* to do something different:  they abandoned the VAX architecture  C with great reluctance because they *had* to do something different.   E VAX certainly could have ridden process advances as well as anything  G else did, but it was far behind RISC (and even x86) on the performance  F (let alone price/performance) curve and thus would have remained so - A even farther behind x86 as x86 underwent the innovative internal  D transformations that the more complex VAX instruction set could not C match (even had DEC had the money to invest in the effort that x86  ! volumes allowed Intel to invest).      InH > the end, being superior is what killed Alpha  because Intel desperatly= > wanted it dead so its own failed chip woudln't look so bad.   C Horseshit.  Intel almost certainly never considered Alpha a threat  H because it was so abundantly clear that Compaq (at least post Pfeiffer) G had no interest whatsoever in *making* it a threat.  What killed Alpha  I was Compaq's complete lack of interest in being a processor manufacturer  D (or even a processor designer, considering that fabbing was already G being farmed out to Intel and IBM) - plus, at the end, the fact that a  K merger with HP would have been difficult had Alpha still been a competitor.   C Whatever Intel paid Compaq was face-saving pocket change:  Curly's  H decision to kill Alpha had been germinating for two years at that point.   ...   H > One must also keep in mind something very important: Alpha came to theJ > market at a time when Palmer started its slash and burn policies. So oneJ > cannot really judge Alpha's true potential in the marketplace because it > was never leveraged.  + No shit, Sherlock.  This you consider news?    - bill   ------------------------------  % Date: Sun, 19 Feb 2006 21:32:05 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> + Subject: Re: "A Historical Look at the VAX" , Message-ID: <43F92A0F.4E8B6320@teksavvy.com>   Bill Todd wrote:J > Right:  the PDP-11 was competing tooth and nail with IBM's VSAM systems.  G Since we're comparing the implementation of RMS on VAX/VMS, then PDP-11 ! isn't relevant to the discussion.   H Secondly, while DG may have been founded in the late 1960s, VAX came out6 before DG's attempt at 32 bit computing (MV machines).  $ The software on AOS/VS was pathetic.  @ Where DG was better than DEC is in competitiveness. DEC expectedB customers to beg to pay a premium for the privilege of getting DECG equipment and software. DG worked hard to give better price/performance 1 for it hardware. But their software was pathetic.    ------------------------------  % Date: Sun, 19 Feb 2006 22:28:35 -0500 ( From: Bill Todd <billtodd@metrocast.net>+ Subject: Re: "A Historical Look at the VAX" = Message-ID: <V46dnUcWqsn6qmTeRVn-qA@metrocastcablevision.com>    JF Mezei wrote:  > Bill Todd wrote:K >> Right:  the PDP-11 was competing tooth and nail with IBM's VSAM systems.  > I > Since we're comparing the implementation of RMS on VAX/VMS, then PDP-11 # > isn't relevant to the discussion.   H No, you've just managed once again to compound one incompetence on your H part with yet another.  The context to which you were responding was my I description of why RMS was designed (for *all* the systems it ran on, of  F which the PDP-11 systems were the first) to include indexed-file (and I alternate index) support, and my observations therein (to which you were  I specifically responding) were about the other 16-bit systems that the 11  I was competing with at that time (just before VAX was released:  RMS-11's  I first release was in January, 1977, over a year before the first VAX/VMS  	 release).    - bill   ------------------------------  % Date: Sun, 19 Feb 2006 23:26:29 -0500 , From: "Richard Tomkins" <tomkinsr@istop.com>+ Subject: Re: "A Historical Look at the VAX" = Message-ID: <43f945df$0$27792$6d36acad@titian.nntpserver.com>   K One of the biggest issues with VAX chip performance was that the chips were J derived from an architecture design which was originally based on discreteG electronics. VAX was a DEC Standard and this definition originally came  about using ECL semiconductors.   J The MicroVAX I and later MicroVAX II were attempts to cut down a number ofC instructions from the original design ( about 300) and focus on the L instructions ( about 170 ) that were most used by the compilers at the time.G Auxiliary libraries provided the dropped instruction functionality when C required. These were ZMOS VLSI implementations and later CMOS VLSI.   K Intel and AMD chips as well as Alpha were all designed as single chips from D the get go (based on CMOS), so working with a clean slate meant thatL performance in the design could be accommodated from conception and thus allJ the learned technologies and design from what went before could be applied to the new designs.   K http://simh.trailing-edge.com/docs/microarch.pdf is an excellent article by J Bob Supnik on the various considerations in front of the designers to makeL VAX chips that would adhere to the VAX DEC standard and still be single chipH implementations that were faster than the machines that had gone before.   rtt   2 "Dan O'Reilly" <dano@process.com> wrote in message; news:6.1.2.0.2.20060219181236.025a12e0@raptor.psccos.com... ( > At 05:48 PM 2/19/2006, JF Mezei wrote: > >A question: > > E > >Much has been said about the VAX's inability to scale up in speed.  > > F > >While I understand that fancy chip logic such as pipelining, branchH > >prediction etc is made much harder with variable length instructions,I > >wouldn't raw clock speeds be more dependant on the FAB process than on  > >the instruction formats ? > > > One of the big problems with the VAX was the instruction setJ > itself.  Instructions are variable length, which makes it much harder to? > pipeline (among other things) than a system with fixed-length I > instructions.  It was a very powerful and rich instruction set, but all  > that came at a price.  >  > ------L > +-------------------------------+----------------------------------------+L > | Dan O'Reilly                  |  "There are 10 types of people in this |L > | Principal Engineer            |   world: those who understand binary   |L > | Process Software              |   and those who don't."                |L > | http://www.process.com        |                                        |L > +-------------------------------+----------------------------------------+ >  >     . *** Free account sponsored by SecureIX.com ***X *** Encrypt your Internet usage with a free VPN account from http://www.SecureIX.com ***   ------------------------------  % Date: Mon, 20 Feb 2006 00:06:02 -0500 ) From: "Neil Rieck" <n.rieck@sympatico.ca> + Subject: Re: "A Historical Look at the VAX" 9 Message-ID: <N6cKf.3161$%14.142661@news20.bellglobal.com>   8 "Richard Tomkins" <tomkinsr@istop.com> wrote in message 7 news:43f945df$0$27792$6d36acad@titian.nntpserver.com... I > One of the biggest issues with VAX chip performance was that the chips   > wereL > derived from an architecture design which was originally based on discreteI > electronics. VAX was a DEC Standard and this definition originally came ! > about using ECL semiconductors.  > K I seem to remember ECL being used in the VAX-9000 but was it used in other   machines as well?   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.9 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html     ------------------------------  % Date: Mon, 20 Feb 2006 01:20:55 -0500 ' From: Dave Froble <davef@tsoft-inc.com> + Subject: Re: "A Historical Look at the VAX" / Message-ID: <H_mdncPrjb_2wmTeRVn-gA@libcom.com>    Richard Tomkins wrote:M > One of the biggest issues with VAX chip performance was that the chips were L > derived from an architecture design which was originally based on discreteI > electronics. VAX was a DEC Standard and this definition originally came ! > about using ECL semiconductors.   I This is so easily forgotten today, when microprocessors are so prevalent  F and have been for a long time.  I'm guessing the concept of pipelines F and such may not have existed when the VAX 11/780 was a collection of  boards.    --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------    Date: 19 Feb 2006 13:28:33 -0800" From: chris_doran@postmaster.co.uk! Subject: Re: 4000 vlc motherboard C Message-ID: <1140384513.711011.322900@g47g2000cwa.googlegroups.com>    Cliff Miller wrote: F > First iteration with the motherboard, without graphics card, or hardG > drive, or console connected:  +5, +12, and ground applied to the hard F > drive power connector - The 8 leds light, but stay illuminated.  The4 > voltages check out according to the drawing above. > G > One source read stated all 8 leds staying lit means "power is on, but  > no instructions executed." > 7 > This is quite a challenge without the graphics board!   F I've now tried mine with the graphics board missing and it gets as farB as F3. Nothing comes out on the console. So I'm afraid the missingD board is not your only problem :-(( And I don't seem to have a spare one anyway.    Chris    ------------------------------    Date: 20 Feb 2006 00:21:53 -06002 From: "Dave Weatherall" <djw-nothere@nospam.nohow>Y Subject: Re: A gripe just posted to HP's VMS ITRC forum (for those with a foot in both ca ? Message-ID: <DTiotGxQ0bj6-pn2-swHOnQq1UekB@dave2_os2.home.ours>   3 On Sat, 18 Feb 2006 04:31:44 UTC, "Craig A. Berry"  & <craigberry@mac.com.spamfooler> wrote:  < > In article <eQuJf.47266$T35.818696@news20.bellglobal.com>,7 >  "Peter Weaver" <newsonly@weaverconsulting.ca> wrote:  > 6 > > "Allan B." <hp.bowman@gmail.com> wrote in message ? > > news:1140199114.050849.8720@g43g2000cwa.googlegroups.com... M > > > Being an OpenVMS user and a frequent user of the ITRC forums, I can say G > > > that they have not alienated me.  As far as the posting from Mark H > > > Daniel that was removed, I completely agree with that decision.  IL > > > don't remember that exact wording he used, but the way the informationM > > > was presented I'm sure was found to be offensive by many people (myself  > > > including).  > G > Notice that he never actually says what about it he found offensive.    E Well I've just re-read Mark's post here and can't for the life of me  F see anything offensive. It's plain as day that it's not commercial. I D won't express the thought that went thro' my head when I read Allen  B's comments...    --   Cheers - Dave W.   ------------------------------  # Date: Mon, 20 Feb 2006 01:11:36 GMT L From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing)Q Subject: Re: How to copy the top level of a website to get rid of Javascript etc? 6 Message-ID: <00A51900.00D01A20@SSRL.SLAC.STANFORD.EDU>  N In article <45rm8iF84i6tU1@individual.net>, Paul Sture <paul.sture@bluewin.ch> writes:   
 >The problem:  > J >I frequently visit a couple of websites (not my own) I wish to make more G >accessible to disabled and older folks (and for that matter those who  # >only have a trackpad on a laptop).  > I >The problem is that the main pages are full of Javascript and extremely  C >tricky to navigate with a mouse, even for someone with good motor   >coordination and eyesight.  > A >What I would like to do is grab the main page(s) to rip out the  C >mouseover highly graphical whizz bangs there and put a plain HTML   >compliant menu in there.  > H >Fr my intitial attempt I want to host the simplified index pages on my J >own systems, but do not wish to use my own bandwidth for more than that, H >and of course I want to avoid copyright infringement issues by copying  >the information beneath.  > B >I have Apache on both Mac OS X and VMS (hence my posting to both I >comp.os.vms and comp.sys.mac.system) and would like to know how best to  	 >do this.   8 Okay, so you're set to host whatever you come up with.     > ? >wget and htdig come to mind, but I am open to all suggestions.   K Well, htdig isn't going to do much for you.  (It's an indexer program that  K crawls web pages; you'd have to get into the crawler part and make it _not_ N follow links and also save intermediate results; this doesn't buy you anything" over using a tool that does this.)  M Wget can suck down the page; so can cURL.  You can also use Perl with libwww, M and I'd expect there's a Python equivalent.  But if this is a one-time thing, 1 you can also just use a browser to save the page.   M But if you're concerned with ongoing issues of accessibility to the websites, L you probably want to automate fetching _and editing_ the index page as much I as possible.  I would tend to do this on VMS because of the robust batch  C system, but a cron job on OS X is likely to be good enough as well.    I'd use Perl, running in batch.   @ In addition to having the tools to do the fetch in libwww, thereL are HTML::Parse capabilities, and regular expression support, so you have atO least a fighting chance of decoding the javascript and extracting the URLs, or, K failing that, at least finding all the URLs hidden in the code, and you can : test those URLs and capture the statuses, all within Perl.  L At the very least, you can easily write a Perl script that notifies you whenN the  originating site has changed in ways you care about, and alerts you to do a manual edit.   -- Alan    ------------------------------  % Date: Sun, 19 Feb 2006 21:16:32 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> Q Subject: Re: How to copy the top level of a website to get rid of Javascript etc? , Message-ID: <43F9266A.FF97FA70@teksavvy.com>  , Alan Winston - SSRL Central Computing wrote:N > are HTML::Parse capabilities, and regular expression support, so you have atQ > least a fighting chance of decoding the javascript and extracting the URLs, or,     H Not enough. A lot of sites have javascript code that build unnecessarilyF complex URLs. So you need to actually execute the damned javascript to# get to a URL it wants you to go to.    ------------------------------    Date: 19 Feb 2006 21:15:02 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) Q Subject: Re: How to copy the top level of a website to get rid of Javascript etc? 3 Message-ID: <Dcput4nHLwYY@eisner.encompasserve.org>   \ In article <43F9266A.FF97FA70@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:. > Alan Winston - SSRL Central Computing wrote:O >> are HTML::Parse capabilities, and regular expression support, so you have at R >> least a fighting chance of decoding the javascript and extracting the URLs, or, >  > J > Not enough. A lot of sites have javascript code that build unnecessarilyH > complex URLs. So you need to actually execute the damned javascript to% > get to a URL it wants you to go to.   F How about something that instead of displaying the page sends an email? message to the domain owner asking them to clean up their act ?    ------------------------------  # Date: Sun, 19 Feb 2006 18:35:24 GMT ) From: Gnarlodious <gnarlodious@yahoo.com> Y Subject: Re: How to copy the top level of a website to get rid of Javascript etc? Javascr 2 Message-ID: <C01E087A.13965%gnarlodious@yahoo.com>   Entity Paul Sture spoke thus:   A > What I would like to do is grab the main page(s) to rip out the C > mouseover highly graphical whizz bangs there and put a plain HTML  > compliant menu in there.I GREAT IDEA! The number of Java driven webpages out there is proliferating A wildly, and the menus are irritating and glitchy in all browsers.   I Put a few URLs here and I'll see if there's a possibility to reformat the  menus.   
 -- Gnarlie http://Gnarlodious.com/Cogent/   ------------------------------  % Date: Sun, 19 Feb 2006 16:34:09 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> @ Subject: Re: KZPEA in ES45 with serial console only -- run bios?, Message-ID: <43F8E451.8BD40BC9@teksavvy.com>  K > > Perhaps a dumb question, but does the card's BIOS run on the card or on  > > the machine's own CPU?  F This may or may not apply to you. But my Q-BUS SCSI card (Dilog SQ739)* has its diagnostics/setup run on the VAX. A You must setup an IO map on the VAX and then branch to a specific A address where the code for the card's setup exists. So the card's ! firmware contain VAX instructions   @ The instructions mention that for graphics consoles, the initialH instructions are different because the IO mappping is done differently.   F Even if the actual program runs on the card, there has to be some sort@ of IO interface to the computer so it can output to the console.    ? > I think it runs on the card's own (small) CPU, because it can G > certainly be run on a PC.  (Now I think that the card is actually the - > Adaptec 39160, according to a FreeBSD site:   H It might be that Adaptec card with Digital specicic firmware (aka: AlphaC based code for the setup and code specific for Alpha's console IO).     : How are you supposed to trigger the card's setup program ?  B >   If you connect a SCSI hard disk drive to the Adaptec SCSI CardA >   39160 that was previously connected to a different SCSI card, > >   you must low-level format the drive before you can use it.  B I have seen this mentioned many times, including the BA35x storage arrays.    ------------------------------  % Date: Sun, 19 Feb 2006 13:56:39 -0500 ' From: Glenn Everhart <Everhart@gce.com> ? Subject: Re: LD devices in shadowsets on fault tolerant cluster 0 Message-ID: <11vhg58o4nck69b@corp.supernews.com>   Ralf Gaertner wrote:@ > Are the disks connected to a HSZ or HSG? If so, why do you notD > partition the the disks at the controller and shadow the resulting > units? > H I have gotten MSCP serving working with some of the variants of vddriverG out there. However, it is more straightforward to have separate virtual L disks on each box pointing at the same container area and let the underlying storage be served.  H As long as the device name and allocation class are the same everywhere,I the devices will be synchronized. There is a vddriver variant that forces ' the allocation class to a constant too.   I If you want to have shdriver work with a device, though, you must be sure F the devices being shadowed implement io$_dse. (Had to add that also toJ vddriver at one point when someone wanted a way to test 200-300 shadowsetsJ at once without having that many real disks. Initially it failed, but onceL io$_dse was added, shdriver would work. Mind: I just dummied the function toT report success and to tell the requestor "yeah, boss, I deleted what you requested".? A more careful emulation might want to actually write zeroes...   K It seemed odd that this worked as it did: shdriver would mysteriously fail, S even though the device driver did not report io$_dse support among legal functions. P There seem to be certain functions assumed to exist on any disk driver and neverN mind what the driver says...the IRPs were being passed to vddriver regardless.  X (I probably should not have been surprised: after all, there is no opportunity for extra FDT processing...)  L Vddriver has been on sigtapes and some freeware CDs; it was certainly on the* V3 one (a level down under sigtape tools).  O I have no VMS V8 system to try vddriver on, but it still works fine on my V7.3+ # systems and is available in source.   D Some of the foregoing should be useful with lddriver if desired too.   Glenn Everhart   ------------------------------  % Date: Sun, 19 Feb 2006 14:05:46 -0500 ' From: Glenn Everhart <Everhart@gce.com> ? Subject: Re: LD devices in shadowsets on fault tolerant cluster 0 Message-ID: <11vhgmab9svse79@corp.supernews.com>   Michael Moroney wrote:) > "Chris" <catsoup57@hotmail.com> writes:  >  > 
 >> $ set noon  > , >> $ reply/term=opa0 "Mounting DSA1 members" > " >> $ mount /system $1$dka100 data1 > " >> $ mount /system $1$dkb100 data2 > " >> $ mount /system $3$dka100 data3 > 4 >> $ reply/term=opa0 "Connecting DSA1 Logical disks" > < >> $ ld connect /share /log $1$dka100:[000000]data1.dsk lda1 >> /alloclass=100  > < >> $ ld connect /share /log $1$dkb100:[000000]data2.dsk lda2 >> /alloclass=100  > < >> $ ld connect /share /log $3$dka100:[000000]data3.dsk lda3 >> /alloclass=100  > $ >> $ reply/term=opa0 "Mounting DSA1" > D >> $ mount /system dsa1 /shadow=($100$lda1,$100$lda2,$100$lda3) data > * >> $ reply/term=opa0 "Finished DSA1 mount" > F > Ugh.  This is ugly.  The way shadowing is designed, each member mustH > be accessible to all nodes mounting the set, either directly connectedG > or MSCP served to it.  But if you think about this carefully, this is H > really not the case.  LDA1: on Node 1 is a different device than LDA1:G > on Node 2.  However, since they are mapped to the same container file K > each LDA1: will contain the same data.  So they are the same, yet not the . > same.  Maybe this is the problem, maybe not. > I > Another issue is whether the file system tries to cache the data on the I > container files.  I'm not familiar with how LD drivers work and if they G > know to disable the caching on the container files.  If the container H > files are cached, the following can happen:  Shadowing on Node 1 readsD > data from LDA1:  That block read on data1.dsk is cached on Node 1.I > Node 2 writes the same block with different data.  The data on the disk M > (both the LD disk and on the physical disk) is the new data.  Shadowing on  H > Node 1 reads the same block again, but because it's still in Node 1's M > container file cache, it gets the _old_ data.  I will tell you that if the  G > SCB on the LD drives get cached like this, shadowing will get _real_   > confused. D So go look at the sources and make sure the no cache flag is put in.  K Certainly vddriver was designed to work with nothing caching underneath it, J and I should think at least the "contig or almost contig" LD flavors wouldL also be so. If caching does not recognize this, it needs to be told so. (The> vms caching designs have been pretty varied over the years...)  G Using the possibly MSCP served underlying storage makes much more sense G than trying to make a shadowset on LD or VD units and then MSCP serving K the shadowed disk. Unless it has been fixed, there is a limit to the number I of MSCP units available (circa 512 if I recall rightly) which get used up L with every shadowed thing. Also, serving an LD/VD shadowset to a cluster canH mean data gets moved via MSCP multiple times before finally getting to aJ destination (which may be where the data could have been directly accessed if this had not been done.)   G Question is along the lines of whether ioc$insioqc is going to just hit L the destination driver, or will it hit some caching service first. Best flag= not to cache, but it has always been a low level interface...    Glenn Everhart   ------------------------------  % Date: Sun, 19 Feb 2006 16:08:29 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>' Subject: More VMS & DCL wish list items + Message-ID: <43F8EC5D.E7E4DAB5@comcast.net>   D From a thread about finding *THE* log file for a specific batch job:  A o We need to have SHOW ENTRY/FULL, and co. be able to display the G explicit, fully qualified filespec of the job's log file, including the  correct version number.     F From a thread about MOUNTing and using Joliet format CDs on VMS V7.3-2
 and later:  E o We need COPY/CONFIRM to allow for renaming the target manually when ' the source filespec is totally invalid.    For example:* $ cop dka400:[dnload]*.txt/conf d.d/noconcE COPY DKA400:[DNLOAD]ACSSS_~1.TXT;1 to SYS$SYSROOT:[SYSMGR]d.d; ? [N]:     How 'bout allowing, for example:/ $ copy/log dka400:[dnload]*.txt/conf d.d/noconc E COPY DKA400:[DNLOAD]ACSSS_~1.TXT;1 to SYS$SYSROOT:[SYSMGR]d.d; ? [N]:  =ACSSS_EVENT_LOG.TXT7 %COPY-I-COPIED, DKA400:[DNLOAD]ACSSS_~1.TXT;1 copied to ) SYS$SYSROOT:[SYSMGR]ACSSS_EVENT_LOG.TXT;1    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------  % Date: Sun, 19 Feb 2006 23:34:43 -0500 1 From: "Farrell, Michael" <MFarrell@Voltdelta.com> + Subject: RE: More VMS & DCL wish list items L Message-ID: <085BCCCF596B684092B66310B1D3BA7D0186C360@NJ103EX1.EAST.VIS.COM>  G On the wish list item for "SHOW ENTRY/FULL", add to that that the queue D name information given for the entry should include the cluster node that the queue is running on.    Mike Farrell   -----Original Message-----< From: David J Dachtera [mailto:djesys.nospam@comcast.net]=20' Sent: Sunday, February 19, 2006 5:08 PM  To: Info-VAX@Mvb.Saic.Com ' Subject: More VMS & DCL wish list items   D From a thread about finding *THE* log file for a specific batch job:  A o We need to have SHOW ENTRY/FULL, and co. be able to display the G explicit, fully qualified filespec of the job's log file, including the  correct version number.     F From a thread about MOUNTing and using Joliet format CDs on VMS V7.3-2
 and later:  E o We need COPY/CONFIRM to allow for renaming the target manually when ' the source filespec is totally invalid.    For example:* $ cop dka400:[dnload]*.txt/conf d.d/noconcE COPY DKA400:[DNLOAD]ACSSS_~1.TXT;1 to SYS$SYSROOT:[SYSMGR]d.d; ? [N]:     How 'bout allowing, for example:/ $ copy/log dka400:[dnload]*.txt/conf d.d/noconc E COPY DKA400:[DNLOAD]ACSSS_~1.TXT;1 to SYS$SYSROOT:[SYSMGR]d.d; ? [N]:  =3DACSSS_EVENT_LOG.TXT7 %COPY-I-COPIED, DKA400:[DNLOAD]ACSSS_~1.TXT;1 copied to ) SYS$SYSROOT:[SYSMGR]ACSSS_EVENT_LOG.TXT;1    --=20  David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------   Date: 19 Feb 06 20:02:14 EST) From: cook@wvnvms.wvnet.edu (George Cook)   Subject: Re: Mosaic v3.9 compile! Message-ID: <mduq56PrfeKr@wvnvms>   ` In article <43F7F2D0.2EC74766@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> writes:! > tomarsin2015@comcast.net wrote:  >>   >> HelloJ >> As I type in this message, I am compiling Mosaic V3.9 on a 3100-40 with >> 24megs of ram. A >> So far it has taken 2 reboots and  3 hours and counting. I was  >> wondering what files are H >> needed so I can just copy them to some other VAXes, or does each copy >> of Mosaic need " >> to be compile on each machine?? > H > No program should *EVER* need to be built from source on each machine. > That's ludicrous.  > I > There is some difference of option, but I hold that LINKing from source 7 > on each target is worst it should *EVER* have to get.  > A > ...but that's just me. I've yet to see an o.s. that can only be F > installed from source (though, perhaps such may exist). So, I see no< > reason why layered products, etc. should be any different.  D Name one other layered product which must be linked with TCP/IP, SSLD and Motif, and which will run on VMS 5.4-3 onward, Motif 1.1 onward,D HP SSL or OpenSSL (0.9.4 onward), and any of the major TCP/IP stacksD including CMU (whether or not they provide UCX compatibility).  ThenD there is the issue of which C (DEC C, VAX C or GNU C) RTL shareablesC or OLBs to link VAX executables against, or how to provide VAX OLBs F which will link in any of the three possible C environments.  It wouldB be a nightmare to provide bug fixes (between releases) in any form other than source.  @ One of the primary goals of keeping Mosaic alive is to provide a@ usable, fast, small, secure GUI web browser for all possible VMSB software environments where there is no good alternative.  As long@ as I only need to worry about distributing source, the amount ofA work I need to do to continue supporting all these enviroments is F quite small.  Almost all of the time I spend on software compatibilityA is in making Mosaic work with new versions of VMS, Motif and SSL. ? Keeping Mosaic working with the old stuff just requires a small F amount of discipline in not using every new gee-wiz software feature.   D Of course if someone wanted to volunteer to do all the work requiredE to distribute Mosaic in a form other than source, I would not object.      George Cook  WVNET      ------------------------------  % Date: Sun, 19 Feb 2006 16:58:55 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> = Subject: Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering , Message-ID: <43F8EA1D.99ED9278@teksavvy.com>   Dave Froble wrote:H > His problem is that the entry number with the problem is not the firstH > use of that job number that day.  It's the second, or third use of the
 > job number.    Actually, it doesn't matter.  F If all your jobs have the same logfile name, then you have a gazillionG jobNAME.log files without any tie in to the original job number in your D directory. If you do a /RETAIN=ERROR, does the SHOW ENTRY/FULL for aH failed job  give you the exact log file name with version number or just3 the generic logfile name without a version number ?   F And as soon as job 471 is declared failed and /RETAINed on error, then: "471" will no longer be re-used until the job is deleted.   I So having different log files for each job seems to be the best solution.    ------------------------------  % Date: Sun, 19 Feb 2006 16:01:53 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>= Subject: Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering + Message-ID: <43F8EAD1.2BBC86EB@comcast.net>   
 AEF wrote: >  > David J Dachtera wrote: $ > > Peter 'EPLAN' LANGSTOEGER wrote: > > > f > > > In article <43F6A30C.BCF5B109@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> writes:P > > > >> you can see, that the same entry number is used more than once per day.% > > > >> And this is very annoying...  > > > >> > > > >> Anybody ? Hoff ?  > > > > K > > > >Well, if I understand the issue, it sounds like you may be trying to . > > > >track batch jobs by their entry number. > > > J > > > Not at all. I only have a lot of (equally named) logfiles and I needJ > > > to find out why entry x failed (and hangs around retained on error).J > > > Searching with the entry number (and the date) is not enough becauseF > > > there are more than one entry number x per day. Thats all folks. > > D > > Well, SHOW ENTRY/FULL on a retained entry shows the time the jobH > > completed. So, DIRECTORY/MODIFIED using /SINCE and /BEFORE should be > > able to narrow it down:  > > B > > DJAS01::DDACHTERA$ dir/noprot/nosize/date=(cre,mod) login.com; > >  > > Directory DKA0:[DDACHTERA] > > I > > LOGIN.COM;1           3-SEP-1997 16:24:35.65  28-NOV-1998 21:25:44.81  > >  > > Total of 1 file.G > > DJAS01::DDACHTERA$ dir/mod/sin="28-NOV-1998 21:25"/bef="28-NOV-1998  > > 21:26" login > > .com > >  > > Directory DKA0:[DDACHTERA] > > A > > LOGIN.COM;1                1/9         3-SEP-1997 16:24:35.65  > > (RWED,RWED,RE,)  > >   > > Total of 1 file, 1/9 blocks. > > K > > Sorry, didn't have a queue entry handy to use as an example, but that's H > > what I mean: bracket the target time using /SINCE and /BEFORE valuesI > > with MODIFIED and less granular sample time for each qualifier should & > > give you everything in that range. > > I > > That said, let me ask this: can you modify whatever SUBMITs the jobs?  > >  > > If you can, try this:  > > ' > > $ SUBMIT/qualifier(s) filespec/HOLD ( > > $ JENTRY = F$FAO( "!7ZL", '$ENTRY' )E > > $ SET ENTRY '$ENTRY'/LOG=[ddcu:<dir>]filename_'JENTRY'.LOG/NOHOLD  > > I > > That will produce fewer logs to sift through since you can then get a I > > listing of every entry number used for that job in ascending order by  > > entry number.  > > G > > Personally, though, I agree with Michael: if the job is retained on K > > error, that entry number won't be re-used so long as that queue remains 
 > > retained.  > G > That's not his problem. Imagine his queue numbers run from 1 to 1000. H > His system runs 3000 jobs one day. Now he has found that entry 442 hasG > been retained on error. Now which of the 3 log files that contain 442 I > is the one that was retained in the queue??? Even though job 442 may be G > reatined in the queue, that same number may have been used earlier in 
 > the day.  2 How many times has that entry number been re-used?   If the job's entry number:  9 $ enbr = F$GETQUI("DISPLAY_JOB","AFTER_TIME",,"THIS_JOB")   D ...is output to the log file, that will help naarow it down, but not pin-point the target log.   H Interesting thing about /RETAIN: if a job is retained, even when a queueH is set /RETAIN=ALWAYS, /DELETE of the log file doesn't take effect until the entry is itself is DELETEd.   G So, one other possible solution might be to SET the QUEUE /RETAIN=ERROR E and specify a "null" queue as the default print destination for batch E logs, then SUBMIT the jobs using /NOKEEP explicitly (to over-ride any G defaults due to symbols, etc.). That way, the only batch logs that will H remain on disk are those where the entry was retained due to the queue's current SETtings.   E That narrows it down even further. SHOW ENTRY/FULL or the appropriate G F$GETQUI() calls to automate the task for an entry would then be useful F to get down even closer to the target log using the completion time of. the job and the RDTs of the log files on disk.  F It would be most helpful, of course, if the queue manager would updateG the entry with the actual target filespec for the log file. Then again, H given that there does not seem to be a way to retrieve that outside of aD great deal of VMS "black magic", that may not even be possible right8 now. It would likely require considerable enhancement to LOGINOUT.EXE(?).   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------    Date: 19 Feb 2006 20:35:03 -0800$ From: "AEF" <spamsink2001@yahoo.com>= Subject: Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering A Message-ID: <1140410103.291077.4690@g44g2000cwa.googlegroups.com>    David J Dachtera wrote:  > AEF wrote: > >  > > David J Dachtera wrote: & > > > Peter 'EPLAN' LANGSTOEGER wrote: > > > > h > > > > In article <43F6A30C.BCF5B109@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> writes: [...]  > > > If you can, try this:  > > > ) > > > $ SUBMIT/qualifier(s) filespec/HOLD * > > > $ JENTRY = F$FAO( "!7ZL", '$ENTRY' )G > > > $ SET ENTRY '$ENTRY'/LOG=[ddcu:<dir>]filename_'JENTRY'.LOG/NOHOLD  > > > K > > > That will produce fewer logs to sift through since you can then get a K > > > listing of every entry number used for that job in ascending order by  > > > entry number.  > > > I > > > Personally, though, I agree with Michael: if the job is retained on M > > > error, that entry number won't be re-used so long as that queue remains  > > > retained.  > > I > > That's not his problem. Imagine his queue numbers run from 1 to 1000. J > > His system runs 3000 jobs one day. Now he has found that entry 442 hasI > > been retained on error. Now which of the 3 log files that contain 442 K > > is the one that was retained in the queue??? Even though job 442 may be I > > reatined in the queue, that same number may have been used earlier in  > > the day. > 4 > How many times has that entry number been re-used?  D Well, in this case, 3. But apparently it is too much. I think even aE low number is too much because you may have to do it many times. It's A like putting your return address on an envelope by hand. A former F housemate once made fun of pre-printed address labes as "Gee, how lazyG can you be?" Well, he didn't pay many bills himself. If he had to do it 9 a dozen times a month or more I think he'd get the point.    >  > If the job's entry number: > ; > $ enbr = F$GETQUI("DISPLAY_JOB","AFTER_TIME",,"THIS_JOB")  > F > ...is output to the log file, that will help naarow it down, but not > pin-point the target log.   , Again, he wants it narrowed down completely.   > J > Interesting thing about /RETAIN: if a job is retained, even when a queueJ > is set /RETAIN=ALWAYS, /DELETE of the log file doesn't take effect until! > the entry is itself is DELETEd.   C Well, that's good, no? I'm sure you'd complain if the log file were  deleted upon completion!   > I > So, one other possible solution might be to SET the QUEUE /RETAIN=ERROR G > and specify a "null" queue as the default print destination for batch G > logs, then SUBMIT the jobs using /NOKEEP explicitly (to over-ride any I > defaults due to symbols, etc.). That way, the only batch logs that will J > remain on disk are those where the entry was retained due to the queue's > current SETtings.  > G > That narrows it down even further. SHOW ENTRY/FULL or the appropriate I > F$GETQUI() calls to automate the task for an entry would then be useful H > to get down even closer to the target log using the completion time of0 > the job and the RDTs of the log files on disk. > H > It would be most helpful, of course, if the queue manager would updateI > the entry with the actual target filespec for the log file. Then again,   7 Yes, that would indeed be nice, at least for this case.   J > given that there does not seem to be a way to retrieve that outside of aF > great deal of VMS "black magic", that may not even be possible right  ? Well, get the job_pid with f$getqui, make a temp file from show C dev/files, and search the temp file for the pid -- is that a lot of D black magic? (It *is* a somewhat roundabout way of doing things, but? sometimes you have no choice -- as in calculating the number of @ combinations of n things taken r at a time. This is described inG probability field as follows: If you can't count the sheep, count their E legs and divide by four.) The macro that achieves the same result may G be, but it's already written and just has to be hunted down in archives  of this ng.   : > now. It would likely require considerable enhancement to > LOGINOUT.EXE(?).  G Why doesn't he just add some kind of index or timestamp to the log-file . name? That seems like the best solution to me.   AEF    ------------------------------  % Date: Mon, 20 Feb 2006 01:26:30 -0500 ' From: Dave Froble <davef@tsoft-inc.com> = Subject: Re: [OpenVMS Alpha V7.3-2] Batch/Print Job Numbering / Message-ID: <kamdne_MoeMn_WTeRVn-jg@libcom.com>   
 AEF wrote: > David J Dachtera wrote:  >  >>AEF wrote: >> >>>David J Dachtera wrote: >>> $ >>>>Peter 'EPLAN' LANGSTOEGER wrote: >>>>e >>>>>In article <43F6A30C.BCF5B109@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> writes:  >  > [...]  >  >>>>If you can, try this:  >>>>' >>>>$ SUBMIT/qualifier(s) filespec/HOLD ( >>>>$ JENTRY = F$FAO( "!7ZL", '$ENTRY' )E >>>>$ SET ENTRY '$ENTRY'/LOG=[ddcu:<dir>]filename_'JENTRY'.LOG/NOHOLD  >>>>I >>>>That will produce fewer logs to sift through since you can then get a I >>>>listing of every entry number used for that job in ascending order by  >>>>entry number.  >>>>G >>>>Personally, though, I agree with Michael: if the job is retained on K >>>>error, that entry number won't be re-used so long as that queue remains 
 >>>>retained.  >>> H >>>That's not his problem. Imagine his queue numbers run from 1 to 1000.I >>>His system runs 3000 jobs one day. Now he has found that entry 442 has H >>>been retained on error. Now which of the 3 log files that contain 442J >>>is the one that was retained in the queue??? Even though job 442 may beH >>>reatined in the queue, that same number may have been used earlier in >>>the day.  >>4 >>How many times has that entry number been re-used? >  > F > Well, in this case, 3. But apparently it is too much. I think even aG > low number is too much because you may have to do it many times. It's C > like putting your return address on an envelope by hand. A former H > housemate once made fun of pre-printed address labes as "Gee, how lazyI > can you be?" Well, he didn't pay many bills himself. If he had to do it ; > a dozen times a month or more I think he'd get the point.  >  >  >>If the job's entry number: >>; >>$ enbr = F$GETQUI("DISPLAY_JOB","AFTER_TIME",,"THIS_JOB")  >>F >>...is output to the log file, that will help naarow it down, but not >>pin-point the target log.  >  > . > Again, he wants it narrowed down completely. >  > J >>Interesting thing about /RETAIN: if a job is retained, even when a queueJ >>is set /RETAIN=ALWAYS, /DELETE of the log file doesn't take effect until! >>the entry is itself is DELETEd.  >  > E > Well, that's good, no? I'm sure you'd complain if the log file were  > deleted upon completion! >  > I >>So, one other possible solution might be to SET the QUEUE /RETAIN=ERROR G >>and specify a "null" queue as the default print destination for batch G >>logs, then SUBMIT the jobs using /NOKEEP explicitly (to over-ride any I >>defaults due to symbols, etc.). That way, the only batch logs that will J >>remain on disk are those where the entry was retained due to the queue's >>current SETtings.  >>G >>That narrows it down even further. SHOW ENTRY/FULL or the appropriate I >>F$GETQUI() calls to automate the task for an entry would then be useful H >>to get down even closer to the target log using the completion time of0 >>the job and the RDTs of the log files on disk. >>H >>It would be most helpful, of course, if the queue manager would updateI >>the entry with the actual target filespec for the log file. Then again,  >  > 9 > Yes, that would indeed be nice, at least for this case.  >  > J >>given that there does not seem to be a way to retrieve that outside of aF >>great deal of VMS "black magic", that may not even be possible right >  > A > Well, get the job_pid with f$getqui, make a temp file from show E > dev/files, and search the temp file for the pid -- is that a lot of F > black magic? (It *is* a somewhat roundabout way of doing things, butA > sometimes you have no choice -- as in calculating the number of B > combinations of n things taken r at a time. This is described inI > probability field as follows: If you can't count the sheep, count their G > legs and divide by four.) The macro that achieves the same result may I > be, but it's already written and just has to be hunted down in archives 
 > of this ng.  >  > : >>now. It would likely require considerable enhancement to >>LOGINOUT.EXE(?). >  > I > Why doesn't he just add some kind of index or timestamp to the log-file 0 > name? That seems like the best solution to me. >  > AEF  >   5 What seems the best solution to me is a utility that:   I 1) Could re-set the number to 0 or 1, depending upon what's stored, last   used, or next to use.   ! 2) Could set the rollover number.   H Every night at midnight, or whenever one wanted to, set the job numbers H to start at 1.  As long as the range selected is large enough, ever job H in a day would have a unique number.  That is what the OP wanted, right?   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------   End of INFO-VAX 2006.101 ************************