1 INFO-VAX	Fri, 25 Aug 2006	Volume 2006 : Issue 473       Contents: Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day 0 Here you can read books free and buy all tickets Hobbyist Media available( Mystery multiple TCP connections dropped= Re: OpenVMS Integrity install CD's and layered products media  Re: Personal note - goodbye ! $ Re: Printing to a HP LaserJet 2605dn' Removing a member from bound volume set 2 Re: SEPPUCLU bugcheck introducing new cluster node4 Re: Thoughts on the book: DEC is dead, long live DEC4 Re: Thoughts on the book: DEC is dead, long live DEC4 Re: Thoughts on the book: DEC is dead, long live DEC Re: VMS in The DA ! what is capacity of a TF85 drive? % Re: what is capacity of a TF85 drive?  Re: WWENG2.SYS Re: WWENG2.SYS Re: WWENG2.SYS2 Re: X-terminal connects get hosed, requires reboot2 Re: X-terminal connects get hosed, requires reboot2 Re: X-terminal connects get hosed, requires reboot2 Re: X-terminal connects get hosed, requires reboot  F ----------------------------------------------------------------------    Date: 25 Aug 2006 07:30:31 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) " Subject: Re: Alpha remembrance day3 Message-ID: <obVWDeZ7oQMY@eisner.encompasserve.org>   \ In article <44EDFED7.BF2B3782@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > I > Note that initial Alpha may have been 64 bit capable, but the operating E > systems weren't yet 64 bit capable, so there was really no point in H > building machines configurable with huge amounts of memory when the OS > couldn't support it.  E   digital OSF/1, later rebadged digital UNIX and then Tru64 UNIX, was    64 bit from first ship.    ------------------------------    Date: 25 Aug 2006 07:00:36 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayB Message-ID: <1156514436.886380.163640@74g2000cwt.googlegroups.com>   Bill Todd wrote: > Andrew wrote:  >  > ...  > K > >>> The reality was that the top of the Alphaserver range for most of the M > >>> 90's was only really equivalent to a sun E4500/4000 (12 CPU's, 12GB RAM  > >>> redundant I/O). L > >> The discussion (at least before you stuck your incompetent oar into it)J > >> had nothing to do with Alpha vs. Sun or about the '90s:  it was aboutL > >> whether 64-bit support was of any significance before *now* (as you canJ > >> still ascertain - assuming that you are capable of extracting meaningJ > >> from simple text, though that fact is clearly not yet in evidence) byI > >> returning to the start of this post and perusing the embedded quoted  > >> material there).  > >> > > 4 > > Of course it was about Alpha vs the competition. > F > No, shithead.  Just because that's what *you* want to talk about nowH > doesn't make it the subject of the sub-thread which you are attemptingI > to divert:  that subject was (and still is) defined by its pre-existing I > content, as augmented by refutations of your more egregious drivel when  > that seemed appropriate. >  > ...  > & > >>   You don't need 64bit support toC > >>> have a single OS instance that adresses more than 4GB of RAM. I > >> Since I already pointed out Pentium's support for 64 GB of RAM since J > >> 1996 (a feature also supported by NT, of course), I'm afraid that oneJ > >> can't consider the above as anything resembling a new contribution to > >> this conversation.  > >>H > > http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx > >  > > Sorry wrong again. > I > At the risk of being pedantic, to be wrong 'again' I would already have A > had to have been wrong in the current discussion at least once.  >   F Well if you can point to one single part of this thread where you have3 been right then I will be happy to buy you a sweet.   E As it is you have lurched from irrelevance to rudness stopping off in # between for a bit of factual error.     6 >   The Pentium may well have supported 64GB of RAM in/ > > 1996 but but Windows NT Server 4 never did.  > I > By George, it appears that you may be right for once:  I thought that I G > remembered some trans-4GB facilities (which Win2K later cleaned up as H > its AWE mechanisms) being introduced in some flavor(s) of NT V4, but I+ > can't find any mention of them right now.  >  > > Neither did Windows 2000,  > J > Wrong (again).  While Microsoft *nominally* supports only up to 32 GB ofF > RAM in Win2K Datacenter, had you even investigated the link that youI > yourself provided you would have seen that this was because of the lack D > of available hardware to test on 64 GB systems, and indeed "InsideJ > Windows 2000" confirms that the Win2K code supports up to the full 64 GB > system size.  G How amusing, it was you who claimed that 64GB was addressable by NT. If B you will note I pointed out that this wasn't true for either NT orG Win2K I didn't say anything about >4GB. Thanks now you have just proved E that not only are unable to read my post but your also failed to read 	 your own.   D As I said in an earlier post the joy of this is in watching the hole3 you are digging for yourself get deeper and deeper.    >  > >>   SomethingL > >>> like Oracle consists of multiple processes but these processes need toJ > >>> access the SGA which is where being able to support more than 4GB of/ > >>> RAM for a single process becomes usefull. M > >> Or, in the case of NT, instead uses a single process and maps around the K > >> larger-than-4GB physical RAM that it's allowed to manage - an approach G > >> often significantly more efficient than cobbling together multiple G > >> separate processes in the Unix idiom (an idiom even more laughably L > >> expressed in fumbling attempts to compensate for the lack of in-processF > >> support for parallelism in the days before it had any support forM > >> asynchrony or system-level process threading) but still not as efficient ) > >> as a 64-bit single-process approach.  > >> > > K > > This was impossible with NT because NT did not support more than 4GB of F > > physical memory. Of course 2003 is an NT derivative but it is also3 > > 64bit so your point lacks any relevance at all.  > H > How about Win2K, moron?  Even if the 32GB limitation that you believedI > existed were real, 32 GB would be more than enough to make the approach  > described above relevant.  >   E I will leave you to work out why in the light of your earlier mistake  this is highly amusing.    > > I > > You also seem to have entirely missed the whole user level and kernel J > > level threads support which has been inherant in many UNIX's since the > > early 1990's.  > I > Hardly, since I referred explicitly to the time before they appeared (a I > period of about 15 years after VMS had flexible asynchronous facilities F > for parallelizing operations within a single process).  Since it wasI > just a passing reference to a similarly-crippled Unix idiom the precise I > dates weren't the issue (though dates obviously aren't your strong suit B > anyway in this discussion, muddling their significance as you've > consistently attempted to).  >  > ...  > L > >>> In reality Oracle TPC-C platforms hit a wall at about 40-50K TPM where> >>>> 4GB SGA's became a necessity. The problem was that the 8400 only ever managed about 50% of this. Sequent through the use of OPS in a box demonstrated how with multiple Oracle instances each with its own SGA you could defeat this limit on a 32bit platform.L > >>> It is hard not to conclude from your posts that you don't reallly have! > >>> a good grasp of the subject H > >> Since you have so far not managed to draw any competent conclusions@ > >> during this discussion, I'd hardly expect you to begin now. > >> > > J > > So provide some examples of the incompetent conclusions that you claim > > I have or havn't drawn.  > H > I've provided them as they occurred, asshole.  Refresh what passes for7 > your memory if you've managed to forget them already.  >  > >> ... > >>I > >>>> That 128 GB system, idiot, was a full 6 years ago (not that 64-bit N > >>>> operation wasn't useful with as little as 8 or 16 GB of RAM, of course,L > >>>> which takes us back a bit over 10 full years).  Whereas the drivel toO > >>>> which my earlier response was directed (as distinct from your own drivel O > >>>> to which *this* response is directed) alleged that only *now* was 64-bit 1 > >>>> support becoming interesting to customers. : > >>> You seem again to have compeletely missed the point.K > >> No, you fucking idiot:  the point (which once again you can see quoted J > >> right up at the start of this post) was the ridiculous assertion thatD > >> 64-bit support was only starting to become interesting *today*. > >> > > J > > And your claim unless you had forgotten was that 64bit was interesting > > a lot earlier than "today".  > G > A claim which even your own incompetent posts have managed to support I > more than adequately - thereby raising the question of why the hell you H > chimed in at all, save that crapping all over other people's backyards( > seems to be your main purpose in life.     regards  Andrew Harrison    ------------------------------    Date: 25 Aug 2006 06:46:26 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayB Message-ID: <1156513586.218485.304240@75g2000cwc.googlegroups.com>   Hoff Hoffman wrote: J > Now it's "balance"?  This being the fall-back marketeering position, eh? > K >    Having 64-bit virtual addressing was and is worthwhile out of the box.    Sort of.  F The biggest benefit is being able to address more than 4GB of RAM withE a single process. There are other benefits but they and being able to < address more then 4GB may come with an expense tag attached.  @ 64bit executables are larger, use more memory and are less cacheG friendly their 32bit equivalents. Some tests have shown up to 20% worse F performance for 64bit versions of common utilities compared with their 32bit counterparts.  > I >    Yes, having more PHYSICAL memory is good, and having more and faster N > processors is good, and there are definitely design issues around having theK > proper speeds and feeds throughout a high-end box, but simply having more P > VIRTUAL memory is also good, and that's where the extra address bits first go. >   D If you look at most vendors porting guides being able to use >4GB of@ RAM per process is top of the list for reasons to port to 64bit.  K >    That's where a number of VAX users slammed into the virtual addressing M > limits.  VAX users.  Not Alpha users.  VAX.  That's how far back this goes.  > O >    Having the address space makes it easier to design and maintain and manage L > the software, as anyone that remembers, for instance, TKB and overlays, orK > swapping in memory segments on an Apple II, or dealing with the limits of Q > various 32-bit or even those early Unix systems that didn't have virtual memory  > will tell you.  E That goes back rather further than a discussion about Alpha's demise. @ As far as I know the first UNIX for VAX hardware which supportedE virtual memory 3BSD was released in 1979.  This predates the start of D most of the large commercial UNIX families in existence today. SunOS@ 1.0 was released in 1982 and was based on 4.1 BSD. HP-UX 1.0 was released in 1983.    regards  Andrew Harrison    ------------------------------    Date: 25 Aug 2006 07:11:53 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayB Message-ID: <1156515113.048899.144820@75g2000cwc.googlegroups.com>   Dave Froble wrote:@ > Andrew wrote:^h^h^h^h^h^h^h^h^h^h^h^h^hBlithering idiot wrote: > I > > Of course it was about Alpha vs the competition. If there had been no K > > competition then Alpha probably would have been a sucess. The fact that I > > there was and the reasons why Alpha wasn't competitive go back to the 8 > > core of this discussion.. What a bizarre suggestion. > > > You just don't get it, do you?  Or maybe just don't want to. > D > Alpha was successful.  It didn't die from lack of success, it died> > solely because Compaq didn't want to be in the CPU business.  F Alpha was not sucessfull commercially, it didn't make Digital money inA fact it was one of the contributors to the demise of Digital. And F because of Alpha's lack of sucess Compaq did not want to be in the CPU	 business.   0 You seem to have got the chicken before the egg.   > E > It's actually a bit too bad for Intel.  Why?  If the high end users E > still had Alpha, maybe Opteron wouldn't have been the success is is A > today.  Without the overwhelming demand AMD just might not have B > succeeded with 'little EV7'.  Intel then might have succeeded in# > foisting the itanic on the world.  >   G Interesting theory but Opteron didn't take share in Alpha's traditional C markets except possibly HPC but then most of that had gone to Intel E anyway. Opteron took share from 1-4 way 32bit Xeon's and having Alpha F alive and kicking in its portfolio would have had absolutely no impact on Opterons rise.   B Until recently there was no such thing as a high end Opteron basedF system unless you count Cray which I don't and in reality no one would8 call the Sun X4600 (16 Opteron Cores) a high end system.  J > Keep in mind the users such as Sandia Labs that wanted to continue using > Alpha.  @ While I am sure that Intel does care if these all go Opteron theG reality is they care very little compared with the inroads that Opteron 1 has made in the 1-4 way commercial server market.    regards  Andrew Harrison    ------------------------------    Date: 25 Aug 2006 09:24:58 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayB Message-ID: <1156523097.933890.308920@75g2000cwc.googlegroups.com>   JF Mezei wrote:  > Andrew wrote: I > > Of course it was about Alpha vs the competition. If there had been no K > > competition then Alpha probably would have been a sucess. The fact that I > > there was and the reasons why Alpha wasn't competitive go back to the 8 > > core of this discussion.. What a bizarre suggestion. > C > Alpha was competitive. Digital wasn't competitive. Digital didn't G > market. Digital was in a downward spiral. Palmer was actively killing I > Digital. Even if they had had an Alpha at 5ghz back i 1995 with 600gigs E > of memory in a PC form factor and priced at $2000, I am not sure it I > would have been a success because Digital wouldn't have marketed it and J > people wouldn't know which OS to put on it. VMS users were first told toJ > migrate to Digital Unix, and then told to go NT, but NT didn't have many< > apps on Alpha due to lack of growth and lack fo marketing.  D Alpha as a CPU was competitive, Alpha in systems wasn't. Digital didE not have a competitive low end server platform for Alpha and the same F was also true for the 8400/8200. This ment that at the low end DigitalD lost out to a number of other vendors who had systems that were fastG enough but which were available at a price point that Digital could not G touch. While at the high end the 8400 scaled poorly compared with other D vendors servers and was expensive and ended up being outperformed byC cheaper systems from other vendors with similar or small numbers of  extra CPU's.  F Now you are welcome to split Alpha the CPU away from the Alpha ServersF and Workstations but a CPU without a package is the most uncompetitive entity possible.  A You complain about Digitals marketing but in fact they ran a very G sucessfull campaign emphasising the 64bit nature of Alpha, the notional ? advantages that offered and Alpha's performance.  It was partly ( responsible for Alpha's initial sucesss.   regards  Andrew Harrison    > E > Digital continued to exist beyond 1987 because of momentum/steam of F > previous years, and to show much much there was, it took 6 years for. > Palmer to kill and already weakened Digital. > F > > Since the thread was about the demise of Alpha which clearly isn't* > > happening now, it has already happened > G > This depends on viewpoints. Consider that for many years, despite the F > June 21 2001 genocide announcement, Alpha had better sales than thatF > IA64 contraption. HP is having to stop Alpha sales despite continued@ > demand in order to protect the image of the failed IA64 thing. > H > Yes, it is a sign that that particular marketplace is now down to justF > the remaining installed base who prefer to stick to Alpha instead ofB > being forced to migrate (costly/time consuming exercise) to someH > unwanted platform whose future is even more uncertain than Alpha's. SoH > the VMS marketplace may not be so healthy. But Alphga still got enoughG > steam in it to still be something worth selling despite it not longer  > being developped.    ------------------------------    Date: 25 Aug 2006 01:50:10 -0700' From: "littlte woman" <faguge1@126.com> 9 Subject: Here you can read books free and buy all tickets A Message-ID: <1156495810.396585.21950@74g2000cwt.googlegroups.com>   0 Here you can read books free and buy all tickets you can find all tickets here:& http://allticket.yourfreewebspace.com/ you can read books free:' http://onlinebook.yourfreewebspace.com/ ' http://bookonline.yourfreewebspace.com/    ------------------------------    Date: 25 Aug 2006 08:36:57 -0700+ From: "bob lombard" <bob.lombard@gmail.com> ! Subject: Hobbyist Media available C Message-ID: <1156520217.701136.245120@h48g2000cwc.googlegroups.com>   G Hi - I'm trying to get a media kit for the hobbyist program. Have tried C to contact the hobbyist website w/o response, although its happy to @ take your order, the process seems to die there (CC does not get charged, no CD''s, etc).  E Lack of recent discussion leads me to ask if the program is dead, are B the licenses still available, are there other avenues to gettign a3 hobbyist system running, if only on SIMH or CHARON?   ! -bob  (blombard at usarc dot org)    ------------------------------    Date: 25 Aug 2006 08:33:38 -0700$ From: "AEF" <spamsink2001@yahoo.com>1 Subject: Mystery multiple TCP connections dropped A Message-ID: <1156520018.781034.83350@74g2000cwt.googlegroups.com>   B I run a trading application that sends data to multifeed data feedF distributers. It's a little complicated and I'll try to describe it as clearly as possible.  C The first two paragraphs below describe the overall set up. I'm not F sure how relevant they really are. The third and fourth paragraphs are the actual problem.   D The back-end runs on several MicroVAX systems. There is the host, orB market system, on which the market exists. Connected to the marketG system are DECnet Phase IV end nodes (which are also MicroVAX systems). A The market node keeps the end nodes up to date with regard to the < market (prices, who's offering what, who's bidding for what,> executions, etc.). On these end nodes run trader processes andA data-feed processes. Each data-feed process maintains a "page" of B issues, bids, and offers. The page data is sent to "multifeed DFD"F systems via TCP connections. Three are in NY and one is in London. TheE ones in NY are various combinations of WinXP or Win2k running on Dell C Optiplex 620 or Compaq DL580 boxes. I'm don't know about the London C system. (These multifeeds pass the page data onto other systems and % eventually to brokers and customers.)   F Anyway, for one of my markets I have four pages: 45 thru 48. Each pageD runs on a separate end node MicroVAX. (The MicroVAX systems for thisE market are all in London.) Each end-node MicroVAX has a data-feed job E that sends the page data to all four multifeeds. Now, on both Tuesday F and Thursday mornings, at about 7:15 or 7:30 London time, I lose pagesE 46 and 47 on all three NY multifeed systems, but these same pages are + still running fine to the London multifeed.   E So the page 46 job was running on one (London) MicroVAX, sending data F to all 4 Multifeeds, when suddenly all within a tenth of a second, the@ TCP connections to the 3 NY multifeeds dropped, while the fourthB connection to the London multifeed stayed up. The same exact thingE happened with page 47 which runs on another (London) MicroVAX sending @ data to the same 4 multifeeds, at the same time that the page 46 connections went down!  E Does anyone have a clue as to what could be causing this? In summary, G each MicroVAX is sending data for its page via TCP connections (telnet, G whatever) to four multifeeds. With 4 MicroVAX systems that's a total of E 16 connections. On each of the two of the MicroVAXes running jobs for G pages 46 and 47, the three connections (total of 6) suddenly die within F a tenth of a second of each other. The same pages had the same problemA on both Tuesday and Thursday mornings (London time). (The page-46 E MicroVAX system is running VMS v6.1 and the page-47 system is running 
 VMS v6.2).  A I know this will appear confusing at first read. I'll be happy to ? answer any questions to clear up any confusion as to the setup.   G Thanks in advance to all who try to come up with some clues and also to - those who actually read this far in the post!    AEF    ------------------------------    Date: 25 Aug 2006 07:31:25 -0700; From: "johnhreinhardt@yahoo.com" <johnhreinhardt@yahoo.com> F Subject: Re: OpenVMS Integrity install CD's and layered products mediaB Message-ID: <1156516285.037332.270690@75g2000cwc.googlegroups.com>   johnhreinhardt@yahoo.com wrote: F > I'm not sure exactly how they are structured - my only experience isH > with the VAX/Alpha distribution.  I have a need now to borrow a set ofC > the Integrity OpenVMS V8.2-1 (and/or V8.2 or 8.3 for that matter) H > installation media and any available layered products.  Geography wiseB > I am near Cincinnati, Ohio, USA.  Any help would be appreciated.	 > Thanks.  >  >   John H. Reinhardt     F Still trying for OpenVMS Integrity media here.  Anybody that can spare? a set for a few days?  I'll even arrange UPS or FedEx overnight  shipping to and from (US only).    Thanks.      John H. Reinhardt    ------------------------------  % Date: Fri, 25 Aug 2006 15:52:47 +0300 7 From: "Guy Peleg" <guy.peleg@remove_this_header@hp.com> & Subject: Re: Personal note - goodbye !* Message-ID: <44eef2a2@usenet01.boi.hp.com>  4 "Dave Froble" <davef@tsoft-inc.com> wrote in message3 news:Pc2dnekOIPoFwnPZnZ2dnUVZ_oydnZ2d@libcom.com...  > Guy Peleg wrote: > > Dear community,  > > H > > I wanted to let you know that I have decided to leave HP (I chose to leave  > > onJ > > my own). I have been part of DEC/CPQ/HP for almost 10 years, 6 of them in > > VMS engineering. > F > The way you wrote the above causes me some concern.  Particularly "I, > chose to leave on my own".  I can imagine: > + > 1) Layoffs in VMS engineering are coming.  >   > 2) The end of VMS development. >  > 3) Whatever. > J > Anything you care to expound upon, or, even to tell me I'm just too damn
 > suspicious?  > ; > Regardless, thanks for the efforts.  They are apriciated.  >  > --  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   	 Hi David,   2 I mentioned that I chose to leave for two reasons:  D 1. To prevent people from thinking that something is going on within engineering.H 2. To maintain my professional name assuring I did not do anything which honored  me with a kick in the ass ;-)   E As JF said....if you are interested in more details buy me a beer ;-)    ------------------------------   Date: 25 Aug 2006 11:57:37 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)- Subject: Re: Printing to a HP LaserJet 2605dn * Message-ID: <4l86thFmoqqU1@individual.net>  9 In article <Pc2dnegOIPqi_XPZnZ2dnUVZ_oydnZ2d@libcom.com>, * 	Dave Froble <davef@tsoft-inc.com> writes: > healyzh@aracnet.com wrote: > 9 > > I personally would stay away from Xerox, how is thier L >> support of alternative OS's these days?  I know how poor thier support of >> Linux is. >>  	 >> 		Zane  > K > I've got to wonder if that's actually bad?  I guess if you're into Linux   > it may be.  I'm not. >   E While I, too, am hardly what you would call a Linux supporter, I have E to wonder how one does not support alternative OS's with a printer. I B would assume it was PostScript, like most printers today, and thus! pretty much usable with anything.    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Fri, 25 Aug 2006 02:08:09 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Removing a member from bound volume set, Message-ID: <44EE93B9.3F64AF6B@teksavvy.com>  3 Say I have a 4 disk bound volume set (MOUNT/BIND).    3 Can anyone provide a sanity check on the following:   ( -Quiesce all writing to the bound volume. -Create list of all files on relative volume 3# -Copy those files to temporary disk ) -Delete those files from bound volume set  -Dismount the bound volume set. -Mount the bound volume set with only 3 disks.L -Copy the files from the temporary disk to the now reduced 3 disk bound set. -Enable writing.    B This would allow reduction of the amount of time the disk would beH totally unavailable, even though during the operation, some web requests@ would generate a file not found if some of the HTML files aren't presently loaded.   H This is as opposed to doing a full backup and a full restore which would, put the disk off line for far longer period.    H What would happen if I were to just dismount the 4 drive set, remount it
 as 3 drives ? A Would an ANA/DISK/REPAIR of the new 3 drive volume set remove all D references (in indexf.sys and in directory files) of the files which% were in RVN3 which no longer exists ?   H At that point, if I were to mount the former RVN3 separately, would I beE able to see the individual files that are on it and then copy them to  the new 3 member Bound set ?   (this is a data disk).    C (The goal is to reduce heat/electricity consumption by removing one H drive from that set, and eventually converting that DSSI "canister" intoG a SCSI drive which can hold all my data in one drive (and hence greatly   reduce electricity/heat issues).   ------------------------------    Date: 25 Aug 2006 04:14:54 -0700/ From: "Volker Halle" <volker_halle@hotmail.com> ; Subject: Re: SEPPUCLU bugcheck introducing new cluster node B Message-ID: <1156504494.046176.15480@m79g2000cwm.googlegroups.com>   Tom,  F lets first rule out the suspicion regarding LOCKIDTBL being too small.A There was a known problem in V7.2-1 causing a LOCKMGRERR crash at E LCK$ALLOC_PAGE_C+2B8 - this was solved by VMS721_FIBRE_SCSI-V0200 and = also in V7.3 or higher, so it does not apply to your crashes.   F MONI LOCK on your nodes will show the no. of locks on each of them, ifG you want to prevent LOCKIDTBL from expanding, you need to set it higher F than the max. no. of locks seen. @AUTOGEN SAVPARAMS SETPARAMS FEEDBACKF will do this for you. It will also take care of RESHASHTBL - check the# SYS$SYSTEM:AGEN$PARAMS.REPORT file.   D I would have expected RSB$L_HASHVAL to be non-zero and have the sameG value as LKMSG$L_HASHVAL - I have to think about how these values could  possibly be different.  F The LOCKMGRERR on TROI (or one of the other nodes) happens, because itD has recieved a 'bad LKMSG' from WORF. The 'bad' part in this messageC was LKMSG$L_HASHVAL; becasue using this hash value did not find the G existing resouce block. Is WORF booting from the same system disk, i.e. F does it have the same patch status ? If there would be something wrongE with the patches on your cluster, wouldn't you expect to see the same ) type of crashes between the other nodes ?   F Did the new node work before ? Can you boot it standalone and run some@ tests involving the LAN interface (DTSEND, NCP/NCL LOOP tests) ?  C What we can try to do is to manaully repeat the steps (in the dump) 9 OpenVMS takens to locate the resource after receiving the  LKMSG$K_RMVDIR message.   G It uses the HASH value (after shifting) to locate the hash chain in the C resource hash table. It then walks that chain to find the resource:    LKMSG$L_HASHVAL = 4F02A47B  - SDA> eva (4F02A47B@-(^d32-@lck$gl_htblcnt))*8  Hex = 00000000.0000xxxx    SDA> exa @^qlck$gq_hashtbl+xxxx % FFFFFFFF.yyyyyyyy:  FFFFFFFF.7EDB75C0   - SDA> vali que/sin/list/quad FFFFFFFF.yyyyyyyy   $  Entry    Address              Flink$  -----    -------              -----0  Header   FFFFFFFF.7F7B22B8    FFFFFFFF.7EDB75C00      1.   FFFFFFFF.zzzzzzzz    00000000.00000000  9 Queue is zero-terminated, total of 1 element in the queue   E For each address shown in column 2 (excluding the Header...) line, do   $ SDA> SHOW RES/ADDR=FFFFFFFF.zzzzzzzz  > I have tested this on V8.2, but it should also work on V7.3-1.   Volker.    ------------------------------  % Date: Fri, 25 Aug 2006 04:43:23 -0400 ( From: Bill Todd <billtodd@metrocast.net>= Subject: Re: Thoughts on the book: DEC is dead, long live DEC G Message-ID: <saudnTAFg422JXPZnZ2dnUVZ_q2dnZ2d@metrocastcablevision.com>    JF Mezei wrote:    ...   G > Olsen was hands-off type, let the engineers battle and decide between 
 > themselves.   C Not quite.  Rather, he preferred to let people arrive at the right  C decisions by consensus rather than dictating them from above - and  L concentrated on creating an environment which would encourage them to do so.  G My impression is that Olsen was a remarkably humble man given all that  G he had accomplished, and understood the potential power and creativity  H of groups (which is more than the simple sum of their parts) far better G than most managers - at least as long as the groups remain healthy and  C at least partially committed to the common good (not that a lot of  C friendly internal competition wasn't present as well, and that was  
 healthy too).   3   This worked well initially, but ended up creating E > independant kingdoms that where inter-kingdom communication was not  > good.   I Rather than 'creating' that situation, it might be better to say that it  I *allowed* that situation to develop when management depth and total head  H count became too great for a "do the right thing" philosophy to work as G well as it had worked before.  The massive influx of new people (often  A from other companies with decidedly different cultures) from the  D mid-'70s through the early '80s also diluted what had been a pretty + pervasive and widely-respected DEC culture.   A   In mid 80s, Olsen became aware of this, but when he tried to do C > something about it, he had lost power within the organisation and J > couldn't force changes onto those independant kingdoms. When he tried toH > reshape the management "matrix" in 1990-1992 period, the various kings > didn't accept it.   I I don't think he 'lost power':  I think rather that he had as much power  H as ever (and that was a *very* significant amount) but had never wanted G to exercise it very overtly and didn't want to begin then.  So he just  I tried harder to make the approaches that had worked so splendidly for 25  I years continue to work, but failed (in part for the reasons noted above).   7   Seems to me that Oslen set himself up to lose control / > by devolving power so much in the early days.   D Seems to me that a major factor in DEC's stunning (and at that time G completely unparalleled) success during its first 25 years was Olsen's  H brilliant use of consensus-building and a very light touch to arrive at G performance that other companies could only envy (rather than have any   hope of matching).  C Plus a corporate-wide knack for finding and attracting really good  G engineers (which was probably at least in part due to this willingness  " to give them real responsibility).   > H > From that book, seems that the only decisions where Olsen actually gotJ > involved were preventing development of PCs and pushing for the VAX 9000H > at the expense of other projects.  (although I am sure he actually was5 > more involveed than the book leads one to believe.)   F KO worked his butt off almost every day, including weekends.  He just B understood that inspiring people produced far better results than @ controlling them - at least until the percentage of people more I interested in self-promotion than in inspiration overwhelmed the company  G (they didn't need to be anything like a majority to do so:  just a few  @ in the right - or perhaps 'wrong' is a better term - positions).   >  > J > Gordon Bell was extremely well respected and he is the one who convincedD > DEC to dump PDP and go for VAX/VMS. The author doesn't mention anyB > battles to get this accepted, nor of any backlash from customersI > (something even I was aware of). Were the top guys so detached from DEC 6 > already ? Seems to me like this was a huge decision.  B It was a huge decision and a very painful one:  no one was at all F 'detached'.  It's easy to forget that despite being wildly successful I DEC had quite limited engineering resources (and limited ability to grow  F them arbitrarily quickly), which had to be divided between continuing I the vigorous development (and maintenance, which we took very seriously)  F of all the existing hardware and software systems that were producing E all our revenue, plus all the new VAX development, plus the many and  . varied new areas into which DEC was expanding.  E In data management alone in the PDP-11/VAX segment, for example, DEC  I went from Andy Goldstein pretty much handling FILES-11 ODS-1 and FCS all  F by himself in 1974-5 to ODS-2, RMS-11 and -32, DATATRIEVE-11 and -32, I TRAX-11, DBMS-11 and -32, Rdb, Rdb/ELN which the rest of the world later  C came to know as Interbase, CDD, ACMS, and probably more that don't  , immediately come to mind by the early '80s).  H These weren't frivolous projects:  most of them were quite important to E VAX's ability to penetrate the commercial marketplace that fueled so  I much of DEC's growth at that time.  But this kind of expansion stretched  H engineering to its limits - both in terms of simple coding and in terms ! of managing the exploding circus.   G Nobody *wanted* to drop the 16- and 36-bit systems:  there just wasn't  H enough manpower to go around, and when priorities had to be set VMS had F to be at the head of the line (because the other systems were already B established and very usable as they stood, and could survive some  development delay).   I The next-generation 36-bit Jupiter project hit a significant snag around  E 1982-3:  exactly how significant depends on whom you talk to, but it  H wound up being the straw that broke that product-line's back.  When the I PDP-11 'Professional' PCs failed to take off by 1984-5, the last hope of  G continued vigorous 16-bit development died with them (an error some of  E us tried to point out at the time, because VAXen wouldn't be able to  H compete in the same space for another 4 - 5 years, but by that time DEC F just wasn't in a good position to undertake much of *anything* in the 9 way of new projects outside the exploding VMS ecosystem).   I Yes, Gordon planned to give priority to VAX and VMS from the start.  But  C I don't think he planned to short-change the rest of the company's  I products:  I just suspect that he had no idea how popular, and therefore  A how demanding, VAX and VMS would prove to be.  DEC already had a  E tradition of keeping product lines going as long as customers wanted  E them (the PDP-8 being a prime example), and I don't believe that the  F degree to which that changed was deliberate, because it wouldn't have & been in character for it to have been.   > E > When Gordon Bell left in 1983, it created a vacuum and there was no 7 > longer true leadership within the engineering groups.   C It's not clear that the leadership was markedly better even before  B Gordon left:  I suspect that things were already very much out of F control, just that it would take a few more years before pre-existing , momentum ran out and they really fell apart.   > J > Also, and perhaps indicative of the situation, the author seems confusedJ > about Alpha. At one point he discusses 3 separate projects competing forI > funding (VAX 9000, Cuttler's Prism and Alpha). Later on, he mentions in I > passing that Alpha picked up what was left of Prism.  Again, no mention J > of any serious discussions about abandonning VAX and focusing on Alpha.   H Perhaps because that was never planned.  As I observed above, DEC had a H tradition of continuing product lines as long as customers wanted them, E and there were future VAXen planned, just no more extremely high-end  G ones after the 9000 disappointment (that territory was ceded to Alpha,  D but since it was territory that VAX had never occupied in the first - place that hardly constitutes 'abandonment').   H > However, as a customer, when Alpha was presented, it seemed very clearI > to me that Alpha would replace VAX, just like PowerPC would replace the I > 68000 at Apple.  Did DEC ever actually formally make such a decision or G > was Olsen expecting VAX to co-exist with Alpha for a very long time ?   F You don't consider 8 years to be 'a very long time' in this business? , Perhaps not by PDP-8 standards, but still...   > J > About the board: Up until the mid 1980s, the original venture capitalistH > (General Doriot) was still on the board and still the mentor for Olsen@ > and vice versa. So Olsen never had to worry about the board ofH > directors. When Doriot died, Olsen was left alone and new guys broughtI > on the board who knew business but not technology, and supposedly Olsen  > didn't relate well to them.   I It's hardly clear that the board 'knew business':  if they actually had,  > they probably would have been of some significant help to him.  A My impression is that General Doriot primarily kept the BoD from  F screwing up KO's way of running DEC (and may have been something of a H friend and/or father figure to KO as well, when there was really no one C else associated with DEC who could fill such roles).  Whether KO's  F management approach would have continued to produce great results had F Doriot's presence continued is of course debatable, but the fact that 6 around the time Doriot died DEC went to pieces is not.  G My guess is that if Ken didn't relate well to the BoD it had little to  H do with their failure to understand technology and much more to do with H their failure to understand (and respect) the value that his managerial C approach brought to the company.  This was a time of transition to  I extreme short-sightedness on the part of investors, and Ken likely would  2 have had no patience with such a viewpoint at all.   ...     6 > Manufacturing wasn't too concerned about efficiency,  G Horseshit.  Manufacturing was *very* concerned about efficiency - they  E were just also guided by a strong tradition of engineered-in quality.      and it seemed thatJ > throughout DEC, money was no object and they were perfectly happy making9 > high cost items as long as they were also high quality.   G It's clear that the author didn't have a clue here.  DEC's problem was  E that it had no idea how to make cheap hardware:  it only knew how to  I make *good* hardware.  The stories about VAXen dropped off loading docks  E and still booting up could have been told about DEC's proprietary PC  E offerings as well:  they cost twice what the competition did because  0 they were built like very-well-engineered tanks.  H So (in that example) you got what you paid for.  Unfortunately, quality I in PCs was not perceived as being nearly as valuable by customers as DEC  H was used to in its other products - and DEC manufacturing simply didn't G know how to make low-quality products, much as they tried to learn how   to make inexpensive ones.   G What it boiled down to was that there were markets (like PCs) that DEC  I just shouldn't have tried to compete in at the time (instead OEMing some  H other vendor's products when necessary).  But it didn't understand that ? up front, and the lesson was a long and expensive one to learn  L (occurring during a period of other major upheavals didn't help, of course).     There were tooE > many plants around the world and no real central controls (remember  > those independant kingdoms).  D I suspect that's hogwash, but will leave it to someone who actually # knows to address that specifically.    > G > It is interesting because from my point of view, DEC was seen as less F > expensive as IBM, so my image in the mid 1980s was of a DEC that wasJ > more efficient than IBM while giving just as good quality. However, thisG > book does outline how its history lead a Digital to become relatively G > bloated when newcomers arrived on the scene with far more efficiency.   G You and/or the author are confusing low cost and resulting low quality  F with high efficiency, whereas they simply reflect a different product E target (without necessarily having anything to do with 'efficiency').   G The main area in which DEC was bloated was in its explosion of markets  H (and strategies):  it tried to address everything it could see a demand F for, rather than understanding how much it could *safely* eat without 
 becoming ill.    > H > When it was decided to battle IBM, DEC hired 26,800 new employees in aG > short period of time. This didn't pan out, but those employees stayed I > on, thus greatly lowering the sales/employee numbers and making it even 2 > harder for DEC to compete. (this was mid 1980s).  C That's generically-incompetent MBA talk.  The problem was not 'the  C numbers', the problem was making effective use of the people.  Ken  I believed he should find a way to do that, rather than just giving up and  : taking the meat cleaver to people he felt responsible for.  B And I suspect that he was right, in the sense that cutting people B wouldn't have solved the underlying problems at all, just perhaps C delayed the end a bit.  Field medics may see triage as normal, but  F engineers tend to hold out for better solutions even if getting there E may be painful - and that attitude had served Olsen very well indeed   throughout his career.  E > re: Palmer's renaming DEC to Digital: The author compares it to IBM ( > renaming itself to "International" :-)  I Except that 'Digital' was *always* the official name, and the attempt to  I deprecate use of the 'DEC' acronym occurred before 1985 IIRC.  So unless  B my memory is completely wrong on this point Palmer had absolutely  nothing to do with that.   - bill   ------------------------------  % Date: Fri, 25 Aug 2006 08:19:11 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> = Subject: Re: Thoughts on the book: DEC is dead, long live DEC < Message-ID: <44eee962$0$24195$9a6e19ea@news.newshosting.com>  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  & news:44EE5EB4.1F371648@teksavvy.com...D >I finished reading it. The first half could have been condensed as: > G > Olsen was hands-off type, let the engineers battle and decide between ? > themselves. This worked well initially, but ended up creating E > independant kingdoms that where inter-kingdom communication was not G > good. In mid 80s, Olsen became aware of this, but when he tried to do C > something about it, he had lost power within the organisation and J > couldn't force changes onto those independant kingdoms. When he tried toH > reshape the management "matrix" in 1990-1992 period, the various kingsI > didn't accept it. Seems to me that Oslen set himself up to lose control / > by devolving power so much in the early days.  >  [...snip...] > K I disagree with most of the points in your posting and here are just a few   of my reasons:  J First off, in several pages including page "xiii" we learn that this book H was "kind of" commissioned by Ken Olsen. Lots of things happened at DEC M since the company was initially founded in 1957 and Ken, as well as many DEC  L alumni, wanted "the record set straight" while many people were still alive C to do so. So it would be in nobody's interest to condense the book.   K We learn from the book that DEC management was passionate about technology  D and always told "to do the right thing". In fact, this phrase was a J corporate mantra that many DIGITS in this newsgroup have mentioned in the K past. This allowed a condition to exist at DEC where people could stand up  K to Olsen without getting fired but Olsen was always a majority shareholder  M (if memory serves) so it is doubtful that he ever "lost control". He allowed  I this condition to exist because he thought it was the right way to run a  5 knowledge-based company AND he wasn't a megalomaniac.        ###    My book summary:L Because this book contains so many historical facts sprinkled together with J the memories of interviewees, it was probably difficult to put everything L together without having a book that seems to ramble. But after you read the K whole book you should go back and re-read pages ix through to 15 (Preface,  I Acknowledgments, Purpose and Overview) and you'll see that the 4 authors  . were probably 95% successful in their efforts.  I Ken Olsen was many things, but foremost, he was a scientist/engineer who  I wanted to document the rise and fall of his company. We all do some "arm  K chair quarterbacking" but I think the main reason for the decline in DEC's  J financial health was the invention of the PC. As we have seen before with M things like "VHS vs. Beta", price usually becomes the most dominant deciding  I factor in the market place. Remember, too, that many other mini-computer  I companies went completely under during this time AND many people thought  K that IBM would go under as well even though IBM is (falsely) credited with  $ starting the commercial PC industry.  K p.s. 15 years ago I remember spread-sheets and word-processing software on  I minicomputers being the norm at my place of employment, not PCs. So even  @ though the IBM PC was introduced in 1981, PCs slowly eroded the  mini-computer business.   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/    ------------------------------    Date: 25 Aug 2006 08:24:41 -0700' From: "bclaremont" <msi1@earthlink.net> = Subject: Re: Thoughts on the book: DEC is dead, long live DEC B Message-ID: <1156519481.469441.60380@p79g2000cwp.googlegroups.com>  9 Nice discussion.  Interesting observations and rebuttals.   D What continually impresses me is the incredible impact an individualD like Ken Olsen had on an industry and thousands, perhaps millions ofE people.  In a sense this legacy lives on in OpenVMS, given the small, F diverse core of engineers that continues to support the O/S.  I tip my- hat to all of you, past, present, and future.    ------------------------------   Date: 25 Aug 2006 12:10:30 GMT( From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: VMS in The DA* Message-ID: <4l87lmFmoqqU2@individual.net>  H In article <8660a3a10608241656x8dbf56fvd77392a2f6d40b8d@mail.gmail.com>,2 	"William Webb" <william.w.webb@gmail.com> writes:H > On 24 Aug 2006 14:50:37 GMT, Bill Gunshannon <bill@cs.uofs.edu> wrote:= >> Surprise, surprise.  I have actually seen a job posting by : >> The Department of the Army looking for someone with VMS= >> experience (among many other requirements).  Of course, it > >> is in the one last field that hasn't totally abandoned VMS,? >> Healthcare.  And, it doesn't read like a conversion but like > >> an ongoing maintenance/development operation.  Interesting. >> > H > It's not so surprising- I've seen a number of such jobs- I think their > application is called CHCS.  > H > The VA uses VMS, too- the New Orleans VA hospital restored its data in* > Texas-- with no loss of data, naturlich. >   B Let me explain my "surprise surprise" comment for you (and Larry).@ Having been told by people here that DOD and DA were still major? users of VMS I did a little research.  I asked in a forum of my @ peers just what VMS systems were available in DA.  There was, ofA course, a method to my madness.  Knowing that VMS is not only not = taught at an Army IT school, but not even mentioned except in E passing and in a rather derogatory manner, I felt that my experience, B limited thoguh it may be, could be of definite value.  The silence@ was resounding.  Eventually, I got one answer from a Colonel whoA was getting ready to retire (I mention that only as evidence that B we are talking about someone who has been doing IT in the Army for@ something like 30 years)who's only comment was that he could not> remember the last time he had seen a VMS system in the Army.  ? Needless to say, I was surprised to find a vacancy announcement B that listed knowledge of VMS as a desired, if not required, skill.? Of course, I hav e to also mention this is the first one I have 5 seen in well over a year of watching these vacancies.    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------    Date: 25 Aug 2006 12:10:20 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) * Subject: what is capacity of a TF85 drive?3 Message-ID: <0osN0TXQzYb3@eisner.encompasserve.org>   B    I've seen one site which claims 2/4 GB and one which claims 10.   ------------------------------    Date: 25 Aug 2006 10:53:09 -0700; From: "johnhreinhardt@yahoo.com" <johnhreinhardt@yahoo.com> . Subject: Re: what is capacity of a TF85 drive?C Message-ID: <1156528388.813941.116300@m73g2000cwd.googlegroups.com>    Bob Koehler wrote:A > I've seen one site which claims 2/4 GB and one which claims 10.   G Google results on "TF85 capacity" seem to indicate that it was 2.6GB. I F don't know if that was with or without compression (if compression was$ even available - I think it wasn't).  8 This appears to be a decent listing of the older drives:0 http://www.discinterchange.com/dec_tk_tape_.html       John H. Reinhardt    ------------------------------  % Date: Fri, 25 Aug 2006 02:49:01 -0400 ' From: Dave Froble <davef@tsoft-inc.com>  Subject: Re: WWENG2.SYS 9 Message-ID: <wsadnZmoW_coBnPZnZ2dnUVZ_vCdnZ2d@libcom.com>    JF Mezei wrote: * > Here is what I got from the Jan 1995 CD: > D >     OpenVMS VAX January 1995 Software Product Library Master Index >  >  > G >     Table_1-1_(Cont.)_January_1995_Master_Index______________________  > G >     Product_Name_______________Vers___UPI____Status_CD__Directory____  > B >     DECserver 200 for VMS      3.3    VCBAA         4   [DS2033] > C >     DECserver 250 for VMS      2.0    VTMAA         4   [DS25020]  > C >     DECserver 300 for VMS      2.2A   VTUAA         4   [DS3A022]  > B >     DECserver 500/550 for VMS  2.2    03KAA         4   [DS5022] > C >     DECserver 700 for VMS,     1.1B   XA5AA         4   [DS7A011]  >     ULTRIX, UNIX, and MS-DOS > C >     DECserver 90 TL Software   1.1B   MJPAA         4   [DS9A011]  > F > If it was removed sometimes during 1995, I don't think it would have& > ever included a more recent version. >  > I > And DS7A011 appears to be a minor update (or is it the same) as what Mr B > Frobble had included in his listing which had DS7011.x savesets. > F > If this is something you want, then contact me privately at jfmezei   > domain is vaxination period ca  I Use BACKUP to look at the 'B' savesets.  See if the WWENG?.SYS is WWENG1  
 or WWENG2.   --  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: 25 Aug 2006 05:07:29 -0700; From: "johnhreinhardt@yahoo.com" <johnhreinhardt@yahoo.com>  Subject: Re: WWENG2.SYS C Message-ID: <1156507649.806105.158010@p79g2000cwp.googlegroups.com>    JF Mezei wrote:  > Dave Froble wrote:L > > Use BACKUP to look at the 'B' savesets.  See if the WWENG?.SYS is WWENG1 > > or WWENG2. > F > Geez, the things we do for comp.os.vms.... I actually had to get up,J > look for disc 4, insert it into the caddy, and issue a mount command and* > then look at the contents... :-) :-) :-)  F I feel for you JF.  Maybe keeping a box of chocolate stashed along the% route to the CD drive would help? :-p   G BTW, when I looked at my ConDist I not only had to get up and go put it E in, but I actually had to BEND OVER to get the box off a lower shelf. 	 Sad, huh?    > @ > OpenVMS VAX January 1995 Software Product Library Master Index > G > Interestingly, the save set was create on node "DORIOT" and had I not > > read that book on DEC's failure, I woudln't know who he was. > * > WWENG1.SYS 1156 blocks dated 13-mar-1995 > - > Looking at contents of this .SYS file I see  >  > NuWhiteWater V1.4 DRAM > H > The youngest copyright I saw was 1994. But there are many places where! > the list of years ends at 1992.  > H > Further down:  DECServer 700-08 Communications Server V1.1A - LAT V5.1 >  > I also see a BL45-121632 >  > G > It looks like the help data is compressed. Perhaps they are using VMS I > help library code with the DCX compression. It woudl make sense to have G > the data reside in flash memory in compressed form (takes less space) 3 > and be uncomopressed on the fly only when needed.  >  > G > OK, now, I have to get up again and dimount/remove/file that disc....  >  > E > Note that the 700 is still a "hot" product because it can do TCPIP. F > However, this version only does SLIP (aka: find "PPP" in it yields a' > "Not Found", but "SLIP" finds stuff.)  >   G If I remember correctly PPP didn't come out in DNAS until at least V2.2 9 which, by then, was only available from Digital Networks.    > G > Perhaps providing Hobbyists with uptodate software version would help E > make DPNG more popular ? Sue, don't you have friends out there ???? # > [hint] [hint] [nudge] [nudge] :-)   G They have been selling on Ebay for a number of months now.  You can buy @ a copy of DNAS V3.3 for a non-trivial amount with the Buy-it-Now@ option.  They also take the best offer, but as I learned from anD inquiry being a OpenVMS Hobbyist only gains you about a 25% discount< from the stated price (and still a very non-trivial amount).     John H. Reinhardt    ------------------------------  % Date: Fri, 25 Aug 2006 04:09:49 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>  Subject: Re: WWENG2.SYS , Message-ID: <44EEB036.A322584D@teksavvy.com>   Dave Froble wrote:J > Use BACKUP to look at the 'B' savesets.  See if the WWENG?.SYS is WWENG1 > or WWENG2.  D Geez, the things we do for comp.os.vms.... I actually had to get up,H look for disc 4, insert it into the caddy, and issue a mount command and) then look at the contents... :-) :-) :-)    > OpenVMS VAX January 1995 Software Product Library Master Index  E Interestingly, the save set was create on node "DORIOT" and had I not = read that book on DEC's failure, I woudln't know who he was.    ( WWENG1.SYS 1156 blocks dated 13-mar-1995  + Looking at contents of this .SYS file I see    NuWhiteWater V1.4 DRAM  F The youngest copyright I saw was 1994. But there are many places where  the list of years ends at 1992.   F Further down:  DECServer 700-08 Communications Server V1.1A - LAT V5.1   I also see a BL45-121632    E It looks like the help data is compressed. Perhaps they are using VMS G help library code with the DCX compression. It woudl make sense to have E the data reside in flash memory in compressed form (takes less space) 1 and be uncomopressed on the fly only when needed.     E OK, now, I have to get up again and dimount/remove/file that disc....     C Note that the 700 is still a "hot" product because it can do TCPIP. D However, this version only does SLIP (aka: find "PPP" in it yields a% "Not Found", but "SLIP" finds stuff.)     E Perhaps providing Hobbyists with uptodate software version would help C make DPNG more popular ? Sue, don't you have friends out there ???? ! [hint] [hint] [nudge] [nudge] :-)    ------------------------------    Date: 25 Aug 2006 05:05:15 -0700' From: "tadamsmar" <tadamsmar@yahoo.com> ; Subject: Re: X-terminal connects get hosed, requires reboot B Message-ID: <1156507515.019462.13290@i42g2000cwa.googlegroups.com>  = I tried that and it did bring back the console login display.   G But the X-terminals were still hosed.  When power cycled or reset, they G appear to load the software but they just show a blank screen and never  show the login display.   : I get a DECnet communications error "Line open error, LineF communications error" when the X-terminal is loading software (it doesB not have to load from the node that host it for Dec$windows by theG way.)   Maybe restarting DECnet would do the trick.  I will try that in  the future.   E Anyway I destoryed the test environment by rebooting the Alpha.  I am F not sure how the reproduce the problem.  I would I have to power-cycleC the X-terminals a number of times to see if I could cause it again.   : Application work has to progress on this system for now...   Thanks!    H Vlems wrote:* > Try restarting just  DECwindows instead.; > Off the top of my head: @sys$startup:decw$startup restart  > 6 > "tadamsmar" <tadamsmar@yahoo.com> schreef in bericht> > news:1156451709.895846.76220@m79g2000cwm.googlegroups.com...C > > I have a Alpha with 3 X-terminals on it (old Tektronix XP338s).  > > H > > But sometimes VMS gets in a state where it will not allow any of theA > > X-terminals to reconnect after I reset or power-up any of the J > > X-terminals.  Also, the window manager will not come up on the console > > so that I can log in.  > > D > > I can still login to the Alpha from a VT type terminal.  And anyG > > X-terminal that are already running the windows manager still works H > > fine.  It's only when a restart any of the X-terminals that I cannot > > get back in. > > 6 > > If I reboot the Alpha, then the problem clears up. > > I > > I wonder if there is a way to clear up the problem without rebooting.  > >    ------------------------------    Date: 25 Aug 2006 05:14:41 -0700' From: "tadamsmar" <tadamsmar@yahoo.com> ; Subject: Re: X-terminal connects get hosed, requires reboot C Message-ID: <1156508081.576326.196120@p79g2000cwp.googlegroups.com>    JF Mezei wrote:  > tadamsmar wrote:H > > But sometimes VMS gets in a state where it will not allow any of theA > > X-terminals to reconnect after I reset or power-up any of the J > > X-terminals.  Also, the window manager will not come up on the console > > so that I can log in.  > C > If you have an active session that is logged in, has the sesssion J > manager running as well as apps, when the X-terminal goes away, the appsD > and session don't automatically go away right away. (is there someH > timeout value one could set for the client side of things (aka, on the$ > VMS side, not on the X-terminal ?) > H > And as long as VMS sees a session and appls running on a WSAx: device,( > it doesn't initiate the login process. > E > For such a hung session, have you tried STOP/ID of the DECW$SESSION G > associated to that user ?  Are you running the window manager off the 1 > VMS side or something local to the X-terminal ?   = I am not sure, the whole process is automatic when I reset or B power-cycle the X-terminal.  I have never thought about that.  The6 X-terminal loads lots of stuff, fonts and other stuff.  G By the way.  While the system was in this funny state, I was still able A to login and get a Dec$windows session going with X-free on a PC. G That is done by manually running a command procedure on the PC side and , another on the VMS side.  That still worked.   > Note that when you kill I > the window manager, the apps are still connected to the X-terminal, and D > the app that had focus at the time is still functional, except allD > windwo decorations are gone and you can't move the window anymore.  C Yeah I tried killing off all the processes that might be associated @ with the hosed X-terminals.  That did not clear up this problem.   ------------------------------    Date: 25 Aug 2006 07:33:58 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ; Subject: Re: X-terminal connects get hosed, requires reboot 3 Message-ID: <YnDAxIPT3RCY@eisner.encompasserve.org>   l In article <1156451709.895846.76220@m79g2000cwm.googlegroups.com>, "tadamsmar" <tadamsmar@yahoo.com> writes: > 4 > If I reboot the Alpha, then the problem clears up. > G > I wonder if there is a way to clear up the problem without rebooting.   8    What networking protocol are you using to run X over?  '    If you're using TCP/IP, whose stack?    ------------------------------    Date: 25 Aug 2006 07:40:12 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ; Subject: Re: X-terminal connects get hosed, requires reboot 3 Message-ID: <wPAEVRFua4Ib@eisner.encompasserve.org>   l In article <1156507515.019462.13290@i42g2000cwa.googlegroups.com>, "tadamsmar" <tadamsmar@yahoo.com> writes: > < > I get a DECnet communications error "Line open error, LineH > communications error" when the X-terminal is loading software (it doesD > not have to load from the node that host it for Dec$windows by theI > way.)   Maybe restarting DECnet would do the trick.  I will try that in 
 > the future.   D    That error is common when a node sees a MOP boot request, but theA    system making the request is not in that node's MOP data base.   D    We used to see it all the time when we had a few LAVC sharing theH    same ethernet.  Each boot host would see and reject MOP load requestsF    from the other boot node's satellites, with the above error message    posted via OPCOM.  H    We simply went into the DECnet data base and removed logging for thatB    message.  It was causing confusion amoungst the uneducated, who9    thought there "must be" a problem needing to be fixed.   F    We kept the message in our development cluster so I could tell what@    was going on when I added new satellites.  I was the only one*    reading OPCOM messages on that cluster.   ------------------------------   End of INFO-VAX 2006.473 ************************                                                                                          ",'ᄞp^mHEc}oxRg0b!`mͨoQS_\|j8w`݃;ݖp;qq,sAock}/8FadY
f܎Sa(}Fuw1/r5=mkS=kǎ2(ۈdG6Ž;g{='&*e}KnCi{qY:U~< xA@4節-ar+<τ۝96"/?r{̝`o;kJ"Z=̎fܪ+:sQwʯUڱu;}]Yjhaf&`E}jK>]?n`L(O7y*5>cȗgn_uԉHJB|pI	u@\'E:fN~'dU`v񖝡5*APwvר"U!cWY|W7iAN?U~'KHȲΰkos5hfsR[%0f5>J~P4(sܗ"=A(^@|XB6YUeaxY ^S(1J8sPF4e|Č̻ XM%wgbufYBNIEkHYLւU2e2H̍FffpˉURH_%'էX"9iNXLyᅆ;A?`("g5%,6j (` (,U/^$aԹR<&g
l[:v~'B\8+g5aI(ϫgt;xie	JC  1#˕y:[
P91:JCDb}w#l3km<yaPg!SF&+y &<$! )_tߣE|ҍK#̄hxHz}Vj50W
Z0#+vZ9g8*:l(	u(
 }<cvbmϢJB:>y$ʳh&E
k{),ZY;P8^JG8t{M17X~ 7&mE4QHF%nщ( (,Ň]gŹwJH^VY^Ԃ} %@bsF
Pn~uBův'PQ1Ho2i:uP%⇌):r;Ԝ[xEe(!%Ir0G	:=%!us?L/;E%s^~2gn8t|-n=olD
8l{՚;@=YT˺<í~a!Gţ
N%S3K35X%H|+&
Z}q78Db}eSt]Fӫ67oWU&ACƇtۍw;KE{F)C$԰k?߃h\q19zz*S4۔Bb.%$)~iGP"r7
 ه%Bh8|(⣘F]y!&xӯɛ$Vvbɜz_QVx9|T%CLC]L`0z`_1~bfU
,Sk< 09ײ;&u<@,tRG7Ϩt_m⚦`ڄ\(8gp6ɽZG	i.߶d3#ByDMKc+iz#q=t0ΚBq_ke3Bw$ifǑIf[$&~}r6u|rY<PN+LFX/p:nFsJ.bBB\yHJ8BVqdWiBN'$j|WI0^vx},=YqNJLN͠CopdNvUCBdD֔mÆ@okӆ Vo I)";MsUHsQKse>i.S6[~^k!3V|Gep%#Ý`Qs¿_7ɣ<_Tj\XV<Ԩ=&_< vzzYxn510y~`T\rS㑢
Mj4Dv'%pҭ=v/8M쥪QdG3c:I8@h}k:*دA$L&nLޓUtNz
wnଲ7HUSI@tP{b1ڛP8`%vup_tbw<H
ލ(Ab4`1K
-*6zreʊ[Nğ'\.K/Wl${iXlN#FX??3 