1 INFO-VAX	Mon, 12 May 2003	Volume 2003 : Issue 262       Contents:. Re: Alpha FX32 could be itanium 32 bit kludge?) Re: AlphaStation 255/500 power up problem  Another AS 500/266 question B Re: Another Book from Digital Press - Getting Started with OpenVMS, Re: Are Bridgeworks and Multinet compatible? Re: Backup question  can call lib$get_symbol  Re: can call lib$get_symbol 6 Cleanup of system files (was: How to clean audit logs): Re: Cleanup of system files (was: How to clean audit logs). Re: Computerworld: HP continues to support VMS Re: CSWS and PHP extensions A Re: DECnet-Plus (DECnet PhaseV) (DECnet/OSI) migration necessary? A Re: DECnet-Plus (DECnet PhaseV) (DECnet/OSI) migration necessary?   Re: Determining Disk Booted From* Re: determining when a file is closed/open Re: gcc for OpenVMS ! Re: Go to an AS/400 from VAX/VMS? ! Re: Go to an AS/400 from VAX/VMS?  Go to an AS/400 from VAX/VMS? < Re: How Alpha will save Itanium - must reading for Bill Todd< Re: How Alpha will save Itanium - must reading for Bill Todd< Re: How Alpha will save Itanium - must reading for Bill Todd< Re: How Alpha will save Itanium - must reading for Bill Todd< Re: How Alpha will save Itanium - must reading for Bill Todd< Re: How Alpha will save Itanium - must reading for Bill Todd How to clean audit logs  Re: How to clean audit logs  Re: How to clean audit logs  Re: How to clean audit logs 3 Re: HP's 'Adaptive Enterprise' advertising campaign 3 Re: HP's 'Adaptive Enterprise' advertising campaign 3 Re: HP's 'Adaptive Enterprise' advertising campaign 3 Re: HP's 'Adaptive Enterprise' advertising campaign 3 Re: HP's 'Adaptive Enterprise' advertising campaign ; Re: MicroVAX and VAX models EOSL list (end of service life)  Re: Need OpenVMS (any version) Re: next VMS versions  Re: next VMS versions  Re: next VMS versions  Re: next VMS versions  Re: next VMS versions G next VMS versions (was: RE: Computerworld: HP continues to support VMS) K Re: next VMS versions (was: RE: Computerworld: HP continues to support VMS) ' Re: OpenVMS Memory/Performance Question 5 Re: OpenVMS Pearl - VAXscan is now available on Alpha 5 Re: OpenVMS Pearl - VAXscan is now available on Alpha 5 Re: OpenVMS Pearl - VAXscan is now available on Alpha 1 Re: Pinout of power connector on DECserver 90TL ?  vax emulator question  Re: vax emulator question 7 Re: What is the schedule for the DII COE certification? 7 Re: What is the schedule for the DII COE certification? 7 Re: What is the schedule for the DII COE certification?   F ----------------------------------------------------------------------  % Date: Mon, 12 May 2003 16:18:21 +0100 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> 7 Subject: Re: Alpha FX32 could be itanium 32 bit kludge? 0 Message-ID: <b9odvu$22c$1@new-usenet.uk.sun.com>   jlsue wrote:G > On Fri, 09 May 2003 10:14:01 +0100, Andrew Harrison SUNUK Consultancy 0 > <Andrew_No.Harrison_No@nospamn.sun.com> wrote: >=20 >=20 >> >>jlsue wrote: >>J >>>On Wed, 30 Apr 2003 22:59:21 +0200, Arne Vajh=F8j <arne@vajhoej.dk> wr= ote: >>>  >>>  >>>  >>>>Bob Ceculski wrote:  >>>> >>>> >>>>>interesting ... >>>>> / >>>>>http://www.theinquirer.net/?article=3D9175  >>>> >>>>Hm.  >>>>- >>>>Do you remember that FX!32 was a fiasco ?  >>>  >>> J >>>FX!32 was wonderful.  The problem was that MS' OS is a moving target w= hen J >>>you're trying to determine the APIs and entry points.  Oh, and when th= eyJ >>>allow the installation of a *layered product* (e.g., MS Office) to cha= nge & >>>OS files, it's even more difficult. >>>  >>B >>There was a much simpler and entirely non technical problem withF >>FX!32 which will probably be the death of the Intel project as well. >> >>ISV support. >> >>[snip for brevity...]  >=20 >=20J > Oh, I totally agree there.  I was thinking more in technical terms in m= y  > response.  >=20G > But you are absolutely right.  Getting ISVs to support the translated J > images is also very important.  And this would happen if customer deman= d H > was there.  I'm not sure we ever marketed it well enough to get anyone > interested in full support.  >=20    B But this is the catch 22. FX!32 existed precisely because customerF demand didn't materialise and exactly the same scenario is now playing itself out with Itanium.  @ Intel ISV's don't want to port to Itanium because they cannot at' less than 25K systems PA see the point.   6 Intel does FX!64 in response to this lack of interest.  : Customers only get support if Intel can persuade ISV's who8 could not be bothered to do the port plus the regression2 testing etc to just do the regression testing etc.   There is a further parallel.  9 Intel like Digital got to where they are in the market by ? producing generations of processors that were highly compatible ; with the previous ones. Intel with IA-32, Digital with VAX.   < Intel like Digital has never had to go out an woo, cajole or+ bully ISV's into supporting their platform.   ? Digital introduced Alpha, Intel introduced IA-64, suddenly both ? vendors had a software portfolio supporting their platform with = very very little in it. Suddenly ISV's who for years could be ; allowed to do their own thing become people who need wining  and dining.    Regards  Andrew Harrison    ------------------------------  % Date: Mon, 12 May 2003 13:03:59 -0400 0 From: "Alan Boyles" <alan.boyles@mindspring.com>2 Subject: Re: AlphaStation 255/500 power up problem/ Message-ID: <vbvkue2dvlem7a@corp.supernews.com>   L Anybody know what the part number is for a AlphaStation 500 power supply is?K I pulled the power supply and it is a Magnetek with a 3617-xxx number but I J can't find anything on their web site with that number and the SOC Archive? on the HP site doesn't give a part number for the power supply.    Alan; "Alan Boyles" <alan.boyles@mindspring.com> wrote in message ) news:vbpk74sin2cg2e@corp.supernews.com...  > Group: > G > I have just received 2 AlphaStations (a 255/400 and a 255/500) and am  havingJ > some problems.  When I try to turn either of the boxes on they will veryI > briefly run, maybe half a second to a second and then shut down.  I was I > thinking power supply but I find it strange that both boxes do the same  > thing.  Any ideas ?  >  > Thanks >  > Alan >  >    ------------------------------  % Date: Mon, 12 May 2003 08:22:06 +0200 ( From: "Rudolf Wingert" <win@fom.fgan.de>$ Subject: Another AS 500/266 question: Message-ID: <MDEJJFGEEOPAFONJONBKMEHJDBAA.win@fom.fgan.de>   Hello,  G I do test the Ethernet Adapter with the DTSEND utility. This is a tool, G which you get with your OpenVMS. Normaly I did see about 90% Throughput > (normal and fast Ethernet). There are a few problems possible:  G 1. If you see a very slow performance, look at the interface parameters H    (LANCP SHO DEV/PARA) and at the switch side, what the current values.F    Are both sides equivalence? If not change the interface parameters.G    If they are equal set the values with LANCP to the displayed values. I    Test the performance again. Do you see some difference, set the inter- ,    face and switch parameters to fix values.  J 2. Check the value of PIPELINE QUOTA or its equivalence under DECnet Plus.@    Sometimes to lower this values will speed up the performance.  I 3. If you will have switches with an trunk (hunt group, ...) and you will J    see a performance in the range of 0.2% to 90%, the trunk is the problemH    (we did have this problem). Try to change the trunk to a high perfor-    mance uplink.  I If you will see bad performance independent of the above, you will have a * hardware problem. Call HP service support.   Best regards Rudolf Wingert    ------------------------------  % Date: Mon, 12 May 2003 07:07:32 -0700 . From: "David D Miller" <ddmiller@raytheon.com>K Subject: Re: Another Book from Digital Press - Getting Started with OpenVMS F Message-ID: <OF5BFA9EED.B4C0FE16-ON07256D24.004D6337@rsc.raytheon.com>  ) Not so!  However it has been delayed  ...   K Baldwin's 2nd edition is due out at year's end.  Hoffman started it and I'm 
 finishing it.    dave.      robert heyes wrote ...  J I wanted a Systems Management one from Digital Press and when I rang them," they said it had been cancelled!!!  > "Sue Skonetski" <susan_skonetski@hotmail.com> wrote in message7 news:857e9e41.0305090942.17872454@posting.google.com...  > From: Skonetski, Susan% > Sent: Friday, May 09, 2003 11:43 AM  > To: Skonetski, SusanB > Subject: OpenVMS Pearl to end the week ANOTHER OpenVMS Book from. > Digital Press - Getting Started with OpenVMS >  > C > Another Book from Digital Press, this is great news for everyone.  > 6 > Getting Started with OpenVMS - A Guide for New Users > Written by Michael D. Duffy  > 7 > (this is what it says in part on the back cover, Sue)  > @ > OpenVMS professional have long enjoyed a robust, full-featuredH > operating system suitable for the most mission-critical application inG > existence.  However, many of today graduates may not yet have had the H > opportunity to experience it for themselves.  Intended for an audienceD > with some knowledge of operating systems such as Windows, UNIX andB > Linux, Getting Started with OpenVMS introduces the reader to the > OpenVMS approach.  > D > (there are a few more paragraphs and then about the Author) not to# > mention all around good guy, Sue)  > H > Michael Duffy is a Senior Software Engineer with Process Software LLC,B > where he develops and maintains various components of two TCP/IP? > implementations for OpenVMS.  He has over 15 years of OpenVMS E > experience as a system manager, analyst, and system programmer, and / > has spoken at the DECUS (now HPETS)symposium.  > H > For more details about this book, click on the Digital Press BookstoreB > which is available from http://h71000.www7.hp.com/ Note that theC > Digital Press website includes a tab for users who are outside of  > North America. >  > ISBN:1-55558-279-6 >  > Warm Regards,  > Sue Skonetski  > OpenVMS Engineering    ------------------------------  % Date: Mon, 12 May 2003 14:26:40 -0000 - From: wspencer@ap.nospam.org (Warren Spencer) 5 Subject: Re: Are Bridgeworks and Multinet compatible? 5 Message-ID: <937960576warrenspencer1977@216.168.3.30>   - phil.hudson@compaq.com (Phil Hudson) wrote in & <VSOua.590$SM3.584@news.cpqcorp.net>:    Phil,   G Many thanks for the response. Is there fix planned for the FTP & REXEC   issue?  Time frame?    ws   >Warren, > F >I apologize for the delay in responding to this note. I have been laxH >in monitoring this user group, so your question had to be brought to my >attention.  > * >Anyway, the answer to your question is...H >    Yes, Multinet will work just fine in place of TCP/IP  Services(UCX)D >    at runtime. BridgeWorks generates a runtime connection based onG >    DCE/RPC, which in turn has successfully tested against the various 1 >    TCP/IP stacks out there, including MultiNet.  > ? >The only problem that you may run into is at development time. > >The BridgeWorks UI uses FTP & REXEC to provide the integrated= >build feature, and the automatic importing of the ANA & STDL = >files. The FTP & REXEC clients built into the BridgeWorks UI = >were written with the expectation that UCX based FTP & REXEC A >servers would be on the other end.   It parses the returned data 9 >based on how these UCX utilities return the information.  > A >If this problem does exists, it only means that you will need to A >manually FTP the generated files over to OpenVMS, and build them - >by hand using the generated build procedure.  >  >Phil Hudson >(HP BridgeWorks Engineering)    ------------------------------    Date: 12 May 2003 09:35:50 -0500 From: briggs@encompasserve.org Subject: Re: Backup question3 Message-ID: <XjAJVn63ZaYK@eisner.encompasserve.org>   V In article <3EBC39E9.CCE77DF7@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes: > Dirk Munk wrote:! >> > $mount mka500/override=label 1 >> > $copy mka500:dka200.bck temp_disk:dka200.bck 6 >> > $backup temp_disk:dka200.bck/save/select=etc .... >>  K >> Gooed idea, if it wasn't for the fact that I used a block size of 65024. 4 >> RMS doesn't like anything with record sizes > 32k > O > Could you use CONVERT to "copy" the file from tape to disk while changing its F > block size ? Would that make BACKUP unable to process the save set ?  H No.  Convert won't work.  You may be thinking about tape record blockingG where you have multiple logical records for each block on tape.  BACKUP ; always uses a logical organization of one record per block.   E You may be thinking about something like EXCHANGE which can interpret F one fixed-length record input file as a byte stream and lay the outputA down as a fixed-length record output file with a different record D length.  That wouldn't help.  BACKUP wants its records to be as long# as the BACKUP header says they are.   D You could conceivably use Save Set Manager to reblock the tape.  ButD that pretty much assumes it's a valid save set format to start with.E And if it's a valid format already, there's no point reformatting it.    	John Briggs   ------------------------------  % Date: Mon, 12 May 2003 16:10:11 +0530 4 From: Kesav Tadimeti <Kesav_Tadimeti@KeaneIndia.com>  Subject: can call lib$get_symbol> Message-ID: <8EA11405E59BD611BA7100104B93C26001538FAE@EXDEL01>  
 Hello all,0 I have a small C program to call lib$get_symbol.L The program while compiling can't find where lib$get_symbol is defined. What header file am I missing?  ThanksL ---------------------------------------------------------------------------- ---------------------------    #include <stdio.h> #include descrip #include <string.h>  #include ssdef #include rms void main()  {   char szSymName[50];  char szSymVal[50]; 
  int dStatus; $  struct dsc$descriptor_s strSymName;$  struct  dsc$descriptor_s strSymVal;    strcpy(szSymName,"ss");-  strSymName.dsc$w_length = strlen(szSymName); &  strSymName.dsc$a_pointer = szSymName;(  strSymName.dsc$b_dtype = DSC$K_DTYPE_T;(  strSymName.dsc$b_class = DSC$K_CLASS_S;    strSymVal.dsc$w_length = 99; $  strSymVal.dsc$a_pointer = szSymVal;'  strSymVal.dsc$b_dtype = DSC$K_DTYPE_T; '  strSymVal.dsc$b_class = DSC$K_CLASS_S;   4  dStatus=lib$get_symbol(&szSymName,&szSymVal,0,0);       if (dStatus == SS$_NORMAL) "     printf("Status = %d",dStatus); } L ---------------------------------------------------------------------------- --------------------------- 7 +-----------------------------------------------------+ 0 	KEANE INDIA LIMITED                            0 	E9 - E12, SDF                                  1 	NEPZ, NOIDA 201 305                              0 	U.P, INDIA                                     6                                                       0 	e-mail: kesav_tadimeti@keaneindia.com          0 	phone: +91-120-2568210(371)                    5       Men are from MACs, Women are from VMS           7 +-----------------------------------------------------+  Oh Dad!  We're ALL Devo!   ------------------------------  % Date: Mon, 12 May 2003 11:52:07 +0100 * From: "Richard Brodie" <R.Brodie@rl.ac.uk>$ Subject: Re: can call lib$get_symbol, Message-ID: <b9nuda$143o@newton.cc.rl.ac.uk>  A "Kesav Tadimeti" <Kesav_Tadimeti@KeaneIndia.com> wrote in message 8 news:8EA11405E59BD611BA7100104B93C26001538FAE@EXDEL01...  N > The program while compiling can't find where lib$get_symbol is defined. What > header file am I missing?    lib$routines   ------------------------------  % Date: Mon, 12 May 2003 11:29:39 -0500 ( From: brandon@dalsemi.com (John Brandon)? Subject: Cleanup of system files (was: How to clean audit logs) 1 Message-ID: <03051211293929@dscis6-0.dalsemi.com>   8 "Vic Mendham" <c00per11242001@yahoo.ca> wrote in message7 news:f7a73cb1.0305120731.58c97cf2@posting.google.com...   E > Ok we took control of a clients VAX systems in late 2002, they have E > just been moved over to my team for mgmt. Can anyone tell me how to 8 > reset or clean out the audit logs for a specific date?  5 You may also consider cleanup of these files as well:   
 ACCOUNTNG.DAT 
 ERRLOG.SYS OPERATOR.LOG  I Depending on the demonstrated activity, I clean them up daily, weekly, or 
 monthly.    O I create a new file, rename the previous with a date-time-stamp imbedded in the ? naming convention, then ZIP those files over a period of time.     Just a thought.    John Brandon VMS Systems Administrator  Dallas Semiconductor first.last@dalsemi.com 972.371.4172 wk    ------------------------------  % Date: Mon, 12 May 2003 13:31:07 -0400 ! From: Jim Agnew <jpagnew@vcu.edu> C Subject: Re: Cleanup of system files (was: How to clean audit logs) ' Message-ID: <3EBFDA5B.23E717FA@vcu.edu>   < Especially when a tape drive head start dying... or the tape6 stretches... that can generate error at a rapid rate..   John Brandon wrote:  > : > "Vic Mendham" <c00per11242001@yahoo.ca> wrote in message9 > news:f7a73cb1.0305120731.58c97cf2@posting.google.com...  > G > > Ok we took control of a clients VAX systems in late 2002, they have G > > just been moved over to my team for mgmt. Can anyone tell me how to : > > reset or clean out the audit logs for a specific date? > 7 > You may also consider cleanup of these files as well:  >  > ACCOUNTNG.DAT  > ERRLOG.SYS > OPERATOR.LOG > K > Depending on the demonstrated activity, I clean them up daily, weekly, or 
 > monthly. > Q > I create a new file, rename the previous with a date-time-stamp imbedded in the @ > naming convention, then ZIP those files over a period of time. >  > Just a thought.  >  > John Brandon > VMS Systems Administrator  > Dallas Semiconductor > first.last@dalsemi.com > 972.371.4172 wk    --  F "4,000 years ago I made a mistake."  Elrond Half-Elven, in "Fellowship of the Ring"   ------------------------------  + Date: Mon, 12 May 2003 10:32:06 +0100 (MET) 9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> 7 Subject: Re: Computerworld: HP continues to support VMS ; Message-ID: <01KVSUHCLMFMAM3M2Q@sysdev.deutsche-boerse.com>   5 > 	But I think the idea is to pick up source code and ; > 	compile and create VMS binaries.  keeping costs down and C > 	removing a argument against VMS.  (i.e. source code - no touch).  > : > 	Ideally?  Ground zero write app targeted *specifically*< > 	for VMS and VMS only?  Okay.  Very small number of folks.  I Perhaps.  However, I suspect that the small number of folks running very  D VMS specific stuff, often in combination (with in practice very VMS C specific) Rdb account for a huge chunk of revenue for VMS, layered  I products and hardware to run the stuff on.  A couple more such customers  G would mean a lot more in some sense than a thousand small businesses.   E (Of course, one of the big guys leaving would be a big disadvantage.)    ------------------------------  # Date: Mon, 12 May 2003 15:37:56 GMT 5 From: Matthew Doremus <Matthew.Doremus@hp.com.NoSpam> $ Subject: Re: CSWS and PHP extensions, Message-ID: <3EBFBD8D.4090902@hp.com.NoSpam>   Hi John,  I    The best way to build a PHP extension to work CSWS_PHP is to download  & the sources for CSWS_PHP available at:       N http://h71000.www7.hp.com/openvms/products/ips/apache/csws_source.html#phpdown  (    Let me know if you have any problems.   Thanks,          Matt Doremus    brandon@dalsemi.com wrote:  H >I am running CSWS and PHP and would like to create an extension to PHP. > M >Does anyone have experience with this?  Or can point me to sample code to do  >so? > ' >Appreciate any help with this, thanks!  >  >  > 
 >John Brandon  >VMS Systems Administrator >Dallas Semiconductor  >john.brandon@dalsemi.com  >972.371.4172 wk >972.371.4003 fx >    ------------------------------  % Date: Sun, 11 May 2003 21:55:30 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> J Subject: Re: DECnet-Plus (DECnet PhaseV) (DECnet/OSI) migration necessary?' Message-ID: <3EBF0D22.608BCEFE@fsi.net>    Bob Ceculski wrote:  > [snip]D > Javascript is used by our web/graphics design people ... what else > do you suggest they use?     HTML. It's the web standard.  + > I use some javascripts for my cgi's also,  > why do you hate javascript?    It's not secure.   > It is an industry standard    	 Well, ...    > ... isn't & > that what everyone out there wants?   H Not everyone. Discriminating people know better than to follow the crowd& of lemmings off of Bill Gates's cliff.  " > The history pages will be filledF > when the company wants them to be ... our customers have praised ourD > partners program, a few history pages still under development doesF > not help them manage their business efficiently ... before you buy a4 > car, I certainly hope you check under the hood ...  E Been deceived there, too. Not unusual to find cleaned, coated engines @ and parts under the hood of a used car with 120,000 miles on it.H Everyone who has any business behind the wheel knows an engine with that/ much experience likely does not look like that.    > > Not exactly awe inspiring. > C > what's awe inspiring is that our site has ran now 4 years without B > ever being down, except for a few reboots for hardware/eco's ...A > and that I have developed a bulletproof online ordering/account D > review system thanks to the stability of OpenVMS ... we are alwaysC > there for our customers, and that is surely inspiring to them ... A > what good is a bunch of flashy html code/graphics when the site D > is down or can't get the services you need?  We only answer to ourA > customers ... that is what matters the most ... but we actually E > have another web site we run I am developing now, and it is flashy, ? > and when it is ready, you will see the flashy side of vms ...     Never cared much for flashers...   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------   Date: 12 May 03 09:04:41 +0200) From: p_sture@elias.decus.ch (Paul Sture) J Subject: Re: DECnet-Plus (DECnet PhaseV) (DECnet/OSI) migration necessary?) Message-ID: <QOb$NNAwU6n8@elias.decus.ch>   h In article <d7791aa1.0305110449.7b68739a@posting.google.com>, bob@instantwhip.com (Bob Ceculski) writes:  D > Javascript is used by our web/graphics design people ... what elseE > do you suggest they use?  I use some javascripts for my cgi's also, C > why do you hate javascript?  It is an industry standard ... isn't % > that what everyone out there wants?   A Why do I hate Javascript? Simply because it can be used to try to  take control of _my_ system.  B Think about this example please. About 4-5 years ago I was readingC this newsgroup with Netscape with Javascript enabled. I came across @ a message which slowed my system to a halt and took me to a pageA advertizing cheap PCs. Fortunately I got tired of waiting at that > point and killed Netscape, because as others here subsequently; reported, the Javascript then led to a hard core porn site.   C Now, I have a 21" monitor at work, at that time visible to everyone C in the office, including ladies who would have been deeply offended F had I let it continue. It could done a lot of damage to my reputation.  + That is why I run with Javascript disabled.   @ If you really must use Javascript, please get your guys to learn* how to cater for those with it disabled.    # >  The history pages will be filled F > when the company wants them to be ... our customers have praised ourD > partners program, a few history pages still under development doesF > not help them manage their business efficiently ... before you buy a4 > car, I certainly hope you check under the hood ... > F Just my opinion of course, but it gives a bad impression when I followC a link to find a "Page under construction" message, especially from B a business site. Better to leave the link inactive until the pages
 are in place.  --  
 Paul Sture   ------------------------------  % Date: Mon, 12 May 2003 09:54:04 +0100 * From: "John Travell" <john@travell.uk.net>) Subject: Re: Determining Disk Booted From 5 Message-ID: <b9nnpk$kjklb$1@ID-120847.news.dfncis.de>   . <rob.buxton@wcc.spam.govt.nz> wrote in message news:3ebeebd8.16619117@news...3 > On Fri, 9 May 2003 23:28:04 +0100, "John Travell"  > <john@travell.uk.net> wrote:F > I think this will just show you which is considered to be the ShadowA > Set Master, but not necessarily the device that was booted off.  > F > If you've split and reformed the shadow set since the last boot thenA > the "Master" will simply be the device that was not dismounted.  > A > Some of the f$getdvi lexicals can be used to look at the Device E > Members, but again, these just relate to the shadow sets and do not  > give you what you were after.  > L Comes of trying to answer before I have read the question at least twice :-(   >  > > > > >"Jack Trachtman" <Jack.Trachtman@vmmc.org> wrote in message9 > >news:69d784c4.0305091349.f99ded2@posting.google.com...  > >> [VMS V7.3]  > >>: > >> All our VMS systems have their system disks shadowed. > >>; > >> How can I find out which disk of the pair was actually  > >> used to boot from?  > >>  	 $ ana/sys ( SDA> show device/address=@sys$ar_bootucbA works in V7.3-1, I cannot verify that it works in older versions.      -- John Travell  VMS crashdump expertise for hire john@travell.uk.net  http://www.travell.uk.net/       --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).A Version: 6.0.478 / Virus Database: 275 - Release Date: 06/05/2003    ------------------------------    Date: 12 May 2003 09:26:38 -0500 From: briggs@encompasserve.org3 Subject: Re: determining when a file is closed/open 3 Message-ID: <JHNNK0FBQpzv@eisner.encompasserve.org>   b In article <f56c6aaf.0305091313.2ce110d8@posting.google.com>, jnboomer@yahoo.com (jboomer) writes:@ > Yes, I agree, "locked" is not the same as "open".  So maybe myF > question is what is the default for an open/write.  Will it lock theA > file until it is closed?  Or, as I read the online help, is the A > default "read access" whenever the /share parameter is omitted?   D For a DCL open/write, the default is exclusive write when the /share qualifier is omitted.   E For an open in some other language from some unknown application, one 4 should not assume any particular default, of course.   	John Briggs   ------------------------------  # Date: Mon, 12 May 2003 14:04:39 GMT < From: "John E. Malmberg" <Malmberg@dskwld.zko.dec.compaq.hp> Subject: Re: gcc for OpenVMS/ Message-ID: <XRNva.689$8A7.37@news.cpqcorp.net>    Ian Wing Yin Chung wrote:  >   K > Is there a version of gcc for OpenVMS on VAX machines. If so what is the   > latest version?   L See the OpenVMS FAQ.  Available as a link from http://www.hp.com/go/openvms/   -John ! malmberg@dskwld.zko.dec.compaq.hp  Personal Opinion Only    ------------------------------  % Date: Mon, 12 May 2003 08:51:21 +0200 + From: "Thomas F. Howald" <howag@bluewin.ch> * Subject: Re: Go to an AS/400 from VAX/VMS?* Message-ID: <3EBF4469.7460E7BC@bluewin.ch>   "David J. Dachtera" wrote: >  > Paul Sture wrote:  > > Z > > In article <3EB953F8.638371CB@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes: > > > RC Bryan wrote: L > > >> If I were in your position, I would struggle to find any way to avoidC > > >> the AS400.  You can get a nice Alpha on EBAY that would be a L > > >> substantial step up from your 3100 for under $1000 and get some up to > > >> date software from HPQ  > > > Q > > > But if you APPLICATION vendor has abandonned VMS, not even a marvel machine ) > > > will make that software run on VMS.  > > > R > > > The OS is neat, but for business, it does very little. It is the application > > > that drives the business.   	 How true.  That's why we have to change.   L > > You have it in one JF. The business application is everything. Sometimes; > > our bias towards VMS can get in the way of seeing that.  > H > ...and hp/Q's bias towards non-VMS keeps them from seeing it, as well. >  > -- > David J. Dachtera  > dba DJE Systems  > http://www.djesys.com/ > * > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/    Thomas F. Howald --  H ------------------------------------------------------------------------G T.F. Howald    |It's difficult to soar with eagles,|Ph:+41 32 686 61 86 H Otto Howald AG | when you work with turkeys.| http://www.garagehowald.ch> Engestrasse 13, 4500 Solothurn, Switzerland | howag@bluewin.ch   ------------------------------  % Date: Mon, 12 May 2003 08:58:25 +0200 + From: "Thomas F. Howald" <howag@bluewin.ch> * Subject: Re: Go to an AS/400 from VAX/VMS?* Message-ID: <3EBF4611.F06B312F@bluewin.ch>   "Main, Kerry" wrote: > 	 > Thomas,  > G > As others have stated, the application typically drives the solution, B > but if you are not satisfied with the overall solution, the only$ > alternative is to consider others. > @ > It may not be applicable and is likely to late, but as a fyi - > 3 > http://www.mimer.com/news.asp?secId=176&itemId=81 C > "Australian Auto Dealers Gear Up to Mimer SQL (November 12, 2002)  > D > International automotive IT software developer, Infomedia Ltd fromE > Australia, is planning to utilise the Mimer SQL Engine in their new E > version of a Dealer Management System (DMS) named AutoLedgers. This D > innovative product will initially replace their existing reportingI > sub-system called Info-Centre(TM). Further DBMS integration is planned. H > AutoLedgers is Infomedia's successful automotive dealership managementB > system used today at more than 200 Australian auto dealers sitesG > supporting the range of vehicle manufacturers including Ford, Holden, J > Toyota, Peugeot, BMW, Mercedes, VW, Subaru, Daewoo, Honda, Kia, Hyundai,> > Jaguar, Audi, Nissan, Chrysler, Lexus, Mazda and Mitsubishi. > H > .. Success in the automotive industry has given Infomedia a solid baseI > market and reputation. Its corporate strategy is heavily biased towards J > the utilization of advanced programming technology, product reliability,I > performance accountability and customer service. The new version of the B > Alpha OpenVMS-based AutoLedgers will use Mimer SQL Engine as theI > built-in database management system (DBMS) for reporting functions. The B > Mimer SQL Engine DBMS will be integrated with AutoLedgers on theJ > OpenVMS-platform, replacing a remote SQL Server database and server that# > was used in the current version."  >  > [see rest of url..]  > 	 > Regards  >  > Kerry Main > Senior Consultant  > Hewlett-Packard (Canada) Co.# > Consulting & Integration Services  > Voice: 613-592-4660  > Fax   : 613-591-4477 > Email: kerryDOTmain@hpDOTcom/ >     (remove the DOT's and replace with "."'s) ! > OpenVMS DCL - the original .COM   ? Thanks for the tip but we already had a nice program running on B our MicroVax running 24/365, but not compatible with the people weG have to deal with, our automobile importer. BTW I didn't notice Renault 
 on your list.    Thomas F. Howald     --  H ------------------------------------------------------------------------G T.F. Howald    |It's difficult to soar with eagles,|Ph:+41 32 686 61 86 H Otto Howald AG | when you work with turkeys.| http://www.garagehowald.ch> Engestrasse 13, 4500 Solothurn, Switzerland | howag@bluewin.ch   ------------------------------  % Date: Mon, 12 May 2003 10:57:07 +0200 + From: "Thomas F. Howald" <howag@bluewin.ch> & Subject: Go to an AS/400 from VAX/VMS?* Message-ID: <3EBF61E3.AFB4EC76@bluewin.ch>   jweisen@eisenschmidt.org wrote:      >Hi, I'm FMS, have we met??   8 >Again, both VMS and OS/400 need some work on the menus.  C >For the command line stuff, back to my IBm engineer. He *love* the ? >OS/400 commands (logical, but without vowels), and thinks Unix @ >commands sound like line noise. Unix people like theirs because? >they're short. VMS people like theirs because they make sense.   
 >So you have: / > -logical and can sometimes be shortened (VMS) & > -logical but without vowels (OS/400) > -short (Unix)   5 Without vowels? That brings another story to my mind.   A Just wondering, was OS/400 written in Bosnia? Read on and laugh!     Found on the net some time ago:       "From: khjones@aol.com (KHJones)  9                    CLINTON DEPLOYS VOWELS TO BOSNIA         :          Cities of Sjlbvdnzv, Grzny to Be First Recipients         B Before an emergency joint session of Congress yesterday,President @ Clinton announced US plans to deploy over 75,000  vowels to the C war-tornregion of Bosnia.  The deployment,  the largest of its kind:B in American history, will provide  the region with the critically ? needed letters A,E,I,O and U, and is hoped to render countless e" Bosnian names more pronounceable.   @ "For six years, we have stood by while names like Ygrjvslhv  and@ Tzlynhr and Glrm have been horribly butchered by millions aroundB the world," Clinton said. "Today, the United States must  finally  stand up and say 'Enough.' w  A It is time the people of  Bosnia finally had some vowels in theiro? incomprehensible words. The US is proud to lead the crusade in s this noble endeavour." n  ; The deployment, dubbed "Operation Vowel Storm" by the StateaE Department, is set for early next week, with the Adriatic port citiesn> of Sjlbvdnzv and Grzny slated to be the first recipients. Two A C-130 transport planes, each carrying over 500 24-count boxes of 0& "E's," will fly from Andrews Air ForceC Base across the Atlantic  and airdrop the letters over the cities. u  @ Citizens of Grzny and Sjlbvdnzv eagerly await the arrival of theA vowels. "My God, I do not think we can last another day,"  Trszg aB Grzdnjkln,44, said.  "I have six children and none of them  has a D name that is understandable to me or to anyone else.  Mr.  Clinton, < please send my poor, wretched family just one 'E.' Please."   E Said Sjlbvdnzv resident Grg Hmphrs, 67: "With just a few key letters,p@ I could be George Humphries.  This is my dream." . . . <portions euthanized>   A The airdrop represents the largest deployment of any letter  to aeE foreign country since 1984.  During the summer of that year,  the US E> shipped 92,000 consonants to Ethiopia, providing cities  like A Ouaouoaua, Eaoiiuae,and Aao with vital, life-giving supplies  of  ? L's, S's and T's.  The consonant-relief effort failed, however, B when vast quantities of the letters were intercepted and hoarded  " by violent, gun-toting warlords. "    s   Regards    Thomas F. Howald     --  H ------------------------------------------------------------------------G T.F. Howald    |It's difficult to soar with eagles,|Ph:+41 32 686 61 86 H Otto Howald AG | when you work with turkeys.| http://www.garagehowald.ch> Engestrasse 13, 4500 Solothurn, Switzerland | howag@bluewin.ch   ------------------------------  % Date: Mon, 12 May 2003 01:20:08 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>E Subject: Re: How Alpha will save Itanium - must reading for Bill Todd ( Message-ID: <3EBF2EF9.2945A5B@istop.com>   Rob Young wrote:B >         SuperDome as we know it is old news.  What Hein hints atI >         is next-gen boxes.  HP has had Compaq for a year now, certainlyoC >         the HP+Compaq folks have been burning the midnight oil ona: >         a next-gen box and Hein hints at a next-gen box.  L Superdome may be old news to you, but it is all that HP is willing to offer.K And you have to ask yourself how much time betwene now and the time HP willc. have some IA64-based Superdome to be proud of.  I You have to consider that future Superdome may look incredible by today'stK standards,  but that is not what counts. At the time the new Superdomes are.M released, they won't be compared to today's Superdomes, they will be compared>, against IBM and SUN offerings of that time.   F If IA64 lags today in features, chances are that it will lag tomorrow.J If IBM and SUN already have experience with large systems. Intel is at itsM first generation. IBM and sun are running while Intel is still walking like a( baby.   L Will Intel eventually catch up ? Perhaps. But it may take a much longer timeN that HP or Intel would like to admit. And we're not even discussing the 64 bitT 8086 which may just kill the IA64 before IA64 is old enough to play with the adults.   ------------------------------  % Date: Mon, 12 May 2003 04:54:02 -0400m* From: "Bill Todd" <billtodd@metrocast.net>E Subject: Re: How Alpha will save Itanium - must reading for Bill Toddt2 Message-ID: <YgCdndvyM5yx_CKjXTWcoQ@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:sPGC9yy5yUqe@eisner.encompasserve.org...n@ > In article <I4WdnRo-U46VYyCjXTWcqA@metrocast.net>, "Bill Todd"  <billtodd@metrocast.net> writes: > > < > > "Rob Young" <young_r@encompasserve.org> wrote in message1 > > news:Jj+dR7teY0eX@eisner.encompasserve.org...eC > >> In article <ovqcndxS1b2GNCGjXTWcog@metrocast.net>, "Bill Todd"a$ > > <billtodd@metrocast.net> writes: > >> > >>? > >> > "Rob Young" <young_r@encompasserve.org> wrote in messagep > >> > >> > > >> >>a> > >> >> Additionally, HP has the highest 4-CPU result on tpmC: > >> >I > >> > Quite likely only because IBM doesn't bother submitting scores forr > > systemseJ > >> > that small.  If their 32-processor system scaled perfectly linearly then > > arK > >> > 4-processor version would yield a score of over 85,000 tpmC, so takei > > your > >> > choice: > >> > >>H > >> http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=103042401 > >>* > >> 85000 tpmC is a lot less than 121000. > >cI > > But it's more than twice the 41,142 that you'd get if you scaled down  theoK > > SuperDome configuration linearly to 4 processors, which, of course, waso theo? > > point (not that I'm surprised you failed to understand it).  > >a > ) > You are scaling in the wrong direction.-  K Not at all:  I'm scaling both systems in exactly the same manner to make itoF clear that either the IBM system scales far more linearly than the newK SuperDome system or, if it scales as poorly as the new SuperDome does, thenaH even a *2*-processor POWER4+ system (if they bothered to sell one) wouldG beat a 4-processor Madison box (just as the 32-processor POWER4+ systemh$ beats the 64-processor Madison box).     The 4-CPU Madisonn@ > config is with a chipset that doesn't go higher in CPU counts.  L Which you'll realize is completely irrelevant to the statement I made if youI can ever bring yourself to shut up and study it long enough to understanda it.o  & > SuperDome as we know it is old news.  K Well, it happens to be what you can buy today, so I'd say that judgement is  just a *bit* premature.      What Hein hints at > is next-gen boxes.  K The new Madison TPC-C result *is* on the next-gen box, Rob:  it's using the L new Pinnacles chipset, and you'll be able to buy one this summer (though whyI you'd want to is not clear, given this first glimpse of its performance).r  -   HP has had Compaq for a year now, certainly ; > the HP+Compaq folks have been burning the midnight oil ong2 > a next-gen box and Hein hints at a next-gen box.  L And these are the same two companies whose server groups never figured out -A it's been a decade now - how to catch up with SGI in large-systemrJ configurations, despite running significantly faster processors.  My bet's on another horse.p  
   My point ofA= > course is to show the CPU itself is certainly more powerfule? > than anything currently shipping.  That is if tpmC and SAP SDr > is to be believed.  G The only tpmC figures we have, Rob, show that the 1.7 GHz POWER4+ beatseG Madison using half as many processors, and IBM will ship that processor < before Madison ships.  So while your statement comparing theL not-yet-shipping Madison TPC-C score against those of products that actuallyE *are* shipping today may be correct, it isn't particularly pertinent.t   ...u  C > >> >  either close to linear scaling to large processor counts isfK > >> > possible in this benchmark, which means that SuperDome's scalability  is > > justE > >> > as lousy as a cursory glance makes it appear to be, or the newc POWER4+s > > areeD > >> > likely faster in a 4-processor configuration than Madison is. > >> > > >> > >> Not at all. > >-H > > Yes, Rob - clueless though you obviously are, the above are the only logicalDD > > conclusions one can draw from the existing data:  either the new POWER4+sH > > would be faster in a 4-processor configuration than the new Madisons (butD > > scale somewhat less than linearly to the score they reach in theH > > 32-processor configuration, or, if they were slower in a 4-processorG > > configuration than the new Madisons, they would be scaling close toS linearlyL > > up to 32 processors while SuperDome's scaling was so shitty that despiteG > > HP's performance lead at 4 processors it fell behind by more than aa factorH > > of 2 per processor at 64 processors.  Take a few days if you need to figure > > it out.  > >9 >07 > If you take a hypothetical 85000 for a Power4+ 4-way,PA > that is 21000 per CPU.  21250 * 32 = 680000.  That is the exacteB > number.  Which is impossible.  No architecture scales linerally.> > So your scaling *down* to 85000 for a 4-way is off the mark.E > I'll give you a few days to come up with a better number than 85000 > > for a hypothetical IBM 4-way.  It would do better than that.  I By George, you've finally stumbled across half of the point I was making,t. but apparently failed to recognize it as such.   > ; > Conversely, HP is showing a 121000 number for 4 Madisons.t? > That is 30250 per CPU.  Looking at various architectures fromnF > small CPU counts to larger (obviously across chipsets/architectures)+ > I am seeing 75%-80% scaling 4 to 16 CPUs.d  D I again invite you to provide the raw data you're using to draw thisE conclusion, so we can ascertain whether you have any idea what you'reeI talking about.  Of course, it's also worth pointing out that the realm ofE& interest here is 32 - 64 CPUs, not 16.     Maybe they can't6 > hit 75%.  If they hit 72%, they do better than 680K.  I Hey, perhaps they'll scale *super*-linearly:  wouldn't that be nice?  Butm somehow I doubt it.s   > A > Current SuperDomes are obviously constrained.  As Andrew points = > out, their bandwidth cross-section isn't exactly burning upe2 > the charts - but SuperDome is long in the tooth.  K As I noted above, you're confused, Rob:  the Madison numbers come from HP'swI *new* (Pinnacles) server architecture, not the 'current SuperDomes'.  AndRG from the TPC-C figures they achieve only 53% more performance from each-G doubling in the number of processors - a real-world measurement which IoG suspect people may find considerably more compelling than the unfoundedp) scaling speculations you put forth above.e  / <much more unsubstantiated speculation snipped>l  L > > TPC-C, however, depends heavily on system configuration and tweaking, as IBMoE > > has just demonstrated by improving its 32-processor configurationeI > > performance by 59% with less than a 31% rise in clock rate.  So while H > > Madison's current TPC-C score certainly is substantially higher thanK > > Opteron's, to determine whether Madison is *in fact* 'considerably moresL > > powerful' than Opteron in a 4-processor configuration we'd have to applyL > > similar amounts of expertise to the configuration and equivalent amounts ofK > > hardware (for example, the Opteron configuration used only 294 disks toP@ > > Madison's 468, and only 32 GB of memory to Madison's 64 GB). > >y >m@ > The *presumption* being it was IO bound or memory bound.  More= > than likely CPU bound as they would toss disks at it to geto > a higher number.  G Maybe, maybe not.  I have no idea who set up that TPC-C submission, butUJ unless they got IBM to help them on the sly I strongly suspect that it didI not have anything like the level of tuning expertise that the other TPC-Ch6 submissions we've been discussing (HP's or IBM's) did.  1   Memory is cheap - they would toss memory at it,d" > perhaps it is maxed out however.  L Possibly:  Opteron can support 16 GB/processor, but I'm not sure memory that dense is yet on the market.B     The very reason the Madison-= > config has so much more.  You are touching on a feature butr: > are neglecting to flesh it out.  They didn't stick thoseA > drives in the Madison config because they had room.  They stuck<A > them in there because the Madison could drive them.  After all,w? > extra disks drive up system cost driving down your $/tpmC and>> > doing *nothing* but spinning.  By focusing on the disk count: > you are actually seeing how much more powerful a Madison8 > processor is compared to Opteron - for this benchmark.  G No, I'm identifying what may be a symptom of sub-optimal configuration,oK since by most measurements relevant to TPC-C performance the Opteron box iscK the equal of the Madison box.  FP performance has zero impact on TPC-C, andeK while we don't know Madison's SPECint scores they'll have to scale linearlyeL from McKinley's just to equal Opteron's.  The Opteron box has close to twiceH the memory bandwidth of the Madison box - and doesn't have to share thatE bandwidth with I/O bandwidth as Madison's bus architecture does.  TheuD Opterons do have smaller caches (1 MB vs. 6 MB), but this is largelyI balanced by main-memory latency that is only about 1/3 that of Madison's.K   ...s  L > > Opteron is just getting started, Rob.  Itanic2 has been out in the field fora > > a year,S >MD > Madison isn't even shipping yet.  Power4+ isn't even shipping yet.  ? But both of those are straight-forward enhancements of existingyH architectures, much more so than Opteron, so one can expect the kinds ofH tuning that proved useful on earlier TPC-C submissions to be useful withG them.  IIRC McKinley's 4-processor TPC-C score debuted at under 80K andsK improved significantly more than 10% just a few months later as familiarityaL with tuning increased - and it seems likely that further tuning improvements# accompanied the Madison submission.d  H Aside from performance on floating-point-style code, Itanic just doesn'tH enjoy any real advantage over other architectures, Rob:  the differencesK you're seeing are benchmarketing at its finest rather than anything innate,fJ and if/when other platforms start putting in the same configuration effortL (as IBM just has but Opteron likely has not, PA-RISC probably won't, and EV7I reportedly never will) TPC-C will cease to make Itanic look like anythinge special.  B > In fact, that IBM number hit the streets the day it could.  i.e.E > you can order that Power4+ config 6 months after tpmC publish date.l >cF > > and its TPC-C figures (on the same hardware) have risen noticeablyI > > over that period.  I expect the same of Opteron's as its vendors gaint  > > expertise in benchmarketing.A > >> Power4 same but add SpecInt - for low CPU count comparisons.= > >dL > > POWER4+ (not POWER4) is the competition now, Rob.  And it blew the doors off-L > > Madison in TPC-C (more than twice the performance per processor - and atL > > only about half the power consumption per processor as well) by so large anB > > amount that it is very probable that it would exceed Madison's
 per-processor @ > > performance at the smallest POWER4+ system size IBM ships (8 processors). > >  > ? > Probably not.  But we will never know.  IBM 8-way results for C > a p690 will be rarer than hen's teeth.  After all, that 8-way MCMrA > has a sticker price of $350000.  Even if higher than a mythical-@ > 8-way Madison (doubt it) the $/tpmC would give Madison way tooA > much marketing muscle (that 4-way shows each Madison listing atrC > $9900 an 8-way Madison config shouldn't be that much of a jump ine > per-CPU prices).  G Careful, Rob:  exactly the same observation applies to the major $/tpmCe+ advantage that Opteron enjoys over Madison.9   >B > >>> > >> Who is to say a Madison box isn't lurking in the wings to# > >> make 32-64 CPU results higher?n > >hI > > Well, 'higher' won't quite cut it, at least for SuperDomes (NEC boxes- don't G > > seem to scale quite as poorly):  the SuperDome results will have to  *more)D > > than double* their per-processor performance to match POWER4+'s. > >-# > >   Hein basically hints at that:c > >> > >> > >hL http://groups.google.com/groups?selm=3E63CCD2.9A6E9124%40eps.zko.dec.com&oe= > > UTF-8&output=gplain  > >>K > >> "What the Itanium and it's follow ups needs is a good large SMP SYSTEMb toL > >> be put in and flourish and a good OS and DB to get everything out of itL > >> that is potentially in there. Obviously HP is working on such solutions0 > >> but I can not say when/where/how-many-CPUs. > >TJ > > Pity that HP already owns a world-beating large MP system architecture buto  > > has declared it superfluous. > >r >m: > Yeah, beat a dead drum.  But as others have pointed out,> > NEC, SGI, Fujitsu, IBM, Dell and others are shipping Itanium > servers also.   K But only SGI has shown any promise of the kind of scalable system that HeinlE was hoping for - which, once again, has exactly zero relevance to theoJ original discussion, since only the Itanic systems that *HP* can offer can5 attempt to provide reasonable replacements for Alpha.o   >  > >>D > >> The NEC benchmark is just a stake in the ground. A first step." > >rI > > By that reasoning, the new SuperDome result (with per-processor TPC-Ce> > > performance only 64% of NEC's) is a major step *backward*. > >. > A > Hein wrote that after the SuperDome numbers were published, bute; > you knew that.  An *obviously* if the NEC folks can scale 	 > Madison2  H NEC didn't scale Madison *well*, Rob:  their result just wasn't quite asJ pitiful as HP's was, but still only achieved 62% more performance for each  doubling of the processor count.  9 , anyone else can and as Andrew points out, the SuperDome A > doesn't have world-class bandwidth.  The next-gen box certainly 	 > should.l  J I'm not aware of much information about Pinnacles yet, but as far as TPC-C+ goes what we saw is apparently what we get.g   >e > >> > >>< > >> The inference of course is there is higher numbers than, > >> what NEC demonstrated coming out of HP. > > L > > While it's not surprising that that is *your* inference, Rob, the actualJ > > *implication* of Hein's words is that HP is indeed aware of how poorlyI > > SuperDome scales (it would, after all, be difficult not to be) and is0H > > *trying* to do something about it.  However, since they've had SGI's systems:K > > to copy for the better part of the past decade and failed to do so with3 anyyJ > > apparent success, why anyone would expect them to have any better luck nownL > > is not quite clear:  my guess is that they're waiting for the Alpha team toG > > bail them out (again) 3 or 4 years from now with a server-on-a-chipo productwI > > that eliminates the problem, but feel free to divulge any interestingl serverI > > development in the pipe (that you can substantiate:  your own glowingu but I > > vague expectations aren't particularly interesting to anyone but you)  that I > > might not be aware of. > >o >e5 > Bill, all server vendors ship high-end servers thattC > outperform the prior generation.  Until Sun came up with the 15K,nD > they were stuck with spins of the UE10000 which had its own issues? > (other than Zinc Whiskers).  Obviously, they have a much more- > powerful box.- > < > SuperDome came out Sept 2000, a lifetime in this industry.  8 Funny how you can see why it's unreasonable to measure aG less-than-3-years-old SuperDome against more recently-developed serversTH without allowing for its age but you seem to think that McKinley's roughL equivalence to the 4-year-older Alpha core constitutes some kind of triumph.     Therei@ > has to be a follow-on tuned specifically with Madison in mind, > or one would think.   F Indeed - and we've seen it in Madison's 64-processor TPC-C submission.8 That's likely all she wrote for the next few years, Rob.  (   Either way, their next-gen box will be > an improvement on SuperDome.  0 Apparently not enough of an improvement, though.   >  > >   Wonder how soonn0 > >> the IBM folks will have to eat these words: > > = > > My guess would be never.  Don't forget that next year thex already-leading-K > > POWER boxes get POWER5 processors with SMT and on-chip offload hardwareJ forhF > > another major performance boost, while Itanic2s get - more on-chip cache. > >  >r; > But that will be a while.  After all the Power4+ hardware  > ships Nov 2003.   K The official release of the new IBM servers is the end of this month, Rob -eL well before Madison will appear.  I don't know why they post-dated the TPC-CH availability date, but you might note that the Madison submission did as well (October 23, 2003).  -   Certainly a new HP high-end server shows up > > before then (with similar or later ship dates - but no doubt > well before Power5).  H The new HP high-end server shows up shortly after the new POWER4+ systemH that beats its pants off, Rob.  And next year when POWER5 adds insult toK injury all HP has to counter with is more on-chip cache in Madison II (pluseL the double-Madison multi-chip-module, but with clock rates restricted to 1.1  GHz to keep it from melting...).   ...    > >   Surely they.> > >> are pushing hard to hit 681000 tpmC with 32 Madisons ;-).? > >> Looking at some examples, I'm seeing 75-80 percent scaling ! > >> factor across architectures.b > >sL > > Why not provide the numbers that lead you to this conclusion, Rob?  Then weJ > > can figure out whether you understood the data you're drawing it from. FortJ > > example, some NUMA architectures (such as EV7, POWER4/4+, SPARC in its large I > > boxes, SGI's boxes, and, within its glueless MP range, Opteron) scaledJ > > considerably better than that, while other server architectures (e.g.,4 > > bus-structured ones) tend to have more problems. > >pI > > The only examples we have of Madison's scaling are the 4-processor HPnG > > result, the 32-processor NEC result that yields only a 4.25x higher  score L > > using 8x as many processors, and the pitiful 64-processor HP result that yiewK > > lds only a 5.44x higher score using 16x as many processors.  That worksy out L > > to a performance improvement of 62% for each doubling of processor count foraL > > the NEC case and only a 53% performance improvement for each doubling of+ > > processor count for the SuperDome case.o > >/ >oC > Exactly.  And one would suppose a next-gen box would scale better0' > than NEC's current shipping hardware.e  J One might, if one did not realize that the above HP numbers *are* from the 'next-gen box'.b     You are presuming that% > you need on-chip switches to scale.3  ; Not quite, since I recognize that SGI manages without them.e     Not so.  IBM doesn't haveu > them.p  K Perhaps not technically, but some of the chip support for MCMs and multiplerD MCMs provides similar functionality.  What they *definitely* have isK scalable bandwidth with minimal local/remote memory latency differences, byh/ virtue of the per-MCM main-memory architecture.t   > + > >   Ideally, an HP 32 next-gen box should  > >> be able tosC > >> get 720K to 760K tpmC *if* their 4-way result is any indicatort > >aG > > But of course it has already proven *not* to be any indicator, Rob:tH > > expecting anything that close to linear scaling out of HP servers is pureL > > wishful thinking until there's at least *some* kind of evidence to point to> > > that they've found a way to get their server act together. > >  >1@ > That isn't linear.  32 * 30250 would be linear or 900000 tpmC. > 720K is assuming 75% scaling.e  J And the unfortunate *reality* is that at 64 processors linear scaling fromK the 4-processor result would yield 1936K tpmC, while in fact what we see isa2 658K tpmC - about 34% scaling in your terminology.   >o= > >> (the CPU is certainly capable of it - let's see how theys> > >> did on their next gen box.  Bet it has higher bandwidth). > >rL > > Any time you have anything more substantial than your own hopes to offer up, & > > Rob, I'll be happy to evaluate it. > >f >iD > Name a high-end server vendor that shipped a next-gen high-end box1 > that didn't outperform the previous generation.i  D Well, the Madison result *does* out-perform the 64-processor PA-RISCK previous-generation figure by a considerable amount.  But that seems to saynL more about the inadequacy of the previous generation than anything very good about the new one.   - bill   ------------------------------    Date: 12 May 2003 07:50:00 -0700' From: icerq4a@spray.se (David Svensson) E Subject: Re: How Alpha will save Itanium - must reading for Bill Todd@= Message-ID: <734da31c.0305120650.5e184985@posting.google.com>.  8 "Bill Todd" <billtodd@metrocast.net> wrote in message > M > The new Madison TPC-C result *is* on the next-gen box, Rob:  it's using theeN > new Pinnacles chipset, and you'll be able to buy one this summer (though whyK > you'd want to is not clear, given this first glimpse of its performance).o >   F The Superdome is a nice machine with very good performance, and I knowC many who would like to buy these. You don't have to be number 1 all C the time! Companies which replace a 4 year old high-end server will 6 get a good increase in performance with the Superdome.   ------------------------------    Date: 12 May 2003 11:52:27 -0500+ From: young_r@encompasserve.org (Rob Young)oE Subject: Re: How Alpha will save Itanium - must reading for Bill Todde3 Message-ID: <e+RmSjL9M2ji@eisner.encompasserve.org>s  U In article <3EBF2EF9.2945A5B@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes:a > Rob Young wrote:C >>         SuperDome as we know it is old news.  What Hein hints at@J >>         is next-gen boxes.  HP has had Compaq for a year now, certainlyD >>         the HP+Compaq folks have been burning the midnight oil on; >>         a next-gen box and Hein hints at a next-gen box.i > N > Superdome may be old news to you, but it is all that HP is willing to offer.  A 	Doesn't change the fact that it is old news, introed Sept. 2000.5   				Rob-   ------------------------------  % Date: Mon, 12 May 2003 17:53:49 +0100gO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>gE Subject: Re: How Alpha will save Itanium - must reading for Bill Todd00 Message-ID: <b9ojiu$444$1@new-usenet.uk.sun.com>   David Svensson wrote::: > "Bill Todd" <billtodd@metrocast.net> wrote in message >  > M >>The new Madison TPC-C result *is* on the next-gen box, Rob:  it's using theiN >>new Pinnacles chipset, and you'll be able to buy one this summer (though whyK >>you'd want to is not clear, given this first glimpse of its performance).h >> >  > H > The Superdome is a nice machine with very good performance, and I knowE > many who would like to buy these. You don't have to be number 1 allsE > the time! Companies which replace a 4 year old high-end server will-8 > get a good increase in performance with the Superdome.   Humm  C Except that the new shiny SuperDome with Itanium III in is probablyfC about the same speed as the SuperDome with the next HP-PA processori in.n  A Now given that the 1 GHz HP-PA processor has things like softwarem> available for it and you don't need to migrate off anything toA get to it why would you bother with Itanium III based SuperDomes.   @ HP-PA even runs 32 bits apps well and you can even do it without. having to run them through a binary converter.  B Now if HP had come out with a replacement for the Dome with a halfA decent backplane, I/O etc and put Itanium III in it then that may6' have been interesting, but they didn't.e  @ Currently the F15K has ~2x the bisectional bandwidth of the Dome= the P690 slightly higher but half the CPU's. Putting the Domee in the rather tired category.   > In fact HP's execution on Enterprise IA-64 based systems is so> bad that despite the fact that they helped design IA-64 it was= after all their high end replacement for HP-PA they have beene< beaten to the market by Unisys, NEC and SGI with large scale IA-64 systems.   RegardsI Andrew Harrison    ------------------------------    Date: 12 May 2003 12:43:34 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) E Subject: Re: How Alpha will save Itanium - must reading for Bill Toddt3 Message-ID: <MO+wahSDgfOX@eisner.encompasserve.org>a   In article <b9ojiu$444$1@new-usenet.uk.sun.com>, Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes:  C > Now given that the 1 GHz HP-PA processor has things like softwaret@ > available for it and you don't need to migrate off anything toC > get to it why would you bother with Itanium III based SuperDomes.   G The PA-RISC machine does not have VMS available for it, and never will. N What software does, or will, run on Unix is not the concern of this newsgroup.   ------------------------------    Date: 12 May 2003 08:31:00 -0700+ From: c00per11242001@yahoo.ca (Vic Mendham)y  Subject: How to clean audit logs= Message-ID: <f7a73cb1.0305120731.58c97cf2@posting.google.com>   C Ok we took control of a clients VAX systems in late 2002, they have C just been moved over to my team for mgmt. Can anyone tell me how to A reset or clean out the audit logs for a specific date? We want to C start collecting/gathering audit info from when we started managingeB the systems. Can this be done or do we have to reset the audit and lose all data?   ------------------------------  % Date: Mon, 12 May 2003 11:59:26 -0400t< From: "Peter Weaver" <WeaverConsultingServices@sympatico.ca>$ Subject: Re: How to clean audit logs5 Message-ID: <b9ogd2$letgp$1@ID-141708.news.dfncis.de>t   Vic Mendham wrote:; > Ok we took control of a clients VAX systems in late 2002,p	 they havei> > just been moved over to my team for mgmt. Can anyone tell me how to; > reset or clean out the audit logs for a specific date? Wee want tog< > start collecting/gathering audit info from when we started managing: > the systems. Can this be done or do we have to reset the	 audit and  > lose all data?  > I have not tested the syntax, but it should be something like;   $ SET AUDIT/SERVER=NEW_LOG2 $ ANA/AUDIT /BINARY /SINCE=date_time_we_tookover -   /OUTPUT= -=   SYS$MANAGER:SECURITY_SINCE_WE_TOOK_OVER_UNTIL_12_MAY_2003 -g'   SYS$MANAGER:SECURITY.AUDIT$JOURNAL;-1o  : Then you can purge off SYS$MANAGER:SECURITY.AUDIT$JOURNAL.   -- Peter Weaver Weaver Consulting Services Inc.i) Serving Southern Ontario/Western New Yorke   ------------------------------  % Date: Mon, 12 May 2003 16:51:27 +0100 * From: "Richard Brodie" <R.Brodie@rl.ac.uk>$ Subject: Re: How to clean audit logs+ Message-ID: <b9ofu2$hno@newton.cc.rl.ac.uk>.  8 "Vic Mendham" <c00per11242001@yahoo.ca> wrote in message7 news:f7a73cb1.0305120731.58c97cf2@posting.google.com...a  E > Ok we took control of a clients VAX systems in late 2002, they haveME > just been moved over to my team for mgmt. Can anyone tell me how toc8 > reset or clean out the audit logs for a specific date?  D You can use the binary qualifier on ANALYZE/AUDIT to split logs, andK its wildcard support to merge them. I guess you could stop the audit serveroL and clean the current audit log that way, although my preference would be toK routinely start a new log (say monthly) in which case you could tidy up the"( historical data at the end of the month.   ------------------------------  % Date: Mon, 12 May 2003 13:37:40 -0400i+ From: "Martin O'Connor" <moconnor@dvfs.com>h$ Subject: Re: How to clean audit logs5 Message-ID: <b9om56$l930t$1@ID-118202.news.dfncis.de>y  G "Peter Weaver" <WeaverConsultingServices@sympatico.ca> wrote in message-/ news:b9ogd2$letgp$1@ID-141708.news.dfncis.de...l : Vic Mendham wrote: :o : $ SET AUDIT/SERVER=NEW_LOG4 : $ ANA/AUDIT /BINARY /SINCE=date_time_we_tookover - :   /OUTPUT= -? :   SYS$MANAGER:SECURITY_SINCE_WE_TOOK_OVER_UNTIL_12_MAY_2003 -l) :   SYS$MANAGER:SECURITY.AUDIT$JOURNAL;-1  :a< : Then you can purge off SYS$MANAGER:SECURITY.AUDIT$JOURNAL. :o :@c We use a job that run just after midnight on the first of each month to not only create a new auditwd file but also OPERATOR.LOG, ACCOUNTNG.DAT, ERROR.SYS and several other application specific log/data_ files. The old files are collected and renamed to include the month and year and thern moved toO` another disk. Sometimes there may be multiple versions of a type of file (e.g. OPERATOR.LOG) andd they can either be appended into one file or use the utility itself to copy all the entries for that month before moving them.d   Martyt   ------------------------------  % Date: Mon, 12 May 2003 09:45:18 +0100(O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>g< Subject: Re: HP's 'Adaptive Enterprise' advertising campaign0 Message-ID: <b9nmv0$m8m$1@new-usenet.uk.sun.com>   David J. Dachtera wrote: > John Smith wrote:O > E >>Watch for the start of a huge advertising campaign by HP later thissF >>month focused around the "Adaptive Enterprise" ( as described in theG >>carly web festival earlier this week). The advertising trade rags aree# >>full of buzz about this campaign.  >>F >>Sharpen your pencils to keep score of how much exposure (if any) VMS7 >>gets in this campaign relative to other HP offerings.O >  > D > Funny you should mention that. This appeared in my inbox just this > eve... >  > HP VISION SHORT ON EXPERIENCEs > * > Posted May 09, 2003 3:00 AM Pacific Time > : > Hewlett-Packard calls it the Adaptive Enterprise, but in< > reality it's an elaborate strategy that's long on business7 > process re-engineering vision and short on real-worldd
 > experience.  > = > The Palo Alto, Calif.-based company has found itself in the ; > uncomfortable position of recasting technology strategiesr= > already articulated ad nauseam by competitors including IBMn > and Sun, critics observed. >   > Even worse than that UDC which is the key technology component8 of the Adaptive Enterprise is not even based on HP's own technology.0  / Its based on Terraspring which is owned by Sun.s  5 So when HP say it works we did it, they actually meanu, it works and we bought it from someone else.  7 Incedentally don't hold your breath for UDC support forc5 OpenVMS. HP do a better job of supporting Solaris and  Windows than OpenVMS with UDC.  : Apart from UDC and some OS virtualisation technologies the/ rest of Adaptive Enterprise is mostly services.    Regards  Andrew Harrison  >  > For the full story: = > http://www.infoworld.com/article/03/05/09/19NNhpwrap_1.htmlg >    ------------------------------  % Date: Mon, 12 May 2003 08:23:54 -0700e9 From: "gregc at gregcagle.com" <"gregc at gregcagle.com">g< Subject: Re: HP's 'Adaptive Enterprise' advertising campaign/ Message-ID: <vbvf5cajdhl550@corp.supernews.com>i  ( Andrew Harrison SUNUK Consultancy wrote:  @ > Even worse than that UDC which is the key technology component: > of the Adaptive Enterprise is not even based on HP's own
 > technology.  > 1 > Its based on Terraspring which is owned by Sun.w  ! Do you have a reference for this?s   -- a
 Greg Cagle gregc at gregcagle dot com   ------------------------------  % Date: Mon, 12 May 2003 17:11:20 +0100uO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> < Subject: Re: HP's 'Adaptive Enterprise' advertising campaign0 Message-ID: <b9oh38$395$1@new-usenet.uk.sun.com>   gregc at gregcagle.com wrote:o* > Andrew Harrison SUNUK Consultancy wrote: > A >> Even worse than that UDC which is the key technology componentm; >> of the Adaptive Enterprise is not even based on HP's own@ >> technology. >>2 >> Its based on Terraspring which is owned by Sun. >  > # > Do you have a reference for this?- >     6 Which bit, Terraspring being owned by Sun or UDC being based on Terraspring.   7 Sun's purchase of Terraspring has been widely reported.n  8 UDC being based on Terraspring. Its based on Terraspring$ 1.0 which HP OEM'd from Terraspring.  W http://www.computerworld.com/databasetopics/data/datacenter/story/0,10801,75989,00.htmlP   http://216.239.39.104/search?q=cache:DC0nEM5sVN4C:www.the451.com/avantgo/lite/index.php+Terraspring+HP+Utility+Datacenter&hl=en&ie=UTF-8    E Strangely the UI for UDC and Sun N1 Blades Edition (Terraspring) are eE almost identical, not that strange when you realise the that N1 bladee? edition is based on a newer version of the Terraspring product.t   Regardst Andrew Harrison    ------------------------------  % Date: Mon, 12 May 2003 09:37:36 -0700g9 From: "gregc at gregcagle.com" <"gregc at gregcagle.com">r< Subject: Re: HP's 'Adaptive Enterprise' advertising campaign/ Message-ID: <vbvjfijloh5o94@corp.supernews.com>t  ( Andrew Harrison SUNUK Consultancy wrote: > gregc at gregcagle.com wrote:v > + >> Andrew Harrison SUNUK Consultancy wrote:l >>B >>> Even worse than that UDC which is the key technology component< >>> of the Adaptive Enterprise is not even based on HP's own >>> technology.o  ? Lots of people have products not based on their own technology.i# Even Sun. Is that such a bad thing?s   >>> 3 >>> Its based on Terraspring which is owned by Sun.   : You actually meant to say "now owned by Sun" - Terraspring8 was independent when UDC was designed. You make it sound% like Sun owned Terraspring all along.    -- d
 Greg Cagle gregc at gregcagle dot com   ------------------------------  # Date: Mon, 12 May 2003 17:12:26 GMTe4 From: brad@.gateway.2wire.net (Bradford J. Hamilton)< Subject: Re: HP's 'Adaptive Enterprise' advertising campaign. Message-ID: <_BQva.821723$L1.237269@sccrnsc02>   In article <b9oh38$395$1@new-usenet.uk.sun.com>, Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes: <snip>9 >UDC being based on Terraspring. Its based on Terraspring % >1.0 which HP OEM'd from Terraspring.  >>X >http://www.computerworld.com/databasetopics/data/datacenter/story/0,10801,75989,00.html  + To quote from the above-referenced article:r  M In addition, Sun on Friday acquired virtualization software maker Terraspring.L Inc. Some of the software from Terraspring is used in HP's utility computing technology, Haff said.  O "None of this happens with the flick of a magic switch, but it does happen over  time," Haff said.   O To a layman like me, "Some of the software from Terraspring..." does not amountt8 to a full-blown birth of one product from the other.	:-)     >o >http://216.239.39.104/search?q=cache:DC0nEM5sVN4C:www.the451.com/avantgo/lite/index.php+Terraspring+HP+Utility+Datacenter&hl=en&ie=UTF-8h    Another quote from this article:  > (Think Dynamics adds storage for system-wide resource pooling)G HP's utility datacenter software currently uses an older version of theb% Terraspring software Sun now offers. o  M An offhand comment from an analyst critiquing a different product.  Hearsay??s  D I've seen nothing compelling here to back the supposition presented.   >s > F >Strangely the UI for UDC and Sun N1 Blades Edition (Terraspring) are F >almost identical, not that strange when you realise the that N1 blade@ >edition is based on a newer version of the Terraspring product. >i >Regards >Andrew Harrison >e  A _________________________________________________________________a0 Bradford J. Hamilton			"All opinions are my own"/ bMradAhamiPltSon@atMtAbi.cPoSm		"Lose the MAPS"s   ------------------------------  # Date: Mon, 12 May 2003 13:48:12 GMTy& From: Woland <weiland@no.spam.post.cz>D Subject: Re: MicroVAX and VAX models EOSL list (end of service life)< Message-ID: <Xns93799F10E2571weilandatpostcz@16.105.248.153>  B > Also, Compaq and HP knew that they couldn't kill VMS outright so@ > quickly because they need the revenus to help prop up their PC> > operations. Remember that since the merger, the "enterprise"= > business has been losing money (until last quarter where itr > started to pickup again).  >  ...f   > B > At this point in time, I wouldn't be surprised if as soon as VMS> > is commercially available on IA64, that they will declare itD > "mature" on both Alpha and IA64, and customers will still continue: > to be able to run the same version of VMS with little/noD > improvements for many years on whatever IA64 boxes HP continues to	 > build. M   Hmm.. it makes sense. Very sad.M  E BTW, does anybody know about some estimate expenses for Alpha ->IA64 d port ?   Jirkaa   ------------------------------  # Date: Mon, 12 May 2003 12:50:34 GMTc& From: Woland <weiland@no.spam.post.cz>' Subject: Re: Need OpenVMS (any version)a< Message-ID: <Xns9379954C1D2ECweilandatpostcz@16.105.248.153>  # "Leiv" <leiv@hotmail.com> wrote in c2 news:BNSua.617113$0M1.632599@telenews.teleline.es:  7 > anyone wanna trade I have several things to offer....  >  > thanks >  >  >   < Hey, that's good. Imagine the OpenVMS on a warez server :-))   Woland   ------------------------------  + Date: Mon, 12 May 2003 11:18:30 +0100 (MET) 9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>i Subject: Re: next VMS versions; Message-ID: <01KVSW3ZNJ2MAKVGCS@sysdev.deutsche-boerse.com>h  E > I haven't looked at the VAX side of things for quite some time, buttD > I'm on Alpha 7.3-1 at both home and work (some systems still to be > upgraded).  F Right.  I guess my question is, should I move from 7.2-1 to 7.3-1, or I wait until 7.3-2 (presumably the last alpha-only version)?  What will be sH the last "VAX-only" version?  Is there 7.3 VAX?  7.3-1?  7.3-2?  (IIRC, % there was no 7.2-1 for VAX, just 7.2)r   ------------------------------   Date: 12 May 03 12:02:14 +0200) From: p_sture@elias.decus.ch (Paul Sture)y Subject: Re: next VMS versions) Message-ID: <eyrKZ0tapNL9@elias.decus.ch>2  w In article <01KVSW3ZNJ2MAKVGCS@sysdev.deutsche-boerse.com>, Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> writes:*F >> I haven't looked at the VAX side of things for quite some time, butE >> I'm on Alpha 7.3-1 at both home and work (some systems still to be 
 >> upgraded).t > H > Right.  I guess my question is, should I move from 7.2-1 to 7.3-1, or K > wait until 7.3-2 (presumably the last alpha-only version)?  What will be rJ > the last "VAX-only" version?  Is there 7.3 VAX?  7.3-1?  7.3-2?  (IIRC, ' > there was no 7.2-1 for VAX, just 7.2)n  F I see from the VAX patch tree that 7.3 appears to be the latest there.  . http://ftp1.support.compaq.com/public/vms/vax/  H On the Alpha side, at home I have been running 7.3-1 since October. WithB the XFC fixes and other performance improvements that came with itE one of my software builds is significantly faster, and our production @ guys report a healthy performance improvement from that upgrade.  - Those improvements are what settle it for me..   From:  http://groups.google.ch/groups?hl=de&lr=&ie=UTF-8&threadm=Mwwta.268%24w87.3%40news.cpqcorp.net&rnum=2&prev=/groups%3Fhl%3Dde%26lr%3D%26ie%3DISO-8859-1%26q%3Dcomp.os.vms%2Bdii%2Bcoe%26btnG%3DGoogle%2BSuche   Fred Kleinsorge says this:  ; "The changes that were made in the OS and several librarieseE are being integrated into the next V7.3-* release of OpenVMS, and thenF DII/COE Kernel is being moved to the new version of the OS and will beL retested.  The new release of the DII/COE Kernel availability is anticipated! to be early next calendar year. "-  H Now, some snippet of information, though I don't remember precisely whatD has led me to believe we will get 7.3-2 in autumn 2003. The roadmaps= on the VMS site also indicate that 7.3-2 will arrive in 2003.,  w   -- e
 Paul Sture   ------------------------------  % Date: Mon, 12 May 2003 11:36:20 +0100 * From: "John Travell" <john@travell.uk.net> Subject: Re: next VMS versions5 Message-ID: <b9ntfa$l76t0$1@ID-120847.news.dfncis.de>o  F "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message5 news:01KVSW3ZNJ2MAKVGCS@sysdev.deutsche-boerse.com...rG > > I haven't looked at the VAX side of things for quite some time, butdF > > I'm on Alpha 7.3-1 at both home and work (some systems still to be > > upgraded). >sG > Right.  I guess my question is, should I move from 7.2-1 to 7.3-1, ordJ > wait until 7.3-2 (presumably the last alpha-only version)?  What will beI > the last "VAX-only" version?  Is there 7.3 VAX?  7.3-1?  7.3-2?  (IIRC, ' > there was no 7.2-1 for VAX, just 7.2)s  ) The last "VAX only" version was V5.5-2H4.aH Think about it... All subsequent versions of OpenVMS VAX have also had a version for Alpha.I There have been a number of minor 'dash' versions for Alpha that have note had equivalent VAX versions.J According to the engineering folks at the INFOSEC exhibition there will be= another Alpha only 'dash' version released this year, V7.3-2.hL This will allegedly be the last "Alpha only" release, and effectively be the last variant of V7.m= V8.0 and V8.1 will be Itanic only. V8.2 will be tri-platform. K After that there are expected to be dual-platform (Alpha and Itanic) 'dash'rK releases, e.g V8.2-1. Note that there is no guarantee that engineering willo, actually release a version with that number.K I am not aware of any plans that specify the last version that will includei a VAX release.     -- John Travell  VMS crashdump expertise for hire john@travell.uk.neto http://www.travell.uk.net/       ---u& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).A Version: 6.0.478 / Virus Database: 275 - Release Date: 06/05/2003i   ------------------------------  + Date: Mon, 12 May 2003 12:51:40 +0100 (MET)b9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>e Subject: Re: next VMS versions; Message-ID: <01KVSZ1CJE3KAKVGCS@sysdev.deutsche-boerse.com>l  I > > > I haven't looked at the VAX side of things for quite some time, but H > > > I'm on Alpha 7.3-1 at both home and work (some systems still to be > > > upgraded). > >hI > > Right.  I guess my question is, should I move from 7.2-1 to 7.3-1, orsL > > wait until 7.3-2 (presumably the last alpha-only version)?  What will beK > > the last "VAX-only" version?  Is there 7.3 VAX?  7.3-1?  7.3-2?  (IIRC,s) > > there was no 7.2-1 for VAX, just 7.2)u > + > The last "VAX only" version was V5.5-2H4. J > Think about it... All subsequent versions of OpenVMS VAX have also had a > version for Alpha.  H Of course.  That's why I added the quotes.  Perhaps I should have added I a smiley.  :-)  Since there WILL BE new VAX releases, I found it strange iA that 7.3-2 is being touted as the last "Alpha only" release.  :-)s  K > There have been a number of minor 'dash' versions for Alpha that have not  > had equivalent VAX versions.   Right.  L > According to the engineering folks at the INFOSEC exhibition there will be? > another Alpha only 'dash' version released this year, V7.3-2.t  I Yes.  I did find some information about 7.3-2 in the "rolling roadmaps". cH (Had to download the source since the slides weren't readable.)  Except G for stuff in the title pages, I didn't see any specific mention of VAX n	 releases.m  F I definitely want to go to 7.3-2.  Particularly interesting for me is I the fact that HBVS doesn't require same-size disks anymore.  Also, TCPIP  G 5.4 looks interesting.  Thus, I'm debating whether to go to 7.3-1 soon eG and then to 7.3-2 a bit later than as early as possible, or wait until o- 7.3-2 comes out and then go to that directly.   G Can I go from 7.2-1 to 7.3-2 directly?  From 7.2-1 to 7.3-1 directly?  e; Can I go from TCPIP 5.0A to 5.4 directly?  To 5.3 directly?   G It seems to me that there should be a) an upgrade matrix and b) a briefC> description of what versions of what main products (OS, TCPIP,H compilers, DECwindows) will be released when which one can quickly find D from the web site.  I like to get a CD distribution and upgrade OS, I layered products etc more or less at the same time.  I also like to keep tF ALPHA and VAX in sync as much as possible.  Thus, it would be nice to , know what versions of what will appear when.  N > This will allegedly be the last "Alpha only" release, and effectively be the > last variant of V7.   I OK, sounds like a safe landing zone.  If I can go to it directly, I just  H have to decide whether to go through 7.3-1 (or 7.2-2 or whatever) first.  G I'd still like to know what is after 7.2 and before and before 8.0 for mG VAX, also what versions of TCPIP and compilers will be released at the n
 same time.   ------------------------------  % Date: Mon, 12 May 2003 13:19:06 +0200t. From: Maarten van Tilburg <maartent@yahoo.com> Subject: Re: next VMS versions) Message-ID: <3EBF832A.56A9D198@yahoo.com>    Phillip Helbig wrote:t > G > > I haven't looked at the VAX side of things for quite some time, butlF > > I'm on Alpha 7.3-1 at both home and work (some systems still to be > > upgraded). > G > Right.  I guess my question is, should I move from 7.2-1 to 7.3-1, ornJ > wait until 7.3-2 (presumably the last alpha-only version)?  What will beI > the last "VAX-only" version?  Is there 7.3 VAX?  7.3-1?  7.3-2?  (IIRC,o' > there was no 7.2-1 for VAX, just 7.2)c  F I understood that the upcoming (Q3/Q4) 7.3-2 alpha version will be theH consolidated version for the IPF port. The preferred "landing zone", and' with a bunch of ECO's already in place.oE Yes, there is VAX 7.3 , and no, there will not be VAX7.3-x AFAIK, not  many ECO's to install either.n   ------------------------------  + Date: Mon, 12 May 2003 10:38:38 +0100 (MET)t9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> P Subject: next VMS versions (was: RE: Computerworld: HP continues to support VMS); Message-ID: <01KVSUNIRBYWAM3M2Q@sysdev.deutsche-boerse.com>i  H > Well, HP has already states plans for VMS 7.3-2 and 8.2 on alpha.  TheJ > dealer is either confused or a liar.  V7.3-2 will be the last Alpha-onlyH > release, from what I have heard.  8.0 and 8.1 will be "early" releasesH > for IA64 (similar to 1.0 and 1.5 on alpha), and then starting with 8.2? > Alpha and IPF VMS will be released together.  None of this isr  > particularly new information.   A My hobbyist cluster is at 7.2-1 (ALPHA) and 7.2 (VAX).  I want to F upgrade soon.  What do folks recommend?  For ALPHA?  For VAX?  I wouldB rather wait A BIT and upgrade to a version which will be supportedH (downloadable patches) longer, especially since there will probably be a- longer than normal wait until 8.2 comes out. r  ? > Alpha and IPF VMS will be released together.  None of this isc  > particularly new information.   H I seem to recall that there would be at least one version for ALPHA and H VAX and IPF.  Is that still planned?  If HP wants to keep folks who are 8 now on VAX by moving them to IPF, then I think having a F mixed-architecture VAX-IPF cluster would be much more attractive than ( having to use ALPHA as a stepping stone.   ------------------------------   Date: 12 May 03 10:55:15 +0200) From: p_sture@elias.decus.ch (Paul Sture) T Subject: Re: next VMS versions (was: RE: Computerworld: HP continues to support VMS)) Message-ID: <sXg4WmoBJ9c7@elias.decus.ch>n  w In article <01KVSUNIRBYWAM3M2Q@sysdev.deutsche-boerse.com>, Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> writes:mI >> Well, HP has already states plans for VMS 7.3-2 and 8.2 on alpha.  TheoK >> dealer is either confused or a liar.  V7.3-2 will be the last Alpha-onlyaI >> release, from what I have heard.  8.0 and 8.1 will be "early" releases I >> for IA64 (similar to 1.0 and 1.5 on alpha), and then starting with 8.2 @ >> Alpha and IPF VMS will be released together.  None of this is! >> particularly new information. i > C > My hobbyist cluster is at 7.2-1 (ALPHA) and 7.2 (VAX).  I want to H > upgrade soon.  What do folks recommend?  For ALPHA?  For VAX?  I wouldD > rather wait A BIT and upgrade to a version which will be supportedJ > (downloadable patches) longer, especially since there will probably be a/ > longer than normal wait until 8.2 comes out. t >p  C I haven't looked at the VAX side of things for quite some time, butiB I'm on Alpha 7.3-1 at both home and work (some systems still to be
 upgraded).      s@ >> Alpha and IPF VMS will be released together.  None of this is! >> particularly new information. i > J > I seem to recall that there would be at least one version for ALPHA and J > VAX and IPF.  Is that still planned?  If HP wants to keep folks who are : > now on VAX by moving them to IPF, then I think having a H > mixed-architecture VAX-IPF cluster would be much more attractive than * > having to use ALPHA as a stepping stone.     -- f
 Paul Sture   ------------------------------  # Date: Mon, 12 May 2003 14:52:59 GMT % From: "Safir" <axica_nopub@yahoo.com>.0 Subject: Re: OpenVMS Memory/Performance Question0 Message-ID: <fzOva.696$vD7.312@news.cpqcorp.net>  7 http://h71000.www7.hp.com/doc/73final/6491/6491pro.html    could be helpful.o   ------------------------------  % Date: Mon, 12 May 2003 10:48:55 -0400s! From: Jim Agnew <jpagnew@vcu.edu>b> Subject: Re: OpenVMS Pearl - VAXscan is now available on Alpha' Message-ID: <3EBFB457.1610CB39@vcu.edu>S  F Excellent!!!  VAX scan is used for MMSgen, a decus tool that generatesF mms dependencies for code. (developed by the space telelescope science people)e   Jimr   Sue Skonetski wrote: >  > -----Original Message----- > From: Skonetski, Susan' > Sent: Thursday, May 08, 2003 10:57 AMe > To: Skonetski, SusanE > Subject: OpenVMS Pearl - VAXscan is now available on Alpha - OK fort > distribution > C > VAXscan is a block-structured programming language in the VAX/VMSeH > environment that is designed to build tools to manipulate text stringsD > and text files. The primary applications for VAX SCAN are filters,? > translators, extractors/analyzers, and preprocessors. It is ah> > versatile tool that includes string operators for searching,G > comparing, extracting, and assigning character strings. A significantnH > strength of VAX SCAN is in the pattern-matching constructs that permitE > matching of one or more complex patterns of text in the input data.y > F > It is used by many companies that process large amounts of text dataA > or utilize complex procedures to manipulate input data streams.f > B > This product was only available for VAX/VMS, but it has now beenE > migrated to the Alpha-platform, allowing users of VAXscan to expandrB > their capabilities to this modern platform. It is available fromE > Emulators International, a company that is specialized in migration  > and migrated tools for VMS.t > ( > Product information is to be found at:A >  http://www.emulatorsinternational.com/en/products SCANAXP.htme   --  F "4,000 years ago I made a mistake."  Elrond Half-Elven, in "Fellowship of the Ring"   ------------------------------    Date: 12 May 2003 10:56:56 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) > Subject: Re: OpenVMS Pearl - VAXscan is now available on Alpha3 Message-ID: <Yz4hSLE3K5PK@eisner.encompasserve.org>s  K In article <3EBFB457.1610CB39@vcu.edu>, Jim Agnew <jpagnew@vcu.edu> writes:tH > Excellent!!!  VAX scan is used for MMSgen, a decus tool that generatesH > mms dependencies for code. (developed by the space telelescope science	 > people)u >   D    Since MMS and the compilers now have this capability built in, weF    stopped using MMSgen.  IIRC we had a vested copy in use on an Alpha    at one time.    ------------------------------  % Date: Mon, 12 May 2003 12:40:29 -0400 ! From: Jim Agnew <jpagnew@vcu.edu>h> Subject: Re: OpenVMS Pearl - VAXscan is now available on Alpha& Message-ID: <3EBFCE7D.7DD4FE9@vcu.edu>  C oh really????????  i'm impressed... what version did that come in??i   jimr   Bob Koehler wrote: > M > In article <3EBFB457.1610CB39@vcu.edu>, Jim Agnew <jpagnew@vcu.edu> writes:bJ > > Excellent!!!  VAX scan is used for MMSgen, a decus tool that generatesJ > > mms dependencies for code. (developed by the space telelescope science > > people)l > >  > F >    Since MMS and the compilers now have this capability built in, weH >    stopped using MMSgen.  IIRC we had a vested copy in use on an Alpha >    at one time.    -- nF "4,000 years ago I made a mistake."  Elrond Half-Elven, in "Fellowship of the Ring"   ------------------------------  # Date: Mon, 12 May 2003 13:32:29 GMTt' From: Rick Dyson <rick-dyson@uiowa.edu>t: Subject: Re: Pinout of power connector on DECserver 90TL ?( Message-ID: <3EBFA26D.68DCBC6@uiowa.edu>   David Froble wrote:n > I > Note that a DEChub 90 will also provide a nice home for the 90TL, and 7- > additional 90 series modules.K  L True!!  And I have a couple for sale if you are interested!  As well as some# other modules (including 4 90TLs!).a  & See http://mis.uihc.uiowa.edu/surplus/  H I have one of the PS units in use somewhere else on a 90M.  If you stillL don't have the details of the part number I can check that one sometime.  ItC seems like you are getting a few responses on that subject already.e   rick   ------------------------------  # Date: Mon, 12 May 2003 03:07:51 GMTe% From: "bayden cline" <bayden@isys.ca>  Subject: vax emulator questionH Message-ID: <beEva.180108$kYH.3204@news01.bloor.is.net.cable.rogers.com>  K I just got Simh vax emulator and am having problems with it in regards to aaI couple of drive images i have it does not seem to want to run the rx29 or-E ra73 drive images.  I does seem to run the ra72 ones fine.  I am justaK wondering if it is because of a size limitation on the drive images that iti: supports or might it be something else.  Thanks in advance   bayden   ------------------------------  % Date: Mon, 12 May 2003 18:42:43 +0200a2 From: martin@radiogaga.harz.de (Martin Vorlaender)" Subject: Re: vax emulator question; Message-ID: <3ebfcf03.524144494f47414741@radiogaga.harz.de>   $ bayden cline (bayden@isys.ca) wrote:  H > I just got Simh vax emulator and am having problems with it in regardsH > to a couple of drive images i have it does not seem to want to run theJ > rx29 or ra73 drive images.  I does seem to run the ra72 ones fine.  I amJ > just wondering if it is because of a size limitation on the drive imagesD > that it supports or might it be something else.  Thanks in advance  G As can be seen from VAX/vax_doc.txt (or PDP11/pdp11_rq.c), the emulateda8 RQDX3 controller only supports the following disk types:  %    type	sec	surf	cyl	tpg	gpc	RCT	LBNsg 	     RX50	10	1	80	5	16	-	800    RX33	15	2	80	2	1	-	2400    RD51	18	4	306	4	1	36*4	21600     RD31	17	4	615	4	1	3*8	41560    RD52	17	8	512	8	1	4*8	60480     RD53	17	7	1024	7	1	5*8	138672"    RD54	17	15	1225	15	1	7*8	311200  >    The simulator also supports larger drives that only existed=    on SDI controllers.  XBN, DBN, RCTS and RCTC are not knownn8    for the SDI drives and are not used by the simulator:  #    RA82	57	15	1435	15	1	?*8	1216665s$    RA72	51	20	1921?	20	1	?*8	1953300#    RA90	69	13	2656	13	1	?*8	2376153 #    RA92	73	13	3101	13	1	?*8	2940951-   cu,-   Martin --  B                         | Martin Vorlaender | VMS & WNT programmer1  OpenVMS: Where do you  | work: mv@pdv-systeme.degD  want to BE today?      |   http://www.pdv-systeme.de/users/martinv/8                         | home: martin@radiogaga.harz.de   ------------------------------  % Date: Sun, 11 May 2003 21:44:53 -0500g1 From: "David J. Dachtera" <djesys.nospam@fsi.net>e@ Subject: Re: What is the schedule for the DII COE certification?' Message-ID: <3EBF0AA5.4507F39F@fsi.net>h   John Santos wrote: > ( > On 10 May 2003, Larry Kilgallen wrote: > Y > > In article <m1$m61PpHU1C@elias.decus.ch>, p_sture@elias.decus.ch (Paul Sture) writes:nr > > > In article <E9uua.528$Ct2.295@news.cpqcorp.net>, "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> writes: > > O > > >> The Kernel sits on top of a standard VMS release.  But changes that wereeR > > >> needed to support the Kernel were done in a seperate release stream for theO > > >> first release to manage schedule and risk.  Those changes will be in the . > > >> next general V7.3-* release of OpenVMS. > > >eN > > > So... I was looking forward to the idea that we non US govt. folks would< > > > get to see the benefits of the work put into VMS here. > > >PK > > > Can you please tell us what advantages we, the normal users will see?h > >rN > > For C programmers, there will be better compatibility with the environment; > > on Unix operating systems, which is useful for porting.  > > J > > For those using higher level languages like Ada, it should not matter. > I > Well, even if you use a higher level language (I'm partial to Macro-32,hJ > VAX/DEC Basic and TECO), you will benefit if other people (HP and nonHP)E > find it easier to port and maintain various programs.  For example,eA > there is a recent thread about 4GB file size limits in ZIP.  IfhJ > this has been or is soon fixed in the generic/Linux/GNU/Solaris/whateverE > version of ZIP and that version can be compiled with minimal hassleo. > on VMS, then we'll get the fix much quicker. > 8 > So it doesn't just apply to low-level C programmers...  D I should think it's a matter of acquiring the ability to use integerH fields 64 bits in length, preferably unsigned. Other software would needG to be modified: ZIP, UNZIP (remember backward compatibility with 32-bitn7 versions), the associated RTLs and math libraries, etc.o  ) Just a guess, but it seems to make sense.i   -- e David J. Dachteraa dba DJE Systemsu http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/D   ------------------------------  % Date: Mon, 12 May 2003 17:26:10 +1000 1 From: Paddy O'Brien <paddy.o'brien@tg.nsw.gov.au> @ Subject: Re: What is the schedule for the DII COE certification?, Message-ID: <3EBF4C92.5060106@tg.nsw.gov.au>   David J. Dachtera wrote: > John Santos wrote: > ( >>On 10 May 2003, Larry Kilgallen wrote: >> >>X >>>In article <m1$m61PpHU1C@elias.decus.ch>, p_sture@elias.decus.ch (Paul Sture) writes: >>>hp >>>>In article <E9uua.528$Ct2.295@news.cpqcorp.net>, "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> writes: >>> M >>>>>The Kernel sits on top of a standard VMS release.  But changes that weresP >>>>>needed to support the Kernel were done in a seperate release stream for theM >>>>>first release to manage schedule and risk.  Those changes will be in the1, >>>>>next general V7.3-* release of OpenVMS. >>>>L >>>>So... I was looking forward to the idea that we non US govt. folks would: >>>>get to see the benefits of the work put into VMS here. >>>>I >>>>Can you please tell us what advantages we, the normal users will see?u >>>eM >>>For C programmers, there will be better compatibility with the environmento: >>>on Unix operating systems, which is useful for porting. >>>lI >>>For those using higher level languages like Ada, it should not matter.C >>I >>Well, even if you use a higher level language (I'm partial to Macro-32,aJ >>VAX/DEC Basic and TECO), you will benefit if other people (HP and nonHP)  G John, I would not class any of these as high level.  Macro is low; not =D sure about Basic, I have only used it as an interpreted language -- G middle; and TECO is an editor not a language (perhaps you can do eigen G analysis with TECO :-)  E >>find it easier to port and maintain various programs.  For example,nA >>there is a recent thread about 4GB file size limits in ZIP.  IfeJ >>this has been or is soon fixed in the generic/Linux/GNU/Solaris/whateverE >>version of ZIP and that version can be compiled with minimal hasslen. >>on VMS, then we'll get the fix much quicker. >>8 >>So it doesn't just apply to low-level C programmers... >  > F > I should think it's a matter of acquiring the ability to use integerJ > fields 64 bits in length, preferably unsigned. Other software would needI > to be modified: ZIP, UNZIP (remember backward compatibility with 32-bito9 > versions), the associated RTLs and math libraries, etc.g > + > Just a guess, but it seems to make sense.s > H David, why "preferably unsigned"?  A 64 bit integer is already a damned I big number, beyond the use of most of us.  Mersenne primes are a sort of  E hobbyist thing and other than that, I cannot think of any use for 64  G bits rather than 63 in my environment. (Not saying that I make any use 4I of Mersenne primes).  Ah, yes I use them for date/time calculations with  3 the system services instead of LIB$ADD and friends.0   Regards, Paddy      G ***********************************************************************e  C "This electronic message and any attachments may contain privilegedo> and confidential information intended only for the use of the B addressees named above.  If you are not the intended recipient of C this email, please delete the message and any attachment and adviseUB the sender.  You are hereby notified that any use, dissemination, 7 distribution, reproduction of this email is prohibited.   A If you have received the email in error, please notify TransGrid aA immediately.  Any views expressed in this email are those of the a= individual sender except where the sender expressly and with rC authority states them to be the views of TransGrid.  TransGrid usesk> virus scanning software but excludes any liability for viruses contained in any attachment.  < Please note the email address for TransGrid personnel is now$ firstname.lastname@transgrid.com.au"  G ***********************************************************************,   ------------------------------  # Date: Mon, 12 May 2003 16:50:48 GMTd9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com>a@ Subject: Re: What is the schedule for the DII COE certification?0 Message-ID: <IhQva.711$PL7.232@news.cpqcorp.net>  6 "Paul Sture" <p_sture@elias.decus.ch> wrote in message# news:m1$m61PpHU1C@elias.decus.ch...i > J > So... I was looking forward to the idea that we non US govt. folks would8 > get to see the benefits of the work put into VMS here. >gG > Can you please tell us what advantages we, the normal users will see?tE > Will porting Solaris applications to VMS be a whole lot easier, for 
 > example? >e >P  K The COE work added new functionality to the CRTL to start filling out a lotxE of the unimplemented, or partially implemented (or worse, incorrectlydK implemented) UNIX library calls.  Hard links were done, UNIX user/file ID'svD were done, semaphores were done/enhanced, UNIX filename symatics hadG extensive work, we started on symbolic links, etc.  We enhanced X11 and K Motif to be fully more-or-less compliant (well, not the POSIX-only stuff) -hH so little things like various environment variables that are standard onD UNIX will work.  You can set up logical names so that in CDE & MotifG filenames will be presented as UNIX-style path names.  You can setup anyK account that will allow you to unlock a paused screen (on UNIX you can typeoL the ROOT password to unpause - we allow you to setup an arbitrary account toL do this).  Plus we collected together and enhanced a lot of tools - like the3 GNV stuff.  POSIX is now working again for example.u  F We have a longer-term objective to bring the C interfaces up to UNIX98I compliance with a goal to allow most UNIX user code to simply compile ando# link (or more to the point "make").s   ------------------------------   End of INFO-VAX 2003.262 ************************