1 INFO-VAX	Tue, 23 Nov 2004	Volume 2004 : Issue 651       Contents:& Re: %SYSTEM-F-ACCVIO, access violation< Re: Any reason why MSL5026S2 wouldn't want to show me tapes? Any VMS bloggers at HP? 5 Re: Apache (CSWS) Index of files (configure width of) 5 Re: Apache (CSWS) Index of files (configure width of) > Re: AST routine and C language va_count, va_start, va_end, etc> Re: AST routine and C language va_count, va_start, va_end, etc> Re: AST routine and C language va_count, va_start, va_end, etc0 Re: BM benchmark leaves server rivals breathless DEC-C and DECwindows includes ! Re: DEC-C and DECwindows includes ! Re: DEC-C and DECwindows includes ! Re: DEC-C and DECwindows includes ! Re: DEC-C and DECwindows includes ! Re: DEC-C and DECwindows includes ! Re: DEC-C and DECwindows includes ! Re: DEC-C and DECwindows includes ! Re: DEC-C and DECwindows includes ! Re: DEC-C and DECwindows includes ! RE: DECnet positively in the news ! RE: DECnet positively in the news ! Re: DECnet positively in the news ! Re: DECnet positively in the news ! Re: DECnet positively in the news  Re: DECW$CLOCK design flaw ! Re: DECW$CLOCK design flaw ! Re: DECW$CLOCK design flaw ! Re: DECW$CLOCK design flaw !6 Re: f$device( "*", "DISK", , ) v. "ESS1888 AudioDrive"6 Re: f$device( "*", "DISK", , ) v. "ESS1888 AudioDrive"" Re: FAST BOOT OF SIMH VAX Emulator" Re: FAST BOOT OF SIMH VAX Emulator" Re: FAST BOOT OF SIMH VAX Emulator" Re: FAST BOOT OF SIMH VAX EmulatorP Re: interesting take on Olsen's "no reason for any individual to have a  computeP Re: interesting take on Olsen's "no reason for any individual tohave a computer P Re: interesting take on Olsen's "no reason for any individual tohave a computer P Re: interesting take on Olsen's "no reason for any individual tohave a computer P Re: interesting take on Olsen's "no reason for any individual tohave acomputer i My home page Re: NFS Problem with AIX, Re: Online forums for former digits/deccies? RE: OpenVMS Support Chart ?  Re: OpenVMS Support Chart ?  Re: OpenVMS Support Chart ?  Re: OpenVMS Support Chart ?  Re: OpenVMS Support Chart ?  Re: OpenVMS Support Chart ?  Re: OpenVMS Support Chart ?  Re: OT: Joke of the week Re: OT: Joke of the week Re: OT: Joke of the week RE: OT: Joke of the week Re: OT: Joke of the week Re: OT: Joke of the week7 Question asked should OpenVMS be used for the web - DA! 9 Re: Re-post on TechWorld of OpenVMS: Survives and Thrives 9 Re: Re-post on TechWorld of OpenVMS: Survives and Thrives 1 Re: reporter inquiry: Is HP selling AlphaServers? 1 Re: reporter inquiry: Is HP selling AlphaServers? 1 Re: reporter inquiry: Is HP selling AlphaServers? 1 Re: reporter inquiry: Is HP selling AlphaServers? 1 Re: reporter inquiry: Is HP selling AlphaServers? $ Re: SYS$GETMSG bug ( false alarm :-(# SYS$GETMSG bug ( RADRMOD or OPCDEC) D Re: The Register: AMD's Opteron loses ground where it kind of counts Re: Upgrading HSG80 Firmware. D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.D Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.- [OT]: From the Department of Patent Stupidity   F ----------------------------------------------------------------------    Date: 23 Nov 2004 02:29:45 -0800. From: martinkirby12@yahoo.co.uk (Martin Kirby)/ Subject: Re: %SYSTEM-F-ACCVIO, access violation < Message-ID: <224291b.0411230229.12d19767@posting.google.com>  n himanshu.patni@gmail.com (Himanshu) wrote in message news:<19cf7b88.0411160210.4ab5c5a1@posting.google.com>...= > %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual , > address=42441430, PC=00030A1C, PS=0000001B  3 The virtual address looks vaguely ASCII like to me. 9 I suspect a buffer overrun from a string has corrupted a   pointer.   Martin Kirby   ------------------------------  + Date: Tue, 23 Nov 2004 17:54:02 +0000 (UTC) , From: lewis@PROBE.MITRE.ORG (Keith A. Lewis)E Subject: Re: Any reason why MSL5026S2 wouldn't want to show me tapes? . Message-ID: <cnvtfq$hu0$1@newslocal.mitre.org>   winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) writes in article <00A3B450.1C4C0C41@SSRL.SLAC.STANFORD.EDU> dated Tue, 23 Nov 2004 03:15:36 GMT:J >Does this make sense?  Does anyone have any clues for me?  Quick scan  ofN >user's guide (located under www.hp.com/go/storage after a kind pointer from aL >comp.os.vms poster) didn't have anything that leapt out at me as addressing >this problem.  L I have one more clue to give on this subject.  My drive has a mode which youL can set from the LCD console where it delivers the tapes sequentially to theJ drive (i.e. DISMOUNT/UNLOAD causes the robot to load a fresh tape from theI next slot) rather than letting the ROBOT command do it.  I don't remember K the name of the feature, but it needs to be off in order to randomly access  the tapes like you want.  0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------  % Date: Tue, 23 Nov 2004 13:24:50 -0500 # From: "John Smith" <a@nonymous.com>   Subject: Any VMS bloggers at HP?, Message-ID: <I_Gdnf1nVcJVHz7cRVn-sg@igs.net>  ) http://devresource.hp.com/blogs/index.jsp    ------------------------------  % Date: Tue, 23 Nov 2004 08:33:11 +0100  From: Dirk Munk <munk@home.nl>> Subject: Re: Apache (CSWS) Index of files (configure width of)2 Message-ID: <cnup43$nn7$1@news2.zwoll1.ov.home.nl>  6 I haven't tried this, so I don't know if it will work.  J When Apache shows a directory, there is also a (rather wide) column for a M description of the files. Most likely this column is empty, unless there are  N html files in the directory. You can configure Apache in such a way that this O column is not shown. With some luck this will result in a wider column for the  P file name. It has been a long time since I read this, so I'm sorry that I can't ( give you any more information right now.       John Brandon wrote: L > In Apache (CSWS) and using no index.html (or other DirectoryIndex for thatD > matter) the output truncates the file name width to 23 characters. > C > I want to increase this value so I can see more of the file name.  >  > Is there a way to do this? > K > I have been looking through the HTTPD.CONF file and can not find anything " > specific to the control of this. > * > I have IndexOptions set to FancyIndexing >  >  > John "REBOOT" Brandon  > VMS Systems Administrator , > firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  % Date: Tue, 23 Nov 2004 10:02:12 -0600 ( From: brandon@dalsemi.com (John Brandon)> Subject: Re: Apache (CSWS) Index of files (configure width of)1 Message-ID: <04112310021225@dscis6-0.dalsemi.com>    Dirk Munk wrote:L > When Apache shows a directory, there is also a (rather wide) column for a O > description of the files. Most likely this column is empty, unless there are  P > html files in the directory. You can configure Apache in such a way that this Q > column is not shown. With some luck this will result in a wider column for the  R > file name. It has been a long time since I read this, so I'm sorry that I can't * > give you any more information right now.  P I dug around on apache.org and found information on the IndexOptions directive.     ! One of the options as you say is:   2 DescriptionWidth=[n | *] (Apache 1.3.10 and later)G     The DescriptionWidth keyword allows you to specify the width of the K     description column in characters. If the keyword value is '*', then the N     column is automatically sized to the length of the longest filename in the     display.   And the option I want is:   * NameWidth=[n | *] (Apache 1.3.2 and later)I     The NameWidth keyword allows you to specify the width of the filename D     column in bytes. If the keyword value is '*', then the column isM     automatically sized to the length of the longest filename in the display.     / I used both and was able to lengthen NameWidth.    Thanks for the input!      John "REBOOT" Brandon  VMS Systems Administrator * firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  % Date: Tue, 23 Nov 2004 08:49:00 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> G Subject: Re: AST routine and C language va_count, va_start, va_end, etc , Message-ID: <41A33FBC.552500D8@teksavvy.com>   Mark Daniel wrote: > @ > I would like to use the C langauge va_count() in a function toG > distinguish between direct and AST use of the function.  For example:   N You may also want to look into LIB$AST_IN_PROG(). It returns true is an AST is% currently in progress , false if not.   K If LIB$AST_IN_PROG returns true, is this a 100% proof than the current code N executes in AST mode? (i.e. does the LIB$AST_IN_PROG code have a certain levelG of atomaticity to it the would prevent it from seeing an AST that would 0 execute while the LIB$ routine was in progress ?   ------------------------------  % Date: Tue, 23 Nov 2004 08:09:08 -0800  From: Z <z@no.spam> G Subject: Re: AST routine and C language va_count, va_start, va_end, etc * Message-ID: <EhJod.2317$211.1177@fe12.lga>   Mark Daniel wrote:A > I would like to use the C langauge va_count() in a function to  G > distinguish between direct and AST use of the function.  For example:  > * >   myFunction (int a1, int, a2, int a3) { >      int  argcount;  >      va_count (argcnt) >      if (argcnt == 3) { % >         /* direct call behaviour */  > 
 >      else { " >         /* AST call behaviour */ >      } >   }  > K > The idea being with all direct calls three arguments are always supplied  4 > but with an AST only the one (the user parameter). > + > Is this usage of va_count() valid?   TIA.   C Even if that would compile and run, there are so many better (less  E confusing, easier to understand, easier to support/maintain) ways to   accomplish what you want.   G eg: AST to an intermediate func that calls myFunction() with arguments  C that indicate "called by AST." Or, the converse: direct call to an  E intermediate func() which calls myFunction(). Or even one consistent  B calling argument and use the appropriate LIB$ function to tell if  you're in AST-mode.   G Also, if your routine is non-reentrant, you want to disable ASTs while  F in myFunction() to prevent direct call mode from being interrupted by ) the AST that will call the same function.    ------------------------------  % Date: Wed, 24 Nov 2004 03:49:26 +1030 * From: Mark Daniel <mark.daniel@vsm.com.au>G Subject: Re: AST routine and C language va_count, va_start, va_end, etc - Message-ID: <41a37140@duster.adelaide.on.net>    Z wrote: > Mark Daniel wrote: > B >> I would like to use the C langauge va_count() in a function to H >> distinguish between direct and AST use of the function.  For example: >>+ >>   myFunction (int a1, int, a2, int a3) {  >>      int  argcount; >>      va_count (argcnt)  >>      if (argcnt == 3) {& >>         /* direct call behaviour */ >> >>      else {# >>         /* AST call behaviour */ 	 >>      }  >>   } >>C >> The idea being with all direct calls three arguments are always  > >> supplied but with an AST only the one (the user parameter). >>, >> Is this usage of va_count() valid?   TIA. >  > E > Even if that would compile and run, there are so many better (less    F It will compile and is in use as I write.  Well, the actual code, not I the illustration (which is missing a brace for starters).  I was getting  L an occasional AST fault which prompted this query.  Coding error, of course.  G > confusing, easier to understand, easier to support/maintain) ways to   > accomplish what you want.   H In context it seems an elegant solution.  A single function to initiate 6 and then run through to completion over multiple I/Os.  I > eg: AST to an intermediate func that calls myFunction() with arguments  E > that indicate "called by AST." Or, the converse: direct call to an  G > intermediate func() which calls myFunction(). Or even one consistent  K > calling argument and use the appropriate LIB$ function to tell if you're   > in AST-mode.  E I like this solution because it relies on something intrinsic to the  I usage (the call stack), not extrinsic mechanisms such as flags being set  I and (forgotten to be) reset, or additional layers of code. I am assuming  * the va_count() is relatively cheap though.  I > Also, if your routine is non-reentrant, you want to disable ASTs while  H > in myFunction() to prevent direct call mode from being interrupted by + > the AST that will call the same function.   I It is called directly from within another AST routine and then by AST so  G the appropriate libary routines for detecting and controlling AST mode   are not appropriate here.   F +--------------------------------------------------------------------+E   Mark Daniel                         http://wasd.vsm.com.au/adelaide F   mailto:Mark.Daniel@wasd.vsm.com.au (Mark.Daniel@dsto.defence.gov.au);   A pox on the houses of all SPAMers.  Make that two poxes. F +--------------------------------------------------------------------+   ------------------------------  % Date: Tue, 23 Nov 2004 11:50:40 -0500 # From: "John Smith" <a@nonymous.com> 9 Subject: Re: BM benchmark leaves server rivals breathless , Message-ID: <_JGdnTD_UOz_9z7cRVn-qQ@igs.net>   Bill Todd wrote:0 > "John Smith" <a@nonymous.com> wrote in message( > news:XeOdnUoea5ujggDcRVn-2Q@igs.net... >> Warren Spencer wrote:= >>> Looks like Itanium is eating dust (yet again?).  Um, wow:  >>> ? >>> http://www.theregister.co.uk/2004/11/18/ibm_shatterrs_tpcc/  >>; >> Guess it's time for intel to ship the dual-core EV8..er,  >> um...Itanium 3. >>C >> Wouldda been on the market round about now too if not for curly.  > 0 > Well, no.  But the single-core EV8 would have. > F > Whether a 32-processor EV8 system could have matched the performanceF > of the new 64-processor (32-chip) POWER5 may be questionable, thoughF > I think that with its 4-way SMT (the POWER5 is only 2-way, per core)C > it could at least have come close.  But a 64-processor EV8 system G > should have been able to blow the POWER5 system pretty well away, and D > IIRC the design allowed at least up to 128 processors (that may inG > fact be the EV7 design, though - I have at least a vague recollection B > that the EV8 limit was even higher), while the POWER5 is already > maxed out in size. > B > Montecito should close some, but not nearly all, of the vast gapE > behind POWER5 about a year from now (it seems to be slowly slipping B > toward a 2006 release date, but may not quite be there yet).  OfE > course, by then POWER5+ in 90 nm. will be out, upping the ante once G > again (though not nearly as dramatically as this time, unless the max B > system size also increases).  And dual-core Opterons in at leastD > 32-core Opteron systems will also be shipping by then to cover the7 > cost-conscious portion of the upper-mid-range market.  > G > The basic problem with Itanic (aside from its brute-force use of chip E > area and power consumption, the former of which won't improve until F > Tukwila appears in 2007 but the latter of which may get some respiteG > with Montecito if the rumors of major improvements in efficiency turn E > out to be more realistic than many past Itanic projections have) is C > the lack of a decent system architecture to go with it, in marked F > contrast to POWERx, EVx, and even SPARC.  SGI is to be commended for: > lashing together dual-processor Itanic boards into largeF > configurations which scale remarkably well for HPC purposes, but has9 > never demonstrated their ability to scale well for more = > commercially-oriented workloads (i.e., those which are less > > fully-partitionable and entail somewhat more inter-processorF > cooperation, such as TPC-C, where HP's large-system Itanic offerings= > scale rather poorly in comparison with POWER4+'s, let alone  > POWER5's). > B > So, alas, Itanic continues along pretty much the path some of usE > foresaw over 3 years ago, much like an ocean liner with a huge hole B > in its bow but with engines just strong enough to keep said holeD > above the waterline as long as they're reved hard enough.  WhetherF > Intel has enough fuel - and patience - to keep those engines turningB > fast until the Alpha team ships a patch for the hole remains theE > question of the day.  Even if the answer turns out to be 'yes', the F > question then will be just how well Tukwila will fare against POWER6? > and the K10 Opterons, and all those products are sufficiently G > shrouded that I don't have the slightest clue what the answer may be.     ; What a great synopsis - I'll be sharing this a lot. Thanks.    ------------------------------  % Date: Tue, 23 Nov 2004 05:25:27 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> & Subject: DEC-C and DECwindows includes, Message-ID: <41A30FEA.4144D51D@teksavvy.com>  P Compiling a decwindows application takes a lot longer than regular applications.  K To my dismay, I have found that modules include many other modules, modules ' which would have already been included.   2 For instance, the module XM.H includes apienvset.hK the module LABELG.H includes both XM.H and apienvset.h, so LABELG.H ends up  including apienvset twice.  I XM.H also includes a whole bunch of includes, such as intrinsics.h, Shell L Xatom XmStrdef VirtKeys etc etc many of which are included by the programmer before including XM.h anyways.    M So, basically, for every widget that you include, it reloads a whole bunch of J files that have already been loaded many times already. (and many of these> files that get reloaded in turn reload another bunch of files.  M Does the DEC-C compiler complain/detect recursive includes ? Does it complain N when it encounters it or just dismiss an #include that would cause recursion ?  G And if a module has already been included, does it dismiss the #include < directive, or does it actually repreocess the include file ?    N Perhaps judicious use of #ifdef statements could avoid re-inclusion of modules  that have already been included.   ------------------------------  % Date: Tue, 23 Nov 2004 13:12:51 +0100 ' From: JOUKJ <joukj@hrem.stm.tudelft.nl> * Subject: Re: DEC-C and DECwindows includes* Message-ID: <cnv9g4$1i6$1@news.tudelft.nl>   JF Mezei wrote:  > O > Does the DEC-C compiler complain/detect recursive includes ? Does it complain P > when it encounters it or just dismiss an #include that would cause recursion ? > I > And if a module has already been included, does it dismiss the #include > > directive, or does it actually repreocess the include file ?F When You do a cc/show=all/list at least the list file shows that each E include file is included at most once, otherwise it is skipped. This   holds for both cases above.                     Jouk    ------------------------------  % Date: Tue, 23 Nov 2004 08:03:12 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> * Subject: Re: DEC-C and DECwindows includes, Message-ID: <41A33504.36CD5AD9@teksavvy.com>   JOUKJ wrote:G > When You do a cc/show=all/list at least the list file shows that each F > include file is included at most once, otherwise it is skipped. This > holds for both cases above.   $ OK. I did a SET WATCH FILE/CLASS=DIR  K Indeed, the XM.H only gets searched once. But the APISETENV.H gets included N over and over and over again. (I think ever module includes it at the top, and APIENVRST at bottom).   E The APIENVSET and APIENVRST seem to always be part of an #ifdef (VMS) N condition, wheras, in the case of labelG, the #include <Xm/XM.h> is not in anyI conditional code. Maybe the compiler will re-include headers when part fo E conditional code, but is smart enough to ignre a #include that is non - conditional if it has already been included ?    ------------------------------  % Date: Tue, 23 Nov 2004 07:34:43 -0600 6 From: "Craig A. Berry" <craigberry@mac.com.spamfooler>* Subject: Re: DEC-C and DECwindows includesD Message-ID: <craigberry-4943A6.07344223112004@news.isp.giganews.com>  , In article <41A33504.36CD5AD9@teksavvy.com>,/  JF Mezei <jfmezei.spamnot@teksavvy.com> wrote:    > JOUKJ wrote:I > > When You do a cc/show=all/list at least the list file shows that each H > > include file is included at most once, otherwise it is skipped. This > > holds for both cases above.  > & > OK. I did a SET WATCH FILE/CLASS=DIR > M > Indeed, the XM.H only gets searched once. But the APISETENV.H gets included P > over and over and over again. (I think ever module includes it at the top, and > APIENVRST at bottom).  > G > The APIENVSET and APIENVRST seem to always be part of an #ifdef (VMS) P > condition, wheras, in the case of labelG, the #include <Xm/XM.h> is not in anyK > conditional code. Maybe the compiler will re-include headers when part fo G > conditional code, but is smart enough to ignre a #include that is non / > conditional if it has already been included ?   B It's not a feature of the compiler, it's a feature of the include F files.  All the standard headers have an #ifdef surrounding the whole C file so they only get included once.  For example stdlib.h has the  E following as the first two lines and the matching #endif is the last   line in the file:    #ifndef __STDLIB_LOADED  #define __STDLIB_LOADED 1   G so it sounds like apienvset.h is missing this type of macro definition   and "already loaded" check.    ------------------------------  # Date: Tue, 23 Nov 2004 14:00:02 GMT 5 From: "Ed Vogel" <edward.vogel_stop_the_spam.@hp.com> * Subject: Re: DEC-C and DECwindows includes2 Message-ID: <CnHod.3377$jj2.3187@news.cpqcorp.net>  A "Craig A. Berry" <craigberry@mac.com.spamfooler> wrote in message  news:craigberry-> C > It's not a feature of the compiler, it's a feature of the include G > files.  All the standard headers have an #ifdef surrounding the whole D > file so they only get included once.  For example stdlib.h has theF > following as the first two lines and the matching #endif is the last > line in the file:  >  > #ifndef __STDLIB_LOADED  > #define __STDLIB_LOADED 1  > H > so it sounds like apienvset.h is missing this type of macro definition > and "already loaded" check.   =     It's a feature of both the compiler and the header files.   >     When a header file is properly guarded using the mechinismB     Craig describes the compiler notes this and keeps track of theH     file.  If a source attemtps to #include the same file again, and the?     guard macro is FALSE, the compiler will never even open the      include file.   C     This can be a big savings because the compiler does not have to <     open the source and read in all the lines of the source.  L     One way to tell if the compiler has done the "include-once" optimization:     is to look at the listing file when /LIST/SHOW=INCLUDEL     is specified.  The .LIS file puts an X in front of code that is excludedG     from either conditional exclusion or the include-once optimization. G     If an #include directive has an X in the left margin, and is not in F     conditionally excluded code, it has been "include-once" optimized.    F     Note that to do the include-once optimization, the headers must be     guarded properly.        Ed Vogel$     HP/Compaq/DEC C/C++ Engineering.   ------------------------------  % Date: Tue, 23 Nov 2004 09:17:41 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> * Subject: Re: DEC-C and DECwindows includes, Message-ID: <41A34673.CC85211D@teksavvy.com>   "Craig A. Berry" wrote: C > It's not a feature of the compiler, it's a feature of the include G > files.  All the standard headers have an #ifdef surrounding the whole & > file so they only get included once.  L Ahh, but this would still involved the compiler re-opening that include file? and re-parsing it. (granted, skipping almost all its contents).   N the SET WATCH revealed that the compiler didn't do a directory lookup for XM.h* after the LABELG.H was opened for parsing.    N Also. lokoking at xm.h, while it does define a "I have been here", there is noL conditional code in it to prevent its re-execution. (Interestingly, this oneG dating back from 1992 already has the Hewlett Packart copyright in it).    ------------------------------  % Date: Tue, 23 Nov 2004 09:39:19 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> * Subject: Re: DEC-C and DECwindows includes, Message-ID: <41A34B83.754F1E85@teksavvy.com>   Ed Vogel wrote:  > > #define __STDLIB_LOADED 1   H >     Note that to do the include-once optimization, the headers must be >     guarded properly.   K Does the compiler look for __<module_name>_LOADED to be defined, and if so,  ignores the include ?   N In the case of the XM.H module, there is no XM__LOADED defined. They do define
 _Xm_h though.    ------------------------------  % Date: Tue, 23 Nov 2004 06:49:29 -0800  From: Z <z@no.spam> * Subject: Re: DEC-C and DECwindows includes( Message-ID: <Y6Iod.2090$29.946@fe12.lga>   JF Mezei wrote: O > Does the DEC-C compiler complain/detect recursive includes ? Does it complain P > when it encounters it or just dismiss an #include that would cause recursion ?  F No. It includes the file, just as its been told. It has to, since one E or more #defines may have been executed since the last time the file  > was #included and those can change the effect of the #include.    I > And if a module has already been included, does it dismiss the #include > > directive, or does it actually repreocess the include file ?  E It actually #includes the file again. The compiler doesn't care that  D the file has been included once already. If you want to limit that, ' you can use #defines in include files :    #ifndef module_x_included  #define module_x_included    ... include file contents ...    #endif    P > Perhaps judicious use of #ifdef statements could avoid re-inclusion of modules" > that have already been included.   Yes, that's the common way.    ------------------------------  % Date: Tue, 23 Nov 2004 06:50:45 -0800  From: Z <z@no.spam> * Subject: Re: DEC-C and DECwindows includes( Message-ID: <98Iod.2127$29.627@fe12.lga>   Ed Vogel wrote: ? >     It's a feature of both the compiler and the header files.  > @ >     When a header file is properly guarded using the mechinismD >     Craig describes the compiler notes this and keeps track of theJ >     file.  If a source attemtps to #include the same file again, and theA >     guard macro is FALSE, the compiler will never even open the  >     include file.   2 Neat. I didn't know that it was optimized that way   ------------------------------  # Date: Tue, 23 Nov 2004 17:18:36 GMT 5 From: "Ed Vogel" <edward.vogel_stop_the_spam.@hp.com> * Subject: Re: DEC-C and DECwindows includes1 Message-ID: <MhKod.3386$bx2.686@news.cpqcorp.net>   : "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message& news:41A34B83.754F1E85@teksavvy.com... > Ed Vogel wrote:  > > > #define __STDLIB_LOADED 1  > J > >     Note that to do the include-once optimization, the headers must be > >     guarded properly.  > I > Does the compiler look for __<module_name>_LOADED to be defined, and if  so,  > ignores the include ?   K     The way this works is that the compiler checks each #include file as it  process it. C     The compiler looks for an #include file that begins with #ifdef  <identifier> or I     #ifndef <identifer>  with the only corresponding #endif at the end of  the include.J     It does not matter what the the <identifer> spelling is.  When it sees thisF     case it marks the file as having the "include-once" property.  The
 compiler then K     detects when it is about to open the same file again (it keep a list of 
 all the files G     it's opened).  If that file then has the include-once property, the  compiler skipsK     opening/reading it.  There is a lot of code to deal with VMS .TLB files  also.   I     I believe things are actually a bit more complex than I've described,  but thisF     is essentially how it works.  I am not all that familiar with this section of code.       Ed Vogel$     HP/Compaq/DEC C/C++ Engineering.   ------------------------------    Date: 23 Nov 2004 09:20:27 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) * Subject: RE: DECnet positively in the news3 Message-ID: <0wBaO6CZ4iFP@eisner.encompasserve.org>   | In article <FD827B33AB0D9C4E92EACEEFEE2BA2FB4A4A75@tayexc19.americas.cpqcorp.net>, "Main, Kerry" <kerry.main@hp.com> writes: > F > You may already be aware of this, but DECnet is available on Linux -0 > http://linux-decnet.sourceforge.net/index.html  F    DECnet is available on just about everything.  I can't remember theE    last time I had a system that I couldn't get Phase IV for.  (Maybe 5    it was my DECSYSTEM 20's before Phase IV shipped?)    ------------------------------  # Date: Tue, 23 Nov 2004 16:05:09 GMT " From:   VAXman-  @SendSpamHere.ORG* Subject: RE: DECnet positively in the news0 Message-ID: <00A3B4D4.C2AD6B82@SendSpamHere.ORG>  q In article <0wBaO6CZ4iFP@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: } >In article <FD827B33AB0D9C4E92EACEEFEE2BA2FB4A4A75@tayexc19.americas.cpqcorp.net>, "Main, Kerry" <kerry.main@hp.com> writes:  >>  G >> You may already be aware of this, but DECnet is available on Linux - 1 >> http://linux-decnet.sourceforge.net/index.html  > G >   DECnet is available on just about everything.  I can't remember the F >   last time I had a system that I couldn't get Phase IV for.  (Maybe6 >   it was my DECSYSTEM 20's before Phase IV shipped?)  4 Anybody here know where I might get DECnet for OS X?   --  < http://www.ProvN.com  for the *best* OpenVMS system security=                       solutions that others only claim to be.  --  , Cyber-Terrorism (si'-ber tayr'-or-iz-em) n.:M   The release of, the sale of, or the use of any Micro$oft software product!   --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM    ------------------------------  % Date: Tue, 23 Nov 2004 11:45:20 -0500 # From: "John Smith" <a@nonymous.com> * Subject: Re: DECnet positively in the news, Message-ID: <TsidnQNaKMO_9D7cRVn-hQ@igs.net>    VAXman- @SendSpamHere.ORG wrote:5 > In article <0wBaO6CZ4iFP@eisner.encompasserve.org>, ? > koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: 
 >> In article J >> <FD827B33AB0D9C4E92EACEEFEE2BA2FB4A4A75@tayexc19.americas.cpqcorp.net>,, >> "Main, Kerry" <kerry.main@hp.com> writes: >>> H >>> You may already be aware of this, but DECnet is available on Linux -2 >>> http://linux-decnet.sourceforge.net/index.html >>H >>   DECnet is available on just about everything.  I can't remember theG >>   last time I had a system that I couldn't get Phase IV for.  (Maybe 7 >>   it was my DECSYSTEM 20's before Phase IV shipped?)  > 6 > Anybody here know where I might get DECnet for OS X?    D It's still the same today as it was years ago.....best server/client combination......VMS and a Mac.    ------------------------------  # Date: Tue, 23 Nov 2004 17:24:08 GMT " From:   VAXman-  @SendSpamHere.ORG* Subject: Re: DECnet positively in the news0 Message-ID: <00A3B4DF.CB45D65E@SendSpamHere.ORG>  R In article <TsidnQNaKMO_9D7cRVn-hQ@igs.net>, "John Smith" <a@nonymous.com> writes:! >VAXman- @SendSpamHere.ORG wrote: 6 >> In article <0wBaO6CZ4iFP@eisner.encompasserve.org>,@ >> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >>> In articleK >>> <FD827B33AB0D9C4E92EACEEFEE2BA2FB4A4A75@tayexc19.americas.cpqcorp.net>, - >>> "Main, Kerry" <kerry.main@hp.com> writes:e >>>>I >>>> You may already be aware of this, but DECnet is available on Linux -M3 >>>> http://linux-decnet.sourceforge.net/index.html( >>>gI >>>   DECnet is available on just about everything.  I can't remember the H >>>   last time I had a system that I couldn't get Phase IV for.  (Maybe8 >>>   it was my DECSYSTEM 20's before Phase IV shipped?) >>7 >> Anybody here know where I might get DECnet for OS X?M >n >aE >It's still the same today as it was years ago.....best server/client   >combination......VMS and a Mac.   Thank you Preacher!i   Signed: The Choir.    J Seriously, I love what I can do with my Powerbook G4 17" and OS X.  I haveK a wonderful X11 server on it and can talk to VMS, run a full-blown CDE ses-iK sion, have a keyboard that reasonable mimics/facilitates the DEC-style key-eJ board and I don't have to put a single cent into that cluster of fucktardsF in Redmond which is, IMHO, the only clustering M$ will ever excel at.    -- n< http://www.ProvN.com  for the *best* OpenVMS system security=                       solutions that others only claim to be.W -- K, Cyber-Terrorism (si'-ber tayr'-or-iz-em) n.:M   The release of, the sale of, or the use of any Micro$oft software product! " --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COMB   ------------------------------  % Date: Tue, 23 Nov 2004 19:06:43 +0100n5 From: "GWDVMS::MOELLER" <moeller@gwdvms.dnet.gwdg.de> * Subject: Re: DECnet positively in the news" Message-ID: <6268487@MVB.SAIC.COM>  @ Bob Koehler <koehler@EISNER.NOSPAM.ENCOMPASSERVE.ORG> writes ... >[...]H > > You may already be aware of this, but DECnet is available on Linux -2 > > http://linux-decnet.sourceforge.net/index.html > H >    DECnet is available on just about everything.  I can't remember theG >    last time I had a system that I couldn't get Phase IV for.  (Mayben7 >    it was my DECSYSTEM 20's before Phase IV shipped?)p  A I have some consolation for those not as fortunate as Mr. KoehlerpG (e.g. not as well-funded, or simply lacking the time to install DECnet, H or even using some esoteric operating system unknown to Mr. Koehler) ...  E A few days ago I remembered (due to meeting a person who appeared to hD spend all of her time on TCP/IP management) that in the olden times,D I had been the one who was able to manage a quite large DECnet (plusF some VAXen) *and* play EMPIRE etc. :-). And since I'm not one of thoseG folks who nowadays manage our TCP/IP network - which not only replaced sE almost all of the old DECnet, but grew to an unprecedented number of qB so-called 'IP hosts' (but I still do manage a few mostly idle VMS A machines, plus AIX machines doing real large amounts of I/O :-), GE I had the time to think a while ... and suddenly I realized that ALL dI of the stuff that makes TCP-IP management so much weirder, and much more UK laborious than DECnet management (like "subnet masks", "default gateways", eD multiple IP adresses per [routing] host, and the frequent necessity K to change IP adresses when upgrading the cabling ...) apparently goes back qA to a design decision involving IP ROUTING, that someone had made rE in the days when most IP hosts were 16-bit computers, in view of the qF then astounding fact that IP allowed for 32-bit host addresses (could G it be that this took place in Berkeley CA? :-). In other words, all of  I this "weird" stuff could become completely unnecessary once IPv4 ROUTERS sK (about which the basic IP RFCs have very little to say) used some slightly pF more intelligent algorithms (like e.g. those used by DECnet) and made D some creative use of (rather more powerful) ARP in order to balance H the lack of (ethernet only) DECnet "hello" messages. And it ought to be H possible to implement this on most of the internet by doing a few small E code changes in the firmware of typical IP router boxes, without any h; requirement to upgrade more than one such box at a time ...o  C I just can't imagine to be the first person to have this idea, so -sD if you know anyone to already propose this idea, please let me know.  G Also, in case you're seriously interested (note: this is not a joke!), hC but do not intend to visit the (German) DECUS "IT-Symposium 2005", -D scheduled to take place April 4..8 in Neuss/Dsseldorf, where I will@ have a chance to talk about that matter, let me know where else A I could turn to. Yes, I'm rather fluent in the English language. 2E I've even been vacationing in Berkeley CA once, and spent a few days cH quite close to the UCB campus, but - in spite of having been admonished B that replying "root" and "root", respectively, to the prompts for E user name and password was *not* the proper way (although it'd work)  F to *use* a PDP 11/45 somewhere else in the building, as a PhD student D of acoustics (or more exactly, physics) in my twenties - for reasonsN unknown, missed the opportunity to visit its computer science department :-). C No objections to another trip to that area. Once there, no problem SB exploring some places not yet visited, on my own funds, like e.g.  San Jose and Palo Alto. :-)L  M Wolfgang J. Moeller, Tel. +49 551 201-1516/-1510, moeller@gwdvms.dnet.gwdg.de3M GWDG, D-37077 Goettingen, F.R.Germany     |    Disclaimer: No claim intended!eM http://www.gwdg.de/~moeller/ ---- <moeller@gwdg.de> ---- <w.moeller@ieee.org>    aka. (in German)  L Dr. J. Wolfgang Mller    Tel. +49 551 201-1516 or -1510   Fax +49 551 21119L GWDG, AG Zentrale Systeme, D-37077 Goettingen, Germany     <moeller@gwdg.de>L --------------------------------------------------------------- G W D G ----   ------------------------------    Date: 23 Nov 2004 07:27:39 -0800. From: spamsink2001@yahoo.com (Alan E. Feldman)% Subject: Re: DECW$CLOCK design flaw !t= Message-ID: <b096a4ee.0411230727.706b33fb@posting.google.com>h  O david20@alpha2.mdx.ac.uk wrote in message news:<cnq9mf$ih8$1@news.mdx.ac.uk>...eP > In article <opshrqtciyzgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com> writes:1 > >On Fri, 19 Nov 2004 23:11:17 -0500, JF Mezei   ( > ><jfmezei.spamnot@teksavvy.com> wrote: > >2 > >> "Alan E. Feldman" wrote:mJ > >>> Despite the very surprising spookiness of certain aspects of quantumG > >>> mechanics, I find the possibility of going backwards in time veryn > >>> unlikely.- > >> [...]-< > >You would need to revise the second law of Thermodynamics > O > I'm not sure what relevance the 2nd Law of Thermodynamics has to Time travel.) > 9 > The standard statements of the 2nd Law are those due to' >  > Kelvin >  > "tJ > There is no thermodynamic process whose sole effect is to transform heatF > extracted from a source at uniform temperature completely into work. > "s >  > ande > 
 > Clausius >  > "sQ > There is no thermodynamic process whose sole effect is to extract a quantity of D > heat from a colder reservoir and deliver it to a hotter reservoir. > "m > Q > I'd assume you probably meant the derived quantity entropy which can be definedm > as >  > " O > For a closed system, the quantitative measure of the amount of thermal energyl > not available to do work." >  > . > with which the second law can be restated as > 2 > "Entropy in a closed system can never decrease." >  > P > Unfortunately entropy is a much misused term (rather like VMS clustering) with" > at least two other popular uses. > P > One is Boltzmann's statistical entropy which deals with the number of possibleP > states a system may evolve into. There are more disordered states than orderedN > states for an ordered system to evolve into hence it is highly probable thatK > a system will evolve from an ordered to a disordered state. This is oftenJL > asserted as a reason for the direction of the arrow of time - however this |s |-I > argument has problems since there are also more disordered states than hE > ordered states which could give rise to the original ordered state.c  E Huh? The odds for a closed macroscopic system going to a more ordered B state are essentially zero. It's like waiting for all the air in aA room to collect into opposite corners of the room, say in 1 cubicu< meter or less at each corner. It's just not going to happen.   [...]n   ------------------------------    Date: 23 Nov 2004 09:39:32 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)r% Subject: Re: DECW$CLOCK design flaw ! 3 Message-ID: <B8COQA1MlEXv@eisner.encompasserve.org>W  n In article <b096a4ee.0411221827.2b1dbac5@posting.google.com>, spamsink2001@yahoo.com (Alan E. Feldman) writes:c > JF Mezei <jfmezei.spamnot@teksavvy.com> wrote in message news:<419DB354.A9B6D204@teksavvy.com>...a >> Paddy O'Brien wrote:fH >> > But I agree with Alan and VAXMAN, time cannot go backwards, and ourC >> > setting time earlier is not the same as time going backwards. r >> o5 >> Time is like a river. It flows into one direction.n >  > Really. Based on what?       Second law of thermodynamics.   ------------------------------  # Date: Tue, 23 Nov 2004 16:37:46 GMT % From: "John Vottero" <John@mvpsi.com>n% Subject: Re: DECW$CLOCK design flaw ! > Message-ID: <uHJod.31450$Qv5.13731@newssvr33.news.prodigy.com>  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message -& news:419DB354.A9B6D204@teksavvy.com... > Paddy O'Brien wrote:F >> But I agree with Alan and VAXMAN, time cannot go backwards, and our@ >> setting time earlier is not the same as time going backwards. >a4 > Time is like a river. It flows into one direction. >   K The St. John river in New Brunswick reverses direction every 6 hours or so.T  A http://new-brunswick.net/Saint_John/reversingfalls/reversing.htmlo  E (which has nothing at all to do with time travel, quantum physics or  	 OpenVMS).t   ------------------------------  + Date: Tue, 23 Nov 2004 17:37:44 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk% Subject: Re: DECW$CLOCK design flaw !a) Message-ID: <cnvsh8$f8u$1@news.mdx.ac.uk>e  n In article <b096a4ee.0411230727.706b33fb@posting.google.com>, spamsink2001@yahoo.com (Alan E. Feldman) writes:P >david20@alpha2.mdx.ac.uk wrote in message news:<cnq9mf$ih8$1@news.mdx.ac.uk>...Q >> In article <opshrqtciyzgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com> writes:d2 >> >On Fri, 19 Nov 2004 23:11:17 -0500, JF Mezei  ) >> ><jfmezei.spamnot@teksavvy.com> wrote:  >> > >> >> "Alan E. Feldman" wrote:K >> >>> Despite the very surprising spookiness of certain aspects of quantumnH >> >>> mechanics, I find the possibility of going backwards in time very >> >>> unlikely. >> >>  >[...]= >> >You would need to revise the second law of Thermodynamics  >> AP >> I'm not sure what relevance the 2nd Law of Thermodynamics has to Time travel. >> e: >> The standard statements of the 2nd Law are those due to >> (	 >> Kelvinr >> r >> "K >> There is no thermodynamic process whose sole effect is to transform heataG >> extracted from a source at uniform temperature completely into work., >> " >> s >> and >> i >> Clausius  >> p >> "R >> There is no thermodynamic process whose sole effect is to extract a quantity ofE >> heat from a colder reservoir and deliver it to a hotter reservoir.  >> " >> mR >> I'd assume you probably meant the derived quantity entropy which can be defined >> ast >> p >> "P >> For a closed system, the quantitative measure of the amount of thermal energy >> not available to do work."  >> w >>  / >> with which the second law can be restated asm >> g3 >> "Entropy in a closed system can never decrease."c >>   >> -Q >> Unfortunately entropy is a much misused term (rather like VMS clustering) withD# >> at least two other popular uses.c >> :Q >> One is Boltzmann's statistical entropy which deals with the number of possible@Q >> states a system may evolve into. There are more disordered states than ordereduO >> states for an ordered system to evolve into hence it is highly probable that L >> a system will evolve from an ordered to a disordered state. This is oftenM >> asserted as a reason for the direction of the arrow of time - however thisc >| >|J >> argument has problems since there are also more disordered states than F >> ordered states which could give rise to the original ordered state. >lF >Huh? The odds for a closed macroscopic system going to a more orderedC >state are essentially zero. It's like waiting for all the air in a)B >room to collect into opposite corners of the room, say in 1 cubic= >meter or less at each corner. It's just not going to happen.I >i    It depends on the point of view.  K Take a closed system and define it's current state as ordered and all thosecF states which it might move to which are so close as to be pretty much M indistinguishable from it as also ordered. All other states it might move to c being considered disordered.  I Then, for any reasonably large system, the number of disordered states D hH vastly outnumbers the number of ordered states O. Hence in the standard I interpretation the system is more likely to move from the ordered to the e disordered state.c  G But unless you introduce other constraints this isn't the whole story. )I Consider the past of the system - where did the ordered state come from ? M The number of disordered states which can become the ordered state is exactly J the same in number as the set D (since each is just a state in D with the L velocity vectors reversed) similarly the number of ordered states which can C become the ordered state is exactly equal to O for the same reason.eK Hence it is vastly more likely that the ordered state came from a precedingSM disordered state than from a preceding ordered state ie the system moved fromd disorder to order.  I To change the situation you have to introduce a time dependent constraintS8 so that in the past the system was more constrained eg  K you remove a partition so that the gas in an enclosed space can move into a 
 larger space.-   Note.-  G In this situation statistical and thermodynamic entropy appear to be in  different places..  K In statistical entropy the entropy increases due to the vast number of new f4 states the system can occupy in the expanded volume.  N In thermodynamics the work done in removing the partition is done from outsideL the system meaning it is no longer closed. Hence the system to be consideredK has to include the agency removing the partition for instance a human hand.vM The entropy increase then can be identified with the waste heat generated by iJ the muscles in that hand. No waste heat is generated by the gas molecules  having more space to move in.       
 David Webb Security Team Leader CCSS Middlesex University   >[...]   ------------------------------  + Date: Tue, 23 Nov 2004 14:57:42 +0000 (UTC) 6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)? Subject: Re: f$device( "*", "DISK", , ) v. "ESS1888 AudioDrive" 0 Message-ID: <newscache$ajzm7i$cjl$1@news.sil.at>  B In article <04112122511555@antinode.org>, sms@antinode.org writes:$ >> > ALP2 $ sho dev /ful _ALP2$AUA0: >> > nS >> > Disk AUA0:, device type ESS1888 AudioDrive, is online, record-oriented device,   A The word "AudioDrive" is already suspect. What is an AudioDrive ?u A speaker with wheels ;-).  @ >ALP2 $ wso F$GETdvI( "AUA0", "DEVCLASS" )       ! PWS 500 a[u]. >1  & Yup. On my PWS433au and PWS500au, too.  = But to get a AUA0: device at all on the Personal Workstations E I had to previously enter the following to SYS$SYSTEM:USER_CONFIG.DAT    device    = "ES1888 Sound Card"r   name    = AU   driver  = MMOV$ESSDRIVER   adapter = XBUS   id      = ES1888
 end_device  H because neither OpenVMS Alpha nor MMOV did add it (during installation).  D >alp $ wso F$GETdvI( "AUA0", "DEVCLASS" )        ! AlpSta 200 4/233. >98e >e5 >alp $ sea /mat = and decc_include:dcdef.h dc, " 98 "bO >#define DC$_AUDIO 98                    /* General audio                    */t  J Maybe this is because the AS200 does it probably with the following clause  % device       = "Microsoft Sound Card"l   name       = AUy   driver     = MMOV$MSBDRIVERc   adapter    = ISA   id         = 0x42584350    or  % device       = "Microsoft Sound Card"t   name       = AUf   driver     = MMOV$MSBDRIVERp   adapter    = ISA   id         = 0x0042534D 
 end_device  J which both were entered during MMOV installation (at least on my systems).I That means, probably MMOV$ESSDRIVER behaves differently to MMOV$MSBDRIVERaM in this area (where I think it should not, means it should also be class 98).e   Fred, Hoff, care to comment ?m Please !   -EPLAN  J PS: Another strange thing is on my PWS500. VMS shows it as "ESS1887" whileI SRM shows it as "ESS1888" (while the PWS433 shows "ES1888" in VMS&SRM andrK SYS$SYSTEM:USER_CONFIG.DAT on both PWS has the same entry "ES1888"). Funny.c -- e Peter "EPLAN" LANGSTOEGERy% Network and OpenVMS system specialista E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  + Date: Tue, 23 Nov 2004 10:59:24 -0600 (CST)i From: sms@antinode.org? Subject: Re: f$device( "*", "DISK", , ) v. "ESS1888 AudioDrive"h) Message-ID: <04112310592438@antinode.org>s  6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)  B > >ALP2 $ wso F$GETdvI( "AUA0", "DEVCLASS" )       ! PWS 500 a[u]. > >1 > ( > Yup. On my PWS433au and PWS500au, too. > ? > But to get a AUA0: device at all on the Personal WorkstationssG > I had to previously enter the following to SYS$SYSTEM:USER_CONFIG.DATt > ! > device    = "ES1888 Sound Card"  >   name    = AU >   driver  = MMOV$ESSDRIVER >   adapter = XBUS >   id      = ES1888 > end_device > J > because neither OpenVMS Alpha nor MMOV did add it (during installation).  ?    That's SYS$USER_CONFIG.DAT, but yes, I apparently added mine 4 manually, too.  I must have read about it somewhere.  F > >alp $ wso F$GETdvI( "AUA0", "DEVCLASS" )        ! AlpSta 200 4/233. > >98  > >m7 > >alp $ sea /mat = and decc_include:dcdef.h dc, " 98 "CQ > >#define DC$_AUDIO 98                    /* General audio                    */  > L > Maybe this is because the AS200 does it probably with the following clause > ' > device       = "Microsoft Sound Card"o >   name       = AU  >   driver     = MMOV$MSBDRIVERn >   adapter    = ISA >   id         = 0x42584350a >  > or > ' > device       = "Microsoft Sound Card"a >   name       = AU. >   driver     = MMOV$MSBDRIVERw >   adapter    = ISA >   id         = 0x0042534Ds > end_device > L > which both were entered during MMOV installation (at least on my systems).K > That means, probably MMOV$ESSDRIVER behaves differently to MMOV$MSBDRIVERdO > in this area (where I think it should not, means it should also be class 98).l      My SYS$CONFIG.DAT includes:  ! device          = "MS Sound Card"n   name          = AU   driver        = SYS$MSBDRIVERc   adapter       = XBUS   id            = SOUN
 end_device  ! but SYS$USER_CONFIG.DAT includes:m  : ! Added on 14-FEB-2001 21:25:41.97 via MMOV_ADD_DEVICE.COM !a% device       = "Microsoft Sound Card"s   name       = AUe   driver     = MMOV$MSBDRIVERe   adapter    = ISA   id         = 0x0042534D 
 end_device  : ! Added on 14-FEB-2001 21:25:42.34 via MMOV_ADD_DEVICE.COM !d% device       = "Microsoft Sound Card"-   name       = AU    driver     = MMOV$MSBDRIVER    adapter    = ISA   id         = 0x42584350j
 end_device  : ! Added on 14-FEB-2001 21:25:42.80 via MMOV_ADD_DEVICE.COM !t% device       = "Microsoft Sound Card"e   name       = AUp   driver     = MMOV$MSBDRIVER?   adapter    = ISA   id         = "PCXBJ"
 end_device  : ! Added on 14-FEB-2001 21:25:43.39 via MMOV_ADD_DEVICE.COM !l% device       = "Microsoft Sound Card"s   name       = AU    driver     = MMOV$MSBDRIVERy   adapter    = EISAd   id         = "ISA2000"
 end_device  : ! Added on 14-FEB-2001 21:25:44.86 via MMOV_ADD_DEVICE.COM !d device       = "AV321"   name       = VIh   driver     = MMOV$VIDRIVER   adapter    = PCI   id         = 0x000E1011-
 end_device  : ! Added on 14-FEB-2001 21:25:45.76 via MMOV_ADD_DEVICE.COM !f device       = "AV300-AA"    name       = VIC   driver     = MMOV$VIDRIVER   adapter    = TC6   id         = "AV300-AA"K
 end_device  H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode-orgi    Saint Paul  MN  55105-2547    ------------------------------  # Date: Tue, 23 Nov 2004 06:42:42 GMTe. From: Uthacalthing <uthacalthing@tymbrimi.gov>+ Subject: Re: FAST BOOT OF SIMH VAX Emulator : Message-ID: <231120040042427518%uthacalthing@tymbrimi.gov>  B In article <1100689177.181769.20060@c13g2000cwb.googlegroups.com>,% Galen <gspamtackett@yahoo.com> wrote:o  
 > Dave wrote:a > H > > I'm guessing most people are running SIMH just to see VMS running on
 > a windoz+ > > box, and aren't doing anything serious.o >  > Ah, but not me!e > * > I'm running it on an OS X 10.3 PowerMac.. > Still not doing anything serious, though :-) >   G Is there a source for the precompiled emulator for Mac OS X?  Or do theiF instructions on the SIMH home page work fine for OS X?   They are longG enuf that I didn't really want to spend all that time only to find thatj  it didn't work part-way through.    - BillK   ------------------------------    Date: 23 Nov 2004 03:20:48 -0800& From: "Galen" <gspamtackett@yahoo.com>+ Subject: Re: FAST BOOT OF SIMH VAX EmulatorhB Message-ID: <1101208848.754469.92600@c13g2000cwb.googlegroups.com>   Bill,D  @ I don't know of a source for a precompiled OS X versino of simh.  G I built it on my PowerMac G4/466 (MacOS 10.3.6) . It was easy to do andc@ it really didn't take very long. Of course, you have to have theC developer tools installed. If you don't, I think the CD you want isd' labelled something like "X Code Tools."   F I don't have a great deal of experience running it yet but do have the4 latest Hobbyist VMS kit installed and running on it.  ? Now if I could just network the emulated VMS system to the hosto Macintosh system...   G Let me know if you have any other questions and I'll see if I can help.h   Galen   B P.S. I'm changing jobs and may be off line for a bit--from work at least, maybe not from home.l   ------------------------------  # Date: Tue, 23 Nov 2004 14:53:11 GMTn. From: Uthacalthing <uthacalthing@tymbrimi.gov>+ Subject: Re: FAST BOOT OF SIMH VAX Emulatorf: Message-ID: <231120040853105686%uthacalthing@tymbrimi.gov>  F Thanks, Galen.  I do have the developer tools installed.   Just wasn't? sure from the main SIMH site if anything special was needed forME compiling under OS X.   Didn't see anything, so I hoped not, but I am:C not a Unix guru (been using VMS for 24 years, Mac for 20, Unix only.B sparingly for the last 4) so I thought it'd be worthwhile to check before diving in.s  C I did find a "precompiled" (actually pre-built) system on a site in @ Australia, but it's 285MB, and was going to take over 5 hours toC download (even over my cable modem!)  I tried it, but it died aboutmF 25MB in. I'll try it again tonight, and keep searching.  It also has a? smaller (2mb) prebuilt one without an installed copy of VMS.   B    - Bill    ------------------------------    Date: 23 Nov 2004 08:02:13 -0800& From: "Galen" <gspamtackett@yahoo.com>+ Subject: Re: FAST BOOT OF SIMH VAX EmulatoruB Message-ID: <1101225733.683461.85930@c13g2000cwb.googlegroups.com>   Bill,r  F I'm not a Unix-head either--I've been using VMS for about 22 years andC Mac for 20 myself, and used RSX-11 for about 15 years in the past.,lG with a bit of Unix here and there along the way. So I have had a lot tow& learn in the Unix area of OS X as well  F All I had to do to compile SIMH, really, was download and unzip it, cd9 to the right directory and say something like "make VAX."u  A I'm still learning when it comes to getting SIMH to start up moree@ easily, and the terminal emulators that I've tried don't map theE typical VMS LK-style keyboard very well. (I'm working on that, slowlyh though, with xmodmap.)  E If you'd like to exchange problems, ideas, etc., offline, please feela free to contact me by e-mail.n  ( gspamtackett <atsign> yahoo <period> com> (remove "spam" and the other obfuscations for my real address)   ------------------------------  ! Date: Tue, 23 Nov 04 10:55:15 GMTe From: jmfbahciv@aol.com Y Subject: Re: interesting take on Olsen's "no reason for any individual to have a  computea, Message-ID: <PLednVnG5KC9gj7cRVn-1Q@rcn.net>  J In article <87acta3p04.fsf@prep.synonet.com>, prep@prep.synonet.com wrote:0 >JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > B >> If IBM understood the potential of personal computers. how come >> Digital didn't ?l > D >IBMs `understanding' PCs was to cripple them to be a funky terminalE >with a few cute trickes. But it escaped and ran away with 20 zillionlE >industry standard pundits who could supply almost anything you could.E >imagine for them. This was not in the great scheme of things hangingdA >in Entry Systems Division, you where meant to come begging for a  >system 3 or 36! (gag...)s >.E >But yes, DECs persistant braindeath in the face of all facts is mind,	 >numbing!o  A DEC did not, I repeat, not have a business model aimed at retail. D It took orders directly from the gear buyers.  It did not, I repeat,? not sell software separately from the gear.  Mostly, it did noto7 sell software but hard/software maintenance.  Customerse; got their bug fixes and updates via a maintenance contract.s  C This business infrastructure could not have maintained PCs in everyn
 household.   /BAH     ' Subtract a hundred and four for e-mail.m   ------------------------------  % Date: Tue, 23 Nov 2004 09:12:30 -0500 # From: "John Smith" <a@nonymous.com> Y Subject: Re: interesting take on Olsen's "no reason for any individual tohave a computer  , Message-ID: <7-mdnYrFm6bN2D7cRVn-tg@igs.net>   jmfbahciv@aol.com wrote: >-< > It did not.  WTF are you talking about?  When DEC "sold" a: > PC, it was not selling its own products.  It was selling? > somebody else's manufactured output.  Alphas were never, evere> > in the retail market.  You could not walk into a CompUSA and8 > buy an Alpha off the shelf with all software installed$ > and maintenance on an as is basis.    K 1) Early on in DEC's PC game they were partnered with Olivetti, mostly as an" way to get them into the business.  K 2) Later on DEC was a significant manufacturer of PC's in its own right. JFlG is correct about the DEC plant in Kanata, Ontario - if memory serves meeJ correccly, it was producing the lion's share of DEC's PC products ans well- as the sole source for several Alpha systems.p  G 3) As to Alpha not being on the shelf at Sears and CompUSA, neither wasaK Proliant or HP's equivalent x86 boxes - which were ostensiby competitors toe some Alpha's running NT.   ------------------------------  % Date: Tue, 23 Nov 2004 07:23:14 -0500u- From: JF Mezei <jfmezei.spamnot@teksavvy.com>-Y Subject: Re: interesting take on Olsen's "no reason for any individual tohave a computer  , Message-ID: <41A32BA9.77A0CEEE@teksavvy.com>   jmfbahciv@aol.com wrote:C > DEC did not, I repeat, not have a business model aimed at retail.sF > It took orders directly from the gear buyers.  It did not, I repeat,A > not sell software separately from the gear.  Mostly, it did nota. > sell software but hard/software maintenance.  ( IBM was like that too.  But IBM learned.  K What is interesting is that DEC at one point stopped taking orders directlyhB from customers and forced them to go through resellers. Resellers,3 distributors, retailers, it is really all the same.e  J DEC had systems to track customers. But it wasn't forced to enter every PC sale into that system.  K Where there is a will, there is a way. If IBM found a way to sell PCs, thenu DEC had absolutely no excuse.   N In fact, under Palmer, DEC had a thriving PC business. However, because of theL musical chair games at every quarter, the PC business got de-emphasized just as it was about to take off.  J DEC should have hired Lou Gerstner and let IBM die. DEC would probably ownL Compaq and HP today, and HP-UX would be the dead product with a few features$ being migrated to DEC Unix on ALPHA.   ------------------------------  ! Date: Tue, 23 Nov 04 12:52:31 GMTs From: jmfbahciv@aol.comeY Subject: Re: interesting take on Olsen's "no reason for any individual tohave a computer l, Message-ID: <OYWdnaOpDLMGpz7cRVn-pA@rcn.net>  , In article <41A32BA9.77A0CEEE@teksavvy.com>,1    JF Mezei <jfmezei.spamnot@teksavvy.com> wrote:e >jmfbahciv@aol.com wrote:iD >> DEC did not, I repeat, not have a business model aimed at retail.G >> It took orders directly from the gear buyers.  It did not, I repeat, B >> not sell software separately from the gear.  Mostly, it did not/ >> sell software but hard/software maintenance.n >s) >IBM was like that too.  But IBM learned.s  ; The business changed!!!!!!  Hardware got cheap.  Every Tom,i9 Dick, and Hairy could buy gear.  People made enough moneya! to waste it on buying a system.  s     > D >What is interesting is that DEC at one point stopped taking orders  directly8 >from customers and forced them to go through resellers.  F HUH!!!!  Stay within the decade.  We were talking about the beginnings of the PC market.      > .. Resellers,.4 >distributors, retailers, it is really all the same.  7 No, it's not.  That's the point I was trying to make.  c6 Certainly DEC fucked itself but not because it ignored: PC business.  They weren't retail.  PCs are purely retail.   >rK >DEC had systems to track customers. But it wasn't forced to enter every PC  >sale into that system.t  ; This is an example of what DEC's business model was.  If ita; was going to continue having the reputation of quality, ands9 thoroughly tested _systems_, it could not get into the PCa9 business.  Remember that DEC's business was hardware, not 	 software.-   >-H >Where there is a will, there is a way. If IBM found a way to sell PCs,  then >DEC had absolutely no excuse. >o7 >In fact, under Palmer, DEC had a thriving PC business.S  : It did not.  WTF are you talking about?  When DEC "sold" a8 PC, it was not selling its own products.  It was selling= somebody else's manufactured output.  Alphas were never, ever@< in the retail market.  You could not walk into a CompUSA and6 buy an Alpha off the shelf with all software installed" and maintenance on an as is basis.     > .. However, because of theI >musical chair games at every quarter, the PC business got de-emphasized I just >as it was about to take off.   @ Palmer's priority job was to strip the company of all cash, sellE all profitable sectors and isolate the help desk part in prepartation ! for the corporate sale to Compaq.   A There was no taking off in any of their business plans.  If there = had been any little piece that might have some profit future,y9 it was destroyed.  The people doing productive work were f5 reassigned, moved, given shitwork or fired^Wlaid off.d >!K >DEC should have hired Lou Gerstner and let IBM die. DEC would probably own(E >Compaq and HP today, and HP-UX would be the dead product with a few : features% >being migrated to DEC Unix on ALPHA.   @ DEC's top management had no intention of continuing the company.   /BAH  ' Subtract a hundred and four for e-mail.    ------------------------------  % Date: Tue, 23 Nov 2004 08:59:36 -0500i- From: JF Mezei <jfmezei.spamnot@teksavvy.com>tY Subject: Re: interesting take on Olsen's "no reason for any individual tohave acomputer in, Message-ID: <41A34237.55FA3814@teksavvy.com>   jmfbahciv@aol.com wrote:H > HUH!!!!  Stay within the decade.  We were talking about the beginnings > of the PC market.e  I DEC started to shift to resellers paradigm in the 1980s. I fact, by 1986, L calling dec to ask to buy a vax would yield an automatic "why don't you callN hamilton avnet (or whatever the big regional reseller-du-jour was) and one had% to insist to talk to a dec sales rep.r  M However, you also forget that initially, IBM aimed its PCs at businesses too. K It did allow the PC to become retail as a side dish. market progressed fromuM there, and Compaq came in and pulled the rug from under IBM for many reasons.D  8 > Certainly DEC fucked itself but not because it ignored< > PC business.  They weren't retail.  PCs are purely retail.  M Not initially. And there was no reason for DEC not to build PCs and make them>  available through "the channel".    = > This is an example of what DEC's business model was.  If it = > was going to continue having the reputation of quality, andE; > thoroughly tested _systems_, it could not get into the PCr > business.i  N True. But IBM managed quite well to spurt out PCs while keeping its enterpriseK business quite "quality" oriented. And look today at HP which is a consumerg4 goods business with an enterprise sideline business.  9 > >In fact, under Palmer, DEC had a thriving PC business.  > < > It did not.  WTF are you talking about?  When DEC "sold" a* > PC, it was not selling its own products.  L Humm, wonder what they were all building then in Kanata (Canada), and wonderK about those DEC ads on TV (yes!) about its canadian made personal computers.N and laptops. And they were becoming quite succesful, visible in shops that had IBM AS400s for instance.  I You can't expect to become a big contender inside of 2 or 3 quarters. DEC J shoudl have stayed in for a couple more years before admitting defeat. TheQ real reason DEC gave up on PCs is due to musical chairs game involving Pessatori.e   > Alphas were never, everi > in the retail market.s  M This isn't because DEC couldn't. It is because DEC decided it didn't want to.VL It decided that its Alpha would not compete against its PCs and as a result,K prevented Alphas from competing against wintel. (and the few low end alphash that were built were crippled).o    B > Palmer's priority job was to strip the company of all cash, sellG > all profitable sectors and isolate the help desk part in prepartation # > for the corporate sale to Compaq.n  J That was for the last 3 years (1996 to 1999). Prior to that, he was just aM headless chicken running around, moving people left and right and not knowingl9 what to do. And the mild PC success was around that time.    ------------------------------    Date: 23 Nov 2004 10:14:09 -0800& From: jordan@ccs4vms.com (Rich Jordan) Subject: My home pageC= Message-ID: <cc5619f2.0411231014.4273b7ba@posting.google.com>e  < for a very long time has been http://www.openvms.digital.com  F No need to change it, since it redirected, and it was a nice nostalgic thing to keep around.o  C Today, while www.digital.com still resolves and redirects, it lookssE like my home page URL is no more... www.openvms.digital.com no longer 	 resolves.y  C One line in a configuration file somewhere... guess it was just too  much trouble to keep.p   Sigh.  Now I'm depressed.t   Rich   ------------------------------    Date: 23 Nov 2004 01:33:03 -0800 From: mb301@hotmail.com (MB)! Subject: Re: NFS Problem with AIXy= Message-ID: <1d08b916.0411230133.4838353d@posting.google.com>a  R What nfs version are you using? v2 ,v3 ,v5.1 have you tried changing the version?    $ tcpip show nfs p  , What switches are you using on the nfs disk?  g udo.kaul@merck.de (Udo Kaul) wrote in message news:<302d60f2.0411220714.32b8bcbf@posting.google.com>..., > Hi,a > > > we mount a NFS- Device from OpenVMS 7.3-2(TCPIP 5.4 ECO2) on > AIX RS6000 V51 .> > If we do ls -l from the mountpoint on the AIX Server we saw  > all the data we need.(? > If we do a find *.syn from the mountpoint on the AIX Server ,p= > we receive the following error in the operator.log ( VMS) :r > : > %%%%%%%%%%%  OPCOM  22-NOV-2004 13:51:03.33  %%%%%%%%%%%' > Message from user NFS Server on MIZARt& > svcktcp_reply: mbuf_send returned 32: > %%%%%%%%%%%  OPCOM  22-NOV-2004 13:51:03.33  %%%%%%%%%%%' > Message from user NFS Server on MIZARi< > rfs_dispatch: sendreply failed IP address: 155.250.205.133 > $ > After this the ls -l didn't work . >  > Does anybody has any idea ?e >  > best regards Udo   ------------------------------    Date: 23 Nov 2004 06:40:48 -0800  From: "Barry" <dysert@gmail.com>5 Subject: Re: Online forums for former digits/deccies? C Message-ID: <1101220848.330224.223450@c13g2000cwb.googlegroups.com>   D Great!  I'm not the proud owner of an account on EISNER::  Now I canG stay in touch with the world's greatest o/s after the retired the VAXeslE here at work.  Plus, NOTES !!  Ah, the good old days.  If someone canyE tell me how to convince Reflection to use my .r2w file from IE I'd beu happy as a clam.  Anyone?f# Thanks for the account, Mr. Eisner.    -- Barry: a 15-year ex-Digit   ------------------------------  + Date: Tue, 23 Nov 2004 11:29:57 +0000 (UTC) 6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)$ Subject: RE: OpenVMS Support Chart ?0 Message-ID: <newscache$2xpm7i$81c$1@news.sil.at>  | In article <FD827B33AB0D9C4E92EACEEFEE2BA2FB4A4AB3@tayexc19.americas.cpqcorp.net>, "Main, Kerry" <kerry.main@hp.com> writes:@ >> From: Peter 'EPLAN' LANGSTOEGER [mailto:peter@langstoeger.at]F >> Does anyone know where one can find now the OpenVMS support chart ?K >> You know the list which shows what VMS version is minimum for what H/W ?s >> It used to be atm >>< >> 	http://www.openvms.digital.com/openvms/supportchart.html >t >These might help: >P< >http://h71000.www7.hp.com/openvms/openvms_supportchart.html >oN >http://h20219.www2.hp.com/services/cache/11774-0-0-225-121.aspx (PVS Support) > @ >http://h20219.www2.hp.com/services/cache/10647-0-0-225-121.aspx  & Sorry, no. You seem to missunderstood.  B >http://h71000.www7.hp.com/openvms/os/openvms-release-history.html  H While this is interesting, it doesn't list what the minimum VMS versions for eg. a MicroVAX 3800 is...e   -- s Peter "EPLAN" LANGSTOEGER7% Network and OpenVMS system specialistl E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Tue, 23 Nov 2004 13:37:21 +0000 - From: John Laird <nospam@laird-towers.org.uk> $ Subject: Re: OpenVMS Support Chart ?8 Message-ID: <75f6q0tr3df1sevj0l8n97atu3rjhegh39@4ax.com>  E On Tue, 23 Nov 2004 11:29:57 +0000 (UTC), peter@langstoeger.at (Peter- 'EPLAN' LANGSTOEGER) wrote:9  } >In article <FD827B33AB0D9C4E92EACEEFEE2BA2FB4A4AB3@tayexc19.americas.cpqcorp.net>, "Main, Kerry" <kerry.main@hp.com> writes:7A >>> From: Peter 'EPLAN' LANGSTOEGER [mailto:peter@langstoeger.at]eG >>> Does anyone know where one can find now the OpenVMS support chart ?cL >>> You know the list which shows what VMS version is minimum for what H/W ? >>> It used to be at >>> = >>> 	http://www.openvms.digital.com/openvms/supportchart.htmle >> >>These might help:p >>= >>http://h71000.www7.hp.com/openvms/openvms_supportchart.html  >>O >>http://h20219.www2.hp.com/services/cache/11774-0-0-225-121.aspx (PVS Support)y >>A >>http://h20219.www2.hp.com/services/cache/10647-0-0-225-121.aspxy >i' >Sorry, no. You seem to missunderstood.  > C >>http://h71000.www7.hp.com/openvms/os/openvms-release-history.htmle > I >While this is interesting, it doesn't list what the minimum VMS versionsr >for eg. a MicroVAX 3800 is...  H I think there is a typo where it mentions VS 38/3900 and this should say% MV...  I also found information here: ( http://vax.sevensages.org/hw/vms-hw.html  F which seems to suggest 5.1-1 offically but maybe 5.0 if you are lucky.   --  L When people are free to do as they please, they usually imitate each other.    Mail john rather than nospam...n   ------------------------------  % Date: Tue, 23 Nov 2004 09:32:20 -0500t- From: JF Mezei <jfmezei.spamnot@teksavvy.com>l$ Subject: Re: OpenVMS Support Chart ?, Message-ID: <41A349E0.7B4F90BF@teksavvy.com>  K > >While this is interesting, it doesn't list what the minimum VMS versionsn  > >for eg. a MicroVAX 3800 is...  K Testing/qualifications issues apart, for VAX, what is required to support a  new model ?B  D Is it just the presence of a specific file in SYS$LOADABLE_IMAGES ?   L In the case of microvax II without floating point, I assume it also required those  math libraries. right ?  F Since I have heard a rumour that next version of VAX VMS won't supportM microvax II, does this mean that they will pull the files that would allow itr+ to run on it, or just not test/qualify it ?   M Assuming for a minute that they were to remove those support files, would the L odds be good that it woudl work if I were to add those files from a previous7 version ? (considering VAX-VMS hardly changes anymore).o   ------------------------------    Date: 23 Nov 2004 09:30:14 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)r$ Subject: Re: OpenVMS Support Chart ?3 Message-ID: <ox1dop7JRXdj@eisner.encompasserve.org>n  \ In article <41A349E0.7B4F90BF@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > H > Since I have heard a rumour that next version of VAX VMS won't supportO > microvax II, does this mean that they will pull the files that would allow it2- > to run on it, or just not test/qualify it ?1  D    Generally they just don't qualify it.  Often a configuration thatD    would support it was never built by DEC, but could be built using    third party components.  H    For example the 11/730 was dropped because DEC didn't make a disk forF    it big enough to serve as a boot disk for the next release of VMS. /    But people ran them using third party disks.n  F    Occaisionally changes actually break VMS for older systems, such asE    when ASMP was cut out and SMP put in.  An 11/782 can't run withoutr    that ASMP code.  B    An MV II maxes out at 16MB using supported memory controllers. H    Changing memory controllers in an MV II is no small job.  The easiestF    way to do it is to pull the CPU and memory boards and plug in a VAXG    4000 Model 100 or 105.  (Was that supported?)  But then it's not an m    MV II any more.  B    The next release of VMS may spend it's whole life doing system G    page faults in 16MB, so it's time it became an unsupported system.  hB    I don't think the redident part of the kernel is over 16MB yet.  D    Why should HP do work to pull files?  That just costs HP money to    pay someone to do it.   ------------------------------  % Date: Tue, 23 Nov 2004 11:15:09 -0500-, From: "warren sander" <warren.sander@hp.com>$ Subject: Re: OpenVMS Support Chart ?, Message-ID: <41a3646b$1@usenet01.boi.hp.com>  6 http://h71000.www7.hp.com/openvms/hw_supportchart.html  B they usurped the 'supportchart.html' name because they created theH http://h71000.www7.hp.com/openvms/openvms_supportchart.html which is the operating system supportchart.  I anyway i put in a redirect from supportchart.html to hw_supportchart.html< but for some9 reason it didn't get set externally. It should overnight.i  " btw.. there was always a link from6 http://h71000.www7.hp.com/openvms/operatingsystem.html- (OpenVMS systems hardware support chart link)n   -warren     C "Peter 'EPLAN' LANGSTOEGER" <peter@langstoeger.at> wrote in messaget+ news:newscache$8aol7i$yfw1$1@news.sil.at...>E > Does anyone know where one can find now the OpenVMS support chart ?IJ > You know the list which shows what VMS version is minimum for what H/W ? > It used to be at > : > http://www.openvms.digital.com/openvms/supportchart.html >>$ > and later its replacement pointers >o9 > http://www.openvms.compaq.com/openvms/supportchart.htmlf5 > http://h71000.www7.hp.com/openvms/supportchart.htmlk > L > and is also referred in the VMS FAQ. But alas, not there. And even "SearchL > results" shows nothing (except a few wizard articles referring this URLs). >e > Anyone ? Warren ? Please.o >r > TIAo >  > --   > Peter "EPLAN" LANGSTOEGERb' > Network and OpenVMS system specialistc > E-mail  peter@langstoeger.atH > A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  + Date: Tue, 23 Nov 2004 16:57:25 +0000 (UTC)d6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)$ Subject: Re: OpenVMS Support Chart ?0 Message-ID: <newscache$t25n7i$j6n$1@news.sil.at>  [ In article <41a3646b$1@usenet01.boi.hp.com>, "warren sander" <warren.sander@hp.com> writes:t7 >http://h71000.www7.hp.com/openvms/hw_supportchart.htmlf >sC >they usurped the 'supportchart.html' name because they created the I >http://h71000.www7.hp.com/openvms/openvms_supportchart.html which is thei >operating system supportchart.s  % Thanks Warren. That's what I thought.s  J >anyway i put in a redirect from supportchart.html to hw_supportchart.html
 >but for some-: >reason it didn't get set externally. It should overnight.  O Good to read (cause nobody wants to reedit the old wizard articles, do they ?).t We'll see...  # >btw.. there was always a link fromc7 >http://h71000.www7.hp.com/openvms/operatingsystem.htmla. >(OpenVMS systems hardware support chart link)  E I had missed it. And now I can find the required info via GOOGLE, too1  , Thanks Warren, it was a pleasure (as always)   -- i Peter "EPLAN" LANGSTOEGERp% Network and OpenVMS system specialisto E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  + Date: Tue, 23 Nov 2004 17:55:28 +0000 (UTC)AP From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)$ Subject: Re: OpenVMS Support Chart ?$ Message-ID: <cnvtig$sva$1@online.de>  5 In article <41A349E0.7B4F90BF@teksavvy.com>, JF Mezei ' <jfmezei.spamnot@teksavvy.com> writes: y  H > Since I have heard a rumour that next version of VAX VMS won't supportO > microvax II, does this mean that they will pull the files that would allow its- > to run on it, or just not test/qualify it ?   F Isn't this official?  Also, I think the earliest ALPHAs are no longer  supported (as of 7.3-2).  O > Assuming for a minute that they were to remove those support files, would the)N > odds be good that it woudl work if I were to add those files from a previous9 > version ? (considering VAX-VMS hardly changes anymore).y  E Could it be that "unsupported" just means "untested and we won't takeaC any complaints"?  I once heard of 7.1 or something booting on a VAXo' 11/780, even though it was unsupported.    ------------------------------  % Date: Tue, 23 Nov 2004 08:36:51 +0100  From: Dirk Munk <munk@home.nl>! Subject: Re: OT: Joke of the weeke2 Message-ID: <cnupan$prj$1@news2.zwoll1.ov.home.nl>   John Smith wrote:n > Bob Koehler wrote: > ; >>In article <RoidnTb4i-9Jtj_cRVn-1Q@igs.net>, "John Smith"s >><a@nonymous.com> writes: >>B >>>Maybe we should offer him a free e-mail account on an Alpha/VMS
 >>>system. >>D >>   Alas, VMS is no better than most on receiving spam.  But add-on= >>   spam filters are available and HP is looking at new one.o >>F >>   We should get HP to ship that as a product and sell it to all the# >>   ISPs while making loud noises!u >  >  > - > The only loud noises HP ever will make are:h > "Buy Proliant" > "Buy Microsoft Windows"nL > "Buy a printer while you're at it. And we have some lovely digital cameras< > you can use to take pictures of carly's(tm) shapely legs." >  > O Why don't you mention those beautiful TV sets and similar stuff? I'm sure they 4N are delivered with a DVD showing a message Carly thanking you for buying this  wonderfull high-tech equipment."   ------------------------------  % Date: Tue, 23 Nov 2004 18:53:56 +1100l4 From: Paddy O'Brien <paddy.o'brien@transgrid.com.au>! Subject: Re: OT: Joke of the weekh/ Message-ID: <41A2EC94.8090807@transgrid.com.au>d   JF Mezei wrote:A   [snips]i  O > Now, back to the topic, if one contends that Microsoft is best suited to helptM > secure the air force's network, this means that Microsoft is fully aware of"N > all the flaws in its software and hence could he held criminally responsibleI > for productizing software it knows to be flawed. (or even designing its   > software to have known flaws).  I Much as I dislike BG and his totally flawed OS (for which he is going to  H try and patent everything that he has plagiarised), I cannot agree that G he can be held criminally responsible.  Govt orgs (responsible for our tE defences) like UK navy, IK health (body defences) and US army and au  H almost everything are the criminals for using a system that they should G know to be totally vulnerable, totally insecure and totally inadequate   for their needs.  G BG could not care a stuff as long as his billions keep increasing.  It eB is the gullibility of our goverments and corporations that can be  classed as criminal.   Regards, Paddy            G ***********************************************************************   C "This electronic message and any attachments may contain privileged > 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 advisehB the sender.  You are hereby notified that any use, dissemination, 7 distribution, reproduction of this email is prohibited.n  A If you have received the email in error, please notify TransGrid  A immediately.  Any views expressed in this email are those of the R= individual sender except where the sender expressly and with rC authority states them to be the views of TransGrid.  TransGrid usesp> 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: Tue, 23 Nov 2004 05:13:27 -0500r( From: David Froble <davef@tsoft-inc.com>! Subject: Re: OT: Joke of the weekI, Message-ID: <41A30D47.4030406@tsoft-inc.com>   Larry Kilgallen wrote:  s > In article <dYep0aPRVc$2@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:n > T >>In article <RoidnTb4i-9Jtj_cRVn-1Q@igs.net>, "John Smith" <a@nonymous.com> writes: >>J >>>Maybe we should offer him a free e-mail account on an Alpha/VMS system. >>>88 >>   Alas, VMS is no better than most on receiving spam. >> > @ > It is much better than the leading vendor at not executing it. >   I To some users, the claim would be that it's not any good at executing it.h  M Then again, those users are normally the ones who get blasted by every nasty   thing on the web.$   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  + Date: Tue, 23 Nov 2004 13:59:16 +0000 (UTC)E From: david20@alpha2.mdx.ac.uk! Subject: RE: OT: Joke of the week ) Message-ID: <cnvfnk$b0h$1@news.mdx.ac.uk>   | In article <FD827B33AB0D9C4E92EACEEFEE2BA2FB4E948F@tayexc19.americas.cpqcorp.net>, "Main, Kerry" <kerry.main@hp.com> writes: >c >> -----Original Message----- 5 >> From: Jack Peacock [mailto:peacock@simconv.com]=20r" >> Sent: November 22, 2004 8:06 PM >> To: Info-VAX@Mvb.Saic.Com$ >> Subject: Re: OT: Joke of the week >>=20sC >> "Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote=20e >> in message=200 >> news:b$klPxsqoqwK@eisner.encompasserve.org...G >> >   If a Microsoft product was handling the problem, Microsoft would_1 >> >   be shipping MS Office-Anti-Spam yesterday.d >> >@ >> MS ships some rudimentary anti-spam in the latest ISA 2004=20 >> firewall, in=20> >> Exchange 2003, and in Outlook 2003.   Not perfect but it=20 >> catches about 95%,=20B >> good enough for freebie add-ons.  I gather log statistics on=20 >> the heaviest=20A >> DNS and SMTP incoming sites, then block some of them in the=20  >> firewall (DNS is=20B >> a real giveaway, easy to spot the brute forcers over time). =20 >> I also link to=20. >> Spamhaus in Exchange for sender DNS checks. >>=20 A >> I expect to see similar features in VMS around the time the=20$ >> last Itanium=20F >> dice roll off the Intel line.  Both will be equally useful by then. >>   Jack Peacock=20 >>=20I >C >As a fyi -e > F >Process Software also a anti-spam solution that is also available (or >will be shortly) on OpenVMS.  >dC Yes it's available on VMS and has been since it was first released.6F Early versions were tied to certain mail server products (PMDF on VMS, Sendmail on Unix systems etc).H The latest version can be run either integrated with such mailservers orK as a transparent SMTP Proxy server which sits in front of any SMTP listener  (eg Dec TCPIP Services).N The current downside to this latter approach is that the SMTP listener doesn'tL see the real IP address the mail connection came from just the proxy serversL address (which maybe 127.0.0.1 if the proxy is running on the same system asJ the SMTP listener). This means that running it with DEC TCPIP services youE would lose the ability to use RBL lists. This isn't a problem running * integrated with a mailserver such as PMDF.K The next version of PreciseMail anti-virus will add RBL facilities into thet SMTP proxy server.    The product itself is very good.    
 David Webb Security team leader CCSS Middlesex University     >Reference: 1 >http://www.process.com/precisemail/antispam.htmlr >iB >Note - I just received a flyer in my regular post mail with large >letters entitled: >o6 >"Make SPAM your Target with Precise Anti-Spam Gateway >0 >Supported on OpenVMSo >o >By Process Software"h >h' >On back side, part of what it says is:cI >- Runs with any email server including Multinet, TCPware, PMDF, HP TCPIPa# >Services for OpenVMS, and Exchangeg) >- Operates on Linux, Solaris and OpenVMSl >h >Regards >t >Kerry Main  >Senior Consultant >HP Services Canadal >Voice: 613-592-4660 >Fax: 613-591-4477 >kerryDOTmainAThpDOTcom- >(remove the DOT's and AT)=20t >a% >"OpenVMS has always had integrity ..H >Now, Integrity has OpenVMS .."2   ------------------------------    Date: 23 Nov 2004 09:18:58 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ! Subject: Re: OT: Joke of the weekO3 Message-ID: <17kI4nH5P21+@eisner.encompasserve.org>t  \ In article <41A2AD84.8498DD1D@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > Larry Kilgallen wrote:; >> >    Alas, VMS is no better than most on receiving spam.d >> fA >> It is much better than the leading vendor at not executing it.  > P > TCPIP services isn't *THAT* Bad. It does have DNS based (both backtranslatable > and RBL) support.   4    I think he was refering to the vendor of Windows.  P > There is a huge difference between VMS and Windows: VMS can't filter viri, butN > viri don't affect it. Windows has some filtration of viri, but otherwise has3 > no immunity to viri and catches them very easily.r  G    VMS can too filter viri.  You can buy comrercial products which willH.    filter Windows viri from VMS based storage.   ------------------------------  % Date: Tue, 23 Nov 2004 11:09:26 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>M! Subject: Re: OT: Joke of the weeke, Message-ID: <41A3609A.5CDA7A68@teksavvy.com>   Bob Koehler wrote:I >    VMS can too filter viri.  You can buy comrercial products which willo0 >    filter Windows viri from VMS based storage.  H TCPIP services does not provide any hooks for you to add software to theN receiver process. And it does not provide any hooks for you to add software toF the main symbiont. You need to find some hacks to route message to the filtering software.m   ------------------------------    Date: 23 Nov 2004 10:27:17 -0800( From: bob@instantwhip.com (Bob Ceculski)@ Subject: Question asked should OpenVMS be used for the web - DA!= Message-ID: <d7791aa1.0411231027.655ffd35@posting.google.com>m  @ http://www.linuxworld.com.au/index.php/id;1616857056;fp;2;fpid;1   asks the question ...4  = "By this logic, users are better off picking the most obscurexC operating systems on the Internet to ensure site safety and uptime.m@ Will this lead the security gurus in the Fortune 500 to flock to; OpenVMS and OS/2 for their Web infrastructure?" Not likely.t   and my question is ... WHY NOT?a   ------------------------------    Date: 23 Nov 2004 10:16:49 -0100* From: "Michael Kraemer" <M.Kraemer@gsi.de>B Subject: Re: Re-post on TechWorld of OpenVMS: Survives and Thrives0 Message-ID: <41A30E11.MD-1.4.4.M.Kraemer@gsi.de>  K > The ComputerWorld article OpenVMS: Survives and Thrives by Drew Robb has y > been re-posted at TechWorld. >   5 Shouldn't they change the headline to something like:b  . "400000 mystery VMS systems spotted in Sweden"   possibly with a subtitle   "10 Million Swedes to use VMS"   ------------------------------  % Date: Tue, 23 Nov 2004 05:58:15 -0500-- From: JF Mezei <jfmezei.spamnot@teksavvy.com> B Subject: Re: Re-post on TechWorld of OpenVMS: Survives and Thrives, Message-ID: <41A317C5.8991EEF5@teksavvy.com>   Michael Kraemer wrote:7 > Shouldn't they change the headline to something like:70 > "400000 mystery VMS systems spotted in Sweden" > possibly with a subtitle >   > "10 Million Swedes to use VMS"  + And a caption in the middle of the article:c  8 	"VMS Engineers to produce VMS in Swedish language only"   And a small window with:  ; 	SET FILE/ATTRIBUTES becomes STLLER DATAREGISTER/ATTRIBUT c   2 years later:  G 	Carly marries CEO of Ericsson, donates VMS to her husband's company asn
 wedding gift.i   ------------------------------  % Date: Tue, 23 Nov 2004 09:04:55 -0500n# From: "John Smith" <a@nonymous.com> : Subject: Re: reporter inquiry: Is HP selling AlphaServers?, Message-ID: <CfWdnQz7iOEV3j7cRVn-oA@igs.net>   JF Mezei wrote:, > "Main, Kerry" wrote:G >> would have to double the size or add another server. Now, because ofsE >> the performance we are seeing, we are quite confident that we willrG >> be able to get through this year and into next before we have to adds >> more database capacity."r >  > @ > Considering that HP has begun to mention Alpha "last sales" noF > earlier than 2 years from now, do such customers with 1280s have anyG > sort of contract/commitment from HP that would allow then to continue-D > to add CPUs to their 1280s until the theoretical limit of 128 even$ > beyond the last-alpha-sales date ? >:F > If not, shouldn't such customers be buying enough capacity to last aG > lot longer than just 1 or 2 years to give them plenty of time to plan G > migration to other platforms before they run out of capacity on their  > alpha infrastructure ?     Consider the following:iD The last EV7z cpu's have been fabbed and are sitting in a shoebox in carly's(tm) closet.tK Some current GS customers come along in a few years asking to buy some morel cpu's.4 carly(tm) sez, "Opening price is $X. What am I bid?"H Since there is some demand and only a finite supply, guess what happens?  I Eventually the extra cpu price will be increased to a point that makes no # economic sense to stay with the GS..   ------------------------------    Date: 23 Nov 2004 09:22:12 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)': Subject: Re: reporter inquiry: Is HP selling AlphaServers?3 Message-ID: <FgjkwP8NeC$y@eisner.encompasserve.org>t  [ In article <41A261EB.54BC265@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:c > "Main, Kerry" wrote:H >> ""The price/performance of the HP Next Generation AlphaServer systemsK >> running OpenVMS puts these large systems within the reach of clients whoR > K > Does Cerner know that Alpha has been killed, murdered and burried ? (last  > sales date announced).  F    Alpha hasn't been killed, murdered, and burried.  It's strapped to H    a guillotine with no chance for reprieve, but the blade isn't to drop    for a couple more years.,   ------------------------------    Date: 23 Nov 2004 07:38:27 -0800& From: jordan@ccs4vms.com (Rich Jordan): Subject: Re: reporter inquiry: Is HP selling AlphaServers?= Message-ID: <cc5619f2.0411230738.3d0ba8fb@posting.google.com>   e David J Dachtera <djesys.nospam@comcast.net> wrote in message news:<41A2AD3C.F6806383@comcast.net>...l > David Froble wrote:h > >  > > > Rich Jordan wrote: > > >s > > >>[snip] > > >>As of this year companies E > > >>have to be able to provide over $1,000,000.00 dollars in annual G > > >>hardware/system sales in order to 'qualify' to resell OpenVMS and, > > >>Alpha systems. > >   > > This is entirely reasonable. > > R > > HP installed that stupid SAP system for their distribution, and to date I have5 > > not heard of one successful SAP system, anywhere.  > > N > > So since their application software has a hard time with having many small1 > > customers, they chop off the small customers.r > > 7 > > Makes as much sense to me as anything else HP does.  >  > Point taken... >  > -- s > David J Dachtera > dba DJE Systems: > http://www.djesys.com/  E Point of clarification.  We were too small to purchase direct from HPOC or Compaq; in fact we were reduced to a tiered VAR under DEC in themD mid '90s and had to purchase from one of DEC's major distributors to? resell.  As a result our only direct contact with corporate was ; getting the systems we resold registered for our customers.y  F But we were an authorized reseller, and you had to be that in order toD buy/resell from those major distributors.  Last year HP decided that@ certification of sales and support folks wasn't enough, and evenC resellers tiered beneath the big distributors had to be (in effect)lC BIG resellers (7 figures per year!) or they would not be allowed tomD sell 'enterprise' product (read Alpha and VMS).  Its damn hard to do* that selling DS10s with custom software...   Rich   ------------------------------  % Date: Tue, 23 Nov 2004 11:22:10 -0500a- From: JF Mezei <jfmezei.spamnot@teksavvy.com> : Subject: Re: reporter inquiry: Is HP selling AlphaServers?, Message-ID: <41A36396.19CC6A65@teksavvy.com>   Rich Jordan wrote:G > Point of clarification.  We were too small to purchase direct from HPsE > or Compaq; in fact we were reduced to a tiered VAR under DEC in thesD > mid '90s and had to purchase from one of DEC's major distributors   O The number of stories on hears that are exactly like the above is pretty scary.a  N Is it because DEC, seing declining sales, wanted to concentrate sales to fewerJ retailers so that those retailers would still make enough profit to bother with dec gear ?o  K Seems to me that they went the wrong way,. They killed off the keen vendorsyL loyal to DEC and kept the big fat vendors who also sold Sun HP IBM , Compaq,	 Dell etc.    ------------------------------  % Date: Tue, 23 Nov 2004 11:16:56 -0500E, From: "warren sander" <warren.sander@hp.com>: Subject: Re: reporter inquiry: Is HP selling AlphaServers?, Message-ID: <41a364d5$1@usenet01.boi.hp.com>  K http://www.hp.com/products1/evolution/alpha_retaintrust/openvms/quotes.html   and go down to the cerner quote.    : "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message% news:41A261EB.54BC265@teksavvy.com...u > "Main, Kerry" wrote:I > > ""The price/performance of the HP Next Generation AlphaServer systemsrL > > running OpenVMS puts these large systems within the reach of clients who >kK > Does Cerner know that Alpha has been killed, murdered and burried ? (lastk > sales date announced). >eK > I certaintly don't see them bragging about that IA64 thing. Once EV7 runsu outyC > of steam compared to other chips, (or HP stops seling Alpha basedn machines), IB > suspect that Cerner might put far more emphasis on AIX on Power. >eG > If computing power is important, than Power is bound to provide etterU price # > performance than that IA64 thing.t   ------------------------------  % Date: Tue, 23 Nov 2004 11:08:12 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> - Subject: Re: SYS$GETMSG bug ( false alarm :-(-, Message-ID: <41A36051.E63A81F8@teksavvy.com>  	 Oh man...3  E Since on VAX they forgot to make starlet and lib$routines define bothtL uppercase and lowercase system service definitions, I have to do it manually in my programs.3  U and I had copied the #define SYS$PUTMSG sys$putmsg and then changed it for get msg...    but in the end, I had    #define SYS$GETMSG sys$putmsg   H and there I was, wondering about why changing the value of the buffer to/ receive the message the application crash !!!!!a  P So the bug is in fact in sys$putmsg which crashes when given wrong arguments :-)  M Had the definitions of the system services include typecasting for arguments,a+ the compiler would  have warned me of this.a  N I started to have some serious doubts when changing the value of the buffer toN 133 resulted in another error message, and when it did work succesfully with aN length of 255 (yes, it id return with a status of success, the returned length was not modified at all.  K Apologize for the false alarm. I though it was rather odd that I would findC' such a bug this late in VMS's life. ...l  M But it does show that VMS engineering's lack of attention to VAX VMS in termsaS of providing complete header files for system services does cost some of us time...h   ------------------------------  % Date: Tue, 23 Nov 2004 10:24:40 -0500u- From: JF Mezei <jfmezei.spamnot@teksavvy.com> , Subject: SYS$GETMSG bug ( RADRMOD or OPCDEC), Message-ID: <41A35620.D408C1CC@teksavvy.com>  G Man, lost a lot of time on this one (since each compile takes forever).t   had   ( char buffer[257];  /* (255 plus null) */  $DESCRIPTOR( buff_desc, buffer);  < status = SYS$GETMSG( thestatus, &retlen, &buff_desc, 15, 0);   It would generate a 5 		%SYSTEM-F-RADRMOD error (reserved adressing fault).n  ! change the buffer to buffer[256] y and the error message becomes:4 		%SYSTEM-F-OPCDEC, opcode reserved to Digital fault    4 Put the definition at buffer[255] and it works !!!!!  N The system services manual states that the maximum length that can be returnedK is 256. So I had originally defined it as 257 so I'd had space for the null.M byte at the end. Since descriptors use word lengths, going from 255 to 256 tosG 257 shouldn't have mattered. And since the descriptor length is used toiJ describe the maximum length, it shouldn't really be mortal to give $GETMSG more space than it needs.l   This is on VAX VMS 7.2   ------------------------------  % Date: Tue, 23 Nov 2004 09:06:47 -0500t* From: "Bill Todd" <billtodd@metrocast.net>M Subject: Re: The Register: AMD's Opteron loses ground where it kind of counts = Message-ID: <B5idncTs48Of2T7cRVn-pg@metrocastcablevision.com>n  > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message+ news:BBrod.3342$XA1.114@news.cpqcorp.net...t > From The Register:8 http://www.theregister.co.uk/2004/11/19/amd_top500_loss/ >nG > "as measured by the most recent Top 500 supercomputer list... AMD and % > its Opteron processor lost ground."a > H > "The number of supercomputer installations using AMD's chips fell fromE > 34 sites in June of 2004 to 31 sites in November. Meanwhile, Intel,gF > which barely registered on this list three years ago, moved from 285 > sites to 318." > E > "high performance computing customers are often ahead of the curve,uG > picking up gear that will later be used by enterprise customers. Withk@ > that in mind, the lack of interest in Opteron clusters must be > disheartening for AMD."   ' Kind of selective quoting there, Keith:u  J "Before the letters start rushing in, let's make a couple of things clear.K First off, Intel has two chips to play with on this list - Xeon and ItaniumrK versus Opteron (Athlon is negligible) for AMD. Secondly, Intel has far more1J resources than AMD to put toward "encouraging" labs and researchers to payJ attention to its products. Intel's willingness to sweeten deals that blockD the purchase of Opterons has become legendary over the past year. InI addition, much of the Top500 list is dominated by fairly well-establishedgI high-end processors that have loads of software already prepared for themIJ and large server vendors helping out the cause of their respective chips."   - bill   ------------------------------  % Date: Tue, 23 Nov 2004 08:53:47 -0600u" From: "Schroeder, AJ" <aj1@qg.com>& Subject: Re: Upgrading HSG80 Firmware.( Message-ID: <41a34f1d$1@news.qgraph.com>  = "Dave Baxter" <dave.baxter@bannerhealth.com> wrote in messagee6 news:a3c44af1.0411091115.f816c77@posting.google.com... > Hey Guys, D > I am upgrading my HSG80 disk controller firmware (flashcards) fromF > 8.6f to 8.7f.   I haven't done this in a while so can anyone refresh > my memory. >e$ > As I recall, for a redundent pair, >s% > Step 1. Hold in both RESET buttons.g! > Step 2.  Eject old Flash Cards.-" > Step 3.  Insert new Flash Cards.! > Step 4.  release RESET buttons.. >> > Does that cover the process??f >e > thanks >i > Dave.s   Dave,1  = That does cover the process. It's simple and straightforward.   I However, and this is a big one, you need to make sure that if you plan oniL doing this as a rolling upgrade that you double-check your documentation andL release notes about rolling upgrades. From the looks of it you plan on doingH this as a shutdown upgrade, but if you are going to do this as a rolling? upgrade, you just update the cards in one controller at a time.g  J I used to manage quite a few SANs and IIRC the upgrade from 8.4 to 8.5 wasH rolling, while 8.6 to 8.7 is. I am out of the SAN area, but I have heardI rumors that 8.6 to 8.7 is a rolling upgrade, but to be on the safe side I>< would read the release notes -- to save a headache later on.   Just my $0.02 worth,   AJ Schroeder   ------------------------------    Date: 23 Nov 2004 09:14:33 +0100C From: vaxinf@chclu.chemie.uni-konstanz.de (Eberhard Heuser-Hofmann)eM Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.m2 Message-ID: <41a2f169$1@merkur.rz.uni-konstanz.de>  B In article <04112223041127@antinode.org>, sms@antinode.org writes:C >   In my large-file Info-ZIP [Un]Zip testing, I've discovered someh* >behavior in UnZip which I find troubling. >eH >   Currently, when expanding a "-V" archive, UnZip fills in the FAB/RABH >data for each output data file from the RMS attributes stored in its PKE >(modern) or IM (old) extra field in the archive.  These data includerG >fab$l_alq, the "allocation quantity", and using this value causes disk G >space for the entire file to be allocated at once when the output fileE >is created. >pF >   This is probably most efficient, as no file extension will ever beJ >needed, but when allocating a large file, some unpleasant things happen. G >The allocation seems to monopolize the destination disk drive for some<H >considerable time (for example, about 11.5 minutes for a 5GB file on anG >otherwise idle PWS 500a[u], QLogic ISP1040B KZPBA-CX, FUJITSU MAF3364L B >SUN36G (wide), VMS V7.3-1).  Also, once the allocation has begun,A >interrupting the UnZip program apparently does not interrupt the@E >allocation, so the disk may be tied up for a long time, irregardful.s >  >   My questions are:  >G& >   1.  Has this bothered anyone else?  : I have noticed the same behavior with my DVDwrite-program:  > DVDwrite allows me to copy a complete disk/CD/DVD into a file:, $  dvdwrite/dump disk: disk1:[dir]dumped.dsk  D If the source disk is large (I can burn 8 GB on a DVD+R DL) it takesC a incredibly long time to allocate the complete file of again 8 GB.mH There is no disk access possible by other processes until the allocation is	 finished.p   eberhard   > 5 >   2.  Does anyone else expect to be bothered by it?0 >5G >   3.  Does anyone, using any software, do such large file allocations1G >       this way?  (My _page_ files are not this big, and SYSGEN CREATE G >       is probably as close as I've previously come to making anythingaE >       so big at one time.  I use UnZip considerably more often than/F >       SYSGEN CREATE, too, though, like everyone else, I haven't been >       doing files so big.) >lI >   Currently, when expanding a non-V archive, default RMS parameters are I >used, and this makes for relatively slow extraction/creation (extension)hB >of a large data file.  Raising the initial allocation and defaultG >extension quantity seems to help considerably (about 2X), so this wille5 >probably be included in the final UnZip 6.0 release.t >aF >   Limiting the initial allocation for data files extracted from a -VG >archive involves more work and more risk of undesired side-effects, soME >I'm reluctant to dive in without some justification (such as whiningt >complaints from users). >eH >   And this time, please, if you don't know anything, don't tell me howH >it works now, how it must work in the future, or how it's too dangerous@ >to touch the code.  In hopeful anticipation, I offer my thanks. >aI >------------------------------------------------------------------------m > 5 >   Steven M. Schweda               (+1) 651-699-9818r4 >   382 South Warwick Street        sms@antinode-org >   Saint Paul  MN  55105-2547 >e   ------------------------------  % Date: Tue, 23 Nov 2004 08:17:12 +0000 - From: Roy Omond <Roy.Omond@BlueBubble.UK.Com>cM Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought. + Message-ID: <30ga44F2vc14rU1@uni-berlin.de>h   sms@antinode.org wrote:eD >    In my large-file Info-ZIP [Un]Zip testing, I've discovered some+ > behavior in UnZip which I find troubling.  > I >    Currently, when expanding a "-V" archive, UnZip fills in the FAB/RABvI > data for each output data file from the RMS attributes stored in its PKVF > (modern) or IM (old) extra field in the archive.  These data includeH > fab$l_alq, the "allocation quantity", and using this value causes diskH > space for the entire file to be allocated at once when the output file
 > is created.t > G >    This is probably most efficient, as no file extension will ever betK > needed, but when allocating a large file, some unpleasant things happen. rH > The allocation seems to monopolize the destination disk drive for someI > considerable time (for example, about 11.5 minutes for a 5GB file on ansH > otherwise idle PWS 500a[u], QLogic ISP1040B KZPBA-CX, FUJITSU MAF3364LC > SUN36G (wide), VMS V7.3-1).  Also, once the allocation has begun, B > interrupting the UnZip program apparently does not interrupt theF > allocation, so the disk may be tied up for a long time, irregardful.  > [...snip...]s  0 Highwater-marking enabled on the output volume ?   ------------------------------  + Date: Tue, 23 Nov 2004 02:39:43 -0600 (CST)  From: sms@antinode.orgM Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.6) Message-ID: <04112302394347@antinode.org>y  - From: Roy Omond <Roy.Omond@BlueBubble.UK.Com>h  2 > Highwater-marking enabled on the output volume ?  H    Yes, as it's the default.  ("Affects Files-11 On-Disk Structure Level* 2 disks only"  What's true on ODS5 disks?)    C From: vaxinf@chclu.chemie.uni-konstanz.de (Eberhard Heuser-Hofmann)   < > I have noticed the same behavior with my DVDwrite-program: > @ > DVDwrite allows me to copy a complete disk/CD/DVD into a file:. > $  dvdwrite/dump disk: disk1:[dir]dumped.dsk > F > If the source disk is large (I can burn 8 GB on a DVD+R DL) it takesE > a incredibly long time to allocate the complete file of again 8 GB.pJ > There is no disk access possible by other processes until the allocation > is finished.  H    That's what I saw.  I could tell when the allocation was finished, as' that's when a DIR would un-hang itself.m  C    In today's trials (on the PWS 500a[u]), UnZip of a 4.2GB archive D containing two 5GB data files took about 57:45 when it allocated theI whole thing, about 58:15 with deq = 64K, and about 62:30 with deq = 16K.  < With all default parameters, the same job took about 103:45.  @    Given the major annoyance with and the small benefit from theF full-allocation method, my current plan is to use a default deq = 64K,E and do full allocation up to twice the deq.  (Unlike Zip creating thewD archive, when UnZip creates a data file, it knows the size before it starts.)      Thanks for the comments.   G    I'm starting to think that reforming the -V methods is sounding more F and more like a good idea (although not any easier).  I suppose that IH could save the original parameters, change them, write the file, restoreC the original parameters, and then close the file.  If that actuallylG worked, it might not be too difficult, but there is the question of thee? over-allocated (past EOF) files, which would need to be checked 
 carefully.  H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode-org<    Saint Paul  MN  55105-2547,   ------------------------------  % Date: Tue, 23 Nov 2004 09:26:32 +0000m- From: Roy Omond <Roy.Omond@BlueBubble.UK.Com>eM Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.p+ Message-ID: <30ge63F31493sU1@uni-berlin.de>i   sms@antinode.org wrote:u  / > From: Roy Omond <Roy.Omond@BlueBubble.UK.Com>t > 2 >>Highwater-marking enabled on the output volume ? > J >    Yes, as it's the default.  ("Affects Files-11 On-Disk Structure Level, > 2 disks only"  What's true on ODS5 disks?)  B Try switching it off if you don't "need" it and repeat your tests.   $ Set Volume/NoHigh xxxx:    Please tell us the results ...   ------------------------------  % Date: Tue, 23 Nov 2004 09:56:22 +0000a- From: Roy Omond <Roy.Omond@BlueBubble.UK.Com> M Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.y+ Message-ID: <30gfu2F30hrf5U1@uni-berlin.de>r   sms@antinode.org wrote:l  / > From: Roy Omond <Roy.Omond@BlueBubble.UK.Com>A > 2 >>Highwater-marking enabled on the output volume ? >-J >    Yes, as it's the default.  ("Affects Files-11 On-Disk Structure Level, > 2 disks only"  What's true on ODS5 disks?)    From VMS 7.3-1:   $ help set volume /highR   SETV  	    VOLUMEa        /HIGHWATER_MARKINGv              /HIGHWATER_MARKING3            /NOHIGHWATER_MARKINGe  I         Determines whether the file highwater mark (FHM) volume attributeuI         is set. The FHM attribute guarantees that a user cannot read data E         that was not written by the user. Applies to Files-11 On-Diskj=         Structure Level 2 (ODS-2) and 5 (ODS-5) volumes only.n  F So that's without a doubt the explanation for your observed behaviour.  * Switch it off, and your UNZIP will fly ;-)   ------------------------------  % Date: Tue, 23 Nov 2004 11:26:16 +0000a- From: Roy Omond <Roy.Omond@BlueBubble.UK.Com>nM Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.s+ Message-ID: <30gl6kF2u97kfU1@uni-berlin.de>p   Eberhard Heuser-Hofmann wrote:  7 > In article <30gfu2F30hrf5U1@uni-berlin.de>, Roy Omondp' > <Roy.Omond@BlueBubble.UK.Com> writes:- >  > [...snip...] >0H >>So that's without a doubt the explanation for your observed behaviour. >>, >>Switch it off, and your UNZIP will fly ;-) > 7 > Speed vs. Security - That's a perfectUn*x philosophy.   : Dog forbid that *I* ever be accused of Un*x philosophy ...  < That's why I originally mentioned: "if you don't *need* it".9 If that level of security is *required*, then you have toA1 expect the observed behaviour (and live with it).   ; If applicable, have a single volume with high-water markingt: switched off for such situations.  The test is still worthA doing, and the results will hopefully prove, ahem, "interesting".    ------------------------------    Date: 23 Nov 2004 12:19:58 +0100C From: vaxinf@chclu.chemie.uni-konstanz.de (Eberhard Heuser-Hofmann).M Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.l2 Message-ID: <41a31cde$1@merkur.rz.uni-konstanz.de>  5 In article <30gfu2F30hrf5U1@uni-berlin.de>, Roy Omondy% <Roy.Omond@BlueBubble.UK.Com> writes:m >sms@antinode.org wrote: > 0 >> From: Roy Omond <Roy.Omond@BlueBubble.UK.Com> >> -3 >>>Highwater-marking enabled on the output volume ?: >>E >>    Yes, as it's the default.  ("Affects Files-11 On-Disk Structure: >Level- >> 2 disks only"  What's true on ODS5 disks?)0 >r > From VMS 7.3-1:  >M >$ help set volume /high >  >SET > 
 >   VOLUME >f >     /HIGHWATER_MARKING >i >           /HIGHWATER_MARKING  >           /NOHIGHWATER_MARKING >tJ >        Determines whether the file highwater mark (FHM) volume attributeJ >        is set. The FHM attribute guarantees that a user cannot read dataF >        that was not written by the user. Applies to Files-11 On-Disk> >        Structure Level 2 (ODS-2) and 5 (ODS-5) volumes only. >oG >So that's without a doubt the explanation for your observed behaviour.r >t+ >Switch it off, and your UNZIP will fly ;-)   5 Speed vs. Security - That's a perfectUn*x philosophy.    eberhard   ------------------------------  % Date: Tue, 23 Nov 2004 07:16:39 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>tM Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought. , Message-ID: <41A32A1E.7FF546EF@teksavvy.com>   Eberhard Heuser-Hofmann wrote: > >     /HIGHWATER_MARKING  7 > Speed vs. Security - That's a perfectUn*x philosophy.e  J With it on, you double the time it takes to extend a file since you have aL first pass to write 0s over all new blocks, and then your application starts  to fill those blocks one by one.  N You can compensate with SET VOLUME /ERASE_ON_DELETE  which is the mirror imageD for /HIGHWATER_MARKING (zaps data on delete instead of on allocate).   ------------------------------    Date: 23 Nov 2004 14:09:31 +0100C From: vaxinf@chclu.chemie.uni-konstanz.de (Eberhard Heuser-Hofmann)lM Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.s2 Message-ID: <41a3368b$1@merkur.rz.uni-konstanz.de>  5 In article <30gl6kF2u97kfU1@uni-berlin.de>, Roy Omonde% <Roy.Omond@BlueBubble.UK.Com> writes:  >Eberhard Heuser-Hofmann wrote:a >r8 >> In article <30gfu2F30hrf5U1@uni-berlin.de>, Roy Omond( >> <Roy.Omond@BlueBubble.UK.Com> writes: >> t >> [...snip...]e >>I >>>So that's without a doubt the explanation for your observed behaviour.s >>>c- >>>Switch it off, and your UNZIP will fly ;-)* >> *8 >> Speed vs. Security - That's a perfectUn*x philosophy. >-; >Dog forbid that *I* ever be accused of Un*x philosophy ...e >a  5 I'm sorry, but it reminded me of the famous sentence:eA "Sure the file system isn't save at all but look who fast it is.":    = >That's why I originally mentioned: "if you don't *need* it".i: >If that level of security is *required*, then you have to2 >expect the observed behaviour (and live with it). >h< >If applicable, have a single volume with high-water marking; >switched off for such situations.  The test is still worth,B >doing, and the results will hopefully prove, ahem, "interesting". >t   This leeds me to the question:  D Is there any idea of speed improvement when allocating a big file on highwater marked disks?    Eberhard   ------------------------------  % Date: Tue, 23 Nov 2004 07:58:00 -0600 6 From: "Craig A. Berry" <craigberry@mac.com.spamfooler>M Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.6D Message-ID: <craigberry-9BBB7A.07580023112004@news.isp.giganews.com>  A In article <04112223041127@antinode.org>, sms@antinode.org wrote:-  H >   Currently, when expanding a "-V" archive, UnZip fills in the FAB/RABI > data for each output data file from the RMS attributes stored in its PKmF > (modern) or IM (old) extra field in the archive.  These data includeH > fab$l_alq, the "allocation quantity", and using this value causes diskH > space for the entire file to be allocated at once when the output file
 > is created.S > G >    This is probably most efficient, as no file extension will ever be K > needed, but when allocating a large file, some unpleasant things happen. sH > The allocation seems to monopolize the destination disk drive for someI > considerable time (for example, about 11.5 minutes for a 5GB file on anrH > otherwise idle PWS 500a[u], QLogic ISP1040B KZPBA-CX, FUJITSU MAF3364LC > SUN36G (wide), VMS V7.3-1).  Also, once the allocation has begun,rB > interrupting the UnZip program apparently does not interrupt theF > allocation, so the disk may be tied up for a long time, irregardful. >  >    My questions are: > ' >    1.  Has this bothered anyone else?i  C It has bothered me.  However, I think it would bother me more if I >F didn't find out until after the file was half written that I couldn't F allocate sufficient space.  I regard the current behavior as a design H to preserve data integrity by decreasing the chances that an incomplete 9 file will be left on disk after a failed unzip operation.e   ------------------------------    Date: 23 Nov 2004 08:13:19 -0600 From: briggs@encompasserve.orgM Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought. 3 Message-ID: <$P6bkFeGyvdU@eisner.encompasserve.org>a  \ In article <41A32A1E.7FF546EF@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:  > Eberhard Heuser-Hofmann wrote: >> >     /HIGHWATER_MARKINGr > 8 >> Speed vs. Security - That's a perfectUn*x philosophy. > L > With it on, you double the time it takes to extend a file since you have aN > first pass to write 0s over all new blocks, and then your application starts" > to fill those blocks one by one.  B One of us has misunderstood how high water marking is implemented.  B It is not "erase on extend".  It is "erase when the highwater markA moves".  For ordinary sequential files, the highwater mark is theeA highest block within the file that has ever been accessed.  It isdA not the same as the end-of-file block.  It is not the same as then last allocated block.a  = You can extend a 10,000 block file by 90,000 blocks and incure? no overhead.  You can (I believe), move the end-of-file pointern= out to block 100,000 in the resulting file and still incur no/B overhead.  But if you try to read from block 100,000, you'd betterB sit back and wait as the file system erases 90,000 blocks for you.  P > You can compensate with SET VOLUME /ERASE_ON_DELETE  which is the mirror imageF > for /HIGHWATER_MARKING (zaps data on delete instead of on allocate).  C Both techniques are intended to prevent "disk scavenging" -- a usern? allocating free space that has not been overwritten and readingh sensitive data.K  F Erase on delete takes the obvious approach.  Erase the data when files> are deleted and you've blocked the attack.  Your free space is9 clean.  The downside is that it slows down file deletion.   B Highwater marking is intended to optimize away much of the erasureC overhead.  Instead of erasing the data right away, the system waitssB and erases it just before the next user tries to read it.  As long> as you have good control over the volume (nobody dismounts theD pack and walks away with it and nobody turns off highwater marking),8 you can get equivalent security with much less overhead.  C For each file on disk, the system maintains a highwater mark.  Data C below the mark is clean.  It has either been written by the user or*E has already been erased by the system.  Data above the mark is dirty.p@ It still contains stale and potentially scavengable information.  = If a user attempts to read above the highwater mark, the highiC water mark is moved and both the accessed block and the interveningf8 blocks are erased before the read is allowed to proceed.  9 If a user attempts to write above the highwater mark, thebB intervening blocks are erased and the write is allowed to proceed.  ; In the typical case of a sequential file that is written in2? sequential order, this algorithm completely avoids the need forv any disk erasure.R  , That's the way it's supposed to work anyway.    B If you change from a highwater marking anti-scavenging strategy to? an erase-on-delete anti-scavenging strategy, you are vulnerabledB to scavenging on the space that was free when you did the cutover.> If you are paranoid, you might want to allocate all that space and then do a $ DELETE /ERASE.    ? In the case at hand (5 minute delay waiting for humonguous filec@ to be created), I would speculate that we're looking at a volume@ lock while the file is being extended (contiguous best try?) and= the file system is going crazy trying to come up with extentseB in the volume bit map.  I can't see any reason for the file system: to hold the volume locked while doing a highwater erasure.   	John Briggs   ------------------------------  % Date: Tue, 23 Nov 2004 09:20:34 -0500e2 From: "Stanley F. Quayle" <squayle@insight.rr.com>M Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.t- Message-ID: <41A300E2.1147.D9808A5@localhost>   - On 23 Nov 2004 at 7:58, Craig A. Berry wrote:y  E > [...] However, I think it would bother me more if I didn't find out @ > until after the file was half written that I couldn't allocate > sufficient space.   C Well, you could allocate space in chunks (to allow other things to  A run), but check SYS$GETDVI after each to make sure there's still  @ space.  Sure, you still run the risk of running out at the last @ minute due to other processes taking up space.  That's a "false 
 negative".  B Of course, if you detect that you're not going to have room, then 7 what?  Abort the program?  Might be a "false positive".-  A Guess you could sum this up as "between a rock and a hard place".M  
 --Stan Quaylem Quayle Consulting Inc.  
 ----------- Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363s3 8572 North Spring Ct., Pickerington, OH  43147  USAh0 stan-at-stanq-dot-com       http://www.stanq.com   ------------------------------  % Date: Tue, 23 Nov 2004 10:04:34 -0500"- From: JF Mezei <jfmezei.spamnot@teksavvy.com> M Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.i, Message-ID: <41A3516C.481E231B@teksavvy.com>   briggs@encompasserve.org wrote:TC > moves".  For ordinary sequential files, the highwater mark is theaC > highest block within the file that has ever been accessed.  It iscC > not the same as the end-of-file block.  It is not the same as the  > last allocated block.   D Where does the "highwater" mark reside ? Is it in the file header ?   J if one had read-only access to the file, and one attempst to read past theK high water mark, does this mean that one magically gets write access to theeN file while the system is busy raising the highwater mark and then rewrites the$ header to reflect the new location ?   ------------------------------  % Date: Tue, 23 Nov 2004 15:06:48 +0000r- From: John Laird <nospam@laird-towers.org.uk>hM Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.o8 Message-ID: <k1k6q05fb6b8k5b1brbsqkvcol4gubnlj4@4ax.com>  > On 23 Nov 2004 08:13:19 -0600, briggs@encompasserve.org wrote:  C >One of us has misunderstood how high water marking is implemented.t >lC >It is not "erase on extend".  It is "erase when the highwater markiB >moves".  For ordinary sequential files, the highwater mark is theB >highest block within the file that has ever been accessed.  It isB >not the same as the end-of-file block.  It is not the same as the >last allocated block. >i> >You can extend a 10,000 block file by 90,000 blocks and incur@ >no overhead.  You can (I believe), move the end-of-file pointer> >out to block 100,000 in the resulting file and still incur noC >overhead.  But if you try to read from block 100,000, you'd betterdC >sit back and wait as the file system erases 90,000 blocks for you.u  I And if you don't read but instead your process dies, then what is left intL the file to indicate to the next reader that those blocks were never writtenI or safely zeroed ?  The only clue in the file header is the EOF position.R  L My *guess* would be that when EOF is updated, either all file extents or allK file blocks from the current EOF block to the new one are initialised.  TheiJ file creation could trigger this, I suppose.  One huge extent could = very long creation time.h  I The OP could investigate if the SQO bit is set on his file - I found some H Google refs suggesting that if this is set, then the unwanted delays areH eliminated (which kinda blows holes in the initialize-by-extent theory).I SQO won't work if UNZIP writes randomly around the file, however, so look " out for fseek and fpos type calls.   -- ,, We die only once, and for such a long time.    Mail john rather than nospam...-   ------------------------------    Date: 23 Nov 2004 09:35:14 -0600 From: briggs@encompasserve.orgM Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.33 Message-ID: <ZLu+mkcPfHa7@eisner.encompasserve.org>s  \ In article <41A3516C.481E231B@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:! > briggs@encompasserve.org wrote:rD >> moves".  For ordinary sequential files, the highwater mark is theD >> highest block within the file that has ever been accessed.  It isD >> not the same as the end-of-file block.  It is not the same as the >> last allocated block. > F > Where does the "highwater" mark reside ? Is it in the file header ?    Yes.  + From SYS$LIBRARY:LIB.MLB in module $FH2DEF:    $EQU    FH2$L_HIGHWATER 76 t  L > if one had read-only access to the file, and one attempst to read past theM > high water mark, does this mean that one magically gets write access to the P > file while the system is busy raising the highwater mark and then rewrites the& > header to reflect the new location ?  A The "writing" is done automatically by the file system and is note( affected by the user's file permissions.  G I don't see any opportunity for exploitation here.  The virtual picturesC of the file as presented to the users is that of a pre-zeroed array K of blocks.  The time as which the physical zeroing takes place is virtually  irrelevant.i  < Hmmm.  I wonder how things are handled on read-only volumes.B One would hope that the read is optimized away and a zeroed buffer	 returned.    	John Briggs   ------------------------------  % Date: Tue, 23 Nov 2004 16:07:19 +0000n- From: John Laird <nospam@laird-towers.org.uk> M Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.e8 Message-ID: <pvn6q0dooru9m1kto95l3qsh6libb5vc6m@4ax.com>  > On 23 Nov 2004 09:35:14 -0600, briggs@encompasserve.org wrote:  ] >In article <41A3516C.481E231B@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:M" >> briggs@encompasserve.org wrote:E >>> moves".  For ordinary sequential files, the highwater mark is theDE >>> highest block within the file that has ever been accessed.  It isaE >>> not the same as the end-of-file block.  It is not the same as the; >>> last allocated block.  >> rG >> Where does the "highwater" mark reside ? Is it in the file header ? s >j >Yes.r >t, >From SYS$LIBRARY:LIB.MLB in module $FH2DEF: >x >$EQU    FH2$L_HIGHWATER 76   3 Please ignore the gibberish in my earlier reply ;-)a  L (I thought I'd scanned all the likely macro files.  Is this ever reported by dump/header ?)   --  $ Stop the world!  I want to get off!    Mail john rather than nospam...e   ------------------------------  % Date: Tue, 23 Nov 2004 11:19:30 -0500h- From: JF Mezei <jfmezei.spamnot@teksavvy.com> M Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought. , Message-ID: <41A362F6.E800A834@teksavvy.com>   briggs@encompasserve.org wrote:iG > > Where does the "highwater" mark reside ? Is it in the file header ?w    G Thanks. finally got to the VMS documentation. Not sure if there is mored
 complete one.e   Here is relevant text:G 	  For nonshared sequential files, the performance impact of high-watersQ        marking is minimal. However, for files of nonsequential format, high-waternD        marking creates some overhead; the system erases the previousL        contents of the disk blocks allocated every time a file is created or        extended.    L So, if one were to create a huge empty sequential file, the HW mark would beK at block 0 with the remainder containing confidential payroll formerly fromo another user, right ?o  M Now, if you were to use SET FILE/ATTRIB=ORG=REL  , the file would now be in apC state where normally all blocks allocated woudl have been zeroed atoL allocation. Would the system still see that the HW mark is still at bolock 0= and then zap blocks 0 to 20 when you tried to read block 20 ?8   ------------------------------    Date: 23 Nov 2004 10:18:28 -0600 From: briggs@encompasserve.orgM Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.X3 Message-ID: <tKh68O5wXWmg@eisner.encompasserve.org>b  h In article <k1k6q05fb6b8k5b1brbsqkvcol4gubnlj4@4ax.com>, John Laird <nospam@laird-towers.org.uk> writes:@ > On 23 Nov 2004 08:13:19 -0600, briggs@encompasserve.org wrote: > D >>One of us has misunderstood how high water marking is implemented. >>D >>It is not "erase on extend".  It is "erase when the highwater markC >>moves".  For ordinary sequential files, the highwater mark is theiC >>highest block within the file that has ever been accessed.  It is C >>not the same as the end-of-file block.  It is not the same as thea >>last allocated block.w >>? >>You can extend a 10,000 block file by 90,000 blocks and incurtA >>no overhead.  You can (I believe), move the end-of-file pointer ? >>out to block 100,000 in the resulting file and still incur no D >>overhead.  But if you try to read from block 100,000, you'd betterD >>sit back and wait as the file system erases 90,000 blocks for you. > K > And if you don't read but instead your process dies, then what is left inuN > the file to indicate to the next reader that those blocks were never writtenK > or safely zeroed ?  The only clue in the file header is the EOF position.e  * Or the high water mark in the file header.   	John Briggs   ------------------------------  % Date: Tue, 23 Nov 2004 16:28:41 +0000:- From: John Laird <nospam@laird-towers.org.uk>DM Subject: Re: Yet another [Un]Zip behavior quirk.  Non-stupid opinions sought.e8 Message-ID: <m8p6q0125cgmjfaqe5o4ii5eio1ugop5ab@4ax.com>  > On 23 Nov 2004 10:18:28 -0600, briggs@encompasserve.org wrote:  i >In article <k1k6q05fb6b8k5b1brbsqkvcol4gubnlj4@4ax.com>, John Laird <nospam@laird-towers.org.uk> writes:r >r7 >>The only clue in the file header is the EOF position.] > + >Or the high water mark in the file header.P   Noted, thanks.   -- D9 Yesterday's flower children are today's blooming idiots. w   Mail john rather than nospam...a   ------------------------------  % Date: Tue, 23 Nov 2004 13:34:47 -0500o# From: "John Smith" <a@nonymous.com>d6 Subject: [OT]: From the Department of Patent Stupidity, Message-ID: <I_GdnfxnVcJUHz7cRVn-sg@igs.net>  3 http://www.eweek.com/article2/0,1759,1730746,00.aspe  J A team of three inventors, two of whom are publicly identified as "membersG of the Visual Basic team," has applied (in a filing published late last-J week) for a U.S. patent on "A system for determining if two operands pointJ to different locations in memory"-in short words, on the IsNot operator in& "BASIC-derived" programming languages. .....s   ------------------------------   End of INFO-VAX 2004.651 ************************