1 INFO-VAX	Thu, 27 Apr 2006	Volume 2006 : Issue 232       Contents:8 Re: DCL versus Unix CLIs, was: Re: File output like Unix8 Re: DCL versus Unix CLIs, was: Re: File output like Unix8 Re: DCL versus Unix CLIs, was: Re: File output like Unix Re: File output like Unix E Re: Heads UP BRUDEN Announces the OpenVMS Bootcamp Uptime Scholarship 1 Re: How does File ID correspond to kfe$w_fid_num? 1 Re: How does File ID correspond to kfe$w_fid_num? 1 Re: How does File ID correspond to kfe$w_fid_num? 1 Re: How does File ID correspond to kfe$w_fid_num?  Re: hypothetical question  Re: hypothetical question ( Re: LPD relay to a LAT queue?  Possible?( Re: LPD relay to a LAT queue?  Possible?( Re: LPD relay to a LAT queue?  Possible?( Re: LPD relay to a LAT queue?  Possible?( Re: LPD relay to a LAT queue?  Possible?( Re: LPD relay to a LAT queue?  Possible? Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet RE: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: Replacing drives in bricks Re: TIMEPROMPTWAIT problem Re: TIMEPROMPTWAIT problem Re: TIMEPROMPTWAIT problem Re: TIMEPROMPTWAIT problem Re: TIMEPROMPTWAIT problem Re: TIMEPROMPTWAIT problem Re: TIMEPROMPTWAIT problem) Re: Various comments (decus presentation) ) Re: Various comments (decus presentation) ) Re: Various comments (decus presentation) ) Re: Various comments (decus presentation) ) Re: Various comments (decus presentation) ) Re: Various comments (decus presentation) ) Re: Various comments (decus presentation) ) Re: Various comments (decus presentation) ) Re: Various comments (decus presentation) ) Re: Various comments (decus presentation) ) Re: Various comments (decus presentation) ) Re: Various comments (decus presentation) ) Re: Various comments (decus presentation)  Virtual I/O Cache  Re: Virtual I/O Cache  Re: Virtual I/O Cache  Re: VMS732_ACRTL-V0300  F ----------------------------------------------------------------------    Date: 26 Apr 2006 14:25:14 -04003 From: Rich Alderson <news@alderson.users.panix.com> A Subject: Re: DCL versus Unix CLIs, was: Re: File output like Unix . Message-ID: <mddslo0tcs5.fsf@panix5.panix.com>  D clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) writes:  L > Things that I dislike about DCL (these relate to 7.3-1 and prior versions,- > I haven't upgraded to a later version yet):   0 > 	Tried renaming file.ext to just .ext lately ?  M That's simply the Unix shell convention for "invisible" files.  On Tops-20 it M was a settable file attribute, not a magic way of naming files; does VMS have  that?   G > 	You can't do filename completion. (On bash, pressing TAB gives you a H > 	list of filenames/directories matching what you have typed so far, orD > 	just completes the filename/directory if there's only one match.)  O Also in tcsh, the "TENEX C-shell".  This is one of the features of Tops-20 (and B of TENEX before it) that I most sorely miss when working with VMS.  K But then, there was a manager in the early history of VMS who swore that no ; feature from the 36-bit world would ever be allowed in VMS.    --  L Rich Alderson                                       | /"\ ASCII ribbon     |L news@alderson.users.panix.com                       | \ / campaign against |L "You get what anybody gets. You get a lifetime."    |  x  HTML mail and    |L                          --Death, of the Endless    | / \ postings         |   ------------------------------    Date: 26 Apr 2006 15:42:20 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) A Subject: Re: DCL versus Unix CLIs, was: Re: File output like Unix 3 Message-ID: <IVfbpfwHLhBV@eisner.encompasserve.org>   d In article <mddslo0tcs5.fsf@panix5.panix.com>, Rich Alderson <news@alderson.users.panix.com> writes: > O > That's simply the Unix shell convention for "invisible" files.  On Tops-20 it O > was a settable file attribute, not a magic way of naming files; does VMS have  > that?  > G    Temporary files are nearly truely invisible.  You have to look a lot .    harder than some listing flag to find them.   ------------------------------    Date: 26 Apr 2006 16:34:23 -0700$ From: "AEF" <spamsink2001@yahoo.com>A Subject: Re: DCL versus Unix CLIs, was: Re: File output like Unix C Message-ID: <1146094463.265362.201570@i40g2000cwc.googlegroups.com>    Simon Clubley wrote:a > In article <1145989404.330424.164290@g10g2000cwb.googlegroups.com>, bob@instantwhip.com writes: C > > why do users want convuluted unix commands like pipe grep slurp > > > gulp ... when they use common english makes sense commands > > like COPY on vms?  > >  > : > Pipe is a DCL command. Unix uses redirection characters. > I > Those Unix commands are generally more powerful than the VMS equivalent ; > and naming commands using English words only goes so far.  > J > For example, what English verbs and qualifiers would you use to describeI > the functionality that ghostscript offers and by the time that you have O > finished have you really gained anything over the current approach (as people 0 > still have to learn what your qualifiers do) ? > ) > Two examples of more powerful commands: C > 	grep (the Unix version of search) can do full regular expression  > 	pattern matching.  ? Can it do something like $ SEARCH FILE.TYP WORD1,WORD2,... with A /MATCH=(one of OR, NOR, AND, NAND, ...) Maybe it can ... I'm just $ asking but I think the answer is no.   > , > 	GNU diff can compare two directory trees. > , > Things that I dislike about the Unix CLIs:F > 	There isn't a DCL style lexical API for getting system information. > L > Things that I dislike about DCL (these relate to 7.3-1 and prior versions,- > I haven't upgraded to a later version yet):  > 6 > 	You can't edit commands across linewrap boundaries.. > 	Has this been fixed in later VMS versions ?  * Isn't this more about the terminal driver?   > D > 	Your command history is lost when you log out unless you manuallyF > 	save it. (Does recall/input work within command procedures on laterH > 	VMS versions and is there a method for intelligently handling commandF > 	histories from multiple DCL sessions in the same way that bash (the > 	Unix CLI that I use) does ?)    Don't know.    > 0 > 	Tried renaming file.ext to just .ext lately ?  " Nope. I have no reason to do this.  B Here's one for you: Ever try writing a SET DEFAULT program in Unix
 shell script?   E And another, though it's not DCL: VMS BACKUP will restore incremental G save sets, but it deletes files that were not present during the latest D incremental save operation. Does *any* other backup program do that?   > A > 	There isn't a way of searching through all help topics looking  > 	for a keyword.   ? Well, you could (not tested, but if this doesn't work, a simple  variation of it will)    $ HELP/OUT=HELP.LIS *... $ SEARCH HELP.LIS keyword  or $ EDIT HELP.LIS  (!!!)    > G > 	You can't do filename completion. (On bash, pressing TAB gives you a H > 	list of filenames/directories matching what you have typed so far, orD > 	just completes the filename/directory if there's only one match.)  G With my WILD.COM you can do filename completion, but you have to supply E wildcards for missing substrings and deal with a YNAQ prompt. But you G can also supply DIRECTORY qualifiers to narrow down the matching files.      > G > 	Command history searching is cumbersome. (With bash, you hit Ctrl-R, F > 	type a few letters of your command (with bash searching the historyE > 	as you type the letters) and just keep hitting Ctrl-R to skip over  > 	duplicates.)   ; Not familiar enough with bash to comment, but I really like D DOSKEY/INSERT on MS-DOS. (I don't like much else on MS-DOS, though.)   > D > And yes, I know that bash is available for VMS. I am talking about > deficiencies within DCL. >  > Simon. >  > --= > Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP K > If Google's motto is "do no wrong", then how did we get Google Groups 2 ?   & Good point. And it's "Don't be evil".    AEF    ------------------------------  % Date: Wed, 26 Apr 2006 21:26:36 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>" Subject: Re: File output like Unix6 Message-ID: <44502BDC.7336BBCB@NeOaSrPtAhMlNiOnWk.net>   Bill Gunshannon wrote: > 5 > In article <al31aT8RqOvF@eisner.encompasserve.org>, G >         koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: [ > > In article <4b74vcF101da8U1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:  > >>G > >> Maybe, but he seems to be looking for an equivalent to the Solaris E > >> "cat file1 > file2" which will make a duplicate copy of the file G > >> with a new name.  Which, as I said, is probably not what he wants, G > >> but I have already had two students today alone do pretty much the F > >> same thing.  They use a paragraph to ask a question that required > >> no more than a sentence!! > > G > >    Actually, what I read between the lines is that he wanted pipes.  > N > Exactly!!  As I said, what he really wants probably isn't what he asked for.M > I can't, for the life of me, understand why people don't just say what they 8 > really mean when they are looking for help like this!!  F Mostly, they don't sufficiently understand what they need, so they ask, based on their best (limited) understanding.  C I could have retired years ago if I could have billed my employer's D vendors for training their people (the ones they sent to train me!).   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------    Date: 26 Apr 2006 14:58:37 -0700) From: "Sue" <susan_skonetski@hotmail.com> N Subject: Re: Heads UP BRUDEN Announces the OpenVMS Bootcamp Uptime ScholarshipC Message-ID: <1146086661.057256.157610@t31g2000cwb.googlegroups.com>   F In speaking with Bruce via email today he has had over 70 people apply( for this scholarship which is wonderful.  G In case you are wondering last year at this time (4 weeks away from the ; boot camp) we were 50% full we are currently over 85% full.   
 Warm Regards,  Sue    ------------------------------  # Date: Wed, 26 Apr 2006 18:23:52 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>: Subject: Re: How does File ID correspond to kfe$w_fid_num?1 Message-ID: <YUO3g.6865$uL.1129@news.cpqcorp.net>    Brice Buchanan wrote:   @    You can pick off the symbol names from the system definition 9 libraries -- I would hope that your references including  H "kfe->wcb->fcb.fid_num" indicates a short-hand used for posting and not C the actual symbol names you are using.  If you have your own local  E symbols, it's quite easy to get into some trouble if/when the system   constants change, obviously.F SYS$LIBRARY:SYS$STARLET_C.TLB and SYS$LIB_C.TLB are the usual sources 2 for system constant definitions for C programmers.  H    It's also possible for the default record padding in C to play havoc G with system data structure references, if you're not careful.  I'd not  E assume fields in system structures are naturally aligned.  There's a  I discussion of this topic over in the FAQ, in the section on C coding and  H C coding bugs.  I mention this because I am among those folks that have $ tripped over this particular detail.  H > I may have to recode this for 8.2... but I'd rather not. Suggestions /* > workarounds will be appreciated! Thanks.  G    Interesting.  I have just reverified the sequence on an OpenVMS I64   V8.2-1 system.  Details below.  D    Is there a chance you are using stale symbolic offsets somewhere?  F    Here's the basic command sequence I have been using, and the X.MAR G mentioned in my earlier reply is what I use to generate the target for  C the READ X.OBJ command shown below.  And it looks to be working as  E expected, so I can't explain what you are seeing in your application.     # > $ dir/file sys$share:decc$shr.exe  >  > Directory SYS$COMMON:[SYSLIB]  > " > DECC$SHR.EXE;1       (2980,13,0) >  > Total of 1 file.& > $ install list sys$share:decc$shr/fu > ) > DISK$I64SYS:<SYS0.SYSCOMMON.SYSLIB>.EXE R >    DECC$SHR;1       Open Hdr Shared                                        Resid > * >         Entry access count         = 598. >         Current / Maximum shared   = 11 / 10( >         Global section count       = 4 >  > $ analyze/system >  > OpenVMS system analyzer  >  > SDA> show kfe decc$shr >  > Known File Entries > ------------------ > B > KFD Device/Directory/Type: FELL$DKA0:<SYS0.SYSCOMMON.SYSLIB>.EXEB > ---------------------------------------------------------------- > Q >     KFE                   Image Name/                LDRIMG Address/       File  > ID/      Flags/ R >   Address                 Section Type                     Base              End >         ImageOffR >   --------  --------------------------------------- ----------------- ---------- > ------- --------R >   8F0506F0  DECC$SHR;1                              8F0508C0          (2980,13,0$ > )       Open HdrRes Shared ResCode ...  > SDA> read x.obj  > SDA> for 8F0506F0 G > FFFFFFFF.8F0506F0   KFE$L_HSHLNK                             00000000 > > FFFFFFFF.8F0506F4   KFE$L_KFELINK                   8F080BE0G > FFFFFFFF.8F0506F8   KFE$W_SIZE                                   0081 C > FFFFFFFF.8F0506FA   KFE$B_TYPE                                 18 A > FFFFFFFF.8F0506FB   KFE$B_HSHIDX                             20 > > FFFFFFFF.8F0506FC   KFE$L_KFD                       8EECA060G > FFFFFFFF.8F050700   KFE$R_FLAGS_BITS                00000257.00041078 ) >                     KFE$R_FLAGS_OVERLAY ! >                     KFE$W_FLAGS % >                     KFE$W_GBLSECCNT " >                     KFE$L_USECNTG > FFFFFFFF.8F050708   KFE$L_WCB                                8955C240 ' >                     KFE$R_FID_OVERLAY ) >                     KFE$R_WINDOW_FIELDS * >                     KFE$R_WINDOW_OVERLAY >                     KFE$W_FID # >                     KFE$W_FID_NUM # >                     KFE$W_FID_SEQ > > FFFFFFFF.8F05070C   KFE$L_IMGHDR                    8F0508C0" >                     KFE$L_LDRIMG* >                     KFE$R_IMGHDR_OVERLAY# >                     KFE$W_FID_RVN  ...  > SDA> for 8955C240 > > FFFFFFFF.8955C234   WCB$L_PREVCOUNT                 00000000G > FFFFFFFF.8955C238   WCB$L_PREVLBN                            00000000 > > FFFFFFFF.8955C23C   WCB$L_PREVRVN                   00000000G > FFFFFFFF.8955C240   WCB$L_COUNT                              89555018   >                     WCB$L_WLFL> > FFFFFFFF.8955C244   WCB$L_LBN                       89555018  >                     WCB$L_WLBLG > FFFFFFFF.8955C248   WCB$L_RVN                                69120060   >                     WCB$W_SIZE  >                     WCB$B_TYPE" >                     WCB$B_ACCESS* >                     WCB$C_MAP_PTR_LENGTH ... > > FFFFFFFF.8955C264   WCB$L_FCB                       89555000 ...  > SDA> for 89555000 G > FFFFFFFF.89555000   FCB$L_FCBFL                              89556200 > > FFFFFFFF.89555004   FCB$L_FCBBL                     8954DD40G > FFFFFFFF.89555008   FCB$W_SIZE                                   0180 C > FFFFFFFF.8955500A   FCB$B_TYPE                                 07  ... G > FFFFFFFF.89555050   FCB$W_FID                                    0BA4 & >                     FCB$W_FID_DIRNUM# >                     FCB$W_FID_NUM C > FFFFFFFF.89555052   FCB$L_FID_RECNUM                    0000.000D # >                     FCB$W_FID_SEQ # >                     FCB$B_FID_RVN # >                     FCB$W_FID_RVN # >                     FCB$B_FID_NMX  ...           Note    ------------------------------    Date: 26 Apr 2006 11:51:46 -0700* From: "Brice Buchanan" <BriceBu@gmail.com>: Subject: Re: How does File ID correspond to kfe$w_fid_num?C Message-ID: <1146077505.960176.179540@i40g2000cwc.googlegroups.com>    Hoff,   * Yup, "kfe->wcb->fcb.fid_num" is shorthand.  $ I'm compiling with these qualifiers:      /stand=vaxc    /nomember_alignment    /assume=(writable,noalign)     /float=d_float   D Thanks very much for the info, I'm going to try to work through this and see how far I get.     Regards,   Brice B.   ------------------------------  # Date: Wed, 26 Apr 2006 19:04:01 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>: Subject: Re: How does File ID correspond to kfe$w_fid_num?1 Message-ID: <BuP3g.6873$EM.5785@news.cpqcorp.net>    Brice Buchanan wrote:    > & > I'm compiling with these qualifiers: >  >    /stand=vaxc  F    I prefer to allow the HP/Compaq/DEC C compiler to spot the errors. F Using VAX C compatibility tends to mask many of the latent errors and F the unstable constructs that can exist in code built for the pre-ANSI  VAX C compiler.    >    /nomember_alignment  G    I'd tend to use the pragmas to mark the specific data structures as  I needed, and not the "really big hammer" of the whole program.  Alpha and  I Itanium applications do tend to operate rather more quickly when natural   alignment is used.   >    /assume=(writable,noalign)   J    Ok...  Though writable strings can cause some interesting behaviours...   >    /float=d_float   H    There's apparently some specific VAX floating point code or floating H point data storage lurking.  If you can, I'd move over to IEEE formats, I if feasible.  These are native on OpenVMS Alpha and on OpenVMS I64.  (If  H you need to deal with direct data interchange with OpenVMS VAX, though, , you'll end up using one of the VAX formats.)   ------------------------------    Date: 26 Apr 2006 14:50:06 -0700* From: "Brice Buchanan" <BriceBu@gmail.com>: Subject: Re: How does File ID correspond to kfe$w_fid_num?B Message-ID: <1146088206.381785.49010@i40g2000cwc.googlegroups.com>   Hoff,   C Thanks, all your points are good, and noted, and I have no argument D with any of them. I'm porting from Alpha VMS 7.3 to VMS 8.2 (axp andG ia64).  First I have to iron out the wrinkles, make sure things work as > expected - and then I'll have a chance to focus on efficiency.  ' Anyway - yes, I've got "stale" offsets.   F I created an X.OBJ as you suggested, fired up the SDA, and sure enoughC there are four unnamed bytes in the WCB, between L_ACON and L_NMAP, E that my (locally-defined) structs do not account for. As you can see, B the value of NMAP is 1, which my app is seeing as L_FCB, hence the wcb$l_fcb value of 1.   E FFFFFFFF.82492818   WCB$L_ACON                               00000801 < FFFFFFFF.8249281C                                   00000000E FFFFFFFF.82492820   WCB$L_NMAP                               00000001 < FFFFFFFF.82492824   WCB$L_FCB                       82426FC0  F I can code around this problem pretty easily, I think. I'd like to get, away from "poking around at the undocumentedC corners of the kernel structures" as you said, but methinks that'll  have to wait.   + Thanks very much for the invaluable help!      - Brice    ------------------------------  % Date: Wed, 26 Apr 2006 21:20:54 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>" Subject: Re: hypothetical question6 Message-ID: <44502A86.4178B03D@NeOaSrPtAhMlNiOnWk.net>   Dave Froble wrote: >  > JF Mezei wrote: 1 > > re: backup from disk to a disk based saveset.  > > F > > One issue I have just thought of: so, you create the save set on aL > > different disk REALLY FAST. But then, how do you savely copy the saveset
 > > to tape ?  > F > To copy the save set to tape, the COPY command is appropriate.  ThisE > does have some ramafications.  BACKUP is set up to handle some tape 6 > errors, while COPY will not do as well in this area.  E True, but remember that the redundancy groups and such are written to > the saveset, regardless of whether the target is disk or tape.  J > I'd think that if I had problems copying a save set to tape, I'd want toG > use another tape.  Best to at least start out with no errors, they'll D > eventually rear their ugly head in time.  However, I'm not sure ifF > BACKUP will be able to better handle the tape if it didn't write the > save set.   D ...but, BACKUP *DID* write the saveset! All you did was COPY it fromE disk to tape! Just remember to MOUNT the tape FILES-11 and /NOHDR3 so E BACKUP doesn't choke on it later when you MOUNT it /FOREIGN as BACKUP  expects.  C > This would be a question for those supporting the BACKUP utility.  >  > There are no guarantees.   Quite.   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------  % Date: Wed, 26 Apr 2006 21:23:22 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>" Subject: Re: hypothetical question6 Message-ID: <44502B1A.7D437B0E@NeOaSrPtAhMlNiOnWk.net>   Guy Peleg wrote: > D > "Guy Peleg" <guy.peleg@remove_this_header@hp.com> wrote in message& > news:444d262e@usenet01.boi.hp.com...> > > If I could make your BACKUP operations complete faster....? > > 2-5 times faster....but restrict this feature for save-sets ; > > written to disks only (not to support it with save-sets 3 > > written to tapes).....would you find it useful?  > > % > > I'm looking for yes/no answer....  > > + > > Please do not ask for more details..... 5 > > Please do not speculate.....it will be clear soon  > > ? > > I'm unable to provide any further information at this point  > >  > > Thank you !  > > 
 > > Guy Peleg  > > OpenVMS Engineering  > > N > > (Please do not re-post this in any other forum, I chose c.o.v. on purpose) > >  > >  > M > unfortunately I did not win the war I was fighting.......but thanks for the J > ammunition. There will be details on this during my utilities session inI > the bootcamp, but it will be under NDA. this  will become somewhat more % > public towards the end of the year.   C With the dawn of ESLs, CDLs and such, it's currently very polically H correct to prefer "cheap" disk for backup (read: tape library emulators)A versus Hitachi / XP / EMC Enterprise Storage arrays (mucho $$$!).    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------    Date: 26 Apr 2006 12:34:27 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 1 Subject: Re: LPD relay to a LAT queue?  Possible? 3 Message-ID: <hQqEJVIFgkNK@eisner.encompasserve.org>   _ In article <06042609212582@dscis6-0.dalsemi.com>, brandon@dalsemi.com (BRANDON, JOHN M) writes: = > Is it possible to configure LPD to serve a LAT print queue?  >   @    I did this years ago with UCX when UCX couldn't do very much.   ------------------------------  % Date: Wed, 26 Apr 2006 14:11:17 -0500 + From: brandon@dalsemi.com (BRANDON, JOHN M) 1 Subject: Re: LPD relay to a LAT queue?  Possible? 1 Message-ID: <06042614111773@dscis6-0.dalsemi.com>    Hoff Hoffman wrote: ? > > Is it possible to configure LPD to serve a LAT print queue?  > J >    Yes.  It's usually easier and more expedient to replace the printer, I > or to add a second (and parallel) printer.  (I usually prefer to avoid  I > host-based printers and network-served remote host-based print queues,  K > nor of relays such as this one.  Direct access to a printer-based NIC is  K > typically far easier to support, and most any printer offers a NIC these  D > days.  But what you want should be possible, within the limits of E > lpr/lpd or the telnet symbiont, or (depending on the platform) DQS.   ! Great!  How?  (Please! & Thanks!)      John "REBOOT" Brandon  VMS Systems Administrator * firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  % Date: Wed, 26 Apr 2006 16:35:48 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 1 Subject: Re: LPD relay to a LAT queue?  Possible? , Message-ID: <444FD992.AD3F7D22@teksavvy.com>   "BRANDON, JOHN M" wrote: > = > Is it possible to configure LPD to serve a LAT print queue?    YEP.  G LPD doesn't really care what type of queue it is. You configure it with 0 MC TCPIP$LPRSETUP and configure a local printer.  A Then, that printer name is available when you print from a remote C location. the LPD server receives the file from the remote machine, C stored it in the spool directory and then queues it to print on the A specified VMS queue. From then on, it appears to VMS as a locally  submitted print job.  D (this is with TCPIP services 5.3).  The management manual has a very good description.     F Here is my configuration file. The service is called LASER_PS, and theF VMS print queue is LASER_PS (a generaic print queue pointing to LASER1F which is a DCPS served queue, but none of that is necessary here sinceH the LPD server on VMS simply does a SUBMIT/PRINT to the specified queue.F There are logicals you can set to affect the processing (for instance,O creatinga stream temporary file and using /PASSALL in the submit/print command.   ) $ type [sys0.tcpip$lpd]TCPIP$PRINTCAP.DAT  #  # LOCAL PRINTERS #  TCPIP$LPD_QUEUE:\          :lp=TCPIP$LPD_QUEUE:\          :sd=TCPIP$LPD_SPOOL: LASER_PS|laser_ps|LASER_PS:\2         :lf=/SYS$SPECIFIC/TCPIP$LPD/LASER_PS.LOG:\         :lp=LASER_PS:\.         :sd=/SYS$SPECIFIC/TCPIP$LPD/LASER_PS:\         :pa: #  $     5 (the above was created by the TCPIP$LPRSETUP utility.    ------------------------------  # Date: Wed, 26 Apr 2006 21:26:28 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>1 Subject: Re: LPD relay to a LAT queue?  Possible? 1 Message-ID: <8AR3g.6881$HL.4070@news.cpqcorp.net>    BRANDON, JOHN M wrote: > Hoff Hoffman wrote: ? >>> Is it possible to configure LPD to serve a LAT print queue? K >>    Yes.  It's usually easier and more expedient to replace the printer,  J >> or to add a second (and parallel) printer.  (I usually prefer to avoid J >> host-based printers and network-served remote host-based print queues, L >> nor of relays such as this one.  Direct access to a printer-based NIC is L >> typically far easier to support, and most any printer offers a NIC these E >> days.  But what you want should be possible, within the limits of  F >> lpr/lpd or the telnet symbiont, or (depending on the platform) DQS. > # > Great!  How?  (Please! & Thanks!)   G    Wander down to your local computer palace or over to www.hp.com and  E pick out a printer with a NIC.  (One potential antecedent for "how?")   E    Again, I expect that LPR/LPD will start to get "helpful" here, as  H that's something I've seen time and time again.  Direct printing is far 4 easier to manage than is any sort of relay printing.  D    As for LPD, most everything involves the printcap file.  In this C case, set the queue name in the lp entry in the printcap file, and  H possibly also the rm and rp fields.  (I tend to use telnet, or -- again B -- direct printing.  And LPD may squawk if the remote queue isn't I LPR/LPD, it's been an eon since I've had anything similar configured.  I   got NICs for the printers...)   #    As for telnetsym relay queues...    "TELNETSYM RELAY QUEUES:  F The output of TELNETSYM can be redirected to another queue rather than? being sent directly to a remote printer.  This configuration is  referred to as a relay queue.   B The primary function of a relay queue is to funnel fully formattedF output to an outbound LPD queue.  This enables LPD to transfer a printG job that is already pre-formatted by OpenVMS on the sending side to its  destination printer.  C To set up a TELNETSYM relay queue, include the /ON qualifier on the C "INITIALIZE/QUEUE" command with a format of '/ON="UCX$QUEUE:qname"' E (where qname is the name of the queue where TELNETSYM should send its G output).  For example, to create a TELNETSYM relay queue named RELAYQ_4 ? which sends its output to another queue named LPD_Q4, issue the  following DCL command:  /       $ INITIALIZE/QUEUE/ON="UCX$QUEUE:LPD_Q4"- 9       _$ /PROCESSOR=UCX$TELNETSYM/DEVICE=PRINTER RELAYQ_4   F TELNETSYM saves its output stream to a temporary file and then submitsD the file to the destination queue.  Note that TCP/IP is not involved with a TELNETSYM relay queue."   ------------------------------  % Date: Wed, 26 Apr 2006 17:01:13 -0500 + From: brandon@dalsemi.com (BRANDON, JOHN M) 1 Subject: Re: LPD relay to a LAT queue?  Possible? 1 Message-ID: <06042617011333@dscis6-0.dalsemi.com>    JF Mezei wrote:  > "BRANDON, JOHN M" wrote: > > ? > > Is it possible to configure LPD to serve a LAT print queue?  >  > YEP. > I > LPD doesn't really care what type of queue it is. You configure it with 2 > MC TCPIP$LPRSETUP and configure a local printer. > C > Then, that printer name is available when you print from a remote E > location. the LPD server receives the file from the remote machine, E > stored it in the spool directory and then queues it to print on the C > specified VMS queue. From then on, it appears to VMS as a locally  > submitted print job. > F > (this is with TCPIP services 5.3).  The management manual has a very > good description.  >  > H > Here is my configuration file. The service is called LASER_PS, and theH > VMS print queue is LASER_PS (a generaic print queue pointing to LASER1H > which is a DCPS served queue, but none of that is necessary here sinceJ > the LPD server on VMS simply does a SUBMIT/PRINT to the specified queue.H > There are logicals you can set to affect the processing (for instance,Q > creatinga stream temporary file and using /PASSALL in the submit/print command.  > + > $ type [sys0.tcpip$lpd]TCPIP$PRINTCAP.DAT  > #  > # LOCAL PRINTERS > #  > TCPIP$LPD_QUEUE:\  >         :lp=TCPIP$LPD_QUEUE:\  >         :sd=TCPIP$LPD_SPOOL: > LASER_PS|laser_ps|LASER_PS:\4 >         :lf=/SYS$SPECIFIC/TCPIP$LPD/LASER_PS.LOG:\ >         :lp=LASER_PS:\0 >         :sd=/SYS$SPECIFIC/TCPIP$LPD/LASER_PS:\ >         :pa: > #  > $  >  > 7 > (the above was created by the TCPIP$LPRSETUP utility.   L Thanks for the information - will try it as soon as I get my IP stack issues7 resolved (had to dust off an old VAX for this stuff...)        John "REBOOT" Brandon  VMS Systems Administrator * firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  % Date: Wed, 26 Apr 2006 16:59:48 -0500 + From: brandon@dalsemi.com (BRANDON, JOHN M) 1 Subject: Re: LPD relay to a LAT queue?  Possible? 1 Message-ID: <06042616594884@dscis6-0.dalsemi.com>    Hoff Hoffman wrote:  > BRANDON, JOHN M wrote: > > Hoff Hoffman wrote: A > >>> Is it possible to configure LPD to serve a LAT print queue? M > >>    Yes.  It's usually easier and more expedient to replace the printer,  L > >> or to add a second (and parallel) printer.  (I usually prefer to avoid L > >> host-based printers and network-served remote host-based print queues, N > >> nor of relays such as this one.  Direct access to a printer-based NIC is N > >> typically far easier to support, and most any printer offers a NIC these G > >> days.  But what you want should be possible, within the limits of  H > >> lpr/lpd or the telnet symbiont, or (depending on the platform) DQS. > > % > > Great!  How?  (Please! & Thanks!)  > I >    Wander down to your local computer palace or over to www.hp.com and  G > pick out a printer with a NIC.  (One potential antecedent for "how?")   O We are dumping to a barcode printer - currently using LAT thru a DECserver 90TL H We converted the DECserver port to a Telnet Listener and created a queue1 using tcpip$telnetsym AND another queue using LPD % in both events records are being lost   A We have also tested using a Netport Express with the same results   K At this time purchase of a NIC card will not suffice as the barcode printer  does not support this...  G >    Again, I expect that LPR/LPD will start to get "helpful" here, as  J > that's something I've seen time and time again.  Direct printing is far 6 > easier to manage than is any sort of relay printing.  ? I would love to however at this point it is not a viable option   F >    As for LPD, most everything involves the printcap file.  In this E > case, set the queue name in the lp entry in the printcap file, and  J > possibly also the rm and rp fields.  (I tend to use telnet, or -- again D > -- direct printing.  And LPD may squawk if the remote queue isn't K > LPR/LPD, it's been an eon since I've had anything similar configured.  I   > got NICs for the printers...)  > % >    As for telnetsym relay queues...  >  > "TELNETSYM RELAY QUEUES: > H > The output of TELNETSYM can be redirected to another queue rather thanA > being sent directly to a remote printer.  This configuration is  > referred to as a relay queue.  > D > The primary function of a relay queue is to funnel fully formattedH > output to an outbound LPD queue.  This enables LPD to transfer a printI > job that is already pre-formatted by OpenVMS on the sending side to its  > destination printer. > E > To set up a TELNETSYM relay queue, include the /ON qualifier on the E > "INITIALIZE/QUEUE" command with a format of '/ON="UCX$QUEUE:qname"' G > (where qname is the name of the queue where TELNETSYM should send its I > output).  For example, to create a TELNETSYM relay queue named RELAYQ_4 A > which sends its output to another queue named LPD_Q4, issue the  > following DCL command: > 1 >       $ INITIALIZE/QUEUE/ON="UCX$QUEUE:LPD_Q4"- ; >       _$ /PROCESSOR=UCX$TELNETSYM/DEVICE=PRINTER RELAYQ_4  > H > TELNETSYM saves its output stream to a temporary file and then submitsF > the file to the destination queue.  Note that TCP/IP is not involved  > with a TELNETSYM relay queue."  @ Thanks for the above - I was headed down the RELAY QUEUE path...     John "REBOOT" Brandon  VMS Systems Administrator * firstname.lastname.spam.me.not@dalsemi.com   ------------------------------    Date: 26 Apr 2006 14:00:33 -0700- From: "Doug Phillips" <dphill46@netscape.net> # Subject: Re: OT: Sparc not dead yet C Message-ID: <1146085233.662446.320090@v46g2000cwv.googlegroups.com>    Main, Kerry wrote: > > From: Doug Phillips  > >  >  > [snip ...] >  > > J > > And you think no one is working on those issues? At one time VMS had aG > > 32 bit "bottleneck". x86 had all kinds of bottlenecks going all the J > > back to 4 bits. Today's x86 CPU's are more capable than both Linux andF > > Windows. That's the way evolution in this industry works. Hardware. > > advances, then software pushes its limits. > >  > G > You also need to also remember that hardware and software gets better H > with each release, but what many who think "x86 solutions will replaceF > everything" forget is that Customer RASS (reliability, availability,< > scalability and security) requirements are also increasingJ > exponentially. Hence, while each new release of OS/HW gets better on all? > platforms, the RASS bar is constantly being moved up as well.  > D > Global DC consolidation, national and international regulatory andC > compliance requirements, global 7x24x365 markets are causing many E > Customers to re-evaluate how they deliver their IT solutions of the 	 > future.  >   A This is all true, Kerry. But how much money can x86's competition E afford to keep spending to stay ahead? The money being spent on x86's G evolution is huge. Sun is bleeding to death today and SPARC engineering D is a big bleeder. At some point, unless Sun is handed a miracle, theF SPARC division will probably be sold. Whatever is on the SPARC drawingB board now might or might not ever get to the market. Chips fartherC along in the process probably will, and a return from that "shorter G term" market would be a reason Samsung or whoever might want to buy it. ? Anyone willing to do a little homework should come to a similar  conclusion.   E Some other factors: Windows and Linux aren't the only OS's that could E run on x86. The focus on DT means that the majority of big users need C better distrubuted computing rather than huge monolithic crunchers. G There are only a few places where monolithic super-computing is needed, B and there will always be a place for the next "Cray". IBM is still making money selling big-iron.  D The Reliability-Availability-Security bar ("goal") is and always hasG been at 100%. Scalability has a few different meanings depending on the F problem. As you say, IT users (customers) must continually re-evaluate? their IT service delivery. Likewise, IT solution providers must ; continually re-evaluate how to best spend their R&D dollar.     J > For many of the these Customers, I would suggest that QA/testing monthlyE > security patches (Linux/Windows) with their primary applications is I > rapidly going to become unacceptable. And as we have seen by all of the H > issues in the last few weeks, if Cust's do not test these applicationsJ > with these monthly security patches then they are open to all the issuesI > that hit the headlines. In a global market, a companies credibility can G > take a serious node dive if this happens to them or worse, their Cust C > data gets exposed because of one of these monthly security flaws.  >   D This is all true, today. But, *any* system can be made secure or not secure.     J > > VMS is unusual because its owners keep trying to reinvent the "wheel",I > > then they drop their wheel when they see the "old" wheels rolling on, H > > so they start over and try to invent a different wheel again. In the- > > meantime, the big wheels keep on rolling.  > >  > >  > ' > Can you expand on what you mean here?  > G > Perhaps I missed an extract from an earlier thread, but this does not  > make much sense on its own.  >   < Substitute "CPU" for "wheel". Neither Alpha nor Itanium were? "revolutionary" technologies, they were attempts to advance and ? redirect evolution. A true technology "revolution" will quickly C obsolete current technology. Money spent on Alpha and Itanium might ! have been better spent elsewhere.   A DEC ignored Win-tel until it was too late. Too often history does  repeat itself.   ------------------------------  % Date: Wed, 26 Apr 2006 17:21:43 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> # Subject: Re: OT: Sparc not dead yet , Message-ID: <444FE452.3671C930@teksavvy.com>   Doug Phillips wrote:C > This is all true, Kerry. But how much money can x86's competition G > afford to keep spending to stay ahead? The money being spent on x86's  > evolution is huge.  @ AMD yesterday announced a 26% increase in its marketshare. (nice8 statistic). I think it now stands at 22% of server CPUs.  D Intel is expected to launch a new generation of 8086 chips this yearT (Conroe etc) and is hoping to get some back,. Its last financials were disapointing.  G Now, it is often said that there is a lot more money to be made selling F enterprise systems than commodity/low/medium end systems. But where is that money made ?   B When intel sells an IA64 chip, does it ask HP whether that chip isG destined to go to a midrange machine or in a Superdome ? If Intel sells E IA64 chips the same price no matter where they will be used, then the L "enterprise systems are far more profitable" mantra does not apply to intel.  F And because of the 8086 competition, Intel cannot afford to charge too much for that IA64 thing.   F As a result, Intel must spend the same R&D (if not more) on IA64 as onH 8086, sell far fewer units of IA64 compared to 8086, and sell those at aE price point that is still competitive with 8086. There is no way that F this chip can be as profitable to Intel as the 8086, unless HP/SGI are6 paying Intel megabucks to keep the sinking ship alive.  @ Intel needs to duplicate its R&D to develop two architectures inF parralel. For Sun, they are focused on Sparc development only, and are6 buying commodity 8086s for parts of its product line.     6 > Sun is bleeding to death today and SPARC engineeringF > is a big bleeder. At some point, unless Sun is handed a miracle, the( > SPARC division will probably be sold.   E You could argue that HP's developper programme is also a big bleeder. A You could argue that HP's announced $10 billion spending spree to A subsidize marketing/development of that IA64 thing is also a HUGE 	 bleeder.    C The VMS ambassador yesterday said that HP sold $1.6 billion of IA64 D systems in the last 12 months. Lets say HP's share of the $10billionG subsidy is 85% like its share of IA64 systems vs SGI and the other tiny G players. That means that HP would be spending 8.5 billion over the next " 5 years, or $1.7 bilion per year.   1 I bet this $10 billion program won't go very far.     D There are costs of doing business. You want to sell a unique productE with special capabilities others don't have ? You have to pay for the = R&D. And arguably, for the number of cores/threads, Sparc has G capabilities that are way ahead of what IA64 has today and way ahead of E what it will have in a few months when that Montecito thing comes out  with only 2 cores.    A > redirect evolution. A true technology "revolution" will quickly E > obsolete current technology. Money spent on Alpha and Itanium might # > have been better spent elsewhere.     G Actuallt, Intel/HP thought that IA64 thing with EPIC would be a massive F revolution that would crush RISC. And they thought that 8086 would runC out of steam.  Their promises/prediction were wrong on both counts.   F Also, they figured that by shifting much of the logic to compilers, itG would allow IA64 to come to market faster because it would end up being H simpler to develop. IA64 is definitely not early to the market and whileD it isn't AS LATE AS it was when it first came out, it is still quite late in the game.     F For all the naysayers of Sparc, it is still way ahead of IA64 in terms of features.   ------------------------------    Date: 26 Apr 2006 14:41:01 -0700- From: "Doug Phillips" <dphill46@netscape.net> # Subject: Re: OT: Sparc not dead yet C Message-ID: <1146087661.167424.209450@i39g2000cwa.googlegroups.com>    JF Mezei wrote:  > Doug Phillips wrote: > C > > redirect evolution. A true technology "revolution" will quickly G > > obsolete current technology. Money spent on Alpha and Itanium might % > > have been better spent elsewhere.  >  > I > Actuallt, Intel/HP thought that IA64 thing with EPIC would be a massive # > revolution that would crush RISC.   G I remember EPIC explained this way once (sorry I don't remember where):   E "Like collies are dogs and dogs are mammals, EPIC is VLIW and VLIW is  RISC."  F Can't remember to buy milk on the way home but crap like that seems to stick with me.:-)    ------------------------------  % Date: Wed, 26 Apr 2006 20:15:40 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> # Subject: RE: OT: Sparc not dead yet T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401301544@tayexc19.americas.cpqcorp.net>   > -----Original Message-----7 > From: Doug Phillips [mailto:dphill46@netscape.net]=20  > Sent: April 26, 2006 5:01 PM > To: Info-VAX@Mvb.Saic.Com % > Subject: Re: OT: Sparc not dead yet  >=20  
 [snip ...]   >=20 >=20< > > For many of the these Customers, I would suggest that=20 > QA/testing monthlyG > > security patches (Linux/Windows) with their primary applications is @ > > rapidly going to become unacceptable. And as we have seen=20 > by all of the @ > > issues in the last few weeks, if Cust's do not test these=20 > applications@ > > with these monthly security patches then they are open to=20 > all the issues> > > that hit the headlines. In a global market, a companies=20 > credibility can A > > take a serious node dive if this happens to them or worse,=20  > their CustE > > data gets exposed because of one of these monthly security flaws.  > >  >=20F > This is all true, today. But, *any* system can be made secure or not	 > secure.  >=20  E That assumes you are aware of all the known issues. What happens when 3 new failures and holes keep coming out every month?   G For companies that literally have hundreds and in some cases, thousands D of X86 servers, how do you keep them all in sync and up to date when= there are so many new issues being discovered every month?=20   H Keep in mind that IT shops worth their salt will ensure that the patchesH for their main applications (especiually those with Cust data) are fully$ tested before releasing the patches.   >=20B > > > VMS is unusual because its owners keep trying to reinvent=20 > the "wheel",B > > > then they drop their wheel when they see the "old" wheels=20
 > rolling on, ? > > > so they start over and try to invent a different wheel=20  > again. In the / > > > meantime, the big wheels keep on rolling.  > > >  > > >  > > ) > > Can you expand on what you mean here?  > > > > > Perhaps I missed an extract from an earlier thread, but=20 > this does not  > > make much sense on its own.  > >  >=20> > Substitute "CPU" for "wheel". Neither Alpha nor Itanium wereA > "revolutionary" technologies, they were attempts to advance and A > redirect evolution. A true technology "revolution" will quickly E > obsolete current technology. Money spent on Alpha and Itanium might # > have been better spent elsewhere.  >=20  ? So, do you consider x86-64 to be revolutionary or evolutionary?   F CPU bits-n-bytes wil continue to come and go. While I certainly do notF expect that SPARC will make any breakthroughs in terms of market shareH (likely will see decrease), but I have no doubt it will be available forG a long time in the future. Same goes for Alpha and PA-RISC and Power as  well.   E As a server or even chip vendor, you could either spend years looking F for some revolutionary technology to invest in or alternatively selectE ones which have long lifetimes, offer relatively short ROI's and that = offer competitive performance to meet your Customers specific G requirements. Note that I did not necessarily say leading performance - G Sun did very well in the past with SPARC servers that certainly did not  lead the pack.=20     C > DEC ignored Win-tel until it was too late. Too often history does  > repeat itself. >=20  H Absolutely. So did many other large companies like Sun and IBM. However,A if you believe in this "all architectures get replaced over time" * philosophy, then what comes after X86? =20  H As one of our hockey analysts used to say about Wayne Gretzky - "Wayne'sH differentiator is that he seldom skates to where the puck is, but rather0 skates to where he feels the puck is heading .."  B And before you say X86 will never be replaceed by some alternativeC architecture, keep in mind that it was only 10-12 years ago that if A someone had suggested WordPerfect will be displaced by some other 6 product, they would have been laughed out of the room.   :-)   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Wed, 26 Apr 2006 20:20:38 -0400 ' From: Dave Froble <davef@tsoft-inc.com> # Subject: Re: OT: Sparc not dead yet 9 Message-ID: <g66dnemNst4GkM3ZnZ2dnUVZ_smdnZ2d@libcom.com>    Doug Phillips wrote: > Main, Kerry wrote: >  >>>From: Doug Phillips >>>  >> >>[snip ...] >> >>I >>>And you think no one is working on those issues? At one time VMS had a F >>>32 bit "bottleneck". x86 had all kinds of bottlenecks going all theI >>>back to 4 bits. Today's x86 CPU's are more capable than both Linux and E >>>Windows. That's the way evolution in this industry works. Hardware - >>>advances, then software pushes its limits.  >>>  >>G >>You also need to also remember that hardware and software gets better H >>with each release, but what many who think "x86 solutions will replaceF >>everything" forget is that Customer RASS (reliability, availability,< >>scalability and security) requirements are also increasingJ >>exponentially. Hence, while each new release of OS/HW gets better on all? >>platforms, the RASS bar is constantly being moved up as well.  >>D >>Global DC consolidation, national and international regulatory andC >>compliance requirements, global 7x24x365 markets are causing many E >>Customers to re-evaluate how they deliver their IT solutions of the 	 >>future.  >> >  > C > This is all true, Kerry. But how much money can x86's competition G > afford to keep spending to stay ahead? The money being spent on x86's I > evolution is huge. Sun is bleeding to death today and SPARC engineering F > is a big bleeder. At some point, unless Sun is handed a miracle, theH > SPARC division will probably be sold. Whatever is on the SPARC drawingD > board now might or might not ever get to the market. Chips fartherE > along in the process probably will, and a return from that "shorter I > term" market would be a reason Samsung or whoever might want to buy it. A > Anyone willing to do a little homework should come to a similar 
 > conclusion.   G The problem I see with such reasoning is that it's looking only at one  H moment in time.  Yes, right now the AMD Opteron is doing well.  Do keep G in mind that it's been called by some "little EV7".  But whoever is on  F top today has no guarantee of staying there.  Need I mention DEC, and  even Intel?   G > Some other factors: Windows and Linux aren't the only OS's that could G > run on x86. The focus on DT means that the majority of big users need E > better distrubuted computing rather than huge monolithic crunchers. I > There are only a few places where monolithic super-computing is needed, D > and there will always be a place for the next "Cray". IBM is still  > making money selling big-iron.  @ There will always be a place for the specialty systems, correct.  F > The Reliability-Availability-Security bar ("goal") is and always hasI > been at 100%. Scalability has a few different meanings depending on the H > problem. As you say, IT users (customers) must continually re-evaluateA > their IT service delivery. Likewise, IT solution providers must = > continually re-evaluate how to best spend their R&D dollar.   H Do you really want a world where everyone but one vendor just gives up? G   If you believe that you cannot win, and never start a race, then the  8 opponent wins by default.  Not everybody is a 'quitter'.  J >>For many of the these Customers, I would suggest that QA/testing monthlyE >>security patches (Linux/Windows) with their primary applications is I >>rapidly going to become unacceptable. And as we have seen by all of the H >>issues in the last few weeks, if Cust's do not test these applicationsJ >>with these monthly security patches then they are open to all the issuesI >>that hit the headlines. In a global market, a companies credibility can G >>take a serious node dive if this happens to them or worse, their Cust C >>data gets exposed because of one of these monthly security flaws.  >> >  > F > This is all true, today. But, *any* system can be made secure or not	 > secure.   C Well some have had lots of time, and aren't a bit closer, possibly  
 further away.   I >>>VMS is unusual because its owners keep trying to reinvent the "wheel", H >>>then they drop their wheel when they see the "old" wheels rolling on,G >>>so they start over and try to invent a different wheel again. In the , >>>meantime, the big wheels keep on rolling. >>>  >>>  >>' >>Can you expand on what you mean here?  >>G >>Perhaps I missed an extract from an earlier thread, but this does not  >>make much sense on its own.  >> >  > > > Substitute "CPU" for "wheel". Neither Alpha nor Itanium wereA > "revolutionary" technologies, they were attempts to advance and A > redirect evolution. A true technology "revolution" will quickly E > obsolete current technology. Money spent on Alpha and Itanium might # > have been better spent elsewhere.    Who should work on evolution?   G I think Alpha was a decent solution to the problems it was intended to  F address, and it did the job well.  The only reason Alpha is not alive G today is because Compaq did not want to be in the CPU business, and if  D they owned the Pentium, they'd still have killed it.  Alpha is dead I because the people in charge didn't understand the business they were in.   C > DEC ignored Win-tel until it was too late. Too often history does  > repeat itself.   That I'll agree with.   3 What I won't agree with is the 'quitter' mentality.   F Where would AMD be today if they just figured Intel would control the H CPU world and it was no use competing?  They could have concentrated on I something else.  Lots of money in electronics.  But no, they believed in  F what they were doing, and they upset the hugh unbeatable Intel.  Just C read that AMD has a twenty something precent share in last quarter  . server shipments, up from 16 % or thereabouts.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Wed, 26 Apr 2006 23:47:57 -0400 ( From: Bill Todd <billtodd@metrocast.net># Subject: Re: OT: Sparc not dead yet G Message-ID: <pbCdndLND5Zso83ZnZ2dnUVZ_u-dnZ2d@metrocastcablevision.com>    Karsten Nyblad wrote:    ...   H > The problem with your post is that you can make faster and faster x86 K > CPUs and chip sets for large computers, but it will not help you getting  @ > large computers run Linux and Windows efficiently.  There are H > bottlenecks in these OSes such that they cannot utilize more than 4-8 J > cores.  AMD and Intel can introduce virtualization and other facilities H > usable for building large machines, but those large machines will not B > get into widespread use before people can get an OS that scales.  E Well, one could observe that Solaris is available on x86 systems and  H scales *extremely* well.  But even with specific respect to Windows and : Linux, your information seems to be seriously out of date.  G For example, the best unclustered current 64-processor Superdome TPC-C  E score was obtained not running HP-UX but (gasp!) Windows Server 2003  E Datacenter Edition (64-bit) and SQL Server 2005; indeed, HP has been  C submitting respectable 64-processor Superdome TPC-C configurations  G running Windows for nearly 3 years (so decent Windows support for such  C configurations is hardly a recent development).  NEC's unclustered  G 32-processor Itanic TPC-C submissions have obtained respectable scores  E using SUSE Linux Enterprise Server for the past couple of years, and  1 used Windows before that with reasonable results.   I Windows has also often been the large-configuration OS of choice for SAP  G SD 2-tier on hardware that permitted its use (e.g., its Itanic and x86  H scores both beat the best HP-UX Itanic score at the 32-processor system G size).  Since SAP SD doesn't give much prominence to price/performance  2 considerations, Linux submissions are rarer there.  D And you might want to ask SGI how well Linux scales to large system F sizes, since they've bet the company that it can (and they, more than 9 perhaps anyone else, specialize in *very* large systems).    - bill   ------------------------------  % Date: Wed, 26 Apr 2006 15:26:00 -0400 . From: "Carl Friedberg" <frida.fried@gmail.com>' Subject: Re: Replacing drives in bricks I Message-ID: <890539d90604261226u23c2c13bv9b180f4663f9f1f7@mail.gmail.com>   	 Hi David,   5 On 4/23/06, d b turner <dbturner@islandco.com> wrote: I > That's why you buy from a reputable dealer that has a little clout with  > distributors ..E > Would you ever buy a TV or PC for home with 30 days warranty???????  > H It's not 30 days, but wonderful SONY TV products come with a conditionalC 90 day warranty now. It's one more reason I won't buy SONY anymore.    ------------------------------  # Date: Wed, 26 Apr 2006 18:55:31 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com># Subject: Re: TIMEPROMPTWAIT problem 1 Message-ID: <DmP3g.6869$gM.1901@news.cpqcorp.net>    Bob Koehler wrote:9 >    VAX 11/785 VMS4.7, so scratch your grey matter deep.   I    Grey matter implies (as it was then known) VAX/VMS V5.*, while Orange  G (or, more correctly, Chinese Red) matter would be more appropriate for  0 V4.* questions.  (Sorry, serious geek joke.  :-)    F >    I have a problem with the TOY clock.  To work around it I want to2 >    set TIMEPROMPTWAIT to always prompt for time. > H >    My documenation says I need to set it to a value greater than 32767H >    (it seems to be 16 bit).  I've tried 65535, 32768, 0, 1, 32767, and >    lot of other values.   H    If the word-length value is negative, OpenVMS VAX is supposed to sit  in the loop.  H >    This doesn't seem to work.  What I get is a system that prompt only( >    if it thinks they TOY value is bad.  H    I'd expect that a negative word value would cause prompting, so this I looks like some sort of a bug, or something that got fixed/changed after   V4.7.   I >    The system has a habit of coming up from power off with a TOY value  E >    in June, which doesn't cause a prompt since the value on disk is  >    in April. > J >    Is this a bug in 4.7 or misdocumentation (I'm using the grey wall)?  I >    The last time I had to use this wwas on 11/780 under VMS 3.6 and it   >    worked as advertized.  G    SETTIME is the other parameter typically involved here, but I don't  / recall if that parameter existed that far back.   E    If you can issue a SET TIME with the particular disk, OpenVMS VAX  I should resynchronize your clock with the value in your system disk image.    ------------------------------  % Date: Wed, 26 Apr 2006 16:21:22 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> # Subject: Re: TIMEPROMPTWAIT problem , Message-ID: <444FD631.26804342@teksavvy.com>   Hoff Hoffman wrote: J >    Grey matter implies (as it was then known) VAX/VMS V5.*, while OrangeH > (or, more correctly, Chinese Red) matter would be more appropriate for > V4.* questions.   G You mean hundreds of thousands of people had it wrong whjen they called F it the "orange books" ??????? How come DEC let this error exist for so
 long ? :-)  C Or was "Chinese Red" something that was forbidden to use in the USA > (like Cuban cigars)  when China was considered an ennemy ? :-)  I >    I'd expect that a negative word value would cause prompting, so this J > looks like some sort of a bug, or something that got fixed/changed after > V4.7.   E So, are you going to look into it, and issue a patch for VMS 4.7 this - afternoon that fixes this long standing bug ?   F >    If you can issue a SET TIME with the particular disk, OpenVMS VAXK > should resynchronize your clock with the value in your system disk image.     G If the TOY clock is off by 10 seconds, when you boot, the VMS time will < be off by 10 seconds, right ? So if you do a SET TIME and itG recalculates the current time by taking te absolute time stored on disk B and adding the TOY clock's delta  time , wouldn't you still get 10; seconds difference with the real time outside the machine ?   F Is there a way to access , in DCL, the absolute time that is stored on disk ?    E If you know that your TOY clock if 20 seconds too fast per hour, then F calculating the hours between current time and the time stored on diskH would allow you to then calculate the error in the time and then issue a8 SET TIME="+xx:yy:zz" command to correct it more or less.   ------------------------------    Date: 26 Apr 2006 15:37:23 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) # Subject: Re: TIMEPROMPTWAIT problem 3 Message-ID: <upvlOy2TsBZV@eisner.encompasserve.org>   ^ In article <1146072822.376439.116450@i40g2000cwc.googlegroups.com>, mckinneyj@saic.com writes:7 >> VAX 11/785 VMS4.7, so scratch your grey matter deep.  >  > F >>   I have a problem with the TOY clock.  To work around it I want to2 >>   set TIMEPROMPTWAIT to always prompt for time. > H > If VMS 4.7 has a SETTIME SYSGEN parameter you'll likely have to set itB > to a value of 1 (in addition to setting TIMEPROMPTWAIT > 32767).  :    OK, thats the kind of thing I was looking for.  Thanks.   ------------------------------    Date: 26 Apr 2006 15:36:48 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) # Subject: Re: TIMEPROMPTWAIT problem 3 Message-ID: <JXPwkad4uFPN@eisner.encompasserve.org>   ` In article <DmP3g.6869$gM.1901@news.cpqcorp.net>, Hoff Hoffman <hoff-remove-this@hp.com> writes: > G >    If you can issue a SET TIME with the particular disk, OpenVMS VAX  K > should resynchronize your clock with the value in your system disk image.  >   D   We've done that many times.  The problem is the TOY clock comes upG   as June, the time on the disk when the system was shutdown was April, C   and VMS thinks time rationally moved forward several weeks so the #   default setting causes no prompt.    ------------------------------    Date: 26 Apr 2006 15:39:03 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) # Subject: Re: TIMEPROMPTWAIT problem 3 Message-ID: <cLoX$geIRydp@eisner.encompasserve.org>   ` In article <DmP3g.6869$gM.1901@news.cpqcorp.net>, Hoff Hoffman <hoff-remove-this@hp.com> writes: > Bob Koehler wrote:: >>    VAX 11/785 VMS4.7, so scratch your grey matter deep. > K >    Grey matter implies (as it was then known) VAX/VMS V5.*, while Orange  I > (or, more correctly, Chinese Red) matter would be more appropriate for  2 > V4.* questions.  (Sorry, serious geek joke.  :-) >   C    I thought 2.* was blue and 3.* was Chinese Red.  Or was 4.* also     Chinese Red?   D    IIRC two major versions were the same color, I can't recall if it    was 3 and 4 or 4 and 5.   ------------------------------  # Date: Wed, 26 Apr 2006 21:32:05 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com># Subject: Re: TIMEPROMPTWAIT problem 1 Message-ID: <pFR3g.6885$HL.2916@news.cpqcorp.net>    Bob Koehler wrote:b > In article <DmP3g.6869$gM.1901@news.cpqcorp.net>, Hoff Hoffman <hoff-remove-this@hp.com> writes:H >>    If you can issue a SET TIME with the particular disk, OpenVMS VAX L >> should resynchronize your clock with the value in your system disk image. >> > F >   We've done that many times.  The problem is the TOY clock comes upI >   as June, the time on the disk when the system was shutdown was April, E >   and VMS thinks time rationally moved forward several weeks so the % >   default setting causes no prompt.   D    The VAX TOY clock is an offset from the year value stored in the F system image.  It doesn't really know about years.  It gets messed up F annually, when the number of days rolls over, if no SET TIME has been . performed within the first three months or so.  E >    I thought 2.* was blue and 3.* was Chinese Red.  Or was 4.* also  >    Chinese Red?  > F >    IIRC two major versions were the same color, I can't recall if it >    was 3 and 4 or 4 and 5   F    Blue, Blue, Orange, Orange, Gray, White, White (with colors), IIRC.   ------------------------------  % Date: Wed, 26 Apr 2006 21:14:19 -0400 3 From: "Richard B. Gilbert" <rgilbert88@comcast.net> # Subject: Re: TIMEPROMPTWAIT problem : Message-ID: <jt6dnT5KLMJxh83ZnZ2dnUVZ_tSdnZ2d@comcast.com>   Bob Koehler wrote:  9 >    VAX 11/785 VMS4.7, so scratch your grey matter deep.  > F >    I have a problem with the TOY clock.  To work around it I want to2 >    set TIMEPROMPTWAIT to always prompt for time. > H >    My documenation says I need to set it to a value greater than 32767H >    (it seems to be 16 bit).  I've tried 65535, 32768, 0, 1, 32767, and >    lot of other values.  > H >    This doesn't seem to work.  What I get is a system that prompt only( >    if it thinks they TOY value is bad. > I >    The system has a habit of coming up from power off with a TOY value  E >    in June, which doesn't cause a prompt since the value on disk is  >    in April. > J >    Is this a bug in 4.7 or misdocumentation (I'm using the grey wall)?  I >    The last time I had to use this wwas on 11/780 under VMS 3.6 and it   >    worked as advertized. > G IIRC, VMS 4.7 was "Orange (Chinese Red) Wall" not "Gray Wall".  Aren't  3 we reaching back pretty close to twenty years here?    ------------------------------  % Date: Wed, 26 Apr 2006 14:00:56 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: Re: Various comments (decus presentation), Message-ID: <444FB54F.100C7D2B@teksavvy.com>   Rob Brown wrote:D > Oooh!  Oooh!  I could use some of those on a customer PDP-11.  HowG > much?  Where?  Etc.  I checked http://www.nemonixengineering.com/ and F > did not find anything about disks.  Am I looking in the right place? > Who can I contact?  R The president made a quick presentation yesterday. His name is Daniel L. Bumbarger  H Phone at 508 393 7700  email: eng nemonix at nemonix engineering dot com.  (remove spaces to assemble the email address)    A BTW, he said that he saw a MFM (RF54) disk go on sale at ebay for H $12,000 !!!! Looks like my RD54 lying on a shelf may be worth a LOT more than I thought !!!!!!    ------------------------------  # Date: Wed, 26 Apr 2006 17:36:34 GMT % From: Rob Brown <mylastname@gmcl.com> 2 Subject: Re: Various comments (decus presentation)E Message-ID: <Pine.LNX.4.61.0604261130430.19837@localhost.localdomain>   $ On Wed, 26 Apr 2006, JF Mezei wrote:  G > Oh, Nemonix does build new disks for VAX systems. It can build an RZ  D > drive equivalent with 7 gigs on it. Those drives are mechanically : > brand new, but are fully compatible with the old drives.  C Oooh!  Oooh!  I could use some of those on a customer PDP-11.  How  F much?  Where?  Etc.  I checked http://www.nemonixengineering.com/ and E did not find anything about disks.  Am I looking in the right place?   Who can I contact?   Thanks for the info.   - Rob      --    B Rob Brown                        b r o w n a t g m c l d o t c o mA G. Michaels Consulting Ltd.      (866)438-2101 (voice) toll free! 6 Edmonton                         (780)438-9343 (voice)5                                   (780)437-3367 (FAX) 2                                   http://gmcl.com/   ------------------------------   Date: 26 Apr 2006 18:33:54 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)2 Subject: Re: Various comments (decus presentation), Message-ID: <4b9soiF10raqnU1@individual.net>  , In article <444FB54F.100C7D2B@teksavvy.com>,0 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > C > BTW, he said that he saw a MFM (RF54) disk go on sale at ebay for J > $12,000 !!!! Looks like my RD54 lying on a shelf may be worth a LOT more > than I thought !!!!!!   B RF is DSSI, not MFM and I could not find any reference to an RF54.B And even if there was, I seriously doubt there is anyone (not evenC boob) stupid enough to pay $12,000 for a 159MB MFM disk.  Which, of B course, makes you wonder if the other things he had to say were of equal value.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Wed, 26 Apr 2006 16:12:20 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: Re: Various comments (decus presentation), Message-ID: <444FD413.DBE50C0C@teksavvy.com>   Bill Gunshannon wrote:D > RF is DSSI, not MFM and I could not find any reference to an RF54.  H Sorry, my keyboard moved while I was talking. I meant RD54. And yeah, he9 mentioned it had gone on EBAY for that ridiculous amount.   E For some people paying $12k for a replacement disk would be less than  having to change the system.   ------------------------------  % Date: Wed, 26 Apr 2006 16:55:17 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: Re: Various comments (decus presentation), Message-ID: <444FDE22.E5EABFE9@teksavvy.com>   Oh, another thing I forgot....  G A VMS ambassador confirmed that about half of VMS engineering is now in D India. Forget the name of the company there, but he said it had beenG associated with DEC for 20 years, but it was not named "Digital India". 9 Perhaps that company changed names with the HP purchase ?     E So, if DECTALK were still part of the Digital portfolio, there is 50% D chance that it would now speak with an Indian accent :-) :-) :-) :-)   ------------------------------   Date: 26 Apr 2006 21:10:56 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)2 Subject: Re: Various comments (decus presentation), Message-ID: <4ba5v0F108pq1U1@individual.net>  , In article <444FD413.DBE50C0C@teksavvy.com>,0 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > Bill Gunshannon wrote:E >> RF is DSSI, not MFM and I could not find any reference to an RF54.  > J > Sorry, my keyboard moved while I was talking. I meant RD54. And yeah, he; > mentioned it had gone on EBAY for that ridiculous amount.  > G > For some people paying $12k for a replacement disk would be less than  > having to change the system.  C Well, RD54 is MSCP.  I can buy a QBUS SCSI controller and SCSI disk C for a lot less.  It will show up as DUwhatever, just like the RD54. B There is no guarantee the replacement RD54 will work for very longF (if at all if you get it on Ebay).  Now name one person who has boughtA an RD54 for $12,000.  Get the picture.  Hogwash.  Oh yeah, I have @ RD54's in my basement and I have never paid more than $20.00 for one.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Wed, 26 Apr 2006 17:01:57 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: Re: Various comments (decus presentation), Message-ID: <444FDFB1.4918CF35@teksavvy.com>   Ian Miller wrote: C > Apparently there are under utilized VMS systems out there in some  > companies.A > There are also other uses for the TICAP etc stuff e.g. DR test.     E Lets say your main server has 8 CPUs enabled, your backup machine may F have just one CPU enabled. In case of a disaster, you *SHOULD* be ableF to shift the "licences" of the 7 surplus CPUs to the backup machine to enabled them there.   D I say SHOULD because the ambassador who made the presentation didn't@ know precisely if this could be done with the planned managementG software. If the windows box is in the same building as your production E system that has just been made unusuable due to a neutron bomb having E exploded on its roof, then you wouldn't have the tools/keys to enable  the CPUs on the DR machine.   @ Also, the worlload management software is supposed to be able to2 automatically enable a new CPU when one CPU fails.   ------------------------------  # Date: Wed, 26 Apr 2006 22:43:01 GMT & From: John Reagan <john.reagan@hp.com>2 Subject: Re: Various comments (decus presentation)1 Message-ID: <VHS3g.6889$IR.3815@news.cpqcorp.net>    JF Mezei wrote:   H > Also found out that one of the big time VMS engineers who was intimateJ > with bits and bytes is no longer working for the owner of VMS. Left someH > 18 months ago and is now working on his own. Looks like job cust at HP? > did hit VMS engineering. His name is sort of like a secret...   I 18 months?  That doesn't ring a bell.  Yes, some people have left either  F via retirement or on to other companies.  All the ones I know of have H already been mentioned in this newsgroup.  No secrets that I know about.   --   John Reagan / HP Pascal/{A|I}MACRO for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------  # Date: Wed, 26 Apr 2006 22:46:16 GMT & From: John Reagan <john.reagan@hp.com>2 Subject: Re: Various comments (decus presentation)1 Message-ID: <YKS3g.6891$XR.2043@news.cpqcorp.net>    JF Mezei wrote:   > Oh, another thing I forgot.... > I > A VMS ambassador confirmed that about half of VMS engineering is now in / > India. Forget the name of the company there,    I It is named Hewlett-Packard.  All the employees there have HP badges and  + the buildings have HP logos on the outside.   F As for "half", well it depends on how you measure it.  Lines of code? G Development vs maintenance?  There are many talented engineers working   there (I've met some of them).   --   John Reagan / HP Pascal/{A|I}MACRO for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------  % Date: Wed, 26 Apr 2006 19:42:40 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: Re: Various comments (decus presentation), Message-ID: <44500553.540F5619@teksavvy.com>   John Reagan wrote:G > via retirement or on to other companies.  All the ones I know of have J > already been mentioned in this newsgroup.  No secrets that I know about.  G His last name is reminiscent of a secret, underCover.t... I dind't mean ! that his leaving was a secret :-)    ------------------------------  % Date: Wed, 26 Apr 2006 19:31:52 -0400 3 From: "Peter Weaver" <newsonly@weaverconsulting.ca> 2 Subject: Re: Various comments (decus presentation)9 Message-ID: <JpT3g.1570$1V4.122413@news20.bellglobal.com>   ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  & news:444FA808.43BE7F41@teksavvy.com...D > There was a DECUS presentation in Montreal yesterday (or whavever  > this< > week's name for the organisation formerly known as DECUS). > ...   : Here is my recollection of the Montreal Encompass Seminar;   Someone said a few words.  JF asked a question. Someone said a few words.  JF asked a question. Someone said a few words.  JF asked a question. Someone said a fe. JF asked a question. Someo. JF asked a question. S. JF asked a question.B Someone said we were 30 minutes into the presentation and only on  slide 2. JF asked a que.  JF aske. JF asked a question.  F :) - It wasn't quite that bad because most of his questions were very D interesting and very on-topic. BTW: It was nice to finally meet you B JF, as I sat in the taxi (switching my view between the tow truck G moving the 18 wheeler with a broken axel off the road and watching the  E airplane I was supposed to be on taking off) I remembered that I was  G going to thank you for your whois program. I use it every two or three  G days tracking down people who are trying to break into my system using   SSH.     ------------------------------  % Date: Wed, 26 Apr 2006 19:47:52 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: Re: Various comments (decus presentation), Message-ID: <4450068B.51F12BA9@teksavvy.com>   John Reagan wrote:J > It is named Hewlett-Packard.  All the employees there have HP badges and- > the buildings have HP logos on the outside.   E The ambassador gave the name of a large Indian firm. It wasn't "HP".  H Just reporting what he said.  Perhaps the company was recently purchased by HP and rebadged as "HP" ?  8 > As for "half", well it depends on how you measure it.   H I'd be more interested in knowing what parts of VMS are still "in house"B and what parts are gone to India. I know that ALL-IN-1 was sent toH India, but that is a retired product in maintenance mode. Does this meanA that any product already in india is a product that is slated for  retirement ?   ------------------------------  % Date: Wed, 26 Apr 2006 20:16:21 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: Re: Various comments (decus presentation), Message-ID: <44500D37.BC7B5357@teksavvy.com>   Peter Weaver wrote:  > Someone said a few words.  > JF asked a question.  D You could have said "someone asked a question"...  Now, my cover has* been blown, reputation ruined :-( :-( :-(   F (Note, I had told the organisers to bring duct tape to cover my mouth,) and they didn't. So it is their fault :-)   C > Someone said we were 30 minutes into the presentation and only on 
 > slide 2.  E I wasn't the *only* one who was asking questions in that one session. F Many others  had also made comments. In the other sessions where I didF ask questions, the sessions ended either on time or helped catch on on
 the delay.    H When a speaker does insist that people ask questions to make the session& "interactive", why not ask questions ?   ------------------------------    Date: 26 Apr 2006 12:59:54 -0700" From: dave.baxter@bannerhealth.com Subject: Virtual I/O CacheB Message-ID: <1146081594.152677.33730@v46g2000cwv.googlegroups.com>  D       We are trying to trouble should a problem on a GS1280, running& OVMS7.3-2 and TCPIP services 5.4 ECO5.D      While checking memory on one node it was noted that Virtual I/O? Cache "Free" was = 0.    It was also discovered that the system C parameter VCC_FLAGS is set to "1", which is the VAX default, rather ' than to "2" which is the alpha default.   ; Q1.    Is Virtual I/O Cache, Free = 0, a potential issue??? ; Q2.    Is having VCC_FLAGS set to 1 on an Alpha system OK?? @ Q2b.        would I be better off with it set to 2, what are the respective benefits.??   Thanks   Dave   ------------------------------    Date: 26 Apr 2006 17:27:11 -0700$ From: "AEF" <spamsink2001@yahoo.com> Subject: Re: Virtual I/O CacheC Message-ID: <1146097631.031325.175560@u72g2000cwu.googlegroups.com>   # dave.baxter@bannerhealth.com wrote: @ > We are trying to trouble should a problem on a GS1280, running( > OVMS7.3-2 and TCPIP services 5.4 ECO5.F >      While checking memory on one node it was noted that Virtual I/OA > Cache "Free" was = 0.    It was also discovered that the system E > parameter VCC_FLAGS is set to "1", which is the VAX default, rather ) > than to "2" which is the alpha default.  > = > Q1.    Is Virtual I/O Cache, Free = 0, a potential issue???   F No. This is normal. The VIOC uses memory on a last-priority basis. YouG can read about it in the Performance Manual. You'll even see very small & values in the examples in this manual.  = > Q2.    Is having VCC_FLAGS set to 1 on an Alpha system OK??   C Well, I don't know the details except that I think it's very bad to + have both VIOC and XFC on at the same time!   B > Q2b.        would I be better off with it set to 2, what are the > respective benefits.?? >  > Thanks >  > Dave   ------------------------------  % Date: Wed, 26 Apr 2006 20:00:37 -0500 % From: Dan Foster <usenet@evilphb.org>  Subject: Re: Virtual I/O Cache5 Message-ID: <slrne505tk.rm2.usenet@zappy.catbert.org>    In article <1146081594.152677.33730@v46g2000cwv.googlegroups.com>, dave.baxter@bannerhealth.com <dave.baxter@bannerhealth.com> wrote: F >       We are trying to trouble should a problem on a GS1280, running( > OVMS7.3-2 and TCPIP services 5.4 ECO5.F >      While checking memory on one node it was noted that Virtual I/OA > Cache "Free" was = 0.    It was also discovered that the system E > parameter VCC_FLAGS is set to "1", which is the VAX default, rather ) > than to "2" which is the alpha default.   = > Q1.    Is Virtual I/O Cache, Free = 0, a potential issue???    Don't think so?   = > Q2.    Is having VCC_FLAGS set to 1 on an Alpha system OK??   F I believe so, but performance is ***FAR*** better with the XFC insteadB of VIOC. The difference is night-and-day, even on the smallest VMS( systems running 7.3-1 or 7.3-2 on Alpha.  G I have heard of OpenVMS sites where end users asked the system managers B if they had secretly sneaked in faster hardware overnight? (System/ managers had done nothing but turn on the XFC.)   - My own experiences with the XFC mirrors this.   A There was at least one nasty XFC bug in 7.2-1 or thereabouts that F required a key XFC patch to be applied. Workaround was to disable XFC,H so that might have been the reason why it was set to VCC_FLAGS=1 on your system.   A However, HP OpenVMS Engineering has long since ironed out the XFC H issues, so they felt comfortable in making it a default for 7.3-x/Alpha.  E (7.3-x also has the bug fix for that particular bug integrated, too.)   B > Q2b.        would I be better off with it set to 2, what are the > respective benefits.??  > In my honest opinion, that's a definitive and unqualified yes.  2 Benefits? Tremendous performance boost, basically.  B A small table comparing VIOC vs XFC as well as a short list of XFC@ benefits can be found in section 18.2 of this one-page document:  ; http://h71000.www7.hp.com/DOC/73final/6017/6017pro_077.html    -Dan   ------------------------------  # Date: Wed, 26 Apr 2006 19:52:05 GMT A From: "Charlie McCutcheon" <charlie.mccutcheon.removetext@hp.com>  Subject: Re: VMS732_ACRTL-V0300 1 Message-ID: <FbQ3g.6879$ue.1955@news.cpqcorp.net>   L The ACRTL kit was to support the timezone changes with the functions in the J CRTL that allow you to manipulate timezones.  It should work fine without  the Timezone kit.   E I'm told that the timezone TZ kit should available (or will be soon).    ------------------------------   End of INFO-VAX 2006.232 ************************