1 INFO-VAX	Mon, 27 Sep 2004	Volume 2004 : Issue 536       Contents:) Re: AlphaServer DS10L - IDE disk question  Re: DHCP client question Re: DHCP client question Re: DHCP client question Re: DHCP client question Re: DHCP client question Re: DHCP client question# Re: From Sun:  HP-UX has no future. 6 Re: How do time synchronize Windows 2000 with OpenVMS?6 Re: How do time synchronize Windows 2000 with OpenVMS?, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations( Re: HP gets 290 million defense contract; Re: Let me own OpenVMS and I will destroy the linux market! 1 Re: Massbus configuration issues and restrictions 1 Re: Massbus configuration issues and restrictions  Re: Off-the-wall CI Question Re: OT: Sun's fighting chance = Re: Slashdot is reporting HP is dropping Itanium workstations 5 Re: Windoze not rebooted monthly shuts down airports! 5 Re: Windoze not rebooted monthly shuts down airports! 5 Re: Windoze not rebooted monthly shuts down airports! < Re: [DCL REQUEST] New ignore keyword for DIFFERENCES command3 Re: [FTP] Is REGET now available somewhere on VMS ?   F ----------------------------------------------------------------------  % Date: Sun, 26 Sep 2004 03:33:29 +0800 , From: Paul Repacholi <prep@prep.synonet.com>2 Subject: Re: AlphaServer DS10L - IDE disk question0 Message-ID: <871xgqkut2.fsf@k9.prep.synonet.com>    Dirk Munk <munk@home.nl> writes:  A > 2. You can not use Shadow software on IDE disks, so no software  > mirroring.  = A /NOFORCEDERROR or something like that should let you do it. ? Don't complain when you get industry standard results though...    --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Sun, 26 Sep 2004 16:42:12 -0400 # From: "Bob Healey" <healer@rpi.edu> ! Subject: Re: DHCP client question 2 Message-ID: <cj79it$ifo$1@misc-cct.server.rpi.edu>  . "Bob Healey" <healer@rpi.edu> wrote in message, news:cj6q4m$h8l$1@misc-cct.server.rpi.edu... <snip>  " Further digging found my problem.:  J ucx show int se0 /full gives my ethernet_addr as aa-00-04-00-01-04, but inK the rom, show dev gives me 08-00-2b-2f-cd-0b.  So, I guess the question is, % how do i make these two values match?   
 Bob Healey   ------------------------------  % Date: Sun, 26 Sep 2004 22:30:57 +0100 < From: "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk>! Subject: Re: DHCP client question 6 Message-ID: <41573512$0$22746$db0fefd9@news.zen.co.uk>  / "Bob Healey" <healer@rpi.edu> wrote in message  , news:cj79it$ifo$1@misc-cct.server.rpi.edu... > $ > Further digging found my problem.: > L > ucx show int se0 /full gives my ethernet_addr as aa-00-04-00-01-04, but inJ > the rom, show dev gives me 08-00-2b-2f-cd-0b.  So, I guess the question  > is, ' > how do i make these two values match?  >  > Bob Healey >   I DECnet has generated your address, we can tell your DECnet address is 1.1   K DECnet starts before TCP/IP Services in your startup (this is correct), it  ) takes your 1.1 DECnet address and does...   K DECnet area * 1024 + DECnet node (i.e. 1*1024 + 1 = 1025) then it converts  J this to HEX (04-01) and inverses it (01-04), then appends it to AA-00-04- ' thus your address is AA-00-04-00-01-04.   M That is a somewhat basic and not full explanation, but should illustrate the   point.   Alex     ------------------------------  # Date: Sun, 26 Sep 2004 22:29:14 GMT % From: "John Vottero" <John@mvpsi.com> ! Subject: Re: DHCP client question = Message-ID: <_oH5d.11101$Qv5.6210@newssvr33.news.prodigy.com>   / "Bob Healey" <healer@rpi.edu> wrote in message  , news:cj6q4m$h8l$1@misc-cct.server.rpi.edu...L > I'm running a vaxstation 4000, temporarily setup to use the DHCP client toE > obtain an IP address.  It's been unable to get an address from the  
 > school'sG > server, so I examined the traffic on a network sniffer.  The packets  	 > leaving K > the machine have the correct source MAC address on the packet, but inside E > the DHCP Discovery packet, it has a field labeled "Client Hardware  
 > Address"E > which is a different value than the actual hardware address of the  
 > machine.L > As far as I can tell by examining the packets, the DHCP server is replyingH > to the "Client Hardware Address" and not the source MAC address.  DoesI > anyone know a trick I can use to tell VMS to either 1.) Not include the G > "client hardware address field" or 2.) force it to include the right   > value?J > This is only temporary as I'm waiting for some static IP assignments to  > come
 > through. >   , Try starting TCP/IP before you start DECnet.  H DECnet is changing the MAC address and it sounds like DHCP is using the  hardware address.    ------------------------------  % Date: Mon, 27 Sep 2004 01:59:14 +0200 B From: Michiel Erens <I.dont.want.spam@this.mailaddress.is.invalid>! Subject: Re: DHCP client question ! Message-ID: <41575828@news.nb.nu>    John Vottero wrote:   . > Try starting TCP/IP before you start DECnet.  + DECnet may not start after starting TCP/IP.   J > DECnet is changing the MAC address and it sounds like DHCP is using the  > hardware address.   E Better, put the "DECnet MAC-address" (AA-00-04-00-01-04) in the DHCP    server as the unique identifier.   --   ME Posted by news://news.nb.nu    ------------------------------  % Date: Sun, 26 Sep 2004 22:10:03 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>! Subject: Re: DHCP client question + Message-ID: <4157848B.F836FA1D@comcast.net>    Bob Healey wrote:  > 0 > "Bob Healey" <healer@rpi.edu> wrote in message. > news:cj6q4m$h8l$1@misc-cct.server.rpi.edu... > <snip> > $ > Further digging found my problem.: > L > ucx show int se0 /full gives my ethernet_addr as aa-00-04-00-01-04, but inM > the rom, show dev gives me 08-00-2b-2f-cd-0b.  So, I guess the question is, ' > how do i make these two values match?   G If you can live without DECnet, don't start it. That's what changes it.    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Mon, 27 Sep 2004 00:40:11 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ! Subject: Re: DHCP client question , Message-ID: <4157999A.9E23C937@teksavvy.com>  Q On my system, TCPIP uses the decnet ethernet address AA-00-04etc for ARP packets.   L The documentation states that the client was "stolen" from Tru64. This meansH that it probably isn't aware of the ethernet interface change by DECNET.  L Is it possible that you start DECNET and TCPIP concurrently and that part ofK the TCP stack starts before DECNET has changed the ethernet address and the ) rest builds after DECNET has changed it ?    ------------------------------  % Date: Sun, 26 Sep 2004 04:10:32 +0800 , From: Paul Repacholi <prep@prep.synonet.com>, Subject: Re: From Sun:  HP-UX has no future.0 Message-ID: <87oejujeiv.fsf@k9.prep.synonet.com>  % "John Smith" <a@nonymous.com> writes:   D > VMS & PH-UX & NSK are tied to Itanic's sinking ship unless EV8 and  > beyond is revived immediately.  = You have not been reading the fine print, NSK no longer needs > lock-step CPUs, so they cauld port it to Power, or even Sparc.  F > Sun has a legitimate marketing tool in saying " We told you so about1 > HP.  C'mon over to Solaris - the water's fine."   ; Even if you don't think it is fine, it is ice free, and you - can be confident it will be there tomorrow...   C The only things hp have are ink and integrity. The Integrity is for  sale...    --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Sun, 26 Sep 2004 22:16:38 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>? Subject: Re: How do time synchronize Windows 2000 with OpenVMS? + Message-ID: <41578615.7EF15CE7@comcast.net>    "Yong Boon, Lim" wrote:  > I > l've one time server run in OpenVMS, l would like to synchronize all my ' > client which run on Windows 2000 with M > OpenVMS? l've tried to use NET TIME, but it does not work? Do anyone of you  > know how do solve this > problem? Thank you!! >  > Best Regrads,  > Yong Boon, Lim  E I believe all of the OpenVMS TCP/IP stacks provide (X)NTP these days.    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Sun, 26 Sep 2004 23:57:08 -0400 - From: "John E. Malmberg" <wb8tyw@qsl.network> ? Subject: Re: How do time synchronize Windows 2000 with OpenVMS? 1 Message-ID: <tpednXmrvp4JEsrcRVn-sA@adelphia.com>    Yong Boon, Lim wrote: F > l've one time server run in OpenVMS, l would like to synchronize all4 > my client which run on Windows 2000 with OpenVMS?   3 > l've tried to use NET TIME, but it does not work?   I The use of the NET TIME command on Microsoft Windows when directed to an  H OpenVMS host requires that the OpenVMS be running Pathworks or Advanced  Server.   > > Do anyone of you know how do solve this problem? Thank you!!  I NTP protocol is available on both platforms.  Watch out for any Daylight  F Savings time changes, as if they become active at a different time on G the OpenVMS host than on the Microsoft Windows system, the time values   will be off for a while.   -John  wb8tyw@qsl.network Personal Opinion Only    ------------------------------  % Date: Sun, 26 Sep 2004 14:32:16 -0400 * From: "Bill Todd" <billtodd@metrocast.net>5 Subject: Re: HP admits discontinued IA64 workstations = Message-ID: <27CdneFeM6JGl8rcRVn-jA@metrocastcablevision.com>   B "Robert Deininger" <rdeininger@mindspringdot.com> wrote in messageF news:rdeininger-2509041635280001@user-uinj4h5.dialup.mindspring.com...   ...   I > The "Alpha tax" was a millstone around VMS's neck for several years.  I J > don't understand where the myth got started that the Alpha chip/server +K > VMS + Tru64 business was financially healthy before the decision to phase  > out Alpha.  J That's an easy one to answer:  from people like Rich Marcello, who told usH in mid-2000 that VMS systems generated annual revenues of $4 billion andF annual profits of $800 million, and by Compaq slides like one shown inJ March, 2001, which listed VMS annual system revenue as the same $4 billionK and Tru64 annual system revenue as $3 billion (suggesting that the combined F annual profit was *well* over $1 billion).  And from people like TerryL Shannon, who quoted gross margin figures of 58% for VMS systems.  Even quiteH recently your friend Keith has quoted VMS profits as around $500 millionK annually, in case you thought Rich's comment might have been made in error.   H Plus Marcello's statement at the time of the Alphacide that annual AlphaH development costs were $150 million, and Winkler's statement at the sameK time that they were $300 million (presumably including significant non-chip H costs such as server development that would not be saved by killing EV8,G since it leveraged the EV7 server architecture that was being developed K anyway).  Do the math:  it's really not very difficult, at least for anyone D paying attention (I've been quoting these figures - and citing theirH sources - consistently for over 3 years now, so paying attention doesn'tF seem to be a significant strength of yours, but it's never too late to start).    - bill   ------------------------------  % Date: Sun, 26 Sep 2004 15:56:09 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 5 Subject: Re: HP admits discontinued IA64 workstations + Message-ID: <41571ED7.17644F0@teksavvy.com>    Nigel Barker wrote: O > Something like 20% of Superdomes are sold to run Windows. VMS & HP-UX are not  > the only players.   G If tyhis statistic is actually true, then it is terrible news for IA64.   L Considering that Windows is not yet "fully" available for 64 bit platforms ,N including IA64, and considering that Windows does not scale well on such largeF machines as Superdomes and the fact that there is very little softwareZ available for Windows on IA64, they couldn't be that many Windows/Superdome installations.  L And if the few windows/superdomes represent 20% of sales of superdome, it is) terrible news for IA64 based HP products.    ------------------------------  % Date: Sun, 26 Sep 2004 16:12:38 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 5 Subject: Re: HP admits discontinued IA64 workstations , Message-ID: <415722B3.2AF21DA5@teksavvy.com>   David J Dachtera wrote: D > Rebuffing the ubiquitous platform (IA32 and its current successor,I > x86-64)) in favor of a target that is hoped to assume Alpha's place was B > proof positive that the choice-makers of the time were hoplessly > deranged and deluded.   H Not that bad. Remember that initially, IA64 was to replace the aging andL thought to be near its limits 8086 architecture. IA64 was to go from desktopD to mainframe, be a young new revolutionary platform that would allowT mainframes to cost a lot less since they would be using high volume commodity chips.  I For HP, by the time it became obvious Ia64 wasn't going to be the miracle M solution, HP and Intel had invested too much and it was though IA64 was close 7 enough to commercial availablity to cancel the project.   N In june 2001, it was already known that IA64 was a technical failure (Compaq'sN own engineerts who worked on Alpha knew this). However, Compaq already knew itN would be taken over by HP since Carly and Curly were already cuddling together& to plan their wedding in every detail.  L Had there not been the HP takeover of Compaq, I think that Compaq would haveK allowed Alpha to limp along for quite a bit more time before announcing its E death and porting to IA64. HP's takeover forced Compaq to prematurely 3 transform its long term plan into a short term one.     I It was clear that Compaq had no intentions to leverage Alpha. But it also J needed the revenus from VMS/Tru64/Alpha to subsidize its wintel operation.   ------------------------------  # Date: Sun, 26 Sep 2004 20:23:55 GMT ! From: Nigel Barker <nigel@hp.com> 5 Subject: Re: HP admits discontinued IA64 workstations 8 Message-ID: <rf8el0tr9mv2n0bnfnr22ifdh0srsahiel@4ax.com>  K On Sun, 26 Sep 2004 15:56:09 -0400, JF Mezei <jfmezei.spamnot@teksavvy.com>  wrote:   >Nigel Barker wrote:P >> Something like 20% of Superdomes are sold to run Windows. VMS & HP-UX are not >> the only players. > H >If tyhis statistic is actually true, then it is terrible news for IA64. > M >Considering that Windows is not yet "fully" available for 64 bit platforms , O >including IA64, and considering that Windows does not scale well on such large G >machines as Superdomes and the fact that there is very little software [ >available for Windows on IA64, they couldn't be that many Windows/Superdome installations.  > M >And if the few windows/superdomes represent 20% of sales of superdome, it is * >terrible news for IA64 based HP products.  O Your ill-informed speculation couldn't be more wrong. Superdome sales are doing M fine thank you. Customers are buying Superdomes to run Windows 64 with 64 bit I SQL Server. Windows Server 64  seems to scale perfectly well in the TPC-C  benchmark & similar workloads..    -- Nigel Barker Live from the sunny Cote d'Azur    ------------------------------  % Date: Sun, 26 Sep 2004 19:30:05 -0400 * From: "Bill Todd" <billtodd@metrocast.net>5 Subject: Re: HP admits discontinued IA64 workstations = Message-ID: <3tWdnRBYHM86zcrcRVn-vQ@metrocastcablevision.com>   . "Nigel Barker" <nigel@hp.com> wrote in message2 news:rf8el0tr9mv2n0bnfnr22ifdh0srsahiel@4ax.com...   ...   K > Your ill-informed speculation couldn't be more wrong. Superdome sales are  doing K > fine thank you. Customers are buying Superdomes to run Windows 64 with 64  bit K > SQL Server. Windows Server 64  seems to scale perfectly well in the TPC-C ! > benchmark & similar workloads..   K Perhaps you should actually *look* at the TPC-C results before spewing such G nonsense.  A 4-processor HP Itanic system running SQL Server manages to J score 121K tpmC, which is pretty good as long as you ignore the new POWER5L 4-processor result (194K tpmC).  A 16-processor HP Itanic system running SQLL Server manages only 301K tpmC:  less than a factor of 2.5x improvement usingG 4x as many processors.  And a 64-processor HP Itanic system running SQL K Server manages only 787K tpmC:  another 4x as many processors yielding only J a 2.6x increase in throughput (for a total of only 6.5x the throughput for5 16x as many processors as in the 4-processor system).   K Of course, there's also the question of just how many "Customers are buying L Superdomes to run Windows 64 with 64 bit SQL Server":  are there really veryG many clueless customers with large amounts of money to waste out there? L I've certainly heard people whose observations I trust a good deal more thanD yours state that there's virtually no use of Windows in large ItanicH systems, but if you've got *actual numbers* to report I won't call you a: liar without more substantial evidence of my own to offer.   - bill   ------------------------------  % Date: Sun, 26 Sep 2004 19:47:00 -0400 # From: "John Smith" <a@nonymous.com> 5 Subject: Re: HP admits discontinued IA64 workstations , Message-ID: <ot-dnZ52Z8RmycrcRVn-og@igs.net>   Keith Cayemberg wrote: > Robert Deininger wrote:  > <SNIP> >>A >> VMS plans haven't changed in this area.  If you didn't see any E >> affirmation of VMS plans in conjuction with the recent workstation F >> EOL announcement, it's because the two have NOTHING to do with each	 >> other.  >> >> ... > E > Also, considering that OpenVMS was never planned to be validated on @ > the Itanium Workstation Models, I suppose the OpenVMS Alpha toE > OpenVMS I64 Layered Product Porting Schedule last updated June 10th  > at...  >  > L http://www.hp.com/products1/evolution/alpha_retaintrust/download/openvms_mov e.pdf  > H > is still valid. It lists Secure Web Browser, DECwindows and DECwindowsD > Client for release on OpenVMS on Itanium for Q4'04 and Multi MediaG > Services H1'05. I also assume this means sound card support will also 3 >   be available on OpenVMS Itanium Server Systems?     L It may be prudent to download a copy of that .pdf as a hedge against the dayI when the same link leads to a .pdf of the same name with vastly different  promises in it.    ------------------------------  % Date: Sun, 26 Sep 2004 20:10:29 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 5 Subject: Re: HP admits discontinued IA64 workstations , Message-ID: <41575A74.627267EB@teksavvy.com>   Nigel Barker wrote: Q > Your ill-informed speculation couldn't be more wrong. Superdome sales are doing  > fine thank you.     I Are you including PaRisc based Superdomes which are still outselling IA64  based Superdomes ?   ------------------------------  % Date: Mon, 27 Sep 2004 01:19:57 +0100 < From: "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk>5 Subject: Re: HP admits discontinued IA64 workstations 6 Message-ID: <41575cae$0$32130$db0fefd9@news.zen.co.uk>  > "Keith Cayemberg" <keith.cayemberg@arcor.de> wrote in message < news:4155fbd2$0$26110$9b4e6d93@newsread4.arcor-online.net...J > Also, considering that OpenVMS was never planned to be validated on the I > Itanium Workstation Models, I suppose the OpenVMS Alpha to OpenVMS I64  ? > Layered Product Porting Schedule last updated June 10th at...  > S > http://www.hp.com/products1/evolution/alpha_retaintrust/download/openvms_move.pdf  > I > is still valid. It lists Secure Web Browser, DECwindows and DECwindows  E > Client for release on OpenVMS on Itanium for Q4'04 and Multi Media  K > Services H1'05. I also assume this means sound card support will also be  . > available on OpenVMS Itanium Server Systems? > 	 > Cheers!  >  > Keith Cayemberg   R http://www.hp.com/products1/evolution/alpha_retaintrust/openvms/openvms_plans.html   Says...   M MultiMedia Services -  Audio not supported on Itanium servers, so MMS is not   needed.    Alex     ------------------------------    Date: 26 Sep 2004 18:31:38 -07001 From: susan_skonetski@hotmail.com (Sue Skonetski) 1 Subject: Re: HP gets 290 million defense contract = Message-ID: <857e9e41.0409261731.749aca68@posting.google.com>    Keith,  * It it was VMS I would have said something.   sue     W "John Smith" <a@nonymous.com> wrote in message news:<KfednbQnLZS_W9XcRVn-iw@igs.net>...  > JF Mezei wrote:  > >>O >  http://www.nyse.com/cgi-bin/ny_news?df=NY&r=S&sym=HPQ&sl=ON-09/15-17:19-1134 N > |ON-09/15-17:07-1119|ON-09/15-16:38-1100|BW-09/15-07:45-320|BW-09/15-07:45-3 >  19|&sp=4  > >  > > Sorry for wrap in URL. > > B > > Looks like a major "consolidation" contract for the US defense > > department.  > > E > > Of course, no mention of platform, which probably means that this D > > involves VMS. (Otherwise HP would have touted its HP-UX or other > > platforms).  > > F > > Does anyone have any further details on whether VMS is involved in > > this contract ?  > > E > > Sue, if VMS was involved in this contract, then this is a perfect B > > example of HP missing out on a free opportunity to market VMS. >  >  >  > Perhaps this:  > ( > http://www.dla.mil/j-6/bsm/msg_bsm.htmM > Replace our legacy materiel management systems (Standard Automated Materiel N > Management System (SAMMS) & Defense Integrated Subsistence Management System7 > (DISMS) with COTS (commercial off-the-shelf) systems.  >  > I > Of course HP's press release, (below) obviously means high availability  > Windows on 808x architecture.  > D > "The EDC program will consolidate large numbers of DLA servers andL > infrastructure into centralized facilities using the latest HP technology,L > thus allowing more efficient support to U.S. service members. The EDC willJ > reduce DLA's IT inventory resulting in a reduction of the agency's totalD > cost of ownership and will create a more modern IT infrastructure.D > The EDC also will allow for more effective implementation of DLA'sF > information assurance programs across the agency and will expand its; > disaster recovery and continuity of operations programs."    ------------------------------  + Date: Sun, 26 Sep 2004 22:29:48 +0000 (UTC) 6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)D Subject: Re: Let me own OpenVMS and I will destroy the linux market!1 Message-ID: <newscache$236o4i$md22$1@news.sil.at>   h In article <d7791aa1.0409230446.77f24008@posting.google.com>, bob@instantwhip.com (Bob Ceculski) writes:8 >It's said that all of the owners of vms fail to realize8 >what they have in their hands ... they have the very os3 >that can destroy the linux market when aggresively  >marketed and priced ...  7 But only after it is ported to the Opteron (and Power). L WINTEL is bought by a lot of people for which it is "good enough" and cheap.L LINUX is trendy and has a hype (80% ?) for just this reason (cheap and x86).H (And the rest of the LINUX hype is probably that LINUX is now the common2 denominator in the battle against the evil empire)  ; >                          but there is hope ... I recently 6 >talked to an old time dec person at HP who feels that* >HP will eventually sell it to someone ...  9 HP will sell it to someone becoming a strong competitor ? B Keep dreaming. If they sell it, then only after it is really dead.' In five more years without marketing...    --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Sun, 26 Sep 2004 04:03:11 +0800 , From: Paul Repacholi <prep@prep.synonet.com>: Subject: Re: Massbus configuration issues and restrictions0 Message-ID: <87sm96jev4.fsf@k9.prep.synonet.com>  . Bob Supnik <bob.supnik@sun.nospam.com> writes:  0 > This RP/RM Massbus stuff gets worse and worse.   Hey, it could be SCSI ;)  B > I was working on the assumption that RP's and RM's had differentF > offsets for SN (= 12 on RP and 8 on RM) and ER2/MR2 (=8 on RP and 12 > on RM) because  " > 1) VMS' drivers show it that wayF > 2) Published RP/RM documentation (including the maintenance manual!) > shows it that way H > So, the weight of the evidence is that, in fact, the RP SN = 8 and ER2G > = 12.  This means the RH11/RH70 had only a single PROM map, which was A > consistent for RP, RM, and TU; and that mixed strings worked on D > PDP-11's and PDP-10's; and that the technical manual is incorrect.  4 > Then what is going on with VMS???  Two hypotheses:  D > 1) RP06's were 'different' on VAXen.  Seems unlikely, unless VAXenD > had a different board set in the disk.  The decoder is not a PROM,. > interchanging 8 and 12 would be an etch cut.  B The RP06 DCLs are identicle, I have run drives on 11/70s and 7x0s.5 (x because I can't remember if it was a 780 or a 750)   F > 2) VMS doesn't care.  Even though SN and ER2 are defined, the driverE > (niether the mainline driver nor the boot driver) doesn't use them. D > If they are inverted, VMS would not notice.  If VMS adhered to theA > published documentation, it would have the 'wrong' definitions.   H > But VAX diagnostics <would> care.  Anyone have VAX diagnostics for theG > RP04/05/06?  Or a real VAX with real RP06's still running, from which  > I could get a register dump?  G > The 'rule' of primary sources says that the schematics are right, and G > that deviates from the schematics -- including the maintenance manual H > and the VMS driver -- is wrong.  I'd sure like someone to come up with@ > an alternate explanation that encompasses all the known facts.  8 The lay out is <couple of MBA registers> <DCL registers>> <more MBA registers> The register count jumper sets the offset= to the 3rd set, and the DCL registers live in the hole. There 9 are also some mixed registers that have bits from both...   < To run a mixed bus, you had to jumper the RHs to the largest> register count so some types you had <MBA> <DCL> <hole> <MBA2>, with the MBA2 set always at the same offset.  9 (I think.  I am NOT going to even thnk about how long ago  I last looked at this stuff!)   8 Ah, the RH7x0s did not have BA2 et all, so MBA2 would be8 empty I suspect... Oh, and there is implicit decoding of* some bits of the function codes as well...   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Sun, 26 Sep 2004 16:08:56 -0400 , From: Bob Supnik <bob.supnik@sun.nospam.com>: Subject: Re: Massbus configuration issues and restrictions8 Message-ID: <m58el012vcj7974ds17am9ebios885uiqu@4ax.com>  % I think I've got the 'smoking gun'...   E The VAX/VMS ERF (error log formating) facility has an independent set / of declarations for the RP drives, and it shows    8 = SN 12 = ER2  E Conclusion: the VAX/VMS driver declarations are wrong (but the driver A doesn't use them); the RP controller maintenance manual is wrong; F handbooks derived from the maintenance manual (like the 81 Peripherals Handbook) are wrong.  E The weight of personal recollections led me to go the schematics; and 4 that's conclusive.  Thanks, everyone, for your help.   /Bob Supnik   . On Thu, 23 Sep 2004 22:57:08 -0400, Bob Supnik" <bob.supnik@sun.nospam.com> wrote:  / >This RP/RM Massbus stuff gets worse and worse.  > A >I was working on the assumption that RP's and RM's had different E >offsets for SN (= 12 on RP and 8 on RM) and ER2/MR2 (=8 on RP and 12  >on RM) because  > ! >1) VMS' drivers show it that way E >2) Published RP/RM documentation (including the maintenance manual!)  >shows it that way >  >But, digging deeper > @ >1) TOPS-10 and TOPS-20 drivers show the RP SN = 8 and ER2 = 12,F >2) PDP-11's clearly supported mixed strings, which would only work if >RP SN = 8 and ER2 = 12, andC >3) RH11/RH70 documentation shows only one register map, which only   >works if RP SN = 8 and ER2 = 12@ >4) Ultrix relies on SN being at 8 regardless of the drive type. >  >And the capper  > ; >5) The RP04/05/06 <schematics> show RP SN = 8 and ER2 = 12  > ; >The RP04/05/06 does the register decodes with a 74154 4:16 @ >demultiplexor.  The selects are laid out in numeric order, with >  >8 = SN and 
 >12 = ER2. > G >So, the weight of the evidence is that, in fact, the RP SN = 8 and ER2 F >= 12.  This means the RH11/RH70 had only a single PROM map, which was@ >consistent for RP, RM, and TU; and that mixed strings worked onC >PDP-11's and PDP-10's; and that the technical manual is incorrect.  > 3 >Then what is going on with VMS???  Two hypotheses:  > G >1) RP06's were 'different' on VAXen.  Seems unlikely, unless VAXen had ? >a different board set in the disk.  The decoder is not a PROM, - >interchanging 8 and 12 would be an etch cut. E >2) VMS doesn't care.  Even though SN and ER2 are defined, the driver D >(niether the mainline driver nor the boot driver) doesn't use them.C >If they are inverted, VMS would not notice.  If VMS adhered to the @ >published documentation, it would have the 'wrong' definitions. > G >But VAX diagnostics <would> care.  Anyone have VAX diagnostics for the F >RP04/05/06?  Or a real VAX with real RP06's still running, from which >I could get a register dump?  > F >The 'rule' of primary sources says that the schematics are right, andF >that deviates from the schematics -- including the maintenance manualG >and the VMS driver -- is wrong.  I'd sure like someone to come up with ? >an alternate explanation that encompasses all the known facts.  >  >/Bob Supnik > / >On Mon, 20 Sep 2004 21:55:10 -0400, Bob Supnik # ><bob.supnik@sun.nospam.com> wrote:  > F >>In preparing to simulate the VAX 11/780 (in hopes of bringing up VMSH >>V1), I dug more deeply into the workings of the Massbus.  I discoveredE >>a rather odd problem: the RP and RM series of drives are not really G >>compatible. The issue is that internal registers 8 and 12 are not the  >>same >>
 >>reg		RP		RM  >> >>8		ER2		SN
 >>12		SN		MR2  >>D >>In the VAX, the Massbus adapter doesn't hide the internal registerG >>numbering of the disk controllers, and this discrepancy is visible to H >>software.  As a result, VMS can handle 'mixed' RP and RM drives on the >>same Massbus adapter.  >>H >>But on the -11 (and on the KS10), SN is always 176730, for both RP andF >>RM drives.  This implies that 176730 is being mapped differently, inG >>the RH11/RH70, for the different drive types.  Also, on the RH70, BAE F >>and CS3 appear at different locations for the TU than for the RP/RM. >>E >>This is all explained by the fact that the RH adapter had a mapping A >>PROM that mapped Unibus addresses to internal/external register E >>numbers.  The PROM was clearly different for an RP, an RM, or a TU. D >>So what happened when RP's and RM's were mixed on the same MassbusF >>adapter???  (Disks and tapes were never mixed.)  If the RH had an RPG >>map, addresses 30 and 40 would return the wrong values for RM drives; 7 >>in an RM map, 30 and 40 would be wrong for RP drives.  >>F >>TOPS-10 has a single driver for "RH" drives.  It reads SN and storesE >>it in the UDB; that's never referenced by the driver again.  ER2 is C >>only zeroed and never read.  MR2 is never referenced.  So TOPS-10   >>should run with mixed strings. >>F >>RSTS/E and RSX have separate drivers for DB (RP) and DR (RM) drives.F >>RSTS/E will catalog a Massbus and assign the units to DB and DR.  InG >>RSTS/E, the DB (RP) driver never reads the SN (it's not even defined)nH >>or MR2, and it bypasses the read of RPER2 if the drive is an RM, so it >>too looks to be ok.P >>G >>RSX also doesn't define the SN.  But the DB driver will look at RPER2rF >>in attempting to do an ECC correction.  Under an RM map, it will getG >>the wrong register from the drive for ER2. The DR (RM) driver doesn'tm3 >>look at either SN or MR2 and thus can't go wrong.c >> >>So here are my questions:P >>F >>1) Is my understanding of the RH11/RH70 correct, that is, were there1 >>different address mappings for RP vs RM drives?oC >>2) Were mixed strings (RP's + RM's on the same Massbus) supportedn >>under TOPS-10/TOPS-20?C >>3) Were mixed strings (RP's + RM's on the same Massbus) supportedI >>under RSTS/E? under RSX? >>
 >>/Bob Supniko   ------------------------------  % Date: Sun, 26 Sep 2004 03:29:41 +0800r, From: Paul Repacholi <prep@prep.synonet.com>% Subject: Re: Off-the-wall CI Questiond0 Message-ID: <876562kuze.fsf@k9.prep.synonet.com>  4 David J Dachtera <djesys.nospam@comcast.net> writes:  ? >> Look for a cheap star coupler.  It supplies the right signaldF >> attenuation and isolation and, as VB reminded me, is needed to make( >> the CIPCA pass the loopback selftest.  C Several CI interfaces must see their xmissions come back on the Rec- port or they get stroppy.-  D > AH! So, I gather (in passive mode) that the Star Coupler is biggerD > part of the design than simply a "star coupler": it has electrical( > properties that are expected, as well.  ? As above, plus it drops the signal level, though there is/was a ( resitive pad that FS could use for that.  < BTW, old base5 cable is a great cost saver :) Just different* colour and N rather than TNCs on the ends.   -- p< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Sun, 26 Sep 2004 03:48:43 +0800-, From: Paul Repacholi <prep@prep.synonet.com>& Subject: Re: OT: Sun's fighting chance0 Message-ID: <87wtyijfj8.fsf@k9.prep.synonet.com>  % "Tom Linden" <tom@kednos.com> writes:e  E > Sounds reminiscent of Gnosis and KeyKOS Factories.  Does it address$* > the "Mutually Suspicious Users" problem?  ? Nessisary, but not suficient. You need at least confinement andm; containment for MSU to be practicable. You should also havee: strong typing as a hardware primitive as well for it to be fully effective.  8 See Wulf et al in the Hydra book for the gritty details.   -- -< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.:@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  + Date: Sun, 26 Sep 2004 22:41:57 +0000 (UTC),6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)F Subject: Re: Slashdot is reporting HP is dropping Itanium workstations1 Message-ID: <newscache$9n6o4i$mf22$1@news.sil.at>a  h In article <d7791aa1.0409251211.4f7a83e8@posting.google.com>, bob@instantwhip.com (Bob Ceculski) writes:@ >seems like DS10L's are selling pretty good to hobbyists now ...  J Over a year ago, I saw a lot of them for $300 on EBAY (lease end after theG dot com bubble burst). After that they went up to $1000 afterwards, and ' now they coming back to the $500 range.    -- h Peter "EPLAN" LANGSTOEGERn% Network and OpenVMS system specialistn E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Sun, 26 Sep 2004 03:14:12 +0800_, From: Paul Repacholi <prep@prep.synonet.com>> Subject: Re: Windoze not rebooted monthly shuts down airports!0 Message-ID: <87ekkqkvp7.fsf@k9.prep.synonet.com>  % "John Smith" <a@nonymous.com> writes:   E > Without doing the math, it seems to me that there are perhaps 5,000aE > thousand flights flights under civilian ATC control at any point inn< > time. How often are the datum representing the transponder? > transmissions updated per aircraft and any 'skin paint' radar E > updates? Are we talking multiple times per second or once every few  > seconds for an ATC?d  C Depends on the head. A long range radar may be as low as once every C few seconds, Precision Approach Radar and some military units up tolF 100Hz. The majority and Secondaries that trigger transponders and willF have the transponder data, A, B, C or soon, S class as well as bearingC and range. Some primaries also give doppler range velocity , but nou
 xponder bits.   B Eurocontrol and ASA both use Alphas btw, for a while at least. Bet5 they love having both hw and the OS, T64, killed off.T   -- e< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Sun, 26 Sep 2004 03:20:20 +0800t, From: Paul Repacholi <prep@prep.synonet.com>> Subject: Re: Windoze not rebooted monthly shuts down airports!0 Message-ID: <87acvekvez.fsf@k9.prep.synonet.com>  . lewis@PROBE.MITRE.ORG (Keith A. Lewis) writes:  @ > In that case, the computer and the controller made conflictingF > decisions about which way each aircraft should go.  The German pilot? > followed the German rule about that situation -- "Go with thecF > computer".  The Russian pilot followed the Russian rule which is "Do > what the human says."   D The rule is the same all over, follow TCAS in all cases. Problem is,? the old habits die hard, and the Russian crew had not been wellnA trained, plus they where not in a normal situtaion due to a chech  pilot on board.-  @ > So both planes ended up heading for the same point, with fatal
 > results.  B > There were other problems that led to the situation in the firstB > place -- the ATC facility was under-staffed and a phone line wasD > down.  But it was the difference in pilot rules that prevented the > last-ditch avoidance.r  C Also, the Russians where expecting to descend to a different level,p standrds not yet harmonised.  @ The really sobering thing is that BOTH crews had the other plane: in sight but that did not allow a collision to be avoided.   -- v< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.t@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  + Date: Sun, 26 Sep 2004 22:33:25 +0000 (UTC)s6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)> Subject: Re: Windoze not rebooted monthly shuts down airports!1 Message-ID: <newscache$396o4i$lf22$1@news.sil.at>0  ] In article <cj1vup$in3$1@newslocal.mitre.org>, lewis@PROBE.MITRE.ORG (Keith A. Lewis) writes: M >I'm talking about this scenario -- 1 node of a multi-node cluster is locatedmI >at your site.  Cluster communications go down.  How do you make it work?E >aK >The only way I know of is to reboot the node with EXPECTED_VOTES set to 1.i  M You should refreshen your VMS skills and look into VMS FAQ and AMDS/AVAILMAN. % (Not related to airtraffic of course)i   --   Peter "EPLAN" LANGSTOEGERa% Network and OpenVMS system specialiste E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------    Date: 26 Sep 2004 20:59:42 -0700. From: spamsink2001@yahoo.com (Alan E. Feldman)E Subject: Re: [DCL REQUEST] New ignore keyword for DIFFERENCES command9< Message-ID: <b096a4ee.0409261959.2f58188@posting.google.com>  a Andrew Robert <arobert@townisp.com> wrote in message news:<10laqc1mhlsts63@corp.supernews.com>...C > Dave Weatherall wrote:J > > On Thu, 23 Sep 2004 20:14:40 UTC, hammond@not@peek.ssr.hp.com (Charlie > > Hammond) wrote:- > >  > >  > >>SOMEbody wrote:u > >> > >>J > >>>>Alan's original post suggested the problem lies with lines that are N > >>>>comments.  As I understand it he said that DIFFERENCES with the various O > >>>>flags to ignore comments treated a line "$! This is a comment" as if the rN > >>>>line actually said "$" and could get itself confused and start matching N > >>>>these lines with similarly treated comments at a different point in the  > >>>>other file.n   Exactly.   > >>$ > >>Ah, yes.  Been there. Done that. > >>J > >>The workaround for this is to use /MATCH=x, where x is large enough to$ > >>prevent this sort of miss-match. > >>O > >>The drawback to this is that you may reduce the numer if different sections > > >>and get sections with a lot of non-different lines listed. > >>M > >>But I also agree with another comment: Comments are important.  Sometimes-I > >>the are as important or even more inportant than the code.  Why wouldb: > >>you NOT want to examine the differences in comments??? > > J > > Sometimes you do but it is nice to be able to choose to check only theI > > executable bits. Which is why DIFF has those wonderful qualifiers of o > > course.a > > J > > The other use for a field exclusion specifier would have been to diff C > > line-numbered files. I haven't seen one for quite a while tho' M; > > although DIFFing .DIF (or ,DMP ?)  files comes close...  > > I > It may be even better to design a script in Perl to do the extractions.u > C > I've found that its abilities far exceed VMS due to the power of   > expressions. > E > Stripping items outs, compressing white space, etc are childs play.c  F Actually, it's not that hard in DCL. I recently revised my program and the key is this code excerpt:i   $_AGAIN:" $        READ/END=_DONE INPUT LINE $!E $!!      *** Change line to "!" if first two non-space chars are "$!", ***e $!, $        TEST_LINE = F$EDIT(LINE,"COLLAPSE")? $        IF (F$EXTRACT(0,2,TEST_LINE).EQS."$!") THEN LINE = "!"a $        WRITE OUTPUT LINE $        GOTO _AGAIN $_DONE:i   ------------------------------  % Date: Sun, 26 Sep 2004 22:15:27 -0500s2 From: David J Dachtera <djesys.nospam@comcast.net>< Subject: Re: [FTP] Is REGET now available somewhere on VMS ?+ Message-ID: <415785CF.996916F7@comcast.net>     Peter 'EPLAN' LANGSTOEGER wrote: > H > Now more than 2 years after my last deeper look I just wanted to know: > H > After many/some/one/no new versions of TCPIP/HGFTP/Multinet/TCPware isH > there now a REGET anywhere implemented in any of the FTP server and/or > clients on VMS ? > I > I would prefer HGFTP (cause of multistack and features) unfortunately ImH > can't request it easily for free (Let's again all thank Hunter for theF > efforts so far). But many of us pay for the IP stacks big bucks. So,F > have any of these bucks found their way into engineering for REGET ?  @ Actually, now that you mention it, I'm wondering if client REGETF couldn't attempt certain brash assumptions. For example, if the sourceH machine's o.s. can be determined with any reliability by whatever magic,D read the existing file fragment forward and count how many bytes theF result should represent on the source machine, then request REGET from that point forward.o  G Easy for Fixed-512 (most binaries), a bit more "work" for most forms ofr- sequential variable. not sure about STRU VMS.    --   David J Dachtera dba DJE Systemse http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page:e" http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/a   ------------------------------   End of INFO-VAX 2004.536 ************************ver 3 years now, so paying attention doesn'tF seem to be a significant strength of yours, but it's never too late to start).    - bill   ------------------------------  % Date: Sun, 26 Sep 2004 15:56:09 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 5 Subject: Re: HP admits discontinued IA64 workstations + Message-ID: <41571ED7.17644F0@teksavvy.com>    Nigel Barker wrote: O > Something like 20% of Superdomes are sold to run Windows. VMS & HP-UX are not  > the only players 83,31,156,101,203,1366 >>> 200 Port 203.136 at Host 83.31.156.101 accepted. <<< RETR texas_io.objc` >>> 150 IMAGE retrieve of /disk$misc/decus/vax87a/telex/hex/texas_io.obj (7760 bytes) started.: >>> 226 Transfer completed.  7556 (8) bytes transferred.  <<< PORT 83,31,156,101,203,1386 >>> 200 Port 203.138 at Host 83.31.156.101 accepted. <<< RETR texas_io.pasia >>> 150 IMAGE retrieve of /disk$misc/decus/vax87a/telex/hex/texas_io.pas (13310 bytes) started. ; >>> 226 Transfer completed.  11723 (8) bytes transferred.>  <<< PORT 83,31,156,101,203,1406 >>> 200 Port 203.140 at Host 83.31.156.101 accepted. <<< RETR transfer.objc` >>> 150 IMAGE retrieve of /disk$misc/decus/vax87a/telex/hex/transfer.obj (1090 bytes) started.9 >>> 226 Transfer completed.  939 (8) bytes transferred.>  <<< PORT 83,31,156,101,203,1416 >>> 200 Port 203.141 at Host 83.31.156.101 accepted. <<< RETR transfer.pasc` >>> 150 IMAGE retrieve of /disk$misc/decus/vax87a/telex/hex/transfer.pas (1926 bytes) started.: >>> 226 Transfer completed.  1095 (8) bytes transferred.  <<< PORT 83,31,156,101,203,1436 >>> 200 Port 203.143 at Host 83.31.156.101 accepted. <<< RETR use.obj[ >>> 150 IMAGE retrieve of /disk$misc/decus/vax87a/telex/hex/use.obj (1978 bytes) started.l: >>> 226 Transfer completed.  1074 (8) bytes transferred.  <<< PORT 83,31,156,101,203,1446 >>> 200 Port 203.144 at Host 83.31.156.101 accepted. <<< RETR use.pas[ >>> 150 IMAGE retrieve of /disk$misc/decus/vax87a/telex/hex/use.pas (2974 bytes) started.n: >>> 226 Transfer completed.  2048 (8) bytes transferred.  <<< PORT 83,31,156,101,203,1466 >>> 200 Port 203.146 at Host 83.31.156.101 accepted. <<< RETR write.obj] >>> 150 IMAGE retrieve of /disk$misc/decus/vax87a/telex/hex/write.obj (3972 bytes) started.r: >>> 226 Transfer completed.  3169 (8) bytes transferred.  <<< PORT 83,31,156,101,203,1486 >>> 200 Port 203.148 at Host 83.31.156.101 accepted. <<< RETR write.pas] >>> 150 IMAGE retrieve of /disk$misc/decus/vax87a/telex/hex/write.pas (3438 bytes) started.m: >>> 226 Transfer completed.  2601 (8) bytes transferred.  <<< PORT 83,31,156,101,203,1506 >>> 200 Port 203.150 at Host 83.31.156.101 accepted. <<< RETR xor.objZ >>> 150 IMAGE retrieve of /disk$misc/decus/vax87a/telex/hex/xor.obj (588 bytes) started.9 >>> 226 Transfer completed.  417 (8) bytes transferred.1  <<< PORT 83,31,156,101,203,1516 >>> 200 Port 203.151 at Host 83.31.156.101 accepted. <<< RETR xor.pas[ >>> 150 IMAGE retrieve of /disk$misc/decus/vax87a/telex/hex/xor.pas (1190 bytes) started.r9 >>> 226 Transfer completed.  819 (8) bytes transferred.8% <<< CWD /disk$misc/decus/vax87a/tso33 >>> 250 Connected to /disk$misc/decus/vax87a/tso.o  <<< PORT 83,31,156,101,203,1536 >>> 200 Port 203.153 at Host 83.31.156.101 accepted.
 <<< LIST >>> 150 List started.4 >>> 226 Transfer completed.<  <<< PORT 83,31,156,101,203,1546 >>> 200 Port 203.154 at Host 83.31.156.101 accepted. <<< RETR aaareadme.txt[ >>> 150 IMAGE retrieve of /disk$misc/decus/vax87a/tso/aaareadme.txt (2516 bytes) started. : >>> 226 Transfer completed.  1534 (8) bytes transferred.- <<< CWD /disk$misc/decus/vax87a/tso/disktste; >>> 250 Connected to /disk$misc/decus/vax87a/tso/disktst.2  <<< PORT 83,31,156,101,203,1566 >>> 200 Port 203.156 at Host 83.31.156.101 accepted.
 <<< LIST >>> 150 List started.t >>> 226 Transfer completed.2  <<< PORT 83,31,156,101,203,1586 >>> 200 Port 203.158 at Host 83.31.156.101 accepted. <<< RETR aaareadme