1 INFO-VAX	Sat, 26 Aug 2006	Volume 2006 : Issue 475       Contents:8 Re: %MOUNT-W-INCONSTRUCT, inconsistent VMS error message Re: Alpha remembrance day  Re: Back at work Re: Hobbyist Media available Re: Hobbyist Media available, Re: Mystery multiple TCP connections dropped, Re: Mystery multiple TCP connections dropped6 Re: Reading UAF Disuser Flag Across Nodes from FORTRAN+ Re: Removing a member from bound volume set  Re: Speaking of Clusters:  Re: Speaking of Clusters: 4 Re: Thoughts on the book: DEC is dead, long live DEC- Weird BUGCHECK on OpenVMS Alpha 8.2 (FREWSLX)  Re: WWENG2.SYS Re: WWENG2.SYS Re: WWENG2.SYS  F ----------------------------------------------------------------------  % Date: Sun, 27 Aug 2006 00:15:31 +0800  From: prep@prep.synonet.com A Subject: Re: %MOUNT-W-INCONSTRUCT, inconsistent VMS error message 0 Message-ID: <874pvzlbh8.fsf@k9.prep.synonet.com>  / Kilgallen@SpamCop.net (Larry Kilgallen) writes:   w > In article <1156396404.433286.254280@m79g2000cwm.googlegroups.com>, "Volker Halle" <volker_halle@hotmail.com> writes:  > B >> $ HELP/MESS DOSETVOL contains an appropriate description of the >> necessary actions.  > 4 > No, it suggest one should mount the disk /NOSHARE.E > The /NOSHARE qualifier is on of a long list that do nothing to make  > this disk mountable. > E > Also, note that my goal is _not_ to make an ODS-5 disk.  My goal is " > to mount my existing ODS-2 disk. > H >> The MOUNT-W-INCONSTRUCT had better been an error or fatal message, if >> it failed to mount the disk.  > > > No there are subsidiary changed messages that show as fatal.' > Theirs is the status returned to DCL.   # Can you mount the drive /OVER=LOCK?    --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Sat, 26 Aug 2006 03:15:04 -0400 + From: Steve Matzura <number6@speakeasy.net> " Subject: Re: Alpha remembrance day8 Message-ID: <bcqve2lhl6rglb1gtk1doilrqijt0ic46b@4ax.com>  C On 10 Aug 2006 12:41:52 -0700, "flatts1" <flatts1@yahoo.com> wrote:    >Andrew wrote:D >- ALL-IN-ONE:  I don't know how this ever made DEC money.  The onlyG >time I ever saw it in use was when I worked at DEC and also at College   >where I presume it was donated.  D I had one-and-a-half full-time jobs (at two different places and twoF different times, of course) based on this product.  Unfortunately, forC reasons you did not care to cite, it died of its own weight and was C replaced by Notes in almost every office I've ever heard of, worked F in, etc., mostly because it failed to make the full jump to a PC-based= client.  It tried--rememberTeamlinks?--but ultimately failed.    ------------------------------  % Date: Sat, 26 Aug 2006 03:15:03 -0400 + From: Steve Matzura <number6@speakeasy.net>  Subject: Re: Back at work 8 Message-ID: <vlpve2pbbpn9098ljuhtbafc61i4jb055j@4ax.com>  A On 7 Aug 2006 15:55:59 -0700, "Sue" <susan_skonetski@hotmail.com>  wrote:  A >I just wanted to let everyone know that I am now back at work.     B Ah, peace in the valley!  It's good to hear you're back online andE in-the-house!  Friends of mine from a previous employer have informed B me that your email newsletter has cranked up again, so I knew it'd9 only be a matter of time before you were spotted in here.   E Hopefully all went well and you'll be in next year's marathon, right?    ------------------------------  % Date: Sat, 26 Aug 2006 11:51:55 -0400 ' From: Dave Froble <davef@tsoft-inc.com> % Subject: Re: Hobbyist Media available 9 Message-ID: <gOqdnSVo27vp8W3ZnZ2dnUVZ_tudnZ2d@libcom.com>    bob lombard wrote:I > Hi - I'm trying to get a media kit for the hobbyist program. Have tried E > to contact the hobbyist website w/o response, although its happy to B > take your order, the process seems to die there (CC does not get > charged, no CD''s, etc). > C > Lack of recent discussion leads me to ask if the program is dead,   D The hobbyist program support is itself sort of a hobby.  The people @ supporting it do have jobs and their time is I believe donated. E Sometimes the response time reflects this.  Just keep trying, and as  & Brad suggests, try the hobbyist forum.   > are D > the licenses still available, are there other avenues to gettign a5 > hobbyist system running, if only on SIMH or CHARON?  > # > -bob  (blombard at usarc dot org)  >      --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------    Date: 26 Aug 2006 09:03:48 -0700 From: davidc@montagar.com % Subject: Re: Hobbyist Media available C Message-ID: <1156608227.962155.186850@b28g2000cwb.googlegroups.com>    bob lombard wrote:I > Hi - I'm trying to get a media kit for the hobbyist program. Have tried E > to contact the hobbyist website w/o response, although its happy to B > take your order, the process seems to die there (CC does not get > charged, no CD''s, etc). > G > Lack of recent discussion leads me to ask if the program is dead, are D > the licenses still available, are there other avenues to gettign a5 > hobbyist system running, if only on SIMH or CHARON?   F Yes, there have been a recent delay in delivering hobbyist CD's.  I'veC had a problem with the printers I use to print labels/etc, and I've C gotten that resolved.  Rest assured, they will be making it out - I D hadn't charged the cards, since Visa/MC/etc really don't like you toF charge the card until the item is shipping...  But a large shipment isB going out today, so everyone that's ordered one recently should be seeing it soon.   ? Forums are generally a better place to send questions, or email + directly to hobbyist (SHIFT-2) montagar.com    > # > -bob  (blombard at usarc dot org)    ------------------------------    Date: 26 Aug 2006 02:27:11 -0700 From: tombourke@gmail.com 5 Subject: Re: Mystery multiple TCP connections dropped C Message-ID: <1156584431.837730.140150@m79g2000cwm.googlegroups.com>   
 AEF wrote: > F > I don't think so. See below about the timestamps. Also, the death ofF > the connection appears identical to what happens if I either disable@ > the page's port in the multifeed program or if I just shut theI > multifeed program altogether. (The job on the VAX gives identical error # > messages for all three scenarios:  > - > %SYSTEM-F-VCCLOSED, virtual circuit closed)   B AEF, when I used to work in broker feed land, we used to find thatF problems were down to saturated hubs and switches our code was usually@ solid (especially if a new network problem appeared(!) ;-)  )...  D I'm sure you''ve looked at these already, but as it sounds more like( it's network related than VMS related...  D Could it be that your market data backbone is getting saturated by aE download to a server at that time i.e. a Reuters RDF starting up or a F interest list on a distribution platform (e.g. TIB/ Triarch/ Whatever)> being renewed after an app on a different server is restarted?   > H > Each feed job running on the MicroVAX systems sends a timestamp to theE > multifeeds every 15 seconds. The original purposes of this was as a E > keep-alive and the time to be displayed on customer screens. In the C > event of a feed outage the multifeed would then time-out after 60 I > seconds of silence. This was to prevent the occurrence of stale prices. G > However, we used to have a lot of trouble with the multifeed program, D > and the timeout was originally global (and therefore, ineffective,G > don't ask why it was global) so we don't really use the timeouts now. H > It's a very long story. Don't ask. I don't have the time to explain it > all.  E Global timeouts... Hmmm... reminds me of a problem with a broker feed 
 from RMJ..  K > > This way, your application could detect an outage during idle times and R > > give you better insight on when (within a 10 minute window) the outage begins. > H > Fortunately we were saved on Tuesday by the redundant London multifeedG > (only London uses these pages, at least at that hour) and on Thursday A > by both that and our monitoring (which woke me up at 2:33). The A > monitoring failed on Tuesday due to some confusion with how the G > multifeed's syslog server should be configured due to some changes in H > the mail system. The marketdata people (who manage the multifeeds) andF > the mail admins pointed fingers at each other. Anyway, it was fixed.  G I know the marketdata people and network people are pointing fingers at F each other, but have any of them put a sniffer on said backbone to seeE if a node is generating traffic 'oddly'/ or is chattering away with a  bad ethernet card/ cable.   C There probably is a sniffer/ network tap already on the segment for ; this very purpose... perhaps they could use that and see...    best,    Tom  (tom hat ex-bidds daht com)    ------------------------------    Date: 26 Aug 2006 06:43:46 -0700$ From: "AEF" <spamsink2001@yahoo.com>5 Subject: Re: Mystery multiple TCP connections dropped B Message-ID: <1156599826.726935.306960@74g2000cwt.googlegroups.com>   tombourke@gmail.com wrote: > AEF wrote: > > H > > I don't think so. See below about the timestamps. Also, the death ofH > > the connection appears identical to what happens if I either disableB > > the page's port in the multifeed program or if I just shut theK > > multifeed program altogether. (The job on the VAX gives identical error % > > messages for all three scenarios:  > > / > > %SYSTEM-F-VCCLOSED, virtual circuit closed)  > D > AEF, when I used to work in broker feed land, we used to find thatH > problems were down to saturated hubs and switches our code was usuallyB > solid (especially if a new network problem appeared(!) ;-)  )... > F > I'm sure you''ve looked at these already, but as it sounds more like* > it's network related than VMS related...  ? Being that this happened on two MicroVAX systems, three Windows A multifeed systems, with all six connections between them dropping @ within a tenth of a second of each other, I can't see any of theF systems being at fault. It must be some external entity. But why theseD two pages and not the other two? The code running on the VAX side isD pretty solid, but we've had trouble with the multifeed code over the2 years. But said code seems to be a lot better now.  F > Could it be that your market data backbone is getting saturated by aG > download to a server at that time i.e. a Reuters RDF starting up or a H > interest list on a distribution platform (e.g. TIB/ Triarch/ Whatever)@ > being renewed after an app on a different server is restarted?   I'll check on Monday.   J > > Each feed job running on the MicroVAX systems sends a timestamp to theG > > multifeeds every 15 seconds. The original purposes of this was as a G > > keep-alive and the time to be displayed on customer screens. In the E > > event of a feed outage the multifeed would then time-out after 60 K > > seconds of silence. This was to prevent the occurrence of stale prices. I > > However, we used to have a lot of trouble with the multifeed program, F > > and the timeout was originally global (and therefore, ineffective,I > > don't ask why it was global) so we don't really use the timeouts now. J > > It's a very long story. Don't ask. I don't have the time to explain it > > all. > G > Global timeouts... Hmmm... reminds me of a problem with a broker feed  > from RMJ.. > M > > > This way, your application could detect an outage during idle times and T > > > give you better insight on when (within a 10 minute window) the outage begins. > > J > > Fortunately we were saved on Tuesday by the redundant London multifeedI > > (only London uses these pages, at least at that hour) and on Thursday C > > by both that and our monitoring (which woke me up at 2:33). The C > > monitoring failed on Tuesday due to some confusion with how the I > > multifeed's syslog server should be configured due to some changes in J > > the mail system. The marketdata people (who manage the multifeeds) andH > > the mail admins pointed fingers at each other. Anyway, it was fixed. > I > I know the marketdata people and network people are pointing fingers at H > each other, but have any of them put a sniffer on said backbone to seeG > if a node is generating traffic 'oddly'/ or is chattering away with a  > bad ethernet card/ cable.   C We have a sniffer appropariately placed now. But the problem hasn't  recurred since.   E > There probably is a sniffer/ network tap already on the segment for = > this very purpose... perhaps they could use that and see...    Nope, there wasn't.    > best,  >  > Tom  > (tom hat ex-bidds daht com)    Thanks for your help.    AEF    ------------------------------  % Date: Sat, 26 Aug 2006 12:00:27 -0400 ' From: Dave Froble <davef@tsoft-inc.com> ? Subject: Re: Reading UAF Disuser Flag Across Nodes from FORTRAN 9 Message-ID: <gOqdnSRo27vp823ZnZ2dnUVZ_tudnZ2d@libcom.com>    wendzinski@yahoo.com wrote: C > Is it possible to access UAF disuser flag values across nodes via G > FORTRAN?  I believe I can call SYS$GETUAI to to access UAI$V_DISACNT. E > The tricky part is that the UAF may be on a node other than the one 6 > running the program.  Examples would be appreciated. > 	 > Thanks.  >   G If you have read access to the file, SYSUAF.DAT, which is not normally  D available for non-system users, you could just open the file on the I target node and read the data.  Such would require you to know what node  3 is the target, and to have adequate access to same.   I Not what I'd consider an optimum solution, but you ask for possibilities.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------    Date: 26 Aug 2006 03:29:09 -0700) From: "Bob Gezelter" <gezelter@rlgsc.com> 4 Subject: Re: Removing a member from bound volume setB Message-ID: <1156588149.745691.140810@75g2000cwc.googlegroups.com>   JF,   ) It is potentially more complex than that.   C It is possible for a file to extend across different volumes in the < set, so identifying all files is more than just scanning the directories.  F If you a are moving to a single volume SCSI, perhaps the best strategy is to do that more directly.  E I have not tried it, but you also might be able to use a LD container 6 file on onf\e of the other members to retire a member.  $ - Bob Gezelter, http://www.rlgsc.com   ------------------------------  % Date: Sat, 26 Aug 2006 23:10:46 +0800  From: prep@prep.synonet.com " Subject: Re: Speaking of Clusters:0 Message-ID: <87lkpbleh5.fsf@k9.prep.synonet.com>  * "geletine" <adaviscg1@hotmail.com> writes:  " > what type of cluster was ARCnet?  B Arcnet was quite niffty. The idea was to hook everything up over aC serial bus, driven by a lamp-driver chip as I recall, and since you A had to add a CPU to all the `peripherals', you may as well crunch  numbers on them as well.  C It started out as an IBM RJE clone, and soon reached the point that ' the best upgrade was to unplug the IBM!   @ Look out for networking presentations from the 80/81 time frame.   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Sat, 26 Aug 2006 23:12:30 +0800  From: prep@prep.synonet.com " Subject: Re: Speaking of Clusters:0 Message-ID: <87hczzlee9.fsf@k9.prep.synonet.com>  * Bill Todd <billtodd@metrocast.net> writes:   > and some even exist for - : > gasp! - Windows (Stratus, still, and perhaps Marathon?).  & And, the shame, FTVax. Briefly anyway.   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Sat, 26 Aug 2006 06:48:11 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> = Subject: Re: Thoughts on the book: DEC is dead, long live DEC < Message-ID: <44f0258b$0$24204$9a6e19ea@news.newshosting.com>  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  & news:44EFB5D2.9F5DC817@teksavvy.com... > Neil Rieck wrote:  [...snip...] > F > Also, the book mentions in one place that the decisions not to adoptI > "commodity" stuff and continue with expensive proprietary stuff was not I > a direct Olsen policy, but just something which the various engineering A > groups decided. So DEC's continued "proprietary" nature isn't a H > reflection of Olsen per say. Olsen didn't make those decisions, but heF > also didn't try to nudge engineers away from proprietary components.C > (maybe he did in real life, but it wasn't mentioned in the book).  >   H While this was true with VAX, it changed when second-gen Alpha chipsets ( (1994?) which supported PCI and ISA/EISA   > J > Another image I got from the book is that until the mid 1980s, DEC livedB > pretty much in "DOT COM" boom mode where money was no object andI > engineers were let loose to develop any/all technologies in the hope of F > getting more cash cows. It worked as long as growth was greater thanJ > ensuing inefficiencies. Come competition, and things unravelled quickly. >   K I aggree and I think this is one reason why IBM survivied intact while DEC  @ did not. IBM (a financially conservative company) was much more L lean-and-mean and did not have engineers developing lots of cool stuff at a K time when the whole industry was going through a paradigm shift from minis   to PCs.    > K >> in Kanata, Montreal, Bedford, and Maynard, between 1977 and 1993. It was I >> obvious to all students that this was a different kind of company and   >> that 4 >> DEC employees seemed very proud as well as happy. > E > Yep. When I bought the first machines, and took the courses, it was B > quite apparent to me. My then boss' husband was a high level IBMI > engineer/consultant and he inspected the hardware when it was delivered J > and said that he was impressed, that it was really well done, built/high > quality etc. >   J You brought up something I forgot to mention. Way back in the 1980s I had I heard of IBM consultants and was wondering why IBM was trying to control  	 expenses.   G > However, when this success lead to headquarters wanting to deploy DEC I > gear throughoput the organisation, (87/88 timeframe) I saw another side H > of DEC that was REALLY ignorant of the competition, extremely arrogantC > and of course very much more expensive. In fairness though, their E > proposal was far more realistic than DG's and that company ended up I > spending much more to get that DG junk working compared to if they have H > bought the DEC gear at list price (that is what DEC had submitted as aE > bid wirth more than a million dollars). The "more realistic" was an F > aspect which the book confirmed with Olsen's demands that DEC remainE > honest and not "lie" through marting exagerated stuff to customers.   L I hope we don't live in a world where the policies of honest people cause a M company's demise. On the flip side, sales people do seem more motivated when  < their income is attached to commission (which Olsen opposed)    
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/    ------------------------------    Date: 26 Aug 2006 05:16:45 -0700A From: "luke.shipway@googlemail.com" <luke.shipway@googlemail.com> 6 Subject: Weird BUGCHECK on OpenVMS Alpha 8.2 (FREWSLX)C Message-ID: <1156594605.813978.292440@h48g2000cwc.googlegroups.com>    Hi All,   E Just a quick question, one of our systems crashed this morning with a  FREWSLX Bugcheck9 when one of the support team tried to run MONITOR SYSTEM.   F The system was running an Oracle 9i PL/SQL extract job and they wanted to checkE the CPU usage, but after rebooting the node, the job and MONITOR both 	 ran fine.   D I've tried Google'ing for FREWSLX but it seems pretty un-common, can anybody give+ me any pointers on why this crash happened?   B NB All the patches from ITRC have already been applied, along with Multinet 5.1 patches.   5 I've attached some of the ANALYSIS/CRASH stuff below:    CPU bugcheck codes: D         CPU 00 -- database address 8203E000 -- FREWSLX, Free working set list index, resource wait   B OpenVMS Operating System, Version V8.2     -- System Dump Analysis? 26-AUG-2006 05:12:40.88                              Page     3 2 CPU 00 Processor state at time of FREWSLX bugcheck          A CPU 00 reason for Bugcheck: FREWSLX, Free working set list index, 
 resource wait     / Process currently executing on this CPU: SYSTEM     = Current image file: DSA0:[SYS0.SYSCOMMON.][SYSEXE]MONITOR.EXE      Current IPL: 8  (decimal)      CPU database address: 8203E000    ( CPUs Capabilities:    PRIMARY,QUORUM,RUN   General registers:  : R0   = 00000000.00000000  R1   = 00000000.00000015  R2   = FFFFFEFC.001EA029 : R3   = 00000000.00000008  R4   = FFFFFFFF.827C0EC0  R5   = FFFFFFFF.85680000 : R6   = FFFFFEFD.BF6FC000  R7   = FFFFFEFD.BF000000  R8   = 00000000.7B44E158 : R9   = 00000000.00CE8072  R10  = FFFFFEFC.00000DB8  R11  = 00000000.000DDF68 : R12  = FFFFFEFE.019E2000  R13  = 00000000.0036E000  R14  = FFFFFFFF.81CEC498 : R15  = 00000000.0010AF9C  R16  = 00000000.00000144  R17  = 00000000.00000000 : R18  = 00000000.0000013C  R19  = 20000000.00000203  R20  = 00000000.7FF87D60 : R21  = FFFFFFFF.81C081A0  R22  = 00000000.00000000  R23  = FFFFFFFF.81C08000 : R24  = FFFFFFFF.81C08000  AI   = 00000000.00000002  RA   = FFFFFFFF.81C0808C : PV   = FFFFFFFF.81C08000  R28  = FFFFFFFF.801779D8  FP   = 00000000.7FF87CA0 2 PC   = FFFFFFFF.80178498  PS   = 38000000.00000800         Processor Internal Registers:     : ASN  = 00000000.00000045                     ASTSR/ASTEN = 0000000F: IPL  =          00000008  PCBB = 00000000.281B6080  PRBR = FFFFFFFF.8203E000 : PTBR = 00000000.0001653F  SCBB = 00000000.00001A8B  SISR = 00000000.00000100 : VPTB = FFFFFEFC.00000000  FPCR = 08000000.00000000  MCES = 00000000.00000000     )     KSP              =  00000000.7FF87C78 )     ESP              =  00000000.7FF8C000 )     SSP              =  00000000.7FF9CC80 )     USP              =  00000000.7ADD7380   B OpenVMS Operating System, Version V8.2     -- System Dump Analysis? 26-AUG-2006 05:12:40.88                              Page     4 2 CPU 00 Processor state at time of FREWSLX bugcheck        6                 No spinlocks currently owned by CPU 00  B OpenVMS Operating System, Version V8.2     -- System Dump Analysis? 26-AUG-2006 05:12:40.88                              Page     5  Process Stacks (on CPU 00)      ! Current Operating Stack (Kernel): =                        00000000.7FF87C58    00000000.0010AF9C =                        00000000.7FF87C60    FFFFFFFF.801779D8  MMG$PAGEFAULT_C+004F8 =                        00000000.7FF87C68    00000000.000DDF68 
 MONITOR+CDF68 =                        00000000.7FF87C70    00000000.00000000 =                 SP =>  00000000.7FF87C78    00000000.00000001 =                        00000000.7FF87C80    7FF87E00.81C51B18  FREE_ENTRY+00040=                        00000000.7FF87C88    00000000.00000000 =                        00000000.7FF87C90    10180000.00000000 =                        00000000.7FF87C98    00000000.00000000 =                        00000000.7FF87CA0    FFFFFFFF.81CEC498 
 MMG$PAGEFAULT =                        00000000.7FF87CA8    00000000.00000000 =                        00000000.7FF87CB0    00000000.00001FFF  CWLNM$K_STEADYSTATE_SIZE+00017=                        00000000.7FF87CB8    00000000.0036E000 =                        00000000.7FF87CC0    00000000.00000000 =                        00000000.7FF87CC8    00000000.7FF87E00 =                        00000000.7FF87CD0    20000000.00000203  REG$_REQUEST=                        00000000.7FF87CD8    00000000.7FF87D60 =                        00000000.7FF87CE0    FFFFFFFF.81C081A0 
 SCH$GL_PCBVEC =                        00000000.7FF87CE8    FFFFFFFF.8014E950  SCH$DELETE_CALLBACK_C+00134 =                        00000000.7FF87CF0    FFFFFFFF.8014E8E0  SCH$DELETE_CALLBACK_C+000C4 =                        00000000.7FF87CF8    FFFFFFFF.81CE5260  SCH$GR_SCHEDULER_LINKAGE_SECT =                        00000000.7FF87D00    00000000.0036E000 =                        00000000.7FF87D08    00000000.00000000 =                        00000000.7FF87D10    00000000.7FF87E00 =                        00000000.7FF87D18    20000000.00000203  REG$_REQUEST=                        00000000.7FF87D20    00000000.7B44E158  SPISHR+20158=                        00000000.7FF87D28    00000000.0014A024 =                        00000000.7FF87D30    00000000.000DDF68 
 MONITOR+CDF68 =                        00000000.7FF87D38    00000000.00000000 =                        00000000.7FF87D40    00000000.7B43E620  SPISHR+10620=                        00000000.7FF87D48    00000000.00000001 =                        00000000.7FF87D50    00000000.0010AF9C =                        00000000.7FF87D58    00000000.7FF87EF0 =                        00000000.7FF87D60    00000000.00000000 =                        00000000.7FF87D68    00000000.0010AF9C =                        00000000.7FF87D70    00000000.7FF87EF0 =                        00000000.7FF87D78    00000000.7FF87EF0 B                        00000000.7FF87D80    FFFFFFFF.827C0EC0  PCB=                        00000000.7FF87D88    00000000.00438028 =                        00000000.7FF87D90    00000000.00000003 =                        00000000.7FF87D98    00000000.7B44E000  SPISHR+20000=                        00000000.7FF87DA0    FFFFFFFF.FFF35FD8 =                        00000000.7FF87DA8    00000000.00000001 =                        00000000.7FF87DB0    00000000.00000000 =                        00000000.7FF87DB8    FFFFFFFF.81C081A0 
 SCH$GL_PCBVEC =                        00000000.7FF87DC0    00000000.00000000 =                        00000000.7FF87DC8    FFFFFFFF.81C10068  MMG$GL_PAGE_SIZE=                        00000000.7FF87DD0    00000000.7FFF0278 
 CTL$GL_PCB=                        00000000.7FF87DD8    00000000.00001FFF  CWLNM$K_STEADYSTATE_SIZE+00017=                        00000000.7FF87DE0    FFFFFFFF.81C10078  MMG$GL_BWP_MASK =                        00000000.7FF87DE8    00000000.00000001 =                        00000000.7FF87DF0    00000000.00000001 =                        00000000.7FF87DF8    00000000.7FF87EF0   B OpenVMS Operating System, Version V8.2     -- System Dump Analysis? 26-AUG-2006 05:12:40.88                              Page     6  Process Stacks (on CPU 00)      =                        00000000.7FF87E00    00000000.0036E000 =                        00000000.7FF87E08    00000000.00002000  UCB$M_CB_FORCE_ERROR=                        00000000.7FF87E10    00000000.0014A028 =                        00000000.7FF87E18    00000000.7FF87ED4 =                        00000000.7FF87E20    00000000.002EE004 =                        00000000.7FF87E28    00000000.0014A024 =                        00000000.7FF87E30    00000000.7B42E0A0  SPISHR+000A0=                        00000000.7FF87E38    20000000.00000203  REG$_REQUEST=                        00000000.7FF87E40    00000000.00000001 =                        00000000.7FF87E48    00000000.00000004 =                        00000000.7FF87E50    00000000.00000016 =                        00000000.7FF87E58    00000000.7FF87ED4 =                        00000000.7FF87E60    00000001.0000101B  WCB$M_CONTROL+0001B =                        00000000.7FF87E68    7B44E158.002EE004  SPISHR+20158E                        00000000.7FF87E70    00000000.7B42E000  SPISHR =                        00000000.7FF87E78    00000000.7B45EB94  SPISHR+30B94=                        00000000.7FF87E80    00000000.7B43E1F0  SPISHR+101F0=                        00000000.7FF87E88    00000000.0010AF9C =                        00000000.7FF87E90    002EE004.00000000 =                        00000000.7FF87E98    00000000.0014A024 =                        00000000.7FF87EA0    00000000.7B45EA14  SPISHR+30A14=                        00000000.7FF87EA8    00000000.7B43E1C0  SPISHR+101C0=                        00000000.7FF87EB0    00000000.7B45E62C  SPISHR+3062C=                        00000000.7FF87EB8    00000000.7B43E100  SPISHR+10100B                        00000000.7FF87EC0    001142E4.827C0EC0  PCB=                        00000000.7FF87EC8    00000000.00000000 =                        00000000.7FF87ED0    0014A024.00000080 =                        00000000.7FF87ED8    00000000.00000000 =                        00000000.7FF87EE0    00000000.00000000 =                        00000000.7FF87EE8    00000000.00000000 =                        00000000.7FF87EF0    00000000.7B43E100  SPISHR+10100=                        00000000.7FF87EF8    00000000.00000000 =                        00000000.7FF87F00    00000080.00000008 =                        00000000.7FF87F08    00000000.00000000 =                        00000000.7FF87F10    00104D50.001140A4 =                        00000000.7FF87F18    00000000.000118E0 
 MONITOR+018E0 =                        00000000.7FF87F20    FFFFFFFF.00000001 =                        00000000.7FF87F28    00000000.7B43E100  SPISHR+10100=                        00000000.7FF87F30    FFFFFFFF.800BC090 $ __RELEASE_SERVICE_ERROR_EXCEPT+002B0=                        00000000.7FF87F38    00000000.00000003 =                        00000000.7FF87F40    FFFFFFFF.81CCB660 
 EXE$CMODEXECX B                        00000000.7FF87F48    FFFFFFFF.827C0EC0  PCB=                        00000000.7FF87F50    00000000.00000000 =                        00000000.7FF87F58    00000000.00070080 
 MONITOR+60080 =                        00000000.7FF87F60    00000000.7FF87FC0 =                        00000000.7FF87F68    00000000.00000080 =                        00000000.7FF87F70    00000000.00CE8072 =                        00000000.7FF87F78    00040000.00000000  REG$M_GENERICEXECUTE=                        00000000.7FF87F80    00000000.000DDF68 
 MONITOR+CDF68 =                        00000000.7FF87F88    00000000.00000000 =                        00000000.7FF87F90    00000000.00000000 =                        00000000.7FF87F98    00000000.7ADD7390 =                        00000000.7FF87FA0    00000000.00000000 =                        00000000.7FF87FA8    00000000.00000001   B OpenVMS Operating System, Version V8.2     -- System Dump Analysis? 26-AUG-2006 05:12:40.88                              Page     7  Process Stacks (on CPU 00)      =                        00000000.7FF87FB0    00000000.00010000  IPCF$M_INPLST_NODENAME=                        00000000.7FF87FB8    00000000.00000000 =                        00000000.7FF87FC0    00000000.00013120  V_LAN$REPORT_EVENT+001E0=                        00000000.7FF87FC8    00000000.00000000 =                        00000000.7FF87FD0    00000000.000118E0 
 MONITOR+018E0 =                        00000000.7FF87FD8    00000000.00104D50 =                        00000000.7FF87FE0    00000000.00104D50 =                        00000000.7FF87FE8    00000000.00000000 =                        00000000.7FF87FF0    00000000.7B49E148  SPISHR+70148=                        00000000.7FF87FF8    00000000.0000001B   B OpenVMS Operating System, Version V8.2     -- System Dump Analysis? 26-AUG-2006 05:12:40.88                              Page     8  Process Stacks (on CPU 00)       Executive Stack =                        00000000.7FF8BFE0    00000000.00000001 =                        00000000.7FF8BFE8    00000000.000F8908 =                        00000000.7FF8BFF0    FFFFFFFF.802A1128  SYS$PARSE_C+00078 =                        00000000.7FF8BFF8    00000000.0000001B '                 SP =>  (Stack is Empty)   B OpenVMS Operating System, Version V8.2     -- System Dump Analysis? 26-AUG-2006 05:12:40.88                              Page     9  Process Stacks (on CPU 00)       Supervisor Stack=                        00000000.7FF9CC60    00000000.00000000 =                        00000000.7FF9CC68    00000000.7B96E008  CMA$TIS_SHR+10008 =                        00000000.7FF9CC70    00000000.7AF9EEA4 	 DCL+92EA4 =                        00000000.7FF9CC78    00000000.0000001B =                 SP =>  00000000.7FF9CC80    FFFFFFFF.81CF8F80 
 SYS$PUTMSG=                        00000000.7FF9CC88    00000000.00000000 =                        00000000.7FF9CC90    00000000.7AF84348 	 DCL+78348 =                        00000000.7FF9CC98    00000000.7AF91EA4 	 DCL+85EA4 =                        00000000.7FF9CCA0    00000000.7AF13208 	 DCL+07208 =                        00000000.7FF9CCA8    00000000.7AF98C98 	 DCL+8CC98 =                        00000000.7FF9CCB0    00000000.00000000 =                        00000000.7FF9CCB8    FFFF8000.00000005 =                        00000000.7FF9CCC0    00000000.7AF8B838 	 DCL+7F838 =                        00000000.7FF9CCC8    00000000.00000000 =                        00000000.7FF9CCD0    00000000.7AFB8EB2 	 DCL+ACEB2 =                        00000000.7FF9CCD8    00000000.00000000 =                        00000000.7FF9CCE0    00000000.7FFCF800 
 MMG$IMGHDRBUF =                        00000000.7FF9CCE8    00000000.00000000 =                        00000000.7FF9CCF0    00000000.00000001 =                        00000000.7FF9CCF8    00000000.7FF9CDE8 =                        00000000.7FF9CD00    00000000.7FF9DDF0 =                        00000000.7FF9CD08    00000000.7FFA4F28 =                        00000000.7FF9CD10    00000000.7FFCDBE8  CTL$AG_CLIDATA+00180=                        00000000.7FF9CD18    00000000.7FFCDA68  CTL$AG_CLIDATA=                        00000000.7FF9CD20    00000000.7AF111C0 	 DCL+051C0 =                        00000000.7FF9CD28    00000000.00000000 =                        00000000.7FF9CD30    00000000.7AF105E0 	 DCL+045E0 =                        00000000.7FF9CD38    00000000.7FF9DDF0 =                        00000000.7FF9CD40    7AFB8EB2.0000000F 	 DCL+ACEB2 =                        00000000.7FF9CD48    7AF10FA0.00000007 	 DCL+04FA0 =                        00000000.7FF9CD50    00000000.7AF72300 	 DCL+66300 =                        00000000.7FF9CD58    00000000.7AF0E6B0 	 DCL+026B0 =                        00000000.7FF9CD60    7ADD9127.00000000 =                        00000000.7FF9CD68    FFFF8000.000000B8 =                        00000000.7FF9CD70    00000000.7AF71934 	 DCL+65934 =                        00000000.7FF9CD78    00000000.7AE80556 =                        00000000.7FF9CD80    00000000.00000010 =                        00000000.7FF9CD88    00000000.00000000 =                        00000000.7FF9CD90    00000000.00000004 =                        00000000.7FF9CD98    00000000.00000000 =                        00000000.7FF9CDA0    00000000.00000001 =                        00000000.7FF9CDA8    00000000.7FF9CDE8 =                        00000000.7FF9CDB0    00000000.7FF9DDF0 =                        00000000.7FF9CDB8    00000000.7FFA4F28 =                        00000000.7FF9CDC0    00000000.7AF0E6B0 	 DCL+026B0 =                        00000000.7FF9CDC8    00000000.7AF105E0 	 DCL+045E0 =                        00000000.7FF9CDD0    00000000.00000000 =                        00000000.7FF9CDD8    00000000.00000018 =                        00000000.7FF9CDE0    00000000.00000000 =                        00000000.7FF9CDE8    7FF9CDF0.00001000  IRP$M_FILACP=                        00000000.7FF9CDF0    00000000.00000000 =                        00000000.7FF9CDF8    00000000.00000000 =                        00000000.7FF9CE00    00000000.00000000    ------------------------------  % Date: Sat, 26 Aug 2006 11:36:13 -0400 ' From: Dave Froble <davef@tsoft-inc.com>  Subject: Re: WWENG2.SYS 9 Message-ID: <gOqdnSpo27ta9W3ZnZ2dnUVZ_tudnZ2d@libcom.com>    William Webb wrote: 9 > On 25 Aug 2006 13:42:21 -0500, briggs@encompasserve.org # > <briggs@encompasserve.org> wrote: @ >> In article <4l4uf4F99apU1@individual.net>, Martin Vorlaender  >> <mv@pdv-systeme.de> writes: >> > Chris Scheers wrote: @ >> >> What is the latest CONDIST that had WWENG2.SYS?  (NA7xxx?) >> >J >> > The DECserver 700 software (UPI XA5AA) Version 1.1C was last included, >> > in the June 2003 VAX & Alpha ConDist's. >>G >> I imagine that was WWENG1.SYS or WWENG.SYS or some such.  There were H >> two versions of DECserver 700 software.  One was LAT only.  The otherH >> was the NAS software and supported LAT, TCP, IPX and PPP.  You neededF >> to have either a memory upgrade or a later version of the DECserver# >> hardware to run the latter code.  >>= >> WWENG2.SYS is the code that supports LAT, TCP, IPX and PPP  >>D >> Having looked on CONDIST for the DECserver NAS software once uponE >> a time, it is my recollection that the software on ConDist doesn't  >> have WWENG2.  >> > G > SInce I got the 2.6 GB for the TF85 capacity correctly off the top of @ > my head, heres another shot at an off-the-cuff answer based on' > experiences of close to a decade ago:  > G > WWENG2.SYS as the DNAS software discussed in this thread required 4MB  > of memory to run.  >  > WWWebb  G Not a big problem.  The DECserver 700 uses 72 pin SIMMs, the ones with  F parity bits if I remember correctly.  (It's been a long while.)  Same H SIMMs the 486 based DEC PCs used.  Old stuff, but if you can find some,  just plug them in.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Sat, 26 Aug 2006 11:48:25 -0400 / From: "William Webb" <william.w.webb@gmail.com>  Subject: Re: WWENG2.SYS I Message-ID: <8660a3a10608260848w13d3eb17ke79ae335b43ee340@mail.gmail.com>   4 On 8/26/06, Dave Froble <davef@tsoft-inc.com> wrote: > William Webb wrote: ; > > On 25 Aug 2006 13:42:21 -0500, briggs@encompasserve.org % > > <briggs@encompasserve.org> wrote: A > >> In article <4l4uf4F99apU1@individual.net>, Martin Vorlaender   > >> <mv@pdv-systeme.de> writes: > >> > Chris Scheers wrote: B > >> >> What is the latest CONDIST that had WWENG2.SYS?  (NA7xxx?) > >> >L > >> > The DECserver 700 software (UPI XA5AA) Version 1.1C was last included. > >> > in the June 2003 VAX & Alpha ConDist's. > >>I > >> I imagine that was WWENG1.SYS or WWENG.SYS or some such.  There were J > >> two versions of DECserver 700 software.  One was LAT only.  The otherJ > >> was the NAS software and supported LAT, TCP, IPX and PPP.  You neededH > >> to have either a memory upgrade or a later version of the DECserver% > >> hardware to run the latter code.  > >>? > >> WWENG2.SYS is the code that supports LAT, TCP, IPX and PPP  > >>F > >> Having looked on CONDIST for the DECserver NAS software once uponG > >> a time, it is my recollection that the software on ConDist doesn't  > >> have WWENG2.  > >> > > I > > SInce I got the 2.6 GB for the TF85 capacity correctly off the top of B > > my head, heres another shot at an off-the-cuff answer based on) > > experiences of close to a decade ago:  > > I > > WWENG2.SYS as the DNAS software discussed in this thread required 4MB  > > of memory to run.  > > 
 > > WWWebb > H > Not a big problem.  The DECserver 700 uses 72 pin SIMMs, the ones withG > parity bits if I remember correctly.  (It's been a long while.)  Same I > SIMMs the 486 based DEC PCs used.  Old stuff, but if you can find some,  > just plug them in. >  > --6 > David Froble                       Tel: 724-529-0450@ > Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com > DFE Ultralights, Inc.  > 170 Grimplin Road  > Vanderbilt, PA  15486  >   / You do remember correctly.  72 pin parity SIMMS . Let's see if my old brain gets three in a row.  ! I'm thinking that they were 60ns.    WWWebb --  ! I'm no longer job-hunting, folks.   F Thanks to all those who expressed concern and sent me possibilities to investigate.   ------------------------------  % Date: Sat, 26 Aug 2006 12:43:56 -0400 ' From: Dave Froble <davef@tsoft-inc.com>  Subject: Re: WWENG2.SYS 9 Message-ID: <p7-dnR4d46U45W3ZnZ2dnUVZ_o-dnZ2d@libcom.com>    William Webb wrote: 6 > On 8/26/06, Dave Froble <davef@tsoft-inc.com> wrote: >> William Webb wrote:< >> > On 25 Aug 2006 13:42:21 -0500, briggs@encompasserve.org& >> > <briggs@encompasserve.org> wrote:B >> >> In article <4l4uf4F99apU1@individual.net>, Martin Vorlaender! >> >> <mv@pdv-systeme.de> writes:  >> >> > Chris Scheers wrote:C >> >> >> What is the latest CONDIST that had WWENG2.SYS?  (NA7xxx?)  >> >> > E >> >> > The DECserver 700 software (UPI XA5AA) Version 1.1C was last   >> included / >> >> > in the June 2003 VAX & Alpha ConDist's.  >> >> J >> >> I imagine that was WWENG1.SYS or WWENG.SYS or some such.  There wereK >> >> two versions of DECserver 700 software.  One was LAT only.  The other K >> >> was the NAS software and supported LAT, TCP, IPX and PPP.  You needed I >> >> to have either a memory upgrade or a later version of the DECserver & >> >> hardware to run the latter code. >> >> @ >> >> WWENG2.SYS is the code that supports LAT, TCP, IPX and PPP >> >> G >> >> Having looked on CONDIST for the DECserver NAS software once upon H >> >> a time, it is my recollection that the software on ConDist doesn't >> >> have WWENG2. >> >>  >> >J >> > SInce I got the 2.6 GB for the TF85 capacity correctly off the top ofC >> > my head, heres another shot at an off-the-cuff answer based on * >> > experiences of close to a decade ago: >> >J >> > WWENG2.SYS as the DNAS software discussed in this thread required 4MB >> > of memory to run. >> > >> > WWWebb  >>I >> Not a big problem.  The DECserver 700 uses 72 pin SIMMs, the ones with H >> parity bits if I remember correctly.  (It's been a long while.)  SameJ >> SIMMs the 486 based DEC PCs used.  Old stuff, but if you can find some, >> just plug them in.  >> >> -- 7 >> David Froble                       Tel: 724-529-0450 A >> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com  >> DFE Ultralights, Inc. >> 170 Grimplin Road >> Vanderbilt, PA  15486 >> > 1 > You do remember correctly.  72 pin parity SIMMS 0 > Let's see if my old brain gets three in a row. > # > I'm thinking that they were 60ns.   I Most SIMMs from that time were 60ns and 70ns, at least the ones I got my  E hands upon.  I seem to remember that 70ns was rather common, and the  # 60ns were 'high speed' pieces.  :-)    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------   End of INFO-VAX 2006.475 ************************