1 INFO-VAX	Wed, 23 Aug 2006	Volume 2006 : Issue 468       Contents: Datatrieve/CDD protection  RE: Datatrieve/CDD protection * debugger source display problem on iTanium. Re: debugger source display problem on iTanium+ Re: Dell Powervault 120T autoloader on VMS? + RE: Dell Powervault 120T autoloader on VMS? + Re: Dell Powervault 120T autoloader on VMS? + RE: Dell Powervault 120T autoloader on VMS?  Re: Enabling SMTP in VAX/VMS' No more Oracle Standard Edition for VMS + Re: No more Oracle Standard Edition for VMS + Re: No more Oracle Standard Edition for VMS  Re: On-chip, 7-way associative Re: On-chip, 7-way associative Re: On-chip, 7-way associativeA Re: openvms - java - timezone - daylight savings - what the heck! A Re: openvms - java - timezone - daylight savings - what the heck! A Re: openvms - java - timezone - daylight savings - what the heck!  Re: PDF parser on VMS ?  Re: PDF parser on VMS ?  Re: Personal note - goodbye !  Re: Personal note - goodbye !  Re: Personal note - goodbye ! $ Re: Printing to a HP LaserJet 2605dn$ Re: Printing to a HP LaserJet 2605dn$ Re: Printing to a HP LaserJet 2605dn$ Re: Printing to a HP LaserJet 2605dn2 Re: SEPPUCLU bugcheck introducing new cluster node2 Re: SEPPUCLU bugcheck introducing new cluster node  F ----------------------------------------------------------------------    Date: 22 Aug 2006 16:21:03 -0700( From: "Rich Jordan" <jordan@ccs4vms.com>" Subject: Datatrieve/CDD protectionB Message-ID: <1156288863.727463.284010@75g2000cwc.googlegroups.com>  G We've never worked with datatrieve, and only very peripherally with CDD E (at MANMAN sites where CDD was dropped when MANMAN no longer required 0 it, so our exposure was mostly deinstalling it).  G Got a site now with issues after a VAX-Alpha move.  Datatrieve runs for A privileged users, but not for non-priv;d.  The problem is not any ; manner of file level access (tested severely, also full SET F WATCH/CLASS=ALL runs to verify).  If a non-priv'd user is given BYPASSE or SYSPRV, Datatrieve starts working for them.  The error seems to be & that Datatrieve can't find its schemasG ("CDD$DEFAULT.MAND.MANDB.DBM$SUBSCHEMAS.DTRMA" not found in dictionary) E due to a protection issue, I assume within the CDD protection scheme.   G We;re using the CDD and DTR dictionaries imported from the VAX.  MANMAN D schemas in the CDD were built by a MANMAN installation on the Alpha.  E What seems funny to me (as a non DTR user) is if I run MCR DMU with a C priv'd account I can SET DEF MM$CDDSCHEMA, list the contents, check > protection, etc.  If I do it with a non-priv'd account it saysA MM$CDDSCHEMA it says directory or object not found.  MM$CDDSCHEMA ? points to MM$DISK:[MANMAN.CDD.SCHEMA], all of which directories D (currently for testing) have full W:RWE access, all the files in the> directory have W:RWE as well as the complex CDD ACLs in place.  E If I log on as SYSTEM, show protections on MM$CDDSCHEMA (which works) A then try to set protections for the non-priv'd users UIC, it says C directory or object not found (tried using both teh logical and the G pathname); says the same if I try to set protection on one of the items C that shows up when I issue a list command at that point; I can list & them but can't set protection on them.  E Tomorrow I'm digging old CDs out to see if I can find a DMU reference B manual.  Found user and install guides for CDD online but not DMU.  G If anyone has a pointer to troubleshooting info on DTR with CDD, or has 1 some thoughts or helpful hints I'd be grateful.      Rich CCS    ------------------------------  % Date: Tue, 22 Aug 2006 20:06:39 -0400 , From: <Barry.Treahy@EmersonNetworkPower.com>& Subject: RE: Datatrieve/CDD protectionM Message-ID: <63A4454BFCE1C048B2683DBB63A3633363C618@ETP-CIN-US-EX01.etp1.com>    Hi Rich,  ? Knowing which versions might help but if memory serves, CDD was D dependent on Rdb and this sounds like you have Rdb permission issuesD with the database, not necessarily external RMS file permissions but2 perhaps internally with the ACL's on the tables...  ' Barry Treahy, Jr                    =20  Vice President/CIO Midwest Microwave, Inc. , Emerson Network Power Connectivity Solutions, E-mail: Barry.Treahy@EmersonNetworkPower.com Phone: 480/314-1320  Cell:     480/216-9568 Fax:     480/661-7028  =20 2                        ... but it's a DRY HEAT!=20 -----Original Message-----0 From: Rich Jordan [mailto:jordan@ccs4vms.com]=20& Sent: Tuesday, August 22, 2006 4:21 PM To: Info-VAX@Mvb.Saic.Com " Subject: Datatrieve/CDD protection  G We've never worked with datatrieve, and only very peripherally with CDD E (at MANMAN sites where CDD was dropped when MANMAN no longer required 0 it, so our exposure was mostly deinstalling it).  G Got a site now with issues after a VAX-Alpha move.  Datatrieve runs for A privileged users, but not for non-priv;d.  The problem is not any ; manner of file level access (tested severely, also full SET H WATCH/CLASS=3DALL runs to verify).  If a non-priv'd user is given BYPASSE or SYSPRV, Datatrieve starts working for them.  The error seems to be & that Datatrieve can't find its schemasG ("CDD$DEFAULT.MAND.MANDB.DBM$SUBSCHEMAS.DTRMA" not found in dictionary) E due to a protection issue, I assume within the CDD protection scheme.   G We;re using the CDD and DTR dictionaries imported from the VAX.  MANMAN D schemas in the CDD were built by a MANMAN installation on the Alpha.  E What seems funny to me (as a non DTR user) is if I run MCR DMU with a C priv'd account I can SET DEF MM$CDDSCHEMA, list the contents, check > protection, etc.  If I do it with a non-priv'd account it saysA MM$CDDSCHEMA it says directory or object not found.  MM$CDDSCHEMA ? points to MM$DISK:[MANMAN.CDD.SCHEMA], all of which directories D (currently for testing) have full W:RWE access, all the files in the> directory have W:RWE as well as the complex CDD ACLs in place.  E If I log on as SYSTEM, show protections on MM$CDDSCHEMA (which works) A then try to set protections for the non-priv'd users UIC, it says C directory or object not found (tried using both teh logical and the G pathname); says the same if I try to set protection on one of the items C that shows up when I issue a list command at that point; I can list & them but can't set protection on them.  E Tomorrow I'm digging old CDs out to see if I can find a DMU reference B manual.  Found user and install guides for CDD online but not DMU.  G If anyone has a pointer to troubleshooting info on DTR with CDD, or has 3 some thoughts or helpful hints I'd be grateful. =20    Rich CCS    ------------------------------    Date: 22 Aug 2006 10:43:50 -0700# From: "Don" <nospam@dgcomputer.com> 3 Subject: debugger source display problem on iTanium C Message-ID: <1156268630.658788.260860@m79g2000cwm.googlegroups.com>   C We have a realtively large (3.5MB) executable that we are trying to  debug.  For a small D number of modules(5), the debugger does not believe source files are available.  We get the message:  ? %DEBUG-W-NOSRCLIN, no source line for address 00000000000AA7200   F The source is displayed for other modules in the same source directory / object library.   F An Analyze/image/section=debug command appears to show the source file
 referencesB for the modules in question, even though the debugger is unable to display the source.   D As a test, I linked an executable with only the main program and the few modules C that couldn't display source.  The debugger was able to find source  files for all of theD modules included in this much smaller executable.  I infer from this that the object ; modules are correctly compiled with /debug and not corrupt.    Version numbers:    OpenVMS 8.2-1 on rx2620    HP C V7.2-001    Linker I02-240 '    OpenVMS I64 Debug64 Version V8.2-022    Any suggestions??  Thank you, 	 Don Gregg    ------------------------------  # Date: Tue, 22 Aug 2006 18:16:24 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>7 Subject: Re: debugger source display problem on iTanium . Message-ID: <YRHGg.77$vJ1.62@news.cpqcorp.net>  
 Don wrote:E > We have a realtively large (3.5MB) executable that we are trying to A > debug.  For a small number of modules(5), the debugger does not % > believe source files are available.  ...  > Any suggestions??  Thank you,   O    I'd confirm that the object code used was built with debug -- I've chased a  M few of these in my own code over the years, and I've found cases where I was  M building with a non-debug or otherwise stale object or object library.  (You  Q know, the usual "Where the heck is my source change?" problem.)  Then after that  N confirmation, I'd package up the reproducer, and ring up the customer support  center.   P    I haven't confirmed current ECOs for the debugger and the linker and for the K compiler.  (That's another obvious step, and I would expect you've already   confirmed that.)   ------------------------------    Date: 22 Aug 2006 11:46:38 -0700 From: "cmk" <ckaron@gmail.com>4 Subject: Re: Dell Powervault 120T autoloader on VMS?B Message-ID: <1156272398.453917.161020@75g2000cwc.googlegroups.com>   Malcolm Dunnett wrote:= > Has anyone managed to get a Dell Powervault 120T autoloader % > working with VMS on an Alphaserver?  > 8 > I can see the drive (mkb500) and the robot (jkb100) at@ > the Alpha console level, but VMS 8.2 doesn't appear to see the; > robot and MRU (v1.8e1) can't find the robot. Shouldn't it # > appear as a GK<something> device?  > 9 > Is there some magic incantation to get it to work or am  > I just out of luck?  > : > ps VMS sees the drive ok, it just doesn't see the robot.  A Firstly, VMS doesn't support LTO-1. But I don't know which of the " drives offered with 120T you have.  ? As to controlling the robot -- try mtx, if you haven't already:  http://mtx.sourceforge.org http://mtx.badtux.net/   ------------------------------  % Date: Tue, 22 Aug 2006 17:32:51 -0400 , From: <Barry.Treahy@EmersonNetworkPower.com>4 Subject: RE: Dell Powervault 120T autoloader on VMS?M Message-ID: <63A4454BFCE1C048B2683DBB63A3633363C60E@ETP-CIN-US-EX01.etp1.com>    -----Original Message-----& From: cmk [mailto:ckaron@gmail.com]=20' Sent: Tuesday, August 22, 2006 11:47 AM  To: Info-VAX@Mvb.Saic.Com 4 Subject: Re: Dell Powervault 120T autoloader on VMS?     Malcolm Dunnett wrote:= > Has anyone managed to get a Dell Powervault 120T autoloader % > working with VMS on an Alphaserver?  > 8 > I can see the drive (mkb500) and the robot (jkb100) at@ > the Alpha console level, but VMS 8.2 doesn't appear to see the; > robot and MRU (v1.8e1) can't find the robot. Shouldn't it # > appear as a GK<something> device?  > 9 > Is there some magic incantation to get it to work or am  > I just out of luck?  > : > ps VMS sees the drive ok, it just doesn't see the robot.  A Firstly, VMS doesn't support LTO-1. But I don't know which of the " drives offered with 120T you have.$ ------------------------------------  G I asked about this a couple years ago regarding another auto-loader and E was told that for VMS, you need additionally licensed software to add E that functionality to VMS; standard drivers and VMS BACKUP can't deal  with the auto-loaders. =20  H That said, I was also told that if you can configure your auto-loader soG that each LUN off the SCSI id represents each loader slot, then you can H manually manipulate it but if you fill a volume, it may not roll-over toH the next tape.  I didn't feel like experimenting, so I can't tell you if  this in fact will or won't work.   Regards,   Barry Treahy   ------------------------------    Date: 22 Aug 2006 14:47:54 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett) 4 Subject: Re: Dell Powervault 120T autoloader on VMS?, Message-ID: <EgFDQTlzmG1J@malvm9.mala.bc.ca>  C In article <1156272398.453917.161020@75g2000cwc.googlegroups.com>,  %      "cmk" <ckaron@gmail.com> writes:   > >> Has anyone managed to get a Dell Powervault 120T autoloader& >> working with VMS on an Alphaserver? >>C > Firstly, VMS doesn't support LTO-1. But I don't know which of the $ > drives offered with 120T you have. >   .    Not a problem, this is the DLT7000 version.    A > As to controlling the robot -- try mtx, if you haven't already:  > http://mtx.sourceforge.org > http://mtx.badtux.net/  ?   The problem was that VMS wasn't loading the driver for it, so 6 I don't imagine any utility would have been much help.  %   Turns out all I needed to do was a:   <  MCR SYSMAN IO CONNECT GKcnnn:/DRIVER=SYS$GKDRIVER/NOADAPTER  @   after that MRU (HPs Media Robot Utility) handles it just fine.  <   Thanks to Encompasserve and particularly to Paul Sture for# pointing me in the right direction.    ------------------------------    Date: 22 Aug 2006 14:58:49 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett) 4 Subject: RE: Dell Powervault 120T autoloader on VMS?, Message-ID: <jsvWsBlM$DEt@malvm9.mala.bc.ca>  N In article <63A4454BFCE1C048B2683DBB63A3633363C60E@ETP-CIN-US-EX01.etp1.com>, 1    <Barry.Treahy@EmersonNetworkPower.com> writes:  > I > I asked about this a couple years ago regarding another auto-loader and G > was told that for VMS, you need additionally licensed software to add G > that functionality to VMS; standard drivers and VMS BACKUP can't deal  > with the auto-loaders. =20 > G    That's correct. The robot appears as a separate device (GKxxxx:) and 1 you need special software to send commands to it.   K    I'm using MRU (Media Robot Utility) from HP for this. It is a separately B licensed product (the license is included under the CSLG, which we subscribe to).  C    See my previous post, once I correctly loaded the VMS driver for  the robot it worked fine.   F    The other warning I should tack on for anyone following this threadH is that the Powervault 120T is High Voltage Differential SCSI ( at leastC the one I have is ) so you'll need the correct SCSI adapter in your G system to connect it to. Using the wrong type of adapter can damage the  adapter and/or the drive.    ------------------------------    Date: 22 Aug 2006 20:29:19 -0700 From: contracer11@gmail.com % Subject: Re: Enabling SMTP in VAX/VMS B Message-ID: <1156303758.950079.154040@75g2000cwc.googlegroups.com>   Hoff Hoffman wrote:  > sol gongola wrote: > @ > > I highly recommend the read and flay part. And educated user > > is the best kind.  > H >    Make no mistakes :-) here, as we were all ignorant once (and that'sL > "ignorant" as differentiated from "stupid"), and we either book-learned, = or we L > played and tested and yes, we crashed-and-burned, or we attended class(es= ), or  > some combination of these. > L >    And if you are in a situation where you can't afford to make any mista= kes --H > and we can and have all made them -- then get somebody in (consultant,L > contractor, vendor, service bureau, etc) that can either provide the nece= ssary L > configuration, or that has enough insurance to cover any mistakes made, o= r both. L >   Or get yourself a target-practice crash-and-burn environment, and make = your > mistakes there.  Or both.  > L >    Go try it.  Go play.  Go make mistakes.  Seriously.  (But try to avoid=  same,K > and definitely try not to make mistakes on any local "production" nodes.)  >  > 	--  > L >    And no, I don't think that MX is what you want here.  And I'd be serio= uslyL > tempted to leave any old box alone (to quietly allow its software to rust=  in L > peace), and to route any mail via DECnet to a newer node.  (You can route=  IP J > mail via DECnet, for instance, by specifying a path to what amounts to aL > DECnet-IP gateway host.)  Or I'd use a minimal client for mail, and a rem= ote  > POP/IMAP/SMTP server.    Reading this post:    L http://groups.google.com/group/comp.os.vms/browse_thread/thread/de5900a5826=L a4b75/6ee0ae804c24d20f?lnk=3Dgst&q=3Dmail+kevin+lai&rnum=3D4#6ee0ae804c24d2= 0f    C I found an answer to my question and now I can send vms mails to my  exchange server:             VAX001 =BB ucx sh config smtp    SMTP Configuration   Options : Initial interval:   0 00:30:00.00       Address_max:    16 NOEIGHT_BIT : Retry interval:     0 01:00:00.00       Hop_count_max:  16 NORELAY ! Maximum interval:   3 00:00:00.00  HEADERS   G Timeout             Initial       Mail    Receipt       Data  Terminate G   Send:                   5          5          5          3         10    Receive:                5   4 Alternate gateway:  EXCHANGE.U L T R A . C O M . B R General gateway:    not defined    Substitute domain:  not defined 2 Zone:               VAX001.U L T R A . C O M . B R   Postmaster:         UCX_SMTP? Log file:           SYS$SPECIFIC:[UCX_SMTP]UCX$SMTP_LOGFILE.LOG   0 Generic queue       Queues   Participating nodes                     =20 # UCX$SMTP_VAX001_00     1     VAX001    ------------------------------    Date: 22 Aug 2006 21:08:06 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett) 0 Subject: No more Oracle Standard Edition for VMS, Message-ID: <u7v6hp3RVqqH@malvm9.mala.bc.ca>  6 I posted a month or so ago asking if anyone knew about7 the status of Oracle Standard Edition for VMS. Metalink 8 says that Oracle 10gR2 Standard edition is "not planned": for VMS on any platform (VAX, Alpha or Itanium). Of course7 it also says that 9.2 Standard Edition was not released . for those platforms (which is patently false).  ; I've now had it confirmed by my Oracle rep that Oracle does ; not plan to release any further versions of Oracle Standard 9 Edition for VMS. The argument is presumably that it's too 8 much work to test it and there's not enough interest. I : can't speak for any other sites but I know it's a "mission critical" product for us.   8 Perhaps I'm missing something, but my experience is that6 unless you're running huge databases where things like5 partitioning become critical there's not much need to 3 use Enterprise Edition and that not having Standard 7 edition available for VMS eliminates the feasibility of 8 being able to use this rock-solid OS as an Oracle server+ platform unless you have very deep pockets.   9 I've been told that the decision to kill Standard Edition : for VMS is "not final". I would encourage anyone out there8 who uses, or has any interest in using, Standard Edition9 on VMS to contact your Oracle rep and let them know you'd 5 like the product to continue. If you know anyone else 8 who uses this product please let them know too. Surely I0 can't be the only customer on the planet, can I?   ------------------------------  % Date: Tue, 22 Aug 2006 22:09:16 -0700 $ From: DA Morgan <damorgan@psoug.org>4 Subject: Re: No more Oracle Standard Edition for VMS6 Message-ID: <1156309756.359226@bubbleator.drizzle.com>   Malcolm Dunnett wrote:  = > I've now had it confirmed by my Oracle rep that Oracle does = > not plan to release any further versions of Oracle Standard ; > Edition for VMS. The argument is presumably that it's too : > much work to test it and there's not enough interest. I < > can't speak for any other sites but I know it's a "mission > critical" product for us.   ? I would argue that Standard Edition is not mission critical for = you as you can always substitute Enterprise Edition. What may = matter is the cost of the license. And here is where you need ? to invite back that lovely sales rep and ask them how hard they > can work, between now and license renewal time, to get that EE, license to match the cost of the SE license. --   Daniel A. Morgan University of Washington damorgan@x.washington.edu  (replace x with u to respond)  Puget Sound Oracle Users Group
 www.psoug.org    ------------------------------  % Date: Wed, 23 Aug 2006 07:24:23 +0200 0 From: Sybrand Bakker <postbus@sybrandb.demon.nl>4 Subject: Re: No more Oracle Standard Edition for VMS8 Message-ID: <0gpne29hq3k0rjdguab55pb843jeq1dlmq@4ax.com>  A On 22 Aug 2006 21:08:06 -0700, nothome@spammers.are.scum (Malcolm  Dunnett) wrote:   : >I've been told that the decision to kill Standard Edition; >for VMS is "not final". I would encourage anyone out there 9 >who uses, or has any interest in using, Standard Edition : >on VMS to contact your Oracle rep and let them know you'd6 >like the product to continue. If you know anyone else9 >who uses this product please let them know too. Surely I 1 >can't be the only customer on the planet, can I?   ? I wouldn't be surprised is OpenVMS is going to be a desupported = platform soon. If you realize how many options are simply not < available for OpenVMS, and how kludgy Oracle implemented andD documented OFA, you realize you would better change O/S, if you want to continue Oracle. @ The number of customers on the planet might number less than 10.   --! Sybrand Bakker, Senior Oracle DBA    ------------------------------  % Date: Tue, 22 Aug 2006 14:19:50 -0400 ( From: Bill Todd <billtodd@metrocast.net>' Subject: Re: On-chip, 7-way associative G Message-ID: <ttKdnbWN5ppb13bZnZ2dnUVZ_oadnZ2d@metrocastcablevision.com>    Robert Deininger wrote: I > In article <EfadnZeFg-2t1nfZnZ2dnUVZ_s6dnZ2d@metrocastcablevision.com>, + > Bill Todd <billtodd@metrocast.net> wrote:    ...   L >> As usual, 'it depends'.  In fact, EV7 has slightly (but *only* slightly) H >> worse performance than EV68 with 16 MB of fast board-level L2 at the  >> same clock rate in SPECint:  B Actually, the two may have been just about equal in SPECint after C normalizing clock rates (EV68 had a significantly better score but   clocked 100 MHz faster).  +    having only about 1/9th as much cache is J >> significantly offset by the approximate halving in cache latency (to a H >> latency of about 10 ns. for EV7, while the off-chip EV68 L2 was IIRC K >> close to 20 ns. and also direct-mapped - single-way-associative - which  E >> further decreased its relative effectiveness) and the approximate  L >> halving of main-memory latency (from about 160 ns. with EV68 to about 80  >> ns. with EV7 IIRC). >  > ES45 CPUs come in 2 flavors:H > 1    GHz CPUs with  8 MB of L2 cache/CPU  (32 MB maximum system cache)H > 1.25 GHz CPUs with 16 MB of L2 cache/CPU  (64 MB maximum system cache)  H The quad-socket 1.25 GHz ES45 TPC-C submission appeared to contain only  16 MB total...  I > The ES45 L2 cache is on the CPU board, but not on the CPU chip.  Any of = > the CPUs can access the whole system's cache at full speed.   H ... but the ES45 SPECint submission indeed states that 16 MB per CPU is H supported (one might infer from the paperwork that only 16 MB was used, H but the HP citation that Hoff provided above states that it had 32 MB -  neither fish nor fowl).    Strange.   > H > I don't think the ES45 memory latency is as bad as you remember, but I* > don't have the numbers at my fingertips.  D The 160 ns. figure I recall from somewhere or other; the Los Alamos > citation that Hoff provided pegs it at 170 ns. (close enough).  "    ES47 memory latency is slightly< > better than ES45; I don't remember it being twice as fast.  I Hoff's HP citation lists 75 ns. as the local-RAM latency for the GS1280;  D his Los Alamos citation lists 83 ns. (for a GHz GS1280 in late 2002 & running at 1.2 GHz - how interesting).   > K > We've certainly seen workloads where ES45 beats ES47, and vice versa.  It H > turns out a lot of real-world work fits in the ES45 cache, but not the
 > ES47 cache.   ? The Wiki post that Dan Foster cited shows a marked drop-off in  H increasing cache effectiveness for SPECint at sizes exceeding 1 MB, and G the same is true for analyzes of TPC-C-style workloads that I've seen.  F So while I don't doubt that *some* real-world applications may be far H better-suited to 16 MB (or better yet 64 MB) of slower, non-associative = off-chip cache, I doubt that this is anything like *typical*.    ...   J > Yes, EV7 is optimized for large systems, and turned out beautifully.  It) > isn't cost-effective for small systems.   I I question that, especially given AMD's experience in small systems with  I a not-all-that-dissimilar system architecture (on-chip memory controller  # and router, 1 MB on-chip L2 cache).    > E > ES45 uses a chipset optimized for small systems and lower cost.  It H > doesn't scale past 4 CPUs.  In this size system, large caches are very2 > effective in terms of both cost and performance.  I But so are smaller, faster on-chip caches with much higher associativity  + - plus radically lower main-memory latency.   C And fast off-chip SRAM and separate memory-controllers aren't that  F cheap, either.  I question (again) whether overall small-system board I costs would have been any lower using EV68 than EV7:  in fact, I suspect  I the opposite - if the components were priced reflecting HP's cost rather  6 than reflecting what HP thought it could get for them.   > J > GS320-class systems don't use the ES45 chipset, and they have much worse* > memory performance at every system size. > F > GS320-class systems don't use EV68 CPUs, BTW.  They use EV6 or EV67.  
 Mea culpa.   > L >> So for single-processor workloads which are 'cache-friendly' EV7 is only L >> about on a par with EV68 plus 16 MB of off-chip L2 (though even there by K >> virtue of eliminating a bunch of other board components EV7 is likely a  . >> considerably more cost-effective design).   > L > Yes, ES45 has a few memory and cache ASICs that add up to perhaps a coupleK > of hundred dollars of cost per system.  But EV68 CPUs are around half the  > cost of EV7.  G Now, why do you suppose that is?  The additional chip area consumed by  H the additional EV7 features does roughly double the chip size IIRC, but G after packaging and testing are taken into account that hardly doubles  ! the overall part cost to produce.   H And, of course, *board* complexity (in terms of additional parts count)  costs something as well.  >    And the cables and connectors that link together EV7 system5 > boxes are FAR more expensive than the ES45 chipset.   H Except that when we're talking about a small-system configuration (as I 2 believe we are here) we don't *need* any of those.      Alpha system volumes H > were never big enough to get significant economies of scale from stuff< > like ASICs, where the development and test costs are huge.  H All the more reason why eliminating them likely saves considerably more I than the cost of the increased chip area required to incorporate them on  	 the chip.   B Even for companies with volumes as large as AMD's are, by the way.   - bill   ------------------------------  # Date: Wed, 23 Aug 2006 04:29:19 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) ' Subject: Re: On-chip, 7-way associative Z Message-ID: <rdeininger-2308060029260001@dialup-4.233.128.75.dial1.manchester1.level3.net>  G In article <ttKdnbWN5ppb13bZnZ2dnUVZ_oadnZ2d@metrocastcablevision.com>, ) Bill Todd <billtodd@metrocast.net> wrote:    >Robert Deininger wrote:J >> In article <EfadnZeFg-2t1nfZnZ2dnUVZ_s6dnZ2d@metrocastcablevision.com>,, >> Bill Todd <billtodd@metrocast.net> wrote: >  >... > M >>> As usual, 'it depends'.  In fact, EV7 has slightly (but *only* slightly)  I >>> worse performance than EV68 with 16 MB of fast board-level L2 at the   >>> same clock rate in SPECint:  > C >Actually, the two may have been just about equal in SPECint after  D >normalizing clock rates (EV68 had a significantly better score but  >clocked 100 MHz faster).  > , >   having only about 1/9th as much cache isK >>> significantly offset by the approximate halving in cache latency (to a  I >>> latency of about 10 ns. for EV7, while the off-chip EV68 L2 was IIRC  L >>> close to 20 ns. and also direct-mapped - single-way-associative - which F >>> further decreased its relative effectiveness) and the approximate M >>> halving of main-memory latency (from about 160 ns. with EV68 to about 80   >>> ns. with EV7 IIRC).  >>   >> ES45 CPUs come in 2 flavors: I >> 1    GHz CPUs with  8 MB of L2 cache/CPU  (32 MB maximum system cache) I >> 1.25 GHz CPUs with 16 MB of L2 cache/CPU  (64 MB maximum system cache)  > I >The quad-socket 1.25 GHz ES45 TPC-C submission appeared to contain only   >16 MB total...  > J >> The ES45 L2 cache is on the CPU board, but not on the CPU chip.  Any of> >> the CPUs can access the whole system's cache at full speed. > I >... but the ES45 SPECint submission indeed states that 16 MB per CPU is  I >supported (one might infer from the paperwork that only 16 MB was used,  I >but the HP citation that Hoff provided above states that it had 32 MB -   >neither fish nor fowl). > 	 >Strange.    Agreed.   ? Benchmarks are bad enough, but benchmarks with poorly-specified % configuration details are even worse.   6 Something must be in error with some of these reports.    I >> I don't think the ES45 memory latency is as bad as you remember, but I + >> don't have the numbers at my fingertips.  > E >The 160 ns. figure I recall from somewhere or other; the Los Alamos  ? >citation that Hoff provided pegs it at 170 ns. (close enough).   I It's fairly dependent on how you load the RAM.  I'd have expected the Los   Alamos system to get this right.  E I thought it was in the 120-130 range, but that's purely from memory.   # >   ES47 memory latency is slightly = >> better than ES45; I don't remember it being twice as fast.  > J >Hoff's HP citation lists 75 ns. as the local-RAM latency for the GS1280; E >his Los Alamos citation lists 83 ns. (for a GHz GS1280 in late 2002  ' >running at 1.2 GHz - how interesting).   2 Well, I'll chalk this one up to bad memory - mine.  L >> We've certainly seen workloads where ES45 beats ES47, and vice versa.  ItI >> turns out a lot of real-world work fits in the ES45 cache, but not the  >> ES47 cache. > @ >The Wiki post that Dan Foster cited shows a marked drop-off in I >increasing cache effectiveness for SPECint at sizes exceeding 1 MB, and  H >the same is true for analyzes of TPC-C-style workloads that I've seen. G >So while I don't doubt that *some* real-world applications may be far  I >better-suited to 16 MB (or better yet 64 MB) of slower, non-associative  > >off-chip cache, I doubt that this is anything like *typical*.  E One obvious case that can enjoy lots of cache is a random mishmash of  unrelated workloads.      K >> Yes, EV7 is optimized for large systems, and turned out beautifully.  It * >> isn't cost-effective for small systems. > J >I question that, especially given AMD's experience in small systems with J >a not-all-that-dissimilar system architecture (on-chip memory controller $ >and router, 1 MB on-chip L2 cache).  J The architectures may be pretty similar on paper, but the costs are in theH implementation.  I don't know AMD's costs.  I have a pretty good idea of
 EV7 costs.  F >> ES45 uses a chipset optimized for small systems and lower cost.  ItI >> doesn't scale past 4 CPUs.  In this size system, large caches are very 3 >> effective in terms of both cost and performance.  > J >But so are smaller, faster on-chip caches with much higher associativity , >- plus radically lower main-memory latency.  H I don't know how much the high EV7 associativity contributed to the cost; or development time of the CPU.  I doubt it was negligible.     D >And fast off-chip SRAM and separate memory-controllers aren't that G >cheap, either.  I question (again) whether overall small-system board  J >costs would have been any lower using EV68 than EV7:  in fact, I suspect J >the opposite - if the components were priced reflecting HP's cost rather 7 >than reflecting what HP thought it could get for them.   M I'm not at liberty to share what I know about the costs in public, obviously.   F Don't confuse prices, which HP can control, with costs, which HP can'tA control.  HP (and others) can and has fiddled with prices to push H customers toward the fad of the quarter.  Costs are much less flexible. E Costs of single-source CPU chips, with a custom-designed process, are  hardly flexible at all.      >>  K >> GS320-class systems don't use the ES45 chipset, and they have much worse + >> memory performance at every system size.  >>  G >> GS320-class systems don't use EV68 CPUs, BTW.  They use EV6 or EV67.  >  >Mea culpa.  >  >>  M >>> So for single-processor workloads which are 'cache-friendly' EV7 is only  M >>> about on a par with EV68 plus 16 MB of off-chip L2 (though even there by  L >>> virtue of eliminating a bunch of other board components EV7 is likely a / >>> considerably more cost-effective design).    >>  M >> Yes, ES45 has a few memory and cache ASICs that add up to perhaps a couple L >> of hundred dollars of cost per system.  But EV68 CPUs are around half the >> cost of EV7.  > H >Now, why do you suppose that is?  The additional chip area consumed by I >the additional EV7 features does roughly double the chip size IIRC, but  H >after packaging and testing are taken into account that hardly doubles " >the overall part cost to produce.  J The EV7 uses a completely different fabrication process than EV68.  I knowF it was difficult and time-consuming to get it working and get adequateJ yields for EV7.  The packaging for EV7 is more expensive as well.  I don'tE know the CPU vendor's costs and profits, but I know HP's cost for EV7 , fairly well.  They are not inexpensive CPUs.   > I >And, of course, *board* complexity (in terms of additional parts count)   >costs something as well.   J Both system boards are very complex; there are lots of components, lots ofJ layers, and both run close to their respective limits of signal integrity.  ? >   And the cables and connectors that link together EV7 system 6 >> boxes are FAR more expensive than the ES45 chipset. > I >Except that when we're talking about a small-system configuration (as I  3 >believe we are here) we don't *need* any of those.   H Sort of.  At 4 CPUs and above, the interconnects are a significant issue: for EV7 systems.  At the 2 CPU level, you mostly avoid it.    @ We may be looking at these question from two radically differentI directions.  I'm not particularly interested in the best, cheapest system F that could have been produced in a given architecture.  These armchairH design exercises can be fun, partly because they can ignore inconvenient# facts to optimize the hypothetical.   J I've been much more concerned with making successful PRODUCTS, in the realF world of Compaq/HP's business needs and target market.  In that world,J there are real constraints on available engineering and management talent,J costs of parts, and market timing.  Lots of things that "should" have been@ done, weren't done because they weren't practical and/or timely.     Consider a few cases...   B For a 1 CPU EV7 system, you have to implement single-CPU power andI packaging to replace the 2-CPU duo used on all existing EV7 systems.  I'm I sure that could be done, but there's little to re-use from existing Alpha I system design.  You'd end up with a system board, a CPU, some memory, and G an I/O subsystem.  There's a good chance you have to make a new chassis I and a new power distribution subsystem.  That would take a while. The CPU H would cost what EV7s cost.  The RAMBUS memory that never quite caught onI would be expensive.  The SRM firmware is unlike anything done before, and I costs quite a lot to develop and debug.  The advantage would be capturing I a good fraction of the potential performance benefits that you and others  have noted.   H Put that up against the DS15, which re-used the DS10 chassis, the XP1000H power supply, and much of the DS25/ES45 electrical design and firmware. E The CPU is much cheaper than EV7 (you'll have to trust me), but a few C additional ASICs (highly leveraged from earlier systems) are needed J compared to the EV7 solution.  And we have to pay for the L2 cache, but atH least that's fairly standard technology that's on a downward price curveG over the life of the product.  The DS15 came to market in about 1 year, I driven by an obvious gap in the product line and a clear need to minimize I the sales price of the system.  Every feature that added significant risk J to the schedule, or added significant cost, was excluded.  Performance wasE MUCH less important than cost according to the marketing gurus.  This J system was mainly for the VMS market; it was after the HP merger and Tru64F was already on the decline.  The VMS market didn't want a 1-CPU system? that pushed for performance; it wanted a low-cost system, SOON.   J Maybe in a different marketing situation, performance would have been moreF important, and the extra cost of the EV7-based 1-CPU system would haveG been justified.  I did have the impression that a later generation (EV8 G timeframe?) of small systems was planned.  1 CPU systems might not have B made it, but a dedicated 2-CPU design would have been very likely.  F I don't know if I can give enough detail to convince you, but DS15 wasF much less expensive to design and build than an EV7-based 1-CPU systemC would have been at the time.  Change the target market environment, J increase the expected system volume by a factor of 5 or 10, allow an extraF year to come to market, or otherwise alter reality in a major way, and; there's a chance the choice would have swung the other way.      How about the 2 CPU space?  H Here we can compare two real systems, the DS25 and the ES47 Tower.  BothH are still for sale, which tells me they both have willing customers, andG HP is making money on both of them.  ES25 was an "easy" scaling-down of G the existing ES45, with extensive re-use from DS20E.  For customers who G need more memory or IO than the DS15 can provide, the DS25 can be built J with only 1 CPU at lower cost than the 2-CPU standard.  Time-to-market wasE hampered by a couple of engineering problems that were unexpected and I unavoidable, so the system was late.  It SHOULD have shipped earlier than  it did.   @ ES47T re-uses the ES80 building block in the smallest reasonable> configuration.  The box incurs some large-system cost overheadI (scalability and interconnect stuff that isn't used), but this was deemed I a better solution than re-engineering a dedicated subsystem for the 2-CPU G space.  There's no way to configure this system with just 1 CPU to save 1 money; that's another schedule vs. cost tradeoff.   I ES47T enjoyed some early discounts intended to soup up EV7 volume, so the I end-user cost was attractive.  I haven't priced out a system in a year or G more, so I don't know if the discounts are still there.  (I'm on a slow G connection so I won't brave HP's web site to try it now.)  But again, I 7 know DS25 is less expensive for HP to build than ES47T.        >   Alpha system volumesI >> were never big enough to get significant economies of scale from stuff = >> like ASICs, where the development and test costs are huge.  > I >All the more reason why eliminating them likely saves considerably more  J >than the cost of the increased chip area required to incorporate them on 
 >the chip.  J The biggest problem is that the EV7 solution, as it came into being in theH real world, is painfully expensive.  It dwarfs things like ASICs.  But IG agree with you, if EV7 had been cheap enough, and if system volumes had J been high enough to warrant the redesign, and if there had been time to doF the work, an EV7 solution in the 1-2 CPU space might have been cheaper# than the ones HP actually designed.     I It occurs to me that there's a path not taken (and not even considered by I the powers that has-been, AFAIK).  Implement the EV7 design in a cheaper, G less aggressive process -- the EV68 process or something even blander.  G Target a much lower CPU cost and give up the cutting-edge performance.  G Take advantage of the large-system scaling by throwing more CPUs at the E workload across the whole product line from 2 CPUs and up.  This idea E seems plausible in hindsight, knowing how painful the EV7 fabrication I process turned out to be, and how good the system architecture is.  Would H it have succeeded?  I don't know.  I'm pretty sure it's too late to find out now.   ------------------------------  % Date: Wed, 23 Aug 2006 01:12:51 -0400 ( From: Bill Todd <billtodd@metrocast.net>' Subject: Re: On-chip, 7-way associative G Message-ID: <VYadnSfvDpVOfnbZnZ2dnUVZ_rudnZ2d@metrocastcablevision.com>    Robert Deininger wrote:    ...   M >>> We've certainly seen workloads where ES45 beats ES47, and vice versa.  It J >>> turns out a lot of real-world work fits in the ES45 cache, but not the >>> ES47 cache. B >> The Wiki post that Dan Foster cited shows a marked drop-off in K >> increasing cache effectiveness for SPECint at sizes exceeding 1 MB, and  J >> the same is true for analyzes of TPC-C-style workloads that I've seen. I >> So while I don't doubt that *some* real-world applications may be far  K >> better-suited to 16 MB (or better yet 64 MB) of slower, non-associative  @ >> off-chip cache, I doubt that this is anything like *typical*. > G > One obvious case that can enjoy lots of cache is a random mishmash of  > unrelated workloads.  E More cache *of the same quality* is always better.  But the question  G here is whether more cache of far less associativity and significantly  D greater latency is better - even for the kind of workload which you F specify above, and especially when the smaller-cache product has half  the RAM latency.  G Sometimes, it may be, but on average I suspect not much if at all.  In  G fact, for the 'random mishmash of unrelated workloads' I think I'd opt  I for the far faster RAM and faster, smarter (though smaller) cache almost   every time.    ...   J > I don't know how much the high EV7 associativity contributed to the cost= > or development time of the CPU.  I doubt it was negligible.   I Ah, but that doesn't matter at all:  that cost was already incurred (and  ) necessary) to support larger EV7 systems.   < The costs one must compare (except for the single-processor G configuration which you rightly note below would have required special  G components to support EV7) to determine whether EV7 ES and dual-socket  I DS series systems would have been more cost effective are the *marginal*  G production costs.  True, the EV68 development costs were already sunk,  G but so were the EV7 costs (for the larger configurations that it *had*  J to support), so only the actual production (not development) costs matter.   >  > F >> And fast off-chip SRAM and separate memory-controllers aren't that I >> cheap, either.  I question (again) whether overall small-system board  L >> costs would have been any lower using EV68 than EV7:  in fact, I suspect L >> the opposite - if the components were priced reflecting HP's cost rather 9 >> than reflecting what HP thought it could get for them.  > O > I'm not at liberty to share what I know about the costs in public, obviously.  > H > Don't confuse prices, which HP can control, with costs, which HP can'tC > control.  HP (and others) can and has fiddled with prices to push J > customers toward the fad of the quarter.  Costs are much less flexible. G > Costs of single-source CPU chips, with a custom-designed process, are  > hardly flexible at all.   D If you're talking actual marginal production costs here rather than D including development costs which Alpha had to incur anyway for its * large-system support, I'll agree with you.   ...   N >>>> So for single-processor workloads which are 'cache-friendly' EV7 is only N >>>> about on a par with EV68 plus 16 MB of off-chip L2 (though even there by M >>>> virtue of eliminating a bunch of other board components EV7 is likely a  0 >>>> considerably more cost-effective design).  N >>> Yes, ES45 has a few memory and cache ASICs that add up to perhaps a coupleM >>> of hundred dollars of cost per system.  But EV68 CPUs are around half the  >>> cost of EV7.J >> Now, why do you suppose that is?  The additional chip area consumed by K >> the additional EV7 features does roughly double the chip size IIRC, but  J >> after packaging and testing are taken into account that hardly doubles $ >> the overall part cost to produce. > L > The EV7 uses a completely different fabrication process than EV68.  I knowH > it was difficult and time-consuming to get it working and get adequate > yields for EV7.   G Again, all that had to happen anyway.  The question is whether *after*  D all was said and done the marginal cost of an EV7 chip exceeded the G marginal cost of the chips required to perform the same functions with  ' EV68 (plus any board-cost differences).   <    The packaging for EV7 is more expensive as well.  I don'tG > know the CPU vendor's costs and profits, but I know HP's cost for EV7 . > fairly well.  They are not inexpensive CPUs.  > Again, if you're talking purely marginal costs, I can't argue.   ...   @ >>   And the cables and connectors that link together EV7 system7 >>> boxes are FAR more expensive than the ES45 chipset. K >> Except that when we're talking about a small-system configuration (as I  5 >> believe we are here) we don't *need* any of those.  > J > Sort of.  At 4 CPUs and above, the interconnects are a significant issue< > for EV7 systems.  At the 2 CPU level, you mostly avoid it.  B My lack of detailed acquaintance with EV7 systems is showing, I'm E afraid:  I do now seem to remember that they're composed of multiple  H dual-processor boards, so if you were really referring to board (rather G than box) connections above then even the quad-processor configuration  4 may be affected (but significantly, I have to ask?).   ...   D > For a 1 CPU EV7 system, you have to implement single-CPU power andF > packaging to replace the 2-CPU duo used on all existing EV7 systems.  G As I noted above, that's a significant point I had overlooked - and an  = excellent argument for having carried over EV68 at least for   single-socket systems.   ...   /    The RAMBUS memory that never quite caught on  > would be expensive.   H Indeed, which might in itself have been sufficient reason to carry over B dual-socket EV68 systems as well (given that the single-socket DS  systems were already needed).   D Which leaves only the question of whether carrying over the ES EV68 G series made sense, I guess - and if stocking both it and the EV7-based  G ES boxes wasn't an unreasonable expense, why not?  But I still suspect  I that the marginal cost to HP of an ES80 may at worst be no more than the  E marginal cost of an ES45 (if I got the numbers right - I'm trying to  G compare the two quad-socket systems), unless the RAMBUS components are  E sufficient to tip the balance or the EV7 process has significant and  ' continuing marginal cost disadvantages.    - bill   ------------------------------  # Date: Tue, 22 Aug 2006 18:54:35 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>J Subject: Re: openvms - java - timezone - daylight savings - what the heck!. Message-ID: <LpIGg.80$_E1.49@news.cpqcorp.net>   troy@makaro.com wrote:D > Please help, I have been searching on the internet all day for the: > answer to why java times are off by one hour on openvms. ...   > So what the heck am I missing?  '    OpenVMS [Alpha] V8.2, I will assume.   Q    I've seen this crop up when somebody uses SET TIME to change the system time,  K rather than letting the automatic processes work, or using the TDF command  6 procedure (UTC$TIMEZONE_SETUP.COM) to change the time.  N    Do C applications also display the wrong time?  (That's a common footprint S for a mis-set TDF.  I *think* Java is involving basically the same behaviour here.)   M    I'd also load the TDF ECO and (while I was at it) the TZ ECO, and (if you  . don't already have it) the current UPDATE kit.  P    And if all else fails, ring up the folks at the support center, and they can . have a look at this system and this footprint.   ------------------------------  % Date: Tue, 22 Aug 2006 22:09:34 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> J Subject: Re: openvms - java - timezone - daylight savings - what the heck!< Message-ID: <44ebb794$0$24188$9a6e19ea@news.newshosting.com>  # <troy@makaro.com> wrote in message  ; news:1156217947.227394.37460@74g2000cwt.googlegroups.com... D > Please help, I have been searching on the internet all day for the: > answer to why java times are off by one hour on openvms. >  [...snip...] > " > OpenVMS version is: OpenVMS V8.2 >   > So what the heck am I missing? > J OK so I copied your demo to my production system and here are the results # using JAVA-1.4.2 with OpenVMS-7.3-2   	     #####   . KAWC09::Neil> @sys$manager:utc$time_setup show  5 AUTO_DLIGHT_SAV is set to "0" and DTSS is not in use. > You will have to manually change to/from Daylight Saving Time.  < You can do this by executing SYS$MANAGER:UTC$TIME_SETUP.COM,0 or you can use SYS$EXAMPLES:DAYLIGHT_SAVING.COM.  < LOCAL TIME ZONE          = EASTERN / CANADA -- DAYLIGHT TIME8 LOCAL SYSTEM TIME        = 22-AUG-2006 21:33:50.24 (EDT)  TIME DIFFERENTIAL FACTOR = -4:008 TIME ZONE RULE           = EST5EDT4,M4.1.0/02,M10.5.0/02D Change EST to EDT on the First Sunday of April (2-Apr-2006) at 02:00F Change EDT to EST on the Last Sunday of October (29-Oct-2006) at 02:00   KAWC09::Neil> java "Neil"  Tue Aug 22 21:35:27 EDT 2006 KAWC09::Neil> ty neil.java import java.util.Date;     public class Neil { 1         public static void main (String[] args) { +             System.out.println(new Date()); 	         }  } 
 KAWC09::Neil>   	     #####   L On my system we've got sysgen parameter AUTO_DLIGHT_SAV set to 0 because we L let TCPware (ntpd) do the clock change. So could your problem be related to I OpenVMS-8.2 ? I get the feeling that your JVM doesn't know what timezone  L your system is in so date displays default to a GMT rather than showing one  of your local time zones.   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada." http://www3.sympatico.ca/n.rieck/    ------------------------------    Date: 22 Aug 2006 21:00:42 -0700) From: "troy@makaro.com" <troy@makaro.com> J Subject: Re: openvms - java - timezone - daylight savings - what the heck!@ Message-ID: <1156305642.810758.8300@i3g2000cwc.googlegroups.com>  E This is really weird, I used your configuration and it worked. Except - that instead of saying EDT it said GMT-04:00.   E I then went and switched back to my time zone and I am off by an hour @ again. My date says GMT-08:00 when it should say PDT or at least
 GMT-07:00.  @ About AUTO_DLIGHT_SAV, I had it set to zero before with the same results.   Troy   ------------------------------  % Date: Tue, 22 Aug 2006 20:09:52 +0200 2 From: martin@radiogaga.harz.de (Martin Vorlaender)  Subject: Re: PDF parser on VMS ?; Message-ID: <44eb4870.524144494f47414741@radiogaga.harz.de>   . JF Mezei <jfmezei.spamnot@teksavvy.com> wrote:G > I'd like to stuff a whole bunch of PDF documents in a folder and have F > some utility parse the PDF files to extract the document information" > (title, author, dates etc) [...]  E Look for the htdig_utils.zip (or so I think I named it) package on my G ht://Dig page. It contains xpdf-based utilities and some DCL to do just F that (for ht://Dig use, of course - but then, I have no doubt that you% are able to refit it for your needs).    cu,    Martin --  ;                      | Martin Vorlaender  |  OpenVMS rules! . Microsoft's answer   | work: mv@pdv-systeme.deA to OpenVMS is        |   http://www.pdv-systeme.de/users/martinv/ 5 Windows NT 10.0.     | home: martin@radiogaga.harz.de    ------------------------------  % Date: Tue, 22 Aug 2006 14:35:09 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>   Subject: Re: PDF parser on VMS ?, Message-ID: <44EB4E5C.BF657F9D@teksavvy.com>   Martin Vorlaender wrote:G > Look for the htdig_utils.zip (or so I think I named it) package on my 2 > ht://Dig page. It contains xpdf-based utilities    thanks ! Will look into it.    ------------------------------  % Date: Tue, 22 Aug 2006 14:27:18 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> & Subject: Re: Personal note - goodbye !, Message-ID: <44EB4C85.9D7F1BC1@teksavvy.com>  
 Mr Peleg,   ? Please convinced/brainwash/blackmail/coerce your replacement to  participate in comp.os.vms   ------------------------------    Date: 22 Aug 2006 13:07:02 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) & Subject: Re: Personal note - goodbye !3 Message-ID: <INk7C3vsjvQ$@eisner.encompasserve.org>   d In article <44e9e4d8@usenet01.boi.hp.com>, "Guy Peleg" <guy.peleg@remove_this_header@hp.com> writes: > / > I'm going to work with Bruce Ellis at BRUDEN.   G    Maybe you can talk Bruce into a revisoin of the Hitchiker's Guide to     VMS?    ------------------------------  % Date: Tue, 22 Aug 2006 23:53:59 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> & Subject: Re: Personal note - goodbye !, Message-ID: <44EBD14B.6931FE36@teksavvy.com>   On second thought...    H SUE ! (now that you are back), it is time to take out your whips, chainsE and other paraphernalia and do whatever it takes to get Guido to stay  within the VMS group ....    ------------------------------  % Date: Tue, 22 Aug 2006 11:12:24 -0400 * From: Paul Anderson <paul.anderson@hp.com>- Subject: Re: Printing to a HP LaserJet 2605dn E Message-ID: <paul.anderson-584ADF.11122422082006@usenet01.boi.hp.com>   . In article <44ea40d1@cfanews.cfa.harvard.edu>,9  "Gareth V. Williams" <graff@cfa0.cfa.harvard.edu> wrote:   F > We recently bought an HP LaserJet 2605dn color printer for our home F > network.  I have set it up to print jobs from the PC and the laptop E > with no problems.  But my attempts to get it to print jobs from my  G > Personal Workstation 500au have been unsuccesful.  Jobs appear to be  B > submitted without error to the queue, but nothing comes out and G > examination of the printer queues shows the jobs to be retained with  	 > errors.   D I was going to suggest turning on PostScript error reporting on the H printer, but the error getting the local host name would appear to have 6 prevented anything from getting to the printer anyway.   > HP_LJ2605|hp_lj2605:\ 4 >         :lf=/TCPIP$LPD_ROOT/000000/HP_LJ2605.LOG:\ >         :lp=HP_LJ2605:\  >         :rm=xx.xx.xx.xx:\  >         :rp=raw:\ ( >         :sd=/TCPIP$LPD_ROOT/HP_LJ2605:  I You have an internal printer queue name of "raw".  Try removing this and  C seeing if there is any difference.  Most printers these days don't  @ require, and ignore if one is specified, an internal queue name.    . In article <5IsGg.40$r61.17@news.cpqcorp.net>,.  Hoff Hoffman <hoff-remove-this@hp.com> wrote:  E > I've been using DCPS with the local printers, but that SPD doesn't  H > (yet?) list the LaserJet 2605 -- this box has port 9100, and may well  > work with DCPS.   H The Color LaserJet 2605 will not work with the current version of DCPS, H V2.5.  We have worked with this printer for the next release and had to ? add some code to deal with the lack of some PostScript Level 1   emulations in the printer.  C And I'd agree that printing to port 9100 is almost always a better  G method than using LPD, especially when using something like DCPS which  I listens for errors coming back from the printer and tells you about them.    Paul   --    Paul Anderson   OpenVMS Engineering    Hewlett-Packard Company    ------------------------------    Date: 22 Aug 2006 15:50:06 -04007 From: "Gareth V. Williams" <graff@cfa0.cfa.harvard.edu> - Subject: Re: Printing to a HP LaserJet 2605dn . Message-ID: <44eb5fee@cfanews.cfa.harvard.edu>  - Hoff Hoffman <hoff-remove-this@hp.com> wrote:  : Gareth V. Williams wrote:   N : >    Where is the C program trying to get the local host name from?  Is thisN : > attempting to use decc$gethostname, which works in other C programs I haveM : > running locally?  If so, why is it failing?  If not, what is looking for   : > and from where?   R :    I don't know where TCP/IP Services is picking up the value off-hand (and the P : source code isn't immediately available), but I also haven't found a previous 6 : similar reference to anything similar to this error.  M :    Has this node been used before for IP, or is this a fresh configuration?    ...   K :    In this case, I'd ensure that TCP/IP Services has been configured and  N : started, particularly around the core environment and the printing services.  D   The problem has been solved!  This machine has been running TCP/IPI Services for quite a few years and appeared to continue to function while B I was having the lpd problem.  I could, e.g., continue with my SSH sessions into our work cluster.   G   However, my suspicions were aroused when an attempt to send an e-mail I from home to work produced the same "no local host name" error.  This had A worked as normal when I tried it late last week.  I worked my way C through the Troubleshooting manual and didn't see anything amiss--I G could ping local and remote machines, the arp and routing tables looked > OK, and traceroute found the printer in one hop.  I then triedF rerunning the TCPIP IVP and it failed with a fatal error (which wasn'tB documented in the Troubleshooting manual)!  I *knew* that this had% worked when I did the installation...   D   I'm running a long series of batch jobs at intervals of ~ 2 hours,E searching for factors of Mersenne numbers.  The output of the program @ I use includes the fully-qualified hostname of the machine it isA running on.  In the .LOG file generated at 17:13 on Saturday, the G hostname was correct.  In the next .LOG file, generated at 18:52 and in B all subsequently-generated .LOG files, the hostname was "unknown".  D   I decided that a reboot was in order.  After rebooting, e-mail wasF again working, .LOG files from my Mersenne factor search contained theG proper hostname and I could finally print my first file from VMS.  Yah!   G   I have no idea why the host and domain name were "forgotten" by TCPIP E sometime between 17:13 and 18:52 on Saturday, but I'm very happy that G whatever it was didn't bugger up other bits of TCPIP, such as SSH.  Now G that would have left me up a certain creek without a certain instrument  ;-)   E   Thanks to all those who offered advice/suggestions on this list and 
 privately.        Gareth    --  H ------------------------------------------------------------------------H Gareth V. Williams, MS 18, 60 Garden Street, Cambridge, MA 02138, U.S.A.+ Associate Director, IAU Minor Planet Center H gwilliams@cfa.harvard.edu        http://cfa-www.harvard.edu/iau/mpc.html7 OpenVMS & RISC OS: refined choices in operating systems    ------------------------------    Date: 22 Aug 2006 16:08:16 -0700( From: "Rich Jordan" <jordan@ccs4vms.com>- Subject: Re: Printing to a HP LaserJet 2605dn C Message-ID: <1156288096.409684.255390@h48g2000cwc.googlegroups.com>    Paul Anderson wrote:0 > In article <44ea40d1@cfanews.cfa.harvard.edu>,; >  "Gareth V. Williams" <graff@cfa0.cfa.harvard.edu> wrote:  > G > > We recently bought an HP LaserJet 2605dn color printer for our home G > > network.  I have set it up to print jobs from the PC and the laptop F > > with no problems.  But my attempts to get it to print jobs from myH > > Personal Workstation 500au have been unsuccesful.  Jobs appear to beC > > submitted without error to the queue, but nothing comes out and H > > examination of the printer queues shows the jobs to be retained with > > errors.  > E > I was going to suggest turning on PostScript error reporting on the I > printer, but the error getting the local host name would appear to have 8 > prevented anything from getting to the printer anyway. >  > > HP_LJ2605|hp_lj2605:\ 6 > >         :lf=/TCPIP$LPD_ROOT/000000/HP_LJ2605.LOG:\ > >         :lp=HP_LJ2605:\  > >         :rm=xx.xx.xx.xx:\  > >         :rp=raw:\ * > >         :sd=/TCPIP$LPD_ROOT/HP_LJ2605: > J > You have an internal printer queue name of "raw".  Try removing this andD > seeing if there is any difference.  Most printers these days don'tB > require, and ignore if one is specified, an internal queue name. >  > 0 > In article <5IsGg.40$r61.17@news.cpqcorp.net>,0 >  Hoff Hoffman <hoff-remove-this@hp.com> wrote: > F > > I've been using DCPS with the local printers, but that SPD doesn'tI > > (yet?) list the LaserJet 2605 -- this box has port 9100, and may well  > > work with DCPS.  > I > The Color LaserJet 2605 will not work with the current version of DCPS, I > V2.5.  We have worked with this printer for the next release and had to @ > add some code to deal with the lack of some PostScript Level 1 > emulations in the printer. > D > And I'd agree that printing to port 9100 is almost always a betterH > method than using LPD, especially when using something like DCPS whichK > listens for errors coming back from the printer and tells you about them.  >  > Paul >  > -- >  Paul Anderson >   OpenVMS Engineering  >   Hewlett-Packard Company   F We used to do all our printing to HP and (some) clone printers via LATG via DECservers, including font and logo downloads, and everything "just . worked"; some clones being notable exceptions.  A As the customers wanted network printers we got emulex netque and C netjet devices, used LAT for the VMS systems, and IP for everything  else, and everything worked.  D When they started buying jetdirects, we started having huge problemsF getting the fonts and logos to download to the printer without causingG paper vomit.  Modified the font files, added DCS/ST encapsulation, both D 7 and 8 bit, yadda yadda.  Sometimes we'd get two identical printersF with jetdirects having different firmware revs, and one would not work? no matter what, and the other would only work with 8 bit DCS/ST C encapsulation, while the older one down the hall only worked with 7 E bit.  Tried variations on the TCPIP$TELNETSYM logicals, including raw C mode, etc.  Sometimes it would work other times not; no consistency F from printer to printer, though once you found a magic combination forD a particular printer it tended to keep working (and some would neverD work,usually the lower end 1XXX and 2XXX Laserjets).  Worst stinking pain the pc to deal with ever.  D Out of sheer annoyance we tried an LPD queue, pointing to the 'auto'E remote queue on the jetdirect equipped printers.  Eureka. Fonts load. E Logos load.  Files don't print right.  Ok, so leave the LPD queue for A font loads and the Telnetsym queue for actual printing.  Harmony!    Wish we could go back to LAT...    Rich   ------------------------------  # Date: Wed, 23 Aug 2006 00:27:51 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>- Subject: Re: Printing to a HP LaserJet 2605dn / Message-ID: <biNGg.100$VS1.58@news.cpqcorp.net>    Gareth V. Williams wrote:   I >   I have no idea why the host and domain name were "forgotten" by TCPIP G > sometime between 17:13 and 18:52 on Saturday, but I'm very happy that I > whatever it was didn't bugger up other bits of TCPIP, such as SSH.  Now I > that would have left me up a certain creek without a certain instrument  > ;-)   E    Do check the ECO level for the particular TCP/IP Services version.    ------------------------------    Date: 22 Aug 2006 10:38:48 -0700/ From: "Volker Halle" <volker_halle@hotmail.com> ; Subject: Re: SEPPUCLU bugcheck introducing new cluster node B Message-ID: <1156268328.350361.226780@74g2000cwt.googlegroups.com>   Tom,  : > %SDA-W-NOTSAVED, global pages not saved in the dump file< > %SDA-E-NOREAD, unable to access location FFFFFFFF.81020120  D the system may have been in its very early stages of booting, so notF all data structures have been set up to take a valid dump, which couldE later be analyzed. Or the dumpfile itself may be too small, which may  be the case for a new system.    Volker.    ------------------------------  % Date: Tue, 22 Aug 2006 17:42:44 +0100 ) From: Tom Wade <nospam@picard.eurokom.ie> ; Subject: Re: SEPPUCLU bugcheck introducing new cluster node 0 Message-ID: <44EB3404.9060709@picard.eurokom.ie>  H > if you have the console output of node WORF available, you could check* > for any errors while writing the dump...   No errors reported.  =20 A > To find out more information from the LOCKMGRERR crash, I need:  >=206 > SDA> exa @r5+cdrp$l_val2 ! address of received LKMSG > xxxxxxxx: yyyyyyyy >=20   SDA>  exa @r5+cdrp$l_val2 + %SDA-E-BADSYM, unknown symbol "CDRP$L_VAL2"  SDA>  & Same result if I do a READ/EXEC first.  ; By poking around SYS$SHARE:LIB.MLB I found a definition for   CDRP$L_VAL2 which equates to 88.   SDA> exa @r5+88 8 FFFFFFFF.81BBDC08:  8116A2A0.8116A2B0   "=B0=A2...=A2.."* SDA> format 8116A2A0.8116A2B0/type=3Dlkmsg? %SDA-E-NOSYMBOLS, no "LKMSG" symbols found to format this block  SDA>  D (I tried 58 in case it was expecting hex, but got a similar result).  $ How do I preload the LKMSG symbols ?  9 --------------------------------------------------------- @ Tom Wade                 | EMail: tee dot wade at eurokom dot ie3 EuroKom                  | Tel:   +353 (1) 296-9696 3 A2, Nutgrove Office Park | Fax:   +353 (1) 296-9697 J Rathfarnham              | Disclaimer:  This is not a disclaimer         =   =20 G Dublin 14                | Tip:   "Friends don't let friends do Unix !"  Ireland    ------------------------------   End of INFO-VAX 2006.468 ************************                                                                                                      