1 INFO-VAX	Tue, 09 Jul 2002	Volume 2002 : Issue 374       Contents:P Re: %SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=20202020! Re: Advice on SCSI options sought  Re: Affordable Page Updated ' Alphaserver 1200 Configuration Question  Re: Cost of $CONNECT/DISCONNECT  Re: CSA -> DSPP $ Re: Fearless IPF Prognostications...# Re: Help- No DECWindows on Hobbyist F Re: How to configure a volumn shadowing system disk on OpenVMS v7.2-1?/ Re: Linking shareable with SYMBOL_VECTOR (long)  Re: Lynx & SSL Re: Lynx & SSL Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh...' McKinley tops SpecFP AND SpecInt charts ' McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts   Re: Mysterious non-spinning disk= Re: New web-page dedicated to ports of PD software to OpenVMS = Re: New web-page dedicated to ports of PD software to OpenVMS + Re: Only 20% drop in VMS systems (was: wow) + Re: Only 20% drop in VMS systems (was: wow) + Re: Only 20% drop in VMS systems (was: wow) + Re: Only 20% drop in VMS systems (was: wow) + RE: Only 20% drop in VMS systems (was: wow) + RE: Only 20% drop in VMS systems (was: wow) + Re: Only 20% drop in VMS systems (was: wow) A Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!) A Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!)  Re: Pascal Editor/EDT * Re: PMS$GL_IOPFMPDB - What's grabbing it??  Re: SET FILE/TRUNCATE equivalent  Re: SET FILE/TRUNCATE equivalent  Re: SET FILE/TRUNCATE equivalent Re: SMTP 8bit hack not working Re: Trouble with BACKUP/RECORD Re: UAF questions  Re: VMS 64bitness  Re: VMS 64bitness  Re: Where to put startup stuff Re: Where to put startup stuff Re: Where to put startup stuff  F ----------------------------------------------------------------------   Date: 8 Jul 2002 19:29:55 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)Y Subject: Re: %SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=20202020 * Message-ID: <agcp7j$qav$2@web1.cup.hp.com>  U In article <uhmb2m7ara0e57@corp.supernews.com>, "Vivek Soni" <visoni@bmc.com> writes:   G :It takes two string parameters  The second string parameter is used to  :create a file by its name.  : M :If  i by mistake all "\" as the last letter to the Second String ( filename)  :then I have following Error.  : < :%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual :address=20202020, PC  :=80000010, PSL=03C00004  A   Various OpenVMS Ask The Wizard (ATW) topics such as (7110) are  A   applicable here.  ATW topic (7552) contains an introduction to  ?   application debugging, and topic (1661) has a list of common     coding bugs.  The ATW URL:  )     http://www.openvms.compaq.com/wizard/   L :I have read about a similar problem.  But could not lead to any conclusion.  B   You are about to learn how to debug application code, something F   that you have apparently little or no experience with.  (No offense G   is intended.  Each of us once had little or no experience with this.)   , :If you have any idea what the prolem is ...  '   Your program likely contains a bug.     G   One thing that I did notice from the traceback -- you appear to have  H   a buffer overrun in your code, and specifically a buffer overrun that H   is writing space characters to the stack.  Why am I making this guess?D   That 20202020 value seen in the target address is the hexadecimal B   interpretation of four ASCII space characters, and this tends toC   mean that somebody overwrote some variable with space characters. D   Usually, this means that another buffer variable somewhere on the =   stack is too small, or too much data was transfered into a     properly-sized variable.  B   Oh, and others have pointed you at the debugger.  Please use it.6   You will find the debugger to be an invaluable tool.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Tue, 09 Jul 2002 02:02:05 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> * Subject: Re: Advice on SCSI options sought' Message-ID: <3D2A485A.2127FF00@fsi.net>    Larry Kilgallen wrote: >  > In article <rdeininger-0707022124270001@1cust230.tnt3.nashua.nh.da.uu.net>, rdeininger@mindspring.com (Robert Deininger) writes:M > > In article <msV4+8JEH6$3@eisner.encompasserve.org>, Kilgallen@SpamCop.net  > > (Larry Kilgallen) wrote: > >  > >>In articleC > > <rdeininger-0607020952080001@1cust72.tnt2.nashua.nh.da.uu.net>, 8 > > rdeininger@mindspring.com (Robert Deininger) writes: > >>P > >>> Since you have BA356 shelves already, you could give them wide personalityL > >>> modules and run wide disks.  IIRC, this would also let you connect twoN > >>> shelves to the KZPSA and run 14 drives on one bus -- if you need capcity > >>> more than speed. > < > >>Or are you commenting on the possibility of contention ? > > K > > Yes.  14 busy disks on 1 SCSI bus makes too much bus traffic.  At least " > > that's the folklore I've read. > F > Not all applications with 14 disks on one bus would be using all theF > disks at the same time.  I have fewer disks on my largest bus, but I> > basically never use more than half the disks on any one day.  E I could see a shadow-merge being a problem, if all members of all the E shadow-sets live on the same SCSI bus, but I doubt you'd be likely to E see that in many clustered environments (which is where shadow merges ! are most likely to be triggered).   ; Highly active databases might be another instance, however.    FWIW...    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Tue, 09 Jul 2002 02:16:52 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> $ Subject: Re: Affordable Page Updated' Message-ID: <3D2A4BD1.8AB9AB38@fsi.net>    "David J. Dachtera" wrote: > C > The "Unofficial Affordable OpenVMS Home Page" has been updated to  > reflect VMS's new ownership. > H > I consider this an interim update since I don't currently know what HPJ > will be calling their ISV program (DEC had A.S.A.P., Q had C.S.A.). Once2 > that info. comes my way, I'll update this again. > A > Denizens of HP: please bring this page to the attention of your + > management. The link is in my sig., below   A I've also discovered that the free polls have disappeared. I will C recreate them and post a note to such effect here and in some other  groups as well.   F Sorry for the inconvenience, but at least you'll be able to vote againB on these issues. Maybe this time, someone will listen. (Hey, I can dream!)    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Tue, 09 Jul 2002 00:36:56 GMT  From: dittman@dittman.net 0 Subject: Alphaserver 1200 Configuration Question7 Message-ID: <IeqW8.21910$5f3.5135@nwrddc01.gnilink.net>   = Can an Alphaserver 1200 work with only one CPU and one memory & board, or does it require two of each? --   Eric Dittman dittman@dittman.net = Check out the DEC Enthusiasts Club at http://www.dittman.net/    ------------------------------  % Date: Mon, 08 Jul 2002 22:44:25 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> ( Subject: Re: Cost of $CONNECT/DISCONNECT, Message-ID: <3D2A4E07.E41D5292@videotron.ca>   Jim Johnson wrote:D > On an easier question, RMS doesn't care about the RAB position, so@ > long as that RAB is not currently busy with an in-progress RMS  C > -- which isn't very normal, I'll admit).  All RMS cares about for 9 > identifying a RAB to a stream is the RAB$L_ISI field.      Thanks.    ------------------------------   Date: 8 Jul 2002 14:13:17 -0600 - From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: CSA -> DSPP3 Message-ID: <dPzZ4xOvJoq8@eisner.encompasserve.org>   _ In article <CIEJLCMNHNNDLLOOGNJIEEPMFEAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes: D > CSA is being replaced with Developer and Solution Partners Portal.H > with a merger date of Nov 1.  Under the new peogram there is no longerC > a fee for membership aas there was with CSA.  see www.hp.com/dspp   = They seem no better than CSA, demanding an unsecured browser.    ------------------------------  # Date: Tue, 09 Jul 2002 04:00:57 GMT   From: "Bill" <billmuy@attbi.com>- Subject: Re: Fearless IPF Prognostications... ? Message-ID: <ZdtW8.333174$6m5.336974@rwcrnsc51.ops.asp.att.net>   < "Terry C. Shannon" <terryshannon@attbi.com> wrote in message( news:1uiW8.438734$352.62167@sccrnsc02... > 7 > "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message , > news:agcc06$ajf$1@pegasus.csx.cam.ac.uk... > >  > > F > > This has been a feature of the larger British companies for a longE > > time, and it is clear that some of the USA ones are attempting to % > > emulate the UK computer industry.  > I > I don't believe that marketing expertise is a prerequisite to corporate J > governance, but it would seem to me that at least several members of the BoD J > of a technology company should have a clue about technology. In the case ofI > HPQ, it would be nice to see such technological expertise extend beyond  the  > president and CEO... >   K Just out of curiosity, what kind of technology representation would you and % Nick consider adequate for HPQ's BoD?   K FWIW, a quick Google search on the current board shows at least 6 out of 12 F technologists, with engineering or science degrees (including a formerJ science advisor to the US president, a wireless pioneer with a engineeringJ school named after him, the first GM of HP's computer business, the fatherG of HP's printer business, and a PhD in engineering who runs the biggest J aerospace company on the planet).  And this does not include the president
 or CEO :-)   Bill   ------------------------------   Date: 8 Jul 2002 22:35:49 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman), Subject: Re: Help- No DECWindows on Hobbyist* Message-ID: <agd445$t12$3@web1.cup.hp.com>  W In article <3D289294.3040800@spammotel.com>, Alder <PGDEHMKOKIMD@spammotel.com> writes:   F :I have a problem setting up DEC Windows on my hobbyist Alpha system, C :particularly the proper detection of the graphics device.  At the  C :hardware detection stage of bootup, the graphics card is properly  I :detected as a Cirrus Logic card, but just before the login prompt first  - :appears the following error message appears:  : 2 :DECW$DEVICE-I-NODEVICE, no graphics devices found  G   Please acquire and read the OpenVMS Frequently Asked Questions (FAQ), F   available at the OpenVMS website.  The FAQ contains a section on howE   to troubleshoot the common causes of the NODEVICE error, as well as E   sections on other errors.  Open the text-format FAQ, and search it.   F :I assume this has something to do with the fact I never ran the EISA I :configuration routines.  I'm not sure what they do exactly, but I can't  E :seem to mount and read the directory contents of the Hobbyist CD to  * :search for them.  Here's what I'm trying:  A   The FAQ also contains information on the details that are often B   required when answering a question.  You do (indirectly) include@   the version and platform (OpenVMS Alpha V7.2), but you do not B   reference the particular box and graphics controller involved.  A   Given you refer to EISA graphics, this is hopefully a DEC 2000  @   series box, as that was the only box with EISA graphics.  The D   DEC 2000 series box is highly sensitive to its SCSI configuration E   (don't even think of trying to extend the internal SCSI out of the  C   box), and yes, you do need to (re)configure the EISA if you have     shuffled the bus.   A   But before you reply to this, please go get and please read the B   details in the FAQ -- I'd really rather not have to re-enter theC   FAQ documentation here; the whole point of the FAQ is to elimiate C   repeated postings of the common problems and also to get you the  8   answer to your question in the most expedient fashion.     N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   Date: 8 JUL 2002 17:40:02 GMT 4 From: karcher@thuria.waisman.wisc.edu (Carl Karcher)O Subject: Re: How to configure a volumn shadowing system disk on OpenVMS v7.2-1? 5 Message-ID: <8JUL02.17400225@thuria.waisman.wisc.edu>   A In a previous article, Bart Zorn <B.Zorn@xs4all.nospam.nl> wrote:  ->  7 ->Set the following SYSGEN parameters in MODPARAMS.DAT:  ->   ->SHADOWING = 2  ->SHADOW_SYS_DISK = 1 0 ->SHADOW_SYS_UNIT = n	! DSAn for the system disk ->  % ->Next perform an AUTOGEN and reboot.  ->  K ->Your system disk should now come up as DSAn, a single member shadow set.  5 ->Next you can mount an other disk to the shadow set.   F And don't forget that the ALLOCLASS sysgen parameter must be NON-ZERO.   --G -- Carl Karcher, Waisman Computing Services, Waisman Center, UW-Madison 9 --                      karcher.nospam@waisman.wisc.edu      ------------------------------   Date: 8 Jul 2002 22:07:36 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)8 Subject: Re: Linking shareable with SYMBOL_VECTOR (long)* Message-ID: <agd2f8$t12$1@web1.cup.hp.com>  Z In article <3D207880.28787.4AA871@localhost>, "Stanley F. Quayle" <stan@stanq.com> writes:/ :On 1 Jul 2002, at 11:44, James Gessling wrote: ? :> I had asked some questions regarding shareable image vectors = :> and how to ensure they stay stable when adding or removing @ :> functions.  I got some good advice, and decided to understand :> this once and for all.  :  : G :Thanks.  You've made a valuable contribution.  Perhaps this should go   :into the FAQ, Hoff?    G   I'm initially hesitant to include the posting in the FAQ (for no good H   reason other than its size and level of detail), but it is a nice fit C   for the shareable image cookbook.  I've sent a request via email.     N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   Date: 8 Jul 2002 23:13:33 GMT / From: Thomas Dickey <dickey@saltmine.radix.net>  Subject: Re: Lynx & SSL * Message-ID: <agd6at$hcu$1@news1.Radix.Net>   david20@alpha1.mdx.ac.uk wrote: P > Yes that explains it. I was following the instructions in the INSTALL.VMS file > which just specifies :-   5 > @MAKEVMS <option> <rsaref-p> <debug-p> [<compiler>]   ! > no mention of any p5 parameter.   O > I've just now been to Robert Byer's excellent site where it does document the  > p5 parameter.   5 a url would help (google shows me only defunct links)    --  = Thomas E. Dickey <dickey@radix.net> <dickey@herndon4.his.com>  http://dickey.his.com  ftp://dickey.his.com   ------------------------------   Date: 8 Jul 2002 20:47:56 GMT 3 From: gartmann@immunbio.mpg.de (Christoph Gartmann)  Subject: Re: Lynx & SSL 0 Message-ID: <agctps$s08$1@n.ruf.uni-freiburg.de>  L In article <agcd7d$5no$1@aquila.mdx.ac.uk>, david20@alpha1.mdx.ac.uk writes: > O >Yes that explains it. I was following the instructions in the INSTALL.VMS file  >which just specifies :- > 4 >@MAKEVMS <option> <rsaref-p> <debug-p> [<compiler>] >   >no mention of any p5 parameter. > N >I've just now been to Robert Byer's excellent site where it does document the >p5 parameter. >2 > P >Thanks I'll try and rebuild openssl now and then give rebuilding Lynx with SSL 
 >another try.r  9 No need to recompile Lynx, relinking would be sufficient.b   Regards,    Christoph GartmannC  H -- --------------------------------------------------------------------+H | Max-Planck-Institut fuer      Phone   : +49-761-5108-464   Fax: -452 |H | Immunbiologie                                                        |H | Postfach 1169                 Internet: gartmann@immunbio.mpg.de     |H | D-79011  Freiburg, Germany                                           |H +--------- http://www.immunbio.mpg.de/home/english/menue.html ---------+   ------------------------------   Date: 8 Jul 2002 18:19:33 GMTA( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: McKinley Cometh...l0 Message-ID: <agcl3l$i9s$1@pegasus.csx.cam.ac.uk>  T In article <BE56C50EA024184DAF48F0B9A47F5CF402660809@kaoexc01.americas.cpqcorp.net>,& Main, Kerry <Kerry.Main@hp.com> wrote: >tH >Re: Market acceptance of IPF-2 .. While I agree it is still very early,# >there is some momentum growing.=20c  D I think that it is too early to claim that there is momentum growingB in market acceptance!  Even if products were available and sellingB like hot cakes, the essence of momentum is movement over time, and) momentum growth is the second derivative.s  @ The only relevance of this topic to this group is that the IA-64@ HAS to establish itself within the next year, or Intel will killB it and leave VMS in the lurch.  And today's announcements are very@ short of "hardness", so we shall have to see how things develop.  = >Fwiw, you likely have seen these pointers, but just in case:CI >http://www.computerworld.com/softwaretopics/os/linux/story/0,10801,72566i	 >,00.html 3 >"Intel's Itanium 2 gains support from UnitedLinux"E  C I hadn't, but I knew about it.  It proves little, I am afraid, as Ih= am certain that the cooperation in such an announcement was ahC condition of the developers being lent or given workstations.  Yes,-D they think that it is worth developing for, but we knew that 3 years ago.  G >http://www.eweek.com/article2/0,3959,342906,00.asp (more on Unisys.coms >site)( >"Unisys Jumping on Itanium 2 Bandwagon"G >"Unisys Corp. will release an upgraded version of its 32-way ES7000 ona: >Monday featuring Intel Corp.'s new Itanium 2 processor. "  D That is why I looked at their announcement.  I would summarise it as "Rah, rah, rah!"     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679s   ------------------------------  # Date: Mon, 08 Jul 2002 18:47:29 GMTa# From: "John Smith" <a@nonymous.com>  Subject: Re: McKinley Cometh...5G Message-ID: <57lW8.2157$Raj1.1392@news01.bloor.is.net.cable.rogers.com>1  5 "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message * news:agcl3l$i9s$1@pegasus.csx.cam.ac.uk... > In articleI <BE56C50EA024184DAF48F0B9A47F5CF402660809@kaoexc01.americas.cpqcorp.net>,r( > Main, Kerry <Kerry.Main@hp.com> wrote: > > J > >Re: Market acceptance of IPF-2 .. While I agree it is still very early,% > >there is some momentum growing.=20  > F > I think that it is too early to claim that there is momentum growingD > in market acceptance!  Even if products were available and sellingD > like hot cakes, the essence of momentum is movement over time, and+ > momentum growth is the second derivative.  >fB > The only relevance of this topic to this group is that the IA-64B > HAS to establish itself within the next year, or Intel will killD > it and leave VMS in the lurch.  And today's announcements are veryB > short of "hardness", so we shall have to see how things develop. >t? > >Fwiw, you likely have seen these pointers, but just in case:aK > >http://www.computerworld.com/softwaretopics/os/linux/story/0,10801,72566e > >,00.html 5 > >"Intel's Itanium 2 gains support from UnitedLinux"e >oE > I hadn't, but I knew about it.  It proves little, I am afraid, as Ia? > am certain that the cooperation in such an announcement was atE > condition of the developers being lent or given workstations.  Yes,tF > they think that it is worth developing for, but we knew that 3 years > ago. >sI > >http://www.eweek.com/article2/0,3959,342906,00.asp (more on Unisys.comM > >site)* > >"Unisys Jumping on Itanium 2 Bandwagon"I > >"Unisys Corp. will release an upgraded version of its 32-way ES7000 ond< > >Monday featuring Intel Corp.'s new Itanium 2 processor. " >SF > That is why I looked at their announcement.  I would summarise it as > "Rah, rah, rah!"    $ Why IBM could win the processor wars* http://zdnet.com.com/2100-1107-941961.html   ------------------------------   Date: 8 Jul 2002 12:15:29 -07006( From: bob@instantwhip.com (Bob Ceculski) Subject: Re: McKinley Cometh... = Message-ID: <d7791aa1.0207081115.250eab24@posting.google.com>1  g "Terry C. Shannon" <terryshannon@attbi.com> wrote in message news:<gHgW8.438259$352.61859@sccrnsc02>...i. > And the performance looks surprisingly good! > + > More at www.tru64.org and www.openvms.orgi  < just wait till chivano and EV8-9 goodies start appearing ...   ------------------------------  # Date: Mon, 08 Jul 2002 19:25:20 GMT># From: "John Smith" <a@nonymous.com>u Subject: Re: McKinley Cometh... F Message-ID: <AGlW8.9541$FH6.5512@news01.bloor.is.net.cable.rogers.com>  5 "Bob Ceculski" <bob@instantwhip.com> wrote in messagea7 news:d7791aa1.0207081115.250eab24@posting.google.com...o> > "Terry C. Shannon" <terryshannon@attbi.com> wrote in message* news:<gHgW8.438259$352.61859@sccrnsc02>...0 > > And the performance looks surprisingly good! > >o- > > More at www.tru64.org and www.openvms.orgm >e> > just wait till chivano and EV8-9 goodies start appearing ...    6 Without marketing, VMS will be officially EOL by then.   ------------------------------   Date: 8 Jul 2002 19:44:01 GMT)( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: McKinley Cometh....0 Message-ID: <agcq21$m9m$1@pegasus.csx.cam.ac.uk>  G In article <57lW8.2157$Raj1.1392@news01.bloor.is.net.cable.rogers.com>,w" John Smith <a@nonymous.com> wrote: >-% >Why IBM could win the processor wars + >http://zdnet.com.com/2100-1107-941961.html    Oh, gods, not ANOTHER!  > I have lost track of how many times I have seen articles alongB those lines.  They are all wrong, because they completely miss the@ point that IBM is NOT a single, coordinated company.  The POWER4C division is not even COMPETING in the same wars that Intel, Sun and  AMD are.  D With the POWER4, IBM moved firmly in the direction of its heartland:A the big iron.  Yes, it produces smaller versions, but that is the.A way to look at them.  And remember that IBM was (and that part ofyD IBM is) a mainframe company, whereas DEC was a minicomputer company.8 While hardware has changed, attitudes are slower moving.  @ IBM has a separate PC division, which also handles its clusters,@ and dinky little servers like those that use 8 Pentium III's.  I@ know little of that, but the communication between that division> and the POWER4 lot is erratic and slow, to put it kindly.  IBM? completely dropped out of the bulk market chip development racep? a decade or more back, and its approach in that area is that of- an OEM.-  > And, while IBM still dabbles with PowerPC, as far as I know it2 has lost interest in it.  I can't see it reviving.  @ Sun was a workstation company, and repeatedly failed to get intoD the HPC and mainframe market, though is now succeeding.  Intel have @ only just reached the workstation and smaller server market, andB AMD are struggling to.  But, as there is no margin in workstations+ and below, they all need to move up or die.a  > Intel's IA-64 manoeuvre was an attempt to wipe the competition= out of the high-end workstation and small server market, thuse> preventing companies like AMD and VIA from building up, and to> use the economies of scale to get the big iron vendors (mainly; IBM) to use Intel chips in the same way that IBM uses IntelrB chips in the PC division.  If it succeeds, it will kill everything. but ARM and perhaps MIPS (embedded uses only).  B AMD's Hammer manoeuvre is an attempt to cut Intel off at the fork,C and to block the IA-64 from the bulk high-end workstation and smallL3 server market.  It it succeeds, it will kill IA-64.D  @ While POWERx and IA-64 will have to compete eventually, if IA-64= takes off, that is several years down the line.  Yes, Chivanom> timescale.  Forget it.  There are lots of battles before then.  B The next two years' battles in the chip development areas relevantA to this group will be Intel, AMD and Sun.  And just possibly SGI,.@ though with less than a 1% chance of being relevant.  It is moreA likely that ARM will be relevant than IBM's high-end POWER in theu bulk market!  A If IA-64 were to fail, then it would be crazy to retarget VMS fors? POWERx.  x86-64, possibly, but it depends on how many 'serious'r SMP OEMs take x86-64 up.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679.   ------------------------------   Date: 8 Jul 2002 14:53:06 -0700p( From: bob@instantwhip.com (Bob Ceculski) Subject: Re: McKinley Cometh...t= Message-ID: <d7791aa1.0207081353.2b8ee9fc@posting.google.com>o  r "John Smith" <a@nonymous.com> wrote in message news:<57lW8.2157$Raj1.1392@news01.bloor.is.net.cable.rogers.com>...7 > "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in messagen, > news:agcl3l$i9s$1@pegasus.csx.cam.ac.uk... > > In articleL >  <BE56C50EA024184DAF48F0B9A47F5CF402660809@kaoexc01.americas.cpqcorp.net>,* > > Main, Kerry <Kerry.Main@hp.com> wrote: > > >wL > > >Re: Market acceptance of IPF-2 .. While I agree it is still very early,' > > >there is some momentum growing.=20a > >nH > > I think that it is too early to claim that there is momentum growingF > > in market acceptance!  Even if products were available and sellingF > > like hot cakes, the essence of momentum is movement over time, and- > > momentum growth is the second derivative.a > > D > > The only relevance of this topic to this group is that the IA-64D > > HAS to establish itself within the next year, or Intel will killF > > it and leave VMS in the lurch.  And today's announcements are veryD > > short of "hardness", so we shall have to see how things develop. > >)A > > >Fwiw, you likely have seen these pointers, but just in case:$M > > >http://www.computerworld.com/softwaretopics/os/linux/story/0,10801,72566G
 > > >,00.htmlm7 > > >"Intel's Itanium 2 gains support from UnitedLinux"n > >oG > > I hadn't, but I knew about it.  It proves little, I am afraid, as IrA > > am certain that the cooperation in such an announcement was agG > > condition of the developers being lent or given workstations.  Yes,fH > > they think that it is worth developing for, but we knew that 3 years > > ago. > >EK > > >http://www.eweek.com/article2/0,3959,342906,00.asp (more on Unisys.comp
 > > >site), > > >"Unisys Jumping on Itanium 2 Bandwagon"K > > >"Unisys Corp. will release an upgraded version of its 32-way ES7000 on > > > >Monday featuring Intel Corp.'s new Itanium 2 processor. " > > H > > That is why I looked at their announcement.  I would summarise it as > > "Rah, rah, rah!" >  > & > Why IBM could win the processor wars, > http://zdnet.com.com/2100-1107-941961.html  . once chivaro and EV8-9 goodies hit, forget it!   ------------------------------   Date: 8 Jul 2002 13:30:01 -0600t+ From: young_r@encompasserve.org (Rob Young) 0 Subject: McKinley tops SpecFP AND SpecInt charts3 Message-ID: <XSeIODJ+jnlW@eisner.encompasserve.org>h  ; 	That's right.  Time to eat crow all around.  Perhaps there / 	may not be enough platters, but who cares, eh?l  = 	According to the PPTs and HTMLs found at www.openvms.org oneuF 	can find (in the notes field) the Spec numbers embargoed until today.  = 	Following are base numbers.  So maybe their is a tiny bit of + 	glory left for Power4 in SpecInt2000 peak?         	 		Itanium 2		Power4 at 1.3 GHz   SpecInt2000	810			804e SpecFp		1356			1202h     				Rob    ------------------------------   Date: 8 Jul 2002 13:34:10 -0600e+ From: young_r@encompasserve.org (Rob Young)e0 Subject: McKinley tops SpecFP AND SpecInt charts3 Message-ID: <WpxFjtZvvMVM@eisner.encompasserve.org>Q  G         That's right.  Time to eat crow all around.  Perhaps there     t7         may not be enough platters, but who cares, eh? n   G         According to the PPTs and HTMLs found at www.openvms.org one   -P         can find (in the notes field) the Spec numbers embargoed until today.      G         Following are base numbers.  So maybe there is a tiny bit of   -3         glory left for Power4 in SpecInt2000 peak? M   G                 Itanium 2               Power4 at 1.3 GHz                  0 SpecInt2000     810                     804     0 SpecFp          1356                    1202         #                                 Robk   ------------------------------   Date: 8 Jul 2002 14:49:00 -0700c( From: bob@instantwhip.com (Bob Ceculski)4 Subject: Re: McKinley tops SpecFP AND SpecInt charts= Message-ID: <d7791aa1.0207081348.219e5a6b@posting.google.com>   f young_r@encompasserve.org (Rob Young) wrote in message news:<WpxFjtZvvMVM@eisner.encompasserve.org>...A > That's right.  Time to eat crow all around.  Perhaps there     D9 >         may not be enough platters, but who cares, eh?   >   I >         According to the PPTs and HTMLs found at www.openvms.org one   mR >         can find (in the notes field) the Spec numbers embargoed until today.    >   I >         Following are base numbers.  So maybe there is a tiny bit of    5 >         glory left for Power4 in SpecInt2000 peak? 7 >   I >                 Itanium 2               Power4 at 1.3 GHz              g >   2 > SpecInt2000     810                     804     2 > SpecFp          1356                    1202     >  >   % >                                 Robn  / save the biggest pieces for Andrew and Bill ...s   ------------------------------  # Date: Tue, 09 Jul 2002 00:15:05 GMTt* From: "Bill Todd" <billtodd@metrocast.net>4 Subject: Re: McKinley tops SpecFP AND SpecInt chartsA Message-ID: <dWpW8.35549$Im2.1187845@bin2.nnrp.aus1.giganews.com>   8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:XSeIODJ+jnlW@eisner.encompasserve.org...  > - > That's right.  Time to eat crow all around.e  I Nope.  The only crow I'm about to eat is my guess at McKinley's SPECint2K E performance - *assuming* that the numbers reported by HP are actuallyt accepted by SPEC.-  H BTW, until that happens, your subject line above is incorrect:  the onlyH official such charts don't yet include McKinley numbers, and by the timeF they do both official SPEC chart bars *may* have been raised higher byL someone else such that your assertion will not be correct then either (e.g.,J given that submissions can be made up to 3 months before ship date the newF 1.25 GHz EV68C numbers may yet appear before McKinley's do, as may newF POWER4 numbers depending on the details of that processor's schedule).  I That said, if HP's numbers are even close to correct McKinley has come iniJ considerably better than I expected it to, and there may be some reason toJ believe it's at least in large part due to HP's new chipset surrounding itI (we'll see if and when other configurations release the same benchmarks).hI Over 20% better SPECint2K performance (if you average base and peak) *persH clock* than Alpha (and roughly the same per-clock performance as PA-RISCK 8700 and MIPS R14K, both of which have lower max clock rates than McKinley)-K is nothing to be sneezed at, though much of what isn't attributable to HP'spI chip set can likely be laid at the door of McKinley's exceptionally large-J and fast on-chip caches (no, I still don't have much use for EPIC itself).  I There's still just a bit of doubt in my mind because of some of the other F benchmark figures HP released that just don't seem to make sense.  ForL example, its 4-processor TPC-C performance came in about 55% higher than theJ ES45's despite no better (perhaps considerably lower) system bandwidth (ifD HP's Itanic configuration uses the shared 6.4 GB/sec bus rather thanL something more like the ES45's onboard switch) and only 20% better SPECint2KD numbers.  MS SQL Server has some reputation for being a better TPC-CK performer than Oracle, though, so that could account for the difference (it-J would be interesting to see results for HP-UX running Oracle...), as couldL details of the test configuration (which we won't know until TPC accepts andF posts the results).  It's unfortunate that Alpha is (still) owned by aE company with little apparent interest in competing with Itanic in the J benchmark area, but IBM and AMD may be able to keep them at least somewhat honest.-  J And, BTW, I haven't heard a peep about McKinley's performance running IA32K code - which will become increasingly important as Hammer becomes an issue.$I In a somewhat related vein, Hammer should be both performance-competitive4H and *extremely* price/performance-competitive with Itanic on things like? TPC-C, bringing to mind a possibly-prophetic echo from the pasts9  http://news.com.com/2100-1001-228204.html?legacy=cnet ):   L "At this point, most people understand that Merced itself is not going to beB a very compelling product for Intel," he said. "If you look at theI performance of Merced, it's really not going to be meaningfully differents> from what you get at the high end of the 32-bit architecture."  B Indeed, even given McKinley's "surprisingly good" (Terry's phrase)H performance, it's still not 'meaningfully different' from that availableJ from existing IA32 hardware (let alone Hammer) except in the very high-endE niche areas which IA32 can't (and Hammer *may* not be able to) reach.e  K None of which makes any substantive difference to my primary, original, and I consistent claim that Itanic's performance would never have done in AlphatL (though Alpha, with any reasonable support, would have stood a decent chanceJ of doing in Itanic - especially if it ran IA32 binaries faster under FX!32J as well as its native code).  The fact that McKinley seems to be coming inH above expectations is more than balanced by the increasing evidence thatI Intel had no clue whatsoever where to go after the McKinley core (nor anynI obvious reason to expect that it would have developed much of a clue, let-F alone the ability to bring it to fruition, without the influx of AlphaK talent and intellectual property such as EV7's on-chip routing facilities).R  H Itanic will have to live with whatever performance McKinley offers todayD through both Madison and Montecito, modulo process shrinks that seemI unlikely to more than double its current performance when Montecito comes4B along in 2004 (assuming that heat dissipation problems don't limitF performance to an even lower value) - and likely through 2005 as well,K though it may get better on-chip support in 2005 similar to what POWER4 andsF USIII got last year and EV7 and Hammer will get this year.  Next monthK McKinley will be matched by EV68 at 1.25 GHz, then next quarter eclipsed byAE EV7 in virtually all respects (SPECint, memory latency and bandwidth,MI scalability, ...), and then would have been dealt an even heavier blow byeG EV8's advantages of a process-shrink plus a completely new core and SMT G support (with interesting things in EV9 yet to come).  These few monthsmH right now are as close as Itanic would ever have come to catching Alpha:G when EV8 rolled around, Montecito would have offered *at most* half theoH per-processor performance in server-style activity, despite being a full process generation ahead.4   - bill   ------------------------------   Date: 8 Jul 2002 22:48:39 -0600l+ From: young_r@encompasserve.org (Rob Young)e4 Subject: Re: McKinley tops SpecFP AND SpecInt charts3 Message-ID: <TCEipOaeAcY9@eisner.encompasserve.org>a  n In article <dWpW8.35549$Im2.1187845@bin2.nnrp.aus1.giganews.com>, "Bill Todd" <billtodd@metrocast.net> writes: > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:XSeIODJ+jnlW@eisner.encompasserve.org.... >>. >> That's right.  Time to eat crow all around. > K > Nope.  The only crow I'm about to eat is my guess at McKinley's SPECint2KrG > performance - *assuming* that the numbers reported by HP are actually  > accepted by SPEC.e >    	That would be a hold out hope.:   > K > That said, if HP's numbers are even close to correct McKinley has come innL > considerably better than I expected it to, and there may be some reason toL > believe it's at least in large part due to HP's new chipset surrounding itK > (we'll see if and when other configurations release the same benchmarks).dK > Over 20% better SPECint2K performance (if you average base and peak) *persJ > clock* than Alpha (and roughly the same per-clock performance as PA-RISCM > 8700 and MIPS R14K, both of which have lower max clock rates than McKinley))M > is nothing to be sneezed at, though much of what isn't attributable to HP'soK > chip set can likely be laid at the door of McKinley's exceptionally largesL > and fast on-chip caches (no, I still don't have much use for EPIC itself). >   > 	You don't have much use for EPIC?  Why?  Performs much better@ 	than expected?  Is there a lurking contradiction I am not quite 	highlighting?  K > There's still just a bit of doubt in my mind because of some of the otheroC > benchmark figures HP released that just don't seem to make sense.4   	They make a lot of sense.     ForgN > example, its 4-processor TPC-C performance came in about 55% higher than theH > ES45's despite no better (perhaps considerably lower) system bandwidth  ! 	That isn't the key to high tpmC.e   > D > Indeed, even given McKinley's "surprisingly good" (Terry's phrase)J > performance, it's still not 'meaningfully different' from that availableL > from existing IA32 hardware (let alone Hammer) except in the very high-endG > niche areas which IA32 can't (and Hammer *may* not be able to) reach.- >   I 	Ummm... for meaningfully different, how about a metric everyone loves?  u 	$/tpmC.   > J > Itanic will have to live with whatever performance McKinley offers todayF > through both Madison and Montecito, modulo process shrinks that seemK > unlikely to more than double its current performance when Montecito comestD > along in 2004 (assuming that heat dissipation problems don't limitH > performance to an even lower value) - and likely through 2005 as well,  0 	That's a bold prediction.  Here is another one:  j http://groups.google.com/groups?selm=SONm8.117351%241g.9103926%40bin3.nnrp.aus1.giganews.com&output=gplain  * From: "Bill Todd" <billtodd@metrocast.net> Newsgroups: comp.os.vmsf. Subject: Predictions - just for the hell of it# Date: Fri, 22 Mar 2002 21:59:14 GMTs  I "McKinley's 1 GHz SPECint2K numbers will also be unimpressive, especiallytE given that this is the core users will have to live with (with only aeL process shrink/cache bump) until at least 2005:  700 max, possibly as low as 600, probably around 650."   ---o  C 	Now maybe there are some pretty substantial compiler optimizationsP@ 	left on the table.  Especially with that 6MB L3.  After all, ifI 	guesses are consistent, we can expect at least a 40% SpecInt performance > 	improvement McKinley to Madison, would be a reasonable guess. 	You agree?a  M > though it may get better on-chip support in 2005 similar to what POWER4 andeH > USIII got last year and EV7 and Hammer will get this year.  Next monthM > McKinley will be matched by EV68 at 1.25 GHz, then next quarter eclipsed by G > EV7 in virtually all respects (SPECint, memory latency and bandwidth,gK > scalability, ...), and then would have been dealt an even heavier blow byaI > EV8's advantages of a process-shrink plus a completely new core and SMT I > support (with interesting things in EV9 yet to come).  These few monthsaJ > right now are as close as Itanic would ever have come to catching Alpha:I > when EV8 rolled around, Montecito would have offered *at most* half the J > per-processor performance in server-style activity, despite being a full > process generation ahead.m    B 	Yeah but... at $5 per tpmC for McKinley, no one is going to touch? 	that until Madison and Madison for sure.  Also, don't overlooknC 	$/Specfp that will help a great deal for folks looking at a numberf 	cruncher on a tight budget.   				Robk   ------------------------------  # Date: Tue, 09 Jul 2002 03:04:08 GMT # From: "John Smith" <a@nonymous.com>44 Subject: Re: McKinley tops SpecFP AND SpecInt chartsG Message-ID: <IosW8.15405$FH6.3743@news01.bloor.is.net.cable.rogers.com>i  5 "Bill Todd" <billtodd@metrocast.net> wrote in messageo; news:dWpW8.35549$Im2.1187845@bin2.nnrp.aus1.giganews.com...i >r: > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:XSeIODJ+jnlW@eisner.encompasserve.org.... > >i/ > > That's right.  Time to eat crow all around.' >iK > Nope.  The only crow I'm about to eat is my guess at McKinley's SPECint2K G > performance - *assuming* that the numbers reported by HP are actuallyh > accepted by SPEC.M >EJ > BTW, until that happens, your subject line above is incorrect:  the onlyJ > official such charts don't yet include McKinley numbers, and by the timeH > they do both official SPEC chart bars *may* have been raised higher byG > someone else such that your assertion will not be correct then eitherp (e.g.,L > given that submissions can be made up to 3 months before ship date the newH > 1.25 GHz EV68C numbers may yet appear before McKinley's do, as may newH > POWER4 numbers depending on the details of that processor's schedule). >.K > That said, if HP's numbers are even close to correct McKinley has come innL > considerably better than I expected it to, and there may be some reason toL > believe it's at least in large part due to HP's new chipset surrounding itK > (we'll see if and when other configurations release the same benchmarks).WK > Over 20% better SPECint2K performance (if you average base and peak) *peraJ > clock* than Alpha (and roughly the same per-clock performance as PA-RISCC > 8700 and MIPS R14K, both of which have lower max clock rates thans	 McKinley) H > is nothing to be sneezed at, though much of what isn't attributable to HP'sK > chip set can likely be laid at the door of McKinley's exceptionally largecL > and fast on-chip caches (no, I still don't have much use for EPIC itself). >rK > There's still just a bit of doubt in my mind because of some of the othereH > benchmark figures HP released that just don't seem to make sense.  ForJ > example, its 4-processor TPC-C performance came in about 55% higher than theeL > ES45's despite no better (perhaps considerably lower) system bandwidth (ifF > HP's Itanic configuration uses the shared 6.4 GB/sec bus rather thanD > something more like the ES45's onboard switch) and only 20% better	 SPECint2KaF > numbers.  MS SQL Server has some reputation for being a better TPC-CI > performer than Oracle, though, so that could account for the difference  (ithL > would be interesting to see results for HP-UX running Oracle...), as couldJ > details of the test configuration (which we won't know until TPC accepts andpH > posts the results).  It's unfortunate that Alpha is (still) owned by aG > company with little apparent interest in competing with Itanic in theaL > benchmark area, but IBM and AMD may be able to keep them at least somewhat	 > honest.h > L > And, BTW, I haven't heard a peep about McKinley's performance running IA32F > code - which will become increasingly important as Hammer becomes an issue.K > In a somewhat related vein, Hammer should be both performance-competitive-J > and *extremely* price/performance-competitive with Itanic on things likeA > TPC-C, bringing to mind a possibly-prophetic echo from the past-; >  http://news.com.com/2100-1001-228204.html?legacy=cnet ):. >iK > "At this point, most people understand that Merced itself is not going tow beD > a very compelling product for Intel," he said. "If you look at theK > performance of Merced, it's really not going to be meaningfully different.@ > from what you get at the high end of the 32-bit architecture." >gD > Indeed, even given McKinley's "surprisingly good" (Terry's phrase)J > performance, it's still not 'meaningfully different' from that availableL > from existing IA32 hardware (let alone Hammer) except in the very high-endG > niche areas which IA32 can't (and Hammer *may* not be able to) reach.  >cI > None of which makes any substantive difference to my primary, original,  andsK > consistent claim that Itanic's performance would never have done in AlphaeG > (though Alpha, with any reasonable support, would have stood a decent  chanceL > of doing in Itanic - especially if it ran IA32 binaries faster under FX!32L > as well as its native code).  The fact that McKinley seems to be coming inJ > above expectations is more than balanced by the increasing evidence thatK > Intel had no clue whatsoever where to go after the McKinley core (nor anyHK > obvious reason to expect that it would have developed much of a clue, letpH > alone the ability to bring it to fruition, without the influx of Alpha@ > talent and intellectual property such as EV7's on-chip routing facilities). > J > Itanic will have to live with whatever performance McKinley offers todayF > through both Madison and Montecito, modulo process shrinks that seemK > unlikely to more than double its current performance when Montecito comesxD > along in 2004 (assuming that heat dissipation problems don't limitH > performance to an even lower value) - and likely through 2005 as well,I > though it may get better on-chip support in 2005 similar to what POWER4n andwH > USIII got last year and EV7 and Hammer will get this year.  Next monthJ > McKinley will be matched by EV68 at 1.25 GHz, then next quarter eclipsed byG > EV7 in virtually all respects (SPECint, memory latency and bandwidth,eK > scalability, ...), and then would have been dealt an even heavier blow by.I > EV8's advantages of a process-shrink plus a completely new core and SMT I > support (with interesting things in EV9 yet to come).  These few months J > right now are as close as Itanic would ever have come to catching Alpha:I > when EV8 rolled around, Montecito would have offered *at most* half theMJ > per-processor performance in server-style activity, despite being a full > process generation ahead.s >- > - bill      K My bet is that HP will NOT publish any SPEC performance numbers for EV68 orr EV7.  K Why, you ask? Because they have no need to. And why would they want to makes9 their multi-billion dollar investment in Itanic look bad?r  K Anyone who needs EV68 or EV7 is a 'current ' customer and has no where elsenE to go for processors/systems, so no matter if EV68 or EV7 numbers are G slightly under, equal to, slightly over, or wildly over Itanic 2, those G customers will buy EV68/EV7 if they need the horsepower for their apps.   D Since HP is not in the business of selling Tru64 or OpenVMS to *new*E customers (their stated business model, not mine), they don't have toeJ impress anyone with great SPEC numbers for EV68/EV7, nor incur the expense of running the tests.m  L By not publishing numbers, they can further distance customer mind-sets fromL Alpha, and the performance they will have lost vs. Alpha when VMS arrives onL Itanic III or IV. Larry Ellison should be paying Capellas a huge royalty forI every customer that migrates from Alpha to n-Itanic processors to get thep same workload processed.   ------------------------------  % Date: Tue, 09 Jul 2002 00:53:37 -0400a- From: JF Mezei <jfmezei.spamnot@videotron.ca>f4 Subject: Re: McKinley tops SpecFP AND SpecInt charts, Message-ID: <3D2A6C46.57957327@videotron.ca>  	 Question:-  L IA64 is "EPIC" where it expects the compiler to do all the work to make best use of the chip's architecture.t  J In the Intel released results for IA64, was it done with normal commercialK applications compiled using whatever commercially available compilers existsF for IA64, was was it done with specially tweaked applications designed7 carefully to generate the best possible speed results ?r  K If the Intel released specs don't reflect what commercial applicatiosn willpI deliver, then the question is how big a gap there will be between Intel'seA "dream" specs, and what real world performance will be delivered.I  N Will Intel's commercial compilers really be able to take code not specifiacllyF designed for IA64 and generate assembler that makes best use of IA64's potential ?a   ------------------------------  $ Date: Mon, 8 Jul 2002 13:50:04 -0700* From: "Jack Peacock" <peacock@simconv.com>) Subject: Re: Mysterious non-spinning disk 5 Message-ID: <sYmW8.13709$AK.11753@news.webusenet.com>   J Is the TERM PWR (terminator power to bus) disabled on all the drives?  AreI you mixing wide and narrow drives?  I assume you have already checked fora duplicate ID numbers?i    Jack Peacock   ) <paul.beaudoin@hsbc.com> wrote in messagea? news:OF54C8014C.48CDABF1-ON80256BF0.003746A5@systems.uk.hsbc...' >e > Technosleuths -K >eC > I have a disk (9GB Seagate ST39102LW) that works only in specificmF > circumstances and can't logically divine what the actual problem is:L > This disk was originally in a DPW 500au (VMS 7.2) and worked fine for over	 > a year.i   ------------------------------   Date: 8 Jul 2002 22:51:30 GMTt2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)F Subject: Re: New web-page dedicated to ports of PD software to OpenVMS* Message-ID: <agd51i$t12$4@web1.cup.hp.com>   JOUKJ wrote:E : I created a new web page (http://nchrem.tnw.tudelft.nl/openvms/) oni  F   Please don't mess with the browser-selected color maps.  Just don't.F   Particularly when the page (sorry) looks like "angry fruit salad".  D   Blue and gray and red text on a fuscia background are, well, very    hard to read.r  F : The page consists of link to where to get it, what to patch and what; : software it depends on (and links to these dependencies). F : I hope this page will help to make it easier to find/install/run the : software on OpenVMS.  C   With your permission, I'll add a pointer to your page to the nextn   edition of the OpenVMS FAQ.g  F   Also, if you have new or newer ports, please consider following the #   submission guidelines at the URL:a  @     http://www.openvms.compaq.com/openvms/freeware/cd_guide.html  F   This will get your ports of the packages onto other sites, and onto G   the OpenVMS Freeware distribution.   Versions of bzip and ImageMagickwG   and such are already on the Freeware, though probably older versions.a  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Tue, 09 Jul 2002 01:57:01 GMTn1 From: "David J. Dachtera" <djesys.nospam@fsi.net>hF Subject: Re: New web-page dedicated to ports of PD software to OpenVMS' Message-ID: <3D2A472A.FD66005F@fsi.net>    JOUKJ wrote: >  > Terry C. Shannon wrote:5@ > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message% > > news:3D277BCB.A00995F6@fsi.net...i > >w > >>JOUKJ wrote: > >> > >>>Hi Folks, > >>>uH > >>>I created a new web page (http://nchrem.tnw.tudelft.nl/openvms/) onH > >>>which I'm planning to give a summary of all Publicdomain software IL > >>>contributed ports and/or patches to in order to have it run on OpenVMS.I > >>>The page consists of link to where to get it, what to patch and whate> > >>>software it depends on (and links to these dependencies).I > >>>I hope this page will help to make it easier to find/install/run thed > >>>software on OpenVMS.r > >>> L > >>>The present page is an initial version. More packages will be added theK > >>>coming weeks, but already contains some nice ports not found elsewhere8) > >>>on OpenVMS pages(i.e. Ted & Pfaedit)  > >>6 > >>The effort is much needed and greatly appreciated. > >>J > >>However, I must agree with Jan-Erik and company: the color scheme is aI > >>bit painful. Red on magenta is virtually invisible to some, just as Is0 > >>cannot see dark blue on black or vice-versa. > >> > >  > > P > > Yep, the current colour scheme might render the site virtually unreadable toN > > the ~10 percent of the male population that suffers from colour blindness. > >s > >M > >e > >PE > Ok, Now you can choose: the original one or the the one which is dee > default of your own browsere   Thanx, Jouk. Much better!    -- e David J. Dachterai dba DJE Systemss http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/e   ------------------------------   Date: 8 Jul 2002 13:42:13 -0600o- From: Kilgallen@SpamCop.net (Larry Kilgallen)i4 Subject: Re: Only 20% drop in VMS systems (was: wow)3 Message-ID: <P9z2QjSqHULr@eisner.encompasserve.org>    In article <agc2cp$jqc$1@new-usenet.uk.sun.com>, Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com> writes:  = > Kerry you are the perfect example of a workman who only has  > one tool,,  B My newsreader is broken, as that like was displayed as originating
 from sun.com.e   ------------------------------   Date: 8 Jul 2002 12:27:25 -0700n( From: bob@instantwhip.com (Bob Ceculski)4 Subject: Re: Only 20% drop in VMS systems (was: wow)= Message-ID: <d7791aa1.0207081127.23abf9e2@posting.google.com>t   Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com> wrote in message news:<agc2cp$jqc$1@new-usenet.uk.sun.com>...r > Main, Kerry wrote: > = > 	If the attempts at TCO studies that you have published arex@ > 	anthing to go by and we all know now that they don't actually= > 	show OpenVMS to be a lower cost environment because of ther? > 	miss-categorisation of your systems, then the answer to this ; > 	question unless you can come up with something better isr > 	also no.r  E the less computers involved in a solution, the less chips involved inmA a solution means lower TCO in the long run ... add VMS clusteringe and you lose Andrew ...A   > ? > Add Sybase into the mix and you have a very difficult task onm0 > your hands if OpenVMS is your chosen platform.  B Sybase is garbage compared to RDB ... maybe that's why they are noC longer on VMS Andrew, it's called competition, and the best productoA wins, except for those who buy Sun or IBM or Windoze garbage overiA Alpha/VMS, then they love paying TCO thru their nose, or they buym/ the kind of TCO lies you and others put out ...    > 	 > Regards  >  > Andrew Harrison    ------------------------------  # Date: Mon, 08 Jul 2002 20:30:22 GMTe* From: "Bill Todd" <billtodd@metrocast.net>4 Subject: Re: Only 20% drop in VMS systems (was: wow)@ Message-ID: <xDmW8.95183$vq.4433475@bin6.nnrp.aus1.giganews.com>  2 "Main, Kerry" <Kerry.Main@hp.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF402660805@kaoexc01.americas.cpqcorp.net. ..   ...u  D How do you proactively shut that single big SMP box down for plannedA maint or OS / HW upgrades / tuning / whatever with ZERO impact onb? application availability ie. no application restarting, no diska( fail-over, no batch jobs restarting etc.   ***s  K Given that I've been explaining to you for years now exactly how to do this E in Sun and similar environments, Kerry, I can only conclude that yourtI learning skills must be such that you never completed grammar school.  ItlF does of course involve clustering in cases where the upgrades can't beE performed on-line (which IIRC SPARC systems support considerably more G comprehensively than Alpha systems do), but nothing beyond what Sun hast provided for several years.n  = Disk fail-over, especially when planned (which eliminates theiI confirm-heartbeat-lost phase that occurs in unplanned failures), can takeeL place in seconds as long as the file system (e.g., VxFS or journaled UFS) isK log-protected (i.e., time sufficiently comparable to the lock-restructuring J latency when a node leaves a VMS cluster that it doesn't materially affectK availability).  Fail-over of various resources on the downed machine can beaL spread across multiple other members of the cluster (it's a static, scriptedH process that is less elegant but not materially less effective than loadJ redistribution in a VMS cluster).  And since such resources have their ownG IP aliases that are maintained after migration to another cluster node,aJ external clients aren't bothered any more than they are in the VMS cluster environment.  K IOW, there is no (more) application restarting than occurs on a VMS clusterhK when a node exits (in both cases, one should migrate applications elsewhererI beforehand) and no disk fail-over that's notably more disruptive than theiH lock-rebuilding VMS experiences when a node exits, though I admit that IK have no idea whether Solaris supports batch-resiliency in such cases (if itcL doesn't directly, I suspect the same effect could be achieved by appropriateJ scripts).  And there is no more requirement for idle, 'stand-by' resourcesK than there is in the VMS environment:  in both cases, the remaining clusteraJ nodes will experience *some* increased load when one cluster member exits,G and in both cases the cluster must be configured with sufficient excessrI capacity to handle this load, but in neither case does this mean that anya" node must stand idle until needed.  G VMS clusters have lead the field for close to 20 years, and still offerhE considerably more flexibility than their competition.  But that addedtL flexibility is increasingly less *functionally* critical to solving customerG problems:  it's still nice (and admirably elegant), but suggesting thatmL other approaches that have recently become available can't solve most of the@ same problems VMS clusters can reflects either ignorance or FUD.   - bill   ------------------------------  # Date: Mon, 08 Jul 2002 21:45:50 GMTi* From: "Bill Todd" <billtodd@metrocast.net>4 Subject: Re: Only 20% drop in VMS systems (was: wow)A Message-ID: <iKnW8.34298$Im2.1078774@bin2.nnrp.aus1.giganews.com>e  2 "Main, Kerry" <Kerry.Main@hp.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF402660808@kaoexc01.americas.cpqcorp.net. .. Andrew,a  E >>> Why would you need to shut it down, I can remove CPU's memory and . I/O controllers on any Sun in the F3800-F15000D range without any downtime, I can add them and I can add for example- faster CPU's/more memory without downtime.<<<a  6 So what happens when the load exceeds a single server?   ***f% *Then* you can start to cluster them.o  E Almost all single applications execute more efficiently on an SMP (oraK slightly NUMA) system than on a cluster, up to the point where the SMP/NUMACL system runs out of headroom.  That's the point where they get 'clusterized',J but even then there's often an advantage in clustering a smaller number ofA larger SMP systems than in using a larger number of small systems K (otherwise, the Alpha world would be full of clustered DS10s and the ES andL/ GS series would just be sitting in warehouses).C  L The ideal 'server consolidation' situation is one where each of your severalH SMP/NUMA boxes can run several of your applications:  no box is idle, no> individual applications experience clustering complexities andJ inefficiencies, but if one box fails or needs planned off-line maintenanceK the applications it hosted can fail over fairly evenly across the remainingg. boxes without themselves becoming partitioned.  K And even if you do have a single application that exceeds the capacity of a L single box (or comes close enough that failing it over to another box with aJ similarly-unpartitionable load would overload that box), 'clusterizing' itJ across relatively few boxes usually allows considerably better locality of+ reference than distributing it more widely.h  I IOW, large SMP/NUMA boxes are good.  So is clustering.  Neither makes therK other irrelevant.  Not only are fully-distributed applications often ratheriC complex to create and usually less efficient than more consolidatedgJ (SMP-oriented) approaches, but the 'many smallish member' cluster approachI is at least somewhat at odds with the general 'consolidation' philosophy:iD while an 'N + 1' (or 'N + 0' if you're willing to lose 1/Nth of your@ performance when you lose a node) approach to redundancy is moreI cost-effective than the '1 + 1' approach you continue to misrepresent SunhG clusters as using, most of that effectiveness is achievable with fairlytF small values of 'N' whereas large values of 'N' in at least many cases= introduce more problems and/or inefficiency than they remove.i ***n  E Perhaps an application that does not scale in an SMP environment (youoH know as well as I do that there are application and OS issues with large! SMP tuning like cache thrashing),n   ***n) That's what SMP/NUMA partitioning is for.  ***A  %  or the business load all of a sudden " becomes much higher than expected?   ***yI Your overall system must be configured to handle the maximum load whethern0 it's an SMP or a cluster (or a cluster of SMPs). ***w  E Replace that single production server with a bigger one? Sure, that'stF one option. Course, now you have to replace the backup server (the one that is hardly used)   ***tF Either it's your brain that's hardly used, Kerry, or the parenthetical phrase above is pure FUD.. ***   2  as it also needs to be capable of handling larger& loads in the event of a failover etc..  C >> Tuning, some tuning does require a re-boot but a great deal doese not,<<<b  H As far as your system tuning patching notes - all OS platforms have some? dynamic patching capabilities and some static ones that requirev> rebooting the system. Same goes for OpenVMS. Same for Solaris.  A The advantage clusters provides is that you can do planned system D reboots like these with ZERO application availability impact. SimplyH allow current work to complete while directing new work to other systemsH in the cluster. When no work is left on that server, it can be shutdown,C upgraded, replaced with a bigger server, whatever - again with ZERO # impact on application availability.o   ***c4 Gee - just like you can do with a Solaris cluster... ***w  # Re: online hot swap capabilities ..m  E Imho, who cares if one can add additional CPU's (you can do this witheF OpenVMS / GS Series as well btw) or IO controllers online, if you haveG the capability to add and/or replace entire systems in a cluster online ( with no application availability impact?   ***iB Well, I'd care if my cluster consisted of a single large local SMPL (desirable for the reasons noted above) plus a remote partner (used, say, atJ another corporate location to achieve disaster-tolerance - even vanilla FCK allows 10 km separation).  A lot of customers might be willing to trade offtJ some temporary system responsiveness (as distinct from availability) if anF unexpected disaster occured, but would prefer not to do so for routine maintenance/upgrades.2   - bill   ------------------------------  $ Date: Mon, 8 Jul 2002 18:42:35 -0400' From: "Main, Kerry" <Kerry.Main@hp.com>i4 Subject: RE: Only 20% drop in VMS systems (was: wow)T Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF40266080B@kaoexc01.americas.cpqcorp.net>   Bill,/   Re: grammar school ..e  D I am sorry if I offended the comp.os.vms moderator / grand teacher -" I'll try to behave in the future..   :-)d  A Sigh ... Lots of theory about what might be possible "if xyz weretF implemented.."  and "if xyz system implemented a log-protected scheme"< and "I suspect that the same could be implemented if ......"  C Lets talk specifics here - and let Andrew explain about how Solaris-E implements all of the "what might be possible if scenarios's .." that. you raised.t  H >>> suggesting that other approaches that have recently become availableF can't solve most of the same problems VMS clusters can reflects either ignorance or FUD.<<<  H Stay focussed - my question to Andrew was on how a single SMP box (not aF cluster - remember Andrew is promoting big SMP boxes over clusters forH IT Consolidation) can maintain application availability when servers are shut down proactively.  G >>> IOW, there is no (more) application restarting than occurs on a VMS < cluster when a node exits (in both cases, one should migrate% applications elsewhere beforehand)<<<o  G Ok, switch to clusters mode .. Remember to focus on proactive shutdowns  here.e  H You do not need to "move" OpenVMS cluster applications at all since theyA are already running in full read-write mode on other nodes in thefF cluster. What do you mean by this statement "in both cases, one should$ migrate applications elsewhere .." ?  F I know you know this already, but the shared everything clustered fileF system and DLM in an OpenVMS cluster ensures that users and batch jobsG on other servers have direct (not served) read-write access to the same 2 data from all the other systems in the cluster.=20  H So, in this scenario, since all of the work and processing is being doneE on other servers (was moved transparently before hand) a server going.G down proactively has zero impact on application availability. There areeF no application connections open to that server and all batch jobs haveH completed and/or directed to other nodes in the cluster. (yes, I realizeD those users that stay logged into servers for days on end need to be) asked to logout and log back in again)=20v  H Hey - I am willing to have my eyes opened, but lets get specific. Forget the "theory".=20  E Lets document (or provide pointers) exactly how Solaris can implementaG proactive server shutdowns with zero impact on application availabilitypE i.e. no broken connections or work restarting. Lets also include what.C needs to be done for clustered batch jobs as well in this scenario.c   Regardsa  
 Kerry Main Senior Consultantw Hewlett-Packard Canada! Consulting & Integration Servicesl Voice: 613-592-4660e Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----2 From: Bill Todd [mailto:billtodd@metrocast.net]=20 Sent: July 8, 2002 4:30 PM To: Info-VAX@Mvb.Saic.Come4 Subject: Re: Only 20% drop in VMS systems (was: wow)      2 "Main, Kerry" <Kerry.Main@hp.com> wrote in messageH news:BE56C50EA024184DAF48F0B9A47F5CF402660805@kaoexc01.americas.cpqcorp. net. .O   ..  D How do you proactively shut that single big SMP box down for plannedA maint or OS / HW upgrades / tuning / whatever with ZERO impact one? application availability ie. no application restarting, no disk ( fail-over, no batch jobs restarting etc.   ***o  F Given that I've been explaining to you for years now exactly how to doE this in Sun and similar environments, Kerry, I can only conclude thatsB your learning skills must be such that you never completed grammar@ school.  It does of course involve clustering in cases where theE upgrades can't be performed on-line (which IIRC SPARC systems supporteE considerably more comprehensively than Alpha systems do), but nothing / beyond what Sun has provided for several years.   = Disk fail-over, especially when planned (which eliminates the0D confirm-heartbeat-lost phase that occurs in unplanned failures), can? take place in seconds as long as the file system (e.g., VxFS orsF journaled UFS) is log-protected (i.e., time sufficiently comparable toG the lock-restructuring latency when a node leaves a VMS cluster that itsH doesn't materially affect availability).  Fail-over of various resourcesH on the downed machine can be spread across multiple other members of theE cluster (it's a static, scripted process that is less elegant but notaE materially less effective than load redistribution in a VMS cluster). F And since such resources have their own IP aliases that are maintained@ after migration to another cluster node, external clients aren't? bothered any more than they are in the VMS cluster environment.l  C IOW, there is no (more) application restarting than occurs on a VMSr< cluster when a node exits (in both cases, one should migrate applications elsewhereE beforehand) and no disk fail-over that's notably more disruptive thaneE the lock-rebuilding VMS experiences when a node exits, though I admittE that I have no idea whether Solaris supports batch-resiliency in sucheA cases (if it doesn't directly, I suspect the same effect could be.G achieved by appropriate scripts).  And there is no more requirement foreD idle, 'stand-by' resources than there is in the VMS environment:  inH both cases, the remaining cluster nodes will experience *some* increasedF load when one cluster member exits, and in both cases the cluster mustF be configured with sufficient excess capacity to handle this load, butB in neither case does this mean that any node must stand idle until needed.e  G VMS clusters have lead the field for close to 20 years, and still offer/E considerably more flexibility than their competition.  But that added/C flexibility is increasingly less *functionally* critical to solving  customerG problems:  it's still nice (and admirably elegant), but suggesting thatiH other approaches that have recently become available can't solve most ofD the same problems VMS clusters can reflects either ignorance or FUD.   - bill   ------------------------------  $ Date: Mon, 8 Jul 2002 19:11:57 -0400' From: "Main, Kerry" <Kerry.Main@hp.com>n4 Subject: RE: Only 20% drop in VMS systems (was: wow)T Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF40266080C@kaoexc01.americas.cpqcorp.net>   Bill,   E <<< Almost all single applications execute more efficiently on an SMPkF (or slightly NUMA) system than on a cluster, up to the point where the( SMP/NUMA system runs out of headroom.>>>  $ It depends on the application(s).=20  C Again, tuning large SMP boxes can be a challenge as well unless the:C application(s) was designed to be partitioned with large numbers of F CPU's. Just ask any DBA how he would setup their DB for max efficiencyF in a 50 cpu SMP server. Do you think he might have to do some planning here?   C <<< IOW, large SMP/NUMA boxes are good.  So is clustering.  Neithers makes the other irrelevant.>>   F Agreed. I also agree that using fewer bigger SMP capable boxes is whatF IT Consolidation is all about. However, when doing IT Consolidation orB eWhatever type external applications, the expected loads are oftenH seriously underestimated. A properly configured OpenVMS cluster providesH one with the flexibility to simply add or remove an entire system to the@ overall processing with zero application availability impact.=20  C Anyway, this is a rat-hole. Both single large SMP and clusters haverG pro's-n-con's. Where the expected loads are not easy to estimate, imho,iD the best approach is to cluster fewer large SMP servers and only add additional servers as required.r  G What started this discussion was Andrew stating SMP servers were better-G for IT Consolidation than clusters. However, imho, SMP servers on their G own do not typically provide the level of availability that is required % when doing IT Consolidation projects.7   Regards.    
 Kerry Main Senior Consultant  Hewlett-Packard Canada! Consulting & Integration ServicesA Voice: 613-592-46600 Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----2 From: Bill Todd [mailto:billtodd@metrocast.net]=20 Sent: July 8, 2002 5:46 PM To: Info-VAX@Mvb.Saic.Comp4 Subject: Re: Only 20% drop in VMS systems (was: wow)      2 "Main, Kerry" <Kerry.Main@hp.com> wrote in messageH news:BE56C50EA024184DAF48F0B9A47F5CF402660808@kaoexc01.americas.cpqcorp. net. .n Andrew,s  E >>> Why would you need to shut it down, I can remove CPU's memory andl. I/O controllers on any Sun in the F3800-F15000D range without any downtime, I can add them and I can add for example- faster CPU's/more memory without downtime.<<<P  6 So what happens when the load exceeds a single server?   ***a% *Then* you can start to cluster them.u  E Almost all single applications execute more efficiently on an SMP (orlB slightly NUMA) system than on a cluster, up to the point where theF SMP/NUMA system runs out of headroom.  That's the point where they getG 'clusterized', but even then there's often an advantage in clustering afE smaller number of larger SMP systems than in using a larger number ofvD small systems (otherwise, the Alpha world would be full of clusteredD DS10s and the ES and GS series would just be sitting in warehouses).  D The ideal 'server consolidation' situation is one where each of yourG several SMP/NUMA boxes can run several of your applications:  no box isiG idle, no individual applications experience clustering complexities andP> inefficiencies, but if one box fails or needs planned off-lineB maintenance the applications it hosted can fail over fairly evenlyC across the remaining boxes without themselves becoming partitioned.e  F And even if you do have a single application that exceeds the capacityF of a single box (or comes close enough that failing it over to anotherC box with a similarly-unpartitionable load would overload that box),x< 'clusterizing' it across relatively few boxes usually allowsC considerably better locality of reference than distributing it moreo widely.e  E IOW, large SMP/NUMA boxes are good.  So is clustering.  Neither makes)H the other irrelevant.  Not only are fully-distributed applications often= rather complex to create and usually less efficient than morel consolidatedA (SMP-oriented) approaches, but the 'many smallish member' cluster,F approach is at least somewhat at odds with the general 'consolidation'H philosophy: while an 'N + 1' (or 'N + 0' if you're willing to lose 1/NthH of your performance when you lose a node) approach to redundancy is moreE cost-effective than the '1 + 1' approach you continue to misrepresenttD Sun clusters as using, most of that effectiveness is achievable withG fairly small values of 'N' whereas large values of 'N' in at least many C cases introduce more problems and/or inefficiency than they remove.t ***a  E Perhaps an application that does not scale in an SMP environment (youlH know as well as I do that there are application and OS issues with large! SMP tuning like cache thrashing),    ***:) That's what SMP/NUMA partitioning is for.r ***.  %  or the business load all of a suddeny" becomes much higher than expected?   ***IA Your overall system must be configured to handle the maximum loadi8 whether it's an SMP or a cluster (or a cluster of SMPs). ***F  E Replace that single production server with a bigger one? Sure, that'soF one option. Course, now you have to replace the backup server (the one that is hardly used)   ***0F Either it's your brain that's hardly used, Kerry, or the parenthetical phrase above is pure FUD.t ***d  2  as it also needs to be capable of handling larger& loads in the event of a failover etc..  C >> Tuning, some tuning does require a re-boot but a great deal does  not,<<<l  H As far as your system tuning patching notes - all OS platforms have some? dynamic patching capabilities and some static ones that requiret> rebooting the system. Same goes for OpenVMS. Same for Solaris.  A The advantage clusters provides is that you can do planned systemnD reboots like these with ZERO application availability impact. SimplyH allow current work to complete while directing new work to other systemsH in the cluster. When no work is left on that server, it can be shutdown,C upgraded, replaced with a bigger server, whatever - again with ZEROr# impact on application availability.n   ***l4 Gee - just like you can do with a Solaris cluster... ***i  # Re: online hot swap capabilities ..   E Imho, who cares if one can add additional CPU's (you can do this withiF OpenVMS / GS Series as well btw) or IO controllers online, if you haveG the capability to add and/or replace entire systems in a cluster online ( with no application availability impact?   *** B Well, I'd care if my cluster consisted of a single large local SMPD (desirable for the reasons noted above) plus a remote partner (used,G say, at another corporate location to achieve disaster-tolerance - evendA vanilla FC allows 10 km separation).  A lot of customers might be F willing to trade off some temporary system responsiveness (as distinctF from availability) if an unexpected disaster occured, but would prefer. not to do so for routine maintenance/upgrades.   - bill   ------------------------------  # Date: Tue, 09 Jul 2002 02:06:48 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>h4 Subject: Re: Only 20% drop in VMS systems (was: wow)' Message-ID: <3D2A4972.F9981389@fsi.net>h  ( Andrew Harrison SUNUK Consultancy wrote: >  > Main, Kerry wrote: >  > > JF - > >aG > > Re: measuring numbers of systems Customers have as a measure of howe > > popular they were vs now ..l > >mK > > Fwiw, the total numbers of systems in almost all med to large CustomerscK > > is shrinking a huge amount these days. Almost every one of these Cust'spL > > is either considering, investigating or implementing an IT consolidation5 > > project as a means to reduce their overall costs.M > >iG > > And this applies to all platforms. We bid on one RFP here in CanadafJ > > whereby the Govt wanted to reduce the number of small Sun systems fromK > > 150 down to less than 10. Another Customer has over 1100 NT servers andxI > > wanted this number to shrink to 250 range. Another Customer in Canada L > > has approx 115 small VAX and Alpha servers across the country and wantes2 > > to reduce that overall number to less than 10. > > L > > All of these have the same thing in common. Reduce the overall number ofC > > servers with much bigger, higher availability and in many cases K > > multi-site as well... (IT consolidation 101 says a single site is not aa > > wise move.)> > >n >  > Motherhood and Apple pie.b > = > But how will you address this with OpenVMS. Lets get a tinyg > weeny dose of reality here.r >  > 1.3 > Unless you cluster which can drag your SW licences< > costs up to a level that makes you wince OpenVMS currentlyF > doesn't have a platform that will support very large consolitations.  6 I'm surprised no one lambasted you for that statement!  H In the past, I've had VAX 6600-series machines with upwards of 200 usersH running All-in-1 (the hog of hogs), while current "Citrix servers" don'tA seem to be able to handle much more than 15 users without seriousw performance degradation.  * My experience does not support your claim.   --   David J. Dachterao dba DJE Systemsl http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/P   ------------------------------   Date: 8 Jul 2002 18:47:35 GMTc2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)J Subject: Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!)* Message-ID: <agcmo7$qav$1@web1.cup.hp.com>  c In article <uhffd6cos3vqa4@news.supernews.com>, "Island (hpaq.net)" <dbturner@islandco.com> writes:tL :I can guarantee you that HPAQ will do something to the main logic board andL :patent/copyright every circuit and firmware on it to prevent others getting8 :a share of the profitable VMS hardware/licensing market  C   The following assumes compliance with the applicable national andb@   international intellectual property and copyright regulations,D   laws, conventions, etc.  If you do choose to clone and/or to copy H   (or even to export or sometimes import certain) hardware or software, F   you will need the appropriate authorizations and/or licenses and/or    permissions.  E   OpenVMS Engineering has historically implemented nothing that would G   explicitly prevent OpenVMS from bootstrapping on third-party VAX and tG   third-party Alpha platforms, and OpenVMS Engineering has specificallytD   provided mechanisms to add platform support for new and otherwise G   unrecognized Alpha platforms via the (documented) SHIP kit mechanism.   F   I know of folks running (licensed copies of) OpenVMS on third-party C   Alpha boxes and on third-party VAX boxes -- there were folks thatfF   were building ruggedized VAX boxes for special applications for manyB   years, and ruggedized third-party Alpha boxes have been shown atC   various customer events), and we went as far as extending formal  B   product support to the Tadpole Alpha boxes.  (There were OpenVMSF   license part numbers that these folks could order.)  More recently, F   we have worked with SRI to provide a VAX emulator package, allowing E   OpenVMS VAX to bootstrap and operate on various HP and third-party o   platforms.  F   In keeping with this tradition, OpenVMS Engineering has no plans to F   implement (technical) restrictions preventing the use of OpenVMS on B   third-party IA-64 platforms.  Of course, issues around customer D   requirements and customer expectations for the testing of and the B   support of the platforms can and will exist, as OpenVMS will be F   tested only on specific HP IA-64 platforms and (potentially) tested E   for specific customer situations and configurations.  (And has has uE   been the case with VAX and Alpha third-party platforms, all issues uG   around adapter and platform support are left to the integrator and/or H   platform vendor.)  These (tested) platforms will comprise the list of ;   platforms supported by HP OpenVMS Engineering, of course.r  J :Quite easy really - just find a reliable obsure SCSI controller and stuffI :some VERY proprietary firmware on it - then stuff it on the motherboard.vI :Just like the KZPCA Ultra LVD controller - use a generic and VMS dumps aa  :coupl eof minutes into loading.  H   No two SCSI controllers are ever alike, as anyone that has ever workedI   with this stuff can attest.  (If you got as far as a couple of minutes oE   into the OpenVMS bootstrap, that's actually fairly impressive.  We lF   recently found a case were a SCSI disk's state machine visited "the D   weeds" simply because we had not read the SCSI check as the disk'sE   state machine had expected.  The state machine ignored all inbound tG   SCSI packets until the check condition was completed, and became, um,uB   catatonic.)  As an old computer joke states, "compatible" means F   "different" -- if the devices were actually "identical", well, they *   would not have been called "compatible".  K   As I have repeatedly stated here in the newsgroups, testing does provide l3   direct customer value.  And testing is not cheap.8  F   As for generics, these are tested with the platforms that the vendorH   expects the device to be used with.  We have found any number of theseI   that don't actually work.  Some USB testing I was involved with severalcG   weeks back found that a brand-new "USB" camera was violating the USB oJ   specifications, and worked on its target platforms (apparently) by luck E   or (possibly) by a host-based "increase in tolerance for standards d    variations".  But I digress...  I   These are not third-party lock-outs, these are the usual joys of deviceeG   support.  (And folks wonder why adding and testing and releasing new  1   platform or new adapter support takes a while?)h    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Mon, 08 Jul 2002 22:24:58 -0500sC From: "Craig A. Berry" <craig.berry@nospam.SignalTreeSolutions.com>lJ Subject: Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!)H Message-ID: <craig.berry-E5AADF.22245808072002@news.directvinternet.com>  * In article <agcmo7$qav$1@web1.cup.hp.com>,4  hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) wrote:  F > In article <uhffd6cos3vqa4@news.supernews.com>, "Island (hpaq.net)" ! > <dbturner@islandco.com> writes:sN > :I can guarantee you that HPAQ will do something to the main logic board andN > :patent/copyright every circuit and firmware on it to prevent others getting: > :a share of the profitable VMS hardware/licensing market  F This is clearly a jaundiced overstatement, but the KZPCA situation is  enough to make one paranoid.  L > :Quite easy really - just find a reliable obsure SCSI controller and stuffK > :some VERY proprietary firmware on it - then stuff it on the motherboard. K > :Just like the KZPCA Ultra LVD controller - use a generic and VMS dumps aM" > :coupl eof minutes into loading. > J >   No two SCSI controllers are ever alike, as anyone that has ever worked! >   with this stuff can attest.  ,  H Even two controllers that use the same chip set and are manufactured by E the same manufacturer and differ only by the "Hello, my name is ..." rH identification in the firmware?  Or does the KZPCA firmware really have H something that special in it that is different from otherwise identical " Symbios (aka LSI Logic) 895 cards?  - >  (If you got as far as a couple of minutes lD >   into the OpenVMS bootstrap, that's actually fairly impressive.    E This statement implies a degree of randomness or luck in how far the  G boot proceeds, but luck has nothing to do with it.  The driver detects eH that this is a device it knows how to run but when it sees that the ROM B checksum is not that of a DEC/Compaq-branded card it takes itself E offline.  One of your colleagues in the Tru64 group has come out and lE said that the special ROM is essentially a "royalty chip" to enforce c3 payment to Intraserver for writing the driver; see:-  I <http://www.rosat.mpe-garching.mpg.de/mailing-lists/tru64-unix-managers/2i 001-09/msg00334.html>p  G Is Compaq/HP still paying royalties to Intraserver/LSI Logic for every BB KZPCA sold?  If not, can we please get the self-destruct sequence  eliminated?   H >   As for generics, these are tested with the platforms that the vendor) >   expects the device to be used with.  u  G The costs and complications of testing are understood and appreciated, pF but this discussion is not about "generics," it is a about brand name E stock devices that are identical to supported options but don't work t' because of a poison pill in the driver.   K >   These are not third-party lock-outs, these are the usual joys of devicev >   support.  D I believe you for most cases, but the KZPCA / Symbios 895 situation D certainly appears to be a lock-out.  This is still true in VMS v7.3 H and, apparently, recent versions of Tru64.  This wouldn't be a big deal E if there were 4 or 5 other relatively modern SCSI options available, tH but there aren't.  I believe the KZPCA is the only LVD card that's even " a possibility for pre-EV6 systems.   ------------------------------  $ Date: Mon, 8 Jul 2002 23:48:01 -0400. From: "David Pikcilingis" <piks@speakeasy.net> Subject: Re: Pascal Editor/EDT/ Message-ID: <uikn8dhq5gcd34@corp.supernews.com>-  L Boston Business Computing produces an editor, EDT+, that works under windows and on most UNIX systems.i7 It can edit the files from OpenVMS on the local system.   G An fully functional time limited Windows version can be downloaded fromt# http://www.bosbc.com/download.html.   K UNIX evaluations can be obtained by sending a request to sales@bosbc.com orr; by filling out the form at http://www.bosbc.com/contact.htmi     David Pikcilingise Boston Business Computingt    . "Jim Agnew" <jpagnew@vcu.edu> wrote in message! news:3D298EEA.51237193@vcu.edu... H > Are you looking for EDT to run on a Pc?  do a www.google.com search on > SEDT, or anker sonneI > (not sure about spelling of last name) he has an sedt page for windows,t > dos, linux, etc. >uJ > the dos sedt runs ok under all windows platforms, including XP, but it's > a little flakier under xp..  >i > jimy >K > Shiva MahaDeva wrote:n > >aD > > Which Editor can I use im my PC to open Vax Pascal files exactlyB > > how I see these files using Edit/EDT files in the VMS system ?D > > Id like transfer VAX Pascal files from the VMS system to my PC,0 > > and vice versa, keeping the Edit/EDT format.   ------------------------------  % Date: Mon, 08 Jul 2002 21:54:48 +0100<- From: Gerald Marsh <gerald@cyfer.demon.co.uk>i3 Subject: Re: PMS$GL_IOPFMPDB - What's grabbing it?? 8 Message-ID: <urujiu0nuqtacjedu2slkuiejhna51lpf1@4ax.com>   Ken,  A Thanks for your response - It is indeed a Fortel product but youriD engineering in The States came up with the goods in very short time!$ (It's an internal PID at offset 32!)  E I am impressed with the speed of the knowledgeable response (Oh me ofg little faith!).a   Bye for now and thanks again,m   Gerald.     B On 8 Jul 2002 10:58:42 -0700, ken.randell@fortel.com (Ken Randell) wrote:  C >I'm not aware of a way to determine WHO actually has 'grabbed' thelF >PMS$GL_IOPFMPDB.  Once it's done, and not 'cleanly' released, you may( >be stuck until you re-boot your system. >iF >You did not mention the name of the 'performance management' product,B >but if the company that produces it successfully compares with myF >e-mail address, contact me off-line at that e-mail address, and I canF >help you.  Alternatively, contacting support directly at that companyC >will also work.  VECINUSE is one of the error messages produced iff2 >things are not as expected during initialization. >e >Ken Randell > n >Gerald Marsh <gerald@cyfer.demon.co.uk> wrote in message news:<ahnbiuka07ia2cl1h1d7ou2jtp94s5sdqu@4ax.com>...I >> We are running a performance management product which supposed to give ' >> a hotfiles list if we ask it nicely.  >>  H >> Unfortunately the module is dying - sometimes with a VECINUSE error -8 >> and reporting that PMS$GL_IOPFMPDB is already in use. >>  C >> Any ideas on how to find out which process has grabbed it for IOnG >> performance instrumentation? We run Perfectdisk - which AFAIK cannotlG >> produce a Hotfiles list - and used to run DecPS but that was removed  >> over a year ago.' >> oC >> EXAMINE in ANAL/SYS around the location doesn't give me anything F >> meaningful but the contents of the longword is definitely non-zero. >> c) >> Any help would be gratefully received.s >> m >> Keep the flag flying! >> h >> Gerald Marshr >> a >> l >> f2 >> gerald -at- cyfer -dot- demon -dot- co -dot- uk   ------------------------------    Date: 09 Jul 2002 02:12:15 +0800, From: Paul Repacholi <prep@prep.synonet.com>) Subject: Re: SET FILE/TRUNCATE equivalente- Message-ID: <8765zqt7gg.fsf@prep.synonet.com>s  B "Antony Wardle" <antony.wardle@nospammmmm.optusnet.com.au> writes:  + > let me know if you find out how to do it.h  uD > I have a file that is a 2.2 million lines long and I only want theF > first 11 characters from each line, I will have to do this every few< > days, so I guess that dcl is out for me, and I don't speak > programming languages ;-(c  C And how long did you say the lines are? And must it be 11? or wouldo> 12 or 14 be near enough? You need to care a lot at 2.2M lines.     -- 0< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.s@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------   Date: 8 Jul 2002 12:01:50 -0700g: From: craig.berry@SignalTreeSolutions.com (Craig A. Berry)) Subject: Re: SET FILE/TRUNCATE equivalent = Message-ID: <7f15589f.0207081101.3279f2f2@posting.google.com>p  r "John.Malmberg" <Malmberg@dskwld.zko.dec.compaq> wrote in message news:<3D299FD9.3040706@dskwld.zko.dec.compaq>... > Antony Wardle wrote: > G >  > I have a file that is a 2.2 million lines long and I only want the I >  > first 11 characters from each line, I will have to do this every fewhK >  > days, so I guess that dcl is out for me, and I don't speak programming  >  > languages ;-( > 9 > Please see the documentation on the SORT/MERGE utility.  > < > That task should be easily done with a small specification > file.   ' Or a really, really small Perl program:l  > $ perl -lne "print substr $_, 0, 11;" infile.dat > outfile.dat   ------------------------------  % Date: Tue, 09 Jul 2002 15:27:59 +0010 % From: paddy.o'brien@zzz.tg.nsw.gov.auo) Subject: Re: SET FILE/TRUNCATE equivalentt5 Message-ID: <01KJW9ECOTZM0009XR@tgmail.tg.nsw.gov.au>a   Paul Sture wrote:t  7 >In article <01KJTO4LKYN600087V@tgmail.tg.nsw.gov.au>, C( >paddy.o'brien@zzz.tg.nsw.gov.au writes:M >> Is there a RTL or system services routine to effect the equivalent of the i >> subject line? >> tN >> I've had a look through help and haven't noticed anything obvious.  I know K >> there is the RMS $truncate, but I'd like to avaoid getting my hands too u dirty  >> if there is a simpler way.v >>   >h+ >Would LIB$SPAWN or LIB$DO_COMMAND suffice?O  = Thanks to all those who replied with a variety of approaches.8  L I have opted to go the way suggested by Paul -- lack of lateral thinking on  my part ;-(   N My reason for this choice is that we have to port some of our applications to L the PC world for our engineers who travel, and we already have a PC version . of LIB$SPAWN which in most cases does nothing.   Regards, Paddy   ------------------------------  # Date: Tue, 09 Jul 2002 01:55:22 GMTs1 From: "David J. Dachtera" <djesys.nospam@fsi.net>i' Subject: Re: SMTP 8bit hack not workingt' Message-ID: <3D2A46C5.B6132C68@fsi.net>a   Don Sykes wrote: >  > Lawrence Bleau wrote:n > >dZ > > In article <3D2338D8.25A5118C@pacbell.net>, Don Sykes <annonymous@pacbell.net> writes: > > ><snip> J > > >Maybe because the logical meant nothing it was ignored. Stop defining > > >TCPIP$SMTP_8BITMIME_HACK.R > > >I'm running VMS 7.2 w/ TCPIP 5.1 (no ECOs applied) and just have EIGHTBIT set@ > > >without any TCPIP$SMTP* logicals defined and it works fine. > > I > > You know, this makes me think: Perhaps when I applied one of the ECOsfI > > it disabled (or broke) this feature?  You know, something that should I > > make it work without needing the logical name, only they reversed the ? > > logic somehow and caused it to never work.  It's a thought.  > >iE > > Wire, would you lay odds that if you applied ECO 4 it would stilll" > > work?  Just a thought/insight. > >rP > In my way-too-long career, I've learned not to fight it when things don't workR > as advertised. It usually takes much less of my time just to work around the illN > effect. Of course you have to note what you've done for a subsequent version$ > when things DO work as advertised. > R > FYI "Wire Paladin" is not my pseudonym, it is a reference to a 1950's TV westernR > (Have Gun, Will Travel) staring Richard Boone. His name was Paladin. His calling > card read: >  > Have Gun, Will Travelo > Wire Paladin > San FranciscoD > A > In the 1880's "wiring" someone was equivalent to today's email.a  B Actually, telegrams are still in existence, but are little used inH comparison to more contemporary facilities, and are not actually sent by' telegraphy (in the conventional sense).:  E Sending someone a wire meant sending a message by wire - in the earlyg days that meant telegraph.  F In grade school, I took a short piece of 22AWG to school, handed it toG the teacher and told her that, "a wire came for you this morning - herel it is".t   --   David J. Dachterad dba DJE Systemsy http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/w   ------------------------------   Date: 8 Jul 2002 16:16:48 -0700p. From: SPAMSINK2001@YAHOO.COM (Alan E. Feldman)' Subject: Re: Trouble with BACKUP/RECORD = Message-ID: <343f30ae.0207081516.32e40cb7@posting.google.com>c  j Roland Barmettler <rob@bbp.ch.remove> wrote in message news:<20020701154048.5fe0e687.rob@bbp.ch.remove>... > Hi all >  > Thanks to all for your help! > . > Apparently, it is not a bug, it's a feature:T > http://www.compaq.com/support/asktima/operating_systems/CHAMP_SRC000308003657.html >  > ;-)V >  > Greetings, Rolandl > H > --------------- bbp - Biveroni Batschelet Partners AG ----------------< >              Bahnhofstrasse 28, CH-5401 Baden, SwitzerlandH > ----------------------------------------------------------------------    # Did you try it with /NOINCREMENTAL?V     Disclaimer: JMHO Alan E. Feldmann afeldman gfigroup com-   ------------------------------   Date: 8 Jul 2002 23:01:43 GMTs2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: UAF questions* Message-ID: <agd5kn$t12$5@web1.cup.hp.com>  f In article <afrjg9$fiu$1@n.ruf.uni-freiburg.de>, gartmann@immunbio.mpg.de (Christoph Gartmann) writes: :In article <20020702044442.48247.qmail@web21009.mail.yahoo.com>, =?iso-8859-1?q?Tadimeti=20Keshav?= <keshav_tadimeti@yahoo.co.uk> writes:  6 :>I am trying to add users with sys$system:authorize.  :>7 :>Now using SYSTEM account I log in and start AUTHORIZEs5 :>program. I want to change the default directory forl4 :>the DEFAULT user (because by default all users are% :>created right under sys$device, eg,m :>sys$device:[NITIN]). u :>6 :>Our machine has only one disk. I want all users have7 :>their login directories under one USER directory. Ford5 :>example, for SAM the login directory path would be i- :>sys$device:[USER.SAM]. For TOM it should be  :>sys$device:[USER.TOM]. i :>( :>So while in UAF, should I do the foll:' :>MODIFY DEFAULT /DIRECTORY=[USER.USER]p8 :>so that user 'X' can be created as sys$device:[USER.X] :u :For an existing user doP :  MODIFY existing_username /DIRECTORY=[USER.existing_user]/device=sys$sysdevice
 :Otherwise? :  ADD new_user /DIRECTORY=[USER.new_user]/device=sys$sysdevicee  E   Beware: Users tend to embed their directory path in procedures and m'   such, so it won't quite be this easy.s  E   I am assuming the reason for the request is to reduce the perceived 8   user directory clutter in the [000000] root directory.  J   I'd encourage use of a rooted logical name for the user root directory, H   and not sys$device:[USER.name].  Specifically, I'd create a concealed K   rooted logical name that (currently) translates into ddcu:[user.], where lF   ddcu: is the device name of the system disk.  This logical would be F   established in SYLOGICALS.  Users will thus see FOO:[BILL] (assumingI   the logical name is FOO, of course), and not SYS$SYSDEVICE:[USER.BILL].CG   This makes it easier on the users, and it makes it easier to move theaE   users around since they don't have "SYS$SYSDEVICE:[USER" or similare(   such text embedded all over the place.  /   Accordingly, the AUTHORIZE commands would be:"-     UAF> MODIFY existing_username /device=FOOe6     UAF> ADD new_user /DIRECTORY=[new_user]/device=FOO      N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   Date: 8 Jul 2002 22:24:11 GMTr2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: VMS 64bitness* Message-ID: <agd3eb$t12$2@web1.cup.hp.com>  2 "Paul Winalski" <prune@ZAnkh-Morpork.mv.com> wrote* news:3d237237.2122121@news.easynews.com...G : Doesn't amount to a hill of beans, given that nearly all the EXTERNALo8 : interfaces available to applications are still 32-bit.  9   As they should be.  That's called upward-compatibility.-  G   Continued application upward-compatibility is central to the decisioncE   of the API changes, of course -- existing and unmodified user-mode -5   32-bit applications do need to continue to operate.i   G   Some of the existing OpenVMS routines were extended and can tolerate eJ   both 32-bit and 64-bit calls, and various other calls were supplemented H   with parallel 64-bit calls, usually with a _64 suffix on the original G   name.  And yes, there are certainly 32-bit RTL calls that were never 7E   moved over to 64-bit -- we do have a huge pile of calls and many ofcG   these calls have long-since been effectively replaced by other calls.e  F   Which (missing) 64-bit services or RTL routines are you refering to?I   There may well be alternatives.  If there are central omissions, well,     we do need to resolve them.t    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Tue, 09 Jul 2002 01:50:34 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>  Subject: Re: VMS 64bitness' Message-ID: <3D2A45A4.7A5AFA41@fsi.net>    David Mathog wrote:  >  > Paul Winalski wrote: > >sI > > Doesn't amount to a hill of beans, given that nearly all the EXTERNALa: > > interfaces available to applications are still 32-bit. > G > Not to mention the 16 bit limits in RMS and the absolutely RIDICULOUSiI > itty bitty limits in parts of DCL (line lengths, variable limits, etc.)e  D Re: the specifics you cite, I thought those were artifacts of stringA descriptors and signed longwords, rather than shortcomings of DCLl itself.o  , Granted, the CLI itself could use revamping.  G Some time back, I posted a wish list that included, among things, fixeswE for the items you cite including introduction of floating point math,vG command procedure libraries (.CLBs?), the ability to "include" DCL codetH at the current procedure depth from either a .COM or a module in a .CLB, and others.n  D Really, when you think about it, DCL really should support a commandF line buffer size of in excess of 4K. Why do I say that? Well, considerG that individual command elements, if taken via symbol substitution froma= symbols P1 through P8 of up to 510 bytes each plus a verb and0/ qualifiers(+values), 4K can easily be exceeded.    My $0.02...L   -- c David J. Dachtera  dba DJE Systemsn http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/h   ------------------------------   Date: 8 Jul 2002 15:56:18 -0700h. From: SPAMSINK2001@YAHOO.COM (Alan E. Feldman)' Subject: Re: Where to put startup stuffs= Message-ID: <343f30ae.0207081456.547ddd17@posting.google.com>   Z p_sture@elias.decus.ch (Paul Sture) wrote in message news:<kG$Jt4wZPKgK@elias.decus.ch>...c > In article <l0djiuc7vmvor6stp3b2iq46m65t1k5c8g@4ax.com>, jlsue <jlsuexxxz@screaminet.com> writes: I > > I've always made use of all the SY*.com files - though SYSECURITY anduJ > > SYCONFIG are not needed most of the time (well, "always" is since they > > were made available).e > > I > > It helps to put a write sys$output statement at the beginning and endvE > > of each of these files (I also include f$time()) so that you knowKB > > which procedure is being executed.  Likewise, before I executeF > > external procedures I use write sys$output to let me know where myE > > startup is processing... this is very useful if things die in theP6 > > middle, helps me get right to the problem quicker. > > F > > One thing to note:  Some of the files - e.g., SYLOGICALS.COM - getJ > > executed even during a "minimum" boot.  You need to put logic there toJ > > skip over things you don't want to happen during a minimum boot (e.g.,. > > mounting all of the system/cluster disks). > > H > It is worth noting that the startup calls these procedures with P1 set > appropriately.  F Could you please explain what you mean by this? Give an example maybe?   ------------------------------   Date: 9 Jul 02 03:17:56 +0200u) From: p_sture@elias.decus.ch (Paul Sture)v' Subject: Re: Where to put startup stuffr) Message-ID: <hTbIPfr3W$Yd@elias.decus.ch>   n In article <343f30ae.0207081456.547ddd17@posting.google.com>, SPAMSINK2001@YAHOO.COM (Alan E. Feldman) writes:\ > p_sture@elias.decus.ch (Paul Sture) wrote in message news:<kG$Jt4wZPKgK@elias.decus.ch>...d >> In article <l0djiuc7vmvor6stp3b2iq46m65t1k5c8g@4ax.com>, jlsue <jlsuexxxz@screaminet.com> writes:J >> > I've always made use of all the SY*.com files - though SYSECURITY andK >> > SYCONFIG are not needed most of the time (well, "always" is since theyh >> > were made available). >> > eJ >> > It helps to put a write sys$output statement at the beginning and endF >> > of each of these files (I also include f$time()) so that you knowC >> > which procedure is being executed.  Likewise, before I executeeG >> > external procedures I use write sys$output to let me know where myfF >> > startup is processing... this is very useful if things die in the7 >> > middle, helps me get right to the problem quicker.  >> > nG >> > One thing to note:  Some of the files - e.g., SYLOGICALS.COM - getlK >> > executed even during a "minimum" boot.  You need to put logic there tonK >> > skip over things you don't want to happen during a minimum boot (e.g., / >> > mounting all of the system/cluster disks).t >> > WI >> It is worth noting that the startup calls these procedures with P1 set' >> appropriately.y > H > Could you please explain what you mean by this? Give an example maybe?  M For example, in SYLOGICALS, on a normal boot, P1 is "FULL". I honestly forget I what the value is on a minimum boot ( "MINI" ?), bur have used it to goodh effect in the past.  __
 Paul Sture Switzerlandv   ------------------------------  # Date: Tue, 09 Jul 2002 02:11:55 GMTU1 From: "David J. Dachtera" <djesys.nospam@fsi.net>g' Subject: Re: Where to put startup stuffo' Message-ID: <3D2A4AA8.4114FD92@fsi.net>g   Paul Sture wrote:u > p > In article <343f30ae.0207081456.547ddd17@posting.google.com>, SPAMSINK2001@YAHOO.COM (Alan E. Feldman) writes:^ > > p_sture@elias.decus.ch (Paul Sture) wrote in message news:<kG$Jt4wZPKgK@elias.decus.ch>...f > >> In article <l0djiuc7vmvor6stp3b2iq46m65t1k5c8g@4ax.com>, jlsue <jlsuexxxz@screaminet.com> writes:L > >> > I've always made use of all the SY*.com files - though SYSECURITY andM > >> > SYCONFIG are not needed most of the time (well, "always" is since theyo > >> > were made available). > >> >L > >> > It helps to put a write sys$output statement at the beginning and endH > >> > of each of these files (I also include f$time()) so that you knowE > >> > which procedure is being executed.  Likewise, before I executehI > >> > external procedures I use write sys$output to let me know where my>H > >> > startup is processing... this is very useful if things die in the9 > >> > middle, helps me get right to the problem quicker.l > >> >I > >> > One thing to note:  Some of the files - e.g., SYLOGICALS.COM - getTM > >> > executed even during a "minimum" boot.  You need to put logic there toAM > >> > skip over things you don't want to happen during a minimum boot (e.g.,o1 > >> > mounting all of the system/cluster disks).l > >> >K > >> It is worth noting that the startup calls these procedures with P1 setc > >> appropriately.o > >hJ > > Could you please explain what you mean by this? Give an example maybe? > O > For example, in SYLOGICALS, on a normal boot, P1 is "FULL". I honestly forgeteK > what the value is on a minimum boot ( "MINI" ?), bur have used it to good. > effect in the past.o  C Note that you can also examine the contents of STARTUP_P1 yourself:   * $ IF	F$GETSYI( "STARTUP_P1" ) .NES. "    " $ THEN
 $	(mumble) $ ENDIF    -- s David J. Dachteraa dba DJE Systems- http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------   End of INFO-VAX 2002.374 ************************