1 INFO-VAX	Thu, 13 Dec 2001	Volume 2001 : Issue 692       Contents:) CSA (was: RE: Inquirer: OpenVMS on DS20L)  DCL Loop using tags? Re: DCL Loop using tags? Re: DCL Loop using tags? Re: DCL Loop using tags? DEC Alpha 255 - 300 Mhz wanted" Re: DEC Alpha 255 - 300 Mhz wanted" Re: DEC Alpha 255 - 300 Mhz wanted DECC$TIME multiply defined Re: DECC$TIME multiply defined DECC$TIME multiply defined Re: DECC$TIME multiply defined Re: DECC$TIME multiply defined< Re: Ethernet Hardware Address (was: Re: help [[  MCR NCP ]]) help [[  MCR NCP ]]  Re: help [[  MCR NCP ]]  help [[  MCR NCP ]]  Re: help [[  MCR NCP ]]  Re: help [[  MCR NCP ]] " Re: HP Foundations - let them know Re: Info-VAX@Mvb.Saic.Com  Re: Info-VAX@Mvb.Saic.Com  Re: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L3 Re: It you say it often enough does it become fact? 3 Re: It you say it often enough does it become fact?  Re: Linus' view on VMS' Re: Modifying ownership of INDEXF.SYS ?  Re: More depressing IA-64 news Re: Moving from MVS to VMS Re: Moving from MVS to VMS Re: Moving from MVS to VMS* nova (was: RE: Inquirer: OpenVMS on DS20L). Re: nova (was: RE: Inquirer: OpenVMS on DS20L). Re: nova (was: RE: Inquirer: OpenVMS on DS20L)= OT: CERT Advisory - Buffer Overflow in System V Derived Login  Re: Poll Re: SYS$EXAMPLES in 7.3  Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq unix equivalent for F$MODE() ?" Re: unix equivalent for F$MODE() ? Re: Unix for HELP ... Examples? " Re: Unknown VAXstation 4000-90 ???" RE: Unknown VAXstation 4000-90 ??? VAX  Re: VAX, er, Voice Populi  Re: VAX, er, Voice Populi  Re: VAX, er, Voice Populi  Re: vms 3.x question Re: VMS 72 on MV 3100  RE: VMS 72 on MV 3100  Re: VMS 72 on MV 3100  Re: VMS 72 on MV 3100  Re: VMS 72 on MV 3100  Re: VMS file hex editor? Re: VMS file hex editor? Re: VMS file hex editor? Re: VMS file hex editor? Re: VMS file hex editor? Re: VMS file hex editor? Re: where can we beat them? ? Re: Writing a device driver: virtual/physical address questions  Re: WSSIZE and AWSA   F ----------------------------------------------------------------------  + Date: Thu, 13 Dec 2001 16:57:16 +0100 (MET) 9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> 2 Subject: CSA (was: RE: Inquirer: OpenVMS on DS20L); Message-ID: <01KBTRRMLL2O9138XQ@sysdev.deutsche-boerse.com>   H > > To LEGALLY develop (or use) commercial software on a VMS system, youG > > have to a) have valid commercial licenses and b) if you bought them L > > second-hand, pay the transfer fee, which might be more than the price of
 > > the box.   > > E > > If this is not the case, point me to an official statement (e.g.  0 > > somewhere on the Compaq web site) saying so. >  >  > http://csa.compaq.com   F I'm not familiar with CSA, but doesn't it apply to people who develop H software to sell to other people, as opposed to developing it for their E own use?  In other words, if I have a Great Idea for MY OWN business  A which involves software running under VMS, I have to buy regular  @ licenses (even if the business never makes a profit) since even G DEVELOPING something INTENDED for commercial use is not covered by the  F hobbyist license, and, again, CSA is for software developed for other ! people as opposed to for oneself.   D Of course, if I don't develop anything, just use Compaq software, I E still need a full license even if all I do is use VMS to prepare and  . print out bills sent to customers or whatever.   ------------------------------  # Date: Thu, 13 Dec 2001 07:17:54 GMT ! From: ab7ji@earthlink.net (Steph)  Subject: DCL Loop using tags? . Message-ID: <3c1851a1.99246376@news.qwest.net>   Hello VMS DCL Gods, F    I believe I'm trying to do something very simple but don't know howC to start.  I'm trying to write a DCL script that loops through each E tag, executes a bunch of commands, then moves onto the next tag until E all tags are done.  Within the tags would have 4 logical definitions. E What I'm trying to do is use logical references to dismount databases E that are going to live in each logical area, backup the data to tape, A then re-mount.  Move onto the next tag and execute the same thing " creating another backup saveset.  E    I guess I could write a huge DCL script that would just go through B the first area, dismount, backup, and remount.  Move onto the nextD one, but I have about 20 areas wth four directories each. This wouldF be all hardcoded and not very well done.  I figure since the dismount,F remount, and backup commands are going to be exactly the same for eachE of the areas, a loop would be more effective.  This way all I have to = do is add a new tag with logical references for future areas.      Thank you for your time! Steph  ab7ji@earthlink.net    ------------------------------  + Date: Thu, 13 Dec 2001 11:46:39 +0100 (MET) 9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> ! Subject: Re: DCL Loop using tags? ; Message-ID: <01KBTGZYCYNU9138XQ@sysdev.deutsche-boerse.com>    > Hello VMS DCL Gods,    Thanks.  :-)  E > I believe I'm trying to do something very simple but don't know how 
 > to start.     * The problem description is not very clear.  D > I guess I could write a huge DCL script that would just go throughD > the first area, dismount, backup, and remount.  Move onto the nextF > one, but I have about 20 areas wth four directories each. This wouldH > be all hardcoded and not very well done.  I figure since the dismount,H > remount, and backup commands are going to be exactly the same for eachG > of the areas, a loop would be more effective.  This way all I have to ? > do is add a new tag with logical references for future areas.   F Write a loop which reads in a list of your areas from a file and uses E these as parameters passed to a subroutine which does the repetitive   work.   @ If this isn't the answer, you need to make the question clearer.   ------------------------------  % Date: Thu, 13 Dec 2001 12:58:39 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> ! Subject: Re: DCL Loop using tags? , Message-ID: <3C18EC4D.6343FE8D@videotron.ca>   Steph wrote:G >    I guess I could write a huge DCL script that would just go through D > the first area, dismount, backup, and remount.  Move onto the nextF > one, but I have about 20 areas wth four directories each. This would+ > be all hardcoded and not very well done.    O Not sure I understand, but if I do, you may wish to look at subroutines in DCL.   $ HELP CALL and then look at Examples.  H You could write a "generic" subroutine and then call the subroutine with% arguments for each of your databases.    ------------------------------   Date: 13 DEC 2001 18:31:05 GMT+ From: Dave Greenwood <greenwoodde@ornl.gov> ! Subject: Re: DCL Loop using tags? 2 Message-ID: <13DEC01.18310533@feda01.fed.ornl.gov>  " ab7ji@earthlink.net (Steph) wrote: > Hello VMS DCL Gods,   7 I think my God-certificate has lapsed.  Nevertheless...   H >    I believe I'm trying to do something very simple but don't know howE > to start.  I'm trying to write a DCL script that loops through each G > tag, executes a bunch of commands, then moves onto the next tag until G > all tags are done.  Within the tags would have 4 logical definitions. G > What I'm trying to do is use logical references to dismount databases G > that are going to live in each logical area, backup the data to tape, C > then re-mount.  Move onto the next tag and execute the same thing $ > creating another backup saveset.  G >    I guess I could write a huge DCL script that would just go through D > the first area, dismount, backup, and remount.  Move onto the nextF > one, but I have about 20 areas wth four directories each. This wouldH > be all hardcoded and not very well done.  I figure since the dismount,H > remount, and backup commands are going to be exactly the same for eachG > of the areas, a loop would be more effective.  This way all I have to ? > do is add a new tag with logical references for future areas.   C I don't know what you mean by "tag".  Does your tag have a specific 6 structure?  Or is it just a general term you're using?  @ Someone has already suggested creating a text file with the infoG you need.  Read a line, do the dismount or whatever, read another line, E etc.  That may well be the simplest way.  Here's another idea you can C consider.  Create an "array" of symbols, where each symbol contains = your 4 logicals separated by some character - say a "|".  Eg:   ;   TAG_0 = "logical_0_0|logical_0_1|logical_0_2|logical_0_3" ;   TAG_1 = "logical_1_0|logical_1_1|logical_1_2|logical_1_3"   2 You can structure your script something like this:  C   $  max_tags = 100               ! The max number of TAG_n symbols    $  idx = 0   $next_tag:H   $  if f$type(TAG_'idx') .eqs. "STRING"     ! Ie - if the symbol exists	   $  then (   $    log0 = f$element(0,"|",TAG_'idx')(   $    log1 = f$element(1,"|",TAG_'idx')
        ...
   $  endif   $  idx = idx + 1,   $  if idx .le. max_tags then goto next_tag  H The f$type() if-then statement and max_tags variable allow you to removeH a tag from the middle of the array without resubscripting all the higher tags.    Dave --------------9 Dave Greenwood                Email: Greenwoodde@ORNL.GOV H Oak Ridge National Lab        %STD-W-DISCLAIMER, I only speak for myself   ------------------------------  % Date: Thu, 13 Dec 2001 14:16:49 +0100 0 From: Thomas Hahnemann <Thomas.Hahnemann@s-t.de>' Subject: DEC Alpha 255 - 300 Mhz wanted & Message-ID: <3C18AA41.34E5DD37@s-t.de>  ; don't know if these is the right group, but I'm looking for = a DEC Alpha 255 - 300 Mhz or bigger for software develpement. 0 It should have a TGA2 or better graphics module.  & Thanks in advance for hints and offers   Thomas Hahnemann   ------------------------------  % Date: Thu, 13 Dec 2001 14:51:27 +0100 = From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@dummy.com> + Subject: Re: DEC Alpha 255 - 300 Mhz wanted ( Message-ID: <3C18B25F.B363F8F@dummy.com>  5 Gosh, someone's going to develope *new* SW for VMS !! : But wait, you can run Tru64 on that box also, can't you...   :-)    Jan-Erik Sderholm.    Thomas Hahnemann wrote:  > = > don't know if these is the right group, but I'm looking for ? > a DEC Alpha 255 - 300 Mhz or bigger for software develpement. 2 > It should have a TGA2 or better graphics module. > ( > Thanks in advance for hints and offers >  > Thomas Hahnemann   ------------------------------  % Date: Thu, 13 Dec 2001 18:35:15 +0100 ( From: Paul Sture <paul.sture@bluewin.ch>+ Subject: Re: DEC Alpha 255 - 300 Mhz wanted - Message-ID: <VA.000004ea.f396e71a@bluewin.ch>   > In article <3C18AA41.34E5DD37@s-t.de>, Thomas Hahnemann wrote:= > don't know if these is the right group, but I'm looking for ? > a DEC Alpha 255 - 300 Mhz or bigger for software develpement. 2 > It should have a TGA2 or better graphics module. > G Try www.islandco.com If you don't see what you require on the website,  * email them. They are usually very helpful.   ___ 
 Paul Sture Switzerland    ------------------------------  % Date: Thu, 13 Dec 2001 08:44:36 +0100 , From: Theo Jakobus <Theo.Jakobus@iaf.fhg.de># Subject: DECC$TIME multiply defined ) Message-ID: <3C185C64.6010003@iaf.fhg.de>   3 I started to build GNU WGET and got a LINK warning:   9 LINK /TRACE/NOMAP/EXEC=[.ALPHA]WGET.EXE wget.opt /options 2 %LINK-W-MULDEF, symbol DECC$UTIME multiply definedB          in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1Q %MMS-F-ABORT, For target [.ALPHA]WGET.EXE, CLI returned abort status: %X10648268.  $   2 I'm using: Compaq C V6.4-008 on OpenVMS Alpha V7.3     Regards, --    ; *********************************************************** ; *                                                         * ; *  Theo Jakobus                                           * ; *  Fraunhofer-Institut fuer Angewandte Festkoerperphysik  * ; *  Tullastr. 72                                           * ; *  D-79108 Freiburg                                       * ; *  Germany                                                * ; *  Phone:   +49-(0)761-5159-325                           * ; *  FAX :    +49-(0)761-5159-200                           * ; *  e-mail:  Theo.Jakobus@iaf.fhg.de                       * ; *  http://www.iaf.fhg.de                                  * ; *                                                         * ; ***********************************************************    ------------------------------  # Date: Thu, 13 Dec 2001 11:45:03 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) ' Subject: Re: DECC$TIME multiply defined 0 Message-ID: <00A0672A.28879577@SendSpamHere.ORG>  X In article <3C185C64.6010003@iaf.fhg.de>, Theo Jakobus <Theo.Jakobus@iaf.fhg.de> writes:4 >I started to build GNU WGET and got a LINK warning: > : >LINK /TRACE/NOMAP/EXEC=[.ALPHA]WGET.EXE wget.opt /options             /MAP  3 >%LINK-W-MULDEF, symbol DECC$UTIME multiply defined C >         in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1 R >%MMS-F-ABORT, For target [.ALPHA]WGET.EXE, CLI returned abort status: %X10648268. >$ > 3 >I'm using: Compaq C V6.4-008 on OpenVMS Alpha V7.3   
 Post the MAP.    --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              J   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes    ------------------------------  + Date: Thu, 13 Dec 2001 08:05:12 -0600 (CST)  From: sms@antinode.org# Subject: DECC$TIME multiply defined ) Message-ID: <01121308051244@antinode.org>   , From: Theo Jakobus <Theo.Jakobus@iaf.fhg.de>5 > I started to build GNU WGET and got a LINK warning:  > ; > LINK /TRACE/NOMAP/EXEC=[.ALPHA]WGET.EXE wget.opt /options 4 > %LINK-W-MULDEF, symbol DECC$UTIME multiply definedD >          in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1S > %MMS-F-ABORT, For target [.ALPHA]WGET.EXE, CLI returned abort status: %X10648268.  > $  > 4 > I'm using: Compaq C V6.4-008 on OpenVMS Alpha V7.3  E    If you got the Wget kit from me, I'd suggest removing the code for F "utime()" from [.SRC]VMS.C.  As a lowly (and cheap) hobbyist, I do notE have VMS V7.3 yet, and, apparently, "utime()" is a new feature in the  C RTL.  H ------------------------------------------------------------------------  C    Steven M. Schweda               (+1) 651-699-9818  (voice, home) C    382 South Warwick Street        (+1) 763-781-0308  (voice, work) G    Saint Paul  MN  55105-2547      (+1) 763-781-0309  (facsimile, work) 9    sms@antinode.org                sms@provis.com  (work)    ------------------------------  % Date: Thu, 13 Dec 2001 15:28:07 +0100 , From: Theo Jakobus <Theo.Jakobus@iaf.fhg.de>' Subject: Re: DECC$TIME multiply defined ) Message-ID: <3C18BAF7.8070205@iaf.fhg.de>   , This is a multi-part message in MIME format.& --------------0700050005040504050607089 Content-Type: text/plain; charset=us-ascii; format=flowed  Content-Transfer-Encoding: 7bit   $ Brian Schenkenberger, VAXman- wrote:  Z > In article <3C185C64.6010003@iaf.fhg.de>, Theo Jakobus <Theo.Jakobus@iaf.fhg.de> writes: > 5 >>I started to build GNU WGET and got a LINK warning:  >>; >>LINK /TRACE/NOMAP/EXEC=[.ALPHA]WGET.EXE wget.opt /options  >> >             /MAP >  > 4 >>%LINK-W-MULDEF, symbol DECC$UTIME multiply definedC >>        in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1 S >>%MMS-F-ABORT, For target [.ALPHA]WGET.EXE, CLI returned abort status: %X10648268.  >>$  >>4 >>I'm using: Compaq C V6.4-008 on OpenVMS Alpha V7.3 >> >  > Post the MAP.  >     P The attached map shows the reference to DECC$UTIME which is multiply defined in P the shared library SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1 so the question emerges is  the library corrupted?P The abort comes from MMS the LINK does a warning only. The program WGET.EXE has " been built and first tests are ok.# Is there a way to test the library?      Regards, --    ; ***********************************************************s; *                                                         *D; *  Theo Jakobus                                           *C; *  Fraunhofer-Institut fuer Angewandte Festkoerperphysik  * ; *  Tullastr. 72                                           *l; *  D-79108 Freiburg                                       *C; *  Germany                                                *T; *  Phone:   +49-(0)761-5159-325                           *e; *  FAX :    +49-(0)761-5159-200                           * ; *  e-mail:  Theo.Jakobus@iaf.fhg.de                       * ; *  http://www.iaf.fhg.de                                  *u; *                                                         *o; ***********************************************************r  & --------------070005000504050405060708 Content-Type: text/plain;p  name="wget.map" Content-Transfer-Encoding: 7bit  Content-Disposition: inline;  filename="wget.map"   h WGET.EXE                                                        13-DEC-2001 14:58        Linker A12-03                    Page    1X  G                                              +------------------------+oG                                              ! Object Module Synopsis !:G                                              +------------------------+o  l Module Name     Ident              Bytes      File                                Creation Date      Creatorl -----------     -----              -----      -----                               -------------      -------s CMPT            V1.0                   16 CMPT.OBJ;1                           13-DEC-2001 08:23  Compaq C V6.4-008os CONNECT         V1.0                 3032 CONNECT.OBJ;1                        13-DEC-2001 08:23  Compaq C V6.4-008ns FNMATCH         V1.0                 2048 FNMATCH.OBJ;1                        13-DEC-2001 08:23  Compaq C V6.4-008es FTP-BASIC       V1.0                 6509 FTP-BASIC.OBJ;1                      13-DEC-2001 08:23  Compaq C V6.4-0082s FTP-LS          V1.0                 6967 FTP-LS.OBJ;1                         13-DEC-2001 08:23  Compaq C V6.4-008 s FTP-OPIE        V1.0                10352 FTP-OPIE.OBJ;1                       13-DEC-2001 08:23  Compaq C V6.4-008bs FTP             V1.0                19955 FTP.OBJ;1                            13-DEC-2001 08:23  Compaq C V6.4-008-s GETOPT          V1.0                 4115 GETOPT.OBJ;1                         13-DEC-2001 08:23  Compaq C V6.4-008 s HEADERS         V1.0                 1716 HEADERS.OBJ;1                        13-DEC-2001 08:23  Compaq C V6.4-008Rs HOST            V1.0                 6119 HOST.OBJ;1                           13-DEC-2001 08:24  Compaq C V6.4-008 s HTML            V1.0                 8522 HTML.OBJ;1                           13-DEC-2001 08:24  Compaq C V6.4-008hs HTTP            V1.0                19560 HTTP.OBJ;1                           13-DEC-2001 08:24  Compaq C V6.4-008ts INIT            V1.0                11239 INIT.OBJ;1                           13-DEC-2001 08:24  Compaq C V6.4-008 s LOG             V1.0                 2924 LOG.OBJ;1                            13-DEC-2001 08:24  Compaq C V6.4-008hs MAIN            V1.0                14908 MAIN.OBJ;1                           13-DEC-2001 08:24  Compaq C V6.4-008Ms MD5             V1.0                 4712 MD5.OBJ;1                            13-DEC-2001 08:24  Compaq C V6.4-008Ts NETRC           V1.0                 3230 NETRC.OBJ;1                          13-DEC-2001 08:24  Compaq C V6.4-008es RBUF            V1.0                  580 RBUF.OBJ;1                           13-DEC-2001 08:24  Compaq C V6.4-008 s RECUR           V1.0                 9054 RECUR.OBJ;1                          13-DEC-2001 08:24  Compaq C V6.4-008-s RETR            V1.0                14465 RETR.OBJ;1                           13-DEC-2001 08:24  Compaq C V6.4-008Ls URL             V1.0                22983 URL.OBJ;1                            13-DEC-2001 08:24  Compaq C V6.4-008os UTILS           V1.0                11319 UTILS.OBJ;1                          13-DEC-2001 08:24  Compaq C V6.4-008as VERSION         V1.0                   12 VERSION.OBJ;1                        13-DEC-2001 08:24  Compaq C V6.4-0084s VMS             V1.0                 1996 VMS.OBJ;1                            13-DEC-2001 08:24  Compaq C V6.4-008e  H                                             +--------------------------+H                                             ! Program Section Synopsis !H                                             +--------------------------+  k Psect Name      Module Name       Base     End           Length            Align                 Attributesik ----------      -----------       ----     ---           ------            -----                 ----------a $LINK$                          00010000 00014C9F 00004CA0 (      19616.) OCTA  4 NOPIC,CON,REL,LCL,NOSHR,NOEXE,NOWRT,NOVEC,  MOD Q                 CONNECT         00010000 0001022F 00000230 (        560.) OCTA  4 Q                 FNMATCH         00010230 00010277 00000048 (         72.) OCTA  4 Q                 FTP-BASIC       00010280 00010595 00000316 (        790.) OCTA  4hQ                 FTP-LS          000105A0 000108AF 00000310 (        784.) OCTA  4@Q                 FTP-OPIE        000108B0 0001096F 000000C0 (        192.) OCTA  4vQ                 FTP             00010970 0001110F 000007A0 (       1952.) OCTA  4 Q                 GETOPT          00011110 0001126F 00000160 (        352.) OCTA  4 Q                 HEADERS         00011270 0001137F 00000110 (        272.) OCTA  4oQ                 HOST            00011380 0001170F 00000390 (        912.) OCTA  4dQ                 HTML            00011710 00011A58 00000349 (        841.) OCTA  4nQ                 HTTP            00011A60 000122AF 00000850 (       2128.) OCTA  4 Q                 INIT            000122B0 0001282F 00000580 (       1408.) OCTA  4lQ                 LOG             00012830 00012ACF 000002A0 (        672.) OCTA  4aQ                 MAIN            00012AD0 00013107 00000638 (       1592.) OCTA  4hQ                 MD5             00013110 0001319F 00000090 (        144.) OCTA  4lQ                 NETRC           000131A0 0001339F 00000200 (        512.) OCTA  4 Q                 RBUF            000133A0 0001343F 000000A0 (        160.) OCTA  4  s PL_DISK:[JAKOBUS.WGET-1_5_3G.SRC.ALPHA]WGET.EXE;3               13-DEC-2001 14:58        Linker A12-03                    Page    2     k Psect Name      Module Name       Base     End           Length            Align                 Attributesek ----------      -----------       ----     ---           ------            -----                 ----------  $LINK$                          00010000 00014C9F 00004CA0 (      19616.) OCTA  4 NOPIC,CON,REL,LCL,NOSHR,NOEXE,NOWRT,NOVEC,  MOD   Q                 RECUR           00013440 000138EF 000004B0 (       1200.) OCTA  4-Q                 RETR            000138F0 00013D2F 00000440 (       1088.) OCTA  4dQ                 URL             00013D30 0001452F 00000800 (       2048.) OCTA  4aQ                 UTILS           00014530 00014B7F 00000650 (       1616.) OCTA  4 Q                 VMS             00014B80 00014C9F 00000120 (        288.) OCTA  4  $LITERAL$                       00014CA0 0001840F 00003770 (      14192.) OCTA  4   PIC,CON,REL,LCL,  SHR,NOEXE,NOWRT,NOVEC,  MOD Q                 FTP-BASIC       00014CA0 00014CD2 00000033 (         51.) OCTA  4 Q                 FTP-LS          00014CE0 00014D72 00000093 (        147.) OCTA  4lQ                 FTP             00014D80 00015546 000007C7 (       1991.) OCTA  4aQ                 GETOPT          00015550 0001568E 0000013F (        319.) OCTA  4eQ                 HOST            00015690 0001576A 000000DB (        219.) OCTA  4aQ                 HTML            00015770 00015A34 000002C5 (        709.) OCTA  4nQ                 HTTP            00015A40 0001612B 000006EC (       1772.) OCTA  4eQ                 INIT            00016130 00016572 00000443 (       1091.) OCTA  4dQ                 LOG             00016580 000165D3 00000054 (         84.) OCTA  4 Q                 MAIN            000165E0 00017F0B 0000192C (       6444.) OCTA  4dQ                 NETRC           00017F10 00017FC1 000000B2 (        178.) OCTA  4nQ                 RECUR           00017FD0 00018099 000000CA (        202.) OCTA  4mQ                 RETR            000180A0 00018164 000000C5 (        197.) OCTA  4 Q                 URL             00018170 0001837E 0000020F (        527.) OCTA  4tQ                 UTILS           00018380 000183F2 00000073 (        115.) OCTA  4"Q                 VERSION         00018400 00018407 00000008 (          8.) OCTA  4h $READONLY$                      00018410 0001858F 00000180 (        384.) OCTA  4   PIC,CON,REL,LCL,  SHR,NOEXE,NOWRT,NOVEC,  MOD Q                 CMPT            00018410 0001841F 00000010 (         16.) OCTA  4mQ                 FTP-BASIC       00018420 0001842F 00000010 (         16.) OCTA  4xQ                 FTP-LS          00018430 0001843F 00000010 (         16.) OCTA  4 Q                 FTP-OPIE        00018440 0001844F 00000010 (         16.) OCTA  4AQ                 FTP             00018450 0001845F 00000010 (         16.) OCTA  4nQ                 GETOPT          00018460 0001846F 00000010 (         16.) OCTA  4 Q                 HEADERS         00018470 0001847F 00000010 (         16.) OCTA  4aQ                 HOST            00018480 0001848F 00000010 (         16.) OCTA  4.Q                 HTML            00018490 0001849F 00000010 (         16.) OCTA  4-Q                 HTTP            000184A0 000184AF 00000010 (         16.) OCTA  4sQ                 INIT            000184B0 000184BF 00000010 (         16.) OCTA  4sQ                 LOG             000184C0 000184CF 00000010 (         16.) OCTA  4'Q                 MAIN            000184D0 000184DF 00000010 (         16.) OCTA  4sQ                 MD5             000184E0 0001852F 00000050 (         80.) OCTA  4eQ                 NETRC           00018530 0001853F 00000010 (         16.) OCTA  41Q                 RECUR           00018540 0001854F 00000010 (         16.) OCTA  4jQ                 RETR            00018550 0001855F 00000010 (         16.) OCTA  4 Q                 URL             00018560 0001856F 00000010 (         16.) OCTA  46Q                 UTILS           00018570 0001857F 00000010 (         16.) OCTA  4nQ                 VMS             00018580 0001858F 00000010 (         16.) OCTA  4E $DATA$                          00020000 000229BF 000029C0 (      10688.) OCTA  4 NOPIC,CON,REL,LCL,NOSHR,NOEXE,  WRT,NOVEC,  MOD Q                 CONNECT         00020000 00020003 00000004 (          4.) OCTA  4 Q                 FTP-LS          00020010 0002003F 00000030 (         48.) OCTA  4 Q                 FTP-OPIE        00020040 0002207F 00002040 (       8256.) OCTA  4eQ                 FTP             00022080 00022087 00000008 (          8.) OCTA  4 Q                 HTML            00022090 0002216F 000000E0 (        224.) OCTA  4 Q                 HTTP            00022170 000221B3 00000044 (         68.) OCTA  4dQ                 INIT            000221C0 000224E7 00000328 (        808.) OCTA  4  i PL_DISK:[JAKOBUS.WGET-1_5_3G.SRC.ALPHA]WGET.EXE;3               13-DEC-2001 14:58        Linker A12-03                    Page    30    k Psect Name      Module Name       Base     End           Length            Align                 Attributes3k ----------      -----------       ----     ---           ------            -----                 ----------C $DATA$                          00020000 000229BF 000029C0 (      10688.) OCTA  4 NOPIC,CON,REL,LCL,NOSHR,NOEXE,  WRT,NOVEC,  MOD   Q                 MAIN            000224F0 0002290F 00000420 (       1056.) OCTA  4rQ                 RECUR           00022910 00022917 00000008 (          8.) OCTA  4 Q                 URL             00022920 000229B3 00000094 (        148.) OCTA  4  OPTARG                          000229C0 000229C3 00000004 (          4.) OCTA  4 NOPIC,OVR,REL,GBL,NOSHR,NOEXE,  WRT,NOVEC,  MOD Q                 GETOPT          000229C0 000229C3 00000004 (          4.) OCTA  4  OPTERR                          000229D0 000229D3 00000004 (          4.) OCTA  4 NOPIC,OVR,REL,GBL,NOSHR,NOEXE,  WRT,NOVEC,  MOD Q                 GETOPT          000229D0 000229D3 00000004 (          4.) OCTA  4  OPTIND                          000229E0 000229E3 00000004 (          4.) OCTA  4 NOPIC,OVR,REL,GBL,NOSHR,NOEXE,  WRT,NOVEC,  MOD Q                 GETOPT          000229E0 000229E3 00000004 (          4.) OCTA  4  OPTOPT                          000229F0 000229F3 00000004 (          4.) OCTA  4 NOPIC,OVR,REL,GBL,NOSHR,NOEXE,  WRT,NOVEC,  MOD Q                 GETOPT          000229F0 000229F3 00000004 (          4.) OCTA  4r VERSION_STRING                  00022A00 00022A03 00000004 (          4.) OCTA  4 NOPIC,OVR,REL,GBL,NOSHR,NOEXE,  WRT,NOVEC,  MOD Q                 VERSION         00022A00 00022A03 00000004 (          4.) OCTA  4u $CODE$                          00030000 000504D3 000204D4 (     132308.) OCTA  4   PIC,CON,REL,LCL,  SHR,  EXE,NOWRT,NOVEC,  MOD Q                 CONNECT         00030000 00030983 00000984 (       2436.) OCTA  4OQ                 FNMATCH         00030990 00031147 000007B8 (       1976.) OCTA  4nQ                 FTP-BASIC       00031150 000326CB 0000157C (       5500.) OCTA  4aQ                 FTP-LS          000326D0 00033E23 00001754 (       5972.) OCTA  4 Q                 FTP-OPIE        00033E30 00034567 00000738 (       1848.) OCTA  4lQ                 FTP             00034570 000383E3 00003E74 (      15988.) OCTA  4 Q                 GETOPT          000383F0 00039133 00000D44 (       3396.) OCTA  40Q                 HEADERS         00039140 000396D3 00000594 (       1428.) OCTA  4eQ                 HOST            000396E0 0003AA43 00001364 (       4964.) OCTA  4iQ                 HTML            0003AA50 0003C483 00001A34 (       6708.) OCTA  4CQ                 HTTP            0003C490 00040167 00003CD8 (      15576.) OCTA  4MQ                 INIT            00040170 0004205B 00001EEC (       7916.) OCTA  4EQ                 LOG             00042060 000428B3 00000854 (       2132.) OCTA  44Q                 MAIN            000428C0 00043E53 00001594 (       5524.) OCTA  4 Q                 MD5             00043E60 00044FE7 00001188 (       4488.) OCTA  4VQ                 NETRC           00044FF0 000459C3 000009D4 (       2516.) OCTA  4yQ                 RBUF            000459D0 00045B73 000001A4 (        420.) OCTA  4-Q                 RECUR           00045B80 00047933 00001DB4 (       7604.) OCTA  4-Q                 RETR            00047940 00048C43 00001304 (       4868.) OCTA  4iQ                 URL             00048C50 0004DB63 00004F14 (      20244.) OCTA  4 Q                 UTILS           0004DB70 000500AB 0000253C (       9532.) OCTA  4-Q                 VMS             000500B0 000504D3 00000424 (       1060.) OCTA  4b $BSS$                           00060000 00062307 00002308 (       8968.) OCTA  4 NOPIC,CON,REL,LCL,NOSHR,NOEXE,  WRT,NOVEC,NOMOD Q                 CONNECT         00060000 0006001F 00000020 (         32.) OCTA  4 Q                 FTP-BASIC       00060020 00060037 00000018 (         24.) OCTA  4nQ                 FTP-OPIE        00060040 00060067 00000028 (         40.) OCTA  4<Q                 GETOPT          00060070 0006007F 00000010 (         16.) OCTA  4wQ                 HOST            00060080 00060087 00000008 (          8.) OCTA  4 Q                 HTML            00060090 000600A7 00000018 (         24.) OCTA  4 Q                 LOG             000600B0 000600BF 00000010 (         16.) OCTA  4 Q                 NETRC           000600C0 000600C3 00000004 (          4.) OCTA  4sQ                 RECUR           000600D0 000600E7 00000018 (         24.) OCTA  4 Q                 RETR            000600F0 00062157 00002068 (       8296.) OCTA  4hQ                 UTILS           00062160 00062187 00000028 (         40.) OCTA  4rQ                 VMS             00062190 00062307 00000178 (        376.) OCTA  4W EXEC_NAME                       00062310 00062313 00000004 (          4.) OCTA  4 NOPIC,OVR,REL,GBL,NOSHR,NOEXE,  WRT,NOVEC,NOMOD Q                 MAIN            00062310 00062313 00000004 (          4.) OCTA  4    PL_DISK:[JAKOBUS.WGET-1_5_3G.SRC.ALPHA]WGET.EXE;3               13-DEC-2001 14:58        Linker A12-03                    Page    4     k Psect Name      Module Name       Base     End           Length            Align                 Attributes k ----------      -----------       ----     ---           ------            -----                 ----------  FTP_LAST_RESPLINE               00062320 0006239F 00000080 (        128.) OCTA  4 NOPIC,OVR,REL,GBL,NOSHR,NOEXE,  WRT,NOVEC,NOMOD Q                 FTP-BASIC       00062320 0006239F 00000080 (        128.) OCTA  4  NETRC_LIST                      000623A0 000623A3 00000004 (          4.) OCTA  4 NOPIC,OVR,REL,GBL,NOSHR,NOEXE,  WRT,NOVEC,NOMOD Q                 NETRC           000623A0 000623A3 00000004 (          4.) OCTA  4n OPT                             000623B0 000624BF 00000110 (        272.) OCTA  4 NOPIC,OVR,REL,GBL,NOSHR,NOEXE,  WRT,NOVEC,NOMOD Q                 MAIN            000623B0 000624BF 00000110 (        272.) OCTA  4  SAVE_LOG_P                      000624C0 000624C3 00000004 (          4.) OCTA  4 NOPIC,OVR,REL,GBL,NOSHR,NOEXE,  WRT,NOVEC,NOMOD Q                 LOG             000624C0 000624C3 00000004 (          4.) OCTA  4- VMS_PATH                        000624D0 000625CF 00000100 (        256.) OCTA  4 NOPIC,OVR,REL,GBL,NOSHR,NOEXE,  WRT,NOVEC,NOMOD Q                 VMS             000624D0 000625CF 00000100 (        256.) OCTA  4-  C                                                 +-----------------+ C                                                 ! Symbols By Name !CC                                                 +-----------------+    Symbol                          Value       Symbol                          Value       Symbol                          Value        ------                          -----       ------                          -----       ------                          -----        ACCDIR                          00014870-R                                              FTP_LOOP                        000110D0-R   ACCEPTABLE                      000148B8-R                                              FTP_PARSE_LS                    00010890-R   ACCEPTPORT                      00010190-R                                              FTP_PASV                        000104E8-R   ACCEPT_DOMAIN                   00011580-R                                              FTP_PORT                        00010510-R   ADD_SLIST                       000146F0-R                                              FTP_RESPONSE                    000102C0-R   ADD_URL                         00013D90-R                                              FTP_REST                        00010458-R   BINDPORT                        000101C0-R                                              FTP_RETR                        00010430-R   CALCULATE_SKEY_RESPONSE         000108E8-R                                              FTP_TYPE                        000104C0-R   CLEANUP                         000122E8-R                                              GETOPT                          00011230-R   CLEAN_HOSTS                     000113D0-R                                              GETOPT_LONG                     00011250-R   CLOSEPORT                       00010150-R                                              GETPROXY                        00013F30-R   CONADDR                         00010110-R                                              GET_CONTENTS                    000139B8-R   CONTAINS_UNSAFE                 00013FC0-R                                              GET_URLS_FILE                   00014340-R   CONVERT_ALL_LINKS               000134B0-R                                              GET_URLS_HTML                   000142B0-R   CONVERT_LINKS                   00013E48-R                                              HAS_WILDCARDS_P                 00010268-R   DECC$UTIME                      00014C30-R                                              HEADER_EXTRACT_NUMBER           00011310-R   ELAPSED_TIME                    00013CE0-R                                              HEADER_GET                      00011270-R   ENCODE_STRING                   00013F90-R                                              HEADER_PROCESS                  00011350-R   EXEC_NAME                       00062310-R                                              HEADER_STRDUP                   000112E0-R   FILE_EXISTS_P                   000148D8-R                                              HERRMSG                         00011408-R   FILE_NON_DIRECTORY_P            00014988-R                                              HTMLFINDURL                     000119F8-R   FNMATCH                         00010230-R                                              HTML_BASE                       000119A0-R   FORK_TO_BACKGROUND              00014A50-R                                              HTTP_LOOP                       00012130-R   FREEURL                         00014370-R                                              INITIALIZE                      000127B0-R   FREE_NETRC                      00013380-R                                              IN_SLIST                        00014640-R   FREE_SLIST                      00014608-R                                              IREAD                           000100D8-R   FREE_URLPOS                     00014218-R                                              IWRITE                          000100A0-R   FREE_VEC                        00014778-R                                              LEGIBLE                         000145B8-R   FRONTCMP                        00014820-R                                              LOAD_FILE                       00014798-R   FTP_CWD                         00010498-R                                              LOGFLUSH                        00012AB0-R   FTP_GETADDRESS                  000114A8-R                                              LOGPRINTF                       00012A30-R   FTP_INDEX                       00011848-R                                              LOGPUTS                         00012830-R   FTP_LAST_RESPLINE               00062320-R                                              LOG_CLOSE                       00012990-R   FTP_LIST                        000103D8-R                                              LOG_INIT                        000129C0-R   FTP_LOGIN                       00010570-R                                              LONG_TO_STRING                  00014590-R     PL_DISK:[JAKOBUS.WGET-1_5_3G.SRC.ALPHA]WGET.EXE;3               13-DEC-2001 14:58        Linker A12-03                    Page    5,     Symbol                          Value       Symbol                          Value       Symbol                          Value        ------                          -----       ------                          -----       ------                          -----        MAIN                            00012D70-R                                              SKIP_UNAME                      00014440-R   MAKE_CONNECTION                 00010000-R                                              SKIP_URL                        00013D30-R   MAKE_DIRECTORY                  00014910-R                                              STORE_HOSTADDRESS               000116F0-R   MD5_FINISH_CTX                  00013178-R                                              STRDUPDELIM                     00014B20-R   MD5_INIT_CTX                    00013110-R                                              STR_URL                         00013FE0-R   MD5_PROCESS_BLOCK               00013120-R                                              SUFFIX                          00014800-R   MD5_PROCESS_BYTES               00013140-R                                              SUFMATCH                        00011550-R   MD5_READ_CTX                    00013168-R                                              TIME_STR                        00014AD0-R   MERGE_VECS                      00014750-R                                              TOUCH                           000149D0-R   MKALLDIRS                       00014150-R                                              UERRMSG                         00014AA0-R   NETRC_LIST                      000623A0-R                                              UNIQUE_NAME                     00014950-R   NEWURL                          000144D0-R                                              URLPROTO                        00014510-R   NGETHOSTBYNAME                  00011380-R                                              URL_EQUAL                       000144F0-R   NO_PROXY_MATCH                  00013F00-R                                              URL_FILENAME                    000140E0-R   NUMDIGIT                        000145A8-R                                              VERSION_STRING                  00022A00-R   OPT                             000623B0-R                                              VMS_PATH                        000624D0-R   OPTARG                          000229C0-R                                              XMALLOC                         000146B0-R   OPTERR                          000229D0-R                                              XREALLOC                        00014710-R   OPTIND                          000229E0-R                                              XSTRDUP                         00014670-R   OPTOPT                          000229F0-R                                              _GETOPT_INTERNAL                000111B8-R   OPT_URL                         00014030-R                                              __MAIN                          00013050-R  X PARSEURL                        00014450-R                                              X PARSE_LINE                      000126E8-R                                              X PATH_SIMPLIFY                   00014A30-R                                              X PRINTWHAT                       00013A20-R                                              X PWD_CUSERID                     00014A60-R                                              X RATE                            00013C70-R                                              X RBUF_DISCARD                    000133B0-R                                              X RBUF_FLUSH                      000133C0-R                                              X RBUF_INITIALIZE                 000133A0-R                                              X RBUF_INITIALIZED_P              00013430-R                                              X RBUF_PEEK                       000133E8-R                                              X RBUF_UNINITIALIZE               00013420-R                                              X READ_WHOLE_LINE                 000147D0-R                                              X REALHOST                        00011660-R                                              X RECURSIVE_CLEANUP               00013440-R                                              X RECURSIVE_RESET                 000138E0-R                                              X RECURSIVE_RETRIEVE              000137E0-R                                              X REDIRECT_OUTPUT                 000128C8-R                                              X REMOVE_LINK                     000149C0-R                                              X RESET_TIMER                     00013D10-R                                              X RETRIEVE_FROM_FILE              00013BF0-R                                              X RETRIEVE_URL                    00013AF0-R                                              X ROTATE_BACKUPS                  000141C0-R                                              X SAME_HOST                       00011690-R                                              X SAVE_LOG_P                      000624C0-R                                              X SEARCH_NETRC                    00013320-R                                              X SEPSTRING                       00014B40-R                                              X SETVAL                          000126C8-R                                              X SET_VMS_NAME                    00014B80-R                                              X SKIP_LWS                        000112D0-R                                              X SKIP_PROTO                      00014400-R                                                 PL_DISK:[JAKOBUS.WGET-1_5_3G.SRC.ALPHA]WGET.EXE;3               13-DEC-2001 14:58        Linker A12-03                    Page    6      Symbol                          Value       Symbol                          Value       Symbol                          Value        ------                          -----       ------                          -----       ------                          -----               $ 	  Key for special characters above: 		+--------------------+ 		! *  - Undefined     ! 		! A  - Alias Name    ! 		! I  - Internal Name ! 		! U  - Universal     ! 		! R  - Relocatable   ! 		! X  - External      ! 		! WK - Weak          ! 		+--------------------+ 7 PL_DISK:[JAKOBUS.WGET-1_5_3G.SRC.ALPHA]WGET.EXE;3               13-DEC-2001 14:58        Linker A12-03                    Page    7S  C                                                  +----------------+ C                                                  ! Image Synopsis ! C                                                  +----------------+   h Virtual memory allocated:                         00010000 0007FFFF 00070000 (458752. bytes, 896. pages)A Stack size:                                             20. pages U Image header virtual block limits:                       1.        2. (    2. blocks)AU Image binary virtual block limits:                       3.      354. (  352. blocks)C; Image name and identification:                    WGET V1.0(; Number of files:                                        32.1; Number of modules:                                      29. ; Number of program sections:                             24.A; Number of global symbols:                             3570.5; Number of image sections:                               34.0: User transfer address:                            00013050: Debugger transfer address:                        00000340; Number of code references to shareable images:         108.7= Image type:                                       EXECUTABLE. s Map format:                                       DEFAULT in file PL_DISK:[JAKOBUS.WGET-1_5_3G.SRC.ALPHA]WGET.MAP;1 = Estimated map length:                             261. blocks0E                                               +---------------------+ E                                               ! Link Run Statistics !ME                                               +---------------------+   S Performance Indicators                            Page Faults	CPU Time	Elapsed TimeES ----------------------                            -----------	--------	------------1U     Command processing:                                    54	00:00:00.07	00:00:00.070U     Pass 1:                                                93	00:00:00.12	00:00:00.130U     Allocation/Relocation:                                  6	00:00:00.00	00:00:00.10(U     Pass 2:                                                36	00:00:00.12	00:00:00.79 U     Map data after object module synopsis:                  4	00:00:00.01	00:00:00.03 U     Symbol table output:                                    0	00:00:00.01	00:00:00.04.U Total run values:                                         193	00:00:00.33	00:00:01.18C  [ Using a working set limited to 10000 pages and 2920 pages of data storage (excluding image)   6 Total number object records read (both passes):   2197W     of which 0 were in libraries and 565 were DEBUG data records containing 72966 bytes S 49058 bytes of DEBUG data were written,starting at VBN 355 with 96 blocks allocated7  6 Number of modules extracted explicitly             = 01     with 0 extracted to resolve undefined symbols,  ? 9 library searches were for symbols not in the library searched   4 A total of 0 global symbol table records was written  0 LINK/TRACE/MAP/EXEC=WGET.EXE [-]wget.opt/OPTIONS  ( --------------070005000504050405060708--   ------------------------------  # Date: Thu, 13 Dec 2001 17:12:44 GMTE2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)' Subject: Re: DECC$TIME multiply definedN2 Message-ID: <gk5S7.553$BK1.14958@news.cpqcorp.net>  X In article <3C185C64.6010003@iaf.fhg.de>, Theo Jakobus <Theo.Jakobus@iaf.fhg.de> writes:4 :I started to build GNU WGET and got a LINK warning: ..3 :%LINK-W-MULDEF, symbol DECC$UTIME multiply defined C :         in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1  ..3 :I'm using: Compaq C V6.4-008 on OpenVMS Alpha V7.3   B   And the compiler believes your code is defining a "time" symbol.C   Either don't do that (usually best), or use the /PREFIX "except"  @   mechanism to resolve the time symbol against the local symbol.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Thu, 13 Dec 2001 17:15:46 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)E Subject: Re: Ethernet Hardware Address (was: Re: help [[  MCR NCP ]]) 2 Message-ID: <6n5S7.554$BK1.15156@news.cpqcorp.net>  K In article <9v9puo$2mi$1@news.nuri.net>, "ȼ" <syahn@icols.com> writes:    :I hope to giga's MAC Address.    H   The OpenVMS Frequently Asked Questions (FAQ) section entitled "How to E   determine the network hardware address?" might be of interest here.   H   And so that you can get the best chance of getting a fast answer, you B   will want to pick a title specifically relevent to the question.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Thu, 13 Dec 2001 15:03:04 +0900   From: "ȼ" <syahn@icols.com> Subject: help [[  MCR NCP ]]( Message-ID: <9v9puo$2mi$1@news.nuri.net>   We have ES40 System.0 The ES40 System have 2-giga bit Ethernet Module.   I hope to giga's MAC Address.  HOW ?? HELP MEL     I have seen Only EWA-0 .   NCP> show known line char    EWA-0    ------------------------------   Date: 13 Dec 2001 09:28:30 GMT) From: leslie@clio.rice.edu (Jerry Leslie)L  Subject: Re: help [[  MCR NCP ]]' Message-ID: <9v9sbu$qqd$1@joe.rice.edu>    ȼ (syahn@icols.com) wrote:1G : We have ES40 System. The ES40 System have 2-giga bit Ethernet Module.  :  : I hope to giga's MAC Address.  : HOW ??	 : HELP ME  :  : I have seen Only EWA-0 . :  : NCP> show known line char  :  : EWA-0  : 7 Is DECNet Phase IV installed, configured, and started ?R  A The output of the "show network/full" command should look similar 8 to this if the answer to those three questions is "Yes":     $ show network/full   <   The following network services are available at this time:  N   Product:  DECNET                Manufacturer:  Digital Equipment Corporation6   Node:  SCCVXG                   Address(es):  58.6316   Network Type:  DNA IV           Interface(s):  net 0     --Jerry Leslie     ------------------------------  % Date: Thu, 13 Dec 2001 15:03:04 +0900L  From: "ȼ" <syahn@icols.com> Subject: help [[  MCR NCP ]]( Message-ID: <9v9gas$g70$1@news.nuri.net>   We have ES40 System.0 The ES40 System have 2-giga bit Ethernet Module.   I hope to giga's MAC Address.  HOW ?? HELP ME      I have seen Only EWA-0 .   NCP> show known line char0   EWA-0    ------------------------------  # Date: Thu, 13 Dec 2001 12:19:35 GMT ' From: "Hans Vlems" <hvlems@zfree.co.nz>   Subject: Re: help [[  MCR NCP ]]$ Message-ID: <3c189cd4$1@zfree.co.nz>  & Either you have phase IV and then try:   $ mc ncp sho known line char  ! Or you have phase V and then try:   " $ mc ncl sho csma-cd station * all  D But I have been told that it is possible that the ES40 only runs IP,! in which case you could try this:0   $ tcpip show interface /full  H provided that you run Compaq's flavor of IP. Other vendors use different4 commands. BTW older versions of TCPIP are called UCX7 so the command would then be $ UCX show interface /full A In case that command returns a MAC address like AA-00-04-00-xx-xxl then you do run DECnet.   % There is another way, if you run LAT:    $ mc latcp sho link/full   Hans  ! "ȼ" <syahn@icols.com> wrote:  >We have ES40 System. 1 >The ES40 System have 2-giga bit Ethernet Module.- >- >I hope to giga's MAC Address. >HOW ??  >HELP ME >f >s >I have seen Only EWA-0 .	 >- >NCP> show known line char >d >EWA-0 >! >	 >  >A       http://www.zfree.co.nz   ------------------------------  % Date: Thu, 13 Dec 2001 13:46:52 +0100t* From: "peter flunger /news" <p-i-b@gmx.at>  Subject: Re: help [[  MCR NCP ]]0 Message-ID: <9va7ro$98j$1@newsreader1.netway.at>  " "ȼ" <syahn@icols.com> schrieb1 im Newsbeitrag news:9v9puo$2mi$1@news.nuri.net...  > We have ES40 System.2 > The ES40 System have 2-giga bit Ethernet Module. >  > I hope to giga's MAC Address.e > HOW ??	 > HELP ME  >  >  > I have seen Only EWA-0 . >  > NCP> show known line chara >e > EWA-0c >d >  > : If you have neither of the mentioned protocols running and' the way to do this would be using LANCP  $ mc LANCP sho dev/char  Hope that helps, Peterr   ------------------------------    Date: 13 Dec 2001 10:17:46 -0600+ From: young_r@encompasserve.org (Rob Young) + Subject: Re: HP Foundations - let them knowC3 Message-ID: <a8YEwIjjlBT2@eisner.encompasserve.org>G  [ In article <3C18381E.29876608@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:  > Rob Young wrote:	 >> [snip] I >>         Don't be too alarmed by "sightings" on a Dead chip... it meanso >>         nothing.  > H > Did I miss something, or were these "sightings" not on the current IPF4 > porting platforms in the possession of OVMS Engr.? >     9 	Yes.  But you can pretty much guess it is pretty arcane. 9 	After all, IBM, Dell and HP were/are shipping boxes with:9 	Itania in it.  My guess is some sort of FDIV like glitch 9 	that shows up once in a Blue Moon.  Certainly nothing to 9 	slow up a porting effort, *BUT* definitely something youA> 	wouldn't want to have long running scientific codes depending, 	on multiple decimal placements of accuracy.    F >> >> We have turned a declining business around, and continue to make >> >> forward progress.S >> >M >> > You have? Evidence please? (Hint: Compaq's stock price is still in tank, 4 >> > though it is near the pre-announcement levels.) >> > >> PI >>         He didn't say Compaq.  He said "a declining business", judging-I >>         from the context that wouldn't be too difficult to take a wild . >>         guess that he was referring to VMS. > = > Did I miss something else? Is VMS no longer part of Compaq?1 >  0  
 	One part.  > >> >> We have a plan to get to a new architecture base for the
 >> >> future.( >> >K >> > Is this more Intel vapor-ware or is it a currently shippable, saleable0
 >> > product?a >> > >> jK >>         Future plans imply products that may not exist, hope that helps.t > I > Kinda dumb to "have a plan" while discarding the current product beforeaB > its replacement goes gamma test (a.k.a. "general availability"). >  0  # 	Okay , zig this way, zag that way.    >> >>pP >> >> Not quite sure I agree with this for OpenVMS.  We still have strong demandQ >> >> for OpenVMS Alpha.  Along with committments from large customers, ISV's and # >> >> partners for Itanium support.  >> >K >> > I'm sure you're aware that the word "commitment" is about as valueless74 >> > as used toilet paper where Compaq is concerned. >> > >> iC >>         Overlooking his statement that "[they] still have strongr& >>         demand for OpenVMS Alpha".  > J > "They" do. How 'bout the other OEMs/VARs? Dunno 'bout where you are, but9 > here in Chi they're in as bad (or worse) shape as I am.  >   ? 	I don't believe Fred mentioned geography or segment.  However, @ 	he did say "strong demand for OpenVMS Alpha", let's kick around- 	the truth or validity of that statement, ok?-   >> Why not FUD that up?  > I > Show me the FUD. I'm talking reality here ... or do you need to go with  > Fred to the river in Egypt?  >    	No.   >> Is he bluffing? > ' > Dunno. Haven't seen the evidence yet.  >    	You won't.T  & >>         Just rose colored glasses?  >  > So it would seem.E >  >> No, let's focus on the wordL >>         "committment" as their "committments" from customers are suspect?- >>         These aren't backed by contracts?   > F > What the hell good is a contract? Do you believe for one minute thatE > someone intent on weaseling out of a contract will hesitate for one,J > moment to do so? Sorry, Pollyanna, but there are *NO* guarantees in this > life, contract or no.  >   D 	The judgements in cases of breach of contract are easy to find and H 	frequent.  So what makes you think "someone intent on weaseling out of : 	a contract" can do so without severe financial penalty?       >> How would you know? >  > Who gives a shit?  >  65 >> >> Why are you soooo sure that Itanium will not be,
 >> >> viable?O >> >J >> > Who ever said it won't be? The point is it currently is *NOT* viable.< >> > Whether or not it ever will be is entirely up to Intel. >> > >>  , >>         It will be.  Give it enough time. > 6 > Are you willing to bet your life (business) on that? >   > 	I certainly wouldn't be planning a migration for 2002 or 2003G 	even.  Let the early adopters receive the big discounts and publicity.    > / > How much time is enough? How late is IPF now?- >    	Late...  G >> >>  I remember a lot of people saying how the x86 was just a toy and R >> >> would never be competetive.  Intel can throw a lot of money and pretty smart >> >> people at a problem. >> >1 >> > Then, they'd better shit or get off the pot.  >> > >>  6 >>         They have only started to spend the money.  > J > Spending money is one thing. Actually accomplishing something is another > matter entirely. >   E 	The point is of course is they have much more money than most.  They 0 	can hire the best and continue to rollout IPFs.   >> If they can garner P >>         95% of server CPU sales, they would probably be successful.  I figureI >>         they probably have a pretty high percentage now with X86, IA64   >>         is icing on the cake. > 5 > What does that have to do with bugs in the IPF CPU?D >   " 	Merced.  Remember IA64 != Merced.   >> >> >> On the other hand, I N >> >> >> continue to see the internal large "wins" messages for new VMS sales,
 >> >> thatL >> >> >> would seem to counter that (and no, we do not make such wins public
 >> >> without ( >> >> >> the customer wishing it to be). >> >> > O >> >> >How 'bout seeing if you can at least get permission to say publicly, "on M >> >> >xx-xxx-xxxx, we sold a total of $nn,nnn,nnn worth of (Alpha, StgWorks, E >> >> >etc.) to y customer(s)"? ("n" and "y" are integers, of course)  >> >> >  >> >> R >> >> You are talking to the wrong guppy.  I do not, and never want, permission to >> >> release such information.  >> >D >> > Then who should be "the one"? (Welcome to the real world, Neo!) >> > >> DJ >>         You can't expect that.  Some of their large wins are governmentM >>         and military... don't expect anyone to be bragging those up.  Just  >>         the way it works. > J > Go back and re-read my original response. Show me where it says anythingG > about identifying customers or markets. All I want to see is how many F > dollars worth of stuff was sold. Hardly anything that could threaten > U.S. security. >   = 	But you can't expect that from anyone or a breakout of that.  	It would help the competition.C  Q >> >> >> I have every reason to believe that OpenVMS will emerge from this in theE? >> >> >> best shape and position that it has been in for years.  >> >> > N >> >> >Do you also have inside info. from Intel as to when they'll FINALLY(!!)M >> >> >have a viable, saleable IA64/IPF CPU for building into OpenVMS-capable  >> >> >systems?  >> >> >  >> >>R0 >> >> I believe that even at todays performance, >> >J >> > Performance is not the issue - accuracy and error-free processing are >> > the issue.  >> > >> 0I >>         Yep.  Give them one more go round and they will have it right.  > D > ...or maybe one more   ...or maybe one more   ...or maybe one more > E >>         You can bet the verification runs on McKinley will be more  >>         thorough.   > # > I should fucking well hope so !!!  >  >> They have Merced as a guide.  >  > God help us! >  >> >H >> > o Current VMS customers see this, and wonder where they can go fromM >> > OpenVMS-Alpha in the short to mid term. Now, remember, the confused mind F >> > always says, "No". Will they stay with VMS? Can they trust Compaq >> > "commitments"?  >> > >>  E >>         Come on... it is hard enough to peal those well performingCF >>         Vaxes from some folks fingers.  We are mostly crunching I/OJ >>         out here... several spins on EV7 will carry most business needsM >>         except for explosive growth.  Maybe you envision clusters grinding 9 >>         to a halt and no Alphas to be found anywhere?   > > > Envision? Hardly! Witness? More times than I care to recall. >  >> When is that?  2008 >>         or 2009?  > E > Try 1998, 1999, 2000, 2001. Every reason to believe defections willE > accelerate in Q1CY2002.  >   > 	You are mixing things up on purpose.  Clusters running out of@ 	horsepower and NOT being able to upgrade or add systems is whatD 	I am talking about.  You are referring to migrations away from VMS.  , >> Why haven't you begun your IPF migration? >  > No viable IPF CPUs yet.T > & 	Nice.  AH would be proud...  I wrote:   When is that?  2008 or 2009?  ) Why haven't you begun your IPF migration?1  A 	As in... if you are still on Alpha in 2008 or 2009, that is your F 	problem.  You should have been planning a migration long before then.   >> > >> > Ask yourself:H >> > o Would *YOU* put *YOUR* stockholder's "eggs" in Compaq's "basket",  >> > knowing what we know today? >> > >>  5 >>         Sure... if they are still around in 2008.   >   > So, whaddaya gonna do in 2002? >   ? 	Same thing.  Whatever is purchased next year will run for many  	years.    >> I don't care who  >>         owns VMS. > I > By 2008, I likely won't care if VMS is still around as I plan to be outE > of EDP by then.  >  D   	Okay.  L >> > o Is it reasonable to expect other business leaders to think as you do? >>  ( >>         Yes.  Solutions is solutions. > I > Are you saying that quality doesn't matter? What about appropriateness?   > Security? Stability? Get real. >   > 	That is a subset of a Solution.  You aren't delivering a goodG 	solution if you don't take into account the things you just mentioned.    >> >E >> > If you still put any stock in Compaq's "commitments", you shouldE2 >> > seriously consider having yourself committed. >> > >>  @ >>         No.  He probably knows a few more things than we do.  > A > Dunno 'bout you, I can't work based on what someone else knows, I > especially if they keep it a secret. I can only go by my own experienceX > and decisions. >   * 	Oh... I might know a thing or two too...    >> Like signedH >>         longterm contracts to very large customers that are binding.  > 6 > Are you willing to bet your life (business) on that? >   = 	That's all you have is contracts.  The company you have them1> 	with could go chapter 13 and they wouldn't be worth the paper= 	they are written on.  I guess you are after warm fuzzies AND * 	binding contracts?  Or just warm fuzzies?  	 >> Things , >>         the owner(s) of VMS will inherit. > J > ...and quickly find a way to weasel out of. Been there, done that - haveC > the coffee mug, the T-shirt, the denim jacket, the briefcase, the  > umbrella, ...y >  c  > 	Not at all.  They are called binding contracts, very few waysA 	out, short of dissolving the business and at that your creditors0A 	can divvy your assests among themselves.  Judgment in your favorh? 	would legally entitle you to a slice of the assets even in the  	case of a failed business.D  P >> >> Here we are months later and what I see is that we have hired engineers to >> >> help with the port,i >> >G >> > What happens to them afterward? (Can you say "job security"? No, I  >> > didn't think you would.): >> > >> KA >>         Talk to Keith Parris... or look at his resume online.   > I > I notice he's no longer with OVMS Engr. Great guy. Bad example for your- > case, however. >   A 	No.  My point was he only spent a few years working the port andmB 	went on to other things.  A good example.  You misinterpreted it.   >> >> (Fred wrote:) [snip]0 >> >> So where in this should I fit "pessimism"? >> >J >> > Ask that question again the next time an IPF deadline at Intel slips.L >> > Ask that question again when the postings appear here about VMS systemsI >> > being replaced due to uncertainty about the future of IPF, and other-L >> > factors. Ask that question again the next time there are "sightings" of >> > anomalies in IPF. >> > >>  N >>         Who cares about the deadline?  They have several THOUSAND engineers >>         working on IPF. > I > I would hope that the bosses of those "several THOUSAND engineers" careB= > very strongly about deadlines, or they should all be fired!i >   6 	Course.  But the point here is the scale.. see below.  ; >>         They have design teams on IPF stacked 5-8 deep. A > ! > ...and that means exactly what?n >   @ 	5 to 8 IPFs in the design phase.  You would be naive to believe7 	they don't ship OR are technical failures like Merced.r   >> Future ofC >>         IPF?  Come on... you can generate better FUD than that. - > J > Again, not "FUD" - reality. Get off that river in Egypt and come back to > the real world, Neo! >  >> "Sightings"? ( >>         Come on... weak... very weak. > ? > Based on the reaction of the financial markets to the news ofH@ > "sightings", your observation seems to run counter to reality. >  m  2 	And what does this mean, and where is the tie-in?    K >> > IPF is a question of when, not if. We know this. We also know that IPFCJ >> > is - and remains - vaporware. It currently is not a viable, shippableI >> > product where OpenVMS-level quality is required, expected, demanded.s >> >6 >> > Regardless of Bill's issue, *THAT* is *MY* issue. >> > >> eL >>         Well the on-chip availability features (not quite fault tolerant)G >>         will make it a reliable chip.  Those sightings will go away.  > E > When? ...and "Are you willing to bet your life (business) on that?". >  w  I 	Absolutely.  Win64 will run on it and Microsoft is spending considerableeA 	resources.  There are a large number of Intel customers that are > 	designing for and using IPF processors.  Your mantra is weak.  ; >> >> And the way we convince both customers and managementtL >> >> that VMS is viable is to tell them what we'll do, and execute to plan. >> >5 >> > There's that whole COMMITMENT thing again! SHIT!  >> > >> tD >>         Yeah... probably on the smart customer end backed up withN >>         signed contracts that their legal department spent months crafting. > F > ...and Compaq's lawyers spent minutes striking out, or hours, weeks,H > months, maybe even years making sure that their exculpatory and escapeE > clauses wre not weakened or made effective by customer "craftings".m >   @ 	Yeah, right.  And multi-billion dollar government, military and; 	business organizations are idiots because they can't craft0@ 	legally binding contracts?   Give me a break.  Weak, very weak.   >> >>  Make?# >> >> money, and grow the business.0 >> >M >> > ...which is not done by shooting yourself in the foot until it ends just J >> > below your shoulder. I think the Q are down to just a couple of hairs- >> > left at this point, or is that a toupee?1 >> > >> eK >>         But if currently they are making money and growing the business,  >  > Are they? Evidence please? >    	See Fred.  :-)o  + >>         then you have to give them that.t >  > Show me the money! >   @ 	Have them show you the money... won't happen.  Guess they don't 	answer to you either, eh?   				Robu   ------------------------------  % Date: Thu, 13 Dec 2001 09:54:40 +0100e( From: Paul Sture <paul.sture@bluewin.ch>" Subject: Re: Info-VAX@Mvb.Saic.Com- Message-ID: <VA.000004e8.f1ba4d8f@bluewin.ch>a  D In article <98rb1us8gt477u4hgsajieeehqbdqhg1ld@4ax.com>, Alan Greig  wrote:H > On Tue, 11 Dec 2001 08:02:59 +0100, Paul Sture <paul.sture@bluewin.ch> > wrote: > H > >In article <5jgR7.28855$wL4.88207@rwcrnsc51>, Ken and Kelley Coleman 	 > >wrote: C > >> Well, we voted and it turned out that you ARE the weakest Linke > >>   > >> Good bye! > >> w6 > >> (just kidding, of course...I haven't a clue why.) > >> zE > >Which gets my vote for the sh*ttiest message I've seen here for a 1 > >while. Totally uncalled for.g > B > Ah come one they did add "just kidding". Not sure if you get theE > reference to "The Weakest Link" - a BBC show with Anne Robinson nowi@ > picked up by NBC in the States - still with Anne Robinson. TheG > reference to the show again indicates the comment is tongue in cheek. # > http://www.bbc.co.uk/weakestlink/?" > http://www.nbc.com/Weakest_Link/ >   > Do you have it in Switzerland?   Yes. Don't like it.  ___ 
 Paul Sture Switzerland    ------------------------------  % Date: Thu, 13 Dec 2001 09:54:40 +0100A( From: Paul Sture <paul.sture@bluewin.ch>" Subject: Re: Info-VAX@Mvb.Saic.Com- Message-ID: <VA.000004e9.f1ba4d99@bluewin.ch>0  F In article <hcBR7.36079$ER5.422102@rwcrnsc52>, Ken and Kelley Coleman  wrote:K > I apologize, Mr. Sture. I really meant no harm at all by it. Bad Americane) > humor on my part. Have a wonderful day.h > J Apology accepted. Had your reply been addressed to someone from the UK or F US I wouldn't have reacted that way, but it was a .nl address. Please 5 remember that we have an international audience here.h   ___g
 Paul Sture Switzerlandt   ------------------------------    Date: 13 Dec 2001 10:27:38 +0100G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>,' Subject: Re: Inquirer: OpenVMS on DS20L:H Message-ID: <y4snafo4fp.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  7 "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:p  J > Sheeesh.  Would you be happy if it was called "Bob"?  Someone in productN > management just gave it what seemed to be a reasonable name.  BTW this thingC > isn't even shipping, and UNIX is still working on support for it.   N Technically true. But business is 90% psychology, 9% sweat, and 1% technology.F Ignore your buyer's psychology at your peril. What was that name, ara?   	Jan   ------------------------------  + Date: Thu, 13 Dec 2001 12:04:33 +0100 (MET)n9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>e' Subject: Re: Inquirer: OpenVMS on DS20L ; Message-ID: <01KBTHI7JCNA9138XQ@sysdev.deutsche-boerse.com>i  I > > The biggest problem VMS faces right now (IMHO) is the availability ofvP > > low-cost development platforms. Long term, IPF will be a Good Thing for VMS,A > > assuming IPF achieves the exalted "industry standard" status.0 > N > Right now?  Really?  Not lack of marketing (or any other sign of interest by
 > its owner)?h > N > Last I knew, VMS systems, complete with licenses, could be found on eBay for! > the cost of a modest home PC.  s  D To LEGALLY develop (or use) commercial software on a VMS system, youC have to a) have valid commercial licenses and b) if you bought themSH second-hand, pay the transfer fee, which might be more than the price of	 the box. m  A If this is not the case, point me to an official statement (e.g. >, somewhere on the Compaq web site) saying so.  I As it stands now, if I literally save a VMS machine from being destroyed  F in the trash compactor, and this happens to machines which, when new, G cost perhaps $30,000, even if I have all the paperwork I have to pay a "F license-transfer fee.  OK, it's not THAT much, but still rather stiff G for such a case.  If, as is often the case, there is no paperwork, one l2 has to buy the licenses, which are very expensive.  B Even if I just use EDT to compose text files and email them to my G publisher, who will publish my novel, this can't be done on a hobbyist  # license since it is commercial use.a   ------------------------------    Date: 13 Dec 2001 07:59:12 -0600- From: koehler@encompasserve.org (Bob Koehler)n' Subject: Re: Inquirer: OpenVMS on DS20L 3 Message-ID: <Y1udisTczekY@eisner.encompasserve.org>   j In article <5LMR7.494$BK1.13935@news.cpqcorp.net>, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:  7 > Sheeesh.  Would you be happy if it was called "Bob"? k  G    No.  I would absolutley demand VMS support for it before I would letf    you use my name.   D    As you may recall, Microsoft's unauthorized use of my name failedF    misserably.  And if you don't think that's for real, meet me at the2    annual Bob fest next year in Steamboat Springs.   ------------------------------  # Date: Thu, 13 Dec 2001 15:49:25 GMTa# From: Jim <krait1@worldnet.att.net>e' Subject: Re: Inquirer: OpenVMS on DS20Lo+ Message-ID: <3C18CC73.807@worldnet.att.net>u   >[snip]?   > F > To LEGALLY develop (or use) commercial software on a VMS system, youE > have to a) have valid commercial licenses and b) if you bought themoJ > second-hand, pay the transfer fee, which might be more than the price of > the box. t > C > If this is not the case, point me to an official statement (e.g.  . > somewhere on the Compaq web site) saying so. >      http://csa.compaq.com'    >[snip]   Jim.   ------------------------------  # Date: Thu, 13 Dec 2001 15:53:58 GMTs4 From: "Terry C. Shannon" <terryshannon@mediaone.net>' Subject: Re: Inquirer: OpenVMS on DS20L - Message-ID: <pa4S7.18977$7y.213398@rwcrnsc54>t  L "Jan Vorbrueggen" <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote inJ message news:y4snafo4fp.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de...9 > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:  > L > > Sheeesh.  Would you be happy if it was called "Bob"?  Someone in productJ > > management just gave it what seemed to be a reasonable name.  BTW this thingtE > > isn't even shipping, and UNIX is still working on support for it.  > D > Technically true. But business is 90% psychology, 9% sweat, and 1% technology.vH > Ignore your buyer's psychology at your peril. What was that name, ara? >r  I Ah yes. Advanced RISC Architecture. I believe "ara" is a Very Bad Word in J Arabic, Farsi, or some other middle eastern language. Same mistake GM madeK with the Chevy Nova. Since "no va" translates into "doesn't go" in Spanish,>2 GM didn't sell a heck of a lot of Novas in Mexico!   ------------------------------  % Date: Thu, 13 Dec 2001 08:48:10 -0800d' From: David Mathog <mathog@caltech.edu>>' Subject: Re: Inquirer: OpenVMS on DS20L + Message-ID: <3C18DBCA.E524D276@caltech.edu>    "Terry C. Shannon" wrote:s  G > The biggest problem VMS faces right now (IMHO) is the availability ofn! > low-cost development platforms.>  < Right now???  That makes it sound like a new development but< it's been a huge problem for at last 15 years!!!  The nearly8 total obliteration of OpenVMS in academia and most other6 computing arenas was (and still is) a direct result of8 OpenVMS software and hardware always costing (much) more than the competition.h  ? > assuming IPF achieves the exalted "industry standard" status.r  9 And that's an increasingly dubious assumption given AMD's 6 increasing market share against Intel in the x86 space7 and the advent in the near future of the Hammer series. 9 Also, is it realistic to expect that Intel will sell IA64m7 cpus without the price markup that it applies to Xeons?t< The only way that I see IA64 becoming price attractive is if= AMD pushes Intel so hard that they have no choice but to selle? this CPU for less.  Kind of like what happened with the regulare (non Xeon) PIII and PIV.   Regards,   David Mathog mathog@caltech.edu   ------------------------------    Date: 13 Dec 2001 10:41:00 +0100G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>e< Subject: Re: It you say it often enough does it become fact?H Message-ID: <y4pu5jo3tf.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  3 John McLean <mcleanj@swissonline.delete.ch> writes:a  E > From the notes accompanying the Technical Update Presentation (withpG > regard to what's coming in 7.3) made in May of this year ... and note A > that month !! ... we find the 1999 breakdown of Server revenue.> > @ > It reads (page 2 of "Compaq Alphaserver Directions") ...  ISSDE > (consisting of WNT) approx $7 billion .... BCSD (consisting of NSK,>E > Tru64 and VMS) approx $9 Billion.   BCSD is further split into NSk,rF > approx $2 billion; Tru64 approx $3 billion ... and OpenVMS approx $4
 > billion.  I That's the slide I saw the breakdown of revenue from the various parts of + Compaq from, and which Bill cited later on.   M If ISSD was also making income of 20% similar to VMS, as Jeff wants to claim, J it would have generated income of $1.4G in that period. Is that checkable?   	Jan   ------------------------------  % Date: Thu, 13 Dec 2001 19:12:37 +0100m1 From: John McLean <mcleanj@swissonline.delete.ch> < Subject: Re: It you say it often enough does it become fact?5 Message-ID: <3C18EF95.A8D1CC39@swissonline.delete.ch>i   Jan Vorbrueggen wrote: > 5 > John McLean <mcleanj@swissonline.delete.ch> writes:  > G > > From the notes accompanying the Technical Update Presentation (withvI > > regard to what's coming in 7.3) made in May of this year ... and notesC > > that month !! ... we find the 1999 breakdown of Server revenue.b > > B > > It reads (page 2 of "Compaq Alphaserver Directions") ...  ISSDG > > (consisting of WNT) approx $7 billion .... BCSD (consisting of NSK,rG > > Tru64 and VMS) approx $9 Billion.   BCSD is further split into NSk, H > > approx $2 billion; Tru64 approx $3 billion ... and OpenVMS approx $4 > > billion. > K > That's the slide I saw the breakdown of revenue from the various parts ofY- > Compaq from, and which Bill cited later on.e > O > If ISSD was also making income of 20% similar to VMS, as Jeff wants to claim,eL > it would have generated income of $1.4G in that period. Is that checkable? > 
 >         Janh    @ Sorry but I'm not aware of any documents that give the Year 2000? breakdown or any figures for the various quarters of this year.m  B I can say that the presentation mentioned above was made in EuropeC during May.  Perhaps it had been pepared for a US audience sometimeE7 earlier when the Year 2000 figures were not available. o     John McL   ------------------------------  % Date: Thu, 13 Dec 2001 15:38:43 +0100o& From: Michael Joosten <joost@c-lab.de> Subject: Re: Linus' view on VMSa$ Message-ID: <3C18BD73.41C6@c-lab.de>   John Laird wrote:  >    > G > We have these real "manuals", you see :-)   (Up until the point whereuE > Decpaq started to create html-only versions of more and more, whileI  E That's actually the reason why I still have four pieces of the Oranger Wall from MicroVMS 4.4...s  F > simultaneously not providing a decent viewer...)  On-line BookreaderI > versions did have substantial cross-referencing, within books at least,nF > and you would rarely have to jump books anyway.  The printed manuals8 > used to be TeX-derived, not a lot of people know that.  E Oh YES! The 4.X manuals proudly mentioned it on the back of the covera? side, and all the examples where set in 'cmtt' (Computer ModernlE Typewriter Text). What about the 5 and 6 versions, when did they stop 1 using TeX, probably because of rising 'figurism'?    -- t* Michael Joosten, SBS C-LAB, joost@c-lab.de* Fuerstenallee 11, 33094 Paderborn, Germany, Phone: +49 5251 606127, Fax: +49 5251 6060658 C-LAB is a cooperation of University Paderborn & SIEMENS   ------------------------------  % Date: Thu, 13 Dec 2001 09:54:40 +0100t( From: Paul Sture <paul.sture@bluewin.ch>0 Subject: Re: Modifying ownership of INDEXF.SYS ?- Message-ID: <VA.000004e7.f1ba4d7b@bluewin.ch>a  G In article <pgfc1ucsttvj6cbue2hnp5a3pjvb7vhbe9@4ax.com>, Richard wrote:u@ > **** Post for FREE via your newsreader at post.usenet.com **** > O > On Sun, 09 Dec 2001 10:57:26 +0100, Paul Sture <paul.sture@bluewin.ch> wrote:s > J > >In article <nvcv0u4v5c78vrq6j27dd5kk7pblvt5hfj@4ax.com>, Richard wrote:C > >> **** Post for FREE via your newsreader at post.usenet.com ****h > >> iB > >> A little more research says it can't be done with native VMS. > >> oK > >> http://www.decus.org/encompass/libcatalog/document_html/vs0174_15.htmlr > >> oR > >> This page points to a utility that will do what I want, but the link is dead. > >> d: > >> Anyone have a copy of CHOWN  or know of a valid link? > >> nR > >No idea. You have so far managed to escape telling us why you want to do this.  > L > Simple.  Because I want the owner of INDEXF.SYS to be modified.  You don'tI > need anything other than that.  Why is a 100% irrelevant question here.a >PK Sorry, but "why" isn't irrelevant. I am interested in how you got into the p/ position and what others should do to avoid it.u   ___c
 Paul Sture Switzerland    ------------------------------  % Date: Thu, 13 Dec 2001 11:51:30 -0500r% From: "John Vottero" <John@mvpsi.com> ' Subject: Re: More depressing IA-64 newso/ Message-ID: <u1hn4ppp39sh25@news.supernews.com>n  : Maybe they'll decide that the best fallback plan is Alpha?  1 "Shane Smith" <ssmith@icius.com> wrote in message * news:01C18328.71501A10@sulfer.icius.com...C > Sorry if this link's already been posted, couldn't find it in thee@ > archives but I haven't been following the group 100% recently. >.) > http://www.theinquirer.net/12120122.htm  > I > Apparently there's only 500 Itanium systems been sold so far, and InteloJ > are putting more effort into their supposed fallback x86-64 project. AndE > the Merced got pushed back to next year - surprise surprise. Great.,J > Kicked off the Alpha Iceberg to land on the Itanic, which may already be
 > sinking. > F > It seems to me VMS has a history of betting on the wrong horses. TooJ > late onto the TCP bandwagon because they went with OSI, chose a minorityH > windowing system at least twice and changed to the frontrunner just asF > it got overtaken, dropped the x86 port. Admittedly they tended to goG > with the technically superior option, but they ended up losing groundaE > each time. So, no change there. This one's just a bit more obvious.e >S1 > Maybe it's time for a "VMS on Hammer" campaign?> >  > Shaner   ------------------------------  + Date: Thu, 13 Dec 2001 05:20:55 -0800 (PST)c. From: Fabio Cardoso <fabiopenvms@yahoo.com.br># Subject: Re: Moving from MVS to VMSb@ Message-ID: <20011213132055.79286.qmail@web20208.mail.yahoo.com>  1 Sometimes I would like a Roscoe like for OpenVMS.  Mainly RPF Panels and AWS.   Regardst   FC=20o. --- Dino Jr <computerguy@antelecom.net> wrote:6 > Is anyone on this list experienced with both VMS and > MVS (OS/390) ? >=205 > I am an old MVS jocky moving into the VAX/VMS world  > and could use some=20s5 > support/guidance in making the change. My specialtyh > is print operations. >=20 > TIA. >=20 >=20 >=20     =3D=3D=3D=3D=3DEL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3De F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazil  fabiopenvms@yahoo.com.brL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D   2 __________________________________________________ Do You Yahoo!?8 Check out Yahoo! Shopping and Yahoo! Auctions for all of; your unique holiday gifts! Buy at http://shopping.yahoo.come# or bid at http://auctions.yahoo.comi   ------------------------------  # Date: Thu, 13 Dec 2001 14:11:52 GMTi8 From: hammond@not@peek.ppb.cpqcorp.net (Charlie Hammond)# Subject: Re: Moving from MVS to VMS>2 Message-ID: <IG2S7.547$BK1.15238@news.cpqcorp.net>  , In article <3C17D180.2548F41@videotron.ca>, / JF Mezei <jfmezei.spamnot@videotron.ca> writes:i ..O >The big paradigm difference is that the VMS queues contain a pointer to a filer2 >whereas the MVS engine contains the spooled data. ..  " See also HELP SET DEVICE /SPOOLED.B Although it is not typical on OpenVMS (in my expereience) this can? create what I would conciser a more IBM/MVS-like environment.  w3 But It gives up various features of OpenVMS queues.,   --  K     Charlie Hammond -- Compaq Computer Corporation -- Pompano Beach  FL USA H        (hammond@not@peek.ppb.cpqcorp.net -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------    Date: 13 Dec 2001 09:55:59 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)l# Subject: Re: Moving from MVS to VMSI3 Message-ID: <w75$4houeeJ+@eisner.encompasserve.org>K  m In article <IG2S7.547$BK1.15238@news.cpqcorp.net>, hammond@not@peek.ppb.cpqcorp.net (Charlie Hammond) writes:o. > In article <3C17D180.2548F41@videotron.ca>, 1 > JF Mezei <jfmezei.spamnot@videotron.ca> writes:t > ..P >>The big paradigm difference is that the VMS queues contain a pointer to a file3 >>whereas the MVS engine contains the spooled data.  > .. > $ > See also HELP SET DEVICE /SPOOLED.D > Although it is not typical on OpenVMS (in my expereience) this canA > create what I would conciser a more IBM/MVS-like environment.  n5 > But It gives up various features of OpenVMS queues.b  A I have never heard of a way to use spooled devices for Postscripty< output from programs, so it is limited in this modern world.  8 Perhaps the originator of the thread can tell us whether- Postscript spooling is handled on modern MVS.l   ------------------------------  + Date: Thu, 13 Dec 2001 17:09:29 +0100 (MET)V9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>$3 Subject: nova (was: RE: Inquirer: OpenVMS on DS20L):; Message-ID: <01KBTRX5DI2E9138XQ@sysdev.deutsche-boerse.com>i  I > Same mistake GM made with the Chevy Nova. Since "no va" translates intoeE > "doesn't go" in Spanish, GM didn't sell a heck of a lot of Novas inu
 > Mexico!   G I'm pretty sure this is an urban legend (if not, it is an urban legend nD that it is an urban legend :-) ).  First, nova is Latin for new and I would be recognised as such in Spanish.  Second, nova was used as a name  > for a type of gasoline, which apparently, didn't have similar F detrimental effects.  Third, I think they sold as many Chevy Novas as  they expected.   ------------------------------  # Date: Thu, 13 Dec 2001 17:03:59 GMTc4 From: "Terry C. Shannon" <terryshannon@mediaone.net>7 Subject: Re: nova (was: RE: Inquirer: OpenVMS on DS20L)a- Message-ID: <3c5S7.19244$7y.215641@rwcrnsc54>   F "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message5 news:01KBTRX5DI2E9138XQ@sysdev.deutsche-boerse.com...oK > > Same mistake GM made with the Chevy Nova. Since "no va" translates intolG > > "doesn't go" in Spanish, GM didn't sell a heck of a lot of Novas ina > > Mexico!e >0H > I'm pretty sure this is an urban legend (if not, it is an urban legendE > that it is an urban legend :-) ).  First, nova is Latin for new andTJ > would be recognised as such in Spanish.  Second, nova was used as a name? > for a type of gasoline, which apparently, didn't have similarpG > detrimental effects.  Third, I think they sold as many Chevy Novas asg > they expected. >l  J I believe Data General once sold a minicomputer bearing the "Nova" name as well!r   ------------------------------  % Date: Thu, 13 Dec 2001 13:21:17 -0500e- From: Jonathan Boswell <jsb@ost.cdrh.fda.gov>B7 Subject: Re: nova (was: RE: Inquirer: OpenVMS on DS20L)d0 Message-ID: <3C18F19D.90A3F33D@ost.cdrh.fda.gov>   Phillip Helbig wrote:aK > > Same mistake GM made with the Chevy Nova. Since "no va" translates intosG > > "doesn't go" in Spanish, GM didn't sell a heck of a lot of Novas inn > > Mexico!p > H > I'm pretty sure this is an urban legend (if not, it is an urban legend# > that it is an urban legend :-) ).t  H See http://www.snopes2.com/business/misxlate/nova.htm which seems pretty definitive.s    - JBn   ------------------------------  % Date: Thu, 13 Dec 2001 13:15:27 -0500k- From: "John Eisenschmidt" <jeisensc@aaas.org>iF Subject: OT: CERT Advisory - Buffer Overflow in System V Derived Login+ Message-ID: <sc18aa0e.078@AAASMTA.aaas.org>   K I thought some of you might get a kick out of this. Does not affect Tru64 = 5 or HP-UX, but it does affect IBM AIX and Sun Solaris.o  . http://www.cert.org/advisories/CA-2001-34.html   Systems Affected  "     * IBM AIX versions 4.3 and 5.1     * Hewlett-Packard's HP-UX &     * SCO OpenServer 5.0.6 and earlier     * SGI IRIX 3.x     * Sun Solaris 8 and earlieri   Overview  D Several applications use login for authentication to the system. A =J remotely exploitable buffer overflow exists in login derived from System =H V. Attackers can exploit this vulnerability to gain root access to the = server.?   ------------------------------  # Date: Thu, 13 Dec 2001 07:14:38 GMT ' From: "Hank Oredson" <horedson@att.net>a Subject: Re: Poll'J Message-ID: <yzYR7.220735$3d2.10336928@bgtnsc06-news.ops.worldnet.att.net>  9 "Peter Watkinson" <peterw@u.genie.co.uk> wrote in messager1 news:3c167c95.14961515@news.cable.ntlworld.com...- >- > H > I wondered if I might do a straw poll asking posters if they have a PC > what type it is. >:4 > For me I still use a dual PPro 200mhz running NT4. >tH > The reason I ask is I'm still confused as to why Q killed the Alpha. IH > now have a cable modem installed at home and I find the speed of my PCC > more than adequate for all my pc uses. In the past with a dial uptF > connection I was always looking for more speed to cope with the slow > network connection.lH >  If this is the case with other users I wonder what makes Compaq thinkF > that home users or business will rush out to buy Itaniums when their > old kit is up to the job.0H >  With EV7 to be imminently released and hopefully knock Power4 off theG > top of the performance pile the Alpha will have plenty of performance8H > to keep Itanium or even Mckinley at bay and thus still keep it's share! > of the Market in the HPC arena.sE >  If Compaq wanted a growth area for Alpha maybe they shouldn't haveiH > cancelled AlphaNT. Alternatively instead of investing $ in the port ofF > VMS/Tru64 to IA64 maybe they should have invested in an Office (Star > Office) port.sA >  Seems to me the only reason I can think of that -Compaq boughtiD > Digital in the first place was part of a 3 pronged conspiracy with' > Wintel to narrow down the opposition.%   One each on the house network:  7 486DX2/66, Cyrix 6X686/200, Pentium 90, Pentium II/400,a Pentium III/550, Pentium 4/2000R  - The 486 and 6X686 are about to be retired ...o   --    ...  Hank   Let loose the cats of war, sleek and fast and strong. They will seek and kill, the evil we have found.    http://horedson.home.att.net   ------------------------------    Date: 13 Dec 2001 06:01:04 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)1  Subject: Re: SYS$EXAMPLES in 7.33 Message-ID: <Ay+9M5DnvH4n@eisner.encompasserve.org>S  e In article <3C182A0C.549C1EFD@cableinet.co.uk>, Tim Llewellyn <tim.llewellyn@cableinet.co.uk> writes:   : > hmmm, its there on the COmpaq Testdrive VMS 7.3 cluster. >  > $ sh sys/noproc>K > OpenVMS V7.3  on node SPE202  12-DEC-2001 22:57:34.45  Uptime  1 13:02:53  > $ dir sys$examples:io*.c > ( > Directory SYS$COMMON:[SYSHLP.EXAMPLES] >  > IO_PERFORM.C;1 >  > Total of 1 file. > $w  1 It is there on a local V7.3 Alpha I just checked.e   ------------------------------  # Date: Thu, 13 Dec 2001 07:04:14 GMTu' From: "Hank Oredson" <horedson@att.net>t! Subject: Re: The demise of compaqnI Message-ID: <OpYR7.293546$W8.10030758@bgtnsc04-news.ops.worldnet.att.net>   5 "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message * news:9v5uio$gns$1@pegasus.csx.cam.ac.uk...4 > In article <nZtR7.445$BK1.13966@news.cpqcorp.net>,6 > Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote: > >>D > >>That is true for the trivial bugs only.  If they are bugs in theD > >>interface, design or (worst) basic model, then it is MUCH harderB > >>to fix them after shipment because doing so will stop all your, > >>existing customers dead in their tracks. > >>G > >>And it is this conflict that is the reason that MOST of the seriousuD > >>bugs in modern software are long-lived and pervasive - there are9 > >>many that I have been suffering from for 20 years :-(D > >>F > >>It can only get worse - and worse - and worse - until such time asC > >>we have a major meltdown, with all the chaos that implies.  Gody > >>help our children! > >e= > >The alternative is to be fixing them and NOT making money.f > > N > >I, and almost anyone in this business make routine decisions everyday aboutK > >the level of quality code must have before it ships.  In general, out of M > >about 5 or 6 levels of bug priorities I use, only one - showstopper - will G > >prevent the code from shipping, or slipping the date.  Enough "high"$M > >priority bugs might also cause this.  But I have never shipped code that ItN > >could reasonable conclude had no bugs, unless it was small enough to fit on > >a couple screens. > >aO > >I have from time to time been put in a position to recommend doing work thatoN > >will make code better to maintain, and reduce the number of problem reportsO > >over time we would get... but cannot justify it because there simply isn't a N > >sufficient customer visable benefit - the question being how many customersM > >will not buy if we don't do it, and how many new ones will buy if we do don > >it. > >hK > >Someone like a Microsoft has precious little incentive to clean up theirhL > >code.  Add features, sell new versions, fix the X% highest bugs reported. > >Repeat until rich.t >h" > I am not denying any of that :-( > E > But I am also warning that the world is heading for a disaster, and C > I don't mean the minor glitches that we have seen so far.  We caniE > only hope that we receive a healthy shock in time to recover.  Yes,SE > I really am talking about a potential collapse of civilisation, and 7 > most of the other experts in this area agree with me.p  * Which disaster? What cause? Which experts?  D > As with the ecology and resources, short-term gain always wins outA > against long-term survival, and we are relying on unsustainable A > practices.  We are seeing an increasing number of projects fail > > simply because changing circumstances bring deep bugs to the? > surface, and it is simply infeasible to locate the problem in D > time to save the project.  Often because there is nobody left with > the appropriate skills.q  / Can you provide any references to back this up?t  C > One day this will happen to something critical, and cause a majoreB > economic collapse - which, history teaches us, very often causes > a major war :-(i  3 What "... something critical" did you have in mind?-  / > There is a saying about a horseshoe nail ....i  $ Yes, there is ... how does it apply?   --    ...  Hank   Let loose the cats of war, sleek and fast and strong. They will seek and kill, the evil we have found.o   http://horedson.home.att.net   ------------------------------    Date: 13 Dec 2001 09:13:22 +0100G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>e! Subject: Re: The demise of compaqsH Message-ID: <y47krrpmfx.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  * nmm1@cus.cam.ac.uk (Nick Maclaren) writes:  B > That is true for the trivial bugs only.  If they are bugs in theB > interface, design or (worst) basic model, then it is MUCH harder@ > to fix them after shipment because doing so will stop all your* > existing customers dead in their tracks.  E That's not bugs, those are design or specification failures. AnythinghG state got as far as coding in that state should result in the designerseC (if there were any) and definitely the manager of the project beingsH summarily executed (or whatever society currently substitutes for such).  I I do think Fred was talking about ordinary bugs that are killed using DDTS or similar insecticides.   	Jan   ------------------------------   Date: 13 Dec 2001 09:16:17 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)! Subject: Re: The demise of compaqs0 Message-ID: <9v9rl1$g4e$1@pegasus.csx.cam.ac.uk>  2 In article <8JTR7.521$BK1.14954@news.cpqcorp.net>,4 Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:I >Wow.  I might ship code that is several thousand lines long, but I wouldSM >never have the lack of humility to believe that it is bug free at the time IkK >shipped it.  I have had code that was "bug free" that ran for years beforeaB >the first bug actually was reported.  Alas, it *wasn't* bug free.  C David Wheeler has said that he does not believe that there has ever/C been a bug-free program.  Once, I felt he was overstating the case. ' Now, I am 20 years more experienced :-)t  E I have written code that has run on dozens of different systems (even C counting Unix as one), was about 1,000 lines long and has never had A a reported bug.  But I (as the author) know that it had some ....u  > I have occasionally challenged people to show me a non-trivialC bug-free program (even one of 20 lines), and have typically pointeda? out a bug in the first half-dozen lines.  The usual response isoA "Ah, but it isn't supposed to handle that case", followed closely 6 by "Well, what can you do if your system is perverse?"  I Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:o > D > > That is true for the trivial bugs only.  If they are bugs in theD > > interface, design or (worst) basic model, then it is MUCH harderB > > to fix them after shipment because doing so will stop all your, > > existing customers dead in their tracks. > G > That's not bugs, those are design or specification failures. AnythingeI > state got as far as coding in that state should result in the designerstE > (if there were any) and definitely the manager of the project being0J > summarily executed (or whatever society currently substitutes for such). > K > I do think Fred was talking about ordinary bugs that are killed using DDTe > or similar insecticides.  B Perhaps, but I think that the difference is illusory.  MOST of theC serious bugs I see in vendors' systems are where the designers have C been careless and not thought through and documented precisely whats2 they are trying to do, and what they are assuming.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679a   ------------------------------  % Date: Thu, 13 Dec 2001 10:21:13 +0100a1 From: Franz-Josef Fornefeld <jo.fornefeld@gmx.de> ! Subject: Re: The demise of compaq-' Message-ID: <9v9veq.ml.1@jo.dyndns.org>    Goran Larsson wrote:  / > My conclusion was that software should have aME > software quality that is balanced. Not too bad as your customers go8G > elsewhere. Not too good as your customers don't need your help fixinga > bugs.P  A We had the same experience. Our customers cancelled their servicec contracts in the 90's.  F A well configured VMS system runs practically with no attention[1] andD so does our software[2]. It was more economic to call for service on demand.   9 [1] our record holder is a VAX8250 with ~1500 days uptimep- [2] not bug free of course, but fairly robust0   ------------------------------   Date: 13 Dec 2001 09:47:01 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)! Subject: Re: The demise of compaqy0 Message-ID: <9v9tel$hbn$1@pegasus.csx.cam.ac.uk>  I In article <OpYR7.293546$W8.10030758@bgtnsc04-news.ops.worldnet.att.net>,3& Hank Oredson <horedson@att.net> wrote: >_ >>F >> But I am also warning that the world is heading for a disaster, andD >> I don't mean the minor glitches that we have seen so far.  We canF >> only hope that we receive a healthy shock in time to recover.  Yes,F >> I really am talking about a potential collapse of civilisation, and8 >> most of the other experts in this area agree with me. >M+ >Which disaster? What cause? Which experts?7  = As I said earlier, I am not prepared to expose my contacts too@ the abuse of the ignorant.  And you can guess which posters I am referring to :-)  = We are not sure where things will fail first, but the genericwA reason is that we are seeing increasingly complex software, builtL? up of multiple layers, where the precise interfaces between the ? layers often make undocumented and untestable assumptions.  And/> each layer may be a million lines of code, written by hundreds of people over several decades.i  @ Even worse, some layers are very poorly understood.  Some people@ understand parts but, because of their size, complexity and long> history, nobody understands the whole.  In some cases, most of< people who know WHY certain decisions were made are over 50,= and nobody has revisited the overall design in over 20 years.K  ? The danger is that this will carry on, and then there will be a4? failure of a sort that cannot be kludged up or bypassed, and it5@ will be impossible to sort out in time to save the industry that> depends on it.  And, if that industry is important enough, its* collapse could lead to a global recession.  D At present, TCP/IP is pretty well in this state, but not so far usedA for much critical.  There is a particular failure syndrome, whichoE I have seen on 4 Unices and have heard of on most others, that I haveiC reasonable evidence is a design error in the stack.  God knows whataC or where, because I have never tracked it right down, but it causessA a connexion to fail to recover from a temporary hardware failure.   E >> As with the ecology and resources, short-term gain always wins outsB >> against long-term survival, and we are relying on unsustainableB >> practices.  We are seeing an increasing number of projects fail? >> simply because changing circumstances bring deep bugs to the:@ >> surface, and it is simply infeasible to locate the problem inE >> time to save the project.  Often because there is nobody left withs >> the appropriate skills. >d0 >Can you provide any references to back this up?  A I could, but many are confidential.  Most of the ones that I haveiD seen have been minor, and often verbal.  Such as when I have pointedE out to a vendor that certain problems are soluble, and the developersnB have said "yes, but we have nobody left who knows how to do that".B Reliable error and signal handling in programming languages is one
 such area.  D >> One day this will happen to something critical, and cause a majorC >> economic collapse - which, history teaches us, very often causese >> a major war :-( >-4 >What "... something critical" did you have in mind?  @ Dunno.  One possibility is air traffic control, which is alreadyA having problems.  Let us say that there is a load-related problem7A in the infrastructure (i.e. not the main code) that causes LondonuA to go down.  So it switches to the backup.  Because this is load-d= related and software, it goes down.  So it switches to Paris. 2 The extra load then triggers the same problem ....  @ Today, there are manual backups that will get most aircraft down? intact.  In 20 years, there probably won't be.  And all backupssD are against hardware failure - NOT against a failure of the software@ design.  Now a one-off incident like that (even if 20,000 peopleA died) isn't serious.  But what if the programmers couldn't locatee the problem?  = Today, you would install another software system, retrain the @ controllers and be back within 6 months (after a fashion).  But,C in 20 years, what if there IS only one system?  After all, there is-C in some areas (think Microsoft).  Speak to an economist about this,  and get nervous.  0 >> There is a saying about a horseshoe nail .... >E% >Yes, there is ... how does it apply?-  D Think game theory.  We are talking about very low probability eventsD with a very high expense.  It is easy to cost how much it would takeA to avoid the problems we can forsee, and it is expensive.  But isNC it cheaper than risking disaster?  For a published analysis on this ) one, look at the asteroid strike problem.s  B We KNOW how to design failure-resistant software, but don't do it.A Even when we DO do it (e.g. air traffic control), it often relies-A on infrastructure that is not done that way (e.g. Unix, TCP/IP orm@ Microsoft).  For the reasons that Fred Kleinsorge said.  Some of( us believe that this is a serious error.  @ The hardware people are much better organised here, and there isF movement (both in research and commerce) to tackle the known problems.       Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 3346790   ------------------------------  % Date: Thu, 13 Dec 2001 09:57:20 +0000r% From: Alan Greig <a.greig@virgin.net>f! Subject: Re: The demise of compaq=8 Message-ID: <hgug1uofg7fmd9ebbldsm6mjlohmd9lpj0@4ax.com>  4 On Wed, 12 Dec 2001 21:18:10 GMT, "Terry C. Shannon"" <terryshannon@mediaone.net> wrote:    H >Hmmm... this idea might have some merit, JF. I'd love to go do customer >pitches in Fiji.  >dH >Thing is, there probably isn't much of an installed base in Fiji, which= >might make Mr. Gorham and crew look askance on the proposal.s  F University of Fiji used to be major VMS users.  A quick check of their web site still shows: @ http://www.usp.ac.fj/its/helpdesk/guides/userguides/vmsmail.html  $ Which is a  guide to using VMS Mail.   So Fiji seems a perfect place!   > H >As an aside, the Compaq New Zealand crew is doing quite well for itselfI >under MD Russ Hewitt. CPQ enjoys majority market share, a loyal customer 2 >base, and a great group of employees in Kiwiland. >.K >Sad but true, Michael Capellas hasn't visited Compaq New Zealand. He oughtdI >to consider doing so, as the New Zealand operation demonstrates what can > >happen when marketing and customer engagement are done right! >b   -- Alan   ------------------------------  + Date: Thu, 13 Dec 2001 13:36:25 +0000 (UTC)o/ From: Sander Vesik <sander@haldjas.folklore.ee>4! Subject: Re: The demise of compaqp2 Message-ID: <1008250583.37922@haldjas.folklore.ee>  ; In comp.arch Robert Harley <harley@estephe.inria.fr> wrote:s  9 > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes: G >>But I have never shipped code that I could reasonable conclude had noA> >>bugs, unless it was small enough to fit on a couple screens.  @ > That small?  I've shipped code up to a few thousand lines (100F > screens or so) for which I could reasonably conclude it had no bugs.  F Well, see, the problem seems to be that the size Fred talks about is aJ codebase of many millions of lines, also known as the Tru64 kernel (unless4 I got my memory wrong and irts some other kernel)...  K >> Someone like a Microsoft has precious little incentive to clean up theireL >> code.  Add features, sell new versions, fix the X% highest bugs reported. >> Repeat until rich.e  H > My old prof used to say: don't put bugs in the code in the first place+ > and then you won't have to debug it... :)2     > Bye, >   R K >     .-.                                                               .-.7L >    /   \           .-.     Robert.Harley@argote.ch     .-.           /   \M >   /     \         /   \       .-.     _     .-.       /   \         /     \tN >  /       \       /     \     /   \   / \   /   \     /     \       /       \O > /         \     /       \   /     `-'   `-'     \   /       \     /         \:D >            \   /         `-'                     `-'         \   /C >             `-'                http://argote.ch/              `-'i   --   	Sanderl   +++ Out of cheese error +++    ------------------------------  % Date: Thu, 13 Dec 2001 06:49:33 -0700m+ From: "Dennis O'Connor" <dmoc@primenet.com>:! Subject: Re: The demise of compaq-2 Message-ID: <1008251374.17333@nnrp2.phx1.gblx.net>  , "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote :( > Hank Oredson <horedson@att.net> wrote:H > >> But I am also warning that the world is heading for a disaster, andF > >> I don't mean the minor glitches that we have seen so far.  We canH > >> only hope that we receive a healthy shock in time to recover.  Yes,H > >> I really am talking about a potential collapse of civilisation, and: > >> most of the other experts in this area agree with me. > >s- > >Which disaster? What cause? Which experts?> > ? > As I said earlier, I am not prepared to expose my contacts to  > the abuse of the ignorant.  < Bullshit.  You have nothing.  This is just your chicken-shit& way of trying to avoid being shredded.  7 Attempting "proof by anonymous authority" is the lamest > thing I've seen in comp.arch in a long time.  It's even a step7 below "Nostradamus predicts...", where at least we knowa  which expert is being relied on. --3 Dennis O'Connor                   dmoc@primenet.comi3 We don't become a rabid dog to destroy a rabid dog.t   ------------------------------  # Date: Thu, 13 Dec 2001 15:44:38 GMT 2 From: "frank brown" <frank.brown@ci.seattle.wa.us>' Subject: unix equivalent for F$MODE() ?e3 Message-ID: <G14S7.555$yb4.25194@news-west.eli.net>i  L I want to test if a bash script is running in interactive vs batch mode on a@ linux box.  Is there a unix equivalent of the DCL F$MODE() call?   -Frank   ------------------------------   Date: 13 Dec 2001 17:37:13 GMT* From: bdwheele@indiana.edu (Brian Wheeler)+ Subject: Re: unix equivalent for F$MODE() ? 3 Message-ID: <9vap09$pue$1@flotsam.uits.indiana.edu>e  3 In article <G14S7.555$yb4.25194@news-west.eli.net>,m5 	"frank brown" <frank.brown@ci.seattle.wa.us> writes:tN > I want to test if a bash script is running in interactive vs batch mode on aB > linux box.  Is there a unix equivalent of the DCL F$MODE() call? >  > -Frank >  >     % would "test -t" do what your wanting?c   from the manpage for test:
       -t [FD]eA               file descriptor FD (stdout by default) is opened ond               a terminal    
 Brian Wheelera bdwheele@indiana.edu   ------------------------------    Date: 13 Dec 2001 08:01:06 -0600- From: koehler@encompasserve.org (Bob Koehler)t( Subject: Re: Unix for HELP ... Examples?3 Message-ID: <hI6vyqVvG1fB@eisner.encompasserve.org>   c In article <rjzPNfWP+2Fy@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:t > H > Get a VMS system and use the MANPAGE destination with DEC Document :-)  H    I new there was a reason I loaded DEC Document on my hobbyist system.B    Now I can look like a eunich without actually having to be one!   ------------------------------  # Date: Thu, 13 Dec 2001 08:46:46 GMT ' From: "Hans Vlems" <hvlems@zfree.co.nz>s+ Subject: Re: Unknown VAXstation 4000-90 ???e$ Message-ID: <3c186af3$1@zfree.co.nz>  E Thanks for your reply. The fact that your 4000-90A also comes up withe* the KA49-A identification is good to hear. To answer your questions:c  > - the ?? CRPT messages never came back on subsequent power ups - VMS 7.3 installed all rightaH - VMS 7.3 still reports that it found an invalid processor configuration   Hans  & "a.carlini" <arcarlini@iee.org> wrote: >, >e >Hans Vlems wrote:3 >> I loaded the kit abd the console message is now:  >>    >> KA49-A V1.4-0D0-V4.4   83 MHZ >> 08-00-2B-94-CD-C3 >> 80MB  >> fH >> The version went up from V1.3 to V1.4 so I conclude that the firmware >> upgrade went well.1 >2# >Does the OpenVMS install work now?i >s@ >> Then I ran a test sequence (>>> t 100) and that started with: >> a< >> KA49    V1.0   System Test CU                  0 00:00:13 >> oO >> Note the cpu identifier: it went to KA49. The Cougar documentation explainedt >> that thenM >> KA49-A is the VAXstation 4000 model 90 and that the KA49 is the VAXstationi >> 4000 model 90A  >f+ >I'm pretty sure my system is running V1.3,s, >it reports itself as a KA49-A 83MHz. I have* >also seen a system that reports itself as. >KA49-A 71MHz, which I believe is a VS4000-90.! >That one, too, was a V1.3, IIRC.s >l& >So unless V1.4 changed something, the) >thing to look out for is 83MHz vs 71MHz.r >c$ >I'll try TEST 100 next time I bring# >mine down to the console prompt. I - >suspect that the test writer forgot to add ai- >"-A" somewhere! Do the various SHOW commandsr) >display KA49 or KA49-A? Does this change- >after TEST 100? > K >> So probably that is wrong: the firmware thinks it runs on a 4000-90 withR aT >> fast clock apparently.g >>  G >> Any ideas on how to make it think it is an honest VS 4000 model 90A?e >c/ >OpenVMS cannot tell, AFAIK. Is it working now?o >c >Antonio >  >--  >m >---------------. >Antonio Carlini             arcarlini@iee.org       http://www.zfree.co.nz   ------------------------------  # Date: Thu, 13 Dec 2001 12:27:42 GMTd' From: "Hans Vlems" <hvlems@zfree.co.nz>a+ Subject: RE: Unknown VAXstation 4000-90 ???t" Message-ID: <3c189ebb@zfree.co.nz>   Tom,  > thanks for your input. The problem with the ?? CRPT message isD over. At least it did not appear any more at subsequent powercycles.= The machine had been power off for 3 years. That might be it.t> But VMS 7.3 still does not recognize the processor. Any ideas?   Hans  $ "Tom Linden" <tom@kednos.com> wrote: >  >  >> -----Original Message-----t< >> From: Hoff Hoffman [mailto:hoffman@xdelta.zko.dec.nospam]- >> Sent: Wednesday, December 12, 2001 8:10 AMp >> To: Info-VAX@Mvb.Saic.Com. >> Subject: Re: Unknown VAXstation 4000-90 ??? >> h >> o5 >> In article <3c170b05$1@zfree.co.nz>, "Hans Vlems" u >> <hvlems@zfree.co.nz> writes:o >> :B >> :The ?? CRPT - Reenter bit clr message no longer appears after  >> switching the? >> :unit on. It had been off for three years, so that may have h >> something to do >> :with that behaviour. >> bE >>   It might well be that a backup battery went flat, or has failed.CG >>   Most (all?) VAX systems have a lithium or NiCd or similar battery oF >>   pack for (at least) the maintenance of the system date and time, 1 >>   and these do eventually need to be replaced.n > G >Well, FWIW, i replaced the Dallas Real-time clock in a 4000/90 a whiletH >back, by cannabilizing a 3100, which uses the same zif socketed device.H >I forgot the part designation, but checking the internet I recall their> >was a newer drop-in replacement part, and it was less than $5 >> e2 >> :How can I locate, and replace, the flash chip? >> IH >>   The flash chips I've seen are fairly obvious chips -- the ones I've  H >>   seen in systems are labeled with some variation of "Dallas" and/or 
 >>   "flash".  >> eI >>   I'd first start with a reload of the microcode for the system -- the J >>   firmware microcode is available from field service and (before anyone  J >>   asks) it is apparently not presently available on the Compaq website. >>  B >>   I have asked one of the Compaq folks that deals with the old  >> VAX product  H >>   line to see if the firmware could be placed onto the existing Alpha  J >>   firmware kits and/or onto the firmware website and firmware FTP site. >> y* >> :Or do I have to replace the cpu board? >> sJ >>   I do not know if it is socketed, but all of the flash chips I've seen   >>   have been.c >> e >> 84 >>  ---------------------------- #include <rtfaq.h>   >> -----------------------------7 >>       For additional, please see the OpenVMS FAQ --   >> www.openvms.compaq.com    .6 >>  --------------------------- pure personal opinion  >> ---------------------------5 >>    Hoff (Stephen) Hoffman   OpenVMS Engineering   n >> hoffman#xdelta.zko.dec.coml >> s       http://www.zfree.co.nz   ------------------------------  % Date: Thu, 13 Dec 2001 09:34:46 -0800- From: ITIntern@thriftyfoods.com9 Subject: VAXF Message-ID: <OF0130B036.5FF2A5B4-ON88256B21.005FFC24@thriftyfoods.com>  	 Good day,D  J My machine is a IBM NetVista X40, OS is Windows 2000 with Kea 2000, duringI an open session I will be entering data and moving on to another line andtJ the data that I entered say four lines prior to the line that I am workingI on now appears to be blank for no apparent reason , at first I thought itnJ was hardware but that wasnt the case cause it happens on any computer thatI i log on and when I print the data appears. No other user is experiencingsF this dilemma. Please let me know if you have any suggestions or if you require any mor information.       Chris Biernackia	 IT Internr  email: itintern@thriftyfoods.com   ------------------------------  # Date: Thu, 13 Dec 2001 14:31:56 GMTo8 From: hammond@not@peek.ppb.cpqcorp.net (Charlie Hammond)" Subject: Re: VAX, er, Voice Populi2 Message-ID: <wZ2S7.548$BK1.15083@news.cpqcorp.net>  / In article <aYPR7.38982$ER5.462308@rwcrnsc52>, e6 "Terry C. Shannon" <terryshannon@mediaone.net> writes:  E >Compaq shares are trading at under $10 right now. If 100 comp.os.vmsuM >denizens were to purchase 10 shares of CPQ apiece, and subsequently craft anoK >Open Letter to Compaq, the letter might get some attention from the Powersm	 >That Be.   H Let's see...  100 "denizens" with 10 shares each...  That's 1000 shares.  C According to Bloomerg.com, there are 1.694 billion shares of Compaqr: stock out there.  Did you leave off two or three zeroes?     -- tK     Charlie Hammond -- Compaq Computer Corporation -- Pompano Beach  FL USA H        (hammond@not@peek.ppb.cpqcorp.net -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------  # Date: Thu, 13 Dec 2001 15:49:36 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>" Subject: Re: VAX, er, Voice Populi- Message-ID: <k64S7.18968$7y.213423@rwcrnsc54>   E "Charlie Hammond" <hammond@not@peek.ppb.cpqcorp.net> wrote in messagei, news:wZ2S7.548$BK1.15083@news.cpqcorp.net...0 > In article <aYPR7.38982$ER5.462308@rwcrnsc52>,8 > "Terry C. Shannon" <terryshannon@mediaone.net> writes: >fG > >Compaq shares are trading at under $10 right now. If 100 comp.os.vmssL > >denizens were to purchase 10 shares of CPQ apiece, and subsequently craft anF > >Open Letter to Compaq, the letter might get some attention from the Powers > >That Be.s >lJ > Let's see...  100 "denizens" with 10 shares each...  That's 1000 shares. > E > According to Bloomerg.com, there are 1.694 billion shares of Compaq.: > stock out there.  Did you leave off two or three zeroes? >s  K Nope. But if a letter signed  by 100 stockholders doesn't get any attentionnK from CPQ, imagine how much attention Usenet postings get from the firm. ;-}    ------------------------------  # Date: Thu, 13 Dec 2001 18:29:46 GMTp* From: "Bill Todd" <billtodd@metrocast.net>" Subject: Re: VAX, er, Voice PopuliB Message-ID: <ts6S7.247524$8q.23035002@bin2.nnrp.aus1.giganews.com>  ? "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messagep' news:k64S7.18968$7y.213423@rwcrnsc54...j > G > "Charlie Hammond" <hammond@not@peek.ppb.cpqcorp.net> wrote in messagea. > news:wZ2S7.548$BK1.15083@news.cpqcorp.net...   ...y  G > > According to Bloomerg.com, there are 1.694 billion shares of Compaqs< > > stock out there.  Did you leave off two or three zeroes? > >  >bC > Nope. But if a letter signed  by 100 stockholders doesn't get anyo	 attentionoI > from CPQ, imagine how much attention Usenet postings get from the firm.t ;-}   L I don't know about anyone else, but I gave up on hoping anyone with any realJ authority at Compaq paid any attention to this forum long ago.  My hope isH that enough customers (not via their CIOs, but via their grunts) do thatK postings will have an effect there - getting them either to pressure CompaqNF directly or to take enough of their business elsewhere to get noticed.  I And of course there's a *bit* of information-migration upward, via peopleuI like Mike Magee and onward toward the mainstream industry press (and evencJ mainstream press, period - people from the Boston Globe have been known to3 drop by and solicit opinions on specific subjects).t  K People with more commitment to changing things can of course help the abovee$ migration along if they're inclined.   - bill   ------------------------------    Date: 13 Dec 2001 11:10:03 +0100G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>s Subject: Re: vms 3.x question H Message-ID: <y4n10no2h0.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  4 "Zane H. Healy" <healyzh@shell1.aracnet.com> writes:  J > > of course, I don't have any way of testing this, and what is the pointJ > > unless you have a 730/750/780 and some application that won't ru on a  > > more recent version of VMS?r >  > Historical Value!   G Yep. See http://simh.trailing-edge.com/ and in particular read Supnik'so- article on resurrecting the OS of the PDP-15.e   	Jan   ------------------------------  % Date: Thu, 13 Dec 2001 10:17:44 +0000e4 From: John Laird <john@laird-towers.freeserve.co.uk> Subject: Re: VMS 72 on MV 31008 Message-ID: <opvg1us1150tld87ag9ha73n41rgb68s29@4ax.com>  + On Wed, 12 Dec 2001 20:55:28 -0500, Phillipe' <nntpmouse@prism.datastacks.com> wrote:i  I >I'll try getting a 1gig or so; I have several RZ23's tho.  I tried a 2.1-G >GB IBM SCSI drive, but it didnt seem to come up, so I'm guessing it's  H >not compatible. Now All I have to do is find my Decus member number for? >the license and figure out how to install on multiple disks :)2  H You don't mention what model of 3100 this is, but I will assume it's oneG of the less speedy varieties (anything up to 48, but not 80 or beyond).uE Even accepting the relative lack of horsepower, you'd really be doing E yourself a favour by getting hold of a decent disk.  The RZ23 *never*aH qualified for the title of decent :-)   I can dig out specs if you like,E but the access times and data rates will make you howl with laughter.i  H If you do have an earlier model (check the FAQ for exact specifics), youG may well not be able to boot without risk of major data corruption withNF any disk larger than 1Gb.  An RZ26 would be ideal, or its Seagate Hawk equivalent.o     	John    ------------------------------    Date: 13 Dec 2001 11:44:53 +0100, From: Nazim MANSER <Nazim.Manser@socgen.com> Subject: RE: VMS 72 on MV 3100T Message-ID: <010A83C1886A5008*/c=FR/admd=ATLAS/prmd=SG/o=INFI/s=MANSER/g=NAZIM/@MHS>   seeing your problemg     >>>show devicese    A >  DKA200   RZ2     A/2/0/00  RODISK    681 MB   RM        CD-ROM E >  DKA300   RZ3     A/3/0/00  DISK           104 MB   FX         RZ23r# >  ...HostID....    A/6       INITRT >d# >  ...HostID....    B/6       INITR0 >.  F 1) the CDrom is not supported by VMS, try another one (e.g.   TOSHIBA)  w 2) the hard disk where you want to install vms 7.2 is too small, i suggest 1 GB or 2 GB drive which is supported by VMSd8      some 3rd party SCSI disks will function others not.    	 reguards,n   Nazim Manser   ------------------------------  % Date: Thu, 13 Dec 2001 17:11:02 +0100c& From: Michael Joosten <joost@c-lab.de> Subject: Re: VMS 72 on MV 3100$ Message-ID: <3C18D316.167E@c-lab.de>   John Santos wrote: >   F > Do you have a real DEC/Compaq CD-ROM drive that is supported by VMS? > L > I had a very similar problem on an Alpha.  My CD-ROM drive also identifiesG > itself as a SONY CD-ROM (not sure of model number.)  It is clearly an G > unsupported drive, (has some logo on the box that seems to be derived I > from the Stanford Univerisity Network), and seems to not be identifyinge > itself as a read-only drive. >   G Yes, the very same happened with two (old!) SONY OEM drives, CDU-541-2S  and CDU561-01.  G show dev in SRM worked ok, it even booted the VMS CD on an PC164 board,gC but once VMS was running, the CDROM did not appear in 'show dev d'. 6 The VMS dkdriver simply doesn't like them, it appears.  H > I can boot it okay (get the Alpha Menu), but when I try to install VMSF > on an RZ28, it inits it okay, then asks for the current date & time.E > It immediately prints a message saying the CD has been write-locked # > and goes into mount verification./ >   G Looks like the easiest way is to copy the install CD on an old 1GB SCSI F drive, and use that if you fail to use 'your' CDROM drive in the first+ attempt. Even faster to install this way...m   -- j* Michael Joosten, SBS C-LAB, joost@c-lab.de* Fuerstenallee 11, 33094 Paderborn, Germany, Phone: +49 5251 606127, Fax: +49 5251 6060658 C-LAB is a cooperation of University Paderborn & SIEMENS   ------------------------------  % Date: Thu, 13 Dec 2001 11:39:41 -0500h0 From: "Phillip" <nntpmouse@prism.datastacks.com> Subject: Re: VMS 72 on MV 3100B Message-ID: <20011213.113941.624549797.20382@prism.datastacks.com>  E In article <opvg1us1150tld87ag9ha73n41rgb68s29@4ax.com>, "John Laird"e* <john@laird-towers.freeserve.co.uk> wrote:J > You don't mention what model of 3100 this is, but I will assume it's oneI > of the less speedy varieties (anything up to 48, but not 80 or beyond).l  = How would I tell what model it is?  I got mine used as thus: t* 	2 sets of mother board, scsi contoler,etc
 	7 rz23 disksy" 	1 case, with powersupply, not top  G > Even accepting the relative lack of horsepower, you'd really be doingmG > yourself a favour by getting hold of a decent disk.  The RZ23 *never*.J > qualified for the title of decent :-)   I can dig out specs if you like,G > but the access times and data rates will make you howl with laughter.  > J > If you do have an earlier model (check the FAQ for exact specifics), youI > may well not be able to boot without risk of major data corruption withyH > any disk larger than 1Gb.  An RZ26 would be ideal, or its Seagate Hawk
 > equivalent.  >    Can you point me to the FAQ?G Also, someone mentioned that the 3100 didnt support over 1GB drives; do- you know if this is so!e   >  > 	John7    + THANKS!  This group really is helping me :)e< -Phillip (Tring to put out the neon 'NEWBIE' sign above him)   ------------------------------  % Date: Thu, 13 Dec 2001 17:50:11 +000094 From: John Laird <john@laird-towers.freeserve.co.uk> Subject: Re: VMS 72 on MV 31008 Message-ID: <f5qh1us5bih3eak2ubap74hteui6rvhcpq@4ax.com>  - On Thu, 13 Dec 2001 11:39:41 -0500, "Phillip"i' <nntpmouse@prism.datastacks.com> wrote:F  F >In article <opvg1us1150tld87ag9ha73n41rgb68s29@4ax.com>, "John Laird"+ ><john@laird-towers.freeserve.co.uk> wrote:iK >> You don't mention what model of 3100 this is, but I will assume it's one J >> of the less speedy varieties (anything up to 48, but not 80 or beyond). >a> >How would I tell what model it is?  I got mine used as thus: + >	2 sets of mother board, scsi contoler,etc. >	7 rz23 disks# >	1 case, with powersupply, not tops  F What does the power-up test say ?  It'll be KA-nn, and this might evenF match a label on the back of the box :-)  You might have to use GoogleH or similar if the FAQ (below) does not equate model numbers to processor identification.D  H >> Even accepting the relative lack of horsepower, you'd really be doingH >> yourself a favour by getting hold of a decent disk.  The RZ23 *never*K >> qualified for the title of decent :-)   I can dig out specs if you like,:H >> but the access times and data rates will make you howl with laughter. >> sK >> If you do have an earlier model (check the FAQ for exact specifics), youiJ >> may well not be able to boot without risk of major data corruption withI >> any disk larger than 1Gb.  An RZ26 would be ideal, or its Seagate Hawki >> equivalent. >>   >o >Can you point me to the FAQ?oH >Also, someone mentioned that the 3100 didnt support over 1GB drives; do >you know if this is so!  5 http://www.openvms.compaq.com/wizard/openvms_faq.html   G The 1Gb issue is described therein.  The older the Microvax (which does>F not always equate to the lower model numbers(*)), the more likely that the limit applies.  @ (*)  Once they got to 80 and beyond, the later models had higherC numbers.  The earliest versions were 30s (38s the same but a larger G box), and then there were 40s (with larger 48 equivalents) and then (iniF an order I cannot remember) things like 10, 20, 10e, 20e.  Usually the front of the case was marked !     	John    ------------------------------  % Date: Thu, 13 Dec 2001 10:19:40 +0000u4 From: John Laird <john@laird-towers.freeserve.co.uk>! Subject: Re: VMS file hex editor?a8 Message-ID: <l40h1u0kj720g7aoasrdudul2kc31498tg@4ax.com>  / On Wed, 12 Dec 2001 23:26:38 GMT, "frank brown"I% <frank.brown@ci.seattle.wa.us> wrote:h  M >Is there a hex editor available for VAX/VMS?  I want to change some bytes in  >a binary file.n >o >http://www.inwa.net/~frog/     ? PATCH/ABSOLUTE (default PATCH mode is oriented to executables).h     	JohnH   ------------------------------  + Date: Thu, 13 Dec 2001 11:55:38 +0100 (MET)>9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>a! Subject: Re: VMS file hex editor?p; Message-ID: <01KBTHC6IHQO9138XQ@sysdev.deutsche-boerse.com>a  E > Is there a hex editor available for VAX/VMS?  I want to change somei > bytes in a binary file.   I There is something called GEM (IIRC); a unix port, but it works.  I know  C Hunter knows something about this, but I didn't see it at his site.    ------------------------------  % Date: Thu, 13 Dec 2001 14:13:46 +0000u( From: Nic Clews <sendspamhere@127.0.0.1>! Subject: Re: VMS file hex editor?>) Message-ID: <3C18B79A.28A9EAEE@127.0.0.1>l   frank brown wrote: > N > Is there a hex editor available for VAX/VMS?  I want to change some bytes in > a binary file.  
 I use VFE.  = http://www.decus.org/libcatalog/document_html/vs0174_154.htmlt  , (However the link for the sw appear to fail)   But the original is here...    ftp://mvb.saic.com/VAX85C/VFE    -- :( Regards, Nic Clews CSC Computer Sciences nclews at csc dot comd   ------------------------------  % Date: Thu, 13 Dec 2001 15:38:37 +0000t From: Roy Omond <Roy@Omond.net>?! Subject: Re: VMS file hex editor?0) Message-ID: <3C18CB7C.61851D2B@Omond.net>e   frank brown wrote:  N > Is there a hex editor available for VAX/VMS?  I want to change some bytes in > a binary file.  ( Others have suggested various solutions.   Me ?  I just use EDT.t  	 Roy Omond> Blue Bubble Ltd.   ------------------------------  # Date: Thu, 13 Dec 2001 16:39:27 GMT   From: adroso@home.com (VLC user)! Subject: Re: VMS file hex editor?l: Message-ID: <3c18d8f3.488305786@news.jamison1.pa.home.com>  F I use EDT.  I can send a decimal/hex/ascii conversion chart to you, if	 you wish.l   ------------------------------  # Date: Thu, 13 Dec 2001 17:18:51 GMTc2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)! Subject: Re: VMS file hex editor?t2 Message-ID: <%p5S7.555$BK1.15173@news.cpqcorp.net>   frank brown wrote: : N : Is there a hex editor available for VAX/VMS?  I want to change some bytes in : a binary file.  ,   For OpenVMS VAX, please see the following:     $ HELP PATCH/ABSOLUTE   B   For OpenVMS Alpha, please see the details around PATCH available   in the OpenVMS FAQ."  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------    Date: 13 Dec 2001 08:12:16 -0600- From: koehler@encompasserve.org (Bob Koehler)o$ Subject: Re: where can we beat them?3 Message-ID: <JDXbVl7kyOYS@eisner.encompasserve.org>r  T In article <9v8r4d$3uu$1@news1.xs4all.nl>, "Wim_K" <verledentijd@homail.com> writes:A > I'm just wondering where we can beat those uniks guys and gals.lL > I know that clustering and shadowing is a big thing, but I havent heard ofM > any major (software, programs ) who are specially for vax or axp, there are-* > so many big spenders who are using VMS.?  H    The US Federal Government is a big spender, and it uses VMS.  Is that    what you're looking for?e  F    Maybe you can write your Congressman to stop using taxpayer dollars    on "eunichs" and "deamons".   ------------------------------    Date: 13 Dec 2001 10:05:43 +0100G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>yH Subject: Re: Writing a device driver: virtual/physical address questionsH Message-ID: <y4vgfbo5g8.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  7 "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:h  L > Well, I wouldn't say that it is a good practice for a device to know aboutG > page table formats.  Makes it platform, and perhaps even OS specific.n  L I would agree in principle. However, I would think that any high-performanceL device contains a processor executing a stored program anyway. So all the OSJ has to do is to download the routine(s) that walk the page tables into the$ device - say, in Java byte code 8-)?   	Jan   ------------------------------  % Date: Thu, 13 Dec 2001 20:05:17 +0100m, From: "Sjaak Bosman @ BBI.nl" <Sjaak@BBI.nl> Subject: Re: WSSIZE and AWSA4 Message-ID: <3c18fa13$0$228$4d4ebb8e@news.nl.uu.net>   D.  K Somehow both my contributions doesn't show up for me in the newsgroup. OnlyaL your repply. Besides of that it looks like the attachement weren't included.  H Still I want to post this contribution to the OpenVMS-world. Any advise?   Regards,   Sjaak.   ------------------------------   End of INFO-VAX 2001.692 ************************