1 INFO-VAX	Thu, 14 Sep 2006	Volume 2006 : Issue 504       Contents: Re: Accounting Questions Re: Accounting Questions# Re: All is not well at the HP board 3 Re: Bugcheck 3C4 Alpha 7.2-2 $audit_event User Mode   Re: Digital TCP/IP Services V4.2  Re: Digital TCP/IP Services V4.2" Re: FOCUS application, written in?" Re: FOCUS application, written in?" Re: FOCUS application, written in? Re: help desk procedure  Re: help desk procedure  Re: help desk procedure  Re: help desk procedure  Re: help desk procedure & RE: HP announces new Integrity servers& Re: HP announces new Integrity servers& Re: HP announces new Integrity servers& Re: HP announces new Integrity servers& Re: HP announces new Integrity servers& Re: HP announces new Integrity servers& Re: HP announces new Integrity servers& Re: HP announces new Integrity servers& Re: HP announces new Integrity servers& RE: HP announces new Integrity servers& RE: HP announces new Integrity servers& Re: HP announces new Integrity servers& RE: HP announces new Integrity servers& Re: HP announces new Integrity servers& Re: HP announces new Integrity servers( Re: HP supported DVD writer for V/A 8.3?( Re: HP supported DVD writer for V/A 8.3?0 Re: Inquirer on VMS support outsourcing to India0 Re: Inquirer on VMS support outsourcing to India0 Re: Inquirer on VMS support outsourcing to India0 Re: Inquirer on VMS support outsourcing to India0 Re: Inquirer on VMS support outsourcing to India0 Re: Inquirer on VMS support outsourcing to India0 Re: Inquirer on VMS support outsourcing to India0 Re: Inquirer on VMS support outsourcing to India0 Re: Inquirer on VMS support outsourcing to India0 Re: Inquirer on VMS support outsourcing to India+ Re: Limiting bytlm within a spawned process 8 MOUNT quietly ignores JTQUOTA exhausted (OpenVMS V7.3-2)P Mozilla Thunderbird with VMS (was:Re: VMS MAIL:  Will it ever join the 21st cent Re: MP Synchronization ISSUES  Re: MP Synchronization ISSUES  Re: mtools, specifically mcopy Re: mtools, specifically mcopy Re: Need to read a TK50 tape Re: Need to read a TK50 tape Re: Need to read a TK50 tape Re: SYS$LANGUAGE Re: SYS$LANGUAGE' Re: VMS support goes to India next week ' Re: VMS support goes to India next week ' Re: VMS support goes to India next week ' Re: VMS support goes to India next week ' Re: VMS support goes to India next week ' Re: VMS support goes to India next week ' Re: VMS support goes to India next week ' Re: VMS support goes to India next week ' Re: VMS support goes to India next week ' Re: VMS support goes to India next week ' Re: VMS support goes to India next week ' Re: VMS support goes to India next week ' Re: VMS support goes to India next week ' Re: VMS support goes to India next week ' Re: VMS support goes to India next week   F ----------------------------------------------------------------------  # Date: Wed, 13 Sep 2006 17:57:40 GMT ' From: Steve Thompson <smt@vgersoft.com> ! Subject: Re: Accounting Questions C Message-ID: <Pine.LNX.4.58.0609131356290.23227@honker.vgersoft.com>   ( On Wed, 13 Sep 2006, Ferry Bolhar wrote:  M > So the question is: is there a way either to reduce the "collection period" M > or tell the job controller to write out all accounting records immediately?   H You could always define the ACCOUNTNG mailbox and then manage the actualH accounting file yourself. This way you can avoid the delay while waiting( for the job controller to flush buffers.   Steve    ------------------------------  % Date: Wed, 13 Sep 2006 14:32:07 -0400 , From: Hoff Hoffman <hoff-remove-this@hp.com>! Subject: Re: Accounting Questions * Message-ID: <45084eb3@usenet01.boi.hp.com>   Ferry Bolhar wrote:   M > So the question is: is there a way either to reduce the "collection period" M > or tell the job controller to write out all accounting records immediately?       Not that I am aware of.  M    Easiest "fix" is to use a synchronous "print"; a copy to a spooled device.   P    More involved would be a customized symbiont, and with an immediate response M (of some application-defined fashion and/or mechanism) back to the web-based   caller as the job arrives.  Q    The start or the completion of print jobs can be delayed hours or weeks, too,  F but I'm sure you know that.  (Some printers contain web servers, what M information might be available via that channel can and does obviously vary.   Widely.)  O    The other approach is to punt on the synchronous approach, and to provide a  O second web page with a display of the printer-related records for a particular  I caller, and with the final dispensation information available over there.    ------------------------------  % Date: Wed, 13 Sep 2006 21:05:40 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> , Subject: Re: All is not well at the HP board, Message-ID: <4508AACE.94D52711@teksavvy.com>   Story still developping:   ##E In a videotaped message to employees, Chairman Patricia Dunn said the G same techniques that were used to obtain details about HP directors and - journalists were also used on two employees.    E "These techniques were practiced on a number of individuals including H certain directors, two employees and a number of individuals outside theE company, including journalists," Dunn said in a message on Tuesday, a E transcript of which was provided by the company. An HP representative ? confirmed that two current employees had their personal records H targeted, but would not identify the employees or say which records were
 accessed.  ##      F So perhaps we need to chip in and give Sue a prepaid phone that is notF tied to her identiy AT ALL. This way, she could still communicate withF friends (and VMS enthousiasts) without fears of her employer spying on her conversations.   ------------------------------  % Date: Wed, 13 Sep 2006 09:28:20 -0400 , From: Hoff Hoffman <hoff-remove-this@hp.com>< Subject: Re: Bugcheck 3C4 Alpha 7.2-2 $audit_event User Mode* Message-ID: <4508076e@usenet01.boi.hp.com>   Richard Maher wrote:   > Update is: - > A > Good news:- 8.3 Alpha is immune and returns illegal code thingy  > M > Bad/good news: - 7.2-2 still booms :-( Are you still interested? (My serial K > port is at my VAX at the moment so I might even be getting some form of a  > dump. Is it worth persuing?   I    Respectfully, the bad news here is that there is (still) no crashdump  O available.  That the OpenVMS Alpha V7.2-2 system still crashes is not what I'd  M like to have happen, but the reliable nature of the crash in this particular    environment can be quite useful.      The crashdump is necessary.  L    The COBOL replicator is the easy part, and John R., myself and two other P engineers are looking at this right now, and reviewing code.  We have the COBOL < code working, and versions of it in several other languages.  K    What we are unable to determine what random junk is on the stack in the  O context of your environment, since -- as I'm sure you're aware -- it's not the  Q missing terminator that's the issue here, it's the cruft that's out on the stack   that's critical.  K    What's missing from the testing is the specific data pattern after your  L itemlist -- we're quite reliably seeing the expected itemlist errors in our N tests.  What's missing is the information from the particular failing process Q context; run-time data and run-time context that is expected to be stored within  O the crashdump as the process will be the current process when the crash occurs.    ------------------------------  % Date: Wed, 13 Sep 2006 14:18:51 -0400 ' From: Dave Froble <davef@tsoft-inc.com> ) Subject: Re: Digital TCP/IP Services V4.2 9 Message-ID: <B_GdndyTXMQr1JXYnZ2dnUVZ_tOdnZ2d@libcom.com>    retchason wrote:H > I am trying to write a read/write server on OpenVMS V7.1 using Digital5 > TCP/IP services V4.2.  I have modified the examples D > UCX_TCP_SERVER_QIO_FOR2.FOR and TCPIP$TCP_SERVER_SOCK.C located inF > ucx$examples.  Howerver, these examples only accept a connection andD > send a message to the client.  They do not read and write.  I haveG > modified both the above mentioned examples to be read and write using A > both QIO's and socket api routines and I have the same problem.  >  > The problem is: B > 1.) I post a read on the socket and when the client sends data I > retrieve it just fiine. C > 2.) I act on the data and send a response to the data back to the 	 > client. H > 3.) I then repost a read on the socket and it returns immediately with' > the same data from the previous read. E > 4.) The program acts on the data and sends data back to the client. I > 5.) The read is then reposted to the socket and it waits for the client  > to send more data.B > 6.) The client sends data and the program receives the data just > fine(new data not old).  > 7.) The problem now repeats. > I > I have verified that the client is not sending data multiple times.  If F > I remove the write from the server and just read and then repost the# > read the program works just fine.  > H > Does anyone have any ideas what is going on here.  Does anyone have anF > example of a read/write server writen in Fortran or C using qio's or > socket api's?? > G > I have written client appliations on this machine that read and write ) > and I do not experience this problem!!!  >  > Thanks > :eek:  >  >   + I've only worked with TCP/IP V5 and higher.   I Are you issuing multiple socket reads until you have the entire message?  G   This is a byte stream type of communication and a single read is not  < guaranteed to read the entire message, regardless of length.  B I've got some stuff in BASIC.  I could send you some of the early H testing code.  Got a program that acts like an 'echo server', which may . be helpful.  Let me know if you're interested.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Wed, 13 Sep 2006 16:48:07 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ) Subject: Re: Digital TCP/IP Services V4.2 , Message-ID: <45086E80.BE91F2D6@teksavvy.com>   retchason wrote:H > 3.) I then repost a read on the socket and it returns immediately with' > the same data from the previous read.   D Are you sure your first read is done entirely properly ? They may beF some hidden option to read the contents of the buffer without emptyingE it, causing any subsequent reads to return the same data (eg: peek at  the buffer).  H Do you have the  programming documentation for that version of the TCPIPD stack ? For the 5.1/5.3, there is a whole manual on the programming @ with a big part on the $QIO interface and all the options in it.   ------------------------------  % Date: Wed, 13 Sep 2006 19:53:16 -0500 6 From: "Craig A. Berry" <craigberry@mac.com.spamfooler>+ Subject: Re: FOCUS application, written in? @ Message-ID: <craigberry-2A7659.19531613092006@free.teranews.com>  - In article <NfXNg.50$6k5.61@news.oracle.com>, B  lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman)   wrote:   E > Just who / what is the FOCUS application?  Perhaps more information D > on that, or just what it is that you're really trying to find out,$ > would elicit a more useful answer.  G It's a reporting tool from Information Builders.  It's gosh awful hard  ? to find anything about the OpenVMS version on their web site.   D Apparently it's been superseded by WebFOCUS, which is apparently in  Java.    --  = Posted via a free Usenet account from http://www.teranews.com    ------------------------------  % Date: Wed, 13 Sep 2006 18:04:58 -0700 * From: "Tom Linden" <tom@kednos-remove.com>+ Subject: Re: FOCUS application, written in? ) Message-ID: <op.tfufykj9tte90l@hyrrokkin>   4 On Wed, 13 Sep 2006 17:53:16 -0700, Craig A. Berry  & <craigberry@mac.com.spamfooler> wrote:  / > In article <NfXNg.50$6k5.61@news.oracle.com>, C >  lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman) 	 >  wrote:  > F >> Just who / what is the FOCUS application?  Perhaps more informationE >> on that, or just what it is that you're really trying to find out, % >> would elicit a more useful answer.  > H > It's a reporting tool from Information Builders.  It's gosh awful hard? > to find anything about the OpenVMS version on their web site. E > Apparently it's been superseded by WebFOCUS, which is apparently in  > Java.  > H It may have been written in PL/I.  I have a vague recollection of them  5 enquiring about our PL/I for Unix about 20 years ago.        --  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Wed, 13 Sep 2006 20:11:16 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>+ Subject: Re: FOCUS application, written in? + Message-ID: <4508AC34.5434670B@comcast.net>    "Bart Z. Lederman" wrote:  > a > In article <06091311293295@dscis6-0.dalsemi.com>, brandon@dalsemi.com (BRANDON, JOHN M) writes: U > >> Does anyone know what the FOCUS application is written in?  COBOL?  FORTRAN? ???  > > ; > >David J Dachtera suggest that I dump the application....  > > L > >And... I have not had a chance to investigate the others, some are system= > >lib's, etc... this is related to my MP Synch investigation  > >  > >FUSELIB_001 > >CMA$TIS_SHR_001       <-- C
 > >LIBRTL_001  > >DECC$SHR_001          <-- C$ > >DEC$FORRTL_001        <-- FORTRAN
 > >LBRSHR_001 
 > >SCRSHR_001  > >DPML$SHR_001 
 > >LIBOTS_001  > >PAS$RTL_001
 > >SMGSHR_001  > >SORTSHR_001 > >DISMNTSHR_001 > >MOUNTSHR_001  > >  > >  > >John "REBOOT" Brandon > >VMS Systems Administrator- > >firstname.lastname.spam.me.not@dalsemi.com  > >  > A > Also apparently referencing PAS$RTL, which might make one think & > there are modules written in Pascal. > E > Although these are nice hints, you can't always assume that because > > an image has references to FORRTL or COBRTL that it actuallyE > contains code that has gone through the FORTRAN or COBOL compilers. B > It's fairly common practice in the OpenVMS world to use routinesE > from whatever RTL contains something useful: which is most of them. B > I have programs that use a routine in the BASIC RTL that contain@ > no BASIC code, and I don't even have the compiler/interpretor.  B Bart is quite correct. I had some DIBOL code that called BASIC RTL0 routines to do things that DIBOL didn't provide.   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------    Date: 13 Sep 2006 10:42:36 -0700- From: "Doug Phillips" <dphill46@netscape.net>   Subject: Re: help desk procedureC Message-ID: <1158169356.539628.137330@p79g2000cwp.googlegroups.com>    contracer11@gmail.com wrote:4 > > On Wed, 13 Sep 2006 contracer11@gmail.com wrote: > > F > > > I made a DCL command procedure where when I put a string to find > > > 2 > > > it show me all string ocurrences, like this: > > > - > > > $ search/win=(8,8) help.txt "``string`"  > > > I > > > but how could I make a procedure to show me all "string" ocurrences  > > > = > > > separated by a "====================" line ? Like this:  > > >  > > > $ @find sarbanes > > >  > > > 8 > > > ================================================== > > > < > > > To see Sarbanes laws read dka2:[documents]sarbanes.txt > > > 8 > > > ================================================== > > > M > > > Sarbanes-Oxley provides a complete cross-referenced index of SEC filers H > > > audit firms, offices, CPAs, services, fees, compliance/enforcement7 > > > actionsand other critical disclosure information.  > > > 7 > > >==================================================  <snip> > C > running the procedure I find what I want and another informations  > that I don't want... > C > Is there any way to put a invisible sequence to control start and 
 > finish ? >  >   G Search alone won't work the way you suggest because the desired text is E not within a fixed number of lines. To do what you want using search, E instead of using one help.txt file you need to create different files G (documents) within a [help] directory. Using search, you could find the G names of the documents that contain the desired key words, then type or F display the selected documents formatting the output however you want.  A To use a single text file (or multiple larger files with multiple G subjects), you would need to build your own keyword index with pointers G to tags/markers within the text. It seems to me that this would be more C easily and efficiently done at a higher level rather than with just C DCL. It's likely that there is already software developed that does F this. I haven't looked. Maybe one of the freeware search engines could be adapted?   @ BTW, is this really for a "help desk" where someone is providingC support to "clients", or is it actually more just a reference tool?    ------------------------------    Date: 13 Sep 2006 14:09:19 -0700 From: contracer11@gmail.com   Subject: Re: help desk procedureC Message-ID: <1158181759.270193.221730@e63g2000cwd.googlegroups.com>    Doug Phillips wrote: > contracer11@gmail.com wrote:6 > > > On Wed, 13 Sep 2006 contracer11@gmail.com wrote: > > > H > > > > I made a DCL command procedure where when I put a string to find > > > > 4 > > > > it show me all string ocurrences, like this: > > > > 1 > > > > $ search/win=3D(8,8) help.txt "``string`"  > > > > K > > > > but how could I make a procedure to show me all "string" ocurrences  > > > > L > > > > separated by a "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D" line ? Like this: > > > >  > > > > $ @find sarbanes > > > >  > > > > K > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=	 =3D=3D=3D  > > > > > > > > > To see Sarbanes laws read dka2:[documents]sarbanes.txt > > > > K > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=	 =3D=3D=3D  > > > > L > > > > Sarbanes-Oxley provides a complete cross-referenced index of SEC fi= lersJ > > > > audit firms, offices, CPAs, services, fees, compliance/enforcement9 > > > > actionsand other critical disclosure information.  > > > > J > > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=	 =3D=3D=3D  > <snip> > > E > > running the procedure I find what I want and another informations  > > that I don't want... > > E > > Is there any way to put a invisible sequence to control start and  > > finish ? > >  > >  > I > Search alone won't work the way you suggest because the desired text is G > not within a fixed number of lines. To do what you want using search, G > instead of using one help.txt file you need to create different files I > (documents) within a [help] directory. Using search, you could find the I > names of the documents that contain the desired key words, then type or H > display the selected documents formatting the output however you want. > C > To use a single text file (or multiple larger files with multiple I > subjects), you would need to build your own keyword index with pointers I > to tags/markers within the text. It seems to me that this would be more E > easily and efficiently done at a higher level rather than with just E > DCL. It's likely that there is already software developed that does H > this. I haven't looked. Maybe one of the freeware search engines could
 > be adapted?  > B > BTW, is this really for a "help desk" where someone is providingE > support to "clients", or is it actually more just a reference tool?     A  It=B4s just a reference tool, and I =B4d like use DCL procedure.     thanks    ------------------------------    Date: 13 Sep 2006 18:34:25 -0500? From: burley.not-this@encompasserve-or-this.org (Graham Burley)   Subject: Re: help desk procedure3 Message-ID: <Bv1b8pRoB4$u@eisner.encompasserve.org>   _ In article <1158163524.224042.99970@e3g2000cwe.googlegroups.com>, contracer11@gmail.com writes:   . > it show me all string ocurrences, like this:) > $ search/win=(8,8) help.txt "``string`"  > E > but how could I make a procedure to show me all "string" ocurrences 9 > separated by a "====================" line ? Like this:   ( If you're allowed to load freeware then:  6 $ grab help.txt "''string'"/cut="===================="  1 GRAB is a freeware search utility available here:   9 http://vms.process.com/scripts/fileserv/fileserv.com?GRAB   , And also on the V8 OpenVMS Freeware V8.0 CD.   ------------------------------  % Date: Wed, 13 Sep 2006 19:45:22 -0400 ' From: Dave Froble <davef@tsoft-inc.com>   Subject: Re: help desk procedure9 Message-ID: <9redncB6UdGhC5XYnZ2dnUVZ_r-dnZ2d@libcom.com>    Doug Phillips wrote: > contracer11@gmail.com wrote:4 >>> On Wed, 13 Sep 2006 contracer11@gmail.com wrote: >>> E >>>> I made a DCL command procedure where when I put a string to find  >>>>1 >>>> it show me all string ocurrences, like this:  >>>>, >>>> $ search/win=(8,8) help.txt "``string`" >>>>H >>>> but how could I make a procedure to show me all "string" ocurrences >>>>< >>>> separated by a "====================" line ? Like this: >>>> >>>> $ @find sarbanes  >>>> >>>>7 >>>> ==================================================  >>>>; >>>> To see Sarbanes laws read dka2:[documents]sarbanes.txt  >>>>7 >>>> ==================================================  >>>>L >>>> Sarbanes-Oxley provides a complete cross-referenced index of SEC filersG >>>> audit firms, offices, CPAs, services, fees, compliance/enforcement 6 >>>> actionsand other critical disclosure information. >>>>7 >>>> ==================================================  > <snip>D >> running the procedure I find what I want and another informations >> that I don't want...  >>D >> Is there any way to put a invisible sequence to control start and >> finish ?  >> >> > I > Search alone won't work the way you suggest because the desired text is G > not within a fixed number of lines. To do what you want using search, G > instead of using one help.txt file you need to create different files I > (documents) within a [help] directory. Using search, you could find the I > names of the documents that contain the desired key words, then type or H > display the selected documents formatting the output however you want. > C > To use a single text file (or multiple larger files with multiple I > subjects), you would need to build your own keyword index with pointers I > to tags/markers within the text. It seems to me that this would be more E > easily and efficiently done at a higher level rather than with just E > DCL. It's likely that there is already software developed that does  > this. I haven't looked.   4 Yes, it's called HELP, and it's on every VMS system.  0 > Maybe one of the freeware search engines could
 > be adapted?  > B > BTW, is this really for a "help desk" where someone is providingE > support to "clients", or is it actually more just a reference tool?  >      --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Wed, 13 Sep 2006 14:23:04 -0400 , From: Hoff Hoffman <hoff-remove-this@hp.com>  Subject: Re: help desk procedure* Message-ID: <45084c84@usenet01.boi.hp.com>   contracer11@gmail.com wrote:D > I'm looking for a VMS command procedure where I can store data andF > where I can find this data using a search command (like a help desk 2 > database). Is there any procedure already made ?      Hello Shiva,   /    Please: Terse questions beget terse answers.   Q    Please back up about 500 to 1000 meters, and tell us what specific problem(s)  P you are trying to (re)solve here, what software you already have access to (eg: Q databases, OpenVMS version(s) and platform(s), whether this is to be a windowing  O system application or character cell or web-based servers, etc), what scale of  P storage is likely involved and what scale of information might be included, who < the intended clients might be, and what the budget might be.  K    On zero information and as a first and potentially wild guess, my first  , suggestions would be Bugzilla and/or a Wiki.  Q    Perl and PHP services and support tools -- stuff built on these languages and  O tools -- should arrive quite easily on OpenVMS, for instance, if there are not   already packages available.   N    At another interpretation of your (unfortunately terse) question, assuming Q it's just you maintaining that's looking to maintain information for yourself, a  O text file and the SEARCH command can be pressed into service -- I've certainly  Q used this solution for myself, as have many other folks.  The extreme and quaint  J and massively low-tech solution of a paper-based notebook also works.  :-)  Q    And with some details and some background, I and others might well be able to   tailor the answer.  
    Thanks,    Hoff    ------------------------------  % Date: Wed, 13 Sep 2006 14:02:44 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> / Subject: RE: HP announces new Integrity servers T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401A64C77@tayexc19.americas.cpqcorp.net>   > -----Original Message-----3 > From: Dave Froble [mailto:davef@tsoft-inc.com]=20 " > Sent: September 13, 2006 1:36 PM > To: Info-VAX@Mvb.Saic.Com 1 > Subject: Re: HP announces new Integrity servers  >=20  
 [snip ...]   >=207 > Not agreeing with your arguments, but I must observe:  >=20  A What parts do you not agree with? These are the items you need to 7 consider when moving from one platform to any platform.   @ > While your arguments are valid as far as a current VMS user=20 > staying with=20 B > VMS, they don't do much for attracting new VMS customers.  My=20 > reading of=20 > > the arguments leads me to feel, based upon the arguments,=20 > that anybody=20 3 > would be crazy to ever contemplate moving TO VMS.  >=20  E Bill was talking about HW x86-64 platform being the target because of H techie issues like the base server cost and performance. These arguments9 have nothing to do with getting new Customers on OpenVMS.   ? > Is this the view of VMS Ambassadors today, to hold onto as=20  > much of the=20B > cow as they can, and milk it for all it's worth?  If so, then=20 > VMS is in=20J > as much trouble as it's biggest opponents claim.  It's been said many=20H > times, in many ways, you cannot stand still, you either advance, or=20G > decline.  If your best argument for VMS is that it's too costly to=20 B > migrate to another platform, I for one cannot see VMS advancing. >=20  G David - you are introducing an entirely different discussion related to 7 marketing. That is better done in a separate thread.=20   F The arguments I presented more or less apply to any platform moving toH any platform i.e. it is not just the server HW cost and performance thatG Customers look at when they consider moving. Usually, these are smaller 3 considerations in the whole business justification.   G > Note, these comments are on your arguments, not on the merits of VMS.  >=20 > --=20 6 > David Froble                       Tel: 724-529-0450@ > Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com > DFE Ultralights, Inc.  > 170 Grimplin Road  > Vanderbilt, PA  15486  >=20  A OpenVMS is winning new Customers. Is it hundreds per week? No.=20   > However, they are in areas where Customers view high levels ofH stability, availablility, scalability (up and out) and security as being very important to them.   H Whether anyone here chooses to believe this or not is irrelevant, but it is reality.    Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Wed, 13 Sep 2006 14:20:26 -0400 ( From: Bill Todd <billtodd@metrocast.net>/ Subject: Re: HP announces new Integrity servers G Message-ID: <qNSdnRISHPV31pXYnZ2dnUVZ_tCdnZ2d@metrocastcablevision.com>    bob@instantwhip.com wrote: > Bill Todd wrote:K >> "We find ourselves living in a world of parity; at least as far as Unix, H >> OS/400, and VMS servers are concerned. What I mean by this is that asJ >> far as base technology goes, we have a level playing field. The WindowsI >> and Linux operating systems have made some progress, but still have to I >> make up some ground in terms of scalability, availability and workload @ >> management in order to compete head-to-head with the dominantJ >> Unixes--Solaris, AIX, and HP-UX--or IBM's OS/400-based iSeries platformK >> or Hewlett-Packard's OpenVMS platform, which may as well both be Unix in B >> terms of its uptime, resiliency, security, and sophistication." > < > oh yeah Bill ... they are all now on the same field as vms  D You really are a moron, boob:  the quote above was from the article I which *Kerry* referred people to for consideration, and used to indicate  B why the conclusions he apparently wished people to draw from that " article were not in fact drawable.   - bill   ------------------------------  % Date: Wed, 13 Sep 2006 14:18:29 -0400 ( From: Bill Todd <billtodd@metrocast.net>/ Subject: Re: HP announces new Integrity servers G Message-ID: <qNSdnRMSHPXr1pXYnZ2dnUVZ_tCdnZ2d@metrocastcablevision.com>    bob@instantwhip.com wrote: > Bill Todd wrote: >> FredK wrote: 4 >>> Cool.  How fast does VMS run on the Power5+ 4+M?J >> I'm not sure how that would be relevant to this sub-topic, unless HP isG >> actually touting price/performance metrics for VMS on Superdome (see H >> above context).  That would be great, since I can't remember the last; >> time VMS's owners bothered to benchmark anything on VMS.  >>J >> Of course, if VMS were to be ported to a platform as estimable as POWERI >> (if that's what you were obliquely referring to) that would be nice as K >> well (though I'd have to suggest that porting to x86-64 should likely be  >> a higher priority). >  > it is very relevant   - No, boob - you're just as clueless as always.   D The sub-topic was about the *price/performance figures* for the new B Integrity servers - so unless any of the quantitative performance L information was obtained in a VMS environment it had nothing to do with VMS.   - bill   ------------------------------  % Date: Wed, 13 Sep 2006 16:40:46 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> / Subject: Re: HP announces new Integrity servers , Message-ID: <45086CC7.29B24DD8@teksavvy.com>   "Main, Kerry" wrote:G > The BU's want IT to provide solutions that add value to the business.   F >Many BUs want IT to install the currently trendy platform/applicationE they've read about in te trade rags because they think it is the only B way to remain competitive. If your competitors have installed thatE platform, there is less risk if you also choose that platform. If you D choose a different platform, you not only have a harder time findingG qualified people, but you also have risk that it will be "incompatible" D and cause you more grief than any advantage it could have gotten you ober competitors.     K > Solution TCO = HW + OS + ISV licenses + App migration porting + App   etc   G Only a certain percentage of customers actually REALLY evaluate TCO. If ? TCO had been such an important metric, you'd have MACs on every 2 corporate desktop in the world instead of Windows.  H Many businesses just look at initial cost of acquisition because that isF what they musty budget for during the selection/acquisition phase. AndG often, there is no way to know the TCO of the selected platform because H they have no idea what percentage of the time their employees will spendG managing that platform, providing fixes and fighting viruses, and since D they don't know the number, they don't discuss it in their documehts2 that outline their decisions to choose platform X.      E Mr Main, perhaps you are biased because in your case, your wins would H have included a disproportionatly large percentage of customers who haveF seriously looked at TCO and decided VMS was a better solution based onI real lonng term costs. But that is a tiny proportion of the total market.    ------------------------------  % Date: Wed, 13 Sep 2006 16:59:23 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> / Subject: Re: HP announces new Integrity servers , Message-ID: <45087123.A231DECF@teksavvy.com>   "Main, Kerry" wrote:G > Bill was talking about HW x86-64 platform being the target because of J > techie issues like the base server cost and performance. These arguments; > have nothing to do with getting new Customers on OpenVMS.   E It has everything to do with getting new customers on VMS.  Customers H are not interested in moving to a dead (Alpha) or dying (IA64) platform,A especially when the vendor is unwilling to commit to a promise of 6 porting VMS to a new platform if/when IA64 is retired.  D The uncertainty around IA64 and the massive improvements on the 8086. that are coming make IA64 a liability to VMS.   H Alpha arrived at a time when VMS still had *some* steam going. That gaveG it a good subset of the VAX application portfolion and still managed to E get a few new apps during its decade. IA64 arrived at a time when VMS G had no steam left, and is getting but a small subset of what is left on A VMS in terms of software, and rumours of its impending retirement 4 started before VMS was commercially available on it.  @ > However, they are in areas where Customers view high levels ofJ > stability, availablility, scalability (up and out) and security as being > very important to them.   H And with the news of HP sabotaging the high quality suport organisation,E it is be every harder to convince customers to move to VMS because in F the end, it won't bring the high quality support that people had often associated with VMS.   ------------------------------  % Date: Wed, 13 Sep 2006 19:20:03 -0400 ( From: Bill Todd <billtodd@metrocast.net>/ Subject: Re: HP announces new Integrity servers G Message-ID: <Wf2dnQziG7i5D5XYnZ2dnUVZ_t6dnZ2d@metrocastcablevision.com>    Main, Kerry wrote: >> -----Original Message----- 3 >> From: Bill Todd [mailto:billtodd@metrocast.net]  # >> Sent: September 11, 2006 2:26 AM  >> To: Info-VAX@Mvb.Saic.Com2 >> Subject: Re: HP announces new Integrity servers >> >> Main, Kerry wrote:  >>>> -----Original Message----- 5 >>>> From: Bill Todd [mailto:billtodd@metrocast.net]  $ >>>> Sent: September 9, 2006 8:36 PM >>>> To: Info-VAX@Mvb.Saic.Com4 >>>> Subject: Re: HP announces new Integrity servers >>>> >>>> Main, Kerry wrote:  >>> [snip..] >>> 9 >>>>> Sigh .. How many times does it need to be repeated?  >>>>> F >>>>> Customers are looking for supported, stable and highly available' >>>>> solutions to run their business.   >>>>> @ >>>>> The ones making the business decisions are not burning up  >>>> their meetings ' >>>>> talking about techie chip stuff.  C >>>> Exactly:  they are looking at *standardizing* (for reasons of   >>>> cost and B >>>> support complexity that have nothing to do with 'techie chip  >>>> stuff') on C >>>> the *least expensive viable solution*.  And beyond any shadow   >>>> of a doubt D >>>> that's x86-64 in any situation where that solution *is* viable. >>>>  >>> Again, you are in the weeds.E >> Rather than blowing such smoke with zero supporting evidence, try  I >> refuting either statement above to which you purport to be responding:  >>: >> 1.  Refute the assertion that customers are seeking to  >> standardize (for 9 >> reasons of cost and support complexity) on *the least   >> expensive viable  >> solution*, and/or >>< >> 2.  Refute the assertion that the least expensive viable  >> solution will  < >> be x86-64 in any situation where that solution is viable. >>I >> Otherwise, shut up:  you're getting tedious and offering no redeeming  0 >> substance to make that worth putting up with. >> > ! > You are looking at the HW only.   H No, idiot:  I'm looking at *solution* costs - initial purchase, ease of = obtaining personnel familiar with the hardware and software,  G availability of applications, cost-reduction by consolidating around a  @ single platform type (which in many cases is possible *only* by D consolidating around x86, because x86 will *always* be required for " *some* portions of the operation).  C The word 'hardware' appears nowhere above, and the word 'solution'  H appears in each of the two assertions (both in their original forms and F in the subsequent paraphrasing of them).  So read them again, and try C again, or shut up.  I'm not going to state them a third time here,  B because both the original statement and the later paraphrase were F crystal clear, despite your incompetent attempt to (yet again) divert  the discussion elsewhere.   H The rest of your drivel I've addressed in one form or another elsewhere 1 in this thread, so I won't bother doing so again.    - bill   ------------------------------  % Date: Wed, 13 Sep 2006 20:11:22 -0400 ' From: Dave Froble <davef@tsoft-inc.com> / Subject: Re: HP announces new Integrity servers 9 Message-ID: <e_adnRsiGa3LAZXYnZ2dnUVZ_rqdnZ2d@libcom.com>    Main, Kerry wrote: >> -----Original Message----- 2 >> From: Dave Froble [mailto:davef@tsoft-inc.com] # >> Sent: September 13, 2006 1:36 PM  >> To: Info-VAX@Mvb.Saic.Com2 >> Subject: Re: HP announces new Integrity servers >> >  > [snip ...] > 8 >> Not agreeing with your arguments, but I must observe: >> > C > What parts do you not agree with? These are the items you need to 9 > consider when moving from one platform to any platform.   F Not totally disagreeing with them either.  One of the things that I'd I want to see, were I buying, is some assurance that what I'm investing in  F has a future.  If I was going to invest in a new environment I'd have F some real bad feelings about itanic.  Some of those feelings are from " things Intel has said, at the top.  ? >> While your arguments are valid as far as a current VMS user   >> staying with A >> VMS, they don't do much for attracting new VMS customers.  My   >> reading of = >> the arguments leads me to feel, based upon the arguments,   >> that anybody 4 >> would be crazy to ever contemplate moving TO VMS. >> > G > Bill was talking about HW x86-64 platform being the target because of J > techie issues like the base server cost and performance. These arguments; > have nothing to do with getting new Customers on OpenVMS.   D They sure do if you're looking at platforms and considering upgrade H paths in the future.  Ok, maybe I'm adding something to the discussion.    But I feel it's relevant.   > >> Is this the view of VMS Ambassadors today, to hold onto as  >> much of the  A >> cow as they can, and milk it for all it's worth?  If so, then  
 >> VMS is in  I >> as much trouble as it's biggest opponents claim.  It's been said many  G >> times, in many ways, you cannot stand still, you either advance, or  F >> decline.  If your best argument for VMS is that it's too costly to C >> migrate to another platform, I for one cannot see VMS advancing.  >> > I > David - you are introducing an entirely different discussion related to 7 > marketing. That is better done in a separate thread.    B If you're talking about growing the user base, and I think that's H entirely relevant to the discussion, then the above is totally relevant.  H > The arguments I presented more or less apply to any platform moving toJ > any platform i.e. it is not just the server HW cost and performance thatI > Customers look at when they consider moving. Usually, these are smaller 5 > considerations in the whole business justification.   
 Sometimes.  H >> Note, these comments are on your arguments, not on the merits of VMS. >> >> -- 7 >> David Froble                       Tel: 724-529-0450 A >> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com  >> DFE Ultralights, Inc. >> 170 Grimplin Road >> Vanderbilt, PA  15486 >> > A > OpenVMS is winning new Customers. Is it hundreds per week? No.   > @ > However, they are in areas where Customers view high levels ofJ > stability, availablility, scalability (up and out) and security as being > very important to them.  > J > Whether anyone here chooses to believe this or not is irrelevant, but it
 > is reality.   G Even a blind dog finds a bone sooner or later.  I'd be more interested  H in this claim, which I've been hearing for some years now, if some real  numbers were included.  I Is it relevant to this discussion to introduce the moving of VMS support  G to India?  I'd think the availability of adequate support would be one  5 of those issues considered when looking at platforms.   G Working for HP, you may be stuck with a dog's dinner, but please don't  9 try to feed it to those of us who have known much better.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Wed, 13 Sep 2006 19:56:04 -0400 ' From: Dave Froble <davef@tsoft-inc.com> / Subject: Re: HP announces new Integrity servers 9 Message-ID: <nbCdnbUf_INdBZXYnZ2dnUVZ_sSdnZ2d@libcom.com>    bob@instantwhip.com wrote: > Bill Todd wrote:K >> "We find ourselves living in a world of parity; at least as far as Unix, H >> OS/400, and VMS servers are concerned. What I mean by this is that asJ >> far as base technology goes, we have a level playing field. The WindowsI >> and Linux operating systems have made some progress, but still have to I >> make up some ground in terms of scalability, availability and workload @ >> management in order to compete head-to-head with the dominantJ >> Unixes--Solaris, AIX, and HP-UX--or IBM's OS/400-based iSeries platformK >> or Hewlett-Packard's OpenVMS platform, which may as well both be Unix in B >> terms of its uptime, resiliency, security, and sophistication." > E > oh yeah Bill ... they are all now on the same field as vms ... well 	 > someone H > better tell the CERT people that their security counts between vms and > all H > the other os's just have to be wrong ... and that they all now cluster > like6 > vms ... I think you are drinking more than kool aid!  I boob, if you knew how to read, you'd have seen that that is a quote from  E some information Kerry introduced, not Bill.  Bill did NOT write the  E above paragraph.  Get a clue on who you're accusing before you start   chucking rocks!   G > and the x86 boat anchor continues to sink ... their is a limit to the  > numberI > of processors and amount of cache you can throw on a dying architecture H > to keep it afloat, and in a few more years, intel, amd and anyone else > will" > run out of tricks ... then what? >   E You must be reading too much JF.  Today's products are not the 8086.  I Opteron and Athlon64 have two (2) very important capabilities that could  F be accused of being similar to Alpha EV7 capabilities, on-chip memory I controller and on-chip SMP glue.  the itanic has neither.  The number of  F processors has much to do with how they're connected and little to do G with architecure.  It's the itanic that's using large on-chip cache to  H gain some performance, not Opteron.  It the itanic and EPIC that may be  running out of tricks.  G Smart money is betting that this attempt to educate you is wasted, but   at least there was a try.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Wed, 13 Sep 2006 20:36:54 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> / Subject: Re: HP announces new Integrity servers , Message-ID: <4508A411.D4C74737@teksavvy.com>   Dave Froble wrote:J > Opteron and Athlon64 have two (2) very important capabilities that couldG > be accused of being similar to Alpha EV7 capabilities, on-chip memory ; > controller and on-chip SMP glue.  the itanic has neither.     H Intel has plans to also bring in on-chip memory controllers for the 8086A by 2008/2009 timeframe along with the new high performance system H interconnect.  Something about cache sizes having reached some limits on) how they can "hide" slower memory access.     ; Tukwilla (IA64) is also expected to support this new system A interconnect. Not sure it will have a on-chip memory interconnect  though.    ------------------------------  % Date: Wed, 13 Sep 2006 21:05:43 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> / Subject: RE: HP announces new Integrity servers T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401A64E57@tayexc19.americas.cpqcorp.net>   > -----Original Message-----9 > From: JF Mezei [mailto:jfmezei.spamnot@teksavvy.com]=20 " > Sent: September 13, 2006 4:41 PM > To: Info-VAX@Mvb.Saic.Com 1 > Subject: Re: HP announces new Integrity servers  >=20 > "Main, Kerry" wrote:B > > The BU's want IT to provide solutions that add value to the=20 > business.  >=20H > >Many BUs want IT to install the currently trendy platform/applicationG > they've read about in te trade rags because they think it is the only D > way to remain competitive. If your competitors have installed thatG > platform, there is less risk if you also choose that platform. If you F > choose a different platform, you not only have a harder time finding= > qualified people, but you also have risk that it will be=20  > "incompatible"F > and cause you more grief than any advantage it could have gotten you > ober competitors.  >=20 >=20> > > Solution TCO =3D HW + OS + ISV licenses + App migration=20 > porting + App   etc  >=20; > Only a certain percentage of customers actually REALLY=20  > evaluate TCO. IfA > TCO had been such an important metric, you'd have MACs on every 4 > corporate desktop in the world instead of Windows. >=20= > Many businesses just look at initial cost of acquisition=20  > because that is H > what they musty budget for during the selection/acquisition phase. And; > often, there is no way to know the TCO of the selected=20  > platform becauseB > they have no idea what percentage of the time their employees=20 > will spendB > managing that platform, providing fixes and fighting viruses,=20 > and since F > they don't know the number, they don't discuss it in their documehts4 > that outline their decisions to choose platform X. >=20  C Nope. What you are talking about is the way Customers *used* to buy F systems during the Internet wild times a few years ago. Most CustomersH IT budget spending is being examined with a magnifying glass these days.   >=20 >=20G > Mr Main, perhaps you are biased because in your case, your wins would : > have included a disproportionatly large percentage of=20 > customers who haveH > seriously looked at TCO and decided VMS was a better solution based on@ > real lonng term costs. But that is a tiny proportion of the=20 > total market.  >=20  / Bottom line for most med-large companies today:   E - budgets are being reduced, but at the same time, IT depts are being @ asked to deliver additional services e.g. take on support of new: applications and/or plan and implement major upgrades etc.  F - they have a huge server utilization problem whereby the one app, oneF server culture has resulted in servers being only 10-20% busy in primeH time. Analogy I like to make to C levels is "What would your reaction beC if someone told you that most of your staff was only 10-20% busy at  their peak time of the day"=20  H - the "grass is greener on the other side" migration mentality better beE supported with a very solid business case with payback in less than 2  years or it isn't happening.     Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Wed, 13 Sep 2006 21:37:01 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> / Subject: RE: HP announces new Integrity servers T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401A64E63@tayexc19.americas.cpqcorp.net>   > -----Original Message-----4 > From: Bill Todd [mailto:billtodd@metrocast.net]=20" > Sent: September 13, 2006 7:20 PM > To: Info-VAX@Mvb.Saic.Com 1 > Subject: Re: HP announces new Integrity servers  >=20 > Main, Kerry wrote: > >> -----Original Message----- 7 > >> From: Bill Todd [mailto:billtodd@metrocast.net]=20 % > >> Sent: September 11, 2006 2:26 AM  > >> To: Info-VAX@Mvb.Saic.Com4 > >> Subject: Re: HP announces new Integrity servers  
 [snip ...]  # > > You are looking at the HW only.  >=20: > No, idiot:  I'm looking at *solution* costs - initial=20 > purchase, ease of=20A > obtaining personnel familiar with the hardware and software,=20 B > availability of applications, cost-reduction by consolidating=20
 > around a=20 D > single platform type (which in many cases is possible *only* by=20H > consolidating around x86, because x86 will *always* be required for=20$ > *some* portions of the operation). >=20G > The word 'hardware' appears nowhere above, and the word 'solution'=20 B > appears in each of the two assertions (both in their original=20 > forms and=20J > in the subsequent paraphrasing of them).  So read them again, and try=20G > again, or shut up.  I'm not going to state them a third time here,=20 F > because both the original statement and the later paraphrase were=20J > crystal clear, despite your incompetent attempt to (yet again) divert=20 > the discussion elsewhere.  >=20  H Unfortunately, when you quote solution or support, your previous repliesH have been very HW only focussed - as an example from your earlier reply-   Earlier Bill Quote:   F Exactly:  they are looking at *standardizing* (for reasons of cost andG support complexity that have nothing to do with 'techie chip stuff') on H the *least expensive viable solution*.  And beyond any shadow of a doubt? that's x86-64 in any situation where that solution *is* viable.   H That's up to 64 Xeon cores *today* in IBM's X3 line, up to 32 Xeon coresH from Unisys, up to 8 Xeon cores from HP.  Up to 16 Opteron cores *today*F from Sun, up to 8 Opteron cores from HP and IBM).  Large enough in theB case of Xeon for all but the very small niche of those whose needsH exceed 64-core systems (and they'll be able to get more from x86-64 nextE year, when Opteron will start supporting 32-core systems effectively; F IBM's X3 systems may actually support 128-core configurations as earlyG as the end of this year if Intel ships quad-core Xeon modules by then), G and reliable enough for just about anyone who doesn't require *real*=20 . fault-tolerant redundantly-executing hardware.   End Bill quote.    Any, enough is enough.=20   ; Points have been made. Agree or not agree. Time to move on.    Regards,  
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Wed, 13 Sep 2006 22:14:11 -0400 ( From: Bill Todd <billtodd@metrocast.net>/ Subject: Re: HP announces new Integrity servers G Message-ID: <0P-dnTwBL6ZpJ5XYnZ2dnUVZ_qudnZ2d@metrocastcablevision.com>    Main, Kerry wrote: >> -----Original Message----- 3 >> From: Bill Todd [mailto:billtodd@metrocast.net]  # >> Sent: September 13, 2006 7:20 PM  >> To: Info-VAX@Mvb.Saic.Com2 >> Subject: Re: HP announces new Integrity servers >> >> Main, Kerry wrote:  >>>> -----Original Message----- 5 >>>> From: Bill Todd [mailto:billtodd@metrocast.net]  % >>>> Sent: September 11, 2006 2:26 AM  >>>> To: Info-VAX@Mvb.Saic.Com4 >>>> Subject: Re: HP announces new Integrity servers >  > [snip ...] > # >>> You are looking at the HW only. 9 >> No, idiot:  I'm looking at *solution* costs - initial   >> purchase, ease of  @ >> obtaining personnel familiar with the hardware and software, A >> availability of applications, cost-reduction by consolidating   >> around a C >> single platform type (which in many cases is possible *only* by  G >> consolidating around x86, because x86 will *always* be required for  % >> *some* portions of the operation).  >>F >> The word 'hardware' appears nowhere above, and the word 'solution' A >> appears in each of the two assertions (both in their original  
 >> forms and  I >> in the subsequent paraphrasing of them).  So read them again, and try  F >> again, or shut up.  I'm not going to state them a third time here, E >> because both the original statement and the later paraphrase were  I >> crystal clear, despite your incompetent attempt to (yet again) divert   >> the discussion elsewhere. >> > J > Unfortunately, when you quote solution or support, your previous repliesJ > have been very HW only focussed - as an example from your earlier reply- >  > Earlier Bill Quote:  > H > Exactly:  they are looking at *standardizing* (for reasons of cost andI > support complexity that have nothing to do with 'techie chip stuff') on J > the *least expensive viable solution*.  And beyond any shadow of a doubtA > that's x86-64 in any situation where that solution *is* viable.  > J > That's up to 64 Xeon cores *today* in IBM's X3 line, up to 32 Xeon coresJ > from Unisys, up to 8 Xeon cores from HP.  Up to 16 Opteron cores *today*H > from Sun, up to 8 Opteron cores from HP and IBM).  Large enough in theD > case of Xeon for all but the very small niche of those whose needsJ > exceed 64-core systems (and they'll be able to get more from x86-64 nextG > year, when Opteron will start supporting 32-core systems effectively; H > IBM's X3 systems may actually support 128-core configurations as earlyI > as the end of this year if Intel ships quad-core Xeon modules by then), G > and reliable enough for just about anyone who doesn't require *real*  0 > fault-tolerant redundantly-executing hardware. >  > End Bill quote.   F What part of offering up evidence to support the *range* of tasks for B which x86 can provide 'viable solutions' do you find difficult to B understand, Kerry?  Especially in response to someone so prone to I harping on the importance of 'server consolidation' and to attempting to  * dismiss x86 systems as strictly 'low-end'?  ? It's a matter of anticipating your all-too-predictable FUD and  C deflecting it in advance (in part because it becomes pretty boring  G responding to it after the fact time, after time, after time).  x86-64  I systems may extend considerably farther into the low-end than Itanic and  G the other proprietary (mostly RISC) platforms do (which is, of course,  C to x86's credit in terms of offering true 'desktop to data center'  F coverage) but now cover all of the mid-range and most of the high-end H ground that Itanic does - both in terms of hardware and software (Linux G and, especially, Solaris offering credible alternatives to proprietary  F mid-range-to-high-end Unix - and, according to the article you cited,  VMS and OS/400 - environments).   G Making x86 solutions extremely attractive for people looking to reduce  H the number of platforms they use and consolidate the expertise required D to support them - especially those installations whose needs do not D *currently* extend beyond the 8- to 16-core range (because multiple I tier-1 vendors offer both Xeon and Opteron servers in that range *today*  H and their core counts will double well within a year with the influx of H the quad-core parts on the near horizon - even if we try to dismiss the D larger IBM and Unisys Xeon systems available *today* as being niche 
 products).  E Of course, if *you* are willing to stop harping on consolidation and  G scalability as allegedly unmatchable Itanic strengths then *I* will be  A more than happy to stop pointing out x86-64's ability to compete  ( head-to-head with Itanic in these areas.   - bill   ------------------------------  % Date: Wed, 13 Sep 2006 22:55:24 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> / Subject: RE: HP announces new Integrity servers T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401A64E77@tayexc19.americas.cpqcorp.net>   > -----Original Message-----4 > From: Bill Todd [mailto:billtodd@metrocast.net]=20# > Sent: September 13, 2006 10:14 PM  > To: Info-VAX@Mvb.Saic.Com 1 > Subject: Re: HP announces new Integrity servers  >=20 > Main, Kerry wrote: > >> -----Original Message----- 7 > >> From: Bill Todd [mailto:billtodd@metrocast.net]=20 % > >> Sent: September 13, 2006 7:20 PM  > >> To: Info-VAX@Mvb.Saic.Com4 > >> Subject: Re: HP announces new Integrity servers > >> > >> Main, Kerry wrote: ! > >>>> -----Original Message----- 9 > >>>> From: Bill Todd [mailto:billtodd@metrocast.net]=20 ' > >>>> Sent: September 11, 2006 2:26 AM   > >>>> To: Info-VAX@Mvb.Saic.Com6 > >>>> Subject: Re: HP announces new Integrity servers > >=20 > > [snip ...] > >=20% > >>> You are looking at the HW only. = > >> No, idiot:  I'm looking at *solution* costs - initial=20  > >> purchase, ease of=20 D > >> obtaining personnel familiar with the hardware and software,=20E > >> availability of applications, cost-reduction by consolidating=20  > >> around a=20G > >> single platform type (which in many cases is possible *only* by=20 > > >> consolidating around x86, because x86 will *always* be=20 > required for=20 ' > >> *some* portions of the operation).  > >>J > >> The word 'hardware' appears nowhere above, and the word 'solution'=20E > >> appears in each of the two assertions (both in their original=20  > >> forms and=20 > > >> in the subsequent paraphrasing of them).  So read them=20 > again, and try=20 J > >> again, or shut up.  I'm not going to state them a third time here,=20I > >> because both the original statement and the later paraphrase were=20 ? > >> crystal clear, despite your incompetent attempt to (yet=20  > again) divert=20 > >> the discussion elsewhere. > >> > >=20> > > Unfortunately, when you quote solution or support, your=20 > previous replies@ > > have been very HW only focussed - as an example from your=20 > earlier reply- > >=20 > > Earlier Bill Quote:  > >=20A > > Exactly:  they are looking at *standardizing* (for reasons=20 
 > of cost and > > > support complexity that have nothing to do with 'techie=20 > chip stuff') on = > > the *least expensive viable solution*.  And beyond any=20  > shadow of a doubt C > > that's x86-64 in any situation where that solution *is* viable.  > >=20A > > That's up to 64 Xeon cores *today* in IBM's X3 line, up to=20  > 32 Xeon cores A > > from Unisys, up to 8 Xeon cores from HP.  Up to 16 Opteron=20  > cores *today* ? > > from Sun, up to 8 Opteron cores from HP and IBM).  Large=20  > enough in the F > > case of Xeon for all but the very small niche of those whose needs> > > exceed 64-core systems (and they'll be able to get more=20 > from x86-64 next? > > year, when Opteron will start supporting 32-core systems=20  > effectively;5 > > IBM's X3 systems may actually support 128-core=20  > configurations as early < > > as the end of this year if Intel ships quad-core Xeon=20 > modules by then), < > > and reliable enough for just about anyone who doesn't=20 > require *real*=20 2 > > fault-tolerant redundantly-executing hardware. > >=20 > > End Bill quote.  >=20J > What part of offering up evidence to support the *range* of tasks for=20F > which x86 can provide 'viable solutions' do you find difficult to=20F > understand, Kerry?  Especially in response to someone so prone to=20? > harping on the importance of 'server consolidation' and to=20  > attempting to=20, > dismiss x86 systems as strictly 'low-end'? >=20  B Bill, your getting to predictable. I am trying to move on here.=20  G Ok, say you have a great x86-64 with 96 cpus. Given the one server, one B app culture with Windows and Linux, what OS will you run on it?=20  F Yes, you can partition it into many smaller ones, but is that the bestE use of a high end system? You also need an OS license with all of the 6 managing software licences for each partition as well.  G And for those sticking with Solaris, they are staying with SPARC on the 	 high end.   C > It's a matter of anticipating your all-too-predictable FUD and=20 G > deflecting it in advance (in part because it becomes pretty boring=20 < > responding to it after the fact time, after time, after=20 > time).  x86-64=20 B > systems may extend considerably farther into the low-end than=20 > Itanic and=20 @ > the other proprietary (mostly RISC) platforms do (which is,=20 > of course,=20 G > to x86's credit in terms of offering true 'desktop to data center'=20 J > coverage) but now cover all of the mid-range and most of the high-end=20< > ground that Itanic does - both in terms of hardware and=20 > software (Linux=20? > and, especially, Solaris offering credible alternatives to=20  > proprietary=20J > mid-range-to-high-end Unix - and, according to the article you cited,=20! > VMS and OS/400 - environments).  >=20A > Making x86 solutions extremely attractive for people looking=20  > to reduce=209 > the number of platforms they use and consolidate the=20  > expertise required=20 H > to support them - especially those installations whose needs do not=20H > *currently* extend beyond the 8- to 16-core range (because multiple=20? > tier-1 vendors offer both Xeon and Opteron servers in that=20  > range *today*=20B > and their core counts will double well within a year with the=20 > influx of=20@ > the quad-core parts on the near horizon - even if we try to=20 > dismiss the=20H > larger IBM and Unisys Xeon systems available *today* as being niche=20 > products). >=20I > Of course, if *you* are willing to stop harping on consolidation and=20 ? > scalability as allegedly unmatchable Itanic strengths then=20  > *I* will be=20E > more than happy to stop pointing out x86-64's ability to compete=20 * > head-to-head with Itanic in these areas. >=20 > - bill >=20     Time to move on.=20   H You think Windows and Linux will offer good consolidation solutions just" because they can run on x86-64.=20  F I think these are limited by one-app, one server culture and a host of other reasons.  # Agree to disagree. Time to move on.    Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Wed, 13 Sep 2006 23:23:28 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> / Subject: Re: HP announces new Integrity servers , Message-ID: <4508CB11.C2796854@teksavvy.com>   "Main, Kerry" wrote:I > Ok, say you have a great x86-64 with 96 cpus. Given the one server, one A > app culture with Windows and Linux, what OS will you run on it?   E If the customer has that one-app-one-server attitude, they won't buyt G that 96 CPU machine, they'll buy a blade system or just a bunch of even  cheaper separate systems.   F If the customer does run a one instance many app approach, then he can buy that 96 CPU mainframe.    G The point is that with the 8086, you get what Carly/Curly promised when F they killed Alpha: a commodity, low cost, truly scalable architecture.2 (none of which were delivered by that IA64 thing).  G The market is far greater than just your "consolidation" thing which is F this weeks industry buzzword that will fade away soon (like the "open"H buzzword faded in the 1990s just after Palmer erroneously tagged it onto VMS to confuse people).   ? By putting VMS on a maintream architecture that spans laptop to H mainframe, you can the start to lererage many opportunities to grow VMS.A By limiting VSM to that niche market IA64 thing, you are severely @ limiting VMS to a subset of that small remaining niche for IA64.    E If VMS management are perfectly happy with restricting VMS to an ever H smaller market niche, if they are happy with dindling installed base, ifF they are happy with news of major database packages not ported to VMS,D then VMS management either needs a big kick in the ass or be fired.   B VMS has great potential, and it is VMS' management,s role to fullyH leverage that potential to grow the installed base, grow service revenusF and grow the profits generated by VMS in order to please shareholders.D And doing so also pleases cutsomers because a growing ecosystem also: means more applications and more ISV involvement with VMS.    A When even an IDG survery posted by HP on the HP web site predicts E serious 30% erosion of installed based because of the unwated move to J IA64, it is ludicrous to see VMS management still blindly supporting IA64.  G IA64 can exist. And in fact, IA64 would stay a schance of a better life F if VMS were ported to the 8086 while still existing on IA64. This way,E VMS could grow into the 8086 market, while still participating in the H high end IA64 market until the 8086 catches up. Growth in VMS because ofH its port to the 8086 would grow interesrt in VMS and make it much easierH for ISVs who have ported to the 78086 to also create a version for IA64.  H As it stands, interest in IA64 is dwindling and the ISV community is not9 exactly ready to port big time apps like Oracle, SAP etc.     B So, it can easily be argued that those HP employees who publicallyB support only IA64 are in fact hurting their employer's profits and7 chances for survival in the enterprise computing arena.   > You should seek the solutions that provide the greatest growthA oppportunities. IA64 only provides a 30% loss in installed base.  F Staying with only IA64 is not acceptable and HP/VMS managemenmt should not tolerate it.  C Remember that HP is not a servant to Intel or Microsoft. They are a E servant to HP shareholders (and to some extent HP customers) and they P cannot afford to scuttle their own products just to help Intel and/or Microsoft.    J > You think Windows and Linux will offer good consolidation solutions just! > because they can run on x86-64.   E No. The better consolidation solution happen because the 8086 product B range is more diversified and you can fidn a server that fits yourH needs, no matter how big or small you are. With IA64, if you don't fit a2 certain niche market, IA64 is not for you. Period.  F So, if you are employed by VMS management, your goal should be to findG the solutions that enable VMS to grow the most. Restricting VMS to IA64 H means that you accept that VMS will take a 30% hit on ist installed baseD and that as such, you accept furtrher downsizing of VMS, which meansD downsizing of engineering, development, which means VMS falls behindH other OS even more and which means VMS quickly becomes irrelevant to the( industry because it will be so far back.  " DO YO REALLY WANT THAT TO HAPPEN ?   I DON'T.   ------------------------------  % Date: Thu, 14 Sep 2006 00:45:01 -0400 ( From: Bill Todd <billtodd@metrocast.net>/ Subject: Re: HP announces new Integrity servers G Message-ID: <8t-dneorssLTQ5XYnZ2dnUVZ_oidnZ2d@metrocastcablevision.com>    Main, Kerry wrote: >> -----Original Message----- 3 >> From: Bill Todd [mailto:billtodd@metrocast.net]  $ >> Sent: September 13, 2006 10:14 PM >> To: Info-VAX@Mvb.Saic.Com2 >> Subject: Re: HP announces new Integrity servers >> >> Main, Kerry wrote:  >>>> -----Original Message----- 5 >>>> From: Bill Todd [mailto:billtodd@metrocast.net]  % >>>> Sent: September 13, 2006 7:20 PM  >>>> To: Info-VAX@Mvb.Saic.Com4 >>>> Subject: Re: HP announces new Integrity servers >>>> >>>> Main, Kerry wrote: ! >>>>>> -----Original Message----- 7 >>>>>> From: Bill Todd [mailto:billtodd@metrocast.net]  ' >>>>>> Sent: September 11, 2006 2:26 AM   >>>>>> To: Info-VAX@Mvb.Saic.Com6 >>>>>> Subject: Re: HP announces new Integrity servers >>> [snip ...] >>> % >>>>> You are looking at the HW only. ; >>>> No, idiot:  I'm looking at *solution* costs - initial   >>>> purchase, ease of  B >>>> obtaining personnel familiar with the hardware and software, C >>>> availability of applications, cost-reduction by consolidating   >>>> around a E >>>> single platform type (which in many cases is possible *only* by  < >>>> consolidating around x86, because x86 will *always* be  >> required for ' >>>> *some* portions of the operation).  >>>>H >>>> The word 'hardware' appears nowhere above, and the word 'solution' C >>>> appears in each of the two assertions (both in their original   >>>> forms and  < >>>> in the subsequent paraphrasing of them).  So read them  >> again, and try H >>>> again, or shut up.  I'm not going to state them a third time here, G >>>> because both the original statement and the later paraphrase were  = >>>> crystal clear, despite your incompetent attempt to (yet   >> again) divert   >>>> the discussion elsewhere. >>>>< >>> Unfortunately, when you quote solution or support, your  >> previous replies > >>> have been very HW only focussed - as an example from your  >> earlier reply-  >>> Earlier Bill Quote:  >>> ? >>> Exactly:  they are looking at *standardizing* (for reasons   >> of cost and< >>> support complexity that have nothing to do with 'techie  >> chip stuff') on; >>> the *least expensive viable solution*.  And beyond any   >> shadow of a doubtC >>> that's x86-64 in any situation where that solution *is* viable.  >>> ? >>> That's up to 64 Xeon cores *today* in IBM's X3 line, up to   >> 32 Xeon cores? >>> from Unisys, up to 8 Xeon cores from HP.  Up to 16 Opteron   >> cores *today*= >>> from Sun, up to 8 Opteron cores from HP and IBM).  Large   >> enough in theF >>> case of Xeon for all but the very small niche of those whose needs< >>> exceed 64-core systems (and they'll be able to get more  >> from x86-64 next = >>> year, when Opteron will start supporting 32-core systems   >> effectively; 3 >>> IBM's X3 systems may actually support 128-core   >> configurations as early: >>> as the end of this year if Intel ships quad-core Xeon  >> modules by then),: >>> and reliable enough for just about anyone who doesn't  >> require *real* 2 >>> fault-tolerant redundantly-executing hardware. >>>  >>> End Bill quote. I >> What part of offering up evidence to support the *range* of tasks for  E >> which x86 can provide 'viable solutions' do you find difficult to  E >> understand, Kerry?  Especially in response to someone so prone to  > >> harping on the importance of 'server consolidation' and to  >> attempting to  - >> dismiss x86 systems as strictly 'low-end'?  >> > B > Bill, your getting to predictable. I am trying to move on here.   G You're welcome to move on just as soon as you stop pretending that you  H have a leg to stand on where we are now.  Until then, keep expecting to  get knocked on your ass.   > I > Ok, say you have a great x86-64 with 96 cpus. Given the one server, one B > app culture with Windows and Linux, what OS will you run on it?   I The same kind of system that you'd run on Itanic:  Windows (if you'd run  G that on Itanic), Linux or *BSD (if you'd run that on Itanic - not that  G Linux and *BSD have anything like a 'one app' culture), or Solaris (if  D you'd run HP-UX or, according the the philosophy in the article you  cited, VMS on Itanic).   > H > Yes, you can partition it into many smaller ones, but is that the best > use of a high end system?   B That's for the customer to decide - and, as noted just above, the H customer has the *same* range of choices that he or she has on Itanic - + but on a *real* industry-standard platform.   F As opposed to Itanic.  If you want to do business with tier-1 vendors H (as the people interested in the kind of systems you keep talking about H usually do), you can get Opteron servers from all of the big four (IBM, F HP, Sun, and Dell) and Xeon servers from three of them (Sun being the 
 hold-out).  L If you want Itanic servers from a tier-1 vendor, you can get them from - HP.  -   You also need an OS license with all of the 8 > managing software licences for each partition as well.  F Just as you do if you choose the same system configuration on Itanic. D Duh.  Stop pretending that Itanic offers any advantage in this area.   > I > And for those sticking with Solaris, they are staying with SPARC on the  > high end.   F What part of the fact that x86-64 covers most of the high end *today* B (in up-to-64-core-systems from IBM and up-to-32-core systems from F Unisys) continues to be so difficult for you to grasp?  While Sun and I IBM haven't completely ironed out arrangements for supporting Solaris on  H IBM's X3 configurations the way Solaris is *already* supported on IBM's G x86 blades, they've worked out an arrangement where EBS does so in the  F interim (I don't know whether any similar Solaris support arrangement * has been created on Unisys x86 platforms).  G If the customer *wants* SPARC on the high end, that's of course OK too.    > B >> It's a matter of anticipating your all-too-predictable FUD and F >> deflecting it in advance (in part because it becomes pretty boring ; >> responding to it after the fact time, after time, after   >> time).  x86-64 A >> systems may extend considerably farther into the low-end than   >> Itanic and ? >> the other proprietary (mostly RISC) platforms do (which is,   >> of course, F >> to x86's credit in terms of offering true 'desktop to data center' I >> coverage) but now cover all of the mid-range and most of the high-end  ; >> ground that Itanic does - both in terms of hardware and   >> software (Linux  > >> and, especially, Solaris offering credible alternatives to  >> proprietary  I >> mid-range-to-high-end Unix - and, according to the article you cited,  " >> VMS and OS/400 - environments). >>@ >> Making x86 solutions extremely attractive for people looking 
 >> to reduce  8 >> the number of platforms they use and consolidate the  >> expertise required G >> to support them - especially those installations whose needs do not  G >> *currently* extend beyond the 8- to 16-core range (because multiple  > >> tier-1 vendors offer both Xeon and Opteron servers in that  >> range *today*  A >> and their core counts will double well within a year with the  
 >> influx of  ? >> the quad-core parts on the near horizon - even if we try to   >> dismiss the  G >> larger IBM and Unisys Xeon systems available *today* as being niche  
 >> products).  >>H >> Of course, if *you* are willing to stop harping on consolidation and > >> scalability as allegedly unmatchable Itanic strengths then  >> *I* will be  D >> more than happy to stop pointing out x86-64's ability to compete + >> head-to-head with Itanic in these areas.  >>	 >> - bill  >> >  >  > Time to move on.    E It's understandable why you'd want to, but I'm not finished with you  	 here yet.    > J > You think Windows and Linux will offer good consolidation solutions just" > because they can run on x86-64.   I You think that you can put words into my mouth without getting caught at   it.  Wrong yet again.   G I think that *x86-64* platforms can offer consolidation solutions that  G are directly comparable to those that Itanic can, because they can run  G the same kind of software that makes consolidation feasible on Itanic,  D as noted above:  Windows where that works, Linux or *BSD where that 1 works, Solaris where a higher-end OS is required.   G You have yet to come up with a single significant strength that Itanic  C can boast of but that x86-64 cannot - save, of course, for VMS (or  E HP-UX) support (precisely the distinction that the article which you  & cited claimed was no longer relevant).   - bill   ------------------------------  % Date: Wed, 13 Sep 2006 18:07:24 -0700 * From: "Tom Linden" <tom@kednos-remove.com>1 Subject: Re: HP supported DVD writer for V/A 8.3? ) Message-ID: <op.tfuf2mx5tte90l@hyrrokkin>   6 On Wed, 13 Sep 2006 18:12:28 -0700, David J Dachtera  " <djesys.nospam@comcast.net> wrote:   > Rod wrote: >>H >> V/A 8.3 has been released.  I have reviewed the SPD and related Alpha" >> hardware support documentation. >>E >> I have been unable to find an HP-supported DVD *writer* for Alphas  >> running V/A 8.3.  > - > I'd be curious to know what "V/A" might be.  >  VMS/Alpha ?      --  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Wed, 13 Sep 2006 20:12:28 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>1 Subject: Re: HP supported DVD writer for V/A 8.3? + Message-ID: <4508AC7C.DB8D17A1@comcast.net>   
 Rod wrote: > G > V/A 8.3 has been released.  I have reviewed the SPD and related Alpha ! > hardware support documentation.  > D > I have been unable to find an HP-supported DVD *writer* for Alphas > running V/A 8.3.  + I'd be curious to know what "V/A" might be.    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------  % Date: Wed, 13 Sep 2006 14:00:24 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 9 Subject: Re: Inquirer on VMS support outsourcing to India 9 Message-ID: <ha2dnVERgdD-2JXYnZ2dnUVZ_s6dnZ2d@libcom.com>    islandco wrote: K > Does anyone think there could be a market for "pay as you go" support for  > VMS outside of HP?N > Perhaps an Irishman/Brit or American that knows the OS back to front working# > for a small company such as ours. : > I guess COV is probably still the best place for issues.A > I wonder how many calls get logged to the call center anyway... L > Most people in this business have considerable knowledge of the OS or know- > people through networking on COV that do...  >  >   H If you're going to do it, forget the "pay as you go" and go with annual H service contracts.  You'd need knowledgeable people, and from the rumor B they may become available.  You'd need to emphasize where they're I located and such.  You'd need to contact most/all VMS customers and tell  0 them their support is going to novices in India.  E Given HP's current ethics, or lack thereof, would you really want to  8 incur their wrath over attacking one of their cash cows?  A One of the strengths of the current support is the capability to  C escalate a problem to the engineers.  Think you'd be able to do so?    Just one person's thoughts.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Wed, 13 Sep 2006 14:25:19 -0400 $ From: "islandco" <dturner@icusc.com>9 Subject: Re: Inquirer on VMS support outsourcing to India 0 Message-ID: <12ggj8ng4sdo1e2@news.supernews.com>  H We could hire some True English speaking US/Brits, set them up with Work6 Visas in China, and let them offer support from there.H China seems impervious to Law suits and the wrath of the Corporate World   --     David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404  Tel: 912 447 6622 X201 Cell: 912 447 6622 X251  Fax: 912 201 0402  Email: dbturner@islandco.com Web: http://www.islandco.com% ===================================== < All orders are subject to the following terms and conditions. of sale. These should be read before ordering.% http://www.islandco.com/warranty.html   4 "Dave Froble" <davef@tsoft-inc.com> wrote in message3 news:ha2dnVERgdD-2JXYnZ2dnUVZ_s6dnZ2d@libcom.com...  > islandco wrote: I > > Does anyone think there could be a market for "pay as you go" support  for  > > VMS outside of HP?H > > Perhaps an Irishman/Brit or American that knows the OS back to front working % > > for a small company such as ours. < > > I guess COV is probably still the best place for issues.C > > I wonder how many calls get logged to the call center anyway... I > > Most people in this business have considerable knowledge of the OS or  know/ > > people through networking on COV that do...  > >  > >  > I > If you're going to do it, forget the "pay as you go" and go with annual I > service contracts.  You'd need knowledgeable people, and from the rumor C > they may become available.  You'd need to emphasize where they're J > located and such.  You'd need to contact most/all VMS customers and tell2 > them their support is going to novices in India. > F > Given HP's current ethics, or lack thereof, would you really want to: > incur their wrath over attacking one of their cash cows? > B > One of the strengths of the current support is the capability toE > escalate a problem to the engineers.  Think you'd be able to do so?  >  > Just one person's thoughts.  >  > --  6 > David Froble                       Tel: 724-529-0450@ > Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com > DFE Ultralights, Inc.  > 170 Grimplin Road  > Vanderbilt, PA  15486    ------------------------------  % Date: Wed, 13 Sep 2006 16:05:41 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 9 Subject: Re: Inquirer on VMS support outsourcing to India , Message-ID: <45086493.603816EF@teksavvy.com>   Ian Miller wrote: C > > Which is odd considering that the margin on VMS business is 20%  > > 2 > selective blindness by the bean counters I guess  H Consider that many parts of VMS maintenance have already moved to India.F So anyone calling for support on those parts that are being maintainedG in india might actually have better support than calling in the USA who - no longer have jurisdiction over those parts.     F Now, lets look at the real trend here: Products who have been declaredF "mature" have had their maintenance moved to India. Notably ALLIN1 andF many of the products it uses below it. The conclusion is that the moreK of VMS they move to India, the closer VMS comes to being declared "mature".   G Dear VMS engineers: if you want the VMS community to fight to save your H jobs you're going to have to develop some ways to send us a message thatG it is time to rise up and fight (without you getting accused of leaking 7 and having all your personal phone calls recorded etc).    ------------------------------  % Date: Wed, 13 Sep 2006 16:08:03 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 9 Subject: Re: Inquirer on VMS support outsourcing to India , Message-ID: <4508651E.DBB0F60F@teksavvy.com>   islandco wrote:  > K > Does anyone think there could be a market for "pay as you go" support for  > VMS outside of HP?  G Guess which company is best suited to support DCL these days ?   Bruden  just hired Guido...     G Perhaps Bruden could pool up all the VMS/TCPIP engineers that have been 8 let go in the recent past and have them provide support.  : > I guess COV is probably still the best place for issues.  " Yes, I was just about to say that.   ------------------------------  % Date: Wed, 13 Sep 2006 16:45:01 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 9 Subject: Re: Inquirer on VMS support outsourcing to India , Message-ID: <45086DC6.6E478321@teksavvy.com>  N > >> Does anyone think there could be a market for "pay as you go" support for > >> VMS outside of HP?     @ What would be needed would be a network of available independantE resources. And some central focal point that can then direct calls to H such resources who would then work on the issue. And it could work a bit# like automobile associations plans:   E Customer pays some fee, and in a call, the "association" then patches F the call to an independant "tow truck" company who gets a fixed/agreedH fee from the association for a defined work unit. So the consultants mayG not be able to define their own rates, but they get that extra business  from the association.    ------------------------------  % Date: Wed, 13 Sep 2006 19:00:11 -0400 3 From: "Richard B. Gilbert" <rgilbert88@comcast.net> 9 Subject: Re: Inquirer on VMS support outsourcing to India : Message-ID: <fo2dnSO0IsvjEJXYnZ2dnUVZ_sadnZ2d@comcast.com>   Bob Koehler wrote:X > In article <4mqgakF7co3bU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > C >>Probably shoots down the myth that the government is riddled with C >>all these invisible VMS systems.  Either that or the one guy left B >>in this country to handlle these contracts is never going to see >>his family again. :-)  >  > E >    There's more than one person, working for more than one company. A >    But somehow I don't think HP has abandon all its commitments E >    to the US government just because the Inquirer wanted to write a  >    story.  > D >    More likely some part of the support will move to India.  AfterB >    all you can hire incompetent people cheaper in India than the$ >    incompetent people in Colorado. > B >    But what we really need is the secret code word that replacedG >    "elevate" which we used to get competent people when we dealt with 	 >    DEC.  >   G As I recall, DEC, usually had competent people on the phones.  The rot  G didn't really set in until HP took over.  About three years ago, I was  F having a problem with support and asked to speak with the "Manager on I Duty".  They didn't even know what I was talking about!!!  I finally got  G to speak to a manager who had some clue as to what I was talking about. F It seems that the "manager on duty" had joined the Auk, Dodo, and the  Passenger Pigeon.   E If the first DEC person you got didn't understand the problem he/she  ( knew how to get hold of someone who did.  F I have fond memories of Katharina Khan and Smiley Smith; there were a D few others I knew by name but those are the only two I remember now.  F I also remember the poor bastard who tried to help me find patches on D ITRC after HP shut down the old system in Colorado.  It took HIM at 4 least twenty minutes to find the patch in that mess!  
   R.I.P. DEC.    ------------------------------  % Date: Wed, 13 Sep 2006 20:16:35 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 9 Subject: Re: Inquirer on VMS support outsourcing to India 9 Message-ID: <e_adnRoiGa0QAJXYnZ2dnUVZ_rqdnZ2d@libcom.com>    islandco wrote: J > We could hire some True English speaking US/Brits, set them up with Work8 > Visas in China, and let them offer support from there.J > China seems impervious to Law suits and the wrath of the Corporate World >   0 Wrong direction.  I don't want to move to China.  E HP would still know who to blame, or would you be moving your entire   operation to China.   I Better to just show them the finger and just do it.  Still, there is the  # problem of access to the engineers.   E Hey, I'm thinking about one of the DS10L systems you just mentioned.  / How many do you have?  I'd need to use a check.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Wed, 13 Sep 2006 20:44:36 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 9 Subject: Re: Inquirer on VMS support outsourcing to India , Message-ID: <4508A5DF.29DE8583@teksavvy.com>   Dave Froble wrote:J > Better to just show them the finger and just do it.  Still, there is the% > problem of access to the engineers.     H 3rd party support folks may have easier access to VMS engineers than theH drones who take the calls at the HP call centres. Remember that many VMS engineers have left HP.   C Will Bruce Ellis end up being the boss of Hoff and FredK, Guido and $ perhaps the TCPIP engineering team ?   ------------------------------    Date: 13 Sep 2006 21:43:57 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) 9 Subject: Re: Inquirer on VMS support outsourcing to India 3 Message-ID: <ZrRmyv6fFpsR@eisner.encompasserve.org>   p In article <fo2dnSO0IsvjEJXYnZ2dnUVZ_sadnZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:  ? > As I recall, DEC, usually had competent people on the phones.   E My last experience with the DEC telephone support center involved me, B as representative of the customer, teaching them, the Pascal team, how Pascal syntax worked.    ------------------------------  % Date: Wed, 13 Sep 2006 23:14:57 -0400 3 From: "Richard B. Gilbert" <rgilbert88@comcast.net> 9 Subject: Re: Inquirer on VMS support outsourcing to India : Message-ID: <f8ednRRi8YSpVJXYnZ2dnUVZ_tGdnZ2d@comcast.com>   Larry Kilgallen wrote:  r > In article <fo2dnSO0IsvjEJXYnZ2dnUVZ_sadnZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes: >  > ? >>As I recall, DEC, usually had competent people on the phones.  >  > G > My last experience with the DEC telephone support center involved me, D > as representative of the customer, teaching them, the Pascal team, > how Pascal syntax worked.   : Well, now you can teach them how English syntax works. :-)   ------------------------------   Date: 13 Sep 2006 21:18:03 GMT) From: Hans Bachner <Hans@Bachner.priv.at> 4 Subject: Re: Limiting bytlm within a spawned process0 Message-ID: <eea3j9.9f.1@usenet.bachner.priv.at>  ) Jeff Cameron <roktsci@comcast.net> wrote:     > On 9/13/06 7:11 AM, in articleA > 1158156671.309657.132690@m73g2000cwd.googlegroups.com, "Brucey" ' > <Bruce.Goller@LCHClearnet.com> wrote:  > H >> Does anyone know to limit bytlm within a process kicked off using the >> command:  >>   >> $ SPAWN / NOWAIT .... >>   <snip>  D > Another possibility would be to install the NETCU image as a known# > image with the EXQUOTA privilege.   G No, this won't help - EXQUOTA allows a process to exceed the disk quota ) assigned to its UIC, not process quotas.     Hans Bachner http://b.it.co.at    ------------------------------  % Date: Wed, 13 Sep 2006 20:28:51 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>A Subject: MOUNT quietly ignores JTQUOTA exhausted (OpenVMS V7.3-2) * Message-ID: <4508B053.DF898E3@comcast.net>   Sorry... This is long...  C I discovered something quite by accident last week: when MOUNTing a C large number of volumes privately to a your process, MOUNT does not G return a failure indication when it cannot create a Logical Volume Name + because the process's JTQUOTA is exhausted.   + Here's a snippet of the code I was testing:   $ (from a proc. Called BCV_MOUNT.COM:)   	. 	. 	.
 $mnt_loop: $ open/read bcvs &fsp  $loop_2: $ read/end=eof_bcvs bcvs p9  $ devc = f$elem( 0, " ", p9 )  $ mount/noassi/over=id &devc" $ lbl = f$getdvi( devc, "volnam" )B $ rlbl = (f$trnlnm( lbl ) .nes. "") .and. (f$locate("/SY",p2) .ne.
 f$len(p2)) $ if    rlbl $ then' $       unit = f$getdvi( devc, "unit" )  $       lbl := drive'unit'# $       set volume/label=&lbl &devc  $ else $ endif  $ dism/nounl &devc $ mount'p2' &devc &lbl &lbl  $ if 0'debug' then -9 $ say f$fao( " ""!AS"" = ""!AS""", lbl, f$trnlnm( lbl ) ) 
 $ goto loop_2 
 $eof_bcvs: $ close bcvs 	. 	. 	.  F The DEBUG symbol is actually set one procedure level above this, hence the "0'debug'" notation.  F With a JTQUOTA of 4096 and a P2 value of "/NOMESSAGE/NOASSIST", here's the output:   8 %MOUNT-I-MOUNTED, PROD196 mounted on _$1$DGA1310: (HNAJ)  "PROD196" = "$1$DGA1310:"8 %MOUNT-I-MOUNTED, PROD200 mounted on _$1$DGA1314: (HNAJ)  "PROD200" = "$1$DGA1314:"8 %MOUNT-I-MOUNTED, PROD204 mounted on _$1$DGA1318: (HNAJ)  "PROD204" = "$1$DGA1318:"8 %MOUNT-I-MOUNTED, PROD208 mounted on _$1$DGA1322: (HNAJ)  "PROD208" = "$1$DGA1322:"8 %MOUNT-I-MOUNTED, PROD212 mounted on _$1$DGA1326: (HNAJ)  "PROD212" = "$1$DGA1326:"8 %MOUNT-I-MOUNTED, PROD216 mounted on _$1$DGA1330: (HNAJ)  "PROD216" = "$1$DGA1330:"8 %MOUNT-I-MOUNTED, PROD220 mounted on _$1$DGA1334: (HNAJ)  "PROD220" = "$1$DGA1334:"8 %MOUNT-I-MOUNTED, PROD224 mounted on _$1$DGA1338: (HNAJ)  "PROD224" = "$1$DGA1338:"8 %MOUNT-I-MOUNTED, PROD228 mounted on _$1$DGA1342: (HNAJ)  "PROD228" = "$1$DGA1342:"8 %MOUNT-I-MOUNTED, PROD232 mounted on _$1$DGA1346: (HNAJ)  "PROD232" = "$1$DGA1346:"8 %MOUNT-I-MOUNTED, PROD236 mounted on _$1$DGA1350: (HNAJ)  "PROD236" = ""   G Starting there, MOUNT fails to create the LOGVOLNAM because JTQUOTA has > been exhausted, but no message or failure status is returned.   B In the proc. which invokes BCV_MOUNT, I added this code to verify:  
 $ if    debug  $ then $       show logical/proc  $       show logical/job $ endif    Here's the output from that:     (LNM$PROCESS_TABLE)   +   "BACKUP_COM" = "PATH4:[BACKUP]BACKUP.COM" +   "BACKUP_LOG" = "PATH4:[BACKUP]BACKUP.LOG"    "DFU$NOSMG" = "X" ,   "DTR$STARTUP" = "USER$COM:DTR$STARTUP.COM"#   "EDTINI" = "SYS$LOGIN:EDTINI.EDT"    "SYS$COMMAND" = "_DSA60:" #   "SYS$DISK" [super] = "USER_DISK:" "   "SYS$DISK" [exec] = "USER_DISK:"   "SYS$ERROR" = "_DSA60:"    "SYS$INPUT" = "_DSA60:" "   "SYS$OUTPUT" [super] = "_DSA60:"!   "SYS$OUTPUT" [exec] = "_DSA60:" "   "TMENU" = "USER_DISK:[TAPEMENU]"   "TOOLS" = "USER$EXE:"    "TT" = "_NLA0:" &   "VAXLINK2" = "USER$EXE:ALPHALK2.EXE"   (LNM$JOB_84DFC340)  5   "CLUE$DUMP_PATH" = "CLUE$DOSD_DEVICE:[SYS5.SYSEXE]"    "DCL$PATH" = "USER$COM:"         = "USER$IMG:"     "DISK$PROD196" = "$1$DGA1310:"    "DISK$PROD200" = "$1$DGA1314:"    "DISK$PROD204" = "$1$DGA1318:"    "DISK$PROD208" = "$1$DGA1322:"    "DISK$PROD212" = "$1$DGA1326:"    "DISK$PROD216" = "$1$DGA1330:"    "DISK$PROD220" = "$1$DGA1334:"    "DISK$PROD224" = "$1$DGA1338:"    "DISK$PROD228" = "$1$DGA1342:"   "PROD196" = "$1$DGA1310:"    "PROD200" = "$1$DGA1314:"    "PROD204" = "$1$DGA1318:"    "PROD208" = "$1$DGA1322:"    "PROD212" = "$1$DGA1326:"    "PROD216" = "$1$DGA1330:"    "PROD220" = "$1$DGA1334:"    "PROD224" = "$1$DGA1338:"    "PROD228" = "$1$DGA1342:"    "PROD232" = "$1$DGA1346:" ,   "RIGHTSLIST" = "SYS$SYSTEM:RIGHTSLIST.DAT"   "SY0" = "DSA3:" !   "SYS$HELP" = "USER$ROOT:[HELP]"           = "SYS$SYSROOT:[SYSHLP]""   "SYS$LOGIN" = "USER$ROOT:[WORK]"#   "SYS$LOGIN_DEVICE" = "USER_DISK:" .   "SYS$SCRATCH" = "USER_DISK:[USER.DDACHTERA]""   "SYSEXE" = "SYS$COMMON:[SYSEXE]""   "SYSMGR" = "SYS$COMMON:[SYSMGR]"   "USER$" = "USER_DISK:[USER]"    "USER$COM" = "USER$ROOT:[EXE]"   "USER$EXE" = "USER$IMG:"         = "USER$COM:" !         = "SYS$SPECIFIC:[SYSEXE]"          = "SYS$COMMON:[SYSEXE]" &   "USER$IMG" = "USER$ROOT:[EXE.ALPHA]"%   "USER$LOGIN" = "USER$ROOT:[000000]" )   "USER$ROOT" = "DSA60:[USER.DDACHTERA.]"   D So, we can see that the MOUNTs succeeded, even though the LOGVOLNAMs. were not created due to exhaustion of JTQUOTA.  6 Is this the expected behavior? ...or is this an issue?  F BTW: I posted one possible work-around for this on OpenVMS.org's Tech. Forum.   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------  % Date: Wed, 13 Sep 2006 18:21:47 -0400 - From: bradhamilton <bradhamilton@comcast.net> Y Subject: Mozilla Thunderbird with VMS (was:Re: VMS MAIL:  Will it ever join the 21st cent * Message-ID: <4508847B.4050001@comcast.net>   Stephen Eickhoff wrote:  [...]  >> Stephen Eickhoff wrote:. >>> What exactly are HP's plans for VMS Mail?  [...] F > I was talking about servers, not clients.  I _am_ trying to use the & > Mozilla Thunderbird client with VMS.  D I have used Thunderbird with VMS (Thunderbird on Windows, VMS-Samba E serving a share to Windows with the mail "database").  It works fine.   I I've asked before, but I'll ask again - will Firefox/Thunderbird replace   Mozilla on VMS in the future?    ------------------------------  % Date: Wed, 13 Sep 2006 09:40:24 -0400 , From: Hoff Hoffman <hoff-remove-this@hp.com>& Subject: Re: MP Synchronization ISSUES* Message-ID: <45080a44@usenet01.boi.hp.com>   Neil Rieck wrote:   K > If you're running multiple CPUs you will notice a performance boost when  M > only upgrading from 7.3-1 to 7.3-2. Prior to 7.3-2 many internal processes  N > erroneously serialized on an internal flag called IOLOCK8 which limited SMP  > scalability.  M    There wasn't anything particularly "erroneous" about the IOLOCK8 spinlock  P synchronization and the associated activity, that's how OpenVMS was designed to E work, and it's the SMP direct descendant of the IPL8 synchronization.   Q    What happened at V7.3-2 was that the on-going performance work found that the  L various pieces that were synchronizing on IOLOCK8 could be split into finer H granularity, and substantially reducing the contention on that spinlock.  O    IOLOCK8 is the traditional main system data structure lock, and -- prior to  O the V7.3-2 changes -- a whole lot of the OpenVMS internal data structures were  & protected by that particular spinlock.  J    As we've added tools (the ssl system service logging, the spl spinlock M tracing, etc) we've identified areas of contention or of heavy activity, and  P have targeted these for work.  As is the case with application performance, you P can be surprised what a tracing will tell you -- tools such as DECset PCA, DTM, Q and SCA can provide insight into what the application code is actually doing and  O where it is spending its time, and the analogous mechanisms added into OpenVMS   provided similar insight.    ------------------------------  % Date: Wed, 13 Sep 2006 14:56:28 -0400 , From: Hoff Hoffman <hoff-remove-this@hp.com>& Subject: Re: MP Synchronization ISSUES* Message-ID: <45085459@usenet01.boi.hp.com>   BRANDON, JOHN M wrote:% > Hoff, to answer your questions  ...  > P > But first, we did a cluster shutdown and startup - this seems to have resolvedP > the MP Synch problem (for now)... the cluster had been online 120+ days.  ThisA > leads me in the direction of application and memory management.   @    Could be.  Some sort of resource starvation or resource leak?  
 >> Clustered?  > O > The servers are clustered using 100 Mbit (private VLAN) and Gigabit (fiber).  + > The Gigabit provides access to our users.   M    Gigabit is also where the locking is.  You might try looking at where the  N locks are mastered, and at what nodes are participating -- these are the lock ! and dlock activities, at a start.   I >>    What happens when you temporarily drop from 4 CPUs down to 1 or 2?  G >> (STOP/CPU your way down, for purposes of testing.)  Do you see a big  >>  drop-off in MPSYNC?  > N > Have not done this - I suspect this will terminate jobs currently executing,) > correct?  If not, then I will try this.   Q    You should be able to remove the processors "hot"; we toss CPUs around within  K the Galaxy all the time, for instance.  If this is a production server and  O you're as paranoid as I can get in such an environment and you can reboot, you  ( can also configure the CPUs out at boot.  . > It seems that CPU is the most used resource.  L    You'll unfortunately have to look behind that, at what the processes are & doing, and what code-paths are active.   ... K >>    What I generally end up doing here is looking at what the particular  & >> applications are doing.  In detail. > N > I have noted that when the system is running FOCUS (and only FOCUS multiple N > batch jobs usually <10) the MP synch shoots up.  As soon as the applications0 > finish the MP synch goes away.  Hmmm... FOCUS?    M    I'm not familiar with what FOCUS is doing internally -- some of the tools  M that have been discussed in this thread were implemented to allow us to peer  O "inside" an application, and see what it's up to.  System service logging, the  Q spinlock tracing, etc.  But your OpenVMS version is unfortunately too far back...    ------------------------------  % Date: Wed, 13 Sep 2006 09:48:17 -0400 , From: Hoff Hoffman <hoff-remove-this@hp.com>' Subject: Re: mtools, specifically mcopy * Message-ID: <45080c1d@usenet01.boi.hp.com>   Paul Sture wrote:   K > I've got enough cables available, but Macs don't come with a serial port  @ > anymore (do PCs still?), I too took the route of burning a CD.  M    As for PC or Mac, it varies by box.   For those boxes that lack it, an IP  O terminal server (for the console), or USB serial dongle (for the "client") can  
 be useful.  N    A terminal server is often a cheap remote console management server, FWIW. I Once you have and use a remote console, it's difficult to go back to the  J hard-wired serial console port.   And various of the terminal servers can A generate BREAK signals up the serial line -- which can be useful.   Q    If you DO choose to use a terminal server and thus connect your console(s) to  Q your network, do ensure you have protected access appropriately for your network  M and the users of your network.  Being the console, it is effectively a fully  & privileged user of the OpenVMS system.  Q    Integrity boxes come with built-in network management consoles on most boxes,  N while these "MP" widgets -- "Management Processor" -- are options on a few of O the low-end boxes.  (And they're well worth having, regardless -- this for the  M integrated Radeon 7000-class graphics and for the remote management alone...)    ------------------------------  % Date: Wed, 13 Sep 2006 17:30:56 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ' Subject: Re: mtools, specifically mcopy , Message-ID: <45087886.B3ACE14F@teksavvy.com>   Hoff Hoffman wrote: R >    Integrity boxes come with built-in network management consoles on most boxes,O > while these "MP" widgets -- "Management Processor" -- are options on a few of  > the low-end boxes.      ? While I used to be philosophically against the use of TCPIP for H consoles, I think I started to turn around when I got my first DSL modemH which had a TCPIP stack that was quite fully features, complete with FTPB , TELNET, PING, traceroute etc. (and yes, this is just a modem :-)  F ROM based TCPIP stancks have become quite reliable enough that you canL start to trust them to be available all the time to access a system console.  G In my case though, I would probably want to have at least some PDA with B ethernet capability, or some terminal with its own ROM based TCPIPH interface that I could use to connect to the system console before beingB ready to ditch the serial port for the system consoles.  (aka: theH equivalent of a VT terminal that you know will work without requiring itE to load its software from some other place).  In the case of terminal G servers, if the terminal server giving you access to a console requires G it loads its software from a host, then after a power failure, you have E no way to access the console because the system won't boot unless you B type the "B" command, and you can't type the "B" command until theG terminal server is up, and the terminal server is waiting for system to 1 boot before its own MOP requests can be answered.    ------------------------------  % Date: Wed, 13 Sep 2006 14:08:43 -0400 2 From: "Stanley F. Quayle" <squayle@insight.rr.com>% Subject: Re: Need to read a TK50 tape 9 Message-ID: <450810EB.4425.3A262B@squayle.insight.rr.com>   ) On 13 Sep 2006 at 10:38, tadamsmar wrote: E > I had someone come by an ask me how they could get data off of what F > appears to be a TK50 tape.   We don't have any machines left to read > that.   , I provide such a service.  Please check out:  &   http://www.stanq.com/conversion.html  
 --Stan Quayle  Quayle Consulting Inc.  
 ----------8 Stanley F. Quayle, P.E. N8SQ  Toll free: 1-888-I-LUV-VAX3 8572 North Spring Ct., Pickerington, OH  43147  USA < stan-at-stanq-dot-com   http://www.stanq.com/charon-vax.html) "OpenVMS, when downtime is not an option"    ------------------------------  % Date: Wed, 13 Sep 2006 17:04:26 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> % Subject: Re: Need to read a TK50 tape , Message-ID: <45087251.C2A1205B@teksavvy.com>   tadamsmar wrote: > E > I had someone come by an ask me how they could get data off of what F > appears to be a TK50 tape.   We don't have any machines left to read > that.     F If you can ship the tape to me along with a good chocolate bar, I'd do. this for you. I can read up to CompacTape III.F (I = TK50, II = TK70 III=first generation DLT). You could then FTP the data back to your host.   G I am in Montreal Canada. If you don't find other closer offers, you can 5 contact me via email at jfmezei at vaxination dot ca.    ------------------------------  % Date: Wed, 13 Sep 2006 19:11:17 -0400 3 From: "Richard B. Gilbert" <rgilbert88@comcast.net> % Subject: Re: Need to read a TK50 tape : Message-ID: <GNOdnc7hgY-FDZXYnZ2dnUVZ_s-dnZ2d@comcast.com>   tadamsmar wrote:  E > I had someone come by an ask me how they could get data off of what F > appears to be a TK50 tape.   We don't have any machines left to read > that.  > I > I wonder where I could find a machine that would read it.  I am located  > in Chapel Hill NC. >   G Give Chris Muller a call: (212) 344-0474 and tell him I sent you.   He  I specializes in recovering data from old/weird media; he keeps an amazing  G collection of old hardware and software used both to recover data from  G strange media and to recover data in strange formats.  If your tape is  F still readable he should be able to put the data on the media of your  choice.    ------------------------------  % Date: Wed, 13 Sep 2006 16:21:47 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>  Subject: Re: SYS$LANGUAGE , Message-ID: <45086855.C369F934@teksavvy.com>   Syltrem wrote:	 > Hello !    Allo !  D > I'm looking for info on how to setup a new language in VMS (define > SYS$LANGUAGE FRENCH)  A My guess is that you need to find a french language kit for VMS.    F In the SPL for VAX, only ALLIN1 seems to be available in french.  So IF suspect that the VMS operating system language options would come with* the VMS CD and not the layered product CD.  G I know it used to be available in french (done at Valbonnes France with H some work done by the Digital Montral office). Not sure if VMS is still1 produced with the french language variant though.    ------------------------------  % Date: Wed, 13 Sep 2006 14:46:17 -0400 , From: Hoff Hoffman <hoff-remove-this@hp.com> Subject: Re: SYS$LANGUAGE * Message-ID: <450851f5@usenet01.boi.hp.com>   Syltrem wrote:' > I can't find my OpenVMS Master Index.   "    AFAIK, it's no longer produced.  % > Apparently it is not online either.   O    I tend to use www.google.com, with the keyword site: to restrict the search  , to the URL for the documentation web server.  E > I'm looking for info on how to setup a new language in VMS (define   > SYS$LANGUAGE FRENCH) > L > I have an application that would like the logical name changed to display O > messages in the user's language, but when I change the setting, other things   > bomb out.  ...  > $ helpe/mess %LIB-W-ENGLUSED* > %LIB-E-ACTIMAGE, error activating image * > $1$DGA100:[SYS0.SYSCOMMON.][SYSLIB]MSGHL > P$FRENCH.EXE;  > -RMS-E-FNF, file not found* > %LIB-E-ACTIMAGE, error activating image * > $1$DGA100:[SYS0.SYSCOMMON.][SYSLIB]MSGHL > P$FRENCH.EXE;  > -RMS-E-FNF, file not found    O    Unfortunately, that's been the behaviour for a while now within the default  P environment.  Circa V6.2 is when I first ran into that case.  The pieces needed Q to fully enable a particular language are not typically shipped in the base kit.  P   Without the MSGHLP$FRENCH image around, for instance, you can DEFINE [/table] M [/mode] MSGHLP$FRENCH to MSGHLP$ENGLISH to suppress the error.  There may be  J (are?) a few other troublespots, if you don't have the local language kit Q loaded.  (The regional/local folks will know if and what languages are available  3 in your particular area, I don't know that detail.)   F    The default mechanism used to start the language-specific tools is:  "      $ DEFINE SYS$LANGUAGES FRENCH"      $ @SYS$MANAGER:LIB$DT_STARTUP   ------------------------------  % Date: Wed, 13 Sep 2006 13:49:08 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 0 Subject: Re: VMS support goes to India next week9 Message-ID: <mKmdnc02aqgi35XYnZ2dnUVZ_v2dnZ2d@libcom.com>    David Mathog wrote:  > Rich Jordan wrote: > H >> It ended up taking over 2 hours on the phone (one continuous call butH >> forwarded several times) PLUS the intervention of the distributor ourF >> service contracts are handled through to convince them that yes, in; >> fact, that system was under a hardware support contract.  > H > If HP service sucks that bad cancel the service contract and take your > business elsewhere.  > 
 > Regards, >  > David Mathog  D Got to agree.  If you're willing to still give them the money after ? getting PC type service, then you're the cause of such service   continuing to exist.  H When someone you can barely understand insists that you must go through I all the steps they have on some 'cheat sheet' (which they probably don't  G understand themselves) even though you're trying to tell them that you  C already know what the problem is, I get the feeling that the whole  0 purpose is to get you to hang up in frustration.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Wed, 13 Sep 2006 21:08:30 +0300 ; From: "Guy Peleg" <guy.peleg@remove_this_header@bruden.com> 0 Subject: Re: VMS support goes to India next week9 Message-ID: <45083c19$0$19717$88260bb3@free.teranews.com>   4 "David Mathog" <mathog@caltech.edu> wrote in message% news:ee9amb$8qg$1@naig.caltech.edu...  > Rich Jordan wrote: > I > > It ended up taking over 2 hours on the phone (one continuous call but I > > forwarded several times) PLUS the intervention of the distributor our G > > service contracts are handled through to convince them that yes, in < > > fact, that system was under a hardware support contract. > H > If HP service sucks that bad cancel the service contract and take your > business elsewhere.    couldn't agree more    BRUDEN-OSSG '                  On-Shore Systems Group    http://www.brudenossg.com    ;-)    Guy    > 
 > Regards, >  > David Mathog       --  = Posted via a free Usenet account from http://www.teranews.com    ------------------------------    Date: 13 Sep 2006 12:45:47 -0700$ From: "Ed Wilts" <ewilts@ewilts.org>0 Subject: Re: VMS support goes to India next weekC Message-ID: <1158176747.189389.207520@d34g2000cwd.googlegroups.com>    etmsreec@yahoo.co.uk wrote: H > I've taken to logging calls electronically on ITRC (was about to write > AES!)    Give me back DSNlink!     	    .../Ed    ------------------------------  % Date: Wed, 13 Sep 2006 15:51:13 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Re: VMS support goes to India next week, Message-ID: <45086130.88BBAFC4@teksavvy.com>   Neil Rieck wrote:  > L > Conspiracy Theory: Patricia Dunn antics are published to cover up the fact, > that "VMS support goes to India next week"  H HP doesn't own VMS. I think Compaq let the VMS trademark lapse and it isC now owned by different outfits. So if VMS support goes to India, it F cannot possibly be related to our beloved operating system :-) :-) :-)  D In reality though, the HP board is probably unaware of VMS. If it isD just VMS going to India, it wouldn't be newsworthy enough to warrantA such a conspiracy theory. If HP-UX goes to India too, it might be & important enough for some distraction.  E In the end, like for Dell, when customers start to complain about the K support folks being hard to understand, they'll have to repatriate support.   F And interestingly, such a move is rather stupid because India can onlyD support certain countries because of language barrier. They may knowF english just well enough to answer phone calls, but they can't supportG people in French, Spanish, Italian etc etc.   How many VMS call centres  are there around the world ?   ------------------------------  % Date: Wed, 13 Sep 2006 13:02:40 -0700 * From: "Tom Linden" <tom@kednos-remove.com>0 Subject: Re: VMS support goes to India next week) Message-ID: <op.tft1yqk4tte90l@hyrrokkin>   . On Wed, 13 Sep 2006 12:51:13 -0700, JF Mezei  % <jfmezei.spamnot@teksavvy.com> wrote:    > Neil Rieck wrote:  >>J >> Conspiracy Theory: Patricia Dunn antics are published to cover up the   >> fact - >> that "VMS support goes to India next week"  > J > HP doesn't own VMS. I think Compaq let the VMS trademark lapse and it isE > now owned by different outfits. So if VMS support goes to India, it H > cannot possibly be related to our beloved operating system :-) :-) :-) > F > In reality though, the HP board is probably unaware of VMS. If it isF > just VMS going to India, it wouldn't be newsworthy enough to warrantC > such a conspiracy theory. If HP-UX goes to India too, it might be ( > important enough for some distraction. > G > In the end, like for Dell, when customers start to complain about the F > support folks being hard to understand, they'll have to repatriate  
 > support.  J I don't think support for their servers went off shore.  I have always had6 xcellent service from them, and it was all stateside. > H > And interestingly, such a move is rather stupid because India can onlyF > support certain countries because of language barrier. They may knowH > english just well enough to answer phone calls, but they can't supportI > people in French, Spanish, Italian etc etc.   How many VMS call centres  > are there around the world ?       --  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Wed, 13 Sep 2006 16:33:14 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Re: VMS support goes to India next week, Message-ID: <45086B03.1EAEBE59@teksavvy.com>   Rich Jordan wrote:I > place the accent) it took 25 minutes to convince him that yes, in fact, C > the tape drive is not working, and yes in fact we know what we're G > doing, and yet we did try this, that, and hte other standard recovery  > method...     B Once they move to script reading biological automatons, they oftenE program the support folks to filter out calls unless the customer can H really convince you that he has a real problem. This is done on a policyD level, not at the individual person's level. Whether it is in India,G Australia or California, if the policy is set by management, the drones  just put it in effect.  A Remember that to bean counters, those pesky call centres are cost F centres. Bean counters don't realise that those pesky call centres areC what bring in all the support contracts and mega revenus. And for a D company like HP, it is very easy to view "support contracts" more asG some profitable insurance scheme where the store salescritter convinces E you to dish out an extra $90 for a 3 year warrantee knowing full well H that the odds of ever needing that extended warrantee are extremely low.  E So, for outfits that think that way, they will love to sell you those F support contracts without an expectation that you'll actually make use@ of the support you're paying for. Hence, it is easy to decide toE downgrade the call centre which won't be needed by customers who just 4 pay for comfort of knowing they have some insurance.   ------------------------------  % Date: Wed, 13 Sep 2006 16:50:09 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Re: VMS support goes to India next week, Message-ID: <45086EFA.9691215C@teksavvy.com>   David Mathog wrote: H > If HP service sucks that bad cancel the service contract and take your > business elsewhere.     F But there is a big danger here: reduce the service contract revenus atF HP, and it is the perfect opportunity for HP to just decalre VMS dead.  E Remember that we have to work to convince HP that it is worth porting D VMS beyond IA64 within the next year or two. A sharp drop in service revenus won't help this.   ------------------------------  % Date: Wed, 13 Sep 2006 17:01:35 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Re: VMS support goes to India next week, Message-ID: <450871A7.B4E20BE3@teksavvy.com>   Guy Peleg wrote:
 > BRUDEN-OSSG ) >                  On-Shore Systems Group   G When Guido announced he was moving there, and including the name change F issue, I remember thinking/writing about "On Shore" being the opposite of "Off Shoring".   F In hindsight, it looks like they already knew HP was about to offshoreH VMS support. Seems to me like there are more leaks at HP than Patty Dunn would admit.  F Perhaps Terry Shannon is still active in passing information via a new plane of existance :-)   ------------------------------  % Date: Wed, 13 Sep 2006 17:20:13 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Re: VMS support goes to India next week, Message-ID: <45087604.D3C99EDB@teksavvy.com>   Tom Linden wrote: I > > In the end, like for Dell, when customers start to complain about the   L > I don't think support for their servers went off shore.  I have always had8 > xcellent service from them, and it was all stateside.    D Dell experimented with offshore support or their servers and quickly1 went back to USA based support due to complaints.   D However, if you treat support as a call centre commodity that can beD switched at will, it defeats the purpose. You want to have more thanH just script readers who answer the phone, you want folks who really knowE their stuff and can deal with issues that are not in the manuals that F the customers already have. And that is not a commodity you can switchG at will to the lowest cost call centre in the USA, canada, China, India  or Nimibia.   E When I signed up with my mobile phone company, they had just started, C and their call centre folks were in direct contact with the network B folks and they really knew their stuff and had access to plenty ofH information. As they grew, they added layers to insulate the people fromG the call centre, eventually outsources them to some outfit that provide E them with scripts of questiosn to ask and they end up having the same E user manual for handsets that we already have, so they cannot provide 0 one with more information than you already know.    F If I ran a *really* important VMS site, Id probably want Hoff's directG phone number if I were to pay for support. Wasting time fighting script ' operated drones would not be an option.    ------------------------------  % Date: Wed, 13 Sep 2006 17:21:33 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> 0 Subject: Re: VMS support goes to India next week< Message-ID: <450874be$0$24187$9a6e19ea@news.newshosting.com>  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  & news:450871A7.B4E20BE3@teksavvy.com... > Guy Peleg wrote: [...snip...] > H > In hindsight, it looks like they already knew HP was about to offshoreJ > VMS support. Seems to me like there are more leaks at HP than Patty Dunn > would admit. > H > Perhaps Terry Shannon is still active in passing information via a new > plane of existance :-) > I As Sue suggested on INFO-VAX today, theinquirer.net does not have a very  < good track record so maybe this is just an unfounded rumour.  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  % Date: Wed, 13 Sep 2006 17:58:21 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Re: VMS support goes to India next week, Message-ID: <45087EF2.4C9A838E@teksavvy.com>   Neil Rieck wrote: J > As Sue suggested on INFO-VAX today, theinquirer.net does not have a very> > good track record so maybe this is just an unfounded rumour.  G Sue's message hasn't made it to comp.os.vms yet. (has it for anyone ?).   F This could have also been a trial balloon leaked on purpose to see theH reaction, after which HP might decide not to go ahead with moving of VMS support to India or wherever.     B So the inquirer would still be "right" even though its predictionsB wouldn't have come true and would have, in the end, contributed toK helping save VMS by ensuring those plan to move to india didn't go through.   F Somone really need to take Mr Peleg out to a bar, give him a few beersG (is he old enough for that ? :-) and find out what is REALLY happening.    ------------------------------  % Date: Wed, 13 Sep 2006 20:35:22 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 0 Subject: Re: VMS support goes to India next week9 Message-ID: <0dGdnToKzvJoPJXYnZ2dnUVZ_oWdnZ2d@libcom.com>    Neil Rieck wrote: = > "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  ( > news:450871A7.B4E20BE3@teksavvy.com... >> Guy Peleg wrote:  > [...snip...]I >> In hindsight, it looks like they already knew HP was about to offshore K >> VMS support. Seems to me like there are more leaks at HP than Patty Dunn  >> would admit.  >>I >> Perhaps Terry Shannon is still active in passing information via a new  >> plane of existance :-)  >>K > As Sue suggested on INFO-VAX today, theinquirer.net does not have a very  > > good track record so maybe this is just an unfounded rumour.  H What else would an HP person say when news is leaked prematurely and/or B would be detrimental to HP?  Not knocking Sue.  Just her employer.  H When you report rumors, yeah, some reports are false.  But The Inquirer # also has been right on many issues.   G I didn't see the post by Sue.  Did she deny the move to India, or just  < point out some discrepancies in The Inquirer's track record.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Wed, 13 Sep 2006 20:38:09 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 0 Subject: Re: VMS support goes to India next week9 Message-ID: <0dGdnTUKzvIGP5XYnZ2dnUVZ_oWdnZ2d@libcom.com>    JF Mezei wrote:  > Neil Rieck wrote: K >> As Sue suggested on INFO-VAX today, theinquirer.net does not have a very ? >> good track record so maybe this is just an unfounded rumour.  > I > Sue's message hasn't made it to comp.os.vms yet. (has it for anyone ?).  > H > This could have also been a trial balloon leaked on purpose to see theJ > reaction, after which HP might decide not to go ahead with moving of VMS > support to India or wherever.  >  > D > So the inquirer would still be "right" even though its predictionsD > wouldn't have come true and would have, in the end, contributed toM > helping save VMS by ensuring those plan to move to india didn't go through.  > H > Somone really need to take Mr Peleg out to a bar, give him a few beersI > (is he old enough for that ? :-) and find out what is REALLY happening.   " I've been considering those beers.  G But in his new position, getting HP pissed off isn't the best thing to  E do.  Even if some juicy tidbits turned up, could they be used if the  @ result would harm a third party providing services to VMS users?   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Wed, 13 Sep 2006 20:51:55 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Re: VMS support goes to India next week, Message-ID: <4508A796.4555ED86@teksavvy.com>   Dave Froble wrote:$ > I've been considering those beers. > H > But in his new position, getting HP pissed off isn't the best thing toF > do.  Even if some juicy tidbits turned up, could they be used if theB > result would harm a third party providing services to VMS users?    H Say that after a few beers, Guido were to tell you that they have infactF looked at a port to the 8086, but La Carly had blocked it, Hurd hasn'tH been convinced and that perhaps getting many customers to ask Hurd mightG unlock the process.  You can't release that info to the public, but you G could mount some campaign to get people to write letters to Hurd urging  a port of VMS to the 8086.  C This would implicate no HP employees, would not appear to be as the  result of any leaks at all.   C There are many ways to use information which cannot be made public.    ------------------------------  % Date: Wed, 13 Sep 2006 20:56:21 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> 0 Subject: Re: VMS support goes to India next week< Message-ID: <4508a71e$0$24198$9a6e19ea@news.newshosting.com>  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  & news:45087EF2.4C9A838E@teksavvy.com... > Neil Rieck wrote: K >> As Sue suggested on INFO-VAX today, theinquirer.net does not have a very ? >> good track record so maybe this is just an unfounded rumour.  > I > Sue's message hasn't made it to comp.os.vms yet. (has it for anyone ?).  > H > This could have also been a trial balloon leaked on purpose to see theJ > reaction, after which HP might decide not to go ahead with moving of VMS > support to India or wherever.  >  > D > So the inquirer would still be "right" even though its predictionsD > wouldn't have come true and would have, in the end, contributed toE > helping save VMS by ensuring those plan to move to india didn't go  
 > through. > H > Somone really need to take Mr Peleg out to a bar, give him a few beersI > (is he old enough for that ? :-) and find out what is REALLY happening.  >   L I hear you, but I prefer to believe Sue at this moment in time. She claimed 8 not know anything about it and I suspect it may be true.  M On a related note, in March 2006 I made my first call in 19 years to OpenVMS  L support. I phoned a published Quebec number, went through 2 levels of voice M jail then was routed to a Colorado tech who helped me within 9 minutes and I  L was never put on hold. (I know it was Colorado because I asked the tech why M he didn't present me with the usual French greetings). The cost of living is  M relatively low in Colorado so it doesn't make much sense to me to close this   center in favour of India.       ###   J In an unrelated point, last year my employer out-sourced customer support H for non-commercial clients. I've never heard a good customer experience K story relating to this change and we've lost a lot of customers (according  F to my friends and relatives who like to push my nose into this mess). I Management keeps repeating the mantra about saving money but no one ever  ( gets an honest comment on lost business.  G My point here is that my employer kept control of customer support for  J commercial clients. I'm pretty sure 99% of HP's customers are commercial, D government or military and I can't see these last two calling India.  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------   End of INFO-VAX 2006.504 ************************                                                                                                                                                                                                    RETR 2004_680.txt Y >>> 150 ASCII retrieve of /disk$misc/decus/info-vax/2004_680.txt (52538 bytes) started.A; >>> 226 Transfer completed.  51394 (8) bytes transferred.e <<< TYPE A >>> 200 Type A ok.
 <<< PASV@ >>> 227 Entering passive mode; use PORT (198,151,12,104,14,39) <<< RETR 2004_682.txt Y >>> 150 ASCII retrieve of /disk$misc/decus/info-vax/2004_682.txt (39670 bytes) started.A; >>> 226 Transfer completed.  38799 (8) bytes transferred.e <<< TYPE A >>> 200 Type A ok.
 <<< PASV@ >>> 227 Entering passive mode; use PORT (198,151,12,104,14,44) <<< RETR 2004_687.txt Y >>> 150 ASCII retrieve of /disk$misc/decus/info-vax/2004_687.txt (27010 bytes) started.A; >>> 226 Transfer completed.  25877 (8) bytes transferred.e <<< TYPE A >>> 200 Type A ok.
 <<< PASV@ >>> 227 Entering passive mode; use PORT (198,151,12,104,14,46) <<< RETR 2004_689.txt Y >>> 150 ASCII retrieve of /disk$misc/decus/info-vax/2004_689.txt (15172 bytes) started.A; >>> 226 Transfer completed.  14401 (8) bytes transferred.e <<< TYPE A >>> 200 Type A ok.
 <<< PASV@ >>> 227 Entering passive mode; use PORT (198,151,12,104,14,51) <<< RETR 2004_691.txt Y >>> 150 ASCII retrieve of /disk$misc/decus/info-vax/2004_691.txt (45392 bytes) started.A; >>> 226 Transfer completed.  44180 (8) bytes transferred.e <<< TYPE A >>> 200 Type A ok.
 <<< PASV@ >>> 227 Entering passive mode; use PORT (198,151,12,104,14,56) <<< RETR 2004_696.txt Y >>> 150 ASCII retrieve of /disk$misc/decus/info-vax/2004_696.txt (53312 bytes) started.A; >>> 226 Transfer completed.  52605 (8) bytes transferred.e <<< TYPE A >>> 200 Type A ok.
 <<< PASV@ >>> 227 Entering passive mode; use PORT (198,151,12,104,14,63) <<< RETR 2004_701.txt Y >>> 150 ASCII retrieve of /disk$misc/decus/info-vax/2004_701.txt (40032 bytes) started.A; >>> 226 Transfer completed.  39426 (8) bytes transferred.e <<< TYPE A >>> 200 Type A ok.
 <<< PASV@ >>> 227 Entering passive mode; use PORT (198,151,12,104,14,67) <<< RETR 2004_705.txt Y >>> 150 ASCII retrieve of /disk$misc/decus/info-vax/2004_705.txt (48982 bytes) started.A; >>> 226 Transfer completed.  47809 (8) bytes transferred.e <<< TYPE A >>> 200 Type A ok.
 <<< PASV@ >>> 227 Entering passive mode; use PORT (198,151,12,104,14,74) <<< RETR 2004_709.txt Y >>> 150 ASCII retrieve of /disk$misc/decus/info-vax/2004_709.txt (59028 bytes) started.A; >>> 226 Transfer completed.  58144 (8) bytes transferred.e <<< TYPE A >>> 200 Type A ok.