1 INFO-VAX	Thu, 24 Aug 2006	Volume 2006 : Issue 471       Contents:8 Re: %MOUNT-W-INCONSTRUCT, inconsistent VMS error message8 Re: %MOUNT-W-INCONSTRUCT, inconsistent VMS error message8 Re: %MOUNT-W-INCONSTRUCT, inconsistent VMS error message8 Re: %MOUNT-W-INCONSTRUCT, inconsistent VMS error message8 Re: %MOUNT-W-INCONSTRUCT, inconsistent VMS error message5 Re: A true pre-emptive multi-tasking operating system 5 Re: A true pre-emptive multi-tasking operating system 5 Re: A true pre-emptive multi-tasking operating system 5 Re: A true pre-emptive multi-tasking operating system 5 Re: A true pre-emptive multi-tasking operating system 5 Re: A true pre-emptive multi-tasking operating system 5 Re: A true pre-emptive multi-tasking operating system 5 Re: A true pre-emptive multi-tasking operating system 5 Re: A true pre-emptive multi-tasking operating system 5 Re: A true pre-emptive multi-tasking operating system 5 Re: A true pre-emptive multi-tasking operating system 5 Re: A true pre-emptive multi-tasking operating system 5 Re: A true pre-emptive multi-tasking operating system 5 Re: A true pre-emptive multi-tasking operating system 5 Re: A true pre-emptive multi-tasking operating system 5 Re: A true pre-emptive multi-tasking operating system  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day % Re: ANN: DynDNS update client for VMS % Re: ANN: DynDNS update client for VMS % Re: ANN: DynDNS update client for VMS  Re: Datatrieve/CDD protection  Re: Datatrieve/CDD protection  Re: Datatrieve/CDD protection 4 Distributed NetBeans Client for OpenVMS cobol editor' Re: Infoserver 1000 working tape drives  Re: LBR$OPEN Re: LBR$OPEN Re: LBR$OPEN Re: LBR$OPENA Re: openvms - java - timezone - daylight savings - what the heck! A Re: openvms - java - timezone - daylight savings - what the heck!  Re: Oracle8, ODBC and VMS  Re: Oracle8, ODBC and VMS  Re: Personal note - goodbye ! $ Re: Printing to a HP LaserJet 2605dn$ Re: Printing to a HP LaserJet 2605dn2 Re: SEPPUCLU bugcheck introducing new cluster node
 VMS in The DA  Re: WWENG2.SYS Re: WWENG2.SYS Re: WWENG2.SYS Re: WWENG2.SYS  F ----------------------------------------------------------------------    Date: 23 Aug 2006 23:59:25 -0700/ From: "Volker Halle" <volker_halle@hotmail.com> A Subject: Re: %MOUNT-W-INCONSTRUCT, inconsistent VMS error message B Message-ID: <1156402765.731972.314850@74g2000cwt.googlegroups.com>   Larry,  D with V8.2 and LDDRIVER you can easily do your own debugging and find& out, which blocks MOUNT tries to read.   Use   2 $ @sys$startup:ld$startup ! if you haven't already    $ LD CONNECT/REPLACE disk: LDAn: $ LD TRACE LDAn:  D issue your mount commands against LDAn: instead of your SCSI device.   $ LD SHOW/TRACE LDAn:  $ LD DISC LDA1:    Volker.    ------------------------------    Date: 24 Aug 2006 07:02:02 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) A Subject: Re: %MOUNT-W-INCONSTRUCT, inconsistent VMS error message 3 Message-ID: <YdBZtT3R4tnd@eisner.encompasserve.org>   u In article <1156396404.433286.254280@m79g2000cwm.googlegroups.com>, "Volker Halle" <volker_halle@hotmail.com> writes:   A > $ HELP/MESS DOSETVOL contains an appropriate description of the  > necessary actions.  2 No, it suggest one should mount the disk /NOSHARE.C The /NOSHARE qualifier is on of a long list that do nothing to make  this disk mountable.  C Also, note that my goal is _not_ to make an ODS-5 disk.  My goal is   to mount my existing ODS-2 disk.  G > The MOUNT-W-INCONSTRUCT had better been an error or fatal message, if  > it failed to mount the disk.  < No there are subsidiary changed messages that show as fatal.% Theirs is the status returned to DCL.    ------------------------------    Date: 24 Aug 2006 07:21:20 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) A Subject: Re: %MOUNT-W-INCONSTRUCT, inconsistent VMS error message 3 Message-ID: <2Klv$ZLWGe7u@eisner.encompasserve.org>   t In article <1156402765.731972.314850@74g2000cwt.googlegroups.com>, "Volker Halle" <volker_halle@hotmail.com> writes: > Larry, > F > with V8.2 and LDDRIVER you can easily do your own debugging and find( > out, which blocks MOUNT tries to read. >  > Use  > 4 > $ @sys$startup:ld$startup ! if you haven't already > " > $ LD CONNECT/REPLACE disk: LDAn: > $ LD TRACE LDAn: > F > issue your mount commands against LDAn: instead of your SCSI device. >  > $ LD SHOW/TRACE LDAn:  > $ LD DISC LDA1:   ! Thank you.  That is a neat trick.  The answers were:    	0	PACKACK|INHERLOG  	1	READPBLK  	1034	READPBLK 	4194499	READPBLK  	4194500	READPBLK  	4194162	READPBLK  	0	AVAILABLE|INHERLOG   F all with an IOSB status of "normal", which indicates to me this is not; a simple matter of all blocks on the disk being unreadable.    ------------------------------    Date: 24 Aug 2006 07:00:05 -0700/ From: "Volker Halle" <volker_halle@hotmail.com> A Subject: Re: %MOUNT-W-INCONSTRUCT, inconsistent VMS error message A Message-ID: <1156428005.315345.41680@i3g2000cwc.googlegroups.com>    Larry,  C LBN 1034 seems to be the Alternate Homeblock LBN - not a good sign, D this is typically only read, if the primary homeblock has a problem.  ; $ MOUNT/FOR LDA1:/NOWRITE just reads the Home Block (LBN 1)   > $ MOUNT/FOR LDA1: reads the Home Block and 2 other blocks: the BITMAP.SYS header and the SCB.  F I must disappoint you about DISKBLOCK, it needs the disk to be mounted	 /FOREIGN.   F But you may get MOUNT/FOR/NOWRITE to work. And I don't think there are physical read problems.    Volker.    ------------------------------    Date: 24 Aug 2006 11:05:42 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) A Subject: Re: %MOUNT-W-INCONSTRUCT, inconsistent VMS error message 3 Message-ID: <jL9BRcBclYMI@eisner.encompasserve.org>   s In article <1156428005.315345.41680@i3g2000cwc.googlegroups.com>, "Volker Halle" <volker_halle@hotmail.com> writes:  > Larry, > E > LBN 1034 seems to be the Alternate Homeblock LBN - not a good sign, F > this is typically only read, if the primary homeblock has a problem. > = > $ MOUNT/FOR LDA1:/NOWRITE just reads the Home Block (LBN 1)  > @ > $ MOUNT/FOR LDA1: reads the Home Block and 2 other blocks: the  > BITMAP.SYS header and the SCB.  A An older version of VMS showed the problem is with SECURITY.SYS .   H > I must disappoint you about DISKBLOCK, it needs the disk to be mounted > /FOREIGN.  > H > But you may get MOUNT/FOR/NOWRITE to work. And I don't think there are > physical read problems.   D MOUNT /OVERRIDE=SECURITY turns out to work on older versions of VMS,6 mounting the disk /NOWRITE (without indicating that) .  # So at least I can get my data back.   9 I have formally reported the message inconsistency to HP.    ------------------------------  % Date: Thu, 24 Aug 2006 10:36:00 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> > Subject: Re: A true pre-emptive multi-tasking operating systemJ Message-ID: <paul.sture.nospam-DB532B.10360024082006@mac.sture.homeip.net>  . In article <0a9Hg.448331$iF6.238352@pd7tw2no>,-  "Villy Madsen" <Villy.Madsen@shaw.ca> wrote:   J > The only problem with *ix is that I can't remember if my name is spelled > 
 > villy or
 > Villy or > VILLY  > 2 > and if I need to use a -H or a -h or a -r or,,,, >   E To compound the case sensitivity issue, the "locate" command doesn't  D have a means of doing a case blind search. So if you can't remember I where a given file is, you can't look up it's exact case sensitive name,  G and if you don't know the casing of the file, you can't find out where   it is.  B (For those unfamiliar with *nix: "locate" searches a periodically B rebuilt database which contains the path names for every publicly  available file on the system.)   Workaround:    locate "" | grep -i myfile  A which of course pipes the entire database through to grep first.    
 Efficient eh?   ? (I believe that at least some versions of Linux do have a case   insensitive option for locate.)   J > and it would be so nice if the MAN (sorry man) entries had some useable 3 > examples that a 55 year brain could make sense of  >   + Grr. YOu don't need to tell me about it :-(    --  
 Paul Sture   ------------------------------  % Date: Thu, 24 Aug 2006 10:42:27 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> > Subject: Re: A true pre-emptive multi-tasking operating systemJ Message-ID: <paul.sture.nospam-EB221C.10422724082006@mac.sture.homeip.net>  A In article <1156396177.150042.95520@i3g2000cwc.googlegroups.com>, )  "toby" <toby@telegraphics.com.au> wrote:    > Villy Madsen wrote: L > > The only problem with *ix is that I can't remember if my name is spelled > >  > > villy or > > Villy or	 > > VILLY  > ? > If it helps, OS X's default filesystem is case insensitive :)   4 But see my other post  in the thread about "locate".    > > 4 > > and if I need to use a -H or a -h or a -r or,,,, > > K > > and it would be so nice if the MAN (sorry man) entries had some useable 5 > > examples that a 55 year brain could make sense of  > H > This is why the web and Google were invented. :) The learning curve on > VMS isn't much less steep. >   H You may have said that in jest. but there's an awful lot of truth in it.  H Another grouse. Without a full time internet connection, you are pretty $ much up  the creek without a paddle.   --  
 Paul Sture   ------------------------------  + Date: Thu, 24 Aug 2006 05:21:11 -0500 (CDT) * From: sms@antinode.org (Steven M. Schweda)> Subject: Re: A true pre-emptive multi-tasking operating system2 Message-ID: <06082405211127_2027FAC5@antinode.org>  ' From: "toby" <toby@telegraphics.com.au>   9 > [...]  The learning curve on VMS isn't much less steep.     G    If a "learning curve" is what you get on a graph of knowledge versus ; time, then why would a steep learning curve be a bad thing?   D    If a "learning curve" is not what you get on a graph of knowledge versus time, then what is it?   H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------   Date: 24 Aug 2006 11:59:04 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)> Subject: Re: A true pre-emptive multi-tasking operating system* Message-ID: <4l5ik8Fcc5hU1@individual.net>  J In article <paul.sture.nospam-DB532B.10360024082006@mac.sture.homeip.net>,2 	Paul Sture <paul.sture.nospam@hispeed.ch> writes:0 > In article <0a9Hg.448331$iF6.238352@pd7tw2no>,/ >  "Villy Madsen" <Villy.Madsen@shaw.ca> wrote:  > K >> The only problem with *ix is that I can't remember if my name is spelled  >>   >> villy or  >> Villy or  >> VILLY >>  3 >> and if I need to use a -H or a -h or a -r or,,,,  >>   >  Sigh, here we go again......  G > To compound the case sensitivity issue, the "locate" command doesn't  - > have a means of doing a case blind search.     From the man page for "locate":   G "-i     Ignore case distinctions in both the pattern and the database."   G >                                             So if you can't remember  K > where a given file is, you can't look up it's exact case sensitive name,  I > and if you don't know the casing of the file, you can't find out where   > it is.  F And then there is the find command, which works on the real filesystem instead of some bogus database.   D ie.  Looking for a file called "NameServer" somewhere in my personalD file space but not being sure if the "N" and/or the "S" are upper or lower case:   *     find ~ -name "[Nn]ame[Ss]erver" -print > D > (For those unfamiliar with *nix: "locate" searches a periodically D > rebuilt database which contains the path names for every publicly   > available file on the system.)  F Another modern tool added at the whim of someone who apparently didn't+ know how to use the tools they already had.    > 
 > Workaround:  >  > locate "" | grep -i myfile > C > which of course pipes the entire database through to grep first.   >  > Efficient eh?   / And totally unnecessary as I pointed out above.   I And, if you really screwed up the filename and have no idea which letters + you might have capitalized there is always:   E        find ~ -name "[Nn][Aa][Mm][Ee][Ss][Ee][Rr][Vv][Ee][Rr]" -print    :-)    > A > (I believe that at least some versions of Linux do have a case  ! > insensitive option for locate.)   @ I would imagine there are very few differences in any version of? locate as it is a fairly new addition to the Unix stable.  But, ? as I also pointed out above, it really is unnecessary as a tool = to do this already existed and has since Version 1 AT&T UNIX.    > K >> and it would be so nice if the MAN (sorry man) entries had some useable  4 >> examples that a 55 year brain could make sense of >>   > - > Grr. YOu don't need to tell me about it :-(   E Some of them do.  Some have had them removed over time as the command ? became to complex to include any reasonable subset of examples.     bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 24 Aug 2006 12:00:58 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) > Subject: Re: A true pre-emptive multi-tasking operating system* Message-ID: <4l5inqFcc5hU2@individual.net>  2 In article <06082405211127_2027FAC5@antinode.org>,- 	sms@antinode.org (Steven M. Schweda) writes: ) > From: "toby" <toby@telegraphics.com.au>  > : >> [...]  The learning curve on VMS isn't much less steep. >  > I >    If a "learning curve" is what you get on a graph of knowledge versus = > time, then why would a steep learning curve be a bad thing?   G Depends on which one you put on the X axis and which one you put on the  Y axis.    > F >    If a "learning curve" is not what you get on a graph of knowledge > versus time, then what is it?    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  + Date: Thu, 24 Aug 2006 07:19:26 -0500 (CDT) * From: sms@antinode.org (Steven M. Schweda)> Subject: Re: A true pre-emptive multi-tasking operating system2 Message-ID: <06082407192613_2027FAC5@antinode.org>  1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)   K > >    If a "learning curve" is what you get on a graph of knowledge versus ? > > time, then why would a steep learning curve be a bad thing?  > I > Depends on which one you put on the X axis and which one you put on the 	 > Y axis.   G    Around here, "a graph of A versus B" implies A on the ordinate and B H on the abscissa.  Things could be different in other places, but I doubtE it.  (Other than in your mind, that is, where anything could happen.)   G    Also, of course, a graph of Y versus X has X and Y axes.  A graph of 2 knowledge versus time has knowledge and time axes.  H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------  % Date: Thu, 24 Aug 2006 14:33:48 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> > Subject: Re: A true pre-emptive multi-tasking operating systemJ Message-ID: <paul.sture.nospam-5BA3CC.14334824082006@mac.sture.homeip.net>  * In article <4l5ik8Fcc5hU1@individual.net>,*  bill@cs.uofs.edu (Bill Gunshannon) wrote:  L > In article <paul.sture.nospam-DB532B.10360024082006@mac.sture.homeip.net>,4 > 	Paul Sture <paul.sture.nospam@hispeed.ch> writes:   > I > > To compound the case sensitivity issue, the "locate" command doesn't  / > > have a means of doing a case blind search.   > ! > From the man page for "locate":  > I > "-i     Ignore case distinctions in both the pattern and the database."  >    Not here (OS X 10.3.9):    locate -i something  usage: locate pattern   I > >                                             So if you can't remember  M > > where a given file is, you can't look up it's exact case sensitive name,  K > > and if you don't know the casing of the file, you can't find out where  
 > > it is. > H > And then there is the find command, which works on the real filesystem! > instead of some bogus database.  > F > ie.  Looking for a file called "NameServer" somewhere in my personalF > file space but not being sure if the "N" and/or the "S" are upper or
 > lower case:  > , >     find ~ -name "[Nn]ame[Ss]erver" -print  @ OK, as long as I can remember which letters are of unknown case.   But it can be slow.    > K > And, if you really screwed up the filename and have no idea which letters - > you might have capitalized there is always:  > G >        find ~ -name "[Nn][Aa][Mm][Ee][Ss][Ee][Rr][Vv][Ee][Rr]" -print  >  > :-)    LOL!   > > C > > (I believe that at least some versions of Linux do have a case  # > > insensitive option for locate.)  > B > I would imagine there are very few differences in any version ofA > locate as it is a fairly new addition to the Unix stable.  But, A > as I also pointed out above, it really is unnecessary as a tool ? > to do this already existed and has since Version 1 AT&T UNIX.  >   B But it's harder to type in a hurry, and can be rather slow in its  response time.  : But thanks. It takes time, but this stuff _is_ sinking in.  F I'll persevere with find (and might just look for a version of locate / which _does_ support case blind searching). :-)    --  
 Paul Sture   ------------------------------    Date: 24 Aug 2006 08:00:33 -0500 From: briggs@encompasserve.org> Subject: Re: A true pre-emptive multi-tasking operating system3 Message-ID: <LTigOh4HoNVV@eisner.encompasserve.org>   _ In article <06082407192613_2027FAC5@antinode.org>, sms@antinode.org (Steven M. Schweda) writes: 3 > From: bill@triangle.cs.uofs.edu (Bill Gunshannon)  > L >> >    If a "learning curve" is what you get on a graph of knowledge versus@ >> > time, then why would a steep learning curve be a bad thing? >>  J >> Depends on which one you put on the X axis and which one you put on the
 >> Y axis. > I >    Around here, "a graph of A versus B" implies A on the ordinate and B J > on the abscissa.  Things could be different in other places, but I doubtG > it.  (Other than in your mind, that is, where anything could happen.)  > I >    Also, of course, a graph of Y versus X has X and Y axes.  A graph of 4 > knowledge versus time has knowledge and time axes.  C So if we put time on the x axis and knowledge on the y axis and say : that "foo has a steep learning curve", this can mean that:  G o If you use "foo", you will gain a bunch of knowledge in a short time.   or E o If you use "foo", you will _need to_ gain a bunch of knowledge in a 
   short time.   F It is the latter interpretation that I think is most natural and whichB makes "steep learning curve" a bad thing.  The folks who can climb* steep learning curves are in short supply.   ------------------------------   Date: 24 Aug 2006 13:16:10 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)> Subject: Re: A true pre-emptive multi-tasking operating system* Message-ID: <4l5n4qFcl57U1@individual.net>  J In article <paul.sture.nospam-5BA3CC.14334824082006@mac.sture.homeip.net>,2 	Paul Sture <paul.sture.nospam@hispeed.ch> writes:, > In article <4l5ik8Fcc5hU1@individual.net>,, >  bill@cs.uofs.edu (Bill Gunshannon) wrote: > M >> In article <paul.sture.nospam-DB532B.10360024082006@mac.sture.homeip.net>, 5 >> 	Paul Sture <paul.sture.nospam@hispeed.ch> writes:  >  >>  J >> > To compound the case sensitivity issue, the "locate" command doesn't 0 >> > have a means of doing a case blind search.  >>  " >> From the man page for "locate": >>  J >> "-i     Ignore case distinctions in both the pattern and the database." >>   >  > Not here (OS X 10.3.9):  >  > locate -i something  > usage: locate pattern   : So that's just one more shortcoming in MacOS, no surprise.   > J >> >                                             So if you can't remember N >> > where a given file is, you can't look up it's exact case sensitive name, L >> > and if you don't know the casing of the file, you can't find out where  >> > it is.  >>  I >> And then there is the find command, which works on the real filesystem " >> instead of some bogus database. >>  G >> ie.  Looking for a file called "NameServer" somewhere in my personal G >> file space but not being sure if the "N" and/or the "S" are upper or  >> lower case: >>  - >>     find ~ -name "[Nn]ame[Ss]erver" -print  > B > OK, as long as I can remember which letters are of unknown case.   Fixed in a later example.  :-)   >  > But it can be slow.   B Depends on the subset of the filesystem that needs to be searched.? I just ran the search above and it took 20 sec. to search 28GB. C locate might not work at all.  Being as the database is most likely E rebuilt at night, as a minimum it is not going to find a file created  today.   >  >>  L >> And, if you really screwed up the filename and have no idea which letters. >> you might have capitalized there is always: >>  H >>        find ~ -name "[Nn][Aa][Mm][Ee][Ss][Ee][Rr][Vv][Ee][Rr]" -print >>   >> :-) >  > LOL!  F Maybe, but it really works.  And it would be fairly trivial to write aG script that would do that for any filename I give it in any case.  But, ( how often do you really need to do this?   >  >> >  D >> > (I believe that at least some versions of Linux do have a case $ >> > insensitive option for locate.) >>  C >> I would imagine there are very few differences in any version of B >> locate as it is a fairly new addition to the Unix stable.  But,B >> as I also pointed out above, it really is unnecessary as a tool@ >> to do this already existed and has since Version 1 AT&T UNIX. >>   > & > But it's harder to type in a hurry,   D Not that hard, if your used to the command and actually know all theD important options.  There are other options that can make the search more relevant.  D >                                     and can be rather slow in its  > response time.  
 See above!   > < > But thanks. It takes time, but this stuff _is_ sinking in. > H > I'll persevere with find (and might just look for a version of locate 1 > which _does_ support case blind searching). :-)    B You can get the source to a version of locate with the "-i" optionF from the FreeBSD distribution.  Being as MacOS is supposed to be using< the FreeBSD userland it should compile without any problems.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 24 Aug 2006 13:24:51 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)> Subject: Re: A true pre-emptive multi-tasking operating system* Message-ID: <4l5nl3Fcl57U2@individual.net>  2 In article <06082407192613_2027FAC5@antinode.org>,- 	sms@antinode.org (Steven M. Schweda) writes: 3 > From: bill@triangle.cs.uofs.edu (Bill Gunshannon)  > L >> >    If a "learning curve" is what you get on a graph of knowledge versus@ >> > time, then why would a steep learning curve be a bad thing? >>  J >> Depends on which one you put on the X axis and which one you put on the
 >> Y axis.   I probably shouldn't, but.....   > I >    Around here, "a graph of A versus B" implies A on the ordinate and B J > on the abscissa.  Things could be different in other places, but I doubtG > it.  (Other than in your mind, that is, where anything could happen.)   J And that would make the learning curve steep only if learning was fast andB easy and we all know that is not what the original poster meant.     > I >    Also, of course, a graph of Y versus X has X and Y axes.  A graph of 4 > knowledge versus time has knowledge and time axes.  H Whatever.  I am fairly certain most everybody knew what he meant and theE steep learning curve he was talking about is usually not considered a I good thing.  Of course, the experiences (both personal and by observation H of large numbers of students over about two decades) of some of us don't4 support this supposed steep learning curve for Unix.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  + Date: Thu, 24 Aug 2006 08:17:16 -0500 (CDT) * From: sms@antinode.org (Steven M. Schweda)> Subject: Re: A true pre-emptive multi-tasking operating system2 Message-ID: <06082408171634_2027FAC5@antinode.org>   From: briggs@encompasserve.org  E > So if we put time on the x axis and knowledge on the y axis and say < > that "foo has a steep learning curve", this can mean that: > I > o If you use "foo", you will gain a bunch of knowledge in a short time.  >  or G > o If you use "foo", you will _need to_ gain a bunch of knowledge in a  >   short time.  > H > It is the latter interpretation that I think is most natural and whichD > makes "steep learning curve" a bad thing.  The folks who can climb, > steep learning curves are in short supply.  /    I won't waste any more time on this, but ...   G    A graph of knowledge versus time does not have X and Y axes.  It has H knowledge and time axes.  Look up "ordinate" and "abscissa" when you get home.   H    No, the _need_ to gain a bunch of knowledge does not set the shape ofD the "learning curve".  The rate of knowledge acquisition sets that. C Something which is difficult to learn has a shallow learning curve, D because learning it takes more time than learning something which is easy to learn.  C    It's not my fault that many people who use the phrase don't make B sense.  If you look around, you can find usage like "exponentiallyG larger", which also makes no sense (as _growth_ can be exponential, not E _size_), but that's not my fault, either.  Lots of people use lots of H math concepts improperly.  I can't stop them, but I reserve the right toG complain about them.  And arguments like "well, you know what he meant" 3 don't change the fact that that's not what he said.   H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------  # Date: Thu, 24 Aug 2006 14:08:20 GMT F From: lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman)> Subject: Re: A true pre-emptive multi-tasking operating system. Message-ID: <opiHg.32$Zm6.341@news.oracle.com>  \ In article <0a9Hg.448331$iF6.238352@pd7tw2no>, "Villy Madsen" <Villy.Madsen@shaw.ca> writes:I >The only problem with *ix is that I can't remember if my name is spelled  > 	 >villy or 	 >Villy or  >VILLY > 1 >and if I need to use a -H or a -h or a -r or,,,,  > I >and it would be so nice if the MAN (sorry man) entries had some useable  2 >examples that a 55 year brain could make sense of >  >Villy  < I think this does depend to some extent on the distribution.  = If you can put up an X-window, I find that xman on Tru64 Unix @ makes it a lot easier to find the command you're likely to want.- And some of the entries have usable examples.   = Still not as good as HELP on OpenVMS, in my experience, but a  step in the right direction.   Bart.    ------------------------------    Date: 24 Aug 2006 07:15:07 -0700 From: etmsreec@yahoo.co.uk> Subject: Re: A true pre-emptive multi-tasking operating systemC Message-ID: <1156428907.503660.182830@m73g2000cwd.googlegroups.com>   F Maybe VMS Engineering could teach HP-UX Engineering about how to write help pages?  :o)    Steve    Bart Z. Lederman wrote: ^ > In article <0a9Hg.448331$iF6.238352@pd7tw2no>, "Villy Madsen" <Villy.Madsen@shaw.ca> writes:K > >The only problem with *ix is that I can't remember if my name is spelled  > >  > >villy or  > >Villy or  > >VILLY > > 3 > >and if I need to use a -H or a -h or a -r or,,,,  > > J > >and it would be so nice if the MAN (sorry man) entries had some useable4 > >examples that a 55 year brain could make sense of > >  > >Villy > > > I think this does depend to some extent on the distribution. > ? > If you can put up an X-window, I find that xman on Tru64 Unix B > makes it a lot easier to find the command you're likely to want./ > And some of the entries have usable examples.  > ? > Still not as good as HELP on OpenVMS, in my experience, but a  > step in the right direction. >  > Bart.    ------------------------------  # Date: Thu, 24 Aug 2006 15:03:18 GMT % From: Rob Brown <mylastname@gmcl.com> > Subject: Re: A true pre-emptive multi-tasking operating systemE Message-ID: <Pine.LNX.4.61.0608240858590.15690@localhost.localdomain>   + On Thu, 24 Aug 2006, Bill Gunshannon wrote:   > > And then there is the find command, which works on the real , > filesystem instead of some bogus database. > G > ie.  Looking for a file called "NameServer" somewhere in my personal  G > file space but not being sure if the "N" and/or the "S" are upper or  
 > lower case:  > + >    find ~ -name "[Nn]ame[Ss]erver" -print    Here in Redhat 7.2 we have  %       find ~ -iname nameserver -print      --    B Rob Brown                        b r o w n a t g m c l d o t c o m6 G. Michaels Consulting Ltd.      (780)438-9343 (voice)4 Edmonton                         (780)437-3367 (FAX)2                                   http://gmcl.com/   ------------------------------  # Date: Thu, 24 Aug 2006 16:04:59 GMT " From:   VAXman-  @SendSpamHere.ORG> Subject: Re: A true pre-emptive multi-tasking operating system0 Message-ID: <00A5AAFD.FC57AD3A@SendSpamHere.ORG>  m In article <Pine.LNX.4.61.0608240858590.15690@localhost.localdomain>, Rob Brown <mylastname@gmcl.com> writes:  >  > , >On Thu, 24 Aug 2006, Bill Gunshannon wrote: > ? >> And then there is the find command, which works on the real  - >> filesystem instead of some bogus database.  >>H >> ie.  Looking for a file called "NameServer" somewhere in my personal H >> file space but not being sure if the "N" and/or the "S" are upper or  >> lower case: >>, >>    find ~ -name "[Nn]ame[Ss]erver" -print >  >Here in Redhat 7.2 we have  > & >      find ~ -iname nameserver -print   Same as in OS X.  N FIND(1)                   BSD General Commands Manual                  FIND(1)   NAME"      find -- walk a file hierarchy   SYNOPSISI      find [-H | -L | -P] [-EXdsx] [-f pathname] [pathname ...] expression    DESCRIPTION K      Find recursively descends the directory tree for each pathname listed, M      evaluating an expression (composed of the ``primaries'' and ``operands'' 5      listed below) in terms of each file in the tree.  :  :       -iname pattern ;              Like -name, but the match is case insensitive.  :  :       -name patternN              True if the last component of the pathname being examined matchesH              pattern.  Special shell pattern matching characters (``['',L              ``]'', ``*'', and ``?'') may be used as part of pattern.  TheseI              characters may be matched explicitly by escaping them with a               backslash (``\'').  :  :    --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------    Date: 24 Aug 2006 10:12:56 -0700- From: "Doug Phillips" <dphill46@netscape.net> > Subject: Re: A true pre-emptive multi-tasking operating systemC Message-ID: <1156439575.961484.245860@p79g2000cwp.googlegroups.com>    Steven M. Schweda wrote:) > From: "toby" <toby@telegraphics.com.au>  > ; > > [...]  The learning curve on VMS isn't much less steep.  >  > I >    If a "learning curve" is what you get on a graph of knowledge versus = > time, then why would a steep learning curve be a bad thing?  > F >    If a "learning curve" is not what you get on a graph of knowledge > versus time, then what is it?  >   C It's the relationship between experience and efficiency, and you're  right about steep being better:    Quoting from Wiki: ##C "The learning curve effect and the closely related experience curve E effect express the relationship between experience and efficiency. As E individuals and/or organizations get more experienced at a task, they E usually become more efficient at them. Both concepts originate in the F old adage, "practice makes perfect", and both concepts are opposite toG the popular misnomer that a "steep" learning curve means that something @ is hard to learn. In fact, a "steep" learning curve implies that something gets easier quickly."  ##  G To avoid jumping into an OS war, I'll speculate that the best operating B system ever developed hasn't yet been released, and once it is the) title will pass to one which will follow.    ------------------------------    Date: 24 Aug 2006 04:48:18 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayC Message-ID: <1156420098.501491.144110@p79g2000cwp.googlegroups.com>    Bill Todd wrote: > Andrew wrote:  > > Bill Todd wrote: > >> Michael Kraemer wrote: ; > >>> In article <44E6087E.FA9BDDEC@teksavvy.com>, JF Mezei , > >>> <jfmezei.spamnot@teksavvy.com> writes: > >>> M > >>>> Well, considering it was the first "mainstream" 64 bit architecture, I O > >>>> wouldn't say that Alpha was late. If at all, it was early to the market. H > >>> even if it were true (Andrew corrected you on that one), so what ?O > >>> It is just now, more than a decade later that people start really looking  > >>> at 64 bit stuff.M > >> Ah, you must be a PC weenie:  that could explain a lot.  Of course, even I > >> PC weenies might have recognized what benefits a 64-bit architecture K > >> could confer on systems configured with 4 GB or less of RAM (let alone K > >> the 64 GB that IA32 servers have supported since 1996 - hmmm, I wonder G > >> why Intel bothered with that?) if he were familiar with NT/2K/XP's M > >> 32-bit approach to its file system cache and how much *virtual* space it  > >> can waste.  > >> > > G > > It would be nice if the benefits of 64bit are as clear as you think  > > they are > J > Actually, *most* things are rather close to what I think they are, sinceB > (unlike you) I don't form firm opinions on negligible (and often > flat-out incorrect) data.  > B >   it would also be nice if your Windows filesystem cache example6 > > was really a 32bit issue and not just an MS issue. > F > Since the context above was explicitly PC technology, moron, the twoI > aren't all that different.  But I guess asking you to try to understand J > what you've read before responding to it would be expecting far too much	 > of you.   8 So why did you introduce it ????????????????????????????  G This is a discussion about Tru64/OpenVMS and their competitors the fact E that example you introduced is only true for Windows doesn't increase + its relevance or did you think it did ?????  >  > ...  > F > > The reality is that 64bit VLM support in Tru64 was of very limitedH > > benefit because the AlphaServer platform was not configurable with a, > > usefull amount of memory, CPU's and I/O. > G > Given a choice between believing you and believing the Tru64 customer > > base's opinions on this point, I'll take the latter any day. >   B Its not an opinion, just read the 8400 configuration guide. It wasG impossible to configure with redundant I/O and 14CPU's and 14GB of RAM. B  There isn't much point having a system with decent I/O bandwidth,  B The 8400 had a 9 slot centerplane into which you could put a 2 CPUD module or a 2 GB memory module or a System I/O module. With a singleD I/O module (no reduncancy and limitted I/O) you have 8 slots left. 8 CPU's 8GB. 6 CPU's 10GB etc.  A Compare that with the Sun 6000 series. 24 CPU's, 24 GB of RAM and G redundant I/O and the 6000 series was a baby compared withe the E10000.     E The reality was that the top of the Alphaserver range for most of the G 90's was only really equivalent to a sun E4500/4000 (12 CPU's, 12GB RAM ? redundant I/O). In fact the E4500 running outperformed the last E iteration of the TurboLaser the GS140 on TPC-C scoring 50K TPM vs 42K G TPM for the GS. By this time in 1999 the Sun was running a 64bit OS and A the GS supported double density memory making 64bit more usefull. I > Tru64 supported at least 8 GB of RAM in a March, 1996, TPC-C system (in E > case you're as mathematically challenged as your are intellectually E > challenged, that's more than 32 bits' worth).  A 12 GB TPC-C system E > followed in March, 1998, a 16 GB TPC-C system in January, 1999 (you H > could even get that much on a lowly quad-socket ES40 later that year),G > and in mid-Y2K 128 GB Alpha systems were available (all these figures J > and dates being only what is revealed in the TPC-C submissions, though IH > suspect those systems probably were configured with the maximum amountF > of supported RAM and were submitted not too long after configuration > availability).  E Ohh dear, let me help you a bit more. You don't need 64bit support to C have a single OS instance that adresses more than 4GB of RAM. 32bit A versions of Solaris, HP-UX, Dynix, AIX and Linux were all able to E support >4G. The Sun E10000 supported 64GB of RAM and one Solaris 2.x & instance could map all of that memory.  F However indevidual processes couldn't address more than 4GB. SomethingF like Oracle consists of multiple processes but these processes need toD access the SGA which is where being able to support more than 4GB of) RAM for a single process becomes usefull.   D In your 8 GB example it is unlikely that Digital actaully configuredE the SGA to be more than 4GB, this is because the 8GB of RAM that they D had was also needed for the kernel and buffers, Oracle processes, TPE Monitor etc and it is unlikely that they would have had 4 GB left for  the SGA.  F In reality Oracle TPC-C platforms hit a wall at about 40-50K TPM where >4GB SGA's became a necessity. The problem was that the 8400 only ever managed about 50% of this. Sequent through the use of OPS in a box demonstrated how with multiple Oracle instances each with its own SGA you could defeat this limit on a 32bit platform.  F It is hard not to conclude from your posts that you don't reallly have@ a good grasp of the subject, however you are welcome to continueC digging if that is what makes you happy. You have also conclusively @ proved my point about your rudness increasing as your ability to converse sensibly falls.   > D > That 128 GB system, idiot, was a full 6 years ago (not that 64-bitI > operation wasn't useful with as little as 8 or 16 GB of RAM, of course, G > which takes us back a bit over 10 full years).  Whereas the drivel to J > which my earlier response was directed (as distinct from your own drivelJ > to which *this* response is directed) alleged that only *now* was 64-bit, > support becoming interesting to customers.  E You seem again to have compeletely missed the point. 64bit support is = in reality all about system balance. Had Digital released the E TurboLaser in a package which supported more than 14 CPU's, more than B 14GB of RAM and a decent amount of I/O at the same time then it isF possible that early TurboLaser customers might have seen benefits from" using a 64bit OS and a 64bit DBMS.  F But as you beautifully illustrate it was in fact another 8 years afterG Alphas initial introduction in 1992 with all its 64bit fanfare that the > platform started to get to memory sizes and CPU number and I/O. bandwidths which made 64bit support necessary.  G Thanks, I am very tempted to reflect one of your increasingly ludicrous F insults back at you but the collapse of your point is rewarding enough
 in itself.   Regards  Andrew Harrison    ------------------------------    Date: 24 Aug 2006 07:59:56 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayC Message-ID: <1156431596.714554.175680@m73g2000cwd.googlegroups.com>    Bill Todd wrote: > Andrew wrote:  > > Bill Todd wrote: > >> Andrew wrote: > >>> Bill Todd wrote: > >>>> Michael Kraemer wrote: = > >>>>> In article <44E6087E.FA9BDDEC@teksavvy.com>, JF Mezei . > >>>>> <jfmezei.spamnot@teksavvy.com> writes: > >>>>> O > >>>>>> Well, considering it was the first "mainstream" 64 bit architecture, I Q > >>>>>> wouldn't say that Alpha was late. If at all, it was early to the market. J > >>>>> even if it were true (Andrew corrected you on that one), so what ?Q > >>>>> It is just now, more than a decade later that people start really looking  > >>>>> at 64 bit stuff.O > >>>> Ah, you must be a PC weenie:  that could explain a lot.  Of course, even K > >>>> PC weenies might have recognized what benefits a 64-bit architecture M > >>>> could confer on systems configured with 4 GB or less of RAM (let alone M > >>>> the 64 GB that IA32 servers have supported since 1996 - hmmm, I wonder I > >>>> why Intel bothered with that?) if he were familiar with NT/2K/XP's O > >>>> 32-bit approach to its file system cache and how much *virtual* space it  > >>>> can waste.  > >>>>I > >>> It would be nice if the benefits of 64bit are as clear as you think  > >>> they areM > >> Actually, *most* things are rather close to what I think they are, since E > >> (unlike you) I don't form firm opinions on negligible (and often  > >> flat-out incorrect) data. > >>E > >>   it would also be nice if your Windows filesystem cache example 8 > >>> was really a 32bit issue and not just an MS issue.I > >> Since the context above was explicitly PC technology, moron, the two L > >> aren't all that different.  But I guess asking you to try to understandM > >> what you've read before responding to it would be expecting far too much  > >> of you. > > < > > So why did you introduce it ???????????????????????????? > H > If you didn't understand why, then why on earth did you think that you0 > were even remotely qualified to respond to it? >  > > K > > This is a discussion about Tru64/OpenVMS and their competitors the fact I > > that example you introduced is only true for Windows doesn't increase / > > its relevance or did you think it did ?????  > F > Hey, moron, it's not *my* job to deal with *your* confusion:  if you; > don't understand a conversation, stay the hell out of it.  >  > >> ... > >>H > >>> The reality is that 64bit VLM support in Tru64 was of very limitedJ > >>> benefit because the AlphaServer platform was not configurable with a. > >>> usefull amount of memory, CPU's and I/O.J > >> Given a choice between believing you and believing the Tru64 customerA > >> base's opinions on this point, I'll take the latter any day.  > >> > > ? > > Its not an opinion, just read the 8400 configuration guide.  > J > Of course it's an opinion, idiot:  an evaluation of *relative benefit toH > the customer* (which you presumed to make, still right up there above)E > is *always* an opinion (and, as I noted, one better advanced by the 4 > customer in question than by some flack like you). >  > ...  > I > > The reality was that the top of the Alphaserver range for most of the K > > 90's was only really equivalent to a sun E4500/4000 (12 CPU's, 12GB RAM  > > redundant I/O).  > I > The discussion (at least before you stuck your incompetent oar into it) G > had nothing to do with Alpha vs. Sun or about the '90s:  it was about I > whether 64-bit support was of any significance before *now* (as you can G > still ascertain - assuming that you are capable of extracting meaning G > from simple text, though that fact is clearly not yet in evidence) by F > returning to the start of this post and perusing the embedded quoted > material there). >   E Of course it was about Alpha vs the competition. If there had been no G competition then Alpha probably would have been a sucess. The fact that E there was and the reasons why Alpha wasn't competitive go back to the 4 core of this discussion.. What a bizarre suggestion.  B Since the thread was about the demise of Alpha which clearly isn'tF happening now, it has already happened your attempts to move the 64bitG discussion into the present entirely lack relevance. Perhaps you should = spend a bit more time reading the thread you are replying to.   = > As (yet again) I already observed, so listen up or shut up.  >  > ...  > # >   You don't need 64bit support to A > > have a single OS instance that adresses more than 4GB of RAM.  > F > Since I already pointed out Pentium's support for 64 GB of RAM sinceG > 1996 (a feature also supported by NT, of course), I'm afraid that one G > can't consider the above as anything resembling a new contribution to  > this conversation. > D http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx  E Sorry wrong again. The Pentium may well have supported 64GB of RAM in E 1996 but but Windows NT Server 4 never did. Neither did Windows 2000, C in fact the first release of Windows that supported 64GB of RAM was , Windows 2003. So much for your contribution.  > And why the ludicrous 8GB example later in your response ?????  G At one point in the thread you demonstrate that you might know what you @ are talking about and then later you demonstrate that you don't.  	 >   32bit E > > versions of Solaris, HP-UX, Dynix, AIX and Linux were all able to I > > support >4G. The Sun E10000 supported 64GB of RAM and one Solaris 2.x * > > instance could map all of that memory. > > @ > > However indevidual processes couldn't address more than 4GB. > H > That, of course, being one of the advantages of a 64-bit architecture,F > nitwit.  Though of course a process in 32-bit NT/2K/XP *can* addressI > more than 4 GB of physical memory by explicitly mapping sections of its 8 > 32-bit virtual address space around the larger region. >   
 >   Something J > > like Oracle consists of multiple processes but these processes need toH > > access the SGA which is where being able to support more than 4GB of- > > RAM for a single process becomes usefull.  > J > Or, in the case of NT, instead uses a single process and maps around theH > larger-than-4GB physical RAM that it's allowed to manage - an approachD > often significantly more efficient than cobbling together multipleD > separate processes in the Unix idiom (an idiom even more laughablyI > expressed in fumbling attempts to compensate for the lack of in-process C > support for parallelism in the days before it had any support for J > asynchrony or system-level process threading) but still not as efficient& > as a 64-bit single-process approach. >   G This was impossible with NT because NT did not support more than 4GB of B physical memory. Of course 2003 is an NT derivative but it is also/ 64bit so your point lacks any relevance at all.   E You also seem to have entirely missed the whole user level and kernel F level threads support which has been inherant in many UNIX's since theG early 1990's. Solaris 2.2 introduced in 1992 had kernel threads, with a D standard API which eventually became POSIX threads to let ISV's like Oracle program for it.  @ Your point was out of date when Alpha was originally introduced.   > ...  > J > > In reality Oracle TPC-C platforms hit a wall at about 40-50K TPM where> >> 4GB SGA's became a necessity. The problem was that the 8400 only ever managed about 50% of this. Sequent through the use of OPS in a box demonstrated how with multiple Oracle instances each with its own SGA you could defeat this limit on a 32bit platform. > > J > > It is hard not to conclude from your posts that you don't reallly have > > a good grasp of the subject  > E > Since you have so far not managed to draw any competent conclusions = > during this discussion, I'd hardly expect you to begin now.  >   F So provide some examples of the incompetent conclusions that you claim I have or havn't drawn.  > ...  > G > >> That 128 GB system, idiot, was a full 6 years ago (not that 64-bit L > >> operation wasn't useful with as little as 8 or 16 GB of RAM, of course,J > >> which takes us back a bit over 10 full years).  Whereas the drivel toM > >> which my earlier response was directed (as distinct from your own drivel M > >> to which *this* response is directed) alleged that only *now* was 64-bit / > >> support becoming interesting to customers.  > > 8 > > You seem again to have compeletely missed the point. > H > No, you fucking idiot:  the point (which once again you can see quotedG > right up at the start of this post) was the ridiculous assertion that A > 64-bit support was only starting to become interesting *today*.  >   F And your claim unless you had forgotten was that 64bit was interestingC a lot earlier than "today".  Hence the discussion about how usefull F 64bit was when Alpha was introduced. Or do you now want to select someE arbitrary point between 1992 and now to base your discussion of 64bit  relevance on ????    Regards  Andrew Harrison    ------------------------------    Date: 24 Aug 2006 08:23:25 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayC Message-ID: <1156433005.012763.128290@h48g2000cwc.googlegroups.com>    Hoff Hoffman wrote:  > Andrew wrote:  > I > > Again you are mistaken, Sun spent a great deal of time worrying about H > > losing business to Alpha because of its 64bit support. However afterF > > the initial flurry of purchases many customers discovered that youJ > > couldn't really benefit from having a 64bit platform at least not with& > > Alpha and so Sun stopped worrying. > P >    Yeah, I heard similar from various Sun folks, too.  I'd just assumed it wasN > the party line for the Sun sales and field folks.  And it was something thatL > always struck me as a denial artfully mixed with a slam, which looked like > marketeering.  > P >    The key to that Sun spiel was the 64 bits part, as nobody then or now needsQ > that much space and isn't likely to need that for quite some time -- it was the O > lack of the 33rd or 34th bit that was at the crux of the support, and we have P > any number of folks that slammed into limit that on OpenVMS VAX, and I slammedR > into similar limits in various Unix flavors over the years.  And more than a fewQ > databases use the extra addressing, as well, and both SPARC and AMD Opteron now P > have the addressing.  So it clearly looks to have value, and apparently enough$ > that even Sun customers needed it.  G Of course, as I pointed out to Bill its about balance. As the amount of D physical memory configurable in a system crept up there came a pointD where having 64bit support became usefull because you could actually7 use the >4GB while having a decent number of CPU's etc.   F But the the TurboLaser never supported enough of CPU/Memory and I/O atE the same time in the same box to make 64bit addressing for individual G processes usefull except in some edge cases and for the very sucessfull @ benchmarketing program run by Digital when Alpha was introduced.  G And by the time AlphaServers did support configurations that made 64bit G support worthwhile everyone else had 64bit OS's anyway. Solaris 7 Sun's F first 64bit OS was released in 1998. HP-UX 11 supported 64bit in 1997.  @ Or put another way by the time AlphaServers acheived the balanceE necessary to support the marketing campaign which Digital launched in E 1992 all Alphas major competitors had the same capability and Digital 
 had vanished.    > J >    And you can bet that Sun was concerned about Alpha, as that bunch wasQ > traditionally smart enough not to be complacent -- case in point: yourself, and H > your valued loyal opposition on-going presence here in the comp.os.vmsK > newsgroup, and the current "you paid how much for a cut-out of two of the O > founders of silicon valley?" marketeering.  (And are the HP OpenVMS folks now M > viewed as competitors for Symantec, or did Sun partner with Symantec when I  > wasn't looking?)  D No HP generally isn't a competitor, nor are my points anti Compaq or> HP. If you have followed the thread you will realise that I amF interested in the over simplistic Palmer killed Alpha and DEC argument5 which does the rounds everytime there is some sort of $ Alpha/DEC/digital/Compaq aniversary.   Regards  Andrew Harrison    ------------------------------  % Date: Thu, 24 Aug 2006 09:06:40 -0700 * From: "Tom Linden" <tom@kednos-remove.com>" Subject: Re: Alpha remembrance day) Message-ID: <op.tesppetttte90l@hyrrokkin>   1 On Thu, 24 Aug 2006 07:25:32 -0700, Bob Koehler   0 <koehler@eisner.nospam.encompasserve.org> wrote:  C > In article <ecgrlp$2lg$02$1@news.t-online.com>, Michael Kraemer    > <M.Kraemer@gsi.de> writes: >>2 >> Right. But unfortunately it seems "proprietary"6 >> turns into an advantage if the "property" comprises >> 90% of the market.  > A >    Gee, sounds like a VAX.  People got off VAXen because of the B >    price/performance; many of them screaming and hollering while> >    their software, security, and reliability were castrated. >   D As you have intimated, it is because the myopically focused on price rather than cost.      --  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Thu, 24 Aug 2006 19:01:23 +0930 * From: Mark Daniel <mark.daniel@vsm.com.au>. Subject: Re: ANN: DynDNS update client for VMS0 Message-ID: <12er019crope004@corp.supernews.com>   David J. Dachtera wrote: > Mark Daniel wrote: >  >>David J. Dachtera wrote: >> >>>Mark Daniel wrote:  >>>  >>>  >>>>David J. Dachtera wrote: >>>> >>>> >>>>>Mark Daniel wrote:  >>>>>  >>>>>  >>>>> 1 >>>>>>Recent discussion of a DynDNS update client  >>>>>>1 >>>>>> http://www.dyndns.com/services/dns/dyndns/  >>>>>>M >>>>>>in this forum prompted me to do something I'd been meaning to for years M >>>>>>- put together a native version for VMS and move the update duties from J >>>>>>my PC to my VMS system.  It has now been running for some four weeksL >>>>>>without too many hiccoughs so you are welcome to give it a go as well.G >>>>>>It requires the HP [Open]SSL product to be installed and started.  >>>>>>J >>>>>>A complementary application included, DynDNSrpt, is a CGI Web serverJ >>>>>>application that can be used as a basic reporting tool for the aboveJ >>>>>>application (should be suitable for Apache, OSU, Purveyor and WASD). >>>>>>M >>>>>>Setup, build instructions and revision log for each may be found in the D >>>>>>source code each of the respective applications once restored. >>>>>>> >>>>>>A ZIPed source-code kit (it is assumed users will be VMSF >>>>>>enthusiasts/hobbiests with their own compiler) is available from >>>>>># >>>>>> http://wasd.vsm.com.au/wasd/  >>>>>> >>>>>>Hope it's useful.  >>>>>  >>>>> E >>>>>Just wondering if this has any advantage over the WGET approach?  >>>>H >>>>Don't know David.  I'm aware of the DCL-based utility that uses WGETJ >>>>because of the recent discussion here that mentioned it.  I didn't useH >>>>it as a reference when putting together my own though and so I'm not' >>>>aware of what it can (or can't do).  >>>  >>> 2 >>>As I use it, the WGET approach works like this: >>> K >>>1. "Visit" a URL that returns "your" IP address as viewed by the outside  >>>world (the internet). >>> ; >>>2. "Visit" a second URL that causes the update to occur.  >>> / >>>A little bit of DCL in between does the job.  >> >>That's the gist. >>% >>There's a bit more to it of course.  >>C >>DynDNS' specifications have a number of policies regarding client D >>behaviour.  These, amongst other requirements, limit the number ofI >>accesses to their web-based client IP identification service in a given G >>period, and require that the update service only be accessed when the E >>client's IP address has actually changed. Poor client behaviour can D >>result in being blocked by DynDNS (someone has reported to me thisF >>happened to them when a local modification to their VMS-based clientH >>made it a little too eager to keep DynDNS informed :-)  Various DynDNSB >>update service responses should be parsed and behaviour modified >>appropriately.  And so forth.  >  > + > Mine runs nightly, in batch (of course!).  > H > A caveat would be that your address needs to be updated at least everyJ > 30 days, whether the IP address has changed or not or you will receive a+ > de-activation e-mail with a grace period.   G Another one of those policies.  DynDNSupd defaults to 14 days for this  F 'forced' update and allows local customisation with /FORCE=<integer>. A My domestic ADSL2+ seems flakey enough (probably due to the four  D telephony devices additionally hanging off the local loop) to never H reach this milestone (and hence the 'forced' update is untested in that  sense).   F > My update job dropped off the queue for some reason, and that's what > happened to me a month later.  >  > B >>Of course there are other bells-and-whistles that make the basicE >>functionality of any application more useful or pleasant to use and  >>DynDNSupd is no different. >>? >>The 80-20 rule (or variant) applies here as much as anywhere.  >  >  > Whatever works for ya!   ------------------------------  % Date: Thu, 24 Aug 2006 19:02:45 +0930 * From: Mark Daniel <mark.daniel@vsm.com.au>. Subject: Re: ANN: DynDNS update client for VMS0 Message-ID: <12er03qfi2o4427@corp.supernews.com>   Paul Sture wrote: 2 > In article <12elgg73f5gn3a6@corp.supernews.com>,. >  Mark Daniel <mark.daniel@vsm.com.au> wrote: >  > % >>There's a bit more to it of course.  >>D >>DynDNS' specifications have a number of policies regarding client E >>behaviour.  These, amongst other requirements, limit the number of  J >>accesses to their web-based client IP identification service in a given H >>period, and require that the update service only be accessed when the G >>client's IP address has actually changed.  Poor client behaviour can  E >>result in being blocked by DynDNS (someone has reported to me this  G >>happened to them when a local modification to their VMS-based client  I >>made it a little too eager to keep DynDNS informed :-)  Various DynDNS  C >>update service responses should be parsed and behaviour modified   >>appropriately.  And so forth.  >> >  > ! > Thanks very much for this Mark.    Thankyou for commenting Paul.   J > I was previously using the DynDNSUpdater for OS X that I picked up from I > the dyndns website. Yuk, it was doing a query every minute. Given that  = > my IP address doesn't change very often, that was overkill.    ------------------------------  % Date: Thu, 24 Aug 2006 19:32:50 +0930 * From: Mark Daniel <mark.daniel@vsm.com.au>. Subject: Re: ANN: DynDNS update client for VMS0 Message-ID: <12er1s8iebtfu0f@corp.supernews.com>   Mark Daniel wrote: > David J. Dachtera wrote: >  >> Mark Daniel wrote:  >> >>> David J. Dachtera wrote: >>>  >>>> Mark Daniel wrote:  >>>> >>>> >>>>> David J. Dachtera wrote: >>>>>  >>>>>  >>>>>> Mark Daniel wrote:  >>>>>> >>>>>> >>>>>>3 >>>>>>> Recent discussion of a DynDNS update client  >>>>>>> 2 >>>>>>> http://www.dyndns.com/services/dns/dyndns/ >>>>>>> J >>>>>>> in this forum prompted me to do something I'd been meaning to for 
 >>>>>>> years D >>>>>>> - put together a native version for VMS and move the update  >>>>>>> duties from L >>>>>>> my PC to my VMS system.  It has now been running for some four weeksI >>>>>>> without too many hiccoughs so you are welcome to give it a go as  
 >>>>>>> well. I >>>>>>> It requires the HP [Open]SSL product to be installed and started.  >>>>>>> L >>>>>>> A complementary application included, DynDNSrpt, is a CGI Web serverL >>>>>>> application that can be used as a basic reporting tool for the aboveL >>>>>>> application (should be suitable for Apache, OSU, Purveyor and WASD). >>>>>>> I >>>>>>> Setup, build instructions and revision log for each may be found   >>>>>>> in theF >>>>>>> source code each of the respective applications once restored. >>>>>>> @ >>>>>>> A ZIPed source-code kit (it is assumed users will be VMSH >>>>>>> enthusiasts/hobbiests with their own compiler) is available from >>>>>>> $ >>>>>>> http://wasd.vsm.com.au/wasd/ >>>>>>>  >>>>>>> Hope it's useful.  >>>>>> >>>>>> >>>>>>G >>>>>> Just wondering if this has any advantage over the WGET approach?  >>>>>  >>>>> J >>>>> Don't know David.  I'm aware of the DCL-based utility that uses WGETL >>>>> because of the recent discussion here that mentioned it.  I didn't useJ >>>>> it as a reference when putting together my own though and so I'm not) >>>>> aware of what it can (or can't do).  >>>> >>>> >>>>4 >>>> As I use it, the WGET approach works like this: >>>>F >>>> 1. "Visit" a URL that returns "your" IP address as viewed by the  >>>> outside >>>> world (the internet). >>>>= >>>> 2. "Visit" a second URL that causes the update to occur.  >>>>1 >>>> A little bit of DCL in between does the job.  >>>  >>>  >>> That's the gist. >>> ' >>> There's a bit more to it of course.  >>> E >>> DynDNS' specifications have a number of policies regarding client F >>> behaviour.  These, amongst other requirements, limit the number ofK >>> accesses to their web-based client IP identification service in a given I >>> period, and require that the update service only be accessed when the G >>> client's IP address has actually changed. Poor client behaviour can F >>> result in being blocked by DynDNS (someone has reported to me thisH >>> happened to them when a local modification to their VMS-based clientJ >>> made it a little too eager to keep DynDNS informed :-)  Various DynDNSD >>> update service responses should be parsed and behaviour modified! >>> appropriately.  And so forth.  >> >> >>, >> Mine runs nightly, in batch (of course!). >>I >> A caveat would be that your address needs to be updated at least every K >> 30 days, whether the IP address has changed or not or you will receive a , >> de-activation e-mail with a grace period. >  > I > Another one of those policies.  DynDNSupd defaults to 14 days for this  K > 'forced' update and allows local customisation with /FORCE=<integer>. My  J > domestic ADSL2+ seems flakey enough (probably due to the four telephony G > devices additionally hanging off the local loop) to never reach this    @ Actually I just realised it's five additional telephony devices!   3 x telephones 1 x cable TV dial-back4 1 x answering machine (to ameliorate telephony SPAM)  E Each with their own in-line filter.  It's a great compliment to ADSL   technology it stays up at all!  F > milestone (and hence the 'forced' update is untested in that sense). > G >> My update job dropped off the queue for some reason, and that's what   >> happened to me a month later. >> >>D >>> Of course there are other bells-and-whistles that make the basicG >>> functionality of any application more useful or pleasant to use and  >>> DynDNSupd is no different. >>> A >>> The 80-20 rule (or variant) applies here as much as anywhere.  >> >> >> >> Whatever works for ya!    ------------------------------  # Date: Thu, 24 Aug 2006 14:12:22 GMT F From: lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman)& Subject: Re: Datatrieve/CDD protection. Message-ID: <atiHg.33$Zm6.355@news.oracle.com>  n In article <1156357901.427099.294320@i42g2000cwa.googlegroups.com>, "Rich Jordan" <jordan@ccs4vms.com> writes: > E >BTW, DTR V7.3, Rdb V7.0-62, CDD V7.0A, on OpenVMS Alpha V7.3-2, with  >MANMAN V11.4. >  >Rich   A If I remember correctly from your first message, I think you said 8 you had migrated off of CDD for your other applications.  ? In that case, you might want to move the Datatrieve definitions D out of CDD and into ordinary RMS files.  You will probably find that+ Datatrieve starts up a lot faster that way.   < Rdb is good for application data, but I've always found that< Datatrieve runs better with it's own metadata out of the CDD and in RMS files.    Bart.    ------------------------------    Date: 24 Aug 2006 07:04:42 -0700( From: "Rich Jordan" <jordan@ccs4vms.com>& Subject: Re: Datatrieve/CDD protectionB Message-ID: <1156428281.949681.327130@75g2000cwc.googlegroups.com>   Bart Z. Lederman wrote: p > In article <1156357901.427099.294320@i42g2000cwa.googlegroups.com>, "Rich Jordan" <jordan@ccs4vms.com> writes: > > G > >BTW, DTR V7.3, Rdb V7.0-62, CDD V7.0A, on OpenVMS Alpha V7.3-2, with  > >MANMAN V11.4. > >  > >Rich  > C > If I remember correctly from your first message, I think you said : > you had migrated off of CDD for your other applications. > A > In that case, you might want to move the Datatrieve definitions F > out of CDD and into ordinary RMS files.  You will probably find that- > Datatrieve starts up a lot faster that way.  > > > Rdb is good for application data, but I've always found that> > Datatrieve runs better with it's own metadata out of the CDD > and in RMS files.  >  > Bart.    Bart, A      thanks for the response. Unfortunately we've had other sites D migrate off CDD when upgrading MANMAN; one of the reasons we have soE little experience with the product (and datatrieve too), but not this ( site; they are staying with the product,  B      We've compared the RMU privs on the VAX and Alpha copies, andG while different they appear to be compatible.  We have not been able to F get auditing going on the databases at Rdb level; all the commands areD there, RMU/SHOW AUDIT... shows them enabled, but nothing shows up in? the audit log no matter what accesses or operations we attempt.    Rich   ------------------------------    Date: 24 Aug 2006 09:47:43 -0700( From: "Rich Jordan" <jordan@ccs4vms.com>& Subject: Re: Datatrieve/CDD protectionA Message-ID: <1156438063.412799.68490@75g2000cwc.googlegroups.com>   D Found at least part of the problem.  Initial docs indicated Rdb V7.1E would be acceptable, but we found after installation that in fact the E multiversion Rdb (all that is available in V7.1 and beyond) would not B work with numerous application builds that had hard codes in them.  > V7.1 was deinstalled, along with CDD, and V7.0a single version installed, and CDD reinstalled.   B The CDD$COMPATIBILITY database did not get rebuilt or recreated byF these installs, and apparently were not removed by the deinstall.  TheD root file version of CDD$COMPATIBILITY:CDD$DATABASE.RDB is Rdb V7.1.8 DMU doesn't complain, but CDO does report the Rdb error.  ? So... is there any way  to force a rebuild or reconstruction of @ CDD$COMPATIBILITY without (hopefully) deinstalling all the laterE layered products that sit on top of CDD (mainly DBMS and Datatrieve)? C I've been perusing the KITINSTAL.COM file for CDD but its more than @ slightly obtuse, and of course Oracle doesn't provide a means ofD downgrading a root file version from V7.1 to V7.0; only upgrades are
 supported.  G Thanks for any info.  I'm seeing if we can get a metalink connection to ) look to Oracle online for assistance too.    Rich   ------------------------------    Date: 24 Aug 2006 06:09:19 -07005 From: "Robert Zoebinger" <Robert.Zoebinger@knapp.com> = Subject: Distributed NetBeans Client for OpenVMS cobol editor C Message-ID: <1156424959.677127.293390@i42g2000cwa.googlegroups.com>    Hello!  . I have just installed ,,Distributed Netbeans":. - IDE Server for OpenVMS 8.2-1  on Itanuim I64E - Distributed NetBeans Client for OpenVMS on my Desktop MS-Windows XP ! (Netbeans 3.6, Java SDK 1.4.2-12)   F Everything works well except the settings for the cobol editor. When IG change for instance some colours for the syntax highlighting during the A active session everything is OK but after restarting Netbeans all A changes are lost. This problem occurs only with the cobol editor,  C/C++, Fortran are OK.. Further I have checked my local home directory@ "\.netbeans\3.6\system\Editors\text\x-openvms-cobol" for storing
 the settings: * In fontsColors.xml the changes are made...   <?xml version="1.0"?> F <!DOCTYPE fontscolors PUBLIC "-//NetBeans//DTD Editor Fonts and Colors settings 1.0//EN"   9 "http://www.netbeans.org/dtds/EditorFontsColors-1_0.dtd"> 
 <fontscolors> ?     <fontcolor foreColor="#000099" syntaxName="Reserved Words"> 8         <font name="Monospaced" size="16" style="bold"/>     </fontcolor>4     <fontcolor bgColor="#0000CC" foreColor="#FFFF00" syntaxName="Comments">:         <font name="Monospaced" size="16" style="italic"/>     </fontcolor>4     <fontcolor bgColor="#FFFFFF" foreColor="#000000" syntaxName="default"> 9         <font name="Monospaced" size="16" style="plain"/>      </fontcolor>@     <elementcolor color="#FF0033" name="text-limit-line-color"/> </fontscolors>  9 But starting Netbeans again, the changes does not affect!   B Can anybody help and give me some advice? Maybe it's a little bug?  
 Kind regards,    Robert   ------------------------------  # Date: Thu, 24 Aug 2006 15:48:51 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>0 Subject: Re: Infoserver 1000 working tape drives/ Message-ID: <DTjHg.186$0O2.69@news.cpqcorp.net>    Rich Jordan wrote: > Thats a bit of a heftyC > unit for such moderate capacity; if a DDS-3 or better DAT will by 3 > chance work, that would be a much nicer solution.   K    DDS (DAT) is designed for and is best for infrequent use or for mailing  O around DDS media or such, and the drives and the media are designed and priced   and rated accordingly.  N    If there's a DLT around with sufficient capacity and you're making regular R use of the media and the tapes for archival purposes, that's the direction I'd go.  M    DDS media is typically rated for 2000 head passes, which worked out to be  P about 20 re-uses of the tape media given my admittedly somewhat involved BACKUP P scheme -- my automated BACKUP sequence was re-scanning the tape labels multiple P times for each part of an aggregate BACKUP operation, which apparently ended up N wearing through the recording substrate.  I was burning through the DDS media O pretty regularly with my particularly archival strategy, in other words.  With  J DLT, short of having the tape eaten or the leader chewed off (and which I L haven't seen since TK50 days, barring mishandling or massive wear), the DLT + cartridges and drives have "just worked..."   Q    FWIW.  (And don't get me wrong here, I can and do use DDS, too.  But for some   tasks, DLT is simply superior.)    ------------------------------    Date: 24 Aug 2006 00:28:18 -0700/ From: "Volker Halle" <volker_halle@hotmail.com>  Subject: Re: LBR$OPEN B Message-ID: <1156404498.746324.123070@i3g2000cwc.googlegroups.com>  ? Here is a pointer to a FORTRAN Example using the LBR$ routines:   R http://h18000.www1.hp.com/support/asktima/appl_tools/00964176-B74E3260-1C02A1.html  B Make sure you declare the LBR$ routines as INTEGER*4 and check the status after each call.    Volker.    ------------------------------  % Date: Thu, 24 Aug 2006 00:51:47 -0700 # From: Joe Bloggs <JBloggs@acme.com>  Subject: Re: LBR$OPEN 8 Message-ID: <ffmqe2h0f20otcjeo0bnu2el3fmd379qsd@4ax.com>  : On 23 Aug 2006 18:41:12 -0700, wendzinski@yahoo.com wrote:  C >I am trying to access the MANMAN help library in a FORTRAN program  >using the following commands: > + >ISTAT=LBR$INI_CONTROL(LIBINDEX,LBR$C_READ) . >ISTAT=LBR$OPEN(LIBINDEX,'MM$HELP:MMHELP.HLB') > G >The first command returns a value of 1 in LIBINDEX.  However, the open 8 >command is not working.  Any help would be appreciated.  % depending on what you needed to do,   4 possibly lbr$output_help might be easier  to use ...  , in C, it would look approximately  like so:          $DESCRIPTOR(         hlb_dsc          ,"MM$HELP:MMHELP.HLB" 
         );     $DESCRIPTOR(         key_dsc          ,"MMHELP" 
         );     unsigned int         help_flags =5         (HLP$M_PROMPT | HLP$M_PROCESS | HLP$M_GROUP | 8          HLP$M_SYSTEM | HLP$M_LIBLIST | HLP$M_HELP    );   
         sts =              lbr$output_help(                   &lib$put_output                 ,0                 ,&key_dsc                  ,&hlb_dsc                  ,&help_flags                 ,&lib$get_input                  );            ------------------------------    Date: 24 Aug 2006 04:50:34 -0700 From: wendzinski@yahoo.com Subject: Re: LBR$OPEN B Message-ID: <1156420234.037159.56240@m79g2000cwm.googlegroups.com>   David B Sneddon wrote: > wendzinski@yahoo.com wrote: F > > I am trying to access the MANMAN help library in a FORTRAN program! > > using the following commands:  > > . > > ISTAT=LBR$INI_CONTROL(LIBINDEX,LBR$C_READ)1 > > ISTAT=LBR$OPEN(LIBINDEX,'MM$HELP:MMHELP.HLB')  > > J > > The first command returns a value of 1 in LIBINDEX.  However, the open; > > command is not working.  Any help would be appreciated.  > 8 > What is the return status?  That will tell you exactly > what the problem is... >  > Dave  > Thanks to everybody for their responses.  The problem was thatA LBR$C_READ was not defined.  I assumed it was in an include file. . Adding this line in the declarations fixed it:  # PARAMETER       LBR$C_READ      = 1   " Before that, the error status was:  ( %LBR-F-ILLCREOPT, illegal create options   -Tom   ------------------------------    Date: 24 Aug 2006 05:05:44 -0700 From: wendzinski@yahoo.com Subject: Re: LBR$OPEN C Message-ID: <1156421144.195963.179230@b28g2000cwb.googlegroups.com>    wendzinski@yahoo.com wrote:  > David B Sneddon wrote: > > wendzinski@yahoo.com wrote: H > > > I am trying to access the MANMAN help library in a FORTRAN program# > > > using the following commands:  > > > 0 > > > ISTAT=LBR$INI_CONTROL(LIBINDEX,LBR$C_READ)3 > > > ISTAT=LBR$OPEN(LIBINDEX,'MM$HELP:MMHELP.HLB')  > > > L > > > The first command returns a value of 1 in LIBINDEX.  However, the open= > > > command is not working.  Any help would be appreciated.  > > : > > What is the return status?  That will tell you exactly > > what the problem is... > >  > > Dave > @ > Thanks to everybody for their responses.  The problem was thatC > LBR$C_READ was not defined.  I assumed it was in an include file. 0 > Adding this line in the declarations fixed it: > % > PARAMETER       LBR$C_READ      = 1  > $ > Before that, the error status was: > * > %LBR-F-ILLCREOPT, illegal create options >  > -Tom    G Including the library definitions file also worked.  This is probably a  better solution.           INCLUDE '($LBRDEF)'    Thanks,  Tom    ------------------------------  % Date: Thu, 24 Aug 2006 06:23:10 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> J Subject: Re: openvms - java - timezone - daylight savings - what the heck!< Message-ID: <44ed7cba$0$24209$9a6e19ea@news.newshosting.com>  B "David J. Dachtera" <djesys.no@spam.comcast.net> wrote in message * news:44ED0E09.E64BED0B@spam.comcast.net... > Neil Rieck wrote: 	 >> [snip]  >> According to this reference: > >> http://java.sun.com/j2se/1.4.2/docs/api/java/util/Date.htmlI >> you need to run the output through method DateFormat.format(Date date)  > H > Just curious as to how you arrived at that based on the quoted URL. InF > IE, Edit->Find returns no occurences of the string ".format" in that > web page.  >  > --   > David J Dachtera > 4 Hmm. I just tried your find example with IE version L 6.0.2900.2180.xpsp_sp2_gdr.050301-1519 and it worked for me. Were you doing  a case-sensitive search?  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html: http://www3.sympatico.ca/n.rieck/links/openvms_demos.html    ------------------------------    Date: 24 Aug 2006 06:46:36 -0700- From: "Wilm Boerhout" <w5.boerhout@planet.nl> J Subject: Re: openvms - java - timezone - daylight savings - what the heck!C Message-ID: <1156427196.344747.142840@b28g2000cwb.googlegroups.com>    Neil Rieck schreef:   E > It seems that the only difference between us is the OS (I'm running I > OpenVMS-7.3-2 while you are running OpenVMS-8.2). Can someone out there 1 > running OpenVMS-8.2 try Troy's JAVA experiment?       $ @sys$login:utc$time_setup show  5 AUTO_DLIGHT_SAV is set to "0" and DTSS is not in use. > You will have to manually change to/from Daylight Saving Time.  < You can do this by executing SYS$MANAGER:UTC$TIME_SETUP.COM,0 or you can use SYS$EXAMPLES:DAYLIGHT_SAVING.COM.    3     LOCAL TIME ZONE          = WET -- DAYLIGHT TIME @     LOCAL SYSTEM TIME        = 24-AUG-2006 15:40:03.94 (WET DST)#     TIME DIFFERENTIAL FACTOR = 2:00 >     TIME ZONE RULE           = WET0WEST-1,M3.4.0/01,M10.5.0/02E     Change WET to WEST on the Fourth Sunday of March (26-Mar-2006) at  01:00 E     Change WEST to WET on the Last Sunday of October (29-Oct-2006) at  02:00     
 $ sho time     24-AUG-2006 15:40:07  
 $ java "Neil"  Thu Aug 24 14:40:19 WEST 2006    $ type neil.java   import java.util.Date;    public class Neil {0        public static void main (String[] args) {*            System.out.println(new Date());        }    }   $ java -version  java version "1.5.0"0 Java(TM) 2 Runtime Environment, Standard EditionD Fast VM (build 1.5.0-1, build J2SDK.v.1.5.0:12/08/2005-05:02, native threads, ji  t_150)   $ sh sys /noproc  @ OpenVMS V8.2  on node AXPDEV  24-AUG-2006 15:42:37.75  Uptime  1 00:44:26   ------------------------------  % Date: Thu, 24 Aug 2006 07:22:20 -0400 * From: "Syltrem" <syltremzulu@videotron.ca>" Subject: Re: Oracle8, ODBC and VMS0 Message-ID: <12er2vf3heuo2ca@corp.supernews.com>  8 <roose_chua@yahoo.com> a crit dans le message de news: 8 1116831849.732227.169800@o13g2000cwo.googlegroups.com...	 > Hi all,  > G > We are currently investigating the possible impact on our AlphaServer A > DS20 (2GB memory, OpenVMS 7.1-2 and UCX 4.2 ECO2) when the ODBC C > connections are increased to the node. The server is using Oracle  > 8.0.5. > H > What system parameters will definitely be affected on this and that weI > need to watch out for? Definitely, this will also impact the memory and E > CPU usage on the node, but will there be a way to estimate how much  > effect will it have? > H > I'm trying to understand this issue, but might as well ask around from1 > experts like you to hasten up my understanding.  > " > Thanks in advance for your help! >  > Roose  >    Hello   L I'm probably very late here... but I would consider using shared servers if  you don't already.I That will help you LOTS as far as memory is concerned, and also some bit   about CPU usage.4 I use it and extended the life of my ES40 once more.   HTH    Syltrem    ------------------------------    Date: 24 Aug 2006 08:11:23 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett) " Subject: Re: Oracle8, ODBC and VMS, Message-ID: <zxv3ErFB2VV$@malvm9.mala.bc.ca>  1 In article <12er2vf3heuo2ca@corp.supernews.com>,  2       "Syltrem" <syltremzulu@videotron.ca> writes:  D >> connections are increased to the node. The server is using Oracle	 >> 8.0.5.  > N > I'm probably very late here... but I would consider using shared servers if  > you don't already.K > That will help you LOTS as far as memory is concerned, and also some bit   > about CPU usage.6 > I use it and extended the life of my ES40 once more. >   L    I would caution against the use of shared servers with Oracle 8.0.5, they were pretty flaky.  H    If it's possible for you to upgrade to Oracle 9.2 then I'd agree withI this recommendation - I use shared servers extensively on VMS with Oracle   9.2 and they seem pretty stable.   ------------------------------  % Date: Thu, 24 Aug 2006 12:19:14 -0400 * From: "Syltrem" <syltremzulu@videotron.ca>& Subject: Re: Personal note - goodbye !0 Message-ID: <12erkc67k6sc68e@corp.supernews.com>  M "Guy Peleg" <guy.peleg@remove_this_header@hp.com> a crit dans le message de  % news: 44e9e4d8@usenet01.boi.hp.com...  > Dear community,  > L > I wanted to let you know that I have decided to leave HP (I chose to leave > onK > my own). I have been part of DEC/CPQ/HP for almost 10 years, 6 of them in  > VMS engineering. > I > I want to thank this forum for all the feedback provided to me over the  > years.J > Look at recent VMS releases (V8.2 and upcoming V8.3) and I'm sure you'llH > be able to see the tremendous impact this forum had (especially in the > utilities  > area). > F > I'm going to work with Bruce Ellis at BRUDEN. The company is growingE > and I'll be responsible for the business in Europe. BRUDEN provides H > training, services and consulting for VMS and other O/S's (guess whichI > area I'll be working on ;-) so there is a good chance you'll be hearing  > more from me.  > C > My new email starting September 1st will be guy.pelegATbruden.com  > 
 > Thank you !  >  > Guy  >  >    Guy,  M Thanks for all the good work done, and for consulting with the customers (us   !) to get some feedback.% Good luck in your future endeavours !    Regards,   Syltrem    ------------------------------    Date: 24 Aug 2006 13:09:07 -04007 From: "Gareth V. Williams" <graff@cfa0.cfa.harvard.edu> - Subject: Re: Printing to a HP LaserJet 2605dn . Message-ID: <44eddd33@cfanews.cfa.harvard.edu>   healyzh@aracnet.com wrote:8 : Gareth V. Williams <graff@cfa0.cfa.harvard.edu> wrote:H : >   I decided that a reboot was in order.  After rebooting, e-mail wasJ : > again working, .LOG files from my Mersenne factor search contained theK : > proper hostname and I could finally print my first file from VMS.  Yah!   N : What are your thoughts on the printer?  The HP LaserJet 2605dn looks to be aO : pretty good value, and I'm actually tempted to get one to replace my HP 5MP.  L : I'd be primarily using it from Mac OS X and OpenVMS.  I like the fact thatK : it's a networked printer that does duplexing, the fact it's colour, is an K : added plus.  At the same time, the 5MP does just about everything I want,  : and is well made.   H   I love it!  And my wife loves it!  The duplexing and colo(u)r printingG work wonderfully: the colo(u)rs are crisp (my wife's reaction on seeing F the colo(u)rs on the config sheet was "Wow!").  If you have a need for colo(u)r, go for it.  
     Gareth  : Disclaimer: Not affiliated with or a shareholder in HP :-)     --  H ------------------------------------------------------------------------H Gareth V. Williams, MS 18, 60 Garden Street, Cambridge, MA 02138, U.S.A.+ Associate Director, IAU Minor Planet Center H gwilliams@cfa.harvard.edu        http://cfa-www.harvard.edu/iau/mpc.html7 OpenVMS & RISC OS: refined choices in operating systems    ------------------------------  % Date: Thu, 24 Aug 2006 13:51:29 -0400  From: norm.raphael@metso.com- Subject: Re: Printing to a HP LaserJet 2605dn Q Message-ID: <OFF379A753.9426B984-ON852571D4.0061F850-852571D4.00621921@metso.com>   E "Gareth V. Williams" <graff@cfa0.cfa.harvard.edu> wrote on 08/24/2006  01:09:07 PM:   > healyzh@aracnet.com wrote:: > : Gareth V. Williams <graff@cfa0.cfa.harvard.edu> wrote:J > : >   I decided that a reboot was in order.  After rebooting, e-mail wasH > : > again working, .LOG files from my Mersenne factor search contained the G > : > proper hostname and I could finally print my first file from VMS.  Yah! > K > : What are your thoughts on the printer?  The HP LaserJet 2605dn looks to  be aE > : pretty good value, and I'm actually tempted to get one to replace  > my HP 5MP.I > : I'd be primarily using it from Mac OS X and OpenVMS.  I like the fact  thatJ > : it's a networked printer that does duplexing, the fact it's colour, is anG > : added plus.  At the same time, the 5MP does just about everything I  want,  > : and is well made.  > J >   I love it!  And my wife loves it!  The duplexing and colo(u)r printingI > work wonderfully: the colo(u)rs are crisp (my wife's reaction on seeing H > the colo(u)rs on the config sheet was "Wow!").  If you have a need for > colo(u)r, go for it.  C What about TCO, the cost of ink cartridges and cost/per 1000 pages?  What about power? J Did you compare it to the Xerox Phaser series, for example, or any others?   >  >     Gareth > < > Disclaimer: Not affiliated with or a shareholder in HP :-) >  >  > --J > ------------------------------------------------------------------------J > Gareth V. Williams, MS 18, 60 Garden Street, Cambridge, MA 02138, U.S.A.- > Associate Director, IAU Minor Planet Center J > gwilliams@cfa.harvard.edu        http://cfa-www.harvard.edu/iau/mpc.html9 > OpenVMS & RISC OS: refined choices in operating systems    ------------------------------    Date: 24 Aug 2006 08:07:20 -0700/ From: "Volker Halle" <volker_halle@hotmail.com> ; Subject: Re: SEPPUCLU bugcheck introducing new cluster node B Message-ID: <1156432039.993448.143990@74g2000cwt.googlegroups.com>   Tom,  B great, so that resource exists locally on TROI, it's a DIRENTR andG there are no locks in any of the lock queues - perfect ! Why would TROI E respond with a fatal message to WORF, when being asked to remove that F resource ? In the fatal message to WORF it said fatal code = 1 = 'hash value does not match'.  , The hash value as received in the LCKMSG was  ! LKMSG$L_HASHVAL          4F02A47B   0 Please look at the hash value stored in the RSB:   SDA> FORMAT FFFFFFFF.3DCC1380     what is in field RSB$L_HASHVAL ?  F If we exclude an OpenVMS error as a cause of this crash for a moment -C how current is this V7.3-1 system regarding patches ? - then a data E corruption error can only happen in the SCS communication path, which F is the ethernet network between the nodes. No cluster traffic is goingG via the SAN (KGPSA). As you said the pair of crashing nodes varied, but B always included the new node, think about common components in theD network communication path between the new nodes and all the others, which crashed.  A The other system is a V7.3-2 system. But the reason for the fatal ? message was also 1 = hash does not match - analysis is ongoing.    Volker.    ------------------------------   Date: 24 Aug 2006 14:50:37 GMT( From: bill@cs.uofs.edu (Bill Gunshannon) Subject: VMS in The DA* Message-ID: <4l5sltFdn9oU1@individual.net>  : Surprise, surprise.  I have actually seen a job posting by7 The Department of the Army looking for someone with VMS : experience (among many other requirements).  Of course, it; is in the one last field that hasn't totally abandoned VMS, < Healthcare.  And, it doesn't read like a conversion but like; an ongoing maintenance/development operation.  Interesting.    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Thu, 24 Aug 2006 08:15:00 +0200 + From: Martin Vorlaender <mv@pdv-systeme.de>  Subject: Re: WWENG2.SYS * Message-ID: <4l4uf4F99apU1@individual.net>   Chris Scheers wrote:< > What is the latest CONDIST that had WWENG2.SYS?  (NA7xxx?)  E The DECserver 700 software (UPI XA5AA) Version 1.1C was last included ' in the June 2003 VAX & Alpha ConDist's.    HTH,	    Martin  --  D One OS to rule them all       | Martin Vorlaender  |  OpenVMS rules!7 One OS to find them           | work: mv@pdv-systeme.de H One OS to bring them all      | http://www.pdv-systeme.de/users/martinv/> And in the Darkness bind them.| home: martin@radiogaga.harz.de   ------------------------------    Date: 24 Aug 2006 00:21:49 -0700/ From: "Volker Halle" <volker_halle@hotmail.com>  Subject: Re: WWENG2.SYS B Message-ID: <1156404109.345083.108870@74g2000cwt.googlegroups.com>   Chris,  D if you are looking for WWENG2.SYS in a NA7xxx (DNAS) Kit, those have$ most likely never been on a CONDIST.  D The DNAS Software has been sold to DNPG (Digital Networks) years go.1 You may be able to order new DNAS V3.3 from them.   & http://eu.digitalnetworks.net/dnas.asp   Volker.    ------------------------------    Date: 24 Aug 2006 07:19:56 -0700( From: "Rich Jordan" <jordan@ccs4vms.com> Subject: Re: WWENG2.SYS B Message-ID: <1156429196.655133.51710@h48g2000cwc.googlegroups.com>   Volker Halle wrote:  > Chris, > F > if you are looking for WWENG2.SYS in a NA7xxx (DNAS) Kit, those have& > most likely never been on a CONDIST. > F > The DNAS Software has been sold to DNPG (Digital Networks) years go.3 > You may be able to order new DNAS V3.3 from them.  > ( > http://eu.digitalnetworks.net/dnas.asp > 	 > Volker.   G If you go this route be careful.  A couple of years ago we tried to buy C the most recent update to DNAS for our older DS700 servers and they E would not/could not provide it.  The newer NAS software only works on F DECservers with more recent firmware/hardware, and DN, at least at theB time, would _not_ provide older versions than whatever the current release was.   Rich CCS    ------------------------------    Date: 24 Aug 2006 09:02:56 -0700; From: "johnhreinhardt@yahoo.com" <johnhreinhardt@yahoo.com>  Subject: Re: WWENG2.SYS B Message-ID: <1156435376.241831.184040@i3g2000cwc.googlegroups.com>   Rich Jordan wrote: > Volker Halle wrote: 
 > > Chris, > > H > > if you are looking for WWENG2.SYS in a NA7xxx (DNAS) Kit, those have( > > most likely never been on a CONDIST. > > H > > The DNAS Software has been sold to DNPG (Digital Networks) years go.5 > > You may be able to order new DNAS V3.3 from them.  > > * > > http://eu.digitalnetworks.net/dnas.asp > >  > > Volker.  > I > If you go this route be careful.  A couple of years ago we tried to buy E > the most recent update to DNAS for our older DS700 servers and they G > would not/could not provide it.  The newer NAS software only works on H > DECservers with more recent firmware/hardware, and DN, at least at theD > time, would _not_ provide older versions than whatever the current > release was.  F This is still true.  I inquired just a couple weeks ago about an olderB version for a DECserver 900TM and they replied that they could notG supply anything but the current version.  FWIW I am now using the NA013 = DECserver kit which I got from a CONDIST from in the 1993, 94 D timeframe.  It has separate portions for both the 700 and the 900TM.C The download image provided is WWENG1.SYS - an earlier version that 7 works (IIRC) with both the DECserver 700 and the 900TM.      John H. Reinhardt    >  > Rich > CCS    ------------------------------   End of INFO-VAX 2006.471 ************************