1 INFO-VAX	Wed, 19 May 2004	Volume 2004 : Issue 277       Contents:1 Re: Anyone here using products from this company? > Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info?????> Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info?????> Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info?????> Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info????? Booting over Fibre Channel Re: Booting over Fibre Channel Re: Copying tapes  Re: Copying tapes  Re: Copying tapes  Re: Copying tapes ) Re: Eastern Washington University project ) Re: Eastern Washington University project ) Re: Eastern Washington University project & Fw: VMS731_FIBRE_SCSI-V0600.DCX_AXPEXE$ HP users burned by EMC court victory LAT & Hobbiest VMS questions  Re: LAT & Hobbiest VMS questions  Re: LAT & Hobbiest VMS questions  Re: LAT & Hobbiest VMS questions  Re: LAT & Hobbiest VMS questions Re: longest uptime Re: longest uptime
 netbooting Re: netbooting OpenVMs Cluster  Re: OpenVMs Cluster > Re: OpenVMS v7.3-1 detach process creation - strange behaviour Re: Request for new SMTP Re: Request for new SMTP Re: Request for new SMTP! Re: SUN fails to advertise VMS... ! Re: SUN fails to advertise VMS... ! Re: SUN fails to advertise VMS... = Re: Switching from Process Software TCPware to TCPIP Services = Re: Switching from Process Software TCPware to TCPIP Services " Re: The next port for OpenVMS? ;-)" Re: The next port for OpenVMS? ;-)" Re: The next port for OpenVMS? ;-)" Re: The next port for OpenVMS? ;-)" Re: The next port for OpenVMS? ;-)" Re: The next port for OpenVMS? ;-)" Re: The next port for OpenVMS? ;-)( Re: Timestamp format stored in RMS file?" VMS731_FIBRE_SCSI-V0600.DCX_AXPEXE) Re: You'll never guess what HP advertised ) Re: You'll never guess what HP advertised ) Re: [OT]:  Maybe SCO is (partially) right ) Re: [OT]:  Maybe SCO is (partially) right ) Re: [OT]:  Maybe SCO is (partially) right ) Re: [OT]:  Maybe SCO is (partially) right ) Re: [OT]:  Maybe SCO is (partially) right ) Re: [OT]:  Maybe SCO is (partially) right ) Re: [OT]:  Maybe SCO is (partially) right , [OT]: HP earnings reports released yesterday  F ----------------------------------------------------------------------  % Date: Wed, 19 May 2004 16:44:41 +0100 9 From: Andrew Harrison <andrew_._remove_harrison@su_n.com> : Subject: Re: Anyone here using products from this company?0 Message-ID: <c8fvdc$mpb$1@new-usenet.uk.sun.com>   Dariush wrote:F > Could you please elaborate some more on the reasons why NetApp would# > not be recommended for databases?  >   / It entirely depends on what your DBMS is doing.   5 If performance absolutely is not an issue and you are 5 happy to expend quite a lot more cycles on the server  then NetApp is fine.  1 If performance is an issue then NetApp is a no no - for a number of reasons (with a few caveats).   . 1.	In general latency for I/O's will be longer+ 	for the NetApp based storage than it would . 	be either for SAN or direct attached storage.  6 	This is because IP stack and its underlying transport4 	and I am assuming you mean Gigabit are much heavier6 	weight than stack for direct or SAN attached storage.  8 	This for example would be highly disadvantageous if the8 	DBMS was doing OLTP for example with a large proportion 	of random writes.  : 2.	There is an additional load on the DBMS server required7 	to drive that stack, some rules of thumb say 1 Mhz per 9 	megabit or in otherwords most of one CPU on an Alpha for , 	to drive the newwork traffic to the NetApp.  > You can of course mitigate against some of this by using a NICA that supports TOE but that will probably still not get you parity $ with direct or SAN attached storage.   Regards  Andrew Harrison 7 > Please provide some reasonening so that I can verify.  >  > Thanks again.  > 
 > Thanks much  > c > brandon@dalsemi.com (John Brandon) wrote in message news:<04051315552652@dscis6-0.dalsemi.com>...  >  >>>http://www.netapp.com >>>  >>>Opinions? >>>  >>5 >>For Win/client and UNIX file services - no problem.  >>7 >>For database (batch processing) - I do not recommend.  >> >> >> >> >> >>J*o*h*n B*r*a*n*d*o*n  >>VMS Systems Administrator , >>firstname.lastname.spam.me.not@dalsemi.com   ------------------------------    Date: 19 May 2004 01:09:24 -0700' From: icerq4a@spray.se (David Svensson) G Subject: Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info????? < Message-ID: <734da31c.0405190009.647be6d@posting.google.com>   Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<c8dg6o$pig$1@new-usenet.uk.sun.com>...  > Jan van Mastbergen wrote:  > A > When OSF died a well deserved death Digital changed the name of C > OSF-1 to DECUNIX quickly followed by another rebranding to Tru64.    Why was it well deserved?    > Its now called HP-UX   No.    ------------------------------  % Date: Wed, 19 May 2004 10:04:39 +0100 9 From: Andrew Harrison <andrew_._remove_harrison@su_n.com> G Subject: Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info????? 0 Message-ID: <c8f7v8$enj$1@new-usenet.uk.sun.com>   David Svensson wrote:    > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<c8dg6o$pig$1@new-usenet.uk.sun.com>...  >  >>Jan van Mastbergen wrote:  >>A >>When OSF died a well deserved death Digital changed the name of C >>OSF-1 to DECUNIX quickly followed by another rebranding to Tru64.  >  >  > Why was it well deserved?  >   2 Because the motives for creating OSF were entirely0 bogus and because is set back the development of# UNIX to a point where NT creapt in.      >  >>Its now called HP-UX >  >  > No.    Yes  Regards  Andrew Harrison    ------------------------------  % Date: Wed, 19 May 2004 10:38:01 +0100 < From: "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk>G Subject: Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info????? * Message-ID: <c8f9q7$19ar$1@news.wplus.net>  F "Andrew Harrison" <andrew_._remove_harrison@su_n.com> wrote in message* news:c8f7v8$enj$1@new-usenet.uk.sun.com... > David Svensson wrote:  > % > > Andrew Harrison SUNUK Consultancy 8 <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message, news:<c8dg6o$pig$1@new-usenet.uk.sun.com>... > >  > >>Jan van Mastbergen wrote:  > >>C > >>When OSF died a well deserved death Digital changed the name of E > >>OSF-1 to DECUNIX quickly followed by another rebranding to Tru64.  > >  > >  > > Why was it well deserved?  > >  > 4 > Because the motives for creating OSF were entirely2 > bogus and because is set back the development of% > UNIX to a point where NT creapt in.  >  >  > >  > >>Its now called HP-UX > >  > >  > > No.  >  > Yes 	 > Regards  > Andrew Harrison   D NO. Please get your facts correct. HP-UX is a completly seperate andA distinct product, which hp had prior to their merger with Compaq.   $ Tru64 has NOT been renamed to HP-UX.   Alex   ------------------------------  % Date: Wed, 19 May 2004 12:03:28 +0100 9 From: Andrew Harrison <andrew_._remove_harrison@su_n.com> G Subject: Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info????? 0 Message-ID: <c8feu2$h4r$1@new-usenet.uk.sun.com>   Alex Daniels wrote:   H > "Andrew Harrison" <andrew_._remove_harrison@su_n.com> wrote in message, > news:c8f7v8$enj$1@new-usenet.uk.sun.com... >  >>David Svensson wrote:  >> >>$ >>>Andrew Harrison SUNUK Consultancy > : > <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message. > news:<c8dg6o$pig$1@new-usenet.uk.sun.com>... >  >>>>Jan van Mastbergen wrote:  >>>>C >>>>When OSF died a well deserved death Digital changed the name of E >>>>OSF-1 to DECUNIX quickly followed by another rebranding to Tru64.  >>>  >>>  >>>Why was it well deserved? >>>  >>4 >>Because the motives for creating OSF were entirely2 >>bogus and because is set back the development of% >>UNIX to a point where NT creapt in.  >> >> >> >>>>Its now called HP-UX >>>  >>>  >>>No. >> >>Yes 	 >>Regards  >>Andrew Harrison  >  > F > NO. Please get your facts correct. HP-UX is a completly seperate andC > distinct product, which hp had prior to their merger with Compaq.  > & > Tru64 has NOT been renamed to HP-UX. >   > So Tru64 hasn't been axed with its features such as TruCluster9 being injected into HP-UX for release sometime in the not  so immediate future ?   ? Unless that plan has changed very very recently I would suggest 6 that it is you who should be getting your facts right.    Has the plan of record changed ?   Regards  Andrew Harrison    > Alex >  >    ------------------------------    Date: 19 May 2004 07:23:26 -0700' From: dan.fabrick@srs.gov (Dan Fabrick) # Subject: Booting over Fibre Channel = Message-ID: <283bc75d.0405190623.546d24fe@posting.google.com>   E I am trying to boot my VMS 7.3-2 system from a Fibre channel attached B disk.  I was able to do a standalone backup to the FC disk from my> normal boot disk, but I seem to have run into a wall on how toC identify the FC disk for the boot command.  Anyone have an example?    TIA, Dan   ------------------------------  # Date: Wed, 19 May 2004 16:49:07 GMT 1 From: Michael Austin <maustin@firstdbasource.com> ' Subject: Re: Booting over Fibre Channel 2 Message-ID: <40AB9004.E949CFE8@firstdbasource.com>   >>> set auto_action halt >>> initD >>> wwidmgr -quickset -udid xxxx  !! where xxx is the LUN identifier >>> initD >>> set bootdef_dev dg*xxxx.*.*.*.*   !!where xxxx is LUN identifier. >>> set dump_dev dg*xxxx.*.*.*.*      !! dittoG >>> set boot_osflags y,0                       !! y = system root 0,1,2  etc...         Dan Fabrick wrote:  G > I am trying to boot my VMS 7.3-2 system from a Fibre channel attached D > disk.  I was able to do a standalone backup to the FC disk from my@ > normal boot disk, but I seem to have run into a wall on how toE > identify the FC disk for the boot command.  Anyone have an example?  > 
 > TIA, Dan   ------------------------------  % Date: Wed, 19 May 2004 11:40:35 +0100 - From: Roy Omond <Roy.Omond@BlueBubble.UK.Com>  Subject: Re: Copying tapes* Message-ID: <2h0ru1F7e029U1@uni-berlin.de>   David J. Dachtera wrote: > Roy Omond wrote: >  >>[snip]F >>I have never seen BACKUP (or any other method in *base* VMS) recoverG >>from parity errors on *any* helical-scan tape media (that's why these H >>specialised data recovery companies can charge lots of money for these	 >>cases).  >  > 1 > DLT is "Linear" (serpentine), not helical-scan.   C OK.  But the point remains:  I have never seen BACKUP (or any other C method in *base* VMS) recover from parity errors on *any* DLT media  (that's why etc.)   	 Roy Omond  Blue Bubble Ltd.   ------------------------------  % Date: Wed, 19 May 2004 11:46:38 +0100 - From: Roy Omond <Roy.Omond@BlueBubble.UK.Com>  Subject: Re: Copying tapes* Message-ID: <2h0s9gF790q4U1@uni-berlin.de>   David J. Dachtera wrote:   > Roy Omond wrote:  > > > [...snip...] >> >> >>No, no, no ! >  > Yes! Yes! Yes!   This is getting silly.  I >>If your backups have been written to stay within the 32,767-byte limit,  >  >  > There's the rub.  8 But that was the pre-requisite for the method suggested.   > G >>then you don't need to futz around with foreign tapes as above.  Your I >>tape is an ANSI-standard labelled tape, so you can do as you originally  >>did, namely: >> >>        $ alloc MKx source >>        $ alloc MKy target% >>        $ mount/nowrite source xxxx % >>        $ mount         target yyyy ' >>        $ copy/log source:*.* target:  >  > J > ...except that conventional wisdom is to use the biggest /BLOCKSIZE thatH > BACKUP supports (usually in reference to DLT) to minimize inter-record= > gaps and maximize tape storage capacity. That's why I said:  >  >  >>David J. Dachtera wrote: >>	 >>>[snip] ; >>>If you have the option, re-write your backup tapes using : >>>/BLOCKSIZE=32256 to stay within RMS's 32767-byte limit.   Exactly.  Enough now.   	 Roy Omond  Blue Bubble Ltd.   ------------------------------  % Date: Wed, 19 May 2004 13:05:16 +0100 * From: Nic Clews <sendspamhere@[127.0.0.1]> Subject: Re: Copying tapes' Message-ID: <c8filb$hho$1@lore.csc.com>    Roy Omond wrote: >  > David J. Dachtera wrote: > > Roy Omond wrote: > > 
 > >>[snip]H > >>I have never seen BACKUP (or any other method in *base* VMS) recoverI > >>from parity errors on *any* helical-scan tape media (that's why these J > >>specialised data recovery companies can charge lots of money for these > >>cases).  > >  > > 3 > > DLT is "Linear" (serpentine), not helical-scan.  > E > OK.  But the point remains:  I have never seen BACKUP (or any other E > method in *base* VMS) recover from parity errors on *any* DLT media  > (that's why etc.)   E I've seen "recoverable media errors" for both DLT and DAT/8mm. Due to C parity or not I don't know but error recovery was activated and was  successful due to redundancy.   E However there are obviously limits, but you control that using /BLOCK G and /GROUP with /CRC. I'd agree that the bit density of DLT and Helical ? scan means that less physical area is involved to span a region H sufficient to defeat the (default) error recovery. I believe that's your point, and valid it is.    --  ? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences  nclews at csc dot com    ------------------------------    Date: 19 May 2004 07:30:40 -0600 From: briggs@encompasserve.org Subject: Re: Copying tapes3 Message-ID: <TcYsbnNBoEYJ@eisner.encompasserve.org>   W In article <2h09vbF7jk3oU1@uni-berlin.de>, Paul Sture <nospam@sture.homeip.net> writes: ! > briggs@encompasserve.org wrote: Z >> In article <2gu5joF6u1sdU1@uni-berlin.de>, Paul Sture <nospam@sture.homeip.net> writes: >>  A >>>I've adopted a 32,556 blocksize as standard practice, as when   >>   >>  M >> 32256 surely.  Though I think that 32556 is functionally identical (rounds : >> down to the next lower multiple of 512 which is 32256). >>   > A > Corrct, that was a typo. Specifying 32000 also rounds to 32556.  >  32256 surely.  :-)   	John Briggs   ------------------------------    Date: 19 May 2004 07:27:44 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 2 Subject: Re: Eastern Washington University project3 Message-ID: <iSFZiNvPcS29@eisner.encompasserve.org>   ^ In article <Oytqc.31170$6f5.2954270@attbi_s54>, "Dave Gudewicz" <k9jdk@NOSPAMarrl.net> writes:@ > Minor nit.  A VMS mainframe is about as common as hen's teeth. >   G    Haven't you ever seen a MicroVAX 3300 mainframe?  Yes, I know people F    who considered that model to be a mainframe.  And I've carried them    around my computer room.    ------------------------------    Date: 19 May 2004 09:13:35 -0700% From: whohe@whoever.com (DL Phillips) 2 Subject: Re: Eastern Washington University project= Message-ID: <af0dc2ea.0405190813.6cea8a68@posting.google.com>   n mail@sanface.com (SANFACE Software) wrote in message news:<8c682947.0405180752.3768e918@posting.google.com>...G > As budget restrictions and resources grow tighter, Eastern Washington 7 > http://www.ewu.edu/ University has chosen Txt2pdf-PRO = > http://www.sanface.com/txt2pdfPRO.html as a tool to enhance # > productivity and reduce expenses.      From Google:   Your search - openvms OR vms? site:http://www.sanface.com/txt2pdfPRO.html - did not match any 
 documents.   ------------------------------    Date: 19 May 2004 09:29:00 -07002 From: williamwebb@openvms-rocks.com (William Webb)2 Subject: Re: Eastern Washington University project= Message-ID: <bf98c417.0405190828.5fe9be8a@posting.google.com>   c "Dave Gudewicz" <k9jdk@NOSPAMarrl.net> wrote in message news:<Oytqc.31170$6f5.2954270@attbi_s54>... @ > Minor nit.  A VMS mainframe is about as common as hen's teeth. > 8 > "SANFACE Software" <mail@sanface.com> wrote in message9 > news:8c682947.0405180752.3768e918@posting.google.com... I > > As budget restrictions and resources grow tighter, Eastern Washington 9 > > http://www.ewu.edu/ University has chosen Txt2pdf-PRO ? > > http://www.sanface.com/txt2pdfPRO.html as a tool to enhance % > > productivity and reduce expenses.  > > J > > Each of our student, financial, and loan management enterprise systemsF > > generates nightly reports that are distributed across campus. WithE > > these paper reports comes a number of costs that we are trying to  > > reduce: " > > Cost of paper and its handling > > Cost of report distribution  > > Cost of additional copies  > > Cost of report handling $ > > Printer and hardware maintenance > > Physical storage > > Usability costs  > > A > > With Txt2pdf-PRO, we are able to reduce expenses and increase D > > productivity in each of the above areas. Txt2pdf-PRO runs on ourG > > mainframe OpenVMS system. However, as Txt2pdf-PRO is cross-platform I > > and can run on any of our servers, we are guaranteed that it will run I > > on future servers and operating systems and that we can scale its use G > > to an enterprise level as its functionality is leveraged to benefit " > > Eastern Washington University.  B This is the next item in the thread (which hasn't hit Google yet)-   > -----Original Message-----. > From: DL Phillips [mailto:whohe@whoever.com]( > Sent: Wednesday, May 19, 2004 12:14 PM > To: Info-VAX@Mvb.Saic.Com 4 > Subject: Re: Eastern Washington University project >  > 7 > mail@sanface.com (SANFACE Software) wrote in message  ; > news:<8c682947.0405180752.3768e918@posting.google.com>... ? > > As budget restrictions and resources grow tighter, Eastern   > Washington9 > > http://www.ewu.edu/ University has chosen Txt2pdf-PRO ? > > http://www.sanface.com/txt2pdfPRO.html as a tool to enhance % > > productivity and reduce expenses.  >  >  > From Google: >  > Your search - openvms OR vmsA > site:http://www.sanface.com/txt2pdfPRO.html - did not match any  > documents. >   @ DL- go to Sanface's main page and put VMS into the search box.     8 hits.    WWWebb   ------------------------------  % Date: Wed, 19 May 2004 12:31:28 -0400  From: norm.raphael@metso.com/ Subject: Fw: VMS731_FIBRE_SCSI-V0600.DCX_AXPEXE Q Message-ID: <OF6F6BDE86.BA66D3EA-ON85256E99.005A86D6-85256E99.005AD554@metso.com>   
 Hi George,  6 I believe there is still some confusion over this ECO. Is the file:  9 DEC-AXPVMS-VMS731_FIBRE_SCSI-V0600--4.PCSI-DCX_AXPEXE;1 - ,          3139/3141    5-MAY-2004 10:01:40.84   which yields  . DEC-AXPVMS-VMS731_FIBRE_SCSI-V0600--4.PCSI;1 -,          4880/4887   23-APR-2004 07:28:33.62  & still okay to use (my understanding) ?  2 Is it going to be restored to the retrieval sites?  = Or will there be another version to replace the held ECO (not  my understanding)?   -Norm K ----- Forwarded by Norm Raphael/WOR/Automation/METSO on 05/19/2004 12:27 PM  -----   J helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)  wrote on 05/19/2004 03:58:13 AM:  E > I see that the .TXT has been changed, reflecting the fact that this G > patch is no longer on hold, but the patch itself seems to be missing:  > I > May  7 12:56  text/plain       VMS731_FIBRE_SCSI-V0600.DCX_AXPEXE  50Kb B > May 18 16:43  text/plain       VMS731_FIBRE_SCSI-V0600.txt  67Kb > I > (VMS731_FIBRE_SCSI-V0600.DCX_AXPEXE decompresses to the old .TXT saying  > that the patch is on hold.)  > ? > Does anyone know when the patch will be taken off hold again?  > D > I signed up for the patch notification at OpenVMS.org; would it beI > possible to include layered products in the announcements?  (I see, for E > example, that there are new C and C++ patches for ALPHA available.)  >    ------------------------------  % Date: Wed, 19 May 2004 12:55:27 -0400  From: norm.raphael@metso.com- Subject: HP users burned by EMC court victory Q Message-ID: <OF97303FD8.73181747-ON85256E99.005C4787-85256E99.005D0762@metso.com>   L DQoNCg0KDQpIUCB1c2VycyBidXJuZWQgYnkgRU1DIGNvdXJ0IHZpY3RvcnkNCg0KQnkgS2V2aW4gL S29taWVnYSwgU2VuaW9yIE5ld3MgV3JpdGVyIGFuZCBKbyBNYWl0bGFuZCwgTmV3cyBEaXJlY3RvL cg0KMTggTWF5IDIwMDQgfCBTZWFyY2hTdG9yYWdlLmNvbQ0KDQoNClVzZXJzIG9mIEhld2xldHQgL UGFja2FyZCBDby4ncyBzdG9yYWdlIHZpcnR1YWxpemF0aW9uIHNvZnR3YXJlIGFyZSBpbiBmb3IgL YQ0Kcm91Z2ggcmlkZSBpbiB0aGUgY29taW5nIG1vbnRocyBhcyBIUCdzIGJlbGVhZ3VlcmVkIHN0L b3JhZ2UgZ3JvdXAgZGVhbHMNCndpdGggdGhlIG91dGNvbWUgb2YgYSBsYXdzdWl0IHRoYXQgY291L bGQgaGF2ZSBzZXZlcmUgY29uc2VxdWVuY2VzIGZvciBpdHMNCnByb2R1Y3RzIGluIHRoaXMgYXJlL YS4NCg0KDQpBIGp1cnkgaW4gdGhlIFUuUy4gRGlzdHJpY3QgQ291cnQgb2YgV29yY2VzdGVyLCBNL YXNzLiwgZGVjaWRlZCBNb25kYXkgdGhhdA0KSFAncyBPcGVuVmlldyBDb250aW51b3VzIEFjY2VzL cyBTdG9yYWdlIEFwcGxpYW5jZSAoQ0FTQSkgaW5mcmluZ2VzIG9uIHRocmVlDQpvZiBFTUMgQ29yL cC4ncyBjb3JlIHBhdGVudHMgcmVsYXRlZCB0byByZW1vdGUgYW5kIGxvY2FsIG1pcnJvcmluZy4gL Q0FTQQ0KZW5hYmxlcyBkYXRhIHJlcGxpY2F0aW9uIGJldHdlZW4gZGV2aWNlcyBmcm9tIGRpZmZlL cmVudCB2ZW5kb3JzIG9uIGEgU0FODQp1c2luZyBzbmFwc2hvdCwgRmlicmUgQ2hhbm5lbCBtaXJyL b3JzIGFuZCBJUC1iYXNlZCBtaXJyb3JzLg0KDQoNCkF0IHRoaXMgcG9pbnQsIFBhbG8gQWx0bywgL Q2FsaWYuLWJhc2VkIEhQIGlzIHVuc3VyZSBob3cgdGhlIHZlcmRpY3Qgd2lsbA0KaW1wYWN0IGl0L cyB1c2Vycy4gSFAgcHVibGljIHJlbGF0aW9ucyBtYW5hZ2VyIEJyaWFuIEdhcmFiZWRpYW4gc2FpL ZCwgIkF0DQp0aGlzIHRpbWUsIHdlIHJlYWxseSBkb24ndCBrbm93IHdpdGggYW55IGNlcnRhaW50L eSB3aGVuIHRoZSBkYW1hZ2VzIHBoYXNlDQp3aWxsIGJlIGNvbXBsZXRlZCBvciBpZiB0aGVyZSB3L aWxsIGJlIGFueSBpbXBhY3QgdG8gY3VycmVudCBjdXN0b21lcnMuIg0KDQoNCkhQIGlzc3VlZCBhL IHN0YXRlbWVudCBhYm91dCB0aGUganVyeSdzIGRlY2lzaW9uOiAiV2UgY29udGludWUgdG8gYmVsL aWV2ZQ0KdGhhdCBIUCdzIHByb2R1Y3RzIGRvIG5vdCBpbmZyaW5nZSB1cG9uIHRoZSBhc3NlcnRlL ZCBwYXRlbnQgY2xhaW0uIiBIUCBpcw0KaW4gdGhlIHByb2Nlc3Mgb2YgZGVjaWRpbmcgaWYgaXQgL d2lsbCBhcHBlYWwgdGhlIHZlcmRpY3QuDQpXZSBob3BlIHRvIGJlIGRvbmUgd2l0aCB0aGUgcHJvL ZHVjdCBieSB0aGUgdGltZSB0aGlzIHNoYWtlcyBvdXQNCk1hcmsgRGVjaw0KRGlyZWN0b3Igb2YgL aW5mcmFzdHJ1Y3R1cmUgdGVjaG5vbG9neSwgTmF0aW9uYWwgTWVkaWNhbCBIZWFsdGggQ2FyZCBTL eXN0ZW1zDQpJbmMuDQoNCg0KQW4gSFAgQ0FTQSB1c2VyIHdob20gU2VhcmNoU3RvcmFnZSBzcG9rL ZSB3aXRoIHdhcyB1bmZhemVkIGJ5IHRoZSBzaXR1YXRpb24uDQoiV2UgaG9wZSB0byBiZSBkb25lL IHdpdGggdGhlIHByb2R1Y3QgYnkgdGhlIHRpbWUgdGhpcyBzaGFrZXMgb3V0LCIgc2FpZA0KTWFyL ayBEZWNrLCBkaXJlY3RvciBvZiBpbmZyYXN0cnVjdHVyZSB0ZWNobm9sb2d5IGF0IE5hdGlvbmFsL IE1lZGljYWwgSGVhbHRoDQpDYXJkIFN5c3RlbXMgSW5jIChOTUhDKSBiYXNlZCBpbiBQb3J0IFdhL c2hpbmd0b24sIE5ZLiBEZWNrIHNhaWQgaGUgaXMgIm5vdA0KY29udmluY2VkIiBieSBIUCdzIGNvL bW1pdG1lbnQgdG8gQ0FTQSBhbmQgaGFzIGJlZW4gbG9va2luZyBlbHNld2hlcmUgZm9yDQpzaW1pL bGFyIHRlY2hub2xvZ3kgZm9yIHNvbWUgbW9udGhzLiAiUmhhcHNvZHksIHdoaWNoIHdhcyBzdXBwL b3NlZCB0byBiZSB0aGUNCm5leHQgZ2VuZXJhdGlvbiBvZiBDQVNBLCBpcyBvdmVyIHR3byB5ZWFyL cyBiZWhpbmQgcmVsZWFzZSwiIGhlIHNhaWQuIERlY2sNCmV4cHJlc3NlZCBoaXMgZGlzbWF5IHdpL dGggdGhlIHNpdHVhdGlvbiBhcyBDQVNBIHdhcyBhIGdvb2QgcHJvZHVjdCwgaGUNCnNhaWQuDQoNL Cg0KQW5vdGhlciBDQVNBIHVzZXIgd2Ugc3Bva2Ugd2l0aCwgd2hvIGRlY2xpbmVkIHRvIGJlIG5hL bWVkLCBzYWlkIGhpcyBjb21wYW55DQpoYXMgYmVlbiBsb29raW5nIGF0IHN3aXRjaGVzIHRvIHBlL cmZvcm0gdGhlIGZ1bmN0aW9ucyB0aGF0IENBU0EgcHJvdmlkZXMuDQoiVGhpcyBpcyBkZWZpbml0L ZWx5IGdvaW5nIHRvIHNwZWVkIHVwIG15IHRoaW5raW5nLCIgaGUgc2FpZC4NCg0KDQpFTUMncyBwL b3NpdGlvbg0KDQoNCkhvcGtpbnRvbiwgTWFzcy4sIGJhc2VkIEVNQyBmaWxlZCB0aGUgb3JpZ2luL YWwgY29tcGxhaW50IGFnYWluc3QNClN0b3JhZ2VBcHBzIGluIE9jdG9iZXIgMjAwMCwgYSBjb21wL YW55IEhQIHdlbnQgb24gdG8gYWNxdWlyZSBpbiBsYXRlIDIwMDENCmZvciAkMzUwIG1pbGxpb24uL IEVNQyBjbGFpbWVkIHRoYXQgU3RvcmFnZUFwcHMnIFNBTkxpbmsgYXBwbGlhbmNlIC0tIG5vdw0KL cmVmZXJyZWQgdG8gYnkgSFAgYXMgQ0FTQSAtLSBpbmZyaW5nZWQgb24gRU1DIHBhdGVudHMgcmVsL YXRlZCB0byBpdHMNClN5bW1ldHJpeCBSZW1vdGUgRGF0YSBGYWNpbGl0eSAoU1JERikgYW5kIFRpL bWVGaW5kZXIgc29mdHdhcmUgcHJvZHVjdHMuDQoNCg0KRU1DIHBsYW5zIHRvIHNlZWsgYW4gaW5qL dW5jdGlvbiBiYXNlZCBvbiBpdHMgY291cnQgd2luLCBidXQgaGFzIG5vdA0KZGV0ZXJtaW5lZCB3L aGF0IGZvcm0gdGhhdCBpbmp1bmN0aW9uIHdpbGwgdGFrZS4gRU1DIHNwb2tlc3dvbWFuIEFubmUgL UGFjZQ0Kc2FpZCBpdCdzIHRvbyBlYXJseSB0byB0ZWxsIHdoZXRoZXIgRU1DIHdpbGwgc2VlayBmL aW5hbmNpYWwgcmVzdGl0dXRpb24gb3INCndpbGwgbW92ZSB0byBzdG9wIEhQIGZyb20gc2VsbGluL ZyBpdHMgQ0FTQSBwcm9kdWN0IGFsdG9nZXRoZXIuICJJdCdzDQpwcmVtYXR1cmUgdG8gc3BlY3VsL YXRlIHdpdGggdGhlIGRlY2lzaW9uIGp1c3QgY29taW5nIGRvd24gTW9uZGF5LCIgc2hlDQpzYWlkL Lg0KDQoNCkFjY29yZGluZyB0byBIUCwgaXRzIENvbnRpbnVvdXMgQWNjZXNzIFN0b3JhZ2UgQXBwL bGlhbmNlIGlzIGEgInJlbGF0aXZlbHkNCmxvdy12b2x1bWUiIHByb2R1Y3QsIGFuZCB0aGUgY29tL cGFueSBwbGFucyAidG8gdGFrZSB3aGF0ZXZlciBzdGVwcyBhcmUNCm5lY2Vzc2FyeSB0byBtaW5pL bWl6ZSB0aGUgcG90ZW50aWFsIGltcGFjdCBvbiBleGlzdGluZyBIUCBTdG9yYWdlV29ya3MgQ0FTL QQ0KY3VzdG9tZXJzIGFuZCBjaGFubmVsIHBhcnRuZXJzLiIgQXQgb25lIHRpbWUsIEhQIHdhcyB0L YWxraW5nIGFib3V0DQpsaWNlbnNpbmcgdGhpcyBzb2Z0d2FyZSB0byBzd2l0Y2ggdmVuZG9ycywgL aW5jbHVkaW5nIEJyb2NhZGUsIGJ1dCB0aGVzZQ0KdGFsa3MgYXBwZWFyIHRvIGhhdmUgZ29uZSBiL eSB0aGUgd2F5c2lkZS4NCg0KDQpPbmUgaW5kdXN0cnkgZXhwZXJ0IHNhaWQgaGUgYmVsaWV2ZXMgL dGhlIGJlc3Qgb3V0Y29tZSBmb3IgdXNlcnMgd291bGQgYmUNCmZvciBIUCB0byBwYXkgRU1DIGFuL IGFncmVlZCB1cG9uIHN1bSBvZiBtb25leSB0byBtYWtlIHRoZSBpbmZyaW5nZW1lbnQNCmlzc3VlL cyBnbyBhd2F5LiAiSXQgd291bGQgbm90IGJlIGluIHRoZSBiZXN0IGludGVyZXN0cyBvZiBlaXRoL ZXIgY29tcGFueSB0bw0KZGlzcnVwdCB0aGUgb3BlcmF0aW9ucyBvZiBDQVNBIHVzZXJzLCIgc2FpL ZCBKb2huIFdlYnN0ZXIsIGZvdW5kZXIgYW5kDQpzZW5pb3IgYW5hbHlzdCBhdCB0aGUgRGF0YSBNL b2JpbGl0eSBHcm91cCBJbmMuLCBOYXNodWEsIE4uSC4NCg0KDQpTdGV2ZSBEdXBsZXNzaWUsIGZvL dW5kZXIgYW5kIHNlbmlvciBhbmFseXN0IHdpdGggdGhlIEVudGVycHJpc2UgU3RvcmFnZQ0KR3JvL dXAgSW5jLiwgTWlsZm9yZCwgTWFzcy4sIGRvZXNuJ3QgZXhwZWN0IHRoYXQgbW9uZXkgd2lsbCBjL aGFuZ2UgaGFuZHMgYXMNCmEgcmVzdWx0IG9mIEVNQydzIGNvdXJ0IHZpY3RvcnkuIEVNQyBoYXMgL ImdyYW5kZXIgYXNwaXJhdGlvbnMsIiBoZSBzYWlkLiAiSQ0KZnVsbHkgZXhwZWN0IHRoYXQgdGhpL cyBjb3VsZCBsZWFkIHRvIGJpZ2dlciB0aGluZ3M7IExpa2UgRU1DIHRyeWluZyB0byBzZWUNCmlmL IG90aGVycyBoYXZlIHZpb2xhdGVkIGl0cyBwYXRlbnRzIGFuZCBmb3JjaW5nIHRoZW0gdG8gbGljL ZW5zZSBmcm9tIEVNQyDigKYNCkF0IHRoZSBlbmQgb2YgdGhlIGRheSwgdGhlIGd1eSB3aXRoIHRoL ZSBtb3N0IGludGVsbGVjdHVhbCBwcm9wZXJ0eSBwYXRlbnRzDQp3aW5zLCIgRHVwbGVzc2llIHNhL aWQuDQoNCg0KSFAncyBmdXR1cmU/DQoNCg0KQXMgdGhpbmdzIHN0YW5kIHRvZGF5LCBIUCdzIHN0L b3JhZ2UgZ3JvdXAgYXBwZWFycyB0byBoYXZlIGl0cyBqb2IgY3V0IG91dA0KcmVidWlsZGluZyBpL dHMgcmVwdXRhdGlvbiBpbiB0aGUgc3RvcmFnZSBpbmR1c3RyeSwgYWNjb3JkaW5nIHRvIGFuYWx5L c3RzLg0KDQoNCkR1cmluZyBsYXRlIEZlYnJ1YXJ5IHRocm91Z2ggZWFybHkgQXByaWwgMjAwNCwgL V2FsbCBTdHJlZXQgZmlybSBSb2JlcnQuIFcNCkJhaXJkICYgQ28gSW5jLiBpbnRlcnZpZXdlZCBDL SU9zLCBDVE9zIGFuZCBJVCBtYW5hZ2VycyBmcm9tIDgxIG1pZHNpemVkIHRvDQpsYXJnZSBmaXJtL cy4gSXQgZm91bmQgdGhhdCB1c2VyIHBlcmNlcHRpb25zIGFib3V0IEhQIHdlcmUgbWl4ZWQsIGJ1L dCBnaXZlbg0KdGhlIG5lZ2F0aXZlIHNlbnRpbWVudCB0b3dhcmQgSFAgaW4gbGFzdCB5ZWFyJ3MgL c3R1ZHksIHJlbGF0ZWQgdG8gdGhlDQpDb21wYXEgbWVyZ2VyLCBhdHRpdHVkZXMgd2VyZSBpbXByL b3ZlZCBzbGlnaHRseS4NCg0KDQpBdCB0aGUgc2FtZSB0aW1lLCAiVGhlIG1hc3MgZXhvZHVzIG9mL IHNlbmlvciBleGVjdXRpdmVzIGluIEhQJ3Mgc3RvcmFnZQ0KZ3JvdXAgaGFzIGxlZnQgdGhlIGNvL bXBhbnkgbGlrZSBhIHJ1ZGRlcmxlc3Mgc2hpcCwiIHF1aXBwZWQgb25lIGFuYWx5c3Qgd2hvDQpyL ZXF1ZXN0ZWQgYW5vbnltaXR5LiBJbiB0aGUgcGFzdCB0d28geWVhcnMsIEhQIGhhcyBsb3N0IE1hL cmsgTGV3aXMsDQp3b3JsZHdpZGUgaGVhZCBvZiBtYXJrZXRpbmcgYW5kIGZvcm1hbGx5IGhlYWQgL b2YgQ29tcGFxJ3Mgc3RvcmFnZSBidXNpbmVzczsNCk1hcmsgU29yZW5zb24sIHZpY2UgcHJlc2lkL ZW50IG9mIHNvZnR3YXJlIGluIHRoZSBuZXR3b3JrIHN0b3JhZ2UgZGl2aXNpb247DQphbmQgbW9zL dCByZWNlbnRseSBIb3dhcmQgRWxpYXMsIGdlbmVyYWwgbWFuYWdlciBvZiBIUCBzdG9yYWdlLiBBL bmQgdGhlc2UNCndlcmUganVzdCB0aGUgZXhlY3V0aXZlcyB3aG8gZmxlZCB0byBFTUMuIEdyZWcgL U2NobWlkdCwgSFAncyB3b3JsZHdpZGUNCm1hbnVmYWN0dXJpbmcgbWFuYWdlciBmb3Igc3RvcmFnL ZSwgbGVmdCBzb21lIHRpbWUgYWdvIHRvIGpvaW4gYSBzdGFydHVwLg0KDQoNCkJvYiBTY2h1bHR6L LCB0aGUgY3VycmVudCBzZW5pb3IgdmljZSBwcmVzaWRlbnQgYW5kIGdlbmVyYWwgbWFuYWdlciBvL Zg0KbmV0d29yayBzdG9yYWdlIHNvbHV0aW9ucyBhdCBIUCwgZGVjbGluZWQgdG8gYmUgaW50ZXJ2L aWV3ZWQgZm9yIHRoaXMgc3RvcnkuDQoNCg0KQXNpZGUgZnJvbSB0aGUgbWFuYWdlbWVudCBpc3N1L ZXMgSFAgZmFjZXMsIGl0IG5vdyBoYXMgdG8gdW50YW5nbGUgaXRzDQp2aXJ0dWFsaXphdGlvbiBwL cm9kdWN0IGZyb20gdGhlIGNvdXJ0IGNhc2UganVzdCBhcyB0aGlzIHRlY2hub2xvZ3kgaGFzDQpnL YWluZWQgcmVhbCBhY2NlcHRhbmNlIGluIHRoZSBtYXJrZXRwbGFjZS4gIlZpcnR1YWxpemF0aW9uL IGlzIGJlY29taW5nIGENCmNvcmUgZmVhdHVyZSBvZiBzdG9yYWdlIGVudmlyb25tZW50cyBhbmQgL aW5mcmFzdHJ1Y3R1cmUgbWFuYWdlbWVudCwiIHNhaWQNCkphbWllIEdydWVuZXIsIHNlbmlvciBhL bmFseXN0IGF0IHRoZSBZYW5rZWUgR3JvdXAuIEluIG90aGVyIHdvcmRzLCB0aGUNCnRpbWluZyBj  b3VsZG4ndCBiZSB3b3JzZSBmb3IgSFAu   ------------------------------  % Date: Wed, 19 May 2004 10:18:12 -0500 % From: Neil Cherry <njc@wolfgang.uucp> % Subject: LAT & Hobbiest VMS questions . Message-ID: <slrncamufr.rb1.njc@wolfgang.uucp>  F Does Hobbiest VMS allow LAT? I've tried starting up LAT on my 3100 and I get errors.   - %SYSTEM-W-NOSUCHDEV, no such device available   > I get that 4 times (btw, I have DECNet IV running). Any ideas?   --  D Linux Home Automation         Neil Cherry        ncherry@comcast.net; http://home.comcast.net/~ncherry/               (Text only) = http://linuxha.sourceforge.net/                 (SourceForge) 8 http://hcs.sourceforge.net/                     (HCS II)   ------------------------------  % Date: Wed, 19 May 2004 17:56:44 +0200 , From: "Reinhard Eigner" <antispam@garnix.de>) Subject: Re: LAT & Hobbiest VMS questions / Message-ID: <c8g01b$plg$03$1@news.t-online.com>   8 "Neil Cherry" <njc@wolfgang.uucp> schrieb im Newsbeitrag( news:slrncamufr.rb1.njc@wolfgang.uucp...H > Does Hobbiest VMS allow LAT? I've tried starting up LAT on my 3100 and > I get errors.    Yes, LAT should work.   / > %SYSTEM-W-NOSUCHDEV, no such device available @ > I get that 4 times (btw, I have DECNet IV running). Any ideas?  . Did you edit the lat$systartup.com in any way?> I don't use LAT but as I read your question here I started it.   I got following:   $ @sys$startup:lat$startup= %RUN-S-PROC_ID, identification of created process is 0000011D   A I run DECnet Plus on a XP900. But I think it doesn't matter which 6 version of DECnet you run because it's a own protocol.   ------------------------------  % Date: Wed, 19 May 2004 11:14:12 -0500 % From: Neil Cherry <njc@wolfgang.uucp> ) Subject: Re: LAT & Hobbiest VMS questions . Message-ID: <slrncan1or.rn2.njc@wolfgang.uucp>  : On Wed, 19 May 2004 17:56:44 +0200, Reinhard Eigner wrote: > : > "Neil Cherry" <njc@wolfgang.uucp> schrieb im Newsbeitrag* > news:slrncamufr.rb1.njc@wolfgang.uucp...   > $ @sys$startup:lat$startup> >%RUN-S-PROC_ID, identification of created process is 0000011D  
 First thanks!   D DOH! I forgot to start LAT! OK, new problem. I started LAT and now IC get this (the 0 rating is bad and the Service responder looks bad):   E Node Name:   VAX                            LAT Protocol Version: 5.2  Node State:  On ) Node Ident:  .Welcome to OpenVMS VAX V6.1   H Incoming Connections:  Enabled              Incoming Session Limit: NoneH Outgoing Connections:  Enabled              Outgoing Session Limit: None Service Responder:     Disabled   E Circuit Timer (msec):        80             Keepalive Timer (sec): 20 D Retransmit Limit (msg):       8             Node Limit (nodes): None9 Multicast Timer (sec):       60             CPU Rating: 0  Maximum Unit Number:       9999    User Groups:     0-255 Service Groups:  0-255  3 Service Name     Status      Rating  Identification A VAX              Available      0 D  .Welcome to OpenVMS VAX V6.1    --  D Linux Home Automation         Neil Cherry        ncherry@comcast.net; http://home.comcast.net/~ncherry/               (Text only) = http://linuxha.sourceforge.net/                 (SourceForge) 8 http://hcs.sourceforge.net/                     (HCS II)   ------------------------------  # Date: Wed, 19 May 2004 16:50:40 GMT 1 From: Michael Austin <maustin@firstdbasource.com> ) Subject: Re: LAT & Hobbiest VMS questions 2 Message-ID: <40AB9061.1C7CC6B3@firstdbasource.com>   mc latcp  help        Neil Cherry wrote:  < > On Wed, 19 May 2004 17:56:44 +0200, Reinhard Eigner wrote: > > < > > "Neil Cherry" <njc@wolfgang.uucp> schrieb im Newsbeitrag, > > news:slrncamufr.rb1.njc@wolfgang.uucp... >  > > $ @sys$startup:lat$startup@ > >%RUN-S-PROC_ID, identification of created process is 0000011D >  > First thanks!  > F > DOH! I forgot to start LAT! OK, new problem. I started LAT and now IE > get this (the 0 rating is bad and the Service responder looks bad):  > G > Node Name:   VAX                            LAT Protocol Version: 5.2  > Node State:  On + > Node Ident:  .Welcome to OpenVMS VAX V6.1  > J > Incoming Connections:  Enabled              Incoming Session Limit: NoneJ > Outgoing Connections:  Enabled              Outgoing Session Limit: None! > Service Responder:     Disabled  > G > Circuit Timer (msec):        80             Keepalive Timer (sec): 20 F > Retransmit Limit (msg):       8             Node Limit (nodes): None; > Multicast Timer (sec):       60             CPU Rating: 0 ! > Maximum Unit Number:       9999  >  > User Groups:     0-255 > Service Groups:  0-255 > 5 > Service Name     Status      Rating  Identification C > VAX              Available      0 D  .Welcome to OpenVMS VAX V6.1  >  > --F > Linux Home Automation         Neil Cherry        ncherry@comcast.net= > http://home.comcast.net/~ncherry/               (Text only)f? > http://linuxha.sourceforge.net/                 (SourceForge)P: > http://hcs.sourceforge.net/                     (HCS II)   ------------------------------    Date: 19 May 2004 12:32:43 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)P) Subject: Re: LAT & Hobbiest VMS questionsl3 Message-ID: <I57r1uApz9kT@eisner.encompasserve.org>   V In article <slrncamufr.rb1.njc@wolfgang.uucp>, Neil Cherry <njc@wolfgang.uucp> writes:H > Does Hobbiest VMS allow LAT? I've tried starting up LAT on my 3100 and > I get errors.  > / > %SYSTEM-W-NOSUCHDEV, no such device availableu > @ > I get that 4 times (btw, I have DECNet IV running). Any ideas?  =    I would think you've missed some step in starting LAT.  It $    runs fine on my hobbyist systems.  ;    Are you running sys$startup:lat$startup.com during boot?e  ;    Did you put your setup in sys$startup:lat$systartup.com?s   ------------------------------    Date: 19 May 2004 04:35:48 -0700$ From: gspamtackett@yahoo.com (Galen) Subject: Re: longest uptime = Message-ID: <bdc65a53.0405190335.68fec294@posting.google.com>a  X Nic Clews <sendspamhere@[127.0.0.1]> wrote in message news:<c82at5$d3$1@lore.csc.com>...! > david20@alpha2.mdx.ac.uk wrote:h > >  > >o  > > >> What is a monthly reboot?* > > >> This is a VMS forum, not windows...
 > > >> ;-) > > >oF > > >Yeah, well, even in the VMS world, pesky app.'s can have resource
 > > >leaks...  > > >  > > >*SIGH*  > > M > > Usually when I've come across this monthly reboot phenonemon on VMS it is R > > because it has been recommnded by the Vendor and the Vendor has recommended itR > > because at some point they had a memory leak problem with the application on aP > > Unix platform. The leak on the Unix platform may itself have been fixed agesN > > ago but the advice to reboot has become set in stone and is applied to all$ > > systems the application runs on. > F > A system that has a weekly reboot (for standalone image backups) theG > operator commands are described as "IPLing" the system (not booting).y > F > No prizes for guessing the "partner in crime" system to this one ;-) > 0 > (Uh, oh, OK, Initial Program Load for the IBM) >   E At my old job in Sunnyvale, our operators and managers ;-} often usedgD to refer to a reboot of any system (from VMS to desktop PCs or Macs)? as a "deadstart." This terminology originated with the enormouseD CrayDesignedCruncher mainframes on which we ran the NOS/BE, NOS, and NOS/VE operating systems.)  @ 10 points if you can guess the name of my employer at that time.  E 100 points if you can tell me what building I worked in (it has since D been levelled and, in the immortal words of Douglas Adams, "replaced2 by something even more bizarre and inexplicable.")  C 1000 points if you can tell me the "program number" that designateda= the operation residing in that building. (This number was noteD considered particularly sensitive-you could find it in the corporate phone book.)   ------------------------------  % Date: Wed, 19 May 2004 09:31:52 -0700N3 From: Alan Frisbie <Usenet01REMOVE@Flying-Disk.com>l Subject: Re: longest uptimeM. Message-ID: <40AB8BF8.2020800@Flying-Disk.com>   Galen wrote:  E > 1000 points if you can tell me the "program number" that designatedt? > the operation residing in that building. (This number was notoF > considered particularly sensitive-you could find it in the corporate > phone book.)   949    ------------------------------  # Date: Wed, 19 May 2004 15:35:17 GMTp3 From: Michael Grunditz <michael.grunditz@telia.com>r Subject: netbootingS1 Message-ID: <1bfda1b14c.michael@privat.utfors.se>    Hi  @ I am going to netboot a Microvax 3000 from a vaxstation 9000-90.C Is there any availble documentation how to activate the mopd servero etc .. s     /Michael Grunditz2   ------------------------------    Date: 19 May 2004 12:33:37 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)o Subject: Re: netbootinga3 Message-ID: <lctAUkywqrJV@eisner.encompasserve.org>>  g In article <1bfda1b14c.michael@privat.utfors.se>, Michael Grunditz <michael.grunditz@telia.com> writes:e > Hi > B > I am going to netboot a Microvax 3000 from a vaxstation 9000-90.E > Is there any availble documentation how to activate the mopd servert	 > etc .. ,  ?    Use sys$manager:cluster_config.com and answer the questions.7   ------------------------------    Date: 19 May 2004 07:22:55 -0700" From: jutta.reichel@gmx.de (jutta) Subject: OpenVMs Cluster< Message-ID: <ec7e473.0405190622.77145268@posting.google.com>  4 We have a OpenVMS (Alpha) Cluster with 4 Satellites.C One of them is defect. We took another Client with Operating Systema< DEC UNIX. We changed the Hardware Address on the Server with Cluster_config. & The boot parameter on the new Client:  >>> os_type OpenVMS1 >>> ew0_protocols MOPn >>> boot_dev ewa0.0.0.14.0 >>> boot_osflags 0,0 >>> ewa0_inet_init  bootpa >>> pal VMS PALcode V1.20-14 >>> version V6-9-7  g5 We try to boot the new Client and we got the message:n >>> bo boot ewa0.0.0.3.0 -flags 0,0 Trying MOP bootd .... bootstrap failure     one of the other clients:w  >>> pal  VMS PALcode V5.65.2u  >>> version V6.9-4   0 Do we need to do somethings more on the server ? Is the firmware the wrong one?   Who can help us?    Jutta Juttay   ------------------------------  + Date: Wed, 19 May 2004 17:31:53 +0000 (UTC) - From: lewis@spyder.mitre.org (Keith A. Lewis)  Subject: Re: OpenVMs Cluster. Message-ID: <c8g5m8$34u$2@newslocal.mitre.org>   jutta.reichel@gmx.de (jutta) writes in article <ec7e473.0405190622.77145268@posting.google.com> dated 19 May 2004 07:22:55 -0700:-5 >We have a OpenVMS (Alpha) Cluster with 4 Satellites.eD >One of them is defect. We took another Client with Operating System= >DEC UNIX. We changed the Hardware Address on the Server with- >Cluster_config.' >The boot parameter on the new Client: d >>>> os_type OpenVMS >>>> ew0_protocols MOP >>>> boot_dev ewa0.0.0.14.0n >>>> boot_osflags 0,0i >>>> ewa0_inet_init  bootp >>>> pal VMS PALcode V1.20-14c >>>> version V6-9-7o > 6 >We try to boot the new Client and we got the message: >>>> b >boot ewa0.0.0.3.0 -flags 0,0  >Trying MOP boot >..... bootstrap failure  ? That's the message I get if the server is down, or ignoring me.o  E Are you running DECnet IV or V?  I know the commands for phase IV, to " double-check the hardware address:   $ MC NCP SHOW NODE (node) CHAR  F Also, you can narrow down the problem by doing a "REPLY/ENABLE" on theH server, then trying to boot again.  If the server gets the request there( will be an OPCOM message to that effect.  C Check ewa0_mode and make sure it's compatible with your hub/switch.-  0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------    Date: 19 May 2004 05:43:23 -07006 From: andrew.rycroft@intrinsitech.com (Andrew Rycroft)G Subject: Re: OpenVMS v7.3-1 detach process creation - strange behaviourR= Message-ID: <58ba0101.0405190443.3643b2bf@posting.google.com>4   Hi,-  ! Thank you for pointing this out. o  @ This problem is actually to be found in the Webes v4.3.2 OpenVMSB WCCPROXY kit. I never thought an HP installation kit would include such an elementary error.>   With regards Andrew    u norm.raphael@metso.com wrote in message news:<OF245048A6.87FEF3A1-ON85256E97.004D1836-85256E97.004D15DC@metso.com>....E > Possibly because your original process_name exceeds the limit of 15d
 > characters?i > F > andrew.rycroft@intrinsitech.com (Andrew Rycroft) wrote on 05/17/2004 > 09:39:49 AM: >  > > Hi,  > > E > > I have come across the following strange behaviour when trying toi  > > create a detached process :- > >s= > > The command procedure i.com creates a detached process :-e > >n > > $ type i.com1 > > $                                       run -e@ > >         /io_direct=300 /detac /process="Starting WCCProxy" -@ > >         /input=DKA200:[SYS0.SYSCOMMON.WEBES.HP.NODES.EDDIE1.8 > > SVCTOOLS.common.wccproxy.bin]wccproxydetachstart.com > > - B > >         sys$system:loginout.exe /priority=15 /page_file=296752	 > > $exite > >h! > > If I run it it aborts with :-  > >  > > $ @i.com* > > %RUN-F-CREPRC, process creation failed, > > -SYSTEM-F-IVLOGNAM, invalid logical name > > * > > If I now change the /process qualifier > >i > > $ type i.com1 > > $                                       run - = > >         /io_direct=300 /detac /process="Start WCCProxy" --@ > >         /input=DKA200:[SYS0.SYSCOMMON.WEBES.HP.NODES.EDDIE1.8 > > SVCTOOLS.common.wccproxy.bin]wccproxydetachstart.com > > -DB > >         sys$system:loginout.exe /priority=15 /page_file=296752	 > > $exitV > >3 > > And run it :-b > >a > > $ @iA > > %RUN-S-PROC_ID, identification of created process is 00000256o > > $o > >b > > It runs successfully.e > >i< > > Any input as to why this might be would be appreciated ? > >n > > With regards
 > > Andrew   ------------------------------  + Date: Wed, 19 May 2004 10:02:23 +0000 (UTC)r From: david20@alpha2.mdx.ac.uk! Subject: Re: Request for new SMTPi) Message-ID: <c8fbbf$2q7$1@news.mdx.ac.uk>0  f In article <40AAC15A.9AC2FCB1@firstdbasource.com>, Michael Austin <maustin@firstdbasource.com> writes:  >david20@alpha2.mdx.ac.uk wrote: > i >> In article <40AA718E.B17E34B1@firstdbasource.com>, Michael Austin <maustin@firstdbasource.com> writes:* >> >Larry Kilgallen wrote: >> >l >> >> In article <409FCEAC.6FD5E5E3@firstdbasource.com>, Michael Austin <maustin@firstdbasource.com> writes:F >> >> > It would be real nice to have a way to not bounce any message.O >> >> > Especially since most of the spam uses forged headers etc...the servers P >> >> > then get into a bounce the bounced message loop.  the only way out is toF >> >> > stop mail and delete all of the bounced messages in the queue. >> >> > ; >> >> > either a parameter in the .CONFIG file or a logicalO- >> >> > TCPIP$BOUNCE_MESSAGES  {TRUE | FALSE}t >> >>e? >> >> The proper technique is to reject during the SMTP dialog.t >> >i >> >I have been thinking about this... and I somewhat disagree.. it is impossible to reject on an unknownri >> >quantity. If I recall correctly, SMTP does not determine if the user exists or not until after it has m >> >received and processed the entire message.  IE, you do not know that some made-up username does not existKm >> >on your system.. So, the post-processing of the message will "bounce" the message to the person listed inrn >> >the "MAIL FROM:" command.  But, if this too is bogus it gets "bounced" back to me..  thereby causing us/me1 >> >to have to handle the same bogus email twice.  >> >n >> >What ever method (reject email or prohibit bounced messages) is used,  it would still be nice to have this2 >> >functionality -- and the sooner the better.... >> > >> >receive email 0 >> >discovers user does not exist on this system( >> >do not bounce it.. just delete it... >> > >>' >> This would not comply with the RFCs. > >> The system must inform the sender that the delivery failed. >>N >> Note. Even if the rejection is made during the SMTP dialogue a message mustR >> still be sent back to the sender. If the mail was sent directly to your machineO >> then the rejection message is sent directly back to the sender's mail clientt5 >> in the form of the 550 rejection code and message.o >>L >> If the mail was sent via an intermediary system then rejecting during theQ >> SMTP dialogue forces the intermediate system to generate a bounce message backo >> to the sender.e >>O >> Indeed for modern MTAs which support the notary extension RFC 3461 specifiesaQ >> that if the sender requests it a failure notification should include the wholee >> message in the bounce.b >> >> "  >>    The third component of theG >>    multipart/report consists of the original message or some portion E >>    thereof.  When the value of the RET parameter is FULL, the fullaJ >>    message SHOULD be returned for any DSN which conveys notification ofJ >>    delivery failure.  (However, if the length of the message is greaterH >>    than some implementation-specified length, the MTA MAY return only< >>    the headers even if the RET parameter specified FULL.) >> " >>, >> The "RET" parameter is set by the sender. >nl >I am not disagreeing with the intention of the RFC. I am however wondering -- as are the thousands of otherm >mail/SMTP server owners/managers, if the RFC needs a bit of updating... because the fact is, the internet is n >clogged  with bogus email bouncing from one system to another because of spam and certain viruses / worms etck >-- some of them containing worms and virii...  As I said, the "mail from" and the "Return-Path" fields areom >generally forged therefore the RFC is causing more problems than it was meant to solve.   Until the spammersbp >and virus authors are shot and hung by various parts of their anatomy, there needs to be a way for the owner ofe >the system to control how he/she handles these sorts of things -- not to mention bandwidth issues...( >aH The reason that the RFCs mandate informing the sender is because SMTP isM supposed to be a reliable system. If you send a mail message it should either H be delivered or you should get something back to tell you that it wasn't delivered and hopefully why.N If you start just dropping mail messages then the sender has no way of knowingL what has happened to their mail - did they mistype the address, was the user overquota etc ? L My response to that situation would be to send every message with a deliveryK receipt request which if everybody did it would generate even more traffic.pJ (At which point I would guess you would start arguing for systems to stop  honouring such requests).a   Note.s  O Although the action of deleting virus laden messages which forge from/returned sL addresses is also strictly speaking against the RFCs this can just about be K excused since once you have detected that this is one of the viruses which -K forge from addresses it is pointless for you to bounce the message back to s the forged address.rO The situation with incorrect usernames is different unless you can come up with@; a system to tell which messages have forged from addresses.4    
 David Webb VMS and Unix team leader CCSS Middlesex University      ? >I have added *@yahoo.{it|fr|ca} to my 'reject-mail-from' list.v >t` >Example from my mail today... my system bounced this message, and it was bounced back to me.... >m, >Date: Tue, 18 May 2004 20:13:52 -0500 (CDT)0 >Message-Id: <04051820135245@firstdbasource.com>$ >From: TCPIP$SMTP@FIRSTDBASOURCE.COM >To: TCPIP$SMTPe >Subject: Returned mailj >:( >---- Transcript of session follows ----? >554  %TCPIP-E-SMTP_XFAIL, remote transaction failure, yahoo.ca ! >---- Unsent message follows ----e >r, >Date: Tue, 18 May 2004 20:13:47 -0500 (CDT)0 >Message-Id: <04051820134760@firstdbasource.com>$ >From: TCPIP$SMTP@FIRSTDBASOURCE.COM >To: irqwwwqjckwmgx@yahoo.ca >Subject: Returned maile >x( >---- Transcript of session follows ----E >%%%%%%%%%%%%                   18-MAY-2004 20:13:43.14  %%%%%%%%%%%% 2 >%MAIL-E-NOSUCHUSR, no such user 3CA09A38.EDD42A5BE >%%%%%%%%%%%%                   18-MAY-2004 20:13:44.33  %%%%%%%%%%%%t2 >%MAIL-E-NOSUCHUSR, no such user 3CA09ACD.E65931BEE >%%%%%%%%%%%%                   18-MAY-2004 20:13:45.56  %%%%%%%%%%%%)1 >%MAIL-E-NOSUCHUSR, no such user 3CA0EF32.F9EA4BFtE >%%%%%%%%%%%%                   18-MAY-2004 20:13:46.35  %%%%%%%%%%%%v2 >%MAIL-E-NOSUCHUSR, no such user 3CA14144.80B41CBDE >%%%%%%%%%%%%                   18-MAY-2004 20:13:47.05  %%%%%%%%%%%%r2 >%MAIL-E-NOSUCHUSR, no such user 3CA2865D.AE018E65& >---- Recipients of this delivery ---- >s1 ><3ca09a38.edd42a5b@firstdbasource.com> (bounced)o1 ><3ca09acd.e65931be@firstdbasource.com> (bounced)c0 ><3ca0ef32.f9ea4bf@firstdbasource.com> (bounced)1 ><3ca14144.80b41cbd@firstdbasource.com> (bounced) 1 ><3ca2865d.ae018e65@firstdbasource.com> (bounced)  >a! >---- Unsent message follows ----x >s% >Return-Path: irqwwwqjckwmgx@yahoo.can. >Received: from mx2.dnsvr.com (216.93.166.122)H >         by alpha1.firstdbasource.com (V5.3-18E, OpenVMS V7.3-1 Alpha);. >        Tue, 18 May 2004 20:13:40 -0500 (CDT)Q >Received: from h00e0188b9f74.ne.client2.attbi.com (h00e0188b9f74.ne.client2.attb  >i.com [24.128.15.63])- >        by mx2.dnsvr.com (Postfix) with SMTPt> >        id 9A57A1CB74B; Tue, 18 May 2004 21:10:15 -0400 (EDT)Q >Received: from 52.92.144.137 by web764.mail.yahoo.com; Wed, 19 May 2004 12:00:25e > -0600i, >Message-ID: <PKHCHRLTOARSOFXDRELLY@msn.com>, >From: "Enrique Kimble" <owrpvlhbr@yahoo.fr>* >To: 3ca09a38.edd42a5b@firstdbasource.com,. >        3ca09acd.e65931be@firstdbasource.com,- >        3ca0ef32.f9ea4bf@firstdbasource.com, . >        3ca14144.80b41cbd@firstdbasource.com,- >        3ca2865d.ae018e65@firstdbasource.coml2 >Subject: Balance Due, account         ineluctable& >Date: Wed, 19 May 2004 23:01:25 +0500 >MIME-Version: 1.0, >Content-Type: text/html; charset=iso-8859-1, >Content-Transfer-Encoding: quoted-printable >p >----875350313654304952o > ! >[HTML CODE REMOVED for brevity.]1 >----875350313654304952--i >o >  >>
 >> David Webbe >> VMS and Unix team leadere >> CCSS  >> Middlesex UniversityF >> >> >Michael Austin >> > >> > >s   ------------------------------  # Date: Wed, 19 May 2004 14:09:40 GMTt1 From: Michael Austin <maustin@firstdbasource.com>a! Subject: Re: Request for new SMTPn2 Message-ID: <40AB6AA4.B9CE5AB8@firstdbasource.com>   david20@alpha2.mdx.ac.uk wrote:t   > <snip>  J > The reason that the RFCs mandate informing the sender is because SMTP is  O > supposed to be a reliable system. If you send a mail message it should either J > be delivered or you should get something back to tell you that it wasn't > delivered and hopefully why.P > If you start just dropping mail messages then the sender has no way of knowingN > what has happened to their mail - did they mistype the address, was the user > overquota etc ?D  l Understood, but you could also argue that the system is reliable since it did receive the message ie messageN transmission succeeded, then what happens to the message is a different story.  o Case and Point:  I have an SMTP server that uses a dynamic DNS provider.  When I send email directly to certain6s companies, the party never receives the message.  I sent it, it was accepted by their system (Exchange Server), but t becuase my IP does not backtranslate to my domain, it is dropped -- not bounced, no error message, just dropped.  In: this case,  would you say they are compliant with the RFC?   >MN > My response to that situation would be to send every message with a deliveryM > receipt request which if everybody did it would generate even more traffic. K > (At which point I would guess you would start arguing for systems to stop  > honouring such requests).  >e  k :) I have my email app set to "ask" before sending and I usually cancel it so you don't get it anyway... :)    >: > Note.p >nP > Although the action of deleting virus laden messages which forge from/returnedM > addresses is also strictly speaking against the RFCs this can just about beoL > excused since once you have detected that this is one of the viruses whichL > forge from addresses it is pointless for you to bounce the message back to > the forged address.hQ > The situation with incorrect usernames is different unless you can come up with = > a system to tell which messages have forged from addresses.e >e  r I didn't say it would be easy :)  Especially since VRFY has been shown to be a bigger problem because then one canY "find" known good addresses.  As I stated before, spammers,etc... should be strung up....C     >y > David Webb > VMS and Unix team leader > CCSS > Middlesex University >E   <stuff snipped>C   ------------------------------  + Date: Wed, 19 May 2004 17:15:08 +0000 (UTC)Q From: david20@alpha2.mdx.ac.uk! Subject: Re: Request for new SMTP1) Message-ID: <c8g4ms$aq2$1@news.mdx.ac.uk>Q  f In article <40AB6AA4.B9CE5AB8@firstdbasource.com>, Michael Austin <maustin@firstdbasource.com> writes:  >david20@alpha2.mdx.ac.uk wrote: >o	 >> <snip>G >GK >> The reason that the RFCs mandate informing the sender is because SMTP isg >QP >> supposed to be a reliable system. If you send a mail message it should eitherK >> be delivered or you should get something back to tell you that it wasn'tE >> delivered and hopefully why.zQ >> If you start just dropping mail messages then the sender has no way of knowingGO >> what has happened to their mail - did they mistype the address, was the userW >> overquota etc ? >um >Understood, but you could also argue that the system is reliable since it did receive the message ie messageQO >transmission succeeded, then what happens to the message is a different story.G >Hp >Case and Point:  I have an SMTP server that uses a dynamic DNS provider.  When I send email directly to certaint >companies, the party never receives the message.  I sent it, it was accepted by their system (Exchange Server), butu >becuase my IP does not backtranslate to my domain, it is dropped -- not bounced, no error message, just dropped.  Inl; >this case,  would you say they are compliant with the RFC?G >mN As long as the return-address corresponds to a DNS  A or MX entry of some sortM or contains a domain-literal ip address then the system should be attempting  8 to send a bounce message if it is rejecting the message.N If your system is unavailable for a long period then the sending of the bounceN might timeout but the system should have attempted it - it shouldn't just dropM mail messages. It may legitimately decide not to deliver the message for any vK reason it wants but it must inform the sender otherwise it is breaking the 0 RFCs.kD I'd think those companies must be dropping a lot of legitimate mail.       "W  	 RFC 1123 C   5.5.3 Reliable Mail ReceiptH  M When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" messageCO in response to DATA), it is accepting responsibility for delivering or relaying2J the message. It must take this responsibility seriously, i.e., it MUST NOT* lose the message for frivolous reasons ...  O If there is a delivery failure after acceptance of a message, the receiver-SMTPN3 MUST formulate and mail a notification message. ...WN The recipient of this notification SHOULD be the the address from the envelopeH return path (or the Return-Path: line). However, if this address is null7 ("<>"), the receiver-SMTP MUST not send a notification.v   "2    k >>O >> My response to that situation would be to send every message with a deliveryvN >> receipt request which if everybody did it would generate even more traffic.L >> (At which point I would guess you would start arguing for systems to stop >> honouring such requests). >> >WL >:) I have my email app set to "ask" before sending and I usually cancel it   so you don't get it anyway... :)  F Are you sure that is for delivery-receipts rather than read-receipts ?   >G >> >> Note. >>Q >> Although the action of deleting virus laden messages which forge from/returnedgN >> addresses is also strictly speaking against the RFCs this can just about beM >> excused since once you have detected that this is one of the viruses whichhM >> forge from addresses it is pointless for you to bounce the message back toi >> the forged address.R >> The situation with incorrect usernames is different unless you can come up with> >> a system to tell which messages have forged from addresses. >> >Hs >I didn't say it would be easy :)  Especially since VRFY has been shown to be a bigger problem because then one cangZ >"find" known good addresses.  As I stated before, spammers,etc... should be strung up.... >W0 There are proposals which might help such as SPF http://spf.pobox.com/intro.htmlg  H however they are still fairly controversial since they cause things likeH forwarding to break - also I'm not sure how well it would work with your dynamic-dns setup.    
 David Webb VMS and Unix team leader CCSS Middlesex University  G >G >>
 >> David Webb2 >> VMS and Unix team leaderG >> CCSSu >> Middlesex University2 >> >W ><stuff snipped> >W   ------------------------------  % Date: Wed, 19 May 2004 08:31:43 +0200j( From: "Rudolf Wingert" <win@fom.fgan.de>* Subject: Re: SUN fails to advertise VMS...3 Message-ID: <001701c43d6a$f3d22600$994614ac@wat153>m   Hello,  C Andrew, do you think that it is an illusion, that there are OpenVMSUD sites on the air (internet) without any downtime in case of viruses, worms and trojaner?yA John Covert and other do have OpenVMS at home and do all internetX@ services (WEBserver, Email, ...) with OpenVMS. They do have onlyF downtime in case of power fail. I did not hear that a complete OpenVMS2 site was down like Sun Solaris, in case of a worm.   Best regards Rudolf WingertX   ------------------------------    Date: 19 May 2004 06:39:04 -07002 From: williamwebb@openvms-rocks.com (William Webb)* Subject: Re: SUN fails to advertise VMS...< Message-ID: <bf98c417.0405190539.7038255@posting.google.com>  W "John Smith" <a@nonymous.com> wrote in message news:<GuSdnbaB54ZlMjfdRVn-ig@igs.net>...X7 > "Bob Ceculski" <bob@instantwhip.com> wrote in messageU8 > news:d7791aa1.0405181519.1cf087d@posting.google.com...M > > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>o@ >  wrote in message news:<c8dfbl$p5u$3@new-usenet.uk.sun.com>... > > > >m > > > > Having a bad day?C > > >G: > > > Why would pointing out Bobs very obvious failings be( > > > a symptom of me having a bad day ? > > >w
 > > > regardsl > > > Andrew HarrisonK > >W> > > the only thing you are pointing out is your desperation toB > > trash the only os that can't get viruses and has 13 irrelevant@ > > certs in 13 years (i.e. decwindows) because your company and> > > every other one out there is selling patch of the day club5 > > memberships in the form of unix/linux/windoze ...m >  >  > Bob, > L > Somehow I don't think that going on about this time after time with AndrewL > will convince him any time soon that he should run out and buy VMS for useL > in his company, even though Andrew knows in his heart that you are correct > ;-)g > I > You'd be of greater service to OpenVMS by convincing all your company'szJ > suppliers and customers to come over to VMS. Statistically you'll have aE > better chance of doing that than getting Andrew to change his view.v >  > John  I But if he [Andrew] argues with us, he MUST take up a contrary position...g   WWWebb   ------------------------------  % Date: Wed, 19 May 2004 10:03:56 -0400z# From: "John Smith" <a@nonymous.com>2* Subject: Re: SUN fails to advertise VMS..., Message-ID: <wb2dnW9fMN3K9DbdRVn-jw@igs.net>  ? "William Webb" <williamwebb@openvms-rocks.com> wrote in messageB6 news:bf98c417.0405190539.7038255@posting.google.com...0 > "John Smith" <a@nonymous.com> wrote in message( news:<GuSdnbaB54ZlMjfdRVn-ig@igs.net>...9 > > "Bob Ceculski" <bob@instantwhip.com> wrote in messageH: > > news:d7791aa1.0405181519.1cf087d@posting.google.com...' > > > Andrew Harrison SUNUK Consultancyi' <Andrew_No.Harrison_No@nospamn.sun.com>yB > >  wrote in message news:<c8dfbl$p5u$3@new-usenet.uk.sun.com>...	 > > > > >p > > > > > Having a bad day?C > > > >X< > > > > Why would pointing out Bobs very obvious failings be* > > > > a symptom of me having a bad day ? > > > >z > > > > regards2 > > > > Andrew HarrisonW > > >C@ > > > the only thing you are pointing out is your desperation toD > > > trash the only os that can't get viruses and has 13 irrelevantB > > > certs in 13 years (i.e. decwindows) because your company and@ > > > every other one out there is selling patch of the day club7 > > > memberships in the form of unix/linux/windoze ...F > >  > >- > > Bob, > >-G > > Somehow I don't think that going on about this time after time withc AndrewJ > > will convince him any time soon that he should run out and buy VMS for use@F > > in his company, even though Andrew knows in his heart that you are correct1 > > ;-)  > >rK > > You'd be of greater service to OpenVMS by convincing all your company'ssL > > suppliers and customers to come over to VMS. Statistically you'll have aG > > better chance of doing that than getting Andrew to change his view.h > >  > > John > K > But if he [Andrew] argues with us, he MUST take up a contrary position...     = While Andrew argues with Bob, he debates with the rest of us.-   ------------------------------  + Date: Wed, 19 May 2004 05:40:05 +0000 (UTC) 6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)F Subject: Re: Switching from Process Software TCPware to TCPIP Services0 Message-ID: <newscache$7w4yxh$umo$1@news.sil.at>  k In article <4b6ec350.0405171512.1f13c58@posting.google.com>, JimStrehlow@data911.com (Jim Strehlow) writes: ` >"Pip" <pip@ti.nl0.com> wrote in message news:<40a889c0$0$3034$afc38c87@news.optusnet.com.au>...K >> Has anybody ever switched from Process Software's TCPware to HP's TCPIP i. >> Services, and have gotchas to look out for?N >> (In particular, features that TCPware has that might be missing from TCPIP  >> Services) >p@ >1) We switched three years ago when it was a budget concern for7 >multiple new nodes.   H.P.'s stack comes with OpenVMS.t  H Funny. We bought TCPware because it was only 15% of the price of UCX andI had 6times the features then (1990 or 1991). We later ran TCPware (on the0F servers) and UCX (on the workstations) mixed in the cluster because IPH transport for DECwindows was free with UCX (that's why I still recommendE thinking IP stack independant). Now we are TCPIP only (except my home & systems which most still run TCPware).  G >2) H.P.'s TCP/IP stack is reliable. They patch it as necessary; but wet* >have had no operational problems with it.  I My problems were years ago, but I also had showstopper bugs with TCPware.e! Way back in the early nineties...   + >3) We had to relink existing applications.e  6 Why ? Did you forget to use UCX emulation in TCPware ?  > >4) A coworker mentions that answering the prompts in order to3 >configure TCP/IP can be tedious; but work is work.o  F It was easier with UCX at earlier times (since TCPIP it is very unixy)L but I also did configure TCPware with the editor instead of the CNFNET tool. Nobody is perfect.  D >5) You will need to allow time to replace "customized code" writtenE >for your existing stack to the new stack.  e.g. When we FTP, we savesA >the log and search the log for different error messages and testm* >accordingly. (Same thing only different.)  
 Of course.  F >6) I personally do not know all the features of one versus the other.B >That is one of your goals during testing if you decide to change.  F I loved the feature to change the IP stack on the server with a simpleH reboot just to check if a given bug/feature was also in the other stack.H And in the case of the showstopper bugs (like crashes by the PWIPDRIVER) it saved my life.    -- I Peter "EPLAN" LANGSTOEGER-% Network and OpenVMS system specialist0 E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------    Date: 19 May 2004 05:36:38 -0700( From: bob@instantwhip.com (Bob Ceculski)F Subject: Re: Switching from Process Software TCPware to TCPIP Services= Message-ID: <d7791aa1.0405190436.48f9c33a@posting.google.com>c  ~ "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in message news:<40AAB683.866FF284@NeOaSrPtAhMlNiOnWk.net>... > Bob Ceculski wrote:  > >  > > "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in message news:<40A979D9.622D78C0@NeOaSrPtAhMlNiOnWk.net>... > > > Bob Ceculski wrote:: > > > > h > > > > "Pip" <pip@ti.nl0.com> wrote in message news:<40a93a4f$0$31675$afc38c87@news.optusnet.com.au>...U > > > > > Because it appears that TCPware is not currently available for OpenVMS v8.1o > > > > > on Itanium.o > > > >l@ > > > > TCPware is being ported to itanium ... will be there for@ > > > > 8.2 ... plus it is the ONLY IP stack that can run decnet > > > > phase IV over IP ... > > >mG > > > Not true. Multinet also provides DnIV/IP as Point-to-Point links.  > > ? > > but not TRUE phase IV over IP ... it uses a pwip driver ...: >  > Try again... > , > Have you actually SEEN Multinet's DnIV/IP? > 4 > Hint: See the on-line Multinet doc.'s, especially:E > http://www.multinet.process.com/ftp/docs/html/admin_guide/httoc.htm K > http://www.multinet.process.com/ftp/docs/html/admin_guide/Ch26.htm#E47E27n >  > No mention is made of PWIP.r  C I was told by engineering when I inquired about the differences ...  is that good enough for you?   ------------------------------    Date: 18 May 2004 22:47:05 -0700' From: icerq4a@spray.se (David Svensson)2+ Subject: Re: The next port for OpenVMS? ;-)o= Message-ID: <734da31c.0405182147.6a70ee1d@posting.google.com>u  a Paul Repacholi <prep@prep.synonet.com> wrote in message news:<87n045ip32.fsf@prep.synonet.com>...gS > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes:v > E > > Its interesting, the only people who still seem to think that theOH > > laws of physics which apply to everyone else don't apply to them are > > the Itanium folks. > J > And the rest of intel marketing it seems. They stated recently that the F > upcoming dual core itanic will be smaller than x86 cores! Or perhaps > they meant 486s or PPros...d  $ You confuse core size with die size., Die size include caches, core size does not.   ------------------------------  % Date: Wed, 19 May 2004 03:42:44 -0400)* From: "Bill Todd" <billtodd@metrocast.net>+ Subject: Re: The next port for OpenVMS? ;-)c2 Message-ID: <taWdndOhGflNkjbdRVn-sw@metrocast.net>  4 "David Svensson" <icerq4a@spray.se> wrote in message7 news:734da31c.0405182143.50852385@posting.google.com...nK > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> = wrote in message news:<c8df1c$p5u$1@new-usenet.uk.sun.com>...e   ...   D > > To give you some idea of the problem Prescott which is currentlyD > > being built in a 90 nanometer process, puts out 103 watts at 3.2C > > GHz roughly 20 watts more than a 3.2 GHz Xeon built in an older B > > and apparently higher power 130 nanometer process. The 3.2 GHzC > > Prescott chip is slightly slower than Xeon for most benchmarks.l > >eE > > Apparently Intel intend to use the die space that would have beenoA > > used to build Tejas to house 2 simpler cores that they expect A > > will deliver slightly better throughput than the single Tejast1 > > core but with better thermal characteristics.h > >tI > > Which leaves us with Itanium. Intels reasons for cancelling Tejas andtB > > Jayhawk were mostly around their heat output, Itanium which isC > > considerably larger than Tejas and which will be even larger in}D > > 2005/2006 suffers from exactly the same problem except of course > > its worse. >"1 > Montecito is apparently in silicon and running,o  F Prescott was 'in silicon and running' *well* over a year ago, but thatI didn't keep it from being a major embarrassment right through the present  day.    it is said to be0A > released in 2005, that will most likely be second half of 2005.   H Since Intel was publicly projecting a 2005H2 release date, last I heard,. it's kind of unlikely to be earlier than that.    GoingA > from 130nm to 90nm looks like a problem for P4, but not for PM.p  F I'd say that depends on how you define 'problem'.  IIRC the new 90 nm.L Dothan Pentium M uses at least as much power as its 130 nm. Banias Pentium MI parent, in a manner distinctly reminiscent of the 130 nm. Northwood to 90nK nm. Prescott non-advance.  However, since unlike Northwood/Prescott PentiumsJ Ms aren't up against a hard power dissipation limit, they can tolerate theL fact that the move to 90 nm. bought them no increased performance efficiency= at all (though Intel is hardly likely to be happy with that).i  D > Whether Itanium will have the same problems as P4 in 2005 is not a > given.  L No, but if they follow the same trajectory that Prescott and Dothan did theyJ will.  And Itanic, like the P4/Xeon, is already close to the limits of itsG power envelope, which means that the 90 nm. Montecito may well clock no H faster than the current 130 nm. Madison even with one of Montecito's twoL cores turned off, and may have to clock *slower* than Madison if both of its cores are running.  :  Large caches does not consume as much power as the cores,F > actually they differences can be huge, and Itanium cores are smaller > than P4 cores.  K Just about anything is smaller than a P4 core (though Itanic is pushing it:sF only if/when they jettison the embedded IA32 hardware support will theL current Itanic core be *noticeably* smaller than the P4 core).  But then the7 question is, will they be smaller than Pentium M cores?e   ...t  K > > Sun cancelled Millenium Aka USV for exactly the same reasons that Intel-K > > cancelled Tejas. This could imply that Intel is in the same boat as Sun.C > > except for one very salient difference, Sun had already started3H > > developing an alternative (Rock) and had been doing so for sometime,F > > Intel does not seem to have got very far if anywhere down the same
 > > route. >sF > Many have predicted that Pentium M is the future, and in that regard! > they already have an advantage.   G Over whom?  The Pentium M core may be a significant step up from the P4vK core, but it's at best comparable to the AMD64 core.  And while Sun doesn't L have an existing core of its own to throw into the temporary gap left by theL cancellation of USV, they reportedly have an arrangement with Fujitsu to use the quite respectable SPARC64.   - bill   ------------------------------  % Date: Wed, 19 May 2004 09:35:26 +0100e9 From: Andrew Harrison <andrew_._remove_harrison@su_n.com>h+ Subject: Re: The next port for OpenVMS? ;-)u0 Message-ID: <c8f68f$e5a$1@new-usenet.uk.sun.com>   David Svensson wrote:0 > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<c8df1c$p5u$1@new-usenet.uk.sun.com>...  >   H >>However its clear from Intels recent cancellation of Tejas and JayhawkH >>that they don't expect these new processes to be available soon enough6 >>to allow the next generation x86 units to be viable. >  > & > Potomac and Tulsa are not cancelled,; > and they are also part of the "next generaton x86" units.- >   . Even that claim seems to be very much in doubt  < http://www.xbitlabs.com/news/cpu/display/20040507014630.html  ; And remember the logic that says that the extended Netburst 9 pipeline doesn't deliver enough throughput and is too hoto: applies to anything that uses that pipeline or derivations of it.  > And Jayhawk was the replacement for the Xeon DP by far in away the highest selling server CPU.I > B >>To give you some idea of the problem Prescott which is currentlyB >>being built in a 90 nanometer process, puts out 103 watts at 3.2A >>GHz roughly 20 watts more than a 3.2 GHz Xeon built in an oldera@ >>and apparently higher power 130 nanometer process. The 3.2 GHzA >>Prescott chip is slightly slower than Xeon for most benchmarks.l >>C >>Apparently Intel intend to use the die space that would have beens? >>used to build Tejas to house 2 simpler cores that they expectk? >>will deliver slightly better throughput than the single Tejaso/ >>core but with better thermal characteristics.- >>G >>Which leaves us with Itanium. Intels reasons for cancelling Tejas and @ >>Jayhawk were mostly around their heat output, Itanium which isA >>considerably larger than Tejas and which will be even larger in@B >>2005/2006 suffers from exactly the same problem except of course >>its worse. >  > B > Montecito is apparently in silicon and running, it is said to beG > released in 2005, that will most likely be second half of 2005. Going A > from 130nm to 90nm looks like a problem for P4, but not for PM. D > Whether Itanium will have the same problems as P4 in 2005 is not aB > given. Large caches does not consume as much power as the cores,F > actually they differences can be huge, and Itanium cores are smaller > than P4 cores. >   E Prescott was apparently running but in fact went through 3 additionaleC spins before getting to market and at a heat output that has raisedr> serious doubts about its viability given its less than stellar performance.  C And you are right cache is less expensive that the core in terms ofu? heat, but this is also relative, Itanium II for example despitex> having a slightly smaller core than Xeon still easily tops outF Xeon on heat output while at the same time delivering less performance than Xeon does.$  @ Pentium M on the other hand is more than half the performance of< either Xeon or Itanium while only pushing out 25 watts under> 1/4 of the heat budget for the Itanium II with the 90 nm units pushing out 21 watts.   E 1.7 GHz Pentium M units are good for over 1000 SPECint while the best 1 Itanium result is 1408 and the best Xeon is 1620.  > J >>So if you apply the Tejas/Jayhawk logic to Itanium you end up cancelling5 >>it in favour of doing a simpler multi-core Itanium.T >  > @ > Simpler multicore is, according to some reports, in the works,
 > Tukwila. >   ? Sure but the problem is the performance of the core, LV ItaniumtB sucks rocks performance wise compared with Pentium M and it easily> exceeds Pentium M heat budgets by a factor of two and the only( trade has been to reduce the cache size.   > I >>However there is no simple Itanium core available nor is one likely to -H >>surface. The Itanium core could have been a candidate but its too slowJ >>and not nearly compact enough, the Pentium M core for example is 2x the E >>performance of the Itanium, uses less transistors and puts out lessc >>heat.a >  > 6 > Pentium M core is not 2x the performance of Itanium. >   9 Did I say it was, it is however easily more than half theu5 performance of Itanium and you could put 4 of them onr9 the same die as Itanium II and still end up with a better< powere budget.   > I >>Sun cancelled Millenium Aka USV for exactly the same reasons that Intel I >>cancelled Tejas. This could imply that Intel is in the same boat as SunsA >>except for one very salient difference, Sun had already startedrF >>developing an alternative (Rock) and had been doing so for sometime,D >>Intel does not seem to have got very far if anywhere down the same >>route. >  > F > Many have predicted that Pentium M is the future, and in that regardF > they already have an advantage. What Intel will have in x86 space in$ > 2007 when Rock appears is unknown.  G Of course, because Intel are re-writing all their roadmaps as we speak.r   regardsi Andrew Harrisonc   ------------------------------  % Date: Wed, 19 May 2004 09:55:19 +0100i9 From: Andrew Harrison <andrew_._remove_harrison@su_n.com>v+ Subject: Re: The next port for OpenVMS? ;-) 0 Message-ID: <c8f7dp$egn$1@new-usenet.uk.sun.com>   Bill Todd wrote:  6 > "David Svensson" <icerq4a@spray.se> wrote in message   > I > Over whom?  The Pentium M core may be a significant step up from the P4iM > core, but it's at best comparable to the AMD64 core.  And while Sun doesn'tvN > have an existing core of its own to throw into the temporary gap left by theN > cancellation of USV, they reportedly have an arrangement with Fujitsu to use  > the quite respectable SPARC64. >   F Its hard to make a direct comparison between Pentium M and say OpteronG EE because the Opteron is 64bit and 64bit support will have to be addedi? to Pentium M plus Opteron includes memory controller and system E interconnect both of which would have to be added to the power budget  for the Pentium M.  F  From a perfromance perspective the 1.4 GHz Opteron EE and the 1.4 GHzA Pentium M are about the same on Integer while the Opteron lead ons FP performance.c  A On the SPARC point Sun does have units to throw into the gap lefto? by USV. At the low end we have Niagara which recently taped out ? while the large SMP servers can use USIV which is dual threadedeA and has a number of quite significant speed bumps in the pipeliner3 including the addition of much larger onchip cache.o   Regardsi Andrew Harrisonf   ------------------------------    Date: 19 May 2004 07:15:03 -0700' From: icerq4a@spray.se (David Svensson)n+ Subject: Re: The next port for OpenVMS? ;-)t= Message-ID: <734da31c.0405190615.47ac8924@posting.google.com>s  d "Bill Todd" <billtodd@metrocast.net> wrote in message news:<taWdndOhGflNkjbdRVn-sw@metrocast.net>...6 > "David Svensson" <icerq4a@spray.se> wrote in message9 > news:734da31c.0405182143.50852385@posting.google.com...eM > > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>r? > wrote in message news:<c8df1c$p5u$1@new-usenet.uk.sun.com>...  >  > ..." > F > > > To give you some idea of the problem Prescott which is currentlyF > > > being built in a 90 nanometer process, puts out 103 watts at 3.2E > > > GHz roughly 20 watts more than a 3.2 GHz Xeon built in an older D > > > and apparently higher power 130 nanometer process. The 3.2 GHzE > > > Prescott chip is slightly slower than Xeon for most benchmarks.c > > >vG > > > Apparently Intel intend to use the die space that would have beensC > > > used to build Tejas to house 2 simpler cores that they expectrC > > > will deliver slightly better throughput than the single Tejaso3 > > > core but with better thermal characteristics.o > > >uK > > > Which leaves us with Itanium. Intels reasons for cancelling Tejas andfD > > > Jayhawk were mostly around their heat output, Itanium which isE > > > considerably larger than Tejas and which will be even larger ineF > > > 2005/2006 suffers from exactly the same problem except of course > > > its worse. > >m3 > > Montecito is apparently in silicon and running,g > H > Prescott was 'in silicon and running' *well* over a year ago, but thatK > didn't keep it from being a major embarrassment right through the present  > day.  F That is correct, but Montecito is going to be introduced more than oneC and a half year later than Prescott. There obviosly is more time tosA get things better. I think one of the the reasons this years 2004lE single-core Montecito was cancelled was because Intel didn't believed E their 90nm process to be enough mature for Montecito. In 2005H2 it iss> most likely better and there might also have been time to make/ physical/layout changes to the Montecito cores.s   >  it is said to besC > > released in 2005, that will most likely be second half of 2005.h > J > Since Intel was publicly projecting a 2005H2 release date, last I heard,0 > it's kind of unlikely to be earlier than that. >  >  GoingC > > from 130nm to 90nm looks like a problem for P4, but not for PM.@ > H > I'd say that depends on how you define 'problem'.  IIRC the new 90 nm.N > Dothan Pentium M uses at least as much power as its 130 nm. Banias Pentium MK > parent, in a manner distinctly reminiscent of the 130 nm. Northwood to 90aM > nm. Prescott non-advance.  However, since unlike Northwood/Prescott PentiumtL > Ms aren't up against a hard power dissipation limit, they can tolerate theN > fact that the move to 90 nm. bought them no increased performance efficiency? > at all (though Intel is hardly likely to be happy with that).4  E Dothan uses less power than Banias at a higher frequency and with 1MbtC more cache. Prescott use much more power than Northwood at the sameDF frequency and with 512kb more cache. Prescott also added 64-bit stuff,5 and that may have been a burden in the layout design.e  F > > Whether Itanium will have the same problems as P4 in 2005 is not a
 > > given. > N > No, but if they follow the same trajectory that Prescott and Dothan did theyL > will.  And Itanic, like the P4/Xeon, is already close to the limits of itsI > power envelope, which means that the 90 nm. Montecito may well clock no%J > faster than the current 130 nm. Madison even with one of Montecito's twoN > cores turned off, and may have to clock *slower* than Madison if both of its > cores are running.  4 Intel is projecting 2.0+Ghz for Montecito next year.4 I think between 2.0 and perhaps up to 2.5 is likely.  < >  Large caches does not consume as much power as the cores,H > > actually they differences can be huge, and Itanium cores are smaller > > than P4 cores. > M > Just about anything is smaller than a P4 core (though Itanic is pushing it:fH > only if/when they jettison the embedded IA32 hardware support will theN > current Itanic core be *noticeably* smaller than the P4 core).  But then the9 > question is, will they be smaller than Pentium M cores?c  E I agree, it looks like Itanium and Pentium M cores are close in size.i3 When Pentium M gets 64-bit they will grow somewhat.    > ...e > M > > > Sun cancelled Millenium Aka USV for exactly the same reasons that IntelcM > > > cancelled Tejas. This could imply that Intel is in the same boat as SunvE > > > except for one very salient difference, Sun had already started1J > > > developing an alternative (Rock) and had been doing so for sometime,H > > > Intel does not seem to have got very far if anywhere down the same > > > route. > >nH > > Many have predicted that Pentium M is the future, and in that regard# > > they already have an advantage.t > I > Over whom?  The Pentium M core may be a significant step up from the P44M > core, but it's at best comparable to the AMD64 core.  And while Sun doesn't N > have an existing core of its own to throw into the temporary gap left by theN > cancellation of USV, they reportedly have an arrangement with Fujitsu to use  > the quite respectable SPARC64.  A It looks like Sun is stuck with USIV until 2007. Whether Sun willrC start to use SPARC64 is pure speculation thus far. They have done aVA good thing and getting AMD in their portfolio. I was at Sun a few>D weeks ago and they said that their x86-64 servers was the future andF Sparc was only kept for existing customers. Now, I think that is a bit4 overstating the case, but they _actually_ said that.   ------------------------------    Date: 19 May 2004 07:41:33 -0700' From: icerq4a@spray.se (David Svensson)s+ Subject: Re: The next port for OpenVMS? ;-) = Message-ID: <734da31c.0405190641.68a666a9@posting.google.com>u  q Andrew Harrison <andrew_._remove_harrison@su_n.com> wrote in message news:<c8f68f$e5a$1@new-usenet.uk.sun.com>...  > David Svensson wrote:h > > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<c8df1c$p5u$1@new-usenet.uk.sun.com>...e > >  >  aJ > >>However its clear from Intels recent cancellation of Tejas and JayhawkJ > >>that they don't expect these new processes to be available soon enough8 > >>to allow the next generation x86 units to be viable. > >  > > ( > > Potomac and Tulsa are not cancelled,= > > and they are also part of the "next generaton x86" units.t > >  > 0 > Even that claim seems to be very much in doubt > > > http://www.xbitlabs.com/news/cpu/display/20040507014630.html > = > And remember the logic that says that the extended Netburst-; > pipeline doesn't deliver enough throughput and is too hot,< > applies to anything that uses that pipeline or derivations > of it.  " We will just have to wait and see.  @ > And Jayhawk was the replacement for the Xeon DP by far in away! > the highest selling server CPU.    I agree.   > > D > >>To give you some idea of the problem Prescott which is currentlyD > >>being built in a 90 nanometer process, puts out 103 watts at 3.2C > >>GHz roughly 20 watts more than a 3.2 GHz Xeon built in an older:B > >>and apparently higher power 130 nanometer process. The 3.2 GHzC > >>Prescott chip is slightly slower than Xeon for most benchmarks.g > >>E > >>Apparently Intel intend to use the die space that would have beendA > >>used to build Tejas to house 2 simpler cores that they expectsA > >>will deliver slightly better throughput than the single Tejase1 > >>core but with better thermal characteristics.i > >>I > >>Which leaves us with Itanium. Intels reasons for cancelling Tejas andeB > >>Jayhawk were mostly around their heat output, Itanium which isC > >>considerably larger than Tejas and which will be even larger incD > >>2005/2006 suffers from exactly the same problem except of course > >>its worse. > >  > > D > > Montecito is apparently in silicon and running, it is said to beI > > released in 2005, that will most likely be second half of 2005. Going C > > from 130nm to 90nm looks like a problem for P4, but not for PM.kF > > Whether Itanium will have the same problems as P4 in 2005 is not aD > > given. Large caches does not consume as much power as the cores,H > > actually they differences can be huge, and Itanium cores are smaller > > than P4 cores. > >  > G > Prescott was apparently running but in fact went through 3 additional E > spins before getting to market and at a heat output that has raiseds@ > serious doubts about its viability given its less than stellar > performance.   Yes, we will see how it goes,l= I think Intel still thinks it will reach 4GHz late this year.s  E > And you are right cache is less expensive that the core in terms ofeA > heat, but this is also relative, Itanium II for example despiter@ > having a slightly smaller core than Xeon still easily tops outH > Xeon on heat output while at the same time delivering less performance > than Xeon does.s  D Xeon is faster on some stuff, and Itanium is faster on other things.  B > Pentium M on the other hand is more than half the performance of> > either Xeon or Itanium while only pushing out 25 watts under@ > 1/4 of the heat budget for the Itanium II with the 90 nm units > pushing out 21 watts.l  E Yes, Pentium M is very power effective. The real interesting questionoA is how much it can scale with more power, if it can tolerate moreRE power. They are most likely a bit clocked down for notebook usage nown and have slower busses.a  G > 1.7 GHz Pentium M units are good for over 1000 SPECint while the bests3 > Itanium result is 1408 and the best Xeon is 1620.   9 You usually don't use SPEC when you speak about Sparc. :)i  L > >>So if you apply the Tejas/Jayhawk logic to Itanium you end up cancelling7 > >>it in favour of doing a simpler multi-core Itanium.d > >  > > B > > Simpler multicore is, according to some reports, in the works, > > Tukwila. > >  > A > Sure but the problem is the performance of the core, LV ItaniumlD > sucks rocks performance wise compared with Pentium M and it easily@ > exceeds Pentium M heat budgets by a factor of two and the only* > trade has been to reduce the cache size.  D I don't think we can draw any good conclusions on how a Tukwila coreD will do compared to current LV McKinley cores. Look how different PM? and P4 are. Low frequency also contributes to lower power on LVy@ Itanium. I think approx. the same amount speculation drawn about Tukwila can be applied to Rock.m   > > K > >>However there is no simple Itanium core available nor is one likely to nJ > >>surface. The Itanium core could have been a candidate but its too slowL > >>and not nearly compact enough, the Pentium M core for example is 2x the G > >>performance of the Itanium, uses less transistors and puts out lessd	 > >>heat.> > >  > > 8 > > Pentium M core is not 2x the performance of Itanium. > >  > ; > Did I say it was, it is however easily more than half thes7 > performance of Itanium and you could put 4 of them on ; > the same die as Itanium II and still end up with a bettera > powere budget.  D That is a simplification. Dothan has an advantage in Power no doubt,F but lets say that 1.3GHz/3Mb (which has 1117 on SpecInt) Itanium 2 hasB approx. the same performance as a 1.7GHz Dothan. A special purposeC built 1.3GHz/3Mb Itanium may not be that much larger than a Dothan.u   ------------------------------  % Date: Wed, 19 May 2004 17:01:19 +0100e9 From: Andrew Harrison <andrew_._remove_harrison@su_n.com>o+ Subject: Re: The next port for OpenVMS? ;-)d0 Message-ID: <c8g0ci$n7d$1@new-usenet.uk.sun.com>   David Svensson wrote:a  s > Andrew Harrison <andrew_._remove_harrison@su_n.com> wrote in message news:<c8f68f$e5a$1@new-usenet.uk.sun.com>...: >  >>David Svensson wrote:b  E >>And you are right cache is less expensive that the core in terms ofdA >>heat, but this is also relative, Itanium II for example despitep@ >>having a slightly smaller core than Xeon still easily tops outH >>Xeon on heat output while at the same time delivering less performance >>than Xeon does.i >  > F > Xeon is faster on some stuff, and Itanium is faster on other things. >  >   G Itanium is only faster on floating point and this much less interestingn+ than integer in terms if adressable market.a  @ In addition a significant proportion of the HPC apps that are FPB dependent are also GRID/cluster/MPP apps and Itanium loses becauseA although its significantly faster on FP it is possible to rack up>= the same compute capacity using Opteron or x86 processors for0 much less money.  B >>Pentium M on the other hand is more than half the performance of> >>either Xeon or Itanium while only pushing out 25 watts under@ >>1/4 of the heat budget for the Itanium II with the 90 nm units >>pushing out 21 watts.n >  > G > Yes, Pentium M is very power effective. The real interesting questionTC > is how much it can scale with more power, if it can tolerate more G > power. They are most likely a bit clocked down for notebook usage now  > and have slower busses.X >   = The 21 watt number I provided you with was for the 2 GHz part0 built in a 90 nm process.-  9 This would be slightly slower than Opteron running at the : same clock speed and obviously the core size would have to% increase to accomodate 64bit support.m > G >>1.7 GHz Pentium M units are good for over 1000 SPECint while the best"3 >>Itanium result is 1408 and the best Xeon is 1620.1 >  > ; > You usually don't use SPEC when you speak about Sparc. :)U >   8 Its the only benchmark available for all three units and7 we are only talking about CPU's not those CPU's running  in systems.    > L >>>>So if you apply the Tejas/Jayhawk logic to Itanium you end up cancelling7 >>>>it in favour of doing a simpler multi-core Itanium.  >>>  >>>dA >>>Simpler multicore is, according to some reports, in the works,n >>>Tukwila.  >>>r >>A >>Sure but the problem is the performance of the core, LV ItaniumeD >>sucks rocks performance wise compared with Pentium M and it easily@ >>exceeds Pentium M heat budgets by a factor of two and the only* >>trade has been to reduce the cache size. >  > F > I don't think we can draw any good conclusions on how a Tukwila coreF > will do compared to current LV McKinley cores. Look how different PMA > and P4 are. Low frequency also contributes to lower power on LVnB > Itanium. I think approx. the same amount speculation drawn about! > Tukwila can be applied to Rock.o >   , It depends on who is doing the speculation ! > K >>>>However there is no simple Itanium core available nor is one likely to aJ >>>>surface. The Itanium core could have been a candidate but its too slowL >>>>and not nearly compact enough, the Pentium M core for example is 2x the G >>>>performance of the Itanium, uses less transistors and puts out lessJ	 >>>>heat.< >>>y >>>c7 >>>Pentium M core is not 2x the performance of Itanium.- >>>w >>; >>Did I say it was, it is however easily more than half then7 >>performance of Itanium and you could put 4 of them on9; >>the same die as Itanium II and still end up with a betterm >>powere budget. >  > F > That is a simplification. Dothan has an advantage in Power no doubt,H > but lets say that 1.3GHz/3Mb (which has 1117 on SpecInt) Itanium 2 hasD > approx. the same performance as a 1.7GHz Dothan. A special purposeE > built 1.3GHz/3Mb Itanium may not be that much larger than a Dothan.e  B And how do you imagine that special purpose Itanium will manage to8 reduce power and at the same time increase performance ?   Regards  Andrew Harrison    ------------------------------  + Date: Wed, 19 May 2004 17:19:08 +0000 (UTC) - From: lewis@spyder.mitre.org (Keith A. Lewis)u1 Subject: Re: Timestamp format stored in RMS file?t. Message-ID: <c8g4uc$34u$1@newslocal.mitre.org>   Jaan Kronberg <jaan.kronberg@mail.ee> writes in article <opr7x0i8q6xckwek@diablo.uninet.ee> dated Thu, 13 May 2004 17:43:46 +0300:
 >Hi there, >r	 >8 bytes:i >0000 36BD 04FB A200   1-APR-2004 00:00:00.00  L >Could anybody "translate" it to "readable" date without using any built-in  >OpenVMS function?H >Or, alternatively, using Perl standard functions (let's assume I don't : >have any modules and I don't know C - and I really don't)  J Take the bytes (in low-high order because this is VMS) and make yourself aF 64-bit integer.  Divide by 1e7 (10000000).  Now you have the number ofB seconds since the VMS base time, which is 17-NOV-1858 00:00:00.00.  K To get from that to the a readable datetime is left as an exercise for youra  local Gregorian calendar expert.  K >p.s. Actually those bytes _should_ represent April 1st, 2004 00:00:00[.00 t ><-- not sure about that]-   Correct.  0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------  + Date: Wed, 19 May 2004 07:58:13 +0000 (UTC)cP From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)+ Subject: VMS731_FIBRE_SCSI-V0600.DCX_AXPEXEe$ Message-ID: <c8f42l$7jg$1@online.de>  D I see that the .TXT has been changed, reflecting the fact that this E patch is no longer on hold, but the patch itself seems to be missing:s  G May  7 12:56  text/plain       VMS731_FIBRE_SCSI-V0600.DCX_AXPEXE  50Kb,@ May 18 16:43  text/plain       VMS731_FIBRE_SCSI-V0600.txt  67Kb  H (VMS731_FIBRE_SCSI-V0600.DCX_AXPEXE decompresses to the old .TXT saying  that the patch is on hold.)P  = Does anyone know when the patch will be taken off hold again?e  C I signed up for the patch notification at OpenVMS.org; would it be (H possible to include layered products in the announcements?  (I see, for C example, that there are new C and C++ patches for ALPHA available.)w   ------------------------------  % Date: Wed, 19 May 2004 12:46:40 +0100n9 From: Andrew Harrison <andrew_._remove_harrison@su_n.com>o2 Subject: Re: You'll never guess what HP advertised0 Message-ID: <c8fhf1$i01$1@new-usenet.uk.sun.com>   David J. Dachtera wrote:  * > Andrew Harrison SUNUK Consultancy wrote: >  >>Bob Koehler wrote: >>] >>>In article <c7opdj$2a11$1@news.cybercity.dk>, "Karsten Nyblad" <nospam@nospam.com> writes:s >>>  >>>  >>>oO >>>>Now try being HP's upper management.  They have three operating systems foriO >>>>back office:  HP-UX, OpenVMS, and NonStop.  OpenVMS and NonStop are both in P >>>>the market of high availability, and HP-UX is getting some of these features >>>dO >>>>from Tru64.  If HP market all three, then customers will ask what HP really. >>>5I >>>>want and if HP is really committed to any of these operating systems.u >>>s >>>sJ >>>   Who gives a damn about what HP wants?  When I'm buying a system, its* >>>   about what _I_ want, not the vendor. >>>r >  >   > I have to agree with Bob here. > ! > The _CUSTOMER_ is always right.w > ; In an ideal world that would be the case, but is would be ag7 foolish customer who took the view that the vendor willh7 always follow a course of action most beneficial to allp their customers.  6 Hence to need to do due dilligence on what you vendors long term intentions really arep    ? > Show me where "it" ever said, "The vendor is always right"...  >   ; Compaq canning Alpha, HP canning Alpha followons and Tru64, ; the vendors in these cases may not have been right but that  didn't alter the decisions.a  7 Perhaps you could say the vendor isn't always right but2% the vendor always gets that last say.i   RegardsC Andrew Harrison:   ------------------------------  % Date: Wed, 19 May 2004 14:23:40 +0100 * From: Nic Clews <sendspamhere@[127.0.0.1]>2 Subject: Re: You'll never guess what HP advertised' Message-ID: <c8fn8b$j14$1@lore.csc.com>0   Karsten Nyblad wrote:h >  ...nM > When you chose an operating system you want to be sure that you can buy newOL > systems for many years.  Thus you want to be sure that the vendor actuallyI > wants to continue active development and selling systems at competitive.K > prices.  It is no easy decission to move to a new operating system if you.6 > have a million lines of code as many companies have. ...a  B So where do the folks that buy a system at versions released 10-15E years, or more, ago, still run them today and expect them to continue.2 running for the next X years, fit into that model?  E Notwithstanding the issue of hardware availability for maintenance ordG replacement, there are still people _using_ PDP systems, never mind VAXrG at versions that predate common MS-DOS, before the days of 3.11 with notF desire or need to move to a "current" version, so the issue of whether? it, or the company that produces it still exists is irrelevant./  + The easy decision is to stay where you are.r   -- o? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences  nclews at csc dot com    ------------------------------  + Date: Wed, 19 May 2004 06:18:16 +0000 (UTC)g% From: Dan Foster <usenet@evilphb.org>-2 Subject: Re: [OT]:  Maybe SCO is (partially) right6 Message-ID: <slrncalv0p.u6a.usenet@gaia.roc2.gblx.net>  ] In article <slrncal74c.u6a.usenet@gaia.roc2.gblx.net>, Dan Foster <usenet@evilphb.org> wrote:c >iH > Personally, I would find it hard to believe that Linus Torvalds didn't= > act as the major force behind Linux's original development.i >_J > I have seen the first source code I could find (around 0.9 or so) and itI > is certainly small enough and sufficiently simplistic (such as not verylG > granular kernel locking structures) for one person with a few helping  > hands to do it.s  E Slight correction: I have a ~72K tar.gz file of the Linux 0.01 kernel  sources, and it is *SMALL*.r  H 88 files; 45 C, 7 assembly (.s), 31 header, and 5 Makefiles. The C filesB comprises 5929 lines; 5382 lines excluding white space. 4308 lines. excluding the white space and bracketed lines.  H The ~/kernel subdirectory has 18 files, typically about 3K each, and all4 the files are dated between July to September, 1991.  < ~/boot subdirectory has only two files -- both assembler. :)   ~/init? One file. And so forth.3  < I've put it up on my FTP site if you'd like to look at them:  < ftp://ftp.globalcrossing.net/pub/users/dsf/linux-0.01.tar.gz  H The code does indeed look simplistic; that's to be expected from someoneH bored trying to see if he could write an UNIX-like OS and coming up withC a first-pass kernel, sans the userland tools that folks are used tot@ today. I honestly don't think the so-called "study" holds merit.  E I do know that Mr. Torvalds wasn't alone with coding Linux; I seem toiC recall that Theodore T'so helped with the early efforts, around 0.7tK (1992-93 time frame?) or so -- perhaps specializing in the filesystem code?   F There were a few other 'valued contributors' around that time as well,@ but it seems clear that Linus did indeed put up the initial codeJ himself, and had the expertise to discuss it in depth at the time as well.  @ The debate between Mr. Torvalds and Dr. Tanenbaum (URL posted inE previous posting) was about a year after the initial cut of the Linuxi kernel (v0.01).a  G I wonder whom AdTI thinks did the kernel, and why it's impossible for arG large group of enthusiasts to build something UNIX-like? I also imagineoD it's possible to do the same for VMS (e.g. FreeVMS project) but it's> going to be a large order given limited manpower and the size,C functionality, and scope of VMS. Also further hampered by having tot" reverse engineer certain key bits.  E I first had hands-on experience with Linux starting at 1.0.2 or so... H my first deployed production system at an all-Linux employer in 1994 wasG based on the Linux 1.0.9 kernel -- they were upgrading to 1.0.9 from anhE earlier version. Apparently the userland -- mostly GNU stuff -- toolsnE and kernel had stabilized well enough to be usable for production ISPe services at the time.t  G Obligatory VMS reference: I learned VMS before I ever touched UNIX (theH real thing and derivatives) :-)e   -Dan   ------------------------------   Date: 19 May 2004 06:12:47 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>2 Subject: Re: [OT]:  Maybe SCO is (partially) right? Message-ID: <DTiotGxQ0bj6-pn2-gxUdzX88nPds@dave2_os2.home.ours>   E On Wed, 19 May 2004 02:21:03 UTC, GreyCloud <mist@cumulus.com> wrote:oK > Pretty much my sentiments as well regarding M$ funding this book and its iH > research.  Seeing that longhorn has been delayed, M$ will continue to K > FUD linux as much as they can.  Seems that M$ is getting a bit desperate.t  B Frankly, it wouldn't surprise me if there were some code (or code F constructs) from existing Unices within Linux and it wouldn't surprise? me at all if it had been done deliberately. Uh Oh MS black car h	 outside. h   -- , Cheers - Dave.   ------------------------------  % Date: Wed, 19 May 2004 09:51:05 +0200 * From: "Karsten Nyblad" <nospam@nospam.com>2 Subject: Re: [OT]:  Maybe SCO is (partially) right, Message-ID: <c8f3ld$fma$1@news.cybercity.dk>  = "Dave Weatherall" <djw-nothere@nospam.nohow> wrote in message 9 news:DTiotGxQ0bj6-pn2-gxUdzX88nPds@dave2_os2.home.ours...nC > Frankly, it wouldn't surprise me if there were some code (or code H > constructs) from existing Unices within Linux and it wouldn't surprise@ > me at all if it had been done deliberately. Uh Oh MS black car
 > outside.  A True, but I doubt there is enough to make $3 billion a reasonable)J compensation.  Or to make it reasonable to ask for $700/machine in licenseK fee.  The normal behavior in such cases where a company (SCO) thinks that aPK business partner (IBM) has made a minor infringement of copyrights would be K to solve the problem without ever involving the courts.  SCO went strait to 
 the court.   ------------------------------  % Date: Wed, 19 May 2004 13:54:01 +0200x  From: "Dr. Dweeb" <dr@dweeb.com>2 Subject: Re: [OT]:  Maybe SCO is (partially) right- Message-ID: <c8fhsp$1067$1@news.cybercity.dk>i   Dan Foster wrote: C > In article <slrncal74c.u6a.usenet@gaia.roc2.gblx.net>, Dan Fostera > <usenet@evilphb.org> wrote:0 >>B >> Personally, I would find it hard to believe that Linus TorvaldsE >> didn't act as the major force behind Linux's original development.s >>D >> I have seen the first source code I could find (around 0.9 or so)E >> and it is certainly small enough and sufficiently simplistic (suchdF >> as not very granular kernel locking structures) for one person with  >> a few helping hands to do it. >JG > Slight correction: I have a ~72K tar.gz file of the Linux 0.01 kernel  > sources, and it is *SMALL*.e >iD > 88 files; 45 C, 7 assembly (.s), 31 header, and 5 Makefiles. The C > filesnD > comprises 5929 lines; 5382 lines excluding white space. 4308 lines0 > excluding the white space and bracketed lines. >wF > The ~/kernel subdirectory has 18 files, typically about 3K each, and > alla6 > the files are dated between July to September, 1991. >r> > ~/boot subdirectory has only two files -- both assembler. :) >h! > ~/init? One file. And so forth.  >n> > I've put it up on my FTP site if you'd like to look at them: >i> > ftp://ftp.globalcrossing.net/pub/users/dsf/linux-0.01.tar.gz >lB > The code does indeed look simplistic; that's to be expected from	 > someoneuE > bored trying to see if he could write an UNIX-like OS and coming upl > withE > a first-pass kernel, sans the userland tools that folks are used tozB > today. I honestly don't think the so-called "study" holds merit. >>G > I do know that Mr. Torvalds wasn't alone with coding Linux; I seem to>E > recall that Theodore T'so helped with the early efforts, around 0.7dG > (1992-93 time frame?) or so -- perhaps specializing in the filesystem  > code?e >lH > There were a few other 'valued contributors' around that time as well,B > but it seems clear that Linus did indeed put up the initial codeF > himself, and had the expertise to discuss it in depth at the time as > well.g >iB > The debate between Mr. Torvalds and Dr. Tanenbaum (URL posted inG > previous posting) was about a year after the initial cut of the Linuxg > kernel (v0.01).  >eG > I wonder whom AdTI thinks did the kernel, and why it's impossible forr > a0A > large group of enthusiasts to build something UNIX-like? I also 	 > imaginelF > it's possible to do the same for VMS (e.g. FreeVMS project) but it's@ > going to be a large order given limited manpower and the size,E > functionality, and scope of VMS. Also further hampered by having to $ > reverse engineer certain key bits. >fG > I first had hands-on experience with Linux starting at 1.0.2 or so...eF > my first deployed production system at an all-Linux employer in 1994 > washF > based on the Linux 1.0.9 kernel -- they were upgrading to 1.0.9 from > anG > earlier version. Apparently the userland -- mostly GNU stuff -- toolslG > and kernel had stabilized well enough to be usable for production ISPt > services at the time.l >tD > Obligatory VMS reference: I learned VMS before I ever touched UNIX > (the! > real thing and derivatives) :-)  >f > -Dan   Since we are OT.  I I read the MINUX v. LINUX v.1 thread.  So just what was Hurd and whateverIJ became of it.  Is there a GNU kernel? Is it useful and is it actually used by anyone ?d  	 Dr. Dweeb0   ------------------------------    Date: 19 May 2004 07:31:07 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)i2 Subject: Re: [OT]:  Maybe SCO is (partially) right3 Message-ID: <7k7R1z3FJtcB@eisner.encompasserve.org>c  R In article <kpCdnQV3HrHmDzfdRVn-gw@igs.net>, "John Smith" <a@nonymous.com> writes: > F > A study challenging the origins of Linux states that the open-sourceF > software frequently is taken or adapted from material owned by otherM > companies and individuals. It also directly questions Linus Torvalds' claim  > to be the inventor of Linux.  E    If I were Torvalds, I'd get my lawer and have these folks in courto:    pronto.  Anything less could be miscontrued as implicit    acknowledgement.P   ------------------------------  + Date: Wed, 19 May 2004 16:49:16 +0000 (UTC)n% From: Dan Foster <usenet@evilphb.org> 2 Subject: Re: [OT]:  Maybe SCO is (partially) right6 Message-ID: <slrncan3vu.u6a.usenet@gaia.roc2.gblx.net>  F In article <c8fhsp$1067$1@news.cybercity.dk>, Dr. Dweeb <dr@dweeb.com> wrote: > Since we are OT. >dA > So just what was Hurd and whatever became of it. Is there a GNU : > kernel? Is it useful and is it actually used by anyone ?  E GNU Hurd is still around, although it hasn't enjoyed the same sort ofsA success that Linux/FreeBSD/etc. has. You could think of Hurd as ar$ long-term research project of sorts.  * http://www.gnu.org/software/hurd/hurd.html  D Hurd is an OS with a Mach microkernel and GNU tools fleshing out the userland environment.c  F It still has much work to be done although they've bootstrapped the OS< to a somewhat usable state, but still lots of stuff missing.   -Dan   ------------------------------  % Date: Wed, 19 May 2004 11:25:55 -0600d" From: GreyCloud <mist@cumulus.com>2 Subject: Re: [OT]:  Maybe SCO is (partially) right0 Message-ID: <-8GdnY86Aab2BTbd4p2dnA@bresnan.com>   Dave Weatherall wrote:  G > On Wed, 19 May 2004 02:21:03 UTC, GreyCloud <mist@cumulus.com> wrote:- > K >>Pretty much my sentiments as well regarding M$ funding this book and its "H >>research.  Seeing that longhorn has been delayed, M$ will continue to K >>FUD linux as much as they can.  Seems that M$ is getting a bit desperate.a >  > D > Frankly, it wouldn't surprise me if there were some code (or code H > constructs) from existing Unices within Linux and it wouldn't surpriseA > me at all if it had been done deliberately. Uh Oh MS black car   > outside. P >   8 Just don't forget when M$ admitted to screwing Netscape.   ------------------------------  % Date: Wed, 19 May 2004 09:28:59 -0400l# From: "John Smith" <a@nonymous.com> 5 Subject: [OT]: HP earnings reports released yesterdayn, Message-ID: <UrCdneA87sC6_DbdRVn-uA@igs.net>   Index page to financial results.& (link to webcast is also on this page)@ http://www.hp.com/hpinfo/investor/financials/quarters/index.html     Division financial summaryF http://www.hp.com/hpinfo/investor/financials/quarters/2004/q2.html#seg     Geographic sales report I http://www.hp.com/hpinfo/investor/financials/quarters/2004/q2overview.pdfM    4 Some slides which show server sales breakout (pg. 6)L http://www.hp.com/hpinfo/investor/financials/quarters/2004/q2presentation.pd fo    
 SEC 8K filingpC http://www.shareholder.com/Common/Edgar/47217/47217-04-28/04-00.pdf-   ------------------------------   End of INFO-VAX 2004.277 ************************