1 INFO-VAX	Sat, 26 Aug 2006	Volume 2006 : Issue 474       Contents: Re: Alpha remembrance day  Re: Freeware links broken? Re: Hobbyist Media available, Re: Mystery multiple TCP connections dropped, Re: Mystery multiple TCP connections dropped, Re: Mystery multiple TCP connections dropped, Re: Mystery multiple TCP connections dropped, Re: Mystery multiple TCP connections dropped, Re: Mystery multiple TCP connections dropped, Re: Mystery multiple TCP connections dropped6 Re: Reading UAF Disuser Flag Across Nodes from FORTRAN6 Re: Reading UAF Disuser Flag Across Nodes from FORTRAN4 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 DEC4 Re: Thoughts on the book: DEC is dead, long live DEC4 Re: Thoughts on the book: DEC is dead, long live DEC& VMS 8.3 for Alpha has been received...* Re: VMS 8.3 for Alpha has been received...* Re: VMS 8.3 for Alpha has been received...% Re: what is capacity of a TF85 drive?  Re: WWENG2.SYS Re: WWENG2.SYS Re: WWENG2.SYS2 Re: X-terminal connects get hosed, requires reboot  F ----------------------------------------------------------------------  % Date: Fri, 25 Aug 2006 16:31:58 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> " Subject: Re: Alpha remembrance day, Message-ID: <44EF5E36.B36D04CB@teksavvy.com>  
 Andrew wrote: H > Alpha was not sucessfull commercially, it didn't make Digital money inC > fact it was one of the contributors to the demise of Digital. And H > because of Alpha's lack of sucess Compaq did not want to be in the CPU > business.      Sorry, but "BULLSHIT"....   H The FAB may have been so mismanaged that it lost mega money. But the FABF was gone by the time Compaq got the DEC leftovers. What Compaq got wasG state of the art chip and excellent chip engineers in a FABless system, H just like SUN. And that chip allowed compaq to enter the real enterpriseG business with serious computers and serious operating systems. And when D you looked at the big picture, it made money for Compaq and in fact,B Alpha's development costs were minimal compared to other stuff and% compared to the revenus it generated.   E Alpha was just like compilers: a core cost of doing business in a way 7 that gave you a copmpetitive advantage over the others.   G Compaq didn't get rid of Alpha because it didn't want to be in the chip G business.  It got rid of Alpha because it was about to be taken over by G HP which had a lot riding on that failed IA64 thing and Intel/HP wanted F Alpha dead not only to remove a competitor, but also to gain access to its technology and engineers.    ------------------------------  % Date: Fri, 25 Aug 2006 11:08:37 -0400 , From: Hoff Hoffman <hoff-remove-this@hp.com># Subject: Re: Freeware links broken? * Message-ID: <44ef128a@usenet01.boi.hp.com>  N    Apologies on the confusion here.  Hopefully the round of updates yesterday ? will reduce the potential numbers of future cases of confusion.   
 AEF wrote: ... " > Then, click the following links: > * > browse the freeware distributions (http)  K    You're walking through a path on the Freeware disk contents itself, and  J getting out into the Freeware, and (for administrative and organizational P purposes) once you traverse from the OpenVMS web site and out onto the Freeware = disks and contents, you've transitioned into in my bailiwick.   P    While somewhat of a hair-split, you're not here finding a hyperlink to these P particular Freeware files -- you could get into similar troubles with opening a M text file on the Freeware and discovering errors in the contents of the text   file, for instance.     I > Well, I didn't know it was up to you to fix. I wrote the Webmaster, not I > you. I'd think broken links would be an important task for a Webmaster, F > assuming the rest of the site is up and running smoothly, of course.  P    The web master is elsewhere this week (AFAIK), and -- as I'm the person that M made the original changes and as I don't know who the web master has for his  N backup right now, and as I don't know that s/he would tangle with the OpenVMS L site and particularly with the contents of the Freeware itself.  (I, on the P other hand, have waded in here where far smarter folks would cringe and recoil.)  C >>   But in this case, the "fix" won't be forthcoming for a year or F >> two -- if at all -- and certainly not likely before any unannounced  >> and future round of Freeware. > E > I thought it was just a typo or something minor that could be fixed H > quickly. I didn't know an entire menu system needs to be written. Yes,, > I believe that would take more than a day!  Q    The contents of that HTML file are almost certainly stale, as the fellow that  T provided those was looking at an older Freeware distro when he created the template.   ------------------------------  % Date: Fri, 25 Aug 2006 21:07:39 -0400 - From: bradhamilton <bradhamilton@comcast.net> % Subject: Re: Hobbyist Media available * Message-ID: <44EF9EDB.8040509@comcast.net>   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?   - Have you tried asking at the hobbyist forum?:   1 <http://www.openvmshobbyist.org/phpbb2/index.php>   & You might get a faster response there.   ------------------------------  + Date: Fri, 25 Aug 2006 18:01:55 +0000 (UTC) . From: Dale Dellutri <ddelQQQlutr@panQQQix.com>5 Subject: Re: Mystery multiple TCP connections dropped , Message-ID: <ecnduj$1vs$1@reader2.panix.com>  B On 25 Aug 2006 08:33:38 -0700, AEF <spamsink2001@yahoo.com> wrote:D > I run a trading application that sends data to multifeed data feedH > distributers. It's a little complicated and I'll try to describe it as > clearly as possible.  E > The first two paragraphs below describe the overall set up. I'm not H > sure how relevant they really are. The third and fourth paragraphs are > the actual problem.   F > The back-end runs on several MicroVAX systems. There is the host, orD > market system, on which the market exists. Connected to the marketI > system are DECnet Phase IV end nodes (which are also MicroVAX systems). C > 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 andC > data-feed processes. Each data-feed process maintains a "page" of D > issues, bids, and offers. The page data is sent to "multifeed DFD"H > systems via TCP connections. Three are in NY and one is in London. TheG > ones in NY are various combinations of WinXP or Win2k running on Dell E > Optiplex 620 or Compaq DL580 boxes. I'm don't know about the London E > system. (These multifeeds pass the page data onto other systems and ' > eventually to brokers and customers.)   H > Anyway, for one of my markets I have four pages: 45 thru 48. Each pageF > runs on a separate end node MicroVAX. (The MicroVAX systems for thisG > market are all in London.) Each end-node MicroVAX has a data-feed job G > that sends the page data to all four multifeeds. Now, on both Tuesday H > and Thursday mornings, at about 7:15 or 7:30 London time, I lose pagesG > 46 and 47 on all three NY multifeed systems, but these same pages are - > still running fine to the London multifeed.   G > So the page 46 job was running on one (London) MicroVAX, sending data H > to all 4 Multifeeds, when suddenly all within a tenth of a second, theB > TCP connections to the 3 NY multifeeds dropped, while the fourthD > connection to the London multifeed stayed up. The same exact thingG > happened with page 47 which runs on another (London) MicroVAX sending B > data to the same 4 multifeeds, at the same time that the page 46 > connections went down!  G > Does anyone have a clue as to what could be causing this? In summary, I > each MicroVAX is sending data for its page via TCP connections (telnet, I > whatever) to four multifeeds. With 4 MicroVAX systems that's a total of G > 16 connections. On each of the two of the MicroVAXes running jobs for I > pages 46 and 47, the three connections (total of 6) suddenly die within H > a tenth of a second of each other. The same pages had the same problemC > on both Tuesday and Thursday mornings (London time). (The page-46 G > MicroVAX system is running VMS v6.1 and the page-47 system is running  > VMS v6.2).  C > I know this will appear confusing at first read. I'll be happy to A > answer any questions to clear up any confusion as to the setup.   I > 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!   9 I'm confused about the physical topology of your network.   @ Are the end nodes in London connected via DECnet Phase IV to theB US end nodes?  And if they are, are the TCP connections going over- the same circuits (same ethernet controller)?   < Do the TCP connections go through the internet (perhaps with4 a VPN), or is it a direct leased line or equivalent?  ? (I'm trying to determine if this is a TCP-only type of problem,  or a physical link problem.)  B Is there anything that happens on the London end nodes at 7:15 AM?? Batch jobs, large influx of users, etc.?  Anything that happens = at that time on the NY multifeed DFD's.  (I don't know what a 3 "multifeed DFD" is, and google didn't know either.)   C Are there routers, switches or bridges in between that keep (or can A be induced to keep) any kind of logs?  Did the logs on the London D end node for any communiction protocol (DECnet or TCP) show anything funny at 7:15 AM?    --  7 Dale Dellutri <ddelQQQlutr@panQQQix.com> (lose the Q's)    ------------------------------    Date: 25 Aug 2006 10:48:47 -0700- From: "Doug Phillips" <dphill46@netscape.net> 5 Subject: Re: Mystery multiple TCP connections dropped B Message-ID: <1156528127.838827.266110@74g2000cwt.googlegroups.com>  
 AEF wrote:D > I run a trading application that sends data to multifeed data feedH > distributers. It's a little complicated and I'll try to describe it as > clearly as possible. > E > The first two paragraphs below describe the overall set up. I'm not H > sure how relevant they really are. The third and fourth paragraphs are > the actual problem.  > F > The back-end runs on several MicroVAX systems. There is the host, orD > market system, on which the market exists. Connected to the marketI > system are DECnet Phase IV end nodes (which are also MicroVAX systems). C > 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 andC > data-feed processes. Each data-feed process maintains a "page" of D > issues, bids, and offers. The page data is sent to "multifeed DFD"H > systems via TCP connections. Three are in NY and one is in London. TheG > ones in NY are various combinations of WinXP or Win2k running on Dell E > Optiplex 620 or Compaq DL580 boxes. I'm don't know about the London E > system. (These multifeeds pass the page data onto other systems and ' > eventually to brokers and customers.)  > H > Anyway, for one of my markets I have four pages: 45 thru 48. Each pageF > runs on a separate end node MicroVAX. (The MicroVAX systems for thisG > market are all in London.) Each end-node MicroVAX has a data-feed job G > that sends the page data to all four multifeeds. Now, on both Tuesday H > and Thursday mornings, at about 7:15 or 7:30 London time, I lose pagesG > 46 and 47 on all three NY multifeed systems, but these same pages are - > still running fine to the London multifeed.  > G > So the page 46 job was running on one (London) MicroVAX, sending data H > to all 4 Multifeeds, when suddenly all within a tenth of a second, theB > TCP connections to the 3 NY multifeeds dropped, while the fourthD > connection to the London multifeed stayed up. The same exact thingG > happened with page 47 which runs on another (London) MicroVAX sending B > data to the same 4 multifeeds, at the same time that the page 46 > connections went down! > G > Does anyone have a clue as to what could be causing this? In summary, I > each MicroVAX is sending data for its page via TCP connections (telnet, I > whatever) to four multifeeds. With 4 MicroVAX systems that's a total of G > 16 connections. On each of the two of the MicroVAXes running jobs for I > pages 46 and 47, the three connections (total of 6) suddenly die within H > a tenth of a second of each other. The same pages had the same problemC > on both Tuesday and Thursday mornings (London time). (The page-46 G > MicroVAX system is running VMS v6.1 and the page-47 system is running  > VMS v6.2). > C > I know this will appear confusing at first read. I'll be happy to A > answer any questions to clear up any confusion as to the setup.  > I > 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!  >   < So the problem doesn't seem to be with the MicroVax systems.  G Pages 45 and 48 got to NY okay? And, the two systems providing pages 46 C and 47 were working properly (as proven by the uninterrupted London E operation). You say three connections, but I'd suspect one connection G --- a comm. channel that connects London to NY. What do the Page 46 and & 47 systems share but not with 45 & 48?  D You say TCP/IP, but what protocol? Are you using a private or leasedF line or the internet? This sounds like an application that needs to be& *very* secure. How is it secured? VPN?  A How soon did the connection come back? What did you have to do to " restore is? Has it happened again?  D Whenever a short duration interruption happens more than once at theB same time of day, most of the time it's because something happenedC along the service line (power, or in your case communication), like A someone was working on something or equipment was being switched.    ------------------------------    Date: 25 Aug 2006 12:21:27 -0700$ From: "AEF" <spamsink2001@yahoo.com>5 Subject: Re: Mystery multiple TCP connections dropped C Message-ID: <1156533687.487136.325770@i42g2000cwa.googlegroups.com>    Doug Phillips wrote: > AEF wrote:F > > I run a trading application that sends data to multifeed data feedJ > > distributers. It's a little complicated and I'll try to describe it as > > clearly as possible. > > G > > The first two paragraphs below describe the overall set up. I'm not J > > sure how relevant they really are. The third and fourth paragraphs are > > the actual problem.  > > H > > The back-end runs on several MicroVAX systems. There is the host, orF > > market system, on which the market exists. Connected to the marketK > > system are DECnet Phase IV end nodes (which are also MicroVAX systems). E > > 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,B > > executions, etc.). On these end nodes run trader processes andE > > data-feed processes. Each data-feed process maintains a "page" of F > > issues, bids, and offers. The page data is sent to "multifeed DFD"J > > systems via TCP connections. Three are in NY and one is in London. TheI > > ones in NY are various combinations of WinXP or Win2k running on Dell G > > Optiplex 620 or Compaq DL580 boxes. I'm don't know about the London G > > system. (These multifeeds pass the page data onto other systems and ) > > eventually to brokers and customers.)  > > J > > Anyway, for one of my markets I have four pages: 45 thru 48. Each pageH > > runs on a separate end node MicroVAX. (The MicroVAX systems for thisI > > market are all in London.) Each end-node MicroVAX has a data-feed job I > > that sends the page data to all four multifeeds. Now, on both Tuesday J > > and Thursday mornings, at about 7:15 or 7:30 London time, I lose pagesI > > 46 and 47 on all three NY multifeed systems, but these same pages are / > > still running fine to the London multifeed.  > > I > > So the page 46 job was running on one (London) MicroVAX, sending data J > > to all 4 Multifeeds, when suddenly all within a tenth of a second, theD > > TCP connections to the 3 NY multifeeds dropped, while the fourthF > > connection to the London multifeed stayed up. The same exact thingI > > happened with page 47 which runs on another (London) MicroVAX sending D > > data to the same 4 multifeeds, at the same time that the page 46 > > connections went down! > > I > > Does anyone have a clue as to what could be causing this? In summary, K > > each MicroVAX is sending data for its page via TCP connections (telnet, K > > whatever) to four multifeeds. With 4 MicroVAX systems that's a total of I > > 16 connections. On each of the two of the MicroVAXes running jobs for K > > pages 46 and 47, the three connections (total of 6) suddenly die within J > > a tenth of a second of each other. The same pages had the same problemE > > on both Tuesday and Thursday mornings (London time). (The page-46 I > > MicroVAX system is running VMS v6.1 and the page-47 system is running  > > VMS v6.2). > > E > > I know this will appear confusing at first read. I'll be happy to C > > answer any questions to clear up any confusion as to the setup.  > > K > > Thanks in advance to all who try to come up with some clues and also to 1 > > those who actually read this far in the post!  > >  > > > So the problem doesn't seem to be with the MicroVax systems. > ! > Pages 45 and 48 got to NY okay?   : Yes, there was not problem with those pages on either day.  ' And, the two systems providing pages 46 E > and 47 were working properly (as proven by the uninterrupted London 
 > operation).   3 They've been working fine day after day for months.   ; > You say three connections, but I'd suspect one connection I > --- a comm. channel that connects London to NY. What do the Page 46 and ( > 47 systems share but not with 45 & 48?  G Each page carries data for different "issues". An issue is a trade-able G entity, like stocks, bonds, repos, etc. Otherwise they are the same. By > three connections I mean three lines on a (TCPWARE) NETCU SHOW+ CONNECTIONS display (NETSTAT-like command).    > F > You say TCP/IP, but what protocol? Are you using a private or leasedH > line or the internet? This sounds like an application that needs to be( > *very* secure. How is it secured? VPN?  " Telnet. Private line. It's secure.  C > How soon did the connection come back? What did you have to do to $ > restore is? Has it happened again?   It didn't. I got the  * %SYSTEM-F-VCCLOSED, virtual circuit closed  E error from the application. This is the same error I get if I go into G the multifeed program (which is running on the Windows box) and disable E the TCP port or if I just close the program. I had to restart the job C on the VAX to recover. Fortunately we were saved by redundancy. The G London multifeed, which lost no connections, saved the day. It happened , twice: once on Tuesday and once on Thursday.   > F > Whenever a short duration interruption happens more than once at theD > same time of day, most of the time it's because something happenedE > along the service line (power, or in your case communication), like C > someone was working on something or equipment was being switched.   A On Tuesday it happened at 06:13:31 but on Thursday it happened at 	 06:52:17.    Thanks for your help.    AEF    ------------------------------    Date: 25 Aug 2006 12:58:57 -0700$ From: "AEF" <spamsink2001@yahoo.com>5 Subject: Re: Mystery multiple TCP connections dropped B Message-ID: <1156535937.041796.252350@75g2000cwc.googlegroups.com>   Dale Dellutri wrote:D > On 25 Aug 2006 08:33:38 -0700, AEF <spamsink2001@yahoo.com> wrote:F > > I run a trading application that sends data to multifeed data feedJ > > distributers. It's a little complicated and I'll try to describe it as > > clearly as possible. > G > > The first two paragraphs below describe the overall set up. I'm not J > > sure how relevant they really are. The third and fourth paragraphs are > > the actual problem.  > H > > The back-end runs on several MicroVAX systems. There is the host, orF > > market system, on which the market exists. Connected to the marketK > > system are DECnet Phase IV end nodes (which are also MicroVAX systems). E > > 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,B > > executions, etc.). On these end nodes run trader processes andE > > data-feed processes. Each data-feed process maintains a "page" of F > > issues, bids, and offers. The page data is sent to "multifeed DFD"J > > systems via TCP connections. Three are in NY and one is in London. TheI > > ones in NY are various combinations of WinXP or Win2k running on Dell G > > Optiplex 620 or Compaq DL580 boxes. I'm don't know about the London G > > system. (These multifeeds pass the page data onto other systems and ) > > eventually to brokers and customers.)  > J > > Anyway, for one of my markets I have four pages: 45 thru 48. Each pageH > > runs on a separate end node MicroVAX. (The MicroVAX systems for thisI > > market are all in London.) Each end-node MicroVAX has a data-feed job I > > that sends the page data to all four multifeeds. Now, on both Tuesday J > > and Thursday mornings, at about 7:15 or 7:30 London time, I lose pagesI > > 46 and 47 on all three NY multifeed systems, but these same pages are / > > still running fine to the London multifeed.  > I > > So the page 46 job was running on one (London) MicroVAX, sending data J > > to all 4 Multifeeds, when suddenly all within a tenth of a second, theD > > TCP connections to the 3 NY multifeeds dropped, while the fourthF > > connection to the London multifeed stayed up. The same exact thingI > > happened with page 47 which runs on another (London) MicroVAX sending D > > data to the same 4 multifeeds, at the same time that the page 46 > > connections went down! > I > > Does anyone have a clue as to what could be causing this? In summary, K > > each MicroVAX is sending data for its page via TCP connections (telnet, K > > whatever) to four multifeeds. With 4 MicroVAX systems that's a total of I > > 16 connections. On each of the two of the MicroVAXes running jobs for K > > pages 46 and 47, the three connections (total of 6) suddenly die within J > > a tenth of a second of each other. The same pages had the same problemE > > on both Tuesday and Thursday mornings (London time). (The page-46 I > > MicroVAX system is running VMS v6.1 and the page-47 system is running  > > VMS v6.2). > E > > I know this will appear confusing at first read. I'll be happy to C > > answer any questions to clear up any confusion as to the setup.  > K > > Thanks in advance to all who try to come up with some clues and also to 1 > > those who actually read this far in the post!  > ; > I'm confused about the physical topology of your network.  > B > Are the end nodes in London connected via DECnet Phase IV to theD > US end nodes?  And if they are, are the TCP connections going over/ > the same circuits (same ethernet controller)?   B There are no US end nodes for this market. (There are for my otherF market [instance of this trading system], but not for this one.) ThreeD of the multifeeds are in New York and one is in London. The MicroVAXD systems for this market are all in London. I think a short list-type table should make it clear:    London:  Several MicroVAX systems One multifeed Windows system.   	 New York:   Three multifeed Windows systems.  G So the only thing common to all this is the WAN. But why the same 2 out E of four pages (which means, of course, the same two MicroVAX systems)  in both incidents?  D The DECnet stuff has nothing to do with the TCP connections from theD MicroVAX systems to the multifeeds. I just mentioned that part as to> how the market system communicates with its end nodes. The TCPG connections in question go directly from the end nodes to the multifeed @ boxes using TCP/IP (telnet protocol). Each MicroVAX has only oneE Ethernet controller. I think it's the same on the multifeeds (Windows F systems) as each one is accessed by only one IP address by my MicroVAX systems.   > > > Do the TCP connections go through the internet (perhaps with6 > a VPN), or is it a direct leased line or equivalent?  
 Private line.   A > (I'm trying to determine if this is a TCP-only type of problem,  > or a physical link problem.) > D > Is there anything that happens on the London end nodes at 7:15 AM?A > Batch jobs, large influx of users, etc.?  Anything that happens ? > at that time on the NY multifeed DFD's.  (I don't know what a 5 > "multifeed DFD" is, and google didn't know either.)   C The Tuesday problem happened at 06:13:31 UTC (GMT) and the Thursday ' problem happened at 06:52:17 UTC (GMT).   ? The 7:15 I mentioned previously is just the rough time of these E incidents in BST (British Summer Time) which is currently local civil G time for London. What happens then is users start coming in to work and @ post bids and offers. But that happens every workday. Note: ThisF problem happened before any prices were posted (for both incidents). I= don't think it means anything. Some users connected via their + front-ends before the incident on each day.   G A multifeed DFD is a DFD that can accept data from multiple systems via C different TCP ports. A DFD (Data Feed Distributer) accepts data and D distributes it to multiple targets. Just think of the multifeed as aD Windows box running a customized-for-us "multifeed" application thatF accepts data from multiple systems (MicroVAX systems in this case) andF "concentrates" them into a single feed to pass along to other systems.G The feed eventually reaches brokers and customers and displays the data D on different pages. In my case, each MicroVAX end node runs a singleF job that generates data for a single page. So I guess you can think of  the multifeed as a concentrator.   > E > Are there routers, switches or bridges in between that keep (or can C > be induced to keep) any kind of logs?  Did the logs on the London F > end node for any communiction protocol (DECnet or TCP) show anything > funny at 7:15 AM?   > I talked to one of our network guys and he said the following:G The logging on the routers is not full enough to give sufficient detail : to hep us. The logs for the switches show nothing unusual.   >  > --9 > Dale Dellutri <ddelQQQlutr@panQQQix.com> (lose the Q's)   = Thanks for your help! I hope the situation is more clear now.    ------------------------------  % Date: Fri, 25 Aug 2006 16:51:50 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 5 Subject: Re: Mystery multiple TCP connections dropped , Message-ID: <44EF62DD.4EA06473@teksavvy.com>  E Couple of thoughts. For one node to detect that a TCPIP link has been F disconnected (virtual circuit closed), it takes more than a line beingC phsyically cut. TCPIP is quite resilient to temporary outages (aka:  delay in transmission).   F So, if one node gets a "circuit has been closed" message, it is likelyE that it received the TCPIP packets announcing the circuit was closed. F (as opposed to some temporary outage), OR, the line went down for longF enough that some inactivity timeout happened and the node decided thatD sicne it hadn't received any ACks/NAks/KEEPALIVE/data in X time, the circuit should be closed.   H Do you have any routers between the TCPIP nodes ? Are they NAT routers ?  H You mention TELNET. Does this mean that the applications will encode theE data to escape certain control characters just like on an interactive E telnet session ?  Is there a reason to use TELNET isntead of just raw  TCPIP ?     G Another thing to investigate: is it possible that someone on the system D would have issued the equivalent of DISCONNECT/LINK=xxxx  ? This tooE would cause the application to be told that the link is no longer up. H (aka: security issue with a hacker, or some ill trained operator causing! problems without ill intentions).    ------------------------------  % Date: Fri, 25 Aug 2006 17:10:25 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 5 Subject: Re: Mystery multiple TCP connections dropped , Message-ID: <44EF6737.6E799376@teksavvy.com>  
 AEF wrote:I > time for London. What happens then is users start coming in to work and B > post bids and offers. But that happens every workday. Note: ThisH > problem happened before any prices were posted (for both incidents). I? > don't think it means anything. Some users connected via their - > front-ends before the incident on each day.   A Is it possible that the TELNET link died a long time ago but goes H undetected because TCPIP is fully able to do survive outages, and at theH first packet being sent, the system then notices it isn't getting an ACK' and declares the channel to be closed ?     @ > I talked to one of our network guys and he said the following:I > The logging on the routers is not full enough to give sufficient detail < > to hep us. The logs for the switches show nothing unusual.  F When your systems are iddle (at night for instance), is there any dataF that goes through thos TELNET links ? Have you considered coding a fewF timed ASTs in yor application to send a "hello there" message every 10# minutes when there is no activity ?   G This way, your application could detect an outage during idle times and N give you better insight on when (within a 10 minute window) the outage begins.   ------------------------------    Date: 25 Aug 2006 14:41:46 -0700$ From: "AEF" <spamsink2001@yahoo.com>5 Subject: Re: Mystery multiple TCP connections dropped C Message-ID: <1156542106.103073.317330@p79g2000cwp.googlegroups.com>    JF Mezei wrote:  > AEF wrote:K > > time for London. What happens then is users start coming in to work and D > > post bids and offers. But that happens every workday. Note: ThisJ > > problem happened before any prices were posted (for both incidents). IA > > don't think it means anything. Some users connected via their / > > front-ends before the incident on each day.  > C > Is it possible that the TELNET link died a long time ago but goes J > undetected because TCPIP is fully able to do survive outages, and at theJ > first packet being sent, the system then notices it isn't getting an ACK) > and declares the channel to be closed ?   D I don't think so. See below about the timestamps. Also, the death ofD the connection appears identical to what happens if I either disable> the page's port in the multifeed program or if I just shut theG multifeed program altogether. (The job on the VAX gives identical error ! messages for all three scenarios:   + %SYSTEM-F-VCCLOSED, virtual circuit closed)   B > > I talked to one of our network guys and he said the following:K > > The logging on the routers is not full enough to give sufficient detail > > > to hep us. The logs for the switches show nothing unusual. > H > When your systems are iddle (at night for instance), is there any dataH > that goes through thos TELNET links ? Have you considered coding a fewH > timed ASTs in yor application to send a "hello there" message every 10% > minutes when there is no activity ?   F Each feed job running on the MicroVAX systems sends a timestamp to theC multifeeds every 15 seconds. The original purposes of this was as a C keep-alive and the time to be displayed on customer screens. In the A event of a feed outage the multifeed would then time-out after 60 G seconds of silence. This was to prevent the occurrence of stale prices. E However, we used to have a lot of trouble with the multifeed program, B and the timeout was originally global (and therefore, ineffective,E don't ask why it was global) so we don't really use the timeouts now. F It's a very long story. Don't ask. I don't have the time to explain it all.  I > This way, your application could detect an outage during idle times and P > give you better insight on when (within a 10 minute window) the outage begins.  F Fortunately we were saved on Tuesday by the redundant London multifeedE (only London uses these pages, at least at that hour) and on Thursday ? by both that and our monitoring (which woke me up at 2:33). The ? monitoring failed on Tuesday due to some confusion with how the E multifeed's syslog server should be configured due to some changes in F the mail system. The marketdata people (who manage the multifeeds) andD the mail admins pointed fingers at each other. Anyway, it was fixed.   Thanks for your efforts.   AEF    ------------------------------  % Date: Fri, 25 Aug 2006 22:41:03 -0500 % From: Dan Foster <usenet@evilphb.org> ? Subject: Re: Reading UAF Disuser Flag Across Nodes from FORTRAN 5 Message-ID: <slrneevgmf.sng.usenet@zappy.catbert.org>   v In article <1156562748.043456.197730@b28g2000cwb.googlegroups.com>, wendzinski@yahoo.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.  E It depends... if this is for clustered nodes, they would be running a  cluster-common shared UAF.  H If this is for standalone, non-clustered nodes, then one way might be to use a DECnet task object.    -Dan   ------------------------------  % Date: Sat, 26 Aug 2006 00:19:45 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ? Subject: Re: Reading UAF Disuser Flag Across Nodes from FORTRAN , Message-ID: <44EFCBD5.1D92A3F5@teksavvy.com>   wendzinski@yahoo.com wrote: 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.  H Not sure if this applies to $GETUAI, but normally the logical SYSUAF can? be set to point to an alternate file. If that file resides on a E different node, make sure the file specification is full and that any C proxies are set properly (or file spec includes username/password).   H If a simple DEFINE SYSUAF does not work, you may have to try DEFINE/EXEC (this needs privileges).   ------------------------------  % Date: Fri, 25 Aug 2006 12:15:32 -0700 ! From: Fred Bach <music@triumf.ca> = Subject: Re: Thoughts on the book: DEC is dead, long live DEC ( Message-ID: <44EF4C54.7080609@triumf.ca>  4    At last, a statement I can completely agree with.  C    One man *can* make a huge difference.  But to do so, a couple of H    the qualities he needs are vision and some kind of charisma effectiveB    in his particular field.   For a while, Olsen had both.  And asD    pointed out indirectly in the last few posts, sometimes it reallyE    does depend on *who* you know.  Given all 3 'qualities', Olsen was C    bound to succeed, but of course it could not last forever.  Some 4    people are surprised it lasted as long as it did.  *     ... Fred Bach  music at triumf dot c a   bclaremont wrote: ; > Nice discussion.  Interesting observations and rebuttals.  > F > What continually impresses me is the incredible impact an individualF > like Ken Olsen had on an industry and thousands, perhaps millions ofG > people.  In a sense this legacy lives on in OpenVMS, given the small, H > diverse core of engineers that continues to support the O/S.  I tip my/ > hat to all of you, past, present, and future.  >    ------------------------------  % Date: Fri, 25 Aug 2006 16:38:11 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> = Subject: Re: Thoughts on the book: DEC is dead, long live DEC , Message-ID: <44EF5FAA.FD7C074F@teksavvy.com>   bclaremont wrote: F > What continually impresses me is the incredible impact an individualF > like Ken Olsen had on an industry and thousands, perhaps millions of
 > people.   G The book has a chapter dedicated to that. The number of DECies who left F to either start their own business (Data General) or moved to high endF jobs at places like Sun etc. And during the Palmer era, DEC donated soB many engineers to companies like Quantum that bought the disk/tape
 business etc.   C Another mention of DEC's legacy: the author claims that many of the H current chips, even the 8086, 68k etc lines inherited a lot from the PDP? architectures which had broken the ground on that type of chip.   C Interestingly to me, there are 2 things where DEC ended up giving a F dominant product: the VT100 as well as DLT tapes. (DLT may disapear inI near term, but I think VT100 emulation will remain for a very long time).   : I think that Ethernet and X-windows is also very importantH contributions, even though DEC wasn't working alone. And to some extent,H a lot of the internet is DEC elements in it. (just look at the number of  RFCs authored by DEC employees).  F The rest of DEC's legacy is really just "inspiration" used succesfully by other companies.   C One big problem is that relatively few people know that some of the 0 technology they are using today emanated at DEC.   ------------------------------  % Date: Fri, 25 Aug 2006 18:14:15 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> = Subject: Re: Thoughts on the book: DEC is dead, long live DEC < Message-ID: <44ef74d7$0$24193$9a6e19ea@news.newshosting.com>  3 "bclaremont" <msi1@earthlink.net> wrote in message  < news:1156519481.469441.60380@p79g2000cwp.googlegroups.com...; > Nice discussion.  Interesting observations and rebuttals.  > F > What continually impresses me is the incredible impact an individualF > like Ken Olsen had on an industry and thousands, perhaps millions ofG > people.  In a sense this legacy lives on in OpenVMS, given the small, H > diverse core of engineers that continues to support the O/S.  I tip my/ > hat to all of you, past, present, and future.  >   J If there was ever such a thing as "the soul of the machine" then it is my 9 belief that a piece of Ken Olsen lives in my OpenVMS box.   E I was fortunate enough to find my self getting a large amount of DEC  L Hardware Training (in order to do customer self-support) on site at Digital I in Kanata, Montreal, Bedford, and Maynard, between 1977 and 1993. It was  K obvious to all students that this was a different kind of company and that  1 DEC employees seemed very proud as well as happy.   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada." http://www3.sympatico.ca/n.rieck/    ------------------------------  % Date: Fri, 25 Aug 2006 22:45:43 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> = Subject: Re: Thoughts on the book: DEC is dead, long live DEC , Message-ID: <44EFB5D2.9F5DC817@teksavvy.com>   Neil Rieck wrote: K > If there was ever such a thing as "the soul of the machine" then it is my ; > belief that a piece of Ken Olsen lives in my OpenVMS box.   D After reading the book, I have less of this feeling. Olsen empoweredE people to direct and run DEC. He created the environment that allowed H Engineers to go wild , have fun and develop neat stuff. The book gave meF the impression that Olsen was significantly less "hands on" than I had= thought before.  (doesn't mean I have less respect for him).    D Also, the book mentions in one place that the decisions not to adoptG "commodity" stuff and continue with expensive proprietary stuff was not G a direct Olsen policy, but just something which the various engineering ? groups decided. So DEC's continued "proprietary" nature isn't a F reflection of Olsen per say. Olsen didn't make those decisions, but heD also didn't try to nudge engineers away from proprietary components.A (maybe he did in real life, but it wasn't mentioned in the book).     H Another image I got from the book is that until the mid 1980s, DEC lived@ pretty much in "DOT COM" boom mode where money was no object andG engineers were let loose to develop any/all technologies in the hope of D getting more cash cows. It worked as long as growth was greater thanH ensuing inefficiencies. Come competition, and things unravelled quickly.  E (again, that is based on how I understood that book which is based on % how some consultant understood Olsen)       J > in Kanata, Montreal, Bedford, and Maynard, between 1977 and 1993. It wasL > obvious to all students that this was a different kind of company and that3 > DEC employees seemed very proud as well as happy.   C Yep. When I bought the first machines, and took the courses, it was @ quite apparent to me. My then boss' husband was a high level IBMG engineer/consultant and he inspected the hardware when it was delivered H and said that he was impressed, that it was really well done, built/high
 quality etc.    E However, when this success lead to headquarters wanting to deploy DEC G gear throughoput the organisation, (87/88 timeframe) I saw another side F of DEC that was REALLY ignorant of the competition, extremely arrogantA and of course very much more expensive. In fairness though, their C proposal was far more realistic than DG's and that company ended up G spending much more to get that DG junk working compared to if they have F bought the DEC gear at list price (that is what DEC had submitted as aC bid wirth more than a million dollars). The "more realistic" was an D aspect which the book confirmed with Olsen's demands that DEC remainC honest and not "lie" through marting exagerated stuff to customers.    ------------------------------  % Date: Fri, 25 Aug 2006 21:35:19 -0600 % From: Dan O'Reilly <dano@process.com> = Subject: Re: Thoughts on the book: DEC is dead, long live DEC A Message-ID: <6.1.2.0.2.20060825213027.030fe660@raptor.psccos.com>   & At 08:45 PM 8/25/2006, JF Mezei wrote: >Neil Rieck wrote:M > > If there was ever such a thing as "the soul of the machine" then it is my = > > belief that a piece of Ken Olsen lives in my OpenVMS box.  > E >After reading the book, I have less of this feeling. Olsen empowered F >people to direct and run DEC. He created the environment that allowedI >Engineers to go wild , have fun and develop neat stuff. The book gave me G >the impression that Olsen was significantly less "hands on" than I had = >thought before.  (doesn't mean I have less respect for him).   K But that's EXACTLY the point.  Olsen provided the soul of DEC and that was  A reflected in engineering and in the products.  An organization's  J temperament is a direct reflection of management at the top.  I've worked B at other organizations that were the same way.  MCI comes to mind E immediately: so long as the founder McGowan was there, it was a VERY  H different organization from what it became.  FEDEX is another one: take 6 Fred Smith out of FEDEX and the soul of FEDEX changes.  I >Another image I got from the book is that until the mid 1980s, DEC lived A >pretty much in "DOT COM" boom mode where money was no object and H >engineers were let loose to develop any/all technologies in the hope ofE >getting more cash cows. It worked as long as growth was greater than I >ensuing inefficiencies. Come competition, and things unravelled quickly.   L In its own way, pretty much true, but there's a big difference: Digital was L successful, the dot coms weren't; they were phantom businesses.  Digital is K different because it was defining an industry as it went along, and that's  D what made it successful.  Dot coms were "successful" mostly on pure  speculation.   ------J +-------------------------------+----------------------------------------+J | Dan O'Reilly                  |  "There are 10 types of people in this |J | Principal Engineer            |   world: those who understand binary   |J | Process Software              |   and those who don't."                |J | http://www.process.com        |                                        |J +-------------------------------+----------------------------------------+   ------------------------------    Date: 25 Aug 2006 12:08:01 -0700 From: "Verne" <verne@wvnet.edu> / Subject: VMS 8.3 for Alpha has been received... C Message-ID: <1156532878.253641.249010@i42g2000cwa.googlegroups.com>   E On Wednesday we got our new 8.3 manuals, and yesterday (Thursday) our  CDrom binaries arrived.   D We (only) have our Alpha under contract and thus got an update kit IC guess; it had just 17 perfect-bound manuals;  no idea when the IA64 D stuff will hit the streets ... I'll have to start thinking on how to get v8.3 for my new RX1620  :-)    Verne    ------------------------------    Date: 25 Aug 2006 12:10:31 -0700; From: "johnhreinhardt@yahoo.com" <johnhreinhardt@yahoo.com> 3 Subject: Re: VMS 8.3 for Alpha has been received... A Message-ID: <1156533030.953145.76820@74g2000cwt.googlegroups.com>    Verne wrote:G > On Wednesday we got our new 8.3 manuals, and yesterday (Thursday) our  > CDrom binaries arrived.  > F > We (only) have our Alpha under contract and thus got an update kit IE > guess; it had just 17 perfect-bound manuals;  no idea when the IA64 F > stuff will hit the streets ... I'll have to start thinking on how to! > get v8.3 for my new RX1620  :-)  >  > Verne   F I've been trying to scrounge up a copy myself without much luck.  Hope you do better.     John H. Reinhardt    ------------------------------  % Date: Fri, 25 Aug 2006 16:10:17 -0400 , From: Hoff Hoffman <hoff-remove-this@hp.com>3 Subject: Re: VMS 8.3 for Alpha has been received... * Message-ID: <44ef592b@usenet01.boi.hp.com>   johnhreinhardt@yahoo.com wrote:   L > I've been trying to scrounge up a copy [of OpenVMS I64 V8.3 -hoff] myself  > without much luck.  K    OpenVMS V8.3 in the manufacturing and distribution pipeline.  The local  O manufacturing organization has been working on it for a while, and I know that  G the process at one of the other manufacturing centers is also underway.   P    OpenVMS I64 software is packaged differently than that of OpenVMS Alpha, and O the former requires either a software support contract and an explicit request  J for the kit, or (with no contract) a new version re-purchase; there is no 8 separate subscription service for the distribution DVDs.  K    The EFT and SDK sites already have access to copies of the V8.3 release.    ------------------------------  % Date: Fri, 25 Aug 2006 15:53:08 -0400 , From: Hoff Hoffman <hoff-remove-this@hp.com>. Subject: Re: what is capacity of a TF85 drive?* Message-ID: <44ef5526@usenet01.boi.hp.com>   johnhreinhardt@yahoo.com wrote:  > Bob Koehler wrote:B >> I've seen one site which claims 2/4 GB and one which claims 10. > I > Google results on "TF85 capacity" seem to indicate that it was 2.6GB. I H > don't know if that was with or without compression (if compression was& > even available - I think it wasn't).  N    It's 2.6GB, no compression, and the TF857 loader is 18.2GB, and (as it was Q then known) VAX/VMS V5.4-2 and later, and roughly 800 KBs.  Built-in EDC, though  M I'm usually sufficiently paranoid to continue to use BACKUP CRCs in any case.    ------------------------------    Date: 25 Aug 2006 13:42:21 -0500 From: briggs@encompasserve.org Subject: Re: WWENG2.SYS 3 Message-ID: <RUzoByjh00mh@eisner.encompasserve.org>   X 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?)  > G > The DECserver 700 software (UPI XA5AA) Version 1.1C was last included ) > in the June 2003 VAX & Alpha ConDist's.   D I imagine that was WWENG1.SYS or WWENG.SYS or some such.  There wereE two versions of DECserver 700 software.  One was LAT only.  The other E was the NAS software and supported LAT, TCP, IPX and PPP.  You needed C 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  A Having looked on CONDIST for the DECserver NAS software once upon B a time, it is my recollection that the software on ConDist doesn't have WWENG2.   ------------------------------  % Date: Fri, 25 Aug 2006 16:05:23 -0400 / From: "William Webb" <william.w.webb@gmail.com>  Subject: Re: WWENG2.SYS I Message-ID: <8660a3a10608251305r3a783316me4e5dc38a3ffe735@mail.gmail.com>   7 On 25 Aug 2006 13:42:21 -0500, briggs@encompasserve.org ! <briggs@encompasserve.org> wrote: Z > 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?)  > > I > > The DECserver 700 software (UPI XA5AA) Version 1.1C was last included + > > in the June 2003 VAX & Alpha ConDist's.  > F > I imagine that was WWENG1.SYS or WWENG.SYS or some such.  There wereG > two versions of DECserver 700 software.  One was LAT only.  The other G > was the NAS software and supported LAT, TCP, IPX and PPP.  You needed E > 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 > C > Having looked on CONDIST for the DECserver NAS software once upon D > a time, it is my recollection that the software on ConDist doesn't > have WWENG2. >   E 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:   E WWENG2.SYS as the DNAS software discussed in this thread required 4MB  of memory to run.    WWWebb --  ! I'm no longer job-hunting, folks.   F Thanks to all those who expressed concern and sent me possibilities to investigate.   ------------------------------  % Date: Fri, 25 Aug 2006 19:32:16 -0500 / From: Chris Scheers <chris@applied-synergy.com>  Subject: Re: WWENG2.SYS * Message-ID: <4l9j4cFtrl4U1@individual.net>   Martin Vorlaender wrote:0 > JF Mezei <jfmezei.spamnot@teksavvy.com> wrote:$ >> "johnhreinhardt@yahoo.com" wrote:! >>> FWIW I am now using the NA013 A >>> DECserver kit which I got from a CONDIST from in the 1993, 94 H >>> timeframe.  It has separate portions for both the 700 and the 900TM.. >>> The download image provided is WWENG1.SYS F >> I would be willing to check my condists to see what I have. Can you9 >> provide me with a hint of what directory to look for ?  > 5 > [NA013] was on disk 2 of the June 1994 AXP ConDist.  > J > On disk 5 of the June '94 VAX ConDist is [NA7013] which also appeared onH > disk 1 of the March '95 VAX SPL Supplement. [NA7015] resides on disk 1G > of the June '95 VAX SPL Supplement. But these apparently only carry a  > DECserver 700 image.   Thanx for the info.   I Unfortunately, these seem to be among the few VAX CONDISTs I am missing.     <sigh>  @ I have all 12 disks of the June '95 VAX SPL, but I don't have a F Supplement disk.  Actually, I don't remember ever seeing a Supplement  disk.  What are those?   --  G ----------------------------------------------------------------------- $ Chris Scheers, Applied Synergy, Inc.  B Voice: 817-237-3360            Internet: chris@applied-synergy.com    Fax: 817-237-3074   ------------------------------  % Date: Fri, 25 Aug 2006 16:23:20 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ; Subject: Re: X-terminal connects get hosed, requires reboot , Message-ID: <44EF5C30.518B694E@teksavvy.com>   tadamsmar wrote:? > I am not sure, the whole process is automatic when I reset or D > power-cycle the X-terminal.  I have never thought about that.  The8 > X-terminal loads lots of stuff, fonts and other stuff.  G When, on the VMS side, you do a SET DISPLAY/CREATE/NODE=x/TRANSPORT=X , F it creates a "temporary" device which evaporates once the process thatD created it is gone AND all applications running on that VMS node and& targetted at that display have exited.     However, if you:  1 $SET DISP/CREATE/TRANSPORT=xxx/NODE=XXX/EXECUTIVE  $MC DECW$LOGIN  A This creates a permanent WSA device and when a decwindows session A terminates, a new login process begins automatically, and it will G attempt at regular intervals if the terminal is turned off, so when you H turn it back on, you eventually get the login process. I do not think it0 is 100% reliable, but it works most of the time.    I > By the way.  While the system was in this funny state, I was still able C > to login and get a Dec$windows session going with X-free on a PC.   G That would be targetted at another WSA device which is totally separate # and handled by a different process.     E > Yeah I tried killing off all the processes that might be associated B > with the hosed X-terminals.  That did not clear up this problem.    3 During such a problem, another thing to attempt is:   ' $SET DISP/CREATE/TRANSPORT=xxx/NODE=XXX  $MC DECW$CLOCK  D This should pop the clock on the target X terminal even if it hasn't1 logged in or doesn't have a DECW$SESSION running.   H If it works, it means your X terminal is functional. If it doesn't work,F it means that it is likely your X terminal is the problem.  Or, if youH have other nodes, try having them pop a window on the problem X terminal% to see if they can or cannot succeed.    ------------------------------   End of INFO-VAX 2006.474 ************************