1 INFO-VAX	Tue, 18 May 2004	Volume 2004 : Issue 275       Contents:> Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info????? Re: Copying tapes  Re: Copying tapes  Re: Copying tapes  Re: Copying tapes  Re: Copying tapes  Re: Copying tapes  Re: Copying tapes  Re: Copying tapes  Re: Copying tapes P Re: DCLER (DCL Enhancement Request) for DIRECTORY /SORT=[CREATED,MODIFIED,...] /. DS20E asks always the date/time when rebooting2 Re: DS20E asks always the date/time when rebooting% Eastern Washington University project ! I know I'm being picky but ...... " POSIX time functions and SYS$TZDIR& Re: POSIX time functions and SYS$TZDIR' Printcap file with ip address and port? + Re: Printcap file with ip address and port? ! Re: Reboot forces Shadowset Merge  Re: SSL in AST-driven programm? ! Re: SUN fails to advertise VMS... ! Re: SUN fails to advertise VMS... ! 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: TCPIP Services V5.4 on OpenVMS/Alpha V7.2-2  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?  F ----------------------------------------------------------------------  % Date: Tue, 18 May 2004 18:12:56 +0100 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> G Subject: Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info????? 0 Message-ID: <c8dg6o$pig$1@new-usenet.uk.sun.com>   Jan van Mastbergen wrote: 7 >>Still the 'IBM Tru64' thing is definetly not right...  > L > Mmm, maybe. Do I remember correctly that Tru64 originated as the love babyM > of a consortium including a.o. DEC and IBM that wanted to produce a unified J > new Unix based on the Mach kernel. It was originally known as OSF-1. Not+ > sure if the rename to Tru64 was DEC only.  >  > Jan     B DEC, IBM, HP and a few others formed the Open Software Foundation,A OSF had as its goals to production of a common "UNIX" OS based as B you say on the Mach Kernel but also incorporating in no particular? order, Motif, DCE, AFS and other bits and pieces each consortia  member had lying around..   B In theory IBM and HP were going to produce OSF based UNIX OE's butA when push came to shove they simply cherry picked the bits of OSF ? they liked and layered them on top of their existing OS's. This > had the great benefit of appearing to be OSF compliant without7 actually breaking anything for your existing customers.   > That left dear old Digital who actually went the whole hog and@ did OSF based OE, in the process breaking most of everything for: their existing customers who were also labouring under the= quaint idea that Digital would continue to support MIPS based  systems.  > Unsurpisingly given the juxtaposition of buzzwords in its name= "Open" Software and "Foundation" clearly designed to generate = suspicion in the more cynical users OSF collapsed or "merged" > with UNIX International an organisation entirly devoid of Open or Foundation in its name.  ? When OSF died a well deserved death Digital changed the name of A OSF-1 to DECUNIX quickly followed by another rebranding to Tru64.    Its now called HP-UX   Regards  Andrew Harrison    ------------------------------  % Date: Tue, 18 May 2004 08:21:25 +0100 - From: Roy Omond <Roy.Omond@BlueBubble.UK.Com>  Subject: Re: Copying tapes* Message-ID: <2gtrt1F6e930U1@uni-berlin.de>   David J. Dachtera wrote: > Denny Rich wrote:  > E >>I seem to remember (dimly) that in the olden days, with tu78/ta79s, A >>connected through HSCs, it was possible to mount  a source tape B >>Files11 (backup tape full of save sets), and a target tape  alsoE >>Files11, and then "$ copy source:*.* target:"  (or was I doing this  >>with HSC backup?)  >>@ >>Anyway, the obvious would happen.  (IIRC...and thats a big if) >>D >>When I try this with a couple of backup tapes on TK89s, they won't >>copy a single byte.  >>D >>Short of laying out each saveset and then putting it back onto the? >>target tape, is there an easy way to duplicate a backup tape?  >  > : > If you have the option, re-write your backup tapes using9 > /BLOCKSIZE=32256 to stay within RMS's 32767-byte limit.  > D > Then, you can MOUNT the source and target tapes /FOREIGN using theG > appropriate /BLOCKSIZE parameter, and copy the datasets one at a time  > for each saveset:  >  > 1. Header labels > 2. Saveset data  > 3. Trailer labels. > J > Use SET MAGTAPE/END after the last trailer labels after the last saveset- > to properly mark the logical end of volume.    No, no, no !  G If your backups have been written to stay within the 32,767-byte limit, E then you don't need to futz around with foreign tapes as above.  Your G 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:    	 Roy Omond  Blue Bubble Ltd.   ------------------------------  % Date: Tue, 18 May 2004 10:15:01 +0100 ; From: "Mark Iline - Info-VAX account" <ivax@meng.ucl.ac.uk>  Subject: Re: Copying tapes: Message-ID: <002301c43cb8$993a99a0$d05f0352@HP19054647700>  / From: "Roy Omond" <Roy.Omond@BLUEBUBBLE.UK.COM>   I > If your backups have been written to stay within the 32,767-byte limit, 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:   + Isn't there a potential problem with this ?   J My recollection from a long time ago, playing with 1600BPI tapes, was thatL Backup deals with errors writing to tape in a way that's not ANSI compliant.  G If the medium you're copying from had experienced no errors when Backup G wrote to it, what you're saying would work fine. However, if Backup had K performed error recovery, some data would be missing from the savesets that  Copy copied.  I This wasn't a problem with TK50 media (or probably 6250BPI tapes), as the J drives handled the write error recovery themselves. However, 1600BPI tapesF would generally have experienced at least one error, and caused Copy a problem.     Mark  0 Mark Iline, UCL Mech Eng. ivax"at"meng.ucl.ac.uk   ------------------------------  % Date: Tue, 18 May 2004 10:45:17 +0100 - From: Roy Omond <Roy.Omond@BlueBubble.UK.Com>  Subject: Re: Copying tapes* Message-ID: <2gu4aqF6t36dU1@uni-berlin.de>  $ Mark Iline - Info-VAX account wrote:  1 > From: "Roy Omond" <Roy.Omond@BLUEBUBBLE.UK.COM>  > I >>If your backups have been written to stay within the 32,767-byte limit, 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:  >  > - > Isn't there a potential problem with this ?  > L > My recollection from a long time ago, playing with 1600BPI tapes, was thatN > Backup deals with errors writing to tape in a way that's not ANSI compliant. > I > If the medium you're copying from had experienced no errors when Backup I > wrote to it, what you're saying would work fine. However, if Backup had M > performed error recovery, some data would be missing from the savesets that  > Copy copied. > K > This wasn't a problem with TK50 media (or probably 6250BPI tapes), as the L > drives handled the write error recovery themselves. However, 1600BPI tapesH > would generally have experienced at least one error, and caused Copy a
 > problem.  H Well, the original poster did mention TK89 (presumably a typo for TZ89).  D I have never seen BACKUP (or any other method in *base* VMS) recoverE from parity errors on *any* helical-scan tape media (that's why these F specialised data recovery companies can charge lots of money for these cases).   F In any case, I was trying to point out the fact that mounting the tapeB /foreign is neither necessary nor a good idea in the case that the3 savesets have been written with blocksize < 32,767.   @ The Saveset Manager software for all other cases is an excellent= solution, and as far as I remember is not all that expensive.   	 Roy Omond  Blue Bubble Ltd.   ------------------------------  % Date: Tue, 18 May 2004 12:07:50 +0200 * From: Paul Sture <nospam@sture.homeip.net> Subject: Re: Copying tapes* Message-ID: <2gu5joF6u1sdU1@uni-berlin.de>   Roy Omond wrote:& > Mark Iline - Info-VAX account wrote: > 2 >> From: "Roy Omond" <Roy.Omond@BLUEBUBBLE.UK.COM> >>K >>> If your backups have been written to stay within the 32,767-byte limit, I >>> then you don't need to futz around with foreign tapes as above.  Your K >>> 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: >> >> >>. >> Isn't there a potential problem with this ? >>I >> My recollection from a long time ago, playing with 1600BPI tapes, was   >> that E >> Backup deals with errors writing to tape in a way that's not ANSI  
 >> compliant.  >>J >> If the medium you're copying from had experienced no errors when BackupJ >> wrote to it, what you're saying would work fine. However, if Backup hadJ >> performed error recovery, some data would be missing from the savesets  >> that  >> Copy copied.  >>L >> This wasn't a problem with TK50 media (or probably 6250BPI tapes), as theH >> drives handled the write error recovery themselves. However, 1600BPI  >> tapesI >> would generally have experienced at least one error, and caused Copy a  >> problem.  >  > J > Well, the original poster did mention TK89 (presumably a typo for TZ89). > 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).  >   I I've been lucky then. On a few occasions I have managed to use COPY from  D a normally (not foreign) mounted helical-scan tape, when BACKUP has  repeatedly failed with:   7 READERRS,  excessive error rate reading 'save-set-spec'   H > In any case, I was trying to point out the fact that mounting the tapeD > /foreign is neither necessary nor a good idea in the case that the5 > savesets have been written with blocksize < 32,767.  >   > I've adopted a 32,556 blocksize as standard practice, as when I selectively restoring, it can be a lot easier and less time consuming to   drop the saveset to disk first.   B > The Saveset Manager software for all other cases is an excellent? > solution, and as far as I remember is not all that expensive.  >    ------------------------------  % Date: Tue, 18 May 2004 11:37:53 +0100 - From: Roy Omond <Roy.Omond@BlueBubble.UK.Com>  Subject: Re: Copying tapes* Message-ID: <2gu7d9F6raksU1@uni-berlin.de>  0 Paul Sture hat mit Elan und Eleganz geschrieben:   > Roy Omond wrote: >  > [...snip...] > G >> I have never seen BACKUP (or any other method in *base* VMS) recover H >> from parity errors on *any* helical-scan tape media (that's why theseI >> specialised data recovery companies can charge lots of money for these 
 >> cases). >> > K > I've been lucky then. On a few occasions I have managed to use COPY from  F > a normally (not foreign) mounted helical-scan tape, when BACKUP has  > repeatedly failed with:  > 9 > READERRS,  excessive error rate reading 'save-set-spec'   @ Hmmm... I'm skeptical - see below (yes, I know it's not on tape)   $ back/log x.com x.x/save  Copied DISK$DATA:[ROY]X.COM;4  Copied DISK$DATA:[ROY]X.COM;3  Copied DISK$DATA:[ROY]X.COM;2 % $ set file/attr=(lrl:512,mrs:512) x.x  $ back/lis x.x/save  Listing of save set(s)  " Error reading DISK$DATA:[ROY]X.X;1 Software block CRC error Invalid block size in save set Invalid record size in save set  Save set:          X.X Written by:        ROY" UIC:               [001002,000001]* Date:              18-MAY-2004 12:25:45.05* Command:           BACK/LOG X.COM X.X/SAVE- Operating system:  OpenVMS Alpha version V7.3  BACKUP version:    AXP72R001 CPU ID register:   80000000  Node name:         _XXXX:: Written on:        _XXXX$DKA0: Block size:        32256 Group size:        10  Buffer count:      57    Invalid record size in save set ; Excessive error rate reading DISK$DATA:[ROY]X.X;1	<--- note  Software header CRC error  %BACKUP-I-OPERSPEC& Operator assistance has been requested   Interrupt    $ copy/log x.x z.z@ DISK$DATA:[ROY]X.X;1 copied to DISK$DATA:[ROY]Z.Z;1 (126 blocks)  < Paul, you sure that this wasn't the case in your situation ?  ? I have *never* seen BACKUP recover from "real" parity errors on ; any helical-scan tape media, but then again, maybe I'm just $ naturally and skillfully unlucky :-)  3 But enough of this thread - it's getting boring ;-)   	 Roy Omond  Blue Bubble Ltd.   ------------------------------  % Date: Tue, 18 May 2004 13:40:11 +0200 * From: Paul Sture <nospam@sture.homeip.net> Subject: Re: Copying tapes* Message-ID: <2gub0sF6uidtU1@uni-berlin.de>   Roy Omond wrote:2 > Paul Sture hat mit Elan und Eleganz geschrieben: >  >> 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).  >>>  >>G >> I've been lucky then. On a few occasions I have managed to use COPY  H >> from a normally (not foreign) mounted helical-scan tape, when BACKUP  >> has repeatedly failed with: >>: >> READERRS,  excessive error rate reading 'save-set-spec' >  > B > Hmmm... I'm skeptical - see below (yes, I know it's not on tape) >  > $ back/log x.com x.x/save  > Copied DISK$DATA:[ROY]X.COM;4  > Copied DISK$DATA:[ROY]X.COM;3  > Copied DISK$DATA:[ROY]X.COM;2 ' > $ set file/attr=(lrl:512,mrs:512) x.x  > $ back/lis x.x/save  > Listing of save set(s) > $ > Error reading DISK$DATA:[ROY]X.X;1 > Software block CRC error  > Invalid block size in save set! > Invalid record size in save set  > Save set:          X.X > Written by:        ROY$ > UIC:               [001002,000001], > Date:              18-MAY-2004 12:25:45.05, > Command:           BACK/LOG X.COM X.X/SAVE/ > Operating system:  OpenVMS Alpha version V7.3  > BACKUP version:    AXP72R001 > CPU ID register:   80000000  > Node name:         _XXXX::  > Written on:        _XXXX$DKA0: > Block size:        32256 > Group size:        10  > Buffer count:      57  > ! > Invalid record size in save set @ > Excessive error rate reading DISK$DATA:[ROY]X.X;1    <--- note > Software header CRC error  > %BACKUP-I-OPERSPEC( > Operator assistance has been requested >  Interrupt >  > $ copy/log x.x z.zB > DISK$DATA:[ROY]X.X;1 copied to DISK$DATA:[ROY]Z.Z;1 (126 blocks) > > > Paul, you sure that this wasn't the case in your situation ? >    Positive it wasn't.   A > I have *never* seen BACKUP recover from "real" parity errors on = > any helical-scan tape media, but then again, maybe I'm just & > naturally and skillfully unlucky :-) >   D OK, my memory fails me as to whether they were "real" parity errors.  F I've tended to assume that when I managed with COPY but not BACKUP it L was a function of luck and COPY somehow hitting the tape in a different way.  5 > But enough of this thread - it's getting boring ;-)  >    OK. Toodle pip,.   ------------------------------    Date: 18 May 2004 08:04:05 -0600 From: briggs@encompasserve.org Subject: Re: Copying tapes3 Message-ID: <PESxi6aTUbn0@eisner.encompasserve.org>   h In article <c8bsi9$70r$1@news.wplus.net>, "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk> writes:M > "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in message 2 > news:40A97587.FE8820D9@NeOaSrPtAhMlNiOnWk.net... >> Denny Rich wrote: >> >H >> > I seem to remember (dimly) that in the olden days, with tu78/ta79s,D >> > connected through HSCs, it was possible to mount  a source tapeE >> > Files11 (backup tape full of save sets), and a target tape  also H >> > Files11, and then "$ copy source:*.* target:"  (or was I doing this >> > with HSC backup?) >> >C >> > Anyway, the obvious would happen.  (IIRC...and thats a big if)  >> >G >> > When I try this with a couple of backup tapes on TK89s, they won't  >> > copy a single byte. >> >G >> > Short of laying out each saveset and then putting it back onto the B >> > target tape, is there an easy way to duplicate a backup tape? >>; >> If you have the option, re-write your backup tapes using : >> /BLOCKSIZE=32256 to stay within RMS's 32767-byte limit. >>E >> Then, you can MOUNT the source and target tapes /FOREIGN using the H >> appropriate /BLOCKSIZE parameter, and copy the datasets one at a time >> for each saveset: >> >> 1. Header labels  >> 2. Saveset data >> 3. Trailer labels.  >>K >> Use SET MAGTAPE/END after the last trailer labels after the last saveset . >> to properly mark the logical end of volume. >> > <snip> > J > One person I worked with, claimed to have physically snapped a couple ofK > tapes on older tape drives by not setting the end of tape marker and then B > later still trying to copy off of the tape beyond the last file.  D Well yes.  I've run off the end of a few improperly terminated tapesF in my time.  Fortunately, the tape was simply taped to the reel ratherF than being bound strongly.  So nothing bad happened.  I wound 30 or 40J feet of tape back onto the take up reel (to get well past the EOT marker)," did a mid-reel load and rewound.    G Note that the [optical] end of tape marker won't do anything to prevent C you from _reading_ off the end of the tape.  It takes a logical end E of volume indication to tell software that it's time to stop reading.   ; BACKUP tapes will have a reliable end of volume indication.   E The optical end of tape marker is supposed to stop you from _writing_ C off the end of the tape.  BACKUP, for instance, notices the marker, > writes an end of volume indication and switches to a new reel.  F If you're dealing with multi-volume BACKUP save sets and the copied-toB reel of tape is slightly shorter than the copied-from reel of tapeF then blindly copying save sets as is recommended above will ignore theE optical end of tape marker and is very likely to write off the end of  the destination reel.    	John Briggs 	    ------------------------------    Date: 18 May 2004 08:08:19 -0600 From: briggs@encompasserve.org Subject: Re: Copying tapes3 Message-ID: <xZVWvZ5lWMR1@eisner.encompasserve.org>   W In article <2gu5joF6u1sdU1@uni-berlin.de>, Paul Sture <nospam@sture.homeip.net> writes: @ > I've adopted a 32,556 blocksize as standard practice, as when   J 32256 surely.  Though I think that 32556 is functionally identical (rounds7 down to the next lower multiple of 512 which is 32256).    	John Briggs   ------------------------------  % Date: Tue, 18 May 2004 12:42:41 -0400 < From: "Peter Weaver" <WeaverConsultingServices@sympatico.ca> Subject: Re: Copying tapes* Message-ID: <2guso2F6vsoeU1@uni-berlin.de>   Denny Rich wrote:  >...D > Short of laying out each saveset and then putting it back onto the? > target tape, is there an easy way to duplicate a backup tape?  >...  ? On Freeware CD 5 you can find the Tapecopy program (mirrored at H http://h71000.www7.hp.com/freeware/freeware50/tapecopy/). If you need anD Alpha version then a quick Google search will find a post on the few small changes you need to make.    --   Peter Weaver Weaver Consulting Services Inc.  Canadian VAR for CHARON-VAX  www.weaverconsulting.ca    ------------------------------  # Date: Tue, 18 May 2004 17:33:58 GMT 1 From: Michael Austin <maustin@firstdbasource.com> Y Subject: Re: DCLER (DCL Enhancement Request) for DIRECTORY /SORT=[CREATED,MODIFIED,...] / 2 Message-ID: <40AA4903.A704894A@firstdbasource.com>   Peter Weaver wrote:    > Michael Austin wrote:  > > ... ; > > Ditto!!  looks like the Unix cut command on steroids...  > E > You might notice in the thread "Suggestion for TYPE command" that I  > posted the solution; > E > $ merge/stable/nocheck sys$manager:operator.log tt:/spec=sys$input: * > /field=(name=first50,position=1,size=50) > /data=first50  >  > and someone else posted; >  > bash$ cut -c 10-50 login.com > @ > Both do the same thing, but merge works on VMS out of the box. >  > > ... D > > Here is a more efficient way to do this without using tmp files: > >..., > > Ya just gotta love the pipe command!! :) > >... > = > You must have a more efficient version of PIPE than I do :)  >   D Unless yours is different from 7.3 or 7.3-1, then no.. I am probablyD just more *proficient* :) :) :)  Some of my co-workers called me Mr.D Pipe..  It is really amazing what you can do with it... and when GuyC Peleg (DCL Engineer) gets me real loop control (for, while, etc..), E there are a ton of things I will be able to do with it... :)    While H Unix has it's weeknesses, contrary to popular belief (especially in this8 newsgroup) there are a lot of really good tools in Unix.   Michael Austin Consultant - Available 816-373-8572 816-728-3080 (Mobile)    >  > -- > Peter Weaver! > Weaver Consulting Services Inc.  > Canadian VAR for CHARON-VAX  > www.weaverconsulting.ca    ------------------------------    Date: 18 May 2004 03:24:43 -0700: From: luc.van.calster@kender-thijssen.be (Luc Van Calster)7 Subject: DS20E asks always the date/time when rebooting = Message-ID: <2c4469c6.0405180224.72006ba5@posting.google.com>    Hello,  4 We have a problem with 2x DS20E's with VMS V7.2-1H2.M When we reboot the machine, VMS asks always the date & time. For our customer L this is a problem because these are production machines, so when the machineN reboots automatically (some kind of hardware crash for example), there must be< always somebody near the console to type in the date & time.N The 'SETTIME' parameter is "0", so VMS can't possibly ask for the date & time.= We replaced the battery on the motherboard also, no solution. P I found on the Internet an article about the command 'SET TIME' & an issue aboutF VMS being up for more than 300 days but this gives no solution either.B If somebody have a similar problem, any help would be appreciated.   Thank's in advance,  luc    ------------------------------  % Date: Tue, 18 May 2004 13:08:08 +0100 - From: John Laird <nospam@laird-towers.org.uk> ; Subject: Re: DS20E asks always the date/time when rebooting 8 Message-ID: <61vja0hvoihkhu9d18i38qq90dvjv8udql@4ax.com>  J On 18 May 2004 03:24:43 -0700, luc.van.calster@kender-thijssen.be (Luc Van Calster) wrote:   O >The 'SETTIME' parameter is "0", so VMS can't possibly ask for the date & time.   K It can and will if it thinks the battery clock is not trustworthy.  As well K as SETTIME, read up on TIMEPROMPTWAIT.  Try setting that to a "don't prompt K or not for long" value and see what the system time is after booting.  This  may or may not confirm...   > >We replaced the battery on the motherboard also, no solution.  C ... that most likely something is still wrong in this area, anyway.    --  ; Most Wanted?  Why not keep them when they're photographed?     Mail john rather than nospam...    ------------------------------    Date: 18 May 2004 08:52:36 -0700) From: mail@sanface.com (SANFACE Software) . Subject: Eastern Washington University project= Message-ID: <8c682947.0405180752.3768e918@posting.google.com>   E As budget restrictions and resources grow tighter, Eastern Washington 5 http://www.ewu.edu/ University has chosen Txt2pdf-PRO ; http://www.sanface.com/txt2pdfPRO.html as a tool to enhance ! productivity and reduce expenses.   F Each of our student, financial, and loan management enterprise systemsB generates nightly reports that are distributed across campus. WithA 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   = With Txt2pdf-PRO, we are able to reduce expenses and increase @ productivity in each of the above areas. Txt2pdf-PRO runs on ourC mainframe OpenVMS system. However, as Txt2pdf-PRO is cross-platform E and can run on any of our servers, we are guaranteed that it will run E on future servers and operating systems and that we can scale its use C to an enterprise level as its functionality is leveraged to benefit  Eastern Washington University.   ------------------------------  % Date: Tue, 18 May 2004 11:07:46 -0400 # From: "John Smith" <a@nonymous.com> * Subject: I know I'm being picky but ......, Message-ID: <laWdnUyUNvtTuzfdRVn-jg@igs.net>  7 At http://h71000.www7.hp.com/openvms/products/clusters/   B OpenVMS clusters are headlined as "World's Best Cluster Software".   while at  : http://welcome.hp.com/country/us/en/prodserv/software.html  J only HP-UX and Linux are touted as 'High Availability & Disaster Tolerant' (under the Clusters heading).   J The 'High Availability & Disaster Tolerant Solutions' link (under the High* Availability heading) leads only to HP-UX.    I Truth in advertising (which HP seldom seems to deal with...you figure out K which I'm refering to) would seem to dictate that disaster tolerance & high 8 availability ought to be promoted thusly on the HP site:  G Best Choice - OpenVMS or NSK depending on your needs, recovery times in H seconds, geographic distribution requirements, and a desire to keep your data 'clean' and consistent.  C Better Choice - Tru64, if you are looking for a unix solution today   = Good Choice - HP-UX today, perhaps eventually a Better Choice   3 You Need Your Head Examined Choice - Linux, Windows    ------------------------------    Date: 18 May 2004 04:03:22 -0700* From: RaoulGough@yahoo.co.uk (Raoul Gough)+ Subject: POSIX time functions and SYS$TZDIR = Message-ID: <a3390f41.0405180303.45dfa796@posting.google.com>   E I'm having trouble using the POSIX time functions when SYS$TZDIR is a ? search list (i.e. has multiple equivalence values). The trouble @ relates only to timezones that are defined in sub-directories of@ SYS$TZDIR, such as ":US/Eastern" or ":Australia/Queensland", and8 disappears if I define SYS$TZDIR to have only one value.  9 This seems very weird to me. I don't think we've modified E SYS$STARTUP:VMS$INITIAL-050_LIB.COM, so we're using the default value 6 of SYS$TZDIR, which points to [.USER] and [.SYSTEM] inD SYS$SYSROOT:[SYS$ZONEINFO]. On the other hand, the US timezones mustE be very heavily used, so I would certainly expect them to work out of , the box. Can anyone explain what's going on?  ? Here are some test runs of a program that exercises tzset (code  included below):   $ show log sys$tzdirE    "SYS$TZDIR" = "SYS$SYSROOT:[SYS$ZONEINFO.USER]" (LNM$SYSTEM_TABLE) -         = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM]"  $!5 $! Try timezone from top-level directory. No problem.  $! $ mc []test_tzset :CET
 tzname[0] MET  tzname[1] MET DST  timezone -3600
 daylight 1 $!9 $! Try timezone from US sub-directory. Results are wrong.  $! $ mc []test_tzset :US/Eastern 
 tzname[0] GMT 	 tzname[1] 
 timezone 0
 daylight 0 $!8 $! SYS$TZDIR logical with only one value. Fixes problem. $!4 $ define sys$tzdir SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM] $ mc []test_tzset :US/Eastern 
 tzname[0] EST 
 tzname[1] EDT  timezone 18000
 daylight 1 $    --8<----- Code begins --8<-----    #include <time.h>  #include <stdio.h> #include <stdlib.h>   # int main (int argc, char *argv[]) {    if (argc > 1) {         setenv ("TZ", argv[1], 1);   }   
   tzset();  '   printf ("tzname[0] %s\n", tzname[0]); '   printf ("tzname[1] %s\n", tzname[1]); &   printf ("timezone %ld\n", timezone);%   printf ("daylight %d\n", daylight);  }    --   Raoul Gough.   ------------------------------  % Date: Tue, 18 May 2004 14:08:55 +0100 - From: Roy Omond <Roy.Omond@BlueBubble.UK.Com> / Subject: Re: POSIX time functions and SYS$TZDIR * Message-ID: <2gug8fF6rb7qU1@uni-berlin.de>   Raoul Gough wrote:  G > I'm having trouble using the POSIX time functions when SYS$TZDIR is a A > search list (i.e. has multiple equivalence values). The trouble B > relates only to timezones that are defined in sub-directories ofB > SYS$TZDIR, such as ":US/Eastern" or ":Australia/Queensland", and: > disappears if I define SYS$TZDIR to have only one value. > ; > This seems very weird to me. I don't think we've modified G > SYS$STARTUP:VMS$INITIAL-050_LIB.COM, so we're using the default value 8 > of SYS$TZDIR, which points to [.USER] and [.SYSTEM] inF > SYS$SYSROOT:[SYS$ZONEINFO]. On the other hand, the US timezones mustG > be very heavily used, so I would certainly expect them to work out of . > the box. Can anyone explain what's going on? > A > Here are some test runs of a program that exercises tzset (code  > included below): >  > $ show log sys$tzdirG >    "SYS$TZDIR" = "SYS$SYSROOT:[SYS$ZONEINFO.USER]" (LNM$SYSTEM_TABLE) / >         = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM]"    [... rest snipped ...]  - Hi Raoul (yes, I am aware of this problem ;-)   E The SYS$TZDIR logical name changed at VMS 7.3 - as far as I can tell, B there's no mention of this change in the Release Notes.  The C-RTL@ documentation still assumes the logical name to be equivalent to> SYS$COMMON:[SYS$ZONEINFO.SYSTEM], which, as your tests confirmD makes "tzset" function as documented when the logical name SYS$TZDIR* is set to that value (even in /USER-mode).  @ I consider this a bug introduced with VMS 7.3, and not addressed$ by any fix or workaround since then.  	 Roy Omond  Blue Bubble Ltd.   ------------------------------  % Date: Tue, 18 May 2004 11:58:39 -0400 " From: "Hal Kuff" <kuff@tessco.com>0 Subject: Printcap file with ip address and port?- Message-ID: <c8dbr9$8v6@library2.airnews.net>    LTA908|lta908:\ /         :lf=/TCPIP$LPD_ROOT/000000/LTA908.LOG:\          :lp=LTA908:\         :rm=10.30.6.19,9102:\          :rp=text:\#         :sd=/TCPIP$LPD_ROOT/LTA908:  #       K How do I get a port number in here... I need 9102 as oposed to the standard  9100 ?   ------------------------------  # Date: Tue, 18 May 2004 17:02:04 GMT 1 From: Michael Austin <maustin@firstdbasource.com> 4 Subject: Re: Printcap file with ip address and port?1 Message-ID: <40AA4189.BDD37F1@firstdbasource.com>    Hal,  N I am guessing by the fact you mention  TCPIP$LPD_ROOT that you are using TCPIPN Services. Using LPD usually means that there is already a print que on anotherN system that has all of that information in it.  So you are only telling LPD toD go to system x and connect to printer y and it handles the port etc.  K Are you trying to create a local print queue that goes to a laserjet, etc.. H networked printer?  If so, then you might want to configure it this way:   example:M @sys$startup:tcpip$config  -- configure telnetsym under Server services.  LPD  under Client (not necessary)   $ INITIALIZE    /QUEUE -5                          /PROCESSOR=TCPIP$TELNETSYM - !                          /START - 8                          /DEFAULT=(FEED,FORM=<someform>)0                          /ON="10.30.6.19:9102" -"                          <QUENAME>   Now, just print/que=<quename>    Michael Austin.  Consultant: Now Available  816-373-8572   Hal Kuff wrote:    > LTA908|lta908:\ 1 >         :lf=/TCPIP$LPD_ROOT/000000/LTA908.LOG:\  >         :lp=LTA908:\ >         :rm=10.30.6.19,9102:\  >         :rp=text:\% >         :sd=/TCPIP$LPD_ROOT/LTA908:  > #  > M > How do I get a port number in here... I need 9102 as oposed to the standard  > 9100 ?   ------------------------------    Date: 18 May 2004 02:33:20 -0700% From: Bart.Zorn@xs4all.nl (Bart Zorn) * Subject: Re: Reboot forces Shadowset Merge= Message-ID: <a98cd882.0405180133.450433e2@posting.google.com>   T The next question is thus: can I safely stop the Job Controller from SYSHUTDWN.COM ?  	 Bart Zorn   h Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<SEEuw1HkkchG@eisner.encompasserve.org>...{ > In article <40A97204.6F5171EB@NeOaSrPtAhMlNiOnWk.net>, "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> writes:  > > John Santos wrote: >  yK > >> You only need to dismount on the node that is rebooting.  If the queueoJ > >> manager is running on the node that is rebooting, you need to fail itG > >> over to the other node.  (I always thought this was automatic????)SJ > >> If the queue manager is running on the other node, then it can't have* > >> any open files on the rebooting node. > > L > > True. If the queue manager is enabled to run on any node of the cluster,I > > the shutdown procedure should make it fail over to the surviving nodeoL > > (queue processing continues uninterrupted). In that case, the local nodeL > > would no longer see the queue database as an open file, and the DISMOUNT > > should go cleanly. > A > Actually, the Job Controller process holds QMAN$MASTER.DAT open.7 > even on nodes where the Queue Manager is not running.S > ' > SYSMAN> do search tie.tmp job_control 4 > %SYSMAN-I-OUTPUT, command execution on node NODE_16 > JOB_CONTROL     2020020F  [SYSEXE]QMAN$MASTER.DAT;364 > %SYSMAN-I-OUTPUT, command execution on node NODE_26 > JOB_CONTROL     2060020F  [SYSEXE]QMAN$MASTER.DAT;36	 > %SYSMAN   + -I-OUTPUT, command execution on node NODE_3-6 > JOB_CONTROL     2080020F  [SYSEXE]QMAN$MASTER.DAT;364 > %SYSMAN-I-OUTPUT, command execution on node NODE_46 > JOB_CONTROL     20C0010F  [SYSEXE]QMAN$MASTER.DAT;364 > %SYSMAN-I-OUTPUT, command execution on node NODE_56 > JOB_CONTROL     21C00410  [SYSEXE]QMAN$MASTER.DAT;36 > SYSMAN> do show sys/noproc4 > %SYSMAN-I-OUTPUT, command execution on node NODE_1L > OpenVMS V7.3  on node NODE_1  17-MAY-2004 20:30:17.16  Uptime  25 04:43:364 > %SYSMAN-I-OUTPUT, command execution on node NODE_2N > OpenVMS V7.3-1  on node NODE_2  17-MAY-2004 20:31:05.66  Uptime  25 01:50:174 > %SYSMAN-I-OUTPUT, command execution on node NODE_3L > OpenVMS V7.3  on node NODE_3  17-MAY-2004 20:31:44.45  Uptime  25 01:49:284 > %SYSMAN-I-OUTPUT, command execution on node NODE_4N > OpenVMS V7.3-1  on node NODE_4  17-MAY-2004 20:32:01.32  Uptime  21 13:46:524 > %SYSMAN-I-OUTPUT, command execution on node NODE_5M > OpenVMS V7.3-2  on node NODE_5  17-MAY-2004 20:31:42.91  Uptime  3 11:50:59l	 > SYSMAN>.   ------------------------------  % Date: Mon, 17 May 2004 14:23:53 -0500h! From: Dan Moore <dmoore@sosu.edu>h( Subject: Re: SSL in AST-driven programm?+ Message-ID: <k18qc.2$tv3.0@news.onenet.net>.  > Have a look at STUNNEL. It can wrap SSL around standard TCPIP $ applications. http://www.stunnel.org  C It's on the OpenVMS Open Source CD. I've been really happy with it.tH You will also need SSL installed and configured properly (Also included  on OpenVMS distributions).  ( I can send you more info if you need it.   Dani   Valentin Likoum wrote: > Hello all, > K >   We have a TCPIP server AST-driven programm. Now we need to  fasten SSL  C > to it. After reading OpenSSL API docs I realized that it's not a t > straight task.H >   HP OpenSSL for OpenVMS manual says that it's possible to use qio[w] C > calls with SSL API (via BIO calls) but it's not clear how and no   > examples are given.sH >   And the most important: SSL_read and SSL_write calls don't have and B > AST routine parameter and no such a beast as ssl$qio[w] exist :)H >   Have anybody implemented something like it? Any expirience to share? >  >   Thank you.   ------------------------------  % Date: Tue, 18 May 2004 10:08:55 +0100pO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>n* Subject: Re: SUN fails to advertise VMS...0 Message-ID: <c8cjr7$jgl$1@new-usenet.uk.sun.com>   Bob Ceculski wrote: e > "Rudolf Wingert" <win@fom.fgan.de> wrote in message news:<004f01c43bda$37f503d0$994614ac@wat153>...  >  >>Hello, >>I >>Hey Andrew, could you tell me which Virus, Worm and Trojaner did attackuI >>OpenVMS within the last 13 years? Our OpenVMS systems where never under J >>attack! Also would you say, that Sun is able to build a cluster with 128J >>or more nodes? With a distance between the nodes over 10.000 kilometers?F >>That is what Sun must have, if they would like to migrate OpenVMS to
 >>Solaris. >> >>Best regards R. Wingerti >  > 9 > all Andrew can do is try to try to get people to ignoret7 > the CERTs and by trying to get people to believe thath8 > the vms group doesn't post certs, but how can you post" > something that doesn't exist? :)  8 Firstly it is BS to claim that they do not exist because: HP and 3rd party documentaion confirms that they do exist.  6 The POP hole for example did/does exist but no posting was made to CERT.o  # So that was your first piece of BS.e  ; Secondly even when postings have been made for example when ; OpenVMS has been vunerable to a generic attack such as LANDr& or Teardrop they have been inaccurate.  ! That was your second piece of BS.a  < Why persist with this rubbish, you have been caught out over; and over again and basically lack the limbs to stand on butx> regretably you persist. Rather like the Knight in Monty Python and the Holy Grail.B   regards  Andrew Harrison-   ------------------------------    Date: 18 May 2004 08:33:58 -0700( From: bob@instantwhip.com (Bob Ceculski)* Subject: Re: SUN fails to advertise VMS...= Message-ID: <d7791aa1.0405180733.781bcd0a@posting.google.com>y   Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<c8cjr7$jgl$1@new-usenet.uk.sun.com>...  > Bob Ceculski wrote:eg > > "Rudolf Wingert" <win@fom.fgan.de> wrote in message news:<004f01c43bda$37f503d0$994614ac@wat153>...  > > 
 > >>Hello, > >>K > >>Hey Andrew, could you tell me which Virus, Worm and Trojaner did attacktK > >>OpenVMS within the last 13 years? Our OpenVMS systems where never undersL > >>attack! Also would you say, that Sun is able to build a cluster with 128L > >>or more nodes? With a distance between the nodes over 10.000 kilometers?H > >>That is what Sun must have, if they would like to migrate OpenVMS to > >>Solaris. > >> > >>Best regards R. Wingerte > : > Firstly it is BS to claim that they do not exist because< > HP and 3rd party documentaion confirms that they do exist. > 8 > The POP hole for example did/does exist but no posting > was made to CERT.  > % > So that was your first piece of BS., > = > Secondly even when postings have been made for example whene= > OpenVMS has been vunerable to a generic attack such as LAND ( > or Teardrop they have been inaccurate. > # > That was your second piece of BS.e > > > Why persist with this rubbish, you have been caught out over= > and over again and basically lack the limbs to stand on butC@ > regretably you persist. Rather like the Knight in Monty Python > and the Holy Grail.e > 	 > regardso > Andrew Harrisonm  ? we run TCPware, not ucx, and we had no problems with any of the = above ... we are still waiting for you to post a vunerabilityn= outside of decwindows that was major in the last 13 years ...u= remember, ucx is unix garbage kernel code that runs on top ofy< vms ... please name us all these VMS security issues ... and< I don't mean unix garbage that was ported and runs on vms, I" mean the vms os and kernel itself!   ------------------------------    Date: 18 May 2004 09:41:55 -0700' From: icerq4a@spray.se (David Svensson) * Subject: Re: SUN fails to advertise VMS...= Message-ID: <734da31c.0405180841.439a8ba7@posting.google.com>o   Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<c8cjr7$jgl$1@new-usenet.uk.sun.com>...r > Bob Ceculski wrote:sg > > "Rudolf Wingert" <win@fom.fgan.de> wrote in message news:<004f01c43bda$37f503d0$994614ac@wat153>...o > > 
 > >>Hello, > >>K > >>Hey Andrew, could you tell me which Virus, Worm and Trojaner did attackIK > >>OpenVMS within the last 13 years? Our OpenVMS systems where never undereL > >>attack! Also would you say, that Sun is able to build a cluster with 128L > >>or more nodes? With a distance between the nodes over 10.000 kilometers?H > >>That is what Sun must have, if they would like to migrate OpenVMS to > >>Solaris. > >> > >>Best regards R. Wingert  > >  > > ; > > all Andrew can do is try to try to get people to ignorep9 > > the CERTs and by trying to get people to believe thaty: > > the vms group doesn't post certs, but how can you post$ > > something that doesn't exist? :) > : > Firstly it is BS to claim that they do not exist because< > HP and 3rd party documentaion confirms that they do exist. > 8 > The POP hole for example did/does exist but no posting > was made to CERT.e > % > So that was your first piece of BS.  > = > Secondly even when postings have been made for example when = > OpenVMS has been vunerable to a generic attack such as LAND:( > or Teardrop they have been inaccurate. > # > That was your second piece of BS.a > > > Why persist with this rubbish, you have been caught out over= > and over again and basically lack the limbs to stand on bute@ > regretably you persist. Rather like the Knight in Monty Python > and the Holy Grail.e > 	 > regardso > Andrew Harrisone   Having a bad day?l   ------------------------------  % Date: Tue, 18 May 2004 17:55:39 +0100 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>w* Subject: Re: SUN fails to advertise VMS...0 Message-ID: <c8df6c$p5u$2@new-usenet.uk.sun.com>   Bob Ceculski wrote:n > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<c8cjr7$jgl$1@new-usenet.uk.sun.com>...u >  >>Bob Ceculski wrote:  >>f >>>"Rudolf Wingert" <win@fom.fgan.de> wrote in message news:<004f01c43bda$37f503d0$994614ac@wat153>... >>>r >>>w
 >>>>Hello, >>>>K >>>>Hey Andrew, could you tell me which Virus, Worm and Trojaner did attackoK >>>>OpenVMS within the last 13 years? Our OpenVMS systems where never under L >>>>attack! Also would you say, that Sun is able to build a cluster with 128L >>>>or more nodes? With a distance between the nodes over 10.000 kilometers?H >>>>That is what Sun must have, if they would like to migrate OpenVMS to >>>>Solaris. >>>> >>>>Best regards R. Wingert  >>: >>Firstly it is BS to claim that they do not exist because< >>HP and 3rd party documentaion confirms that they do exist. >>8 >>The POP hole for example did/does exist but no posting >>was made to CERT.t >>% >>So that was your first piece of BS.r >>= >>Secondly even when postings have been made for example when'= >>OpenVMS has been vunerable to a generic attack such as LANDP( >>or Teardrop they have been inaccurate. >># >>That was your second piece of BS.e >>> >>Why persist with this rubbish, you have been caught out over= >>and over again and basically lack the limbs to stand on butc@ >>regretably you persist. Rather like the Knight in Monty Python >>and the Holy Grail.t >>	 >>regardss >>Andrew Harrisonw >  > A > we run TCPware, not ucx, and we had no problems with any of the ? > above ... we are still waiting for you to post a vunerability ? > outside of decwindows that was major in the last 13 years ... ? > remember, ucx is unix garbage kernel code that runs on top oft> > vms ... please name us all these VMS security issues ... and> > I don't mean unix garbage that was ported and runs on vms, I$ > mean the vms os and kernel itself!  9 This makes absolutely no difference, TCPware has also hads; unreported vunerabilites to generic CERT exploits unless ofE? course you think that a denial of service isn't a vunerability.p   regards> Andrew Harrisonn   ------------------------------  % Date: Tue, 18 May 2004 17:58:29 +0100 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>c* Subject: Re: SUN fails to advertise VMS...0 Message-ID: <c8dfbl$p5u$3@new-usenet.uk.sun.com>   David Svensson wrote:a > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<c8cjr7$jgl$1@new-usenet.uk.sun.com>...  >>> >>Why persist with this rubbish, you have been caught out over= >>and over again and basically lack the limbs to stand on butc@ >>regretably you persist. Rather like the Knight in Monty Python >>and the Holy Grail.$ >>	 >>regards; >>Andrew Harrison= >  >  > Having a bad day?k  4 Why would pointing out Bobs very obvious failings be" a symptom of me having a bad day ?   regards  Andrew Harrisone   ------------------------------    Date: 18 May 2004 05:59:11 -0700( From: bob@instantwhip.com (Bob Ceculski)F Subject: Re: Switching from Process Software TCPware to TCPIP Services= Message-ID: <d7791aa1.0405180459.1a256bf8@posting.google.com>A  ~ "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in message news:<40A979D9.622D78C0@NeOaSrPtAhMlNiOnWk.net>... > Bob Ceculski wrote:  > > d > > "Pip" <pip@ti.nl0.com> wrote in message news:<40a93a4f$0$31675$afc38c87@news.optusnet.com.au>...Q > > > Because it appears that TCPware is not currently available for OpenVMS v8.1U > > > on Itanium.t > > < > > 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 ... > C > Not true. Multinet also provides DnIV/IP as Point-to-Point links.r  ; but not TRUE phase IV over IP ... it uses a pwip driver ...i   ------------------------------  # Date: Tue, 18 May 2004 14:34:47 GMT % From: "John Vottero" <John@mvpsi.com>iF Subject: Re: Switching from Process Software TCPware to TCPIP Services? Message-ID: <bapqc.8904$eH1.4900339@newssvr28.news.prodigy.com>u  K "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in messageu0 news:40A9742E.E03754D7@NeOaSrPtAhMlNiOnWk.net...   [snip]   >aJ > Frankly, IMO, since Tru64 is toast anyway, someone should buy up VMS (hpH > can't be trusted with it, this much is obvious to even the most casualI > observer) and Process Software's TCP/IP stacks for it, combine the bestsB > features of all three stacks into one and bundle the result with
 > OpenVMS.  B I would guess that there are very good reasons for not doing this.I Otherwise, TCPware and Multinet would have been combined a long time ago.l   ------------------------------  % Date: Tue, 18 May 2004 11:06:05 -0400 2 From: "Jonathan Boswell" <jsb.NOSP@M.cdrh.fda.gov>8 Subject: Re: TCPIP Services V5.4 on OpenVMS/Alpha V7.2-23 Message-ID: <xDpqc.274$Ny6.912@mencken.net.nih.gov>d  J I tried it myself, including the recent ECO.  The installation generated aF dire warning when it couldn't find a particular PCSI post-installationI command file, but I told it to continue despite this warning.  Other than1: that error message, TCPIP Services seems to run just fine.   ------------------------------  % Date: Tue, 18 May 2004 10:09:31 -0400 # From: "John Smith" <a@nonymous.com>[' Subject: The next port for OpenVMS? ;-)A, Message-ID: <DN-dncrlXZ-5hDfdRVn_iw@igs.net>  L http://story.news.yahoo.com/news?tmpl=story&ncid=1211&e=7&u=/pcworld/2004051  7/tc_pcworld/116150&sid=95612664     VMS on a PDA anyone? ;-)  J Lay a bunch of them on a tabletop within 1 meter of each other and do IrDA	 clusters.    ------------------------------  % Date: Tue, 18 May 2004 15:33:39 +0100vO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>a+ Subject: Re: The next port for OpenVMS? ;-) 0 Message-ID: <c8d6s3$gq9$1@new-usenet.uk.sun.com>   John Smith wrote:xN > http://story.news.yahoo.com/news?tmpl=story&ncid=1211&e=7&u=/pcworld/2004051" > 7/tc_pcworld/116150&sid=95612664 >  >  > VMS on a PDA anyone? ;-) > L > Lay a bunch of them on a tabletop within 1 meter of each other and do IrDA > clusters.  >   = Its interesting, the only people who still seem to think that ? the laws of physics which apply to everyone else don't apply toe them are the Itanium folks.e   Regards' Andrew Harrisonm   ------------------------------  % Date: Tue, 18 May 2004 11:11:48 -0400a# From: "John Smith" <a@nonymous.com> + Subject: Re: The next port for OpenVMS? ;-) , Message-ID: <c-adncN-jPYgujfdRVn-sA@igs.net>  K "Andrew Harrison SUNUK Consultancy" <Andrew_No.Harrison_No@nospamn.sun.com>m; wrote in message news:c8d6s3$gq9$1@new-usenet.uk.sun.com...g > John Smith wrote:i > >eL http://story.news.yahoo.com/news?tmpl=story&ncid=1211&e=7&u=/pcworld/2004051$ > > 7/tc_pcworld/116150&sid=95612664 > >i > >  > > VMS on a PDA anyone? ;-) > >mI > > Lay a bunch of them on a tabletop within 1 meter of each other and doP IrDA
 > > clusters.> > >y >c? > Its interesting, the only people who still seem to think that A > the laws of physics which apply to everyone else don't apply toe > them are the Itanium folks.F    F Not meaning to stand-up for the Itanic folks, but in fairness, today'sD physics of chip engineering is a long way from that of 10 years ago.  I Perhaps in a further 10 years time, Itanic IV with a healthy dose of "EV8hK Inside" will prove to be state-of-the-art....if the product line lives thatK long.e   ------------------------------  % Date: Tue, 18 May 2004 17:53:00 +0100eO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> + Subject: Re: The next port for OpenVMS? ;-)t0 Message-ID: <c8df1c$p5u$1@new-usenet.uk.sun.com>   John Smith wrote:aM > "Andrew Harrison SUNUK Consultancy" <Andrew_No.Harrison_No@nospamn.sun.com>g= > wrote in message news:c8d6s3$gq9$1@new-usenet.uk.sun.com...e >  >>John Smith wrote:o >>N > http://story.news.yahoo.com/news?tmpl=story&ncid=1211&e=7&u=/pcworld/2004051 > # >>>7/tc_pcworld/116150&sid=95612664A >>>D >>>r >>>VMS on a PDA anyone? ;-)r >>>lH >>>Lay a bunch of them on a tabletop within 1 meter of each other and do >  > IrDA >  >>>clusters. >>>l >>? >>Its interesting, the only people who still seem to think thatrA >>the laws of physics which apply to everyone else don't apply to  >>them are the Itanium folks.b >  >  > H > Not meaning to stand-up for the Itanic folks, but in fairness, today'sF > physics of chip engineering is a long way from that of 10 years ago. > K > Perhaps in a further 10 years time, Itanic IV with a healthy dose of "EV8eM > Inside" will prove to be state-of-the-art....if the product line lives that  > long.l >   B One of the major issues seems to be heat output and there are someB potentially promising new processes coming on stream in the second: half of the decade that may mitigate against this problem.  F However its clear from Intels recent cancellation of Tejas and JayhawkF that they don't expect these new processes to be available soon enough4 to allow the next generation x86 units to be viable.  @ To give you some idea of the problem Prescott which is currently@ being built in a 90 nanometer process, puts out 103 watts at 3.2? GHz roughly 20 watts more than a 3.2 GHz Xeon built in an olderl> and apparently higher power 130 nanometer process. The 3.2 GHz? Prescott chip is slightly slower than Xeon for most benchmarks.   A Apparently Intel intend to use the die space that would have beene= used to build Tejas to house 2 simpler cores that they expect-= will deliver slightly better throughput than the single Tejasa- core but with better thermal characteristics.-  E Which leaves us with Itanium. Intels reasons for cancelling Tejas and1> Jayhawk were mostly around their heat output, Itanium which is? considerably larger than Tejas and which will be even larger in @ 2005/2006 suffers from exactly the same problem except of course
 its worse.  H So if you apply the Tejas/Jayhawk logic to Itanium you end up cancelling3 it in favour of doing a simpler multi-core Itanium.0  G However there is no simple Itanium core available nor is one likely to oF surface. The Itanium core could have been a candidate but its too slowH and not nearly compact enough, the Pentium M core for example is 2x the C performance of the Itanium, uses less transistors and puts out lessd heat.e  G Sun cancelled Millenium Aka USV for exactly the same reasons that IntelmG cancelled Tejas. This could imply that Intel is in the same boat as Sun ? except for one very salient difference, Sun had already starteddD developing an alternative (Rock) and had been doing so for sometime,B Intel does not seem to have got very far if anywhere down the same route.   regardsi Andrew Harrison-   ------------------------------  % Date: Tue, 18 May 2004 09:56:01 +0100e* From: "Richard Brodie" <R.Brodie@rl.ac.uk>1 Subject: Re: Timestamp format stored in RMS file?O+ Message-ID: <c8cj33$nmu@newton.cc.rl.ac.uk>D  Y ""Alan Winston - SSRL Admin Cmptg Mgr"" <winston@SSRL.SLAC.STANFORD.EDU> wrote in message 0 news:00A31D48.513F3305@SSRL.SLAC.STANFORD.EDU...  L > I suspect you won't find vms.starlet.bintim working properly on any PythonJ > platform but VMS. This is just the Python interface into the VMS runtime
 > library.  S Yes, that isn't the platform independent part; it's just a derivation of the offset5I (sadly with a couple of noise centisecond digits, which I already noted).    ------------------------------   End of INFO-VAX 2004.275 ************************