1 INFO-VAX	Sat, 03 Jul 2004	Volume 2004 : Issue 364       Contents: RE: A lint Utility for OpenVMS Re: A lint Utility for OpenVMS RE: A lint Utility for OpenVMS* Re: FTP client to understand ODS-5 volumes* Re: FTP client to understand ODS-5 volumes= Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article  MySQL 4.1.3-beta for OpenVMS Re: OpenVMS .... no news?  Re: OpenVMS .... no news?  Re: OpenVMS .... no news?  Re: OpenVMS .... no news?  Re: OpenVMS .... no news?  OpenVMS Perm Position - Dallas Powerstor L200 tapeloader ' Problem with BASIC install on VMS 7.3-2 + Re: Problem with BASIC install on VMS 7.3-2  Re: Secondary DNS problem ' Re: slap in the face again... thanks HP ' Re: slap in the face again... thanks HP ' Re: slap in the face again... thanks HP  Re: smile, be happy $ Re: Split I/Os to contiguous file??? Very nice VMS testimonial  VMS on VAXstation 3100 M76 Re: VMS on VAXstation 3100 M76 Re: VMS on VAXstation 3100 M76 Re: VMS on VAXstation 3100 M76 Re: VMS on VAXstation 3100 M76
 VMS7.2 on VAX 1 Re: When to use INIT/WINDOWS, SET VOLUME /WINDOWS   F ----------------------------------------------------------------------   Date: 2 Jul 2004 12:52:22 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ' Subject: RE: A lint Utility for OpenVMS 3 Message-ID: <v17bQA0nnFsC@eisner.encompasserve.org>   _ In article <NDEMLKKEBOIFBMJLCECIOELODHAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes: , > If you used PL/I you wouldn't need lint:-) >   H    If you used the mother tounge of programming, you wouldn't be staring    at your bippy.    ------------------------------   Date: 2 Jul 2004 12:49:04 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ' Subject: Re: A lint Utility for OpenVMS 3 Message-ID: <2L3+3V80KvST@eisner.encompasserve.org>   _ In article <926edf3b.0406301523.602f3d3d@posting.google.com>, lsk55@hotmail.com (Scott) writes: / > Does anyone know of a lint utility for DEC C?  >   F    Almost all the checks that lint does were put into the first ANSI C<    language standard, so a good C compiler will report them.  G    Most of the checks which didn't get put into the language definition J    aren't reliable.  For example lint typically will flag this, but ANSI CK    compilers won't, the code is good since both a, *a, and b always contain H    valid data before they are used.  Note that the first flag is for *a,
    not for a.       void c(int *a)     {
       *a = 2;     }  	    main()        int b;       int* a = &b;  6       c(a);             /* flag as uninitialized *a */5       printf("%d\n",b); /* flag as uninitialized b */     }   ------------------------------  $ Date: Fri, 2 Jul 2004 19:14:06 -0700# From: "Tom Linden" <tom@kednos.com> ' Subject: RE: A lint Utility for OpenVMS 9 Message-ID: <NDEMLKKEBOIFBMJLCECIOEOIDHAA.tom@kednos.com>   = Not sure what that means, but I'll assume it is meaningful to  someone.     -----Original Message-----D   From: Bob Koehler [mailto:koehler@eisner.nospam.encompasserve.org]&   Sent: Friday, July 02, 2004 10:52 AM   To: Info-VAX@Mvb.Saic.Com )   Subject: RE: A lint Utility for OpenVMS       A   In article <NDEMLKKEBOIFBMJLCECIOELODHAA.tom@kednos.com>, "Tom  "   Linden" <tom@kednos.com> writes:.   > If you used PL/I you wouldn't need lint:-)   >    J      If you used the mother tounge of programming, you wouldn't be staring      at your bippy.       --- (   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).B   Version: 6.0.710 / Virus Database: 466 - Release Date: 6/23/2004    --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.710 / Virus Database: 466 - Release Date: 6/23/2004   ------------------------------   Date: 2 Jul 2004 12:34:44 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 3 Subject: Re: FTP client to understand ODS-5 volumes 3 Message-ID: <1D2gmKE8J1WI@eisner.encompasserve.org>   m In article <30JUN04.20550092@thuria.waisman.wisc.edu>, karcher@thuria.waisman.wisc.edu (Carl Karcher) writes: I > Any suggestions for a GUI FTP client (for Windows) that will understand J > ODS-5 filenames when used with the FTP server on TCPIP V5.4? There was aD > previous post about Mozilla being fixed to handle VMS ftp servers: > 5 >  http://bugzilla.mozilla.org/show_bug.cgi?id=151501  > H > But this only appears to work for ODS-2 type file names (at least withB > Mozilla V1.7). I might re-open that bug - just looking for other > ideas.  &    I've had no problems with ftp95pro.   ------------------------------   Date: 2 Jul 2004 12:38:38 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 3 Subject: Re: FTP client to understand ODS-5 volumes 3 Message-ID: <lLx3zSS25AOb@eisner.encompasserve.org>   B In article <04070109131585@antinode.org>, sms@antinode.org writes: > C >    Everything's complicated, I always say.  Of course, for a real < > nightmare, I prefer trying to parse a UNIX "ls -l" report.  >    Try porting that between BSD and SVID systems when you need    something to do.    ------------------------------  # Date: Fri, 02 Jul 2004 17:55:16 GMT & From: Rick Jones <foo@bar.baz.invalid>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <8khFc.5263$Ie4.1624@news.cpqcorp.net>  ) Bill Todd <billtodd@metrocast.net> wrote: D > Then if the applications spent any significant time in the OS codeA > (rather than running mostly without OS intervention after being C > started), the performance values you obtained were not for 32-bit D > x86 emulation but for a mixture of 32-bit x86 emulation and nativeC > OS code execution - which of course would be higher than for pure  > x86 emulation.  B Indeed, some of the time is in the OS, varying from application toD application - and that is the way x86 applications run on Itanium2 - on top of a native Itanium OS.  
 rick jones --  = denial, anger, bargaining, depression, acceptance, rebirth... C                                      where do you want to be today? F these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...    ------------------------------  # Date: Fri, 02 Jul 2004 17:59:13 GMT & From: Rick Jones <foo@bar.baz.invalid>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <RnhFc.5264$Ie4.1409@news.cpqcorp.net>  P Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote:A > How much of the DNS Server/Bind workload is Kernel and how much  > is user ?   F It varies with the version of named being run and the options that areG set.  Just as other applications will vary in their user/kernel splits.    > User is emulated > Kernel isn't   Correct.  @ > Or put another way without that information what you have just$ > presented is entirely meaningless.  F I do not believe so.  Emulated x86 applications are going to be run on a native IPF OS.  
 rick jones --  ? Process shall set you free from the need for rational thought.  F these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...    ------------------------------  $ Date: Fri, 2 Jul 2004 22:56:45 +0200  From: "Dr. Dweeb" <dr@dweeb.com>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article- Message-ID: <cc4i64$148m$1@news.cybercity.dk>   ( Andrew Harrison SUNUK Consultancy wrote: > Dr. Dweeb wrote: >> JF Mezei" <"jfmezei wrote:  >># >>> david20@alpha2.mdx.ac.uk wrote:  >>> G >>>> "Internally, Intel has basically given up hope on IPF becoming the G >>>> defacto 64-bit architecture until Tukwilla in 2007. From the specs C >>>> being bandied about, that chip looks to be another marvel (pun F >>>> intended) from the Alpha team, but between now and then, there is >>>> precious little." >>>  >>> D >>> IA64 may look much better in 3 years compared to IA64 today. Few >>> people will debate this. >>> D >>> The *REAL* question is whether IA64 will progress as fast as itsB >>> competing chips such as Power, 8086 and even Sparc during thatC >>> period. And one could argue that it needs to progress faster in  >>> order to catch up. >>> F >>> 3 years from now, how will IA64 perform compared to whatever Power >>> offers 3 years from now ?  >>> C >>> Remember that it was those very Alpha developpers that gave all F >>> those presentations on how IA64 was a bad archictecture that wouldE >>> be very difficult to move as quickly as cleaner architectures. So E >>> no matter how good the alpha guys are, if they are tasked to help F >>> improve a bad architecture, there is no way that they can work theD >>> same miracles as they would have been able to do on a nice clean >>> architecture.  >>> B >>> IA64 will NEVER be industry standard. That "just wait 3 years"H >>> statement from Intel is yet another "IA64 may not be impressive now,H >>> but wait X years, and you'll see" statements. Heard those many times >>> already. >> >>C >> Can anyone show me anywhere in writing where INTEL (not HP) have E >> said that EPIC will become "industry standard", as distinct from a 6 >> high end server chip for specialised applications ? >>D > http://www.dhbrown.com/cffiles/RPPage.cfm?ID=2503375&DOC=148254036+ > http://www.theinquirer.net/?article=10203  > X http://www.hp.com/products1/itanium/infolibrary/pdfs/ISS_Solutions_Whitepaper_062503.pdf > ? > I would caution that much of this stuff is not for the easily < > nauseated and that if you are in this category it would be; > best to print this out and read it in your smallest room.  >   J Well Andrew, I know that HP and plenty of hacks echoing HP have constantlyJ used the "Industry standard" moniker for Itanium, which is why I asked forL INTEL specific references.  I have this sneaking suspicion, that HP made theJ "Industry standard" thing up and that INTEL might never have actually have8 mentioned "Itanic" & "Industry Standard" simultaneously.  	 > regards  > Andrew Harrison    ------------------------------  $ Date: Fri, 2 Jul 2004 23:08:18 +0200  From: "Dr. Dweeb" <dr@dweeb.com>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article- Message-ID: <cc4iro$156b$1@news.cybercity.dk>    Bill Todd wrote:- > "Dr. Dweeb" <dr@dweeb.com> wrote in message ) > news:cc226v$1sap$1@news.cybercity.dk...  >  > ...  > E >> There are technical "problems" associated with the nature of EPIC. E >> These were spelled out very clearly, unequivocally and irrefutably E >> and in the Digital IA64 v. Alpha paper.  These issues have nothing E >> to do with "heat generation" or intrinsic "competitiveness" of the  >> IA64 implementation.  > A > True, but those are nonetheless legitimate issues as well, even F > though they were not clearly foreseeable at the time the Alpha paper > was written.  . Indeed.  It was not my intent to dispute this.   >  >  SadlyE >> my copy went south with a disk crash, so I cannot quote it to you.  > F > Google is your friend:  search for alpha_ia64.pdf, and about the 4th, > hit is a copy still available at Raytheon. >    Found - Thanks Bill.   > - bill   ------------------------------   Date: 2 Jul 2004 21:38:11 -0500 + From: young_r@encompasserve.org (Rob Young) F Subject: Re: Intel Itanium's very survival in doubt - inquirer article3 Message-ID: <b38nQxuepIrJ@eisner.encompasserve.org>   _ In article <cL2dnZ9zlpZJZ3nd4p2dnA@metrocast.net>, "Bill Todd" <billtodd@metrocast.net> writes:  > : > "Rob Young" <young_r@encompasserve.org> wrote in message   > N > By using significantly lower-performing cores than a linear extrapolation of  > today's Itanics would suggest. > N > Montecito is already in trouble in this regard:  its two cores won't be ableK > to clock noticeably faster than today's Madison core even if Intel *does* M > solve its 90 nm. process problems, because the pair would generate too much J > heat.  Move to 4 or 8 cores in Tukwila, and the problems only get worse. > E > It's entirely possible that an 8-core Tukwila could offer twice the K > aggregate chip performance of a dual-core Xeon without being able to come J > anywhere near it in per-core performance, and even a 4-core Tukwila thatC > doubled dual-core Xeon performance would clearly offer only equal " > performance on a per-core basis. >   ? 	I suppose a lot is possible.  But yes - equal core performance H 	would mean a single Itanium die would be 100% faster than a single Xeon0 	die given it would contain twice as many cores.  J > By the way, since the article that you cited claims that Itanic offers aM > 30% - 50% per-core performance advantage over Xeon *today* in database use, I > it's instructive to note that the actual lead that Itanic enjoys at the K > 4-processor node size in TPC-C (in an apples-to-apples, SQL Server to SQL K > Server comparison) is only about 18% - most or all of which can likely be M > attributed to the fact that the Itanic system has twice the RAM of the Xeon N > system and uses nearly twice as many disks in the test configuration.  GivenJ > that Intel can't even get *today's* performance comparisons right, theirL > ability to forecast future relative performance would be questionable evenL > if they had not established such an absymal record in such fortune-telling > in the past.    @ 	Maybe more than a little bit of bait and switch going on there.$ 	i.e. a convenient snapshot in time.   >  > ...  > E >> Itanium gets much stronger in SpecInt2000 - probably in Montecito.  > L > Why?  Do you have any information that suggests significant changes in theI > Montecito core from McKinley/Madison?  The only change I've heard of is M > primitive SMT - and it's not clear whether that's been there (unenabled and / > undisclosed, as it was in P4) from the start.  >   ? 	Or course I could be way off the mark but I don't believe Paul * 	would be referring to a CPU 3 years away:  j http://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=2468&Thread=15&entryID=34292&roomID=11  4 But the improvements that will be made in pipelining9 efficiency, cache hierarchy, and system level infrastruc- 7 ture can improve IPF SPECint performance significantly. 7 The ILP is there to be had in SPECint2k and current IPF 6 compilers are finding much more of it than can be used by current hardware.  4 	If that isn't Montecito, he's selling deep futures.   > ...  > ; >> http://www.midrangeserver.com/mid/mid032404-story04.html  >>2 >> Garrison said that the Itanium core is half theK >> size of the Xeon core, which means that Intel will be able to cram twice  > asG >> many Itanium cores on a single chip for a given chip making process.  > H > C'mon, Rob - you're not *that* dumb (though Morgan often seems to be). > K > 1.  Just what part of the fact that cache already consumes more than half N > the area on the 'processor' die is escaping you?  If you need more cache dieM > area than processor area for each core on the chip, then simply halving the N > core size won't get you anything like twice the cores on a die if you retainN > a balanced cache component for them (not to mention that Itanic needs *more*N > cache per core than Xeon or Opteron to perform competitively with them).  SoI > if Intel actually does place twice as many Itanic cores on a die as x86 N > cores, that Itanic die is either going to be a hell of a lot bigger than theC > x86 die or is going to be extremely cache-starved compared to it.  >   @ 	No.  Tukwila is rumored to have greatly reduced caches compared@ 	to Montecito.  An entirely different design - or so it appears.  L > 2.  Not to mention the fact that the real question is not how much smallerF > than the Xeon core the Itanic core is, but how much smaller than theN > Banias/Dothan (and, of course, Opteron) core it is.  Hadn't you noticed thatM > Intel is finally admitting that dozens of pipeline stages may make for good * > clock-rate marketecture but little else?  B 	Multiple cores it is for everybody and Intel is late to the game.6 	Late can be a very good thing as you watch and learn.   > J > After this point, you began wandering around in a daze which it would beN > uncharitable to comment upon in detail (especially as much of that wandering7 > was predicated on some of your misconceptions above).  >   C 	That's charitable of you.  But the over-arching point I was trying = 	to make is Itanium is apparently going to get much better in < 	one so-called weak spot (SpecInt) if Paul's careful wording
 	is accurate.    				Rob    ------------------------------  % Date: Fri, 02 Jul 2004 23:30:43 +0200  From: jf.pieronne@laposte.net % Subject: MySQL 4.1.3-beta for OpenVMS 2 Message-ID: <cc4k67$827$1@news-reader1.wanadoo.fr>  6 MySQL 4.1.3-beta is the first MySQL V4.1 beta version.  : This version is based on a merge of the two existing port.E This is the first version which has no known VMS problem, the MyIsam  ' corruption tables seem to be fixed :-).   K I have successfully access a MySQL database on OpenVMS using the following   tools from a Windows system: - MySQL Control Center     - query database     - add user     - analyze database	     - ...  - MySQL administrator K     - backup/restore database including databases running on differents OS.      - all admin task   -MySQL Query Browser     - query database  J Download from http://www.pi-net.dyndns.org/anonymous/kits/ or any mirrors.  R Kit need the following ACRTL patches as minimum patch levels for each VMS version:  ? OpenVMS 7.3 ACRTL-V0600 OpenVMS 7.3-1 ACRTL-V0300 OpenVMS 7.3-2      Warning:N    This version use files which has differents RMS attributes, also meta-data L are differents. So it is necessary to recreate previous database(delete all M the mysql_root:[data...]). mysqldump can be use to backup existing databases.      Sorry for this inconvenience.  
 Jean-Franois    ------------------------------  # Date: Fri, 02 Jul 2004 18:15:27 GMT ! From: Nigel Barker <nigel@hp.com> " Subject: Re: OpenVMS .... no news?8 Message-ID: <o56be01ml8mq6tptplghsb3dnfpb740hmj@4ax.com>  N On Fri, 2 Jul 2004 12:20:57 -0400, "Bill Todd" <billtodd@metrocast.net> wrote:  6 > I repeat nobody ever promised to double headcount inB >> OpenVMS engineering & for to say otherwise is simply incorrect. > M >Well, since I just provided a quote to the contrary, I'd say that's a bit of M >a stretch.  Now, if you'd like to qualify your statement as applying only to + >Compaq sources, I have no problem with it.   M At that time how could anyone other than a Compaq source possibly _promise_ a I doubling of VMS headcount? You provided a quote from non-employee who was 6 obviously misinformed or just hopeful. Take your pick.  I >> >I think not.  According to the Compaq announcement at the time of the M >> >Alphacide reproduced here, "The first Itanium-based system for Tru64 UNIX $ >> >and OpenVMS is planned for 2003" >>K >> OpenVMS V8.1 shipped in December 2003 & is available as an SDK to anyone  >with  >> $75.  > F >I really didn't see the statement I quoted above as specifying a betaH >version (as clearly evidenced by its price, as well as its limitations)I >rather than a production version.  I doubt that most others did, either.   O This is entirely consistent with the commitment to ship the first Itanium-based O systems with OpenVMS in 2003. OpenVMS V8.1 is far more functional & stable than J OpenVMS Alpha V1.0 was when that shipped all those years ago. Alpha took aO couple of years to get feature parity for VAX. In this case it's within a year. M AlphaVMS 1.0 was not a Beta release & neither is IA64 V8.1. It's a version to M use to start porting all the necessary infrastructure software for production P systems. Earlier versions provided to ISVs were used for porting but this is theH first publicly available version with native compilers & other necessary development tools.   -- Nigel Barker Live from the sunny Cote d'Azur    ------------------------------  # Date: Fri, 02 Jul 2004 19:10:14 GMT - From: JF Mezei <jfmezei.spamnot@teksavvy.com> " Subject: Re: OpenVMS .... no news?@ Message-ID: <61e6f0b024ab928469b2140fae231fdd@news.teranews.com>   Nigel Barker wrote: O > At that time how could anyone other than a Compaq source possibly _promise_ a  > doubling of VMS headcount?    I I also recall statements of VMS engineering growing significantly for the L purposes of handling the alpha murder (port to IA64). It is possible that byM now, most of the work has been done and they have been able to start reducing E headcount.  I was never given the impression that the increase of VMS 4 engineering due to port of IA64 was to be permanent.  Q > systems with OpenVMS in 2003. OpenVMS V8.1 is far more functional & stable than L > OpenVMS Alpha V1.0 was when that shipped all those years ago. Alpha took a0 > couple of years to get feature parity for VAX.  H Yes, but while VMS-ALPHA was being developped, VMS-VAX was continuing toJ progress significantly (for instance, new queue manager), so only once theL core was complete did they start to retrofit Alpha-VMS with all the new bits	 from VAX.   H But in today's environment, if IA64-VMS is to have immediate parity withM ALPHA-VMS, it leads one to believe that there hasn't been much development on M ALPHA-VMS while they were busy porting to IA64. Or perhaps the fact that they E worked on a common code base has really paid off and they are able to N implement alpha improvements on IA64 in real time even at a time when IA64 was still very incomplete.   ------------------------------  $ Date: Fri, 2 Jul 2004 18:51:23 -0400* From: "Bill Todd" <billtodd@metrocast.net>" Subject: Re: OpenVMS .... no news?2 Message-ID: <OIWdnXkV7PYue3jdRVn-iQ@metrocast.net>  . "Nigel Barker" <nigel@hp.com> wrote in message2 news:o56be01ml8mq6tptplghsb3dnfpb740hmj@4ax.com...I > On Fri, 2 Jul 2004 12:20:57 -0400, "Bill Todd" <billtodd@metrocast.net>  wrote: > 8 > > I repeat nobody ever promised to double headcount inD > >> OpenVMS engineering & for to say otherwise is simply incorrect. > > L > >Well, since I just provided a quote to the contrary, I'd say that's a bit ofL > >a stretch.  Now, if you'd like to qualify your statement as applying only to- > >Compaq sources, I have no problem with it.  > C > At that time how could anyone other than a Compaq source possibly  _promise_ a  > doubling of VMS headcount?  L You're becoming somewhat tiresome, Nigel:  try to focus on the actual words,= rather than your vague impression of what may have been said.   K You originally objected to my statement "I can so clearly remember the time G when it was stated that the VMS head count would be doubled":  the word I 'promise' was not used, nor was it claimed that this precise wording came I from Compaq.  When you responded "You are wrong on this" - i.e., claiming J that *no* such statement had been made, I provided a quote proving that itH had (though not by Compaq) plus another from Fred (a reasonably credibleB Compaq source on that matter, IMO) indicating that at least a very> substantial (though unquantified) increase had been committed.  E Furthermore, the specific statement that a doubling in head-count was I planned was never in any way corrected by those in a position to, AFAICT. J So while Compaq may not have made it, those who might have corrected chose to let it stand.   ...   K > >> >I think not.  According to the Compaq announcement at the time of the J > >> >Alphacide reproduced here, "The first Itanium-based system for Tru64 UNIX& > >> >and OpenVMS is planned for 2003" > >>F > >> OpenVMS V8.1 shipped in December 2003 & is available as an SDK to anyone > >with 	 > >> $75.  > > H > >I really didn't see the statement I quoted above as specifying a betaJ > >version (as clearly evidenced by its price, as well as its limitations)K > >rather than a production version.  I doubt that most others did, either.  > C > This is entirely consistent with the commitment to ship the first 
 Itanium-based  > systems with OpenVMS in 2003.   E I consider that statement to be pure bullshit (when considered in the L context of the rather well-established understanding of what a 'VMS release'H means), but am happy to let others come to their own conclusions without further help from me.    - bill   ------------------------------   Date: 2 Jul 2004 16:01:27 -0700 1 From: keithparris_NOSPAM@yahoo.com (Keith Parris) " Subject: Re: OpenVMS .... no news?= Message-ID: <cf15391e.0407021414.2125caac@posting.google.com>   s fabiopenvms@yahoo.com.br (Fabio Cardoso) wrote in message news:<f30679fb.0406280834.71564e4b@posting.google.com>... - > For a long time I am not reading good news  2 > about OpenVMS' new features in this news group ?& > What is happening ? Is it freezed ?   D OpenVMS is far from frozen. You might want to read the release notesF for new versions of VMS as they come out to get a taste for all that's happening behind the scenes.  B I spent the period of 1996-2002 as a customer. During that time, IF worked at high-end sites with critical needs and begged DEC/Compaq for> features like dissimilar device shadowing, dynamic volume sizeF expansion, direct-to-MSCP-served-and-back path failover, and solutionsB to severe problems with Primary CPU interrupt-state saturation andC excessive MP_Synch time, and long shadow merge times on SCSI disks.   A Solutions to all these problems have been developed and delivered > based on development work that occurred since the Itanium port started.  C When the Itanium port started in 2001, OpenVMS version 7.3 had just D shipped, and work had just started on 7.3-1. This means that all theD features in 7.3-1 and versions beyond that have been developed sinceF the Itanium port started. (I know there's always some work on conceptsF and ideas and such beforehand, but the real development work for 7.3-1C features couldn't really start until 7.3 was "in the can".) 7.3 had B introduced Fast_Path for SCSI and Fibre Channel, which helped someB with Primary CPU interrupt-state saturation, but not enough. 7.3-1E introduced major improvements in lots of performance areas, including C MP_Synch, and also provided direct/MSCP-served path failover. 7.3-2 B had Dissimilar Device Shadowing and dynamic volume size expansion,D features users had asked for and dreamed of probably for more than aD decade. 7.3-2 also had Fast_Path for LANs, solving the last piece ofF the Primary CPU saturation problem. Now we have host-based mini-merge,D solving another long-standing problem. The issues I listed were just> my biggest problems as a customer -- other customers had otherD problems that were solved during the same time (for example, lots of@ TCP/IP needs of various sorts and other failover needs solved byF failSAFE IP and LAN Failover). And all this was done while the Itanium port was going on.   ------------------------------  $ Date: Fri, 2 Jul 2004 19:28:20 -0400* From: "Bill Todd" <billtodd@metrocast.net>" Subject: Re: OpenVMS .... no news?2 Message-ID: <SZ-dnWoeO6nBcnjdRVn-uw@metrocast.net>  > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message7 news:cf15391e.0407021414.2125caac@posting.google.com... ; > fabiopenvms@yahoo.com.br (Fabio Cardoso) wrote in message 9 news:<f30679fb.0406280834.71564e4b@posting.google.com>... . > > For a long time I am not reading good news4 > > about OpenVMS' new features in this news group ?' > > What is happening ? Is it freezed ?  > F > OpenVMS is far from frozen. You might want to read the release notesH > for new versions of VMS as they come out to get a taste for all that's > happening behind the scenes. > D > I spent the period of 1996-2002 as a customer. During that time, IH > worked at high-end sites with critical needs and begged DEC/Compaq for@ > features like dissimilar device shadowing, dynamic volume sizeH > expansion, direct-to-MSCP-served-and-back path failover, and solutionsD > to severe problems with Primary CPU interrupt-state saturation andE > excessive MP_Synch time, and long shadow merge times on SCSI disks.  > C > Solutions to all these problems have been developed and delivered @ > based on development work that occurred since the Itanium port
 > started. > E > When the Itanium port started in 2001, OpenVMS version 7.3 had just F > shipped, and work had just started on 7.3-1. This means that all theF > features in 7.3-1 and versions beyond that have been developed sinceH > the Itanium port started. (I know there's always some work on conceptsH > and ideas and such beforehand, but the real development work for 7.3-1E > features couldn't really start until 7.3 was "in the can".) 7.3 had D > introduced Fast_Path for SCSI and Fibre Channel, which helped someD > with Primary CPU interrupt-state saturation, but not enough. 7.3-1G > introduced major improvements in lots of performance areas, including E > MP_Synch, and also provided direct/MSCP-served path failover. 7.3-2 D > had Dissimilar Device Shadowing and dynamic volume size expansion,F > features users had asked for and dreamed of probably for more than aF > decade. 7.3-2 also had Fast_Path for LANs, solving the last piece ofH > the Primary CPU saturation problem. Now we have host-based mini-merge,F > solving another long-standing problem. The issues I listed were just@ > my biggest problems as a customer -- other customers had otherF > problems that were solved during the same time (for example, lots ofB > TCP/IP needs of various sorts and other failover needs solved byH > failSAFE IP and LAN Failover). And all this was done while the Itanium > port was going on.  K Despite Keith's propensity to play marketeer, I agree with him on this one. H There are still many very dedicated and accomplished people at SpitbrookF working on VMS, and over the past 3 years they've managed to work in aK respectable amount of development alongside the porting effort, despite the I disruption of the latter and perhaps with more regard for doing the right 6 thing by customers than for HP's corporate priorities.  J But I suspect many of them consider this to be VMS's last hurrah, and wantJ to make it a good one.  HP needed them during the porting process, and mayK even need quite a few of them until the 'full functionality' Itanic release G a year or so from now.  So for a good indication of VMS's likely health J beyond then, keep a close eye on its head-count - particularly that of itsA more senior people - as time passes (if you haven't already drawn J conclusions from the level of HP's VMS marketing efforts and the dearth of1 new features on the VMS roadmap beyond mid-2005).    - bill   ------------------------------   Date: 2 Jul 2004 10:25:30 -0700 + From: greg.dement@cdicorp.com (Greg Dement) ' Subject: OpenVMS Perm Position - Dallas = Message-ID: <be3bb8c5.0407020925.354909e8@posting.google.com>    Hello,  F For anyone interested, we have a direct hire opportunity with a clientE in the Downtown Dallas area. Laid back environment (business casual). ? Must haves for the position are 5+ years OpenVMS administration E experience and strong UNIX background, ideally AIX. TRU64 is an added % bonus, but by no means a dealbreaker.   : You are welcome to send resumes to greg.dement@cdicorp.com   ------------------------------   Date: 2 Jul 2004 20:42:16 GMT  From: healyzh@aracnet.com " Subject: Powerstor L200 tapeloader, Message-ID: <cc4hb802q2c@enews4.newsguy.com>  K I recently obtained a Powerstor L200 (aka ATL L200, aka Quantum L200).  Has L anyone used one of these with OpenVMS, and if so what does it take to get itG to work?  Ideally I'd like to be able to at least have it automatically G cycle through the tapes loading and unloading them as needed.  It has 8 K slots, a DLT4000 drive.  The one I have doesn't have a barcode reader, butI * doubt that's really an option that I need.   		Zane   ------------------------------  % Date: Fri, 02 Jul 2004 14:18:06 -0400 2 From: "Stanley F. Quayle" <squayle@insight.rr.com>0 Subject: Problem with BASIC install on VMS 7.3-2- Message-ID: <40E56E9E.23136.E6C053@localhost>   E This was sent by a friend who uses BASIC.  Could someone report this   to HP?    ) ------- Forwarded message follows ------- A I know you don't use BASIC much, but one of your customers might.   E Any attempt to install recent versions of BASIC (V1.3, V1.4, V1.5) oneC ALPHA VMS 7.3-2 fails if the "OpenVMS Alpha system definitions texteA library" is selected. This options makes BASIC actually useful byTE allowing system definitions to be included in code, such as $IODEF et5 al.m  B BASIC V1.5 will install with no problem on Alpha VMS 7.3. I don't  have a VMS 7.3-1 system to test on.  = There are no patches on this subject in the HP OpenVMS patch t	 database.   6 I don't have contract access to make a trouble ticket.  E The workaround is to install basic V1.5 on a VMS 7.3 machine and copyiD the resultant SYS$LIBRARY:BASIC$STARLET.TLB to the VMS 7.3-2 system.   Jim.( ------- End of forwarded message -------
 --Stan Quayle. Quayle Consulting Inc.  
 ----------- Stanley F. Quayle, P.E. N8SQ  +1 614-868-136303 8572 North Spring Ct., Pickerington, OH  43147  USA 0 stan-at-stanq-dot-com       http://www.stanq.com   ------------------------------  * Date: Fri, 2 Jul 2004 22:32:50 +0000 (UTC)6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)4 Subject: Re: Problem with BASIC install on VMS 7.3-21 Message-ID: <newscache$zbx80i$1rr1$1@news.sil.at>M  b In article <40E56E9E.23136.E6C053@localhost>, "Stanley F. Quayle" <squayle@insight.rr.com> writes:F >This was sent by a friend who uses BASIC.  Could someone report this  >to HP?s >[BASIC$STARLET.TLB]  E IIRC, BASIC V1.5A was just done for this case (V7.3-2 in particular).-J And BASIC V1.5A is out since last november or so (=> at least 2 ConDists). It surely is worth checking...   -- u Peter "EPLAN" LANGSTOEGERo% Network and OpenVMS system specialisti E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  * Date: Fri, 2 Jul 2004 22:20:53 +0000 (UTC)6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)" Subject: Re: Secondary DNS problem1 Message-ID: <newscache$1sw80i$lhr1$1@news.sil.at>1   In article <1037270357C4D411A1C900A0C9D4BFCB01147BC4@hqnts40div01.academy.kiev.ua>, "Oleksii Krykun" <krikun@academy.kiev.ua.no.spam> writes:@K >MS DNS became non-reliable. It hangs often. Moreover I am planning to movegK >this server to FreeBSD with BIND and I would like to test this software int >my environment.  ' So you use a 3rd party DNS on NT4 now ?t  > >> Do you have security keys in use (wouldn't make sense ;-) ? > E >Hmmm! No. But I invoked rndc-confgen -a without any modifications ofp, >rndc.key. May be this... What do you think?  F Don't know. As long as you have no key statement in DNS config file...  3 >I removed old zone files and restarted DNS. I see:y >$ ucx sh host/nolocal' >%UCX-W-NORECORD, Information not foundr6 >-UCX-E-BIND_NO_INFORMA, The server has no information  C Seems logical. A Secondary without cached data and no connection to=  the primary is short of infos...  , >I would like to exclude VMS problem source.  G I think, UCX V3.2 is old crap but is not the reason for your problem...-   >$ nslookup2 >Default Server:  localhostm >Address:  127.0.0.1 >s >> ls -d bla.bla.bla >[localhost]6 >*** Can't list domain academy.kiev.ua: No information  - Yup, as you said, the secondary DNS is empty.    >> server primaryn >Default Server:  primary- >Address:  10.0.4.1- >  >> ls -d bla.bla.bla
 >[[10.0.4.1]]i7 > bla.bla.bla.               SOA   primary.bla.bla.blaa2> >administrator.bla.bla.ua. (2004063012 3600 600 1209600 86400) >t >t
 >Then *hangs*   0 And this is exactly the problem. On the primary.I It should list the whole zone starting and ending with (the same) SOA RR. A So digging there in the event log and the config tabs may help...e   >$ telnet primary 53 >Trying...10.0.4.1 >Connected to PRIMARY. >Escape character is '^]'.  8 Ok. DNS Server is running on the primary (as you wrote).  J Do you have another BIND 4 server for a test ? Configure it as a secondary7 and try if it also have the same problem as UCX V3.2...d  	 Good luck    --   Peter "EPLAN" LANGSTOEGERt% Network and OpenVMS system specialist0 E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------   Date: 2 Jul 2004 13:02:03 -0500K; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 0 Subject: Re: slap in the face again... thanks HP3 Message-ID: <3f$n$wGSrmL5@eisner.encompasserve.org>i  r In article <dfff2914e2163e0a0bfac01d6a917575@news.teranews.com>, JF Mezei <"jfmezei"@spamnot@teksavvy.com> writes:   > backup/image/ignore=interlocke  G    ghost is what we use for the equivalent of backup/image, but I don'tp    know about /interlock.e   ------------------------------   Date: 2 Jul 2004 13:03:34 -0500_; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)D0 Subject: Re: slap in the face again... thanks HP3 Message-ID: <iZvzZbrBt3nn@eisner.encompasserve.org>   h In article <cfm7e0p31n1akur3m6msgicjfv979cm06t@4ax.com>, John Laird <nospam@laird-towers.org.uk> writes: > = > No o/s can call itself "serious" without such a tool, imho.e  H    What do you expect when the cover letter says it's not to be used for    critical appliations?   ------------------------------  % Date: Fri, 02 Jul 2004 20:14:43 +0100w- From: John Laird <nospam@laird-towers.org.uk>w0 Subject: Re: slap in the face again... thanks HP8 Message-ID: <k0dbe098dlm8t8oj4bu13b7k6ac6d77bbp@4ax.com>  J On 2 Jul 2004 13:03:34 -0500, koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:-  i >In article <cfm7e0p31n1akur3m6msgicjfv979cm06t@4ax.com>, John Laird <nospam@laird-towers.org.uk> writes:t >> a> >> No o/s can call itself "serious" without such a tool, imho. >cI >   What do you expect when the cover letter says it's not to be used fore >   critical appliations?o   It does ?!!g   -- t' Me a skeptic?  I trust you have proof. i   Mail john rather than nospam...f   ------------------------------   Date: 2 Jul 2004 12:30:08 -0500f; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)m Subject: Re: smile, be happy3 Message-ID: <e4o4kIlCDjPu@eisner.encompasserve.org>p  t In article <40e32f97$0$4587$db0fefd9@news.zen.co.uk>, "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk> writes: > K > The rx1600 isn't 'supported' with V8.1, but being an Eval release its notk> > like you getting proper support with whatever you run it on.  F    It wasn't clear to me that V8.1 would boot on an rx1600, not just aD    matter of whether VMS Engineering would officially support 8.1 on    anything.  E    I think to get some support for 8.1 you may have to be in the beta-H    test program.  Somehow I don't think the purpose of letting folks buy2    8.1 for $99 (or was it $75?) excluded feedback.   ------------------------------   Date: 2 Jul 2004 10:57:29 -0700c$ From: gspamtackett@yahoo.com (Galen)- Subject: Re: Split I/Os to contiguous file???i= Message-ID: <bdc65a53.0407020957.4cac90cc@posting.google.com>n  F I finally got the right syntax to use the system console to change the' value of UCB$L_MAXBCNT for this device.h  > Halving the value had a marked negative impact on performance.5 (Halving it again REALLY slowed things to a crawl :-)   A Doubling it had no visible effect on performance, and also didn'tv@ crash the system or cause any errors to be logged. I'm not brave& enough yet to double it one more time!  @ 256 blocks per I/O, or thereabouts, produces the highest KB/sec.  F FEI (for everyone's information) here's a little summary of the story:  3 System:     ES40 EV6/500MHz, 1 GB RAM on 4 arrays, e  < Controller: KZPDC SmartArray 5304A "Ramanujan", 512 MB cacheC             installed in a slot on an otherwise empty 33MHz PCI bus C             Note: NOT officially supported on this model ES40, but u$             works okay for me. YMMV.  E Storage:    14x HP 36gig 15Krpm UltraSCSI III (Exact model uncertain)s:             spread 4/3/4/3 across the KZPDC's 4 SCSI ports  > O/S:        OpenVMS V7.3-2 w/ patches current as of yesterday.  F Benchmark:  HP's internal IOHAMMER (customized slightly by me to allowE             larger I/O sizes and to avoid 32-bit integer overflow in i             rate computation)k  = Measured Maximum Performance (roughly) found at 256 blocks/IO (   synchronous:  128 MB/sec,  983 IO/sec B  Asynchronous:  147 MB/sec, 1128 IO/sec, avg. queue depth set to 2      J > >> Now the problem is to determine whether the split I/Os are really the- > >> big limiting factor on write throughput.  > > F > > Try cutting the UCB$L_MAXBCNT value in half and seeing if there is > > an effect. > > 8 > > CMKRNL is your friend (at least on test systems :-). > @ >   Heck, I was thinking he oughtta double the value, and see if@ > it's just pro forma, or if it is a real limitation...on a test > system, of course. > H >   CMKRNL usage is always good for something - even when it goes wrong,? > you get excellent practice material for reading a crash dump.s >  > Lee K. Gleason N5ZMR > Control-G Consultants  > lgleason@houston.rr.com,   ------------------------------  # Date: Sat, 03 Jul 2004 03:54:57 GMT , From: "Dave Gudewicz" <k9jdk@NOSPAMarrl.net>" Subject: Very nice VMS testimonial, Message-ID: <l6qFc.16860$Oq2.1646@attbi_s52>  1 http://h71000.www7.hp.com/openvms/brochures/lutz/   7 If you cannot run the video, there's a text transcript.   0 Another step.  Not backwards, but the other way.   Dave...t   ------------------------------  $ Date: Fri, 2 Jul 2004 20:49:15 +0100' From: "BobbydaMong" <bobby@nowhere.com>H# Subject: VMS on VAXstation 3100 M76m+ Message-ID: <cc4e7v01ce9@news3.newsguy.com>>  L Hey there... have a VAXstation 3100 M76, and would like to boot it...! Can't even do that at the mo'...  J Have a VMS7.3 CD to boot from, but booting from a Sun single-speed / caddy CDROM gets :   >>> boot dkb100i  L DKBTDRIVER halting at relative address 041A  DKBTDRIVER base addr = 0000163CE REGISTERS   R0: 00000054   R1: 00000003   R2: 2008000F   R3: 00000000nE             R4: 00000000   R5: 00000040   R6: 0000165C   R7: 200C0180rE             R8: 0000000C   R9: 00000000  R10: 00007200  R11: 00000000 7 CMDBUF: 00000800 00000306  SENSE_BUF: 08000000 00060070m+ STATUS_BUF: 02             SENSE_STATUS: 00 I MSG_IN_BUF: 00             SENSE_MSG_IN: 00         SENSE_INDEX: FFFFFFFFeL USER_BUF_ADDR: 00000000    TOTAL_XFER_COUNT: 00000000   BYTES_LEFT: 00000000H PG_TABLE_PTR: 00000000     BASE_VPN: 00000000       BUFFER_PTR: 00000000 MAP_MODE: 00000000 STACK:  00001A3D         00002450         00000210         00001B5E         000019B5         0000197B   ?06 HLT INST     PC = 00002ADCv  E This CD happily installs under SIMH / VAX... it's just a bit slow :-)t  
 Many thanks!!d  - Hmmm... Your help would be much appreciated!!e   ------------------------------  $ Date: Fri, 2 Jul 2004 21:08:39 +0100' From: "BobbydaMong" <bobby@nowhere.com>t' Subject: Re: VMS on VAXstation 3100 M76l+ Message-ID: <cc4fca01hv1@news1.newsguy.com>u  L Hmmmm... one thing... does this need a ROM update? - if so, does anyone know where I can get one...   Many thanks again...  2 "BobbydaMong" <bobby@nowhere.com> wrote in message% news:cc4e7v01ce9@news3.newsguy.com...iH > Hey there... have a VAXstation 3100 M76, and would like to boot it...! Can'te > even do that at the mo'... > L > Have a VMS7.3 CD to boot from, but booting from a Sun single-speed / caddy > CDROM gets : >s > >>> boot dkb100t >oE > DKBTDRIVER halting at relative address 041A  DKBTDRIVER base addr =, 0000163CG > REGISTERS   R0: 00000054   R1: 00000003   R2: 2008000F   R3: 00000000nG >             R4: 00000000   R5: 00000040   R6: 0000165C   R7: 200C01804G >             R8: 0000000C   R9: 00000000  R10: 00007200  R11: 00000000R9 > CMDBUF: 00000800 00000306  SENSE_BUF: 08000000 00060070e- > STATUS_BUF: 02             SENSE_STATUS: 00eK > MSG_IN_BUF: 00             SENSE_MSG_IN: 00         SENSE_INDEX: FFFFFFFFlE > USER_BUF_ADDR: 00000000    TOTAL_XFER_COUNT: 00000000   BYTES_LEFT:o 00000000J > PG_TABLE_PTR: 00000000     BASE_VPN: 00000000       BUFFER_PTR: 00000000 > MAP_MODE: 00000000 > STACK:  00001A3D >         00002450 >         00000210 >         00001B5E >         000019B5 >         0000197B >c > ?06 HLT INST >     PC = 00002ADCa >oG > This CD happily installs under SIMH / VAX... it's just a bit slow :-)e >e > Many thanks!!a >t/ > Hmmm... Your help would be much appreciated!!a >n >h   ------------------------------  $ Date: Fri, 2 Jul 2004 17:38:21 -0400# From: "R P" <petersra@sympatico.ca>g' Subject: Re: VMS on VAXstation 3100 M76w; Message-ID: <hBkFc.90804$Ax1.1232357@news20.bellglobal.com>r  2 "BobbydaMong" <bobby@nowhere.com> wrote in message% news:cc4fca01hv1@news1.newsguy.com...oI > Hmmmm... one thing... does this need a ROM update? - if so, does anyonet know > where I can get one... >  > Many thanks again... > 4 > "BobbydaMong" <bobby@nowhere.com> wrote in message' > news:cc4e7v01ce9@news3.newsguy.com...sJ > > Hey there... have a VAXstation 3100 M76, and would like to boot it...! > Can'te > > even do that at the mo'... > >eH > > Have a VMS7.3 CD to boot from, but booting from a Sun single-speed / caddyh > > CDROM gets : > >i > > >>> boot dkb100- > >sG > > DKBTDRIVER halting at relative address 041A  DKBTDRIVER base addr =v
 > 0000163CI > > REGISTERS   R0: 00000054   R1: 00000003   R2: 2008000F   R3: 00000000 I > >             R4: 00000000   R5: 00000040   R6: 0000165C   R7: 200C0180dI > >             R8: 0000000C   R9: 00000000  R10: 00007200  R11: 00000000I; > > CMDBUF: 00000800 00000306  SENSE_BUF: 08000000 00060070t/ > > STATUS_BUF: 02             SENSE_STATUS: 00rD > > MSG_IN_BUF: 00             SENSE_MSG_IN: 00         SENSE_INDEX: FFFFFFFFG > > USER_BUF_ADDR: 00000000    TOTAL_XFER_COUNT: 00000000   BYTES_LEFT:t
 > 00000000L > > PG_TABLE_PTR: 00000000     BASE_VPN: 00000000       BUFFER_PTR: 00000000 > > MAP_MODE: 00000000 > > STACK:  00001A3D > >         00002450 > >         00000210 > >         00001B5E > >         000019B5 > >         0000197B > >e > > ?06 HLT INST > >     PC = 00002ADC  > >oI > > This CD happily installs under SIMH / VAX... it's just a bit slow :-)t > >  > > Many thanks!!e > > 1 > > Hmmm... Your help would be much appreciated!!  > >  > >o >e >c' Does the drive support 512byte blocks ?e   ------------------------------  $ Date: Fri, 2 Jul 2004 23:29:10 +0100" From: "SCC" <simonc99@hotmail.com>' Subject: Re: VMS on VAXstation 3100 M762+ Message-ID: <cc4njq01r25@news1.newsguy.com>b  D Also, this drive does the same thing if I try and boot netbsd from a bootable image...i  - "SCC" <simonc99@hotmail.com> wrote in messageh% news:cc4n9n01qof@news1.newsguy.com...nJ > Hi - cheers for getting back - Yeah think so - it works OK for a SolarisK > install (the drive is a Sony CDU-8012) Do you know how I can tell if this  is > a 512K block?? >i0 > "R P" <petersra@sympatico.ca> wrote in message7 > news:hBkFc.90804$Ax1.1232357@news20.bellglobal.com...z > >t6 > > "BobbydaMong" <bobby@nowhere.com> wrote in message) > > news:cc4fca01hv1@news1.newsguy.com...sF > > > Hmmmm... one thing... does this need a ROM update? - if so, does anyone > > know > > > where I can get one... > > >  > > > Many thanks again... > > >a8 > > > "BobbydaMong" <bobby@nowhere.com> wrote in message+ > > > news:cc4e7v01ce9@news3.newsguy.com...eG > > > > Hey there... have a VAXstation 3100 M76, and would like to booth it...! > > > Can't " > > > > even do that at the mo'... > > > >cL > > > > Have a VMS7.3 CD to boot from, but booting from a Sun single-speed /	 > > caddy  > > > > CDROM gets : > > > >h > > > > >>> boot dkb100p > > > >pK > > > > DKBTDRIVER halting at relative address 041A  DKBTDRIVER base addr =  > > > 0000163CD > > > > REGISTERS   R0: 00000054   R1: 00000003   R2: 2008000F   R3: 00000000D > > > >             R4: 00000000   R5: 00000040   R6: 0000165C   R7: 200C0180D > > > >             R8: 0000000C   R9: 00000000  R10: 00007200  R11: 00000000? > > > > CMDBUF: 00000800 00000306  SENSE_BUF: 08000000 00060070.3 > > > > STATUS_BUF: 02             SENSE_STATUS: 00iH > > > > MSG_IN_BUF: 00             SENSE_MSG_IN: 00         SENSE_INDEX: > > FFFFFFFFK > > > > USER_BUF_ADDR: 00000000    TOTAL_XFER_COUNT: 00000000   BYTES_LEFT:  > > > 00000000G > > > > PG_TABLE_PTR: 00000000     BASE_VPN: 00000000       BUFFER_PTR:o
 > 00000000 > > > > MAP_MODE: 00000000 > > > > STACK:  00001A3D > > > >         00002450 > > > >         00000210 > > > >         00001B5E > > > >         000019B5 > > > >         0000197B > > > >e > > > > ?06 HLT INST > > > >     PC = 00002ADC  > > > >tI > > > > This CD happily installs under SIMH / VAX... it's just a bit slow  :-)c > > > >o > > > > Many thanks!!n > > > > 5 > > > > Hmmm... Your help would be much appreciated!!g > > > >w > > > >  > > >a > > >t+ > > Does the drive support 512byte blocks ?i > >o > >- >l >w   ------------------------------  $ Date: Fri, 2 Jul 2004 23:23:47 +0100" From: "SCC" <simonc99@hotmail.com>' Subject: Re: VMS on VAXstation 3100 M76r+ Message-ID: <cc4n9n01qof@news1.newsguy.com>4  H Hi - cheers for getting back - Yeah think so - it works OK for a SolarisL install (the drive is a Sony CDU-8012) Do you know how I can tell if this is a 512K block??  . "R P" <petersra@sympatico.ca> wrote in message5 news:hBkFc.90804$Ax1.1232357@news20.bellglobal.com...i >t4 > "BobbydaMong" <bobby@nowhere.com> wrote in message' > news:cc4fca01hv1@news1.newsguy.com...eK > > Hmmmm... one thing... does this need a ROM update? - if so, does anyoner > know > > where I can get one... > >  > > Many thanks again... > >d6 > > "BobbydaMong" <bobby@nowhere.com> wrote in message) > > news:cc4e7v01ce9@news3.newsguy.com...lL > > > Hey there... have a VAXstation 3100 M76, and would like to boot it...!	 > > Can't-  > > > even do that at the mo'... > > >rJ > > > Have a VMS7.3 CD to boot from, but booting from a Sun single-speed / > caddys > > > CDROM gets : > > >0 > > > >>> boot dkb100- > > >pI > > > DKBTDRIVER halting at relative address 041A  DKBTDRIVER base addr =R > > 0000163CK > > > REGISTERS   R0: 00000054   R1: 00000003   R2: 2008000F   R3: 00000000aK > > >             R4: 00000000   R5: 00000040   R6: 0000165C   R7: 200C0180xK > > >             R8: 0000000C   R9: 00000000  R10: 00007200  R11: 00000000-= > > > CMDBUF: 00000800 00000306  SENSE_BUF: 08000000 00060070M1 > > > STATUS_BUF: 02             SENSE_STATUS: 00:F > > > MSG_IN_BUF: 00             SENSE_MSG_IN: 00         SENSE_INDEX:
 > FFFFFFFFI > > > USER_BUF_ADDR: 00000000    TOTAL_XFER_COUNT: 00000000   BYTES_LEFT:t > > 00000000E > > > PG_TABLE_PTR: 00000000     BASE_VPN: 00000000       BUFFER_PTR:& 00000000 > > > MAP_MODE: 00000000 > > > STACK:  00001A3D > > >         00002450 > > >         00000210 > > >         00001B5E > > >         000019B5 > > >         0000197B > > >s > > > ?06 HLT INST > > >     PC = 00002ADCo > > >mK > > > This CD happily installs under SIMH / VAX... it's just a bit slow :-)l > > >i > > > Many thanks!!M > > >o3 > > > Hmmm... Your help would be much appreciated!!  > > >l > > >f > >  > >s) > Does the drive support 512byte blocks ?o >  >o   ------------------------------  $ Date: Fri, 2 Jul 2004 22:54:00 +0100" From: "SCC" <simonc99@hotmail.com> Subject: VMS7.2 on VAX+ Message-ID: <cc4lhs03143@news4.newsguy.com>O  L Hey there... I'm a bit new to this DECs stuff... I'd appreciate your help...  $ Anyone know where I can get either :  8 A ROM update for a VAXstation 3100M76 to run OpenVMS7.3?  1 Or a version of VMS that will boot on it 'as is'?a   A "show ver" gives...o   >>> show ver   KA43-A  V1.20C-185-V1.6-26A          PST: 185         CON: 20C         VMB: V1.6m         ROM: 26A   ------------------------------   Date: 2 Jul 2004 11:16:50 -0700 . From: spamsink2001@yahoo.com (Alan E. Feldman): Subject: Re: When to use INIT/WINDOWS, SET VOLUME /WINDOWS= Message-ID: <b096a4ee.0407021016.3439990b@posting.google.com>s  h Wilm Boerhout <w3.boerhout@planet.nl> wrote in message news:<40e4577a$0$2736$ba620dc5@nova.planet.nl>... > Alan E. Feldman wrote:H > > When is it appropriate to use the /WINDOWS qualifier for INIT or SETH > > VOLUME? If this affects performance, why isn't it in the Performance > > Manaual? > G >  From the obscure but supposedly still valid "OpenVMS and Windows NT  8 > Integration Manual", Section IV, Uninstall Procedures: > I > "The $ INIT /[NO]WINDOWS and SET VOL /[NO]WINDOWS command are used for oF > the occasion that the system manager defines sharable drives on his D > OpenVMS system, but does not want those drives to be populated by  > Windows system or user files.  > I > The command $ INIT DKA100: /NOWINDOWS ensures that no file originating  G > from a Windows system will ever be added to the file system on drive  
 > DKA100:.   Better yet:t       $ SET WORLD/NOWINDOWS)  J > The non-negating form (e.g.: SET VOLUME /WINDOWS) is rarely seen in the 	 > field."s   ------------------------------   End of INFO-VAX 2004.364 ************************