1 INFO-VAX	Sun, 08 Apr 2001	Volume 2001 : Issue 196       Contents:' Re: - OpenVMS ever to be on Intel chip?  Compaq & VMS Careers Re: Compaq & VMS Careers Re: Compaq & VMS Careers Re: Compaq & VMS Careers  Re: DEC Server software question2 RE: Flipping from big-endian to little endian in C2 Re: Flipping from big-endian to little endian in C2 Re: Flipping from big-endian to little endian in C2 Re: Flipping from big-endian to little endian in C2 RE: Flipping from big-endian to little endian in C$ Re: free disk space on a bound disks$ Re: free disk space on a bound disks Re: FTP hijacking of VMS sites RE: FTP hijacking of VMS sites Re: FTP hijacking of VMS sites/ Q: Converting a VAX 6000-420 to a VAX 6000-620? 3 Re: Q: Converting a VAX 6000-420 to a VAX 6000-620?  sys$io_performw  Re: sys$io_performw   Re: THE EMC Chronicles - revised Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable B Web Counter 2.4 with Purveyor Support and distributed lock managerF Re: Web Counter 2.4 with Purveyor Support and distributed lock manager  F ----------------------------------------------------------------------  $ Date: Sat, 7 Apr 2001 11:17:38 -0700- From: "Bill Pedersen" <pedersen@ccsscorp.com> 0 Subject: Re: - OpenVMS ever to be on Intel chip?9 Message-ID: <3acf59c3$0$830$8eec23a@newsreader.tycho.net>    Motivation is:  F     1) the continued support of existing OpenVMS VAX based applicationG without port to OpenVMS Alpha - especially long term given there are no * longer any VAX systems being manufactured.  0     2) small, portable development environments.  A These are the primary draw that I see for the product at present.   G There does seem to be some interest in it, in talking with the folks at J Software Resources International they see between 100 and 200 downloads of the hobbyiest version DAILY.  H SMP is not the direction being pursued at the present time.  It uses SMPF already in that each thread in the emulator (each device) is a thread.   --
 Bill Pedersen  CCSS Corporation www.CCSScorp.com 831-336-2708    3 "bill davidsen" <davidsen@tmr.com> wrote in message 4 news:9aktmn$2nkq$1@newssvr05-en0.news.prodigy.com...; > In article <3acde9fa$0$838$8eec23a@newsreader.tycho.net>, . > Bill Pedersen <pedersen@ccsscorp.com> wrote:0 > | ELN has been run on the Charon-VAX emulator. > | E > | Am currently working with a couple customers with the emulator on  OpenVMS K > | Alpha for support of OpenVMS VAX applications which they do not wish to " > | migrate (or can not) to Alpha. > | F > | Newest version (MV3500/3600) which supports 64MB is still in beta. > |  > | Looks JUST LIKE A VAX. > | J > | Issues are, of course, the extra network adapter and a console device. OnJ > | workstation console can be another x-window.  On server have developedI > | technique of using a LAT device is applicaiton mode as the "console".  > @ >   I'd re-ask the previous question, can SMP be used to improveG > performance? And given the relative price and performance of ia86 vs. H > Alpha, isn't the market limited to people who need to run VAX softwareF > (VMS? OpenUNIX?) but can't or won't use a real VAX? If the markey isH > people who can't afford a VAX, I would guess the price of the softwareF > is going to have to be pretty low or they can't afford that, either. > I >   Those are questions, not comments or anything, I'm just curious about $ > the implementation and motivation. >  > --> >   bill davidsen <davidsen@tmr.com>  CTO, TMR Associates, IncI > "I am lost. I am out looking for myself. If I should come back before I = > return, please ask me to wait."  -seen in a doctor's office    ------------------------------   Date: 7 Apr 2001 17:53:02 GMT 1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)  Subject: Compaq & VMS Careers + Message-ID: <9ank5u$hvv$1@info.cs.uofs.edu>   B I hate to point out yet another bad sign, but a couple weeks ago IC was visiting the Compaq Home Page under Careers and it listed pages F of them all over the country.  I went there today to show a particularC possibility to one of our graduating students (It was a position to C work on Math Libraries and this student double majored in CS & Math F with very high scores.)  There are a grand total of 13 VMS jobs listedD on the web site.  I guess it won't accomplish much to steer studentsC in that direction any more.  What happened to all those positions??    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  # Date: Sat, 07 Apr 2001 19:27:38 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>! Subject: Re: Compaq & VMS Careers = Message-ID: <KSJz6.45046$Wz.11354446@typhoon.ne.mediaone.net>   > "Bill Gunshannon" <bill@triangle.cs.uofs.edu> wrote in message% news:9ank5u$hvv$1@info.cs.uofs.edu... D > I hate to point out yet another bad sign, but a couple weeks ago IE > was visiting the Compaq Home Page under Careers and it listed pages H > of them all over the country.  I went there today to show a particularE > possibility to one of our graduating students (It was a position to E > work on Math Libraries and this student double majored in CS & Math H > with very high scores.)  There are a grand total of 13 VMS jobs listedF > on the web site.  I guess it won't accomplish much to steer studentsE > in that direction any more.  What happened to all those positions??  >   J I just took a look and found 18 positions. That said, it's a steep declineH from a month or so ago. Must have something to do with the layoffs whichB took place at the end of 1FQ01. Unfortunately, Compaq's enterpriseH contingent was not exempt from the layoffs, even though the problem lies+ with peecees, not with VMS or Tru64 or NSK.   B But hey, if you're gonna have layoffs, it would be INSENSITIVE andK INAPPROPRIATE to restrict such to the business segments that are performing K poorly. Everybody's gotta get their fair share of the pain. Never mind that K VMS and Tru64 boast margins in excess of 50 percent, and that 90 percent of : CPQ's 1FQ01 profit will come from the enterprise business.  ; Isn't Personnel Department Political Correctness wonderful?    ------------------------------  % Date: Sun, 08 Apr 2001 20:40:39 +0000 ) From: Christof Brass <brass@infopuls.com> ! Subject: Re: Compaq & VMS Careers , Message-ID: <3AD0CCC7.AEC4E9DA@infopuls.com>   "Terry C. Shannon" wrote:  > @ > "Bill Gunshannon" <bill@triangle.cs.uofs.edu> wrote in message' > news:9ank5u$hvv$1@info.cs.uofs.edu... F > > I hate to point out yet another bad sign, but a couple weeks ago IG > > was visiting the Compaq Home Page under Careers and it listed pages J > > of them all over the country.  I went there today to show a particularG > > possibility to one of our graduating students (It was a position to G > > work on Math Libraries and this student double majored in CS & Math J > > with very high scores.)  There are a grand total of 13 VMS jobs listedH > > on the web site.  I guess it won't accomplish much to steer studentsG > > in that direction any more.  What happened to all those positions??  > >  > L > I just took a look and found 18 positions. That said, it's a steep declineJ > from a month or so ago. Must have something to do with the layoffs whichD > took place at the end of 1FQ01. Unfortunately, Compaq's enterpriseJ > contingent was not exempt from the layoffs, even though the problem lies- > with peecees, not with VMS or Tru64 or NSK.  > D > But hey, if you're gonna have layoffs, it would be INSENSITIVE andM > INAPPROPRIATE to restrict such to the business segments that are performing M > poorly. Everybody's gotta get their fair share of the pain. Never mind that M > VMS and Tru64 boast margins in excess of 50 percent, and that 90 percent of < > CPQ's 1FQ01 profit will come from the enterprise business. > = > Isn't Personnel Department Political Correctness wonderful?   
 Brilliant :-) 5 This is a good example why democracy isn't helpful in ? enterprises for beeing successful. As a CEO I would try to keep > all the people in the good parts of the business and only make, those redundant in the non-profitable parts.   ------------------------------  % Date: Sat, 07 Apr 2001 21:09:27 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)! Subject: Re: Compaq & VMS Careers L Message-ID: <rdeininger-0704012109280001@user-2iveae1.dialup.mindspring.com>  G In article <KSJz6.45046$Wz.11354446@typhoon.ne.mediaone.net>, "Terry C. + Shannon" <terryshannon@mediaone.net> wrote:   @ > "Bill Gunshannon" <bill@triangle.cs.uofs.edu> wrote in message' > news:9ank5u$hvv$1@info.cs.uofs.edu... F > > I hate to point out yet another bad sign, but a couple weeks ago IG > > was visiting the Compaq Home Page under Careers and it listed pages J > > of them all over the country.  I went there today to show a particularG > > possibility to one of our graduating students (It was a position to G > > work on Math Libraries and this student double majored in CS & Math J > > with very high scores.)  There are a grand total of 13 VMS jobs listedH > > on the web site.  I guess it won't accomplish much to steer studentsG > > in that direction any more.  What happened to all those positions??  > >  > L > I just took a look and found 18 positions. That said, it's a steep declineJ > from a month or so ago. Must have something to do with the layoffs whichD > took place at the end of 1FQ01. Unfortunately, Compaq's enterpriseJ > contingent was not exempt from the layoffs, even though the problem lies- > with peecees, not with VMS or Tru64 or NSK.   5 It's also possible they filled some of the positions.    --   Robert Deininger rdeininger@mindspring.com    ------------------------------  # Date: Sat, 07 Apr 2001 20:33:06 GMT  From: Dirk Munk <munk@home.nl>) Subject: Re: DEC Server software question ' Message-ID: <3ACF797C.56AD7508@home.nl>   L This software used to be on the VMS software library CD's, but I can't check that now I'm afraid.N Anyway, your vendor is responsible for a complete package of course. So if theE most recent software is not on VMS CD's, he has to supply it I guess.    Patrick Massey wrote:    > Hello,J > I've recently installed a DS900TM and found that only the first 16 of 32N > ports work.  The software it's loading WWENG2 ver 1.1a makes it think it's aL > DS700.  I really need to get the other 16 ports working.  Does anyone knowM > where I can find an updated loadfile?  I've contacted Compaq and the vendor : > I ordered the part from, neither have been very helpful. > Thanks in advance. > 
 > -Pat Massey    ------------------------------  % Date: Sat, 07 Apr 2001 09:33:02 -0700 ! From: Tom Linden <tom@kednos.com> ; Subject: RE: Flipping from big-endian to little endian in C 9 Message-ID: <CIEJLCMNHNNDLLOOGNJIGEINCFAA.tom@kednos.com>   + flip: proc options(input) returns(bit(16)); $ dcl src bit(16) based (addr(input)),     input fixed bin(15); return(reverse(src)); 	 end flip;    so in your C program   int *p p = flip(&value);   ! because PL/I passes by reference.    Or in a non-portable fashion  7 flip: proc options(input VALUE) returns(bit(16) VALUE); $ dcl src bit(16) based (addr(input)),     input fixed bin(15); return(reverse(src)); 	 end flip;    so in your C program   int p; p = flip(value);     > -----Original Message-----6 > From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]( > Sent: Saturday, April 07, 2001 1:32 AM > To: Info-VAX@Mvb.Saic.Com 9 > Subject: Flipping from big-endian to little endian in C  >  > > > I have to read a rather large amount of binary data (2 byte  > signed integers)1 > in C. The data is stored as big-endian shorts.   > = > If I have a entire row of 4800 big-endian signed shorts in   > consecutive memory, : > what would be the most efficient to flip all of them to  > litte-endian ? (VAX  > architecture, DEC-C).  >  > 2 > And while I am at it, a question on descriptors: > ) > I used to declare descriptors such as : 6 > $DESCRIPTOR(my_time_desc,"dd-mmm-yyyy hh:mm:ss.mm"); > A > and in the program, my_time_desc.dsc$a_pointer was filled with   > actual data.C > However, since DEC-C, the default ahs been to made the string in  
 > $DESCRIPTOR D > in non-writable memory, causing access violations when you try to  > write it.  > ) > I have since change my programs to have  > 	char my_time_char[25];   + > 	$DESCRIPTOP(my_time_desc,my_time_char) ;  >  > Is there a better way ?    ------------------------------  % Date: Sat, 07 Apr 2001 20:29:12 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> ; Subject: Re: Flipping from big-endian to little endian in C ) Message-ID: <3ACF5C78.36EDCE19@gtech.com>    JF Mezei wrote: N > I have to read a rather large amount of binary data (2 byte signed integers)0 > in C. The data is stored as big-endian shorts. > P > If I have a entire row of 4800 big-endian signed shorts in consecutive memory,M > what would be the most efficient to flip all of them to litte-endian ? (VAX  > architecture, DEC-C).   ? I can not see any other way than loop through them and swap the  bytes for each short int.   2 > And while I am at it, a question on descriptors: > ) > I used to declare descriptors such as : 6 > $DESCRIPTOR(my_time_desc,"dd-mmm-yyyy hh:mm:ss.mm"); > M > and in the program, my_time_desc.dsc$a_pointer was filled with actual data. N > However, since DEC-C, the default ahs been to made the string in $DESCRIPTORM > in non-writable memory, causing access violations when you try to write it.  > ) > I have since change my programs to have   >         char my_time_char[25];2 >         $DESCRIPTOP(my_time_desc,my_time_char) ; >  > Is there a better way ?    No.   G /STANDARD=VAXC or /STANDARD=COMMON or /ASSUME=WRITEABLE_STRING_LITERALS @ will solve the problem, but I think a variable is a variable and a constant a constant !    Arne   ------------------------------   Date: 7 Apr 2001 19:34 PDT) From: rankin@eql.caltech.edu (Pat Rankin) ; Subject: Re: Flipping from big-endian to little endian in C . Message-ID: <7APR200119343200@eql.caltech.edu>  - In article <3ACED07F.4CA8A637@videotron.ca>,\ 2  JF Mezei <jfmezei.spamnot@videotron.ca> writes...D > I have to read a rather large amount of binary data (2 byte signed; > integers) in C. The data is stored as big-endian shorts.   > H > If I have a entire row of 4800 big-endian signed shorts in consecutiveH > memory, what would be the most efficient to flip all of them to litte-% > endian ? (VAX architecture, DEC-C).   B      I would copy them into a separate array rather than swap themA in place.  Use pointers to unsigned char (rather than short) with   #   for (i = 0; i < 2*4800; i += 2) {      outbuf[i+1] = inbuf[i];      outbuf[i] = inbuf[i+1];    }   D (You might be tempted to use i++ or ++i in that loop.  Don't do it.)  B      For Alpha the answer might be different; cache considerationsC are more likely to apply and shifting and masking four 16-bit units   at a time could perhaps pay off.  2 > And while I am at it, a question on descriptors: > ) > I used to declare descriptors such as : 6 > $DESCRIPTOR(my_time_desc,"dd-mmm-yyyy hh:mm:ss.mm"); > G > and in the program, my_time_desc.dsc$a_pointer was filled with actual H > data. However, since DEC-C, the default ahs been to made the string inH > $DESCRIPTOR in non-writable memory, causing access violations when you > try to write it.  B      Such behavior is sanctioned by the C standard, and it usually= is a good thing.  The compiler has a qualifier to get the oldt$ behavior back if you really need it.  ) > I have since change my programs to haveN >	char my_time_char[25];  * >	$DESCRIPTOP(my_time_desc,my_time_char) ; > Is there a better way ?r  -      Let the compiler do the length counting.r  >        static char my_time_char[] = "dd-mmm-yyyy hh:mm:ss.mm";/        $DESCRIPTOR(my_time_desc, my_time_char);g  2                 Pat Rankin, rankin@eql.caltech.edu   ------------------------------  % Date: Sat, 07 Apr 2001 22:59:01 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>f; Subject: Re: Flipping from big-endian to little endian in Ci, Message-ID: <3ACFD3F2.6F5428A6@videotron.ca>   Pat Rankin wrote:l% >   for (i = 0; i < 2*4800; i += 2) {o >     outbuf[i+1] = inbuf[i];l >     outbuf[i] = inbuf[i+1];n >   }i > F > (You might be tempted to use i++ or ++i in that loop.  Don't do it.)  I why not ?  Also, is there something magic in the above that preserves the:: value of the second byte so it can be moved to the first ?   I was thinking of :p   ptr1 = inbuff ;  ptr2 = ptr1 + 1 ;5 ptr3 = ptr1 + 9600 ;   while (ptr1 < ptr3)r   { x = *ptr2 ;e       *ptr2 = *ptr1 ;>       *ptr1 = x;       ptr2 = ptr2 + 2 ;g 	ptr1 = ptr1 + 2 ;     }s  M The compiler would surely put "x" in a register and you only have 2 additionseJ to perform. In your example, would the compiler see the two "[i+1]" and do that operation only once ?   ------------------------------  % Date: Sat, 07 Apr 2001 19:58:50 -0700t! From: Tom Linden <tom@kednos.com>u; Subject: RE: Flipping from big-endian to little endian in Ch9 Message-ID: <CIEJLCMNHNNDLLOOGNJIIEJFCFAA.tom@kednos.com>   9 That won't work.  You need to reverse the entire 16 bits.j   > -----Original Message-----2 > From: Pat Rankin [mailto:rankin@eql.caltech.edu]( > Sent: Saturday, April 07, 2001 7:34 PM > To: Info-VAX@Mvb.Saic.Com?= > Subject: Re: Flipping from big-endian to little endian in C  >  > / > In article <3ACED07F.4CA8A637@videotron.ca>,\t4 >  JF Mezei <jfmezei.spamnot@videotron.ca> writes...F > > I have to read a rather large amount of binary data (2 byte signed= > > integers) in C. The data is stored as big-endian shorts. s > > J > > If I have a entire row of 4800 big-endian signed shorts in consecutiveJ > > memory, what would be the most efficient to flip all of them to litte-' > > endian ? (VAX architecture, DEC-C).a > D >      I would copy them into a separate array rather than swap themC > in place.  Use pointers to unsigned char (rather than short) withh > % >   for (i = 0; i < 2*4800; i += 2) {  >     outbuf[i+1] = inbuf[i];I >     outbuf[i] = inbuf[i+1];i >   }w > F > (You might be tempted to use i++ or ++i in that loop.  Don't do it.) > D >      For Alpha the answer might be different; cache considerationsE > are more likely to apply and shifting and masking four 16-bit units " > at a time could perhaps pay off. > 4 > > And while I am at it, a question on descriptors: > >k+ > > I used to declare descriptors such as :o8 > > $DESCRIPTOR(my_time_desc,"dd-mmm-yyyy hh:mm:ss.mm"); > >aI > > and in the program, my_time_desc.dsc$a_pointer was filled with actualeJ > > data. However, since DEC-C, the default ahs been to made the string inJ > > $DESCRIPTOR in non-writable memory, causing access violations when you > > try to write it. > D >      Such behavior is sanctioned by the C standard, and it usually? > is a good thing.  The compiler has a qualifier to get the old@& > behavior back if you really need it. > + > > I have since change my programs to have( > >	char my_time_char[25];  , > >	$DESCRIPTOP(my_time_desc,my_time_char) ; > > Is there a better way ?  > / >      Let the compiler do the length counting.e > @ >        static char my_time_char[] = "dd-mmm-yyyy hh:mm:ss.mm";1 >        $DESCRIPTOR(my_time_desc, my_time_char);d > 4 >                 Pat Rankin, rankin@eql.caltech.edu   ------------------------------  # Date: Sat, 07 Apr 2001 21:01:15 GMT  From: "Brad" <Brad@rkinc.com>r- Subject: Re: free disk space on a bound disksc; Message-ID: <veLz6.30246$Os.6671668@news1.rdc2.pa.home.com>M  0    Wow and you guys complain UNIX is Cryptic !!!  H > Here's some DCL I use to display disk volumes, their total size, theirH > space in use, space free and percent free. Note that it was written to% > handle shadow-sets and volume-sets.e >w  > USER$ROOT:[EXE]FREEDISK.COM;14 >  > $ IF P1 .EQS. "" THEN P1 := *w > $ SAY := WRITE SYS$OUTPUT  > $ TMB = 0h > $ FMB = 0t > $ CNTR = 0 > $ PCNT = 0
 > $P_LOOP:" > $ ELEM = F$ELEM( PCNT, ",", P1 ) > $ PCNT = PCNT + 1t% > $ IF ELEM .EQS. "" THEN GOTO P_LOOPr+ > $ IF ELEM .EQS. "," THEN GOTO EXIT_P_LOOPm > $ LNMTRN = F$TRNLNM( ELEM )n > $ IF LNMTRN .NES. "" THEN -d4 > $ ELEM = F$PARSE( ELEM,,, "DEVICE", "NO_CONCEAL" ) > $! ELEM = LNMTRN > $ GOSUB GET_DATA > $ GOTO P_LOOP  > $EXIT_P_LOOP:O > $ PCNT = 0 > $ GOSUB P_SHIFTs# > $ IF P1 .NES. "" THEN GOTO P_LOOP  > $ IF    TMB .NE. 0 > $ THEN- > $ FPCT = ((( FMB * 1000) / TMB ) + 5 ) / 10_
 > $ SAY ""J > $ MSG = F$FAO( "!UL Volume!%S Mounted, Aggregate: (MB, rounded)", CNTR )J > $ SAY F$FAO( "!45AS !8UL !8UL !8UL !3UL", MSG, TMB, TMB - FMB, FMB, FPCT > )r	 > $ ENDIFi > $ EXIT > $! > $P_SHIFT:v > $ P1 = P2c > $ P2 = P3: > $ P3 = P4  > $ P4 = P5a > $ P5 = P6n > $ P6 = P7e > $ P7 = P8C > $ P8 = ""9
 > $ RETURN > $! > $GET_DATA: > $ PREV_DISK :=- > $ ELEM = ELEM - "_" - "_" - ":" - ":" - ":"i > $ ELEM = "_''ELEM':" > $DISKLOOP:% > $ DISK = F$DEVICE("''ELEM'","DISK")h* > $ IF DISK .EQS. PREV_DISK THEN GOTO TAPE# > $ IF DISK .EQS. "" THEN GOTO TAPEw > $ PREV_DISK = DISK! > $ MNT = F$GETDVI( DISK, "MNT" )n# > $ IF .NOT. MNT THEN GOTO DISKLOOP + > $ SMSTR = F$GETDVI( DISK, "SHDW_MASTER" )o* > $ SMBR = F$GETDVI( DISK, "SHDW_MEMBER" ) > $ IF SMBR THEN GOTO DISKLOOP) > $! IF SMSTR .NES. "" THEN GOTO DISKLOOPt' > $ IF    F$GETDVI( DISK, "VOLSETMEM" )R > $ THEN > $       GOSUB PROC_VSET: > $ ELSE > $       GOSUB VOL_STATSy	 > $ ENDIFd > $ GOTO DISKLOOPl > $TAPE:
 > $ RETURN
 > $PROC_VSET:n/ > $ DISK = F$GETDVI( DISK, "ROOTDEVNAM" ) - "_"  > $PV_LOOP:R > $ GOSUB VOL_STATSe/ > $ DISK = F$GETDVI( DISK, "NEXTDEVNAM" ) - "_"r& > $ IF DISK .NES. "" THEN GOTO PV_LOOP
 > $ RETURN > $!
 > $VOL_STATS:m' > $ MNAME = F$GETDVI(DISK,"MEDIA_NAME")y# > $ ERCNT = F$GETDVI(DISK,"ERRCNT")t# > $ VOLNM = F$GETDVI(DISK,"VOLNAM")D% > $ MBLKS = F$GETDVI(DISK,"MAXBLOCK")=' > $ FBLKS = F$GETDVI(DISK,"FREEBLOCKS")e > $ UBLKS = MBLKS - FBLKSi > $ IF    (FBLKS * 100) .LT. 0, > $ THEN  FPCT = (FBLKS * 10) / (MBLKS / 10)& > $ ELSE  FPCT = (FBLKS * 100) / MBLKS	 > $ ENDIFa > $ IF    CNTR .EQ. 0a > $ THEN
 > $ SAY ""> > $ SAY "                   Media    Err     Volume      Total > Blocks    Free > Pct"H > $ SAY "Device Name        Name     Cnt     Label       Blocks   in use > Blocks > Free"r	 > $ ENDIFe > $ CNTR = CNTR + 1d' > $ lvn = f$getdvi( disk, "logvolnam" )b	 > $ lv := < > $ if f$length( lvn ) .eq. 2 then lv =f$fao( "(!AS)", lvn )> > $ SAY F$FAO( "!16AS !10AS !3UL !13AS !8UL !8UL !8UL !3UL", -E >         DISK + lv, MNAME, ERCNT, VOLNM, MBLKS, UBLKS, FBLKS, FPCT ) 4 > $ TMB = TMB + ((( MBLKS * 10 ) / 2048 ) + 5 ) / 104 > $ FMB = FMB + ((( FBLKS * 10 ) / 2048 ) + 5 ) / 10
 > $ RETURN >m > -- > David J. Dachterao > dba DJE Systemsh > http://www.djesys.com/ > < > Unofficial Affordable OpenVMS Home Page and Message Board:! > http://www.djesys.com/vms/soho/  >YH > This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings > is to be expected. >hB > Feel free to exercise your rights of free speech and expression. >tH > However, attacks against individual posters, or groups of posters, are > strongly discouraged.u   ------------------------------  % Date: Sat, 07 Apr 2001 20:03:13 -0600D1 From: "David J. Dachtera" <djesys.nospam@fsi.net> - Subject: Re: free disk space on a bound disksi' Message-ID: <3ACFC6E1.74130A57@fsi.net>e   Brad wrote:C > 2 >    Wow and you guys complain UNIX is Cryptic !!!   It *IS* !!!a  A I *SHUDDER* to think what all that DCL might look like if it were A possible to duplicate in perl or any kind of a shell script (UN*X = provides for neither host-based shadowing, nor the concept ofN? volume-sets, AFAIK in my admittedly limited knowledge of UN*X).   G I try to use "plain English" variable (symbol) names, but sometimes I'm&? just not in the mood to do a lot of typing or cut/paste in EDT. G FREEDISK.COM illustrates both cases. It actually evolved from part of ae  set of automated BACKUP scripts.   -- t David J. DachteraC dba DJE Systemso http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/   F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.    ------------------------------   Date: 7 Apr 2001 19:08:29 GMTr1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)e' Subject: Re: FTP hijacking of VMS sitesr+ Message-ID: <9anojd$js5$1@info.cs.uofs.edu>-  ) In article <9alg6r$bt7$1@hecate.umd.edu>,a-  bleau@umtof.umd.edu (Lawrence Bleau) writes:a |> A+ |> Has anyone experienced this phenomenon?     No.a  :Q |>                                           Has is cropped up at VMS sites?  Aree  C I'm sure it has as there are probably bound to be a proportionatelyr* equal number of clueless admins on any OS.    ) |> there standard ways of combating it?  a  B Don't allow Anonymous uploading of files to your machine by random people you can not trust.e  C |>                                       Should this be in the FAQ?e  ? Personally, I doubt it.  If you tried to list everything that aeB clueless admin can do to set up a machine improperly the FAQ would grow to an infinite size.-   bill   -- -J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   n   ------------------------------   Date: 7 Apr 2001 14:36:34 CDTO= From: wayne@tachysoft.xxx.065234.killspam.015d (Wayne Sewell)s' Subject: RE: FTP hijacking of VMS siteso. Message-ID: <LDaV$uF1fCnv@tachxxsoftxxconsult>  z In article <3B55D7F383B0D31197D9009027541CBF0D9D1D26@cmiexch1.cmi.itds.com>, Christopher Smith <csmith@amdocs.com> writes: >> -----Original Message-----i9 >> From: bleau@umtof.umd.edu [mailto:bleau@umtof.umd.edu]a > B >> i don't know if this is the case here, but i read articles fromB >> people who's anonymous ftp areas have been "hijacked" by peopleB >> distributing large files like movies.  typically, a 1MB file isG >> uploaded to check the speed.  if the hijacker thinks the speed is okc@ >> lots of directories are created and movie parts are uploaded. >  > That is fairly common. > < >> I think this subject deserves some discussion.  It's the  >> first I heard of it,>2 >> and I've been managing VMS systems for a while. > A >> Has anyone experienced this phenomenon?  Has is cropped up at y >> VMS sites?  AreC >> there standard ways of combating it?  Should this be in the FAQ?f > N > You don't mention whether it is really supposed to be a "public" archive, orL > something else...  The first of these solutions won't work for a site like > that, for obvious reasons. > M > It happens in FTP sites in general.  Typically there are three methods useddN > to stop it.  Perhaps the most obvious is to disallow anonymous access.  MakeM > an account with a password known only to those people who need access -- or"F > -- give each their own account. (For several reasons this may not be > feasible...) >   L I do it slightly differently.  I have only two accounts that everybody uses:K uploads and downloads, but I additionally restrict access by ip address.  ItM modified madgoat ftp to look at a logical called MGFTP_ALLOW_LIST, which is awM list of ip addresses, either discrete addresses or networks.  If a connectioneO is attempted from an ip address not in the list, it is rejected.  It never getsn) as far as username, much less password.  a  O Obviously, this is only feasible with a limited number of addresses, but that'scM all I need.  I don't allow general ftp access, just certain associates and/orfK customers.  The nice thing is that if I want to add a new ip address to the-K list temporarily for a one-shot transfer, I just redefine the logical, thenn0 redefine it back after the one-shot is finished.    I I don't use the ftp of the tcpip stack, but some of them can do somethingnO similar.  For instance, tcpware can restrict access to certain ports, includingeN ftp, with "netcu add access_list <port-number> permit <ip-address>" and "netcuK modify service <port-number> stream /access_list=<port-number>".  Unlike mytJ logical, this mechanism can both permit and deny specific ip addresses and	 networks.&   Waynei   --  O =============================================================================== M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxW: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)cO ===============================================================================aB Jed Clampett, checking into hotel: "This place got a cement pond?"+ Ellie May: "And do yuh let critters in it?"    ------------------------------  " Date: Sun, 8 Apr 2001 04:26:21 GMT7 From: moroney@world.std.spaamtrap.com (Michael Moroney)e' Subject: Re: FTP hijacking of VMS sitesn& Message-ID: <GBGHnx.8ux@world.std.com>  , bleau@umtof.umd.edu (Lawrence Bleau) writes:  N >Has anyone experienced this phenomenon?  Has is cropped up at VMS sites?  AreA >there standard ways of combating it?  Should this be in the FAQ?   D When I put my VMS system on a DSL line I knew it would be subject toI hackers and "script kiddies" poking at it.  I left the anon FTP directoryeG read-only to the anonymous FTP server (actually it "came" that way whenbH TCPIP was installed) and left the FTP server up to see what happened.  II kept monitoring the logs and I've seen the same things others have posteduF here, as well as attempts to look at the pub and incoming directories.F Of course the attempts to write files failed due to the writelock, butE 99% of them would have failed anyway due to the filenames (periods orhE slashes in the supplied names)  I'm sure that VMS systems confuse thet4 kiddies, as they can handle PCs and flavors of UNIX.  G So yes, secure your FTP access on all systems.  The script kiddies knowSJ what ranges of addresses are assigned to ISPs and they run scripts lookingG for open FTP sites (and many many others, abusable TELNET ports, trojantH horses on PCs that open a TCP port with a certain port number, etc. etc. So be careful out there!   -Mike    ------------------------------  " Date: Sat, 7 Apr 2001 20:57:09 GMT% From: bdc@world.std.com (Brian Chase)e8 Subject: Q: Converting a VAX 6000-420 to a VAX 6000-620?& Message-ID: <GBFwvA.Gxs@world.std.com>  J I've got a VAX 6000-420 and some CPUs coming from a VAX 6000-6xx system.  C Is it possible to replace the VAX 6000-4xx series CPUs with the VAX3J 6000-6xx CPUs?  If it is possible, is it just as simple as pulling out theG old CPUs and swapping in faster ones, or does something more need to be$ done?c   -brian.. --  F --- Brian Chase | bdc@world.std.com | http://world.std.com/~bdc/ -----I This 'telephone' has too many shortcomings to be seriously considered as  E a means of communication. The device is inherently of no value to us. 5                 -- Western Union internal memo, 1876.a   ------------------------------  # Date: Sat, 07 Apr 2001 21:45:14 GMTr) From: Bob Willard <bobwbsgs@mediaone.net>.< Subject: Re: Q: Converting a VAX 6000-420 to a VAX 6000-620?, Message-ID: <3ACF8A70.EB74DC5C@mediaone.net>   Brian Chase wrote: > J > I've got a VAX 6000-420 and some CPUs coming from a VAX 6000-6xx system.E > Is it possible to replace the VAX 6000-4xx series CPUs with the VAXiL > 6000-6xx CPUs?  If it is possible, is it just as simple as pulling out theI > old CPUs and swapping in faster ones, or does something more need to beo > done?w > 	 > -brian.r  E More.  The VAX 62x0/63x0/64x0 used write-thru caches, while the lateroF 65x0/66x0 used write-back caches.  If your 64x0 has original memories,B they will need to be replaced with later ones that had support for write-back caches.  D Also, maybe, if you have some early XMI I/O adapters, they may causeC problems.  Most of the I/O adapters were cured early enough that ifaC they shipped with a 64x0 they would also work with write-back CPUs.   B There may also be some configuration constraints -- number of 6500B or 6600 CPUs comes to mind -- based on the older power supplies in	 the 64x0.   D Sorry I can't be more specific about the I/O and P.S. stuff, but the! memories are the primary concern.  --   Cheers, Bob    ------------------------------  % Date: Sat, 07 Apr 2001 21:38:21 +0200pB From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@mail.danbbs.dk> Subject: sys$io_performw. Message-ID: <3ACF6CAD.BEFAD76D@mail.danbbs.dk>  / Does anyone just happend to have a nice example . with this that they could post (or email me if they do not want to post) ?0   Arne   PS: Yep - I am getting !   ------------------------------   Date: 07 Apr 2001 21:18:52 GMT' From: dashw459@aol.comeatspam (Doug W.)  Subject: Re: sys$io_performw: Message-ID: <20010407171852.28121.00004691@ng-mi1.aol.com>  ( << arne.vajhoej@mail.danbbs.dk wrote  >>.  sys$io_performw - does anyone have an example    N If you can drop the w, there is an example of sys$io_perform in sys$examples. K Last time I looked it gave a compiler error, but its easy to fix and fairly  clear.  Its a C program.  O I'm on vacation this week, when I return I have some disk spiraling performanceeJ utilities your welcome to if sys$examples is not what you are looking for.  J Personally, until I saw sys$examples I was confused by the documentation. M Also, there is an undocumented status return.  You will be able to figure outnG what VMS is complaining about, but I was surprised it was undocumented.J   ------------------------------  # Date: Sat, 07 Apr 2001 19:56:12 GMTt* From: Sean O'Banion <seanobanion@home.com>) Subject: Re: THE EMC Chronicles - reviseda( Message-ID: <3ACF70D6.AA201383@home.com>  O This is not he first time that criticism of EMC has resulted in complaints madeuO to the very managers who where "smoozed" (that IS the best way to describe whatcO happened with us), and was passed onto the employee.  However, that company dida# not put EMC into their VMS systems.u    M Nor am I surprised that some of the engineering details got glossed over when  it comes to VMS issues:[  N   After going through hell to evaluate the hardware, in which we found nothingI wrong but SCSI cabling and configuration mistakes on EMC's part, we stillhN rejected EMC on the grounds that their engineering expertise in evaluating ourF environment left too much to be desired.  Our management, however, hadJ forgotten that the 90 day trial had long ago expired, so we had to buy the	 hardware.t  N   We grudgingly installed it, and migrated from Storage Works & HSJ50 to EMC &O MTI Trident per their specifications.  Once there, the IO subsystem ran so slowaO that we could no longer process data as fast as the business required, which weON where doing on the SW & HSJ50.  EMC came back and admitted that we should haveN continued to use host-based striping to spread our IO across all six CI's whenH we moved to EMC.  This was exactly what EMC stated that we should not doO because it is not well supported on EMC systems: their cache algorithms did not M handle host-based parallel IO well.  This validated our original conclusions,sM but it was already in production, and we have been living with it ever since.   K   The only downtime we had last year in production on our Sales applicationEL cluster was caused by a known failure mode on the Tridents that EMC chose toO ignore such that we cannot claim that any down time was caused by EMC hardware,:; but their engineered solution left this failure point open.   N   We never used any of the "advanced" features in production, making this some2 of the most expensive disks I've ever worked with.  M   The promised NT-based performance tool required static IP addresses for alleJ systems involved (they discovered during installation), and once installed$ never worked more than about 3 days.  J   We where having monthly meeting with them, to review these issues.  TheyJ stopped coming, with no notice, several months ago.  They lost a couple ofO contracts in our company, and decided that they should show up again, asking to  re-bid (no, they couldn't).O  L   With the 3 year warranty expiring, the monthly support cost is going to beL around $30K.  So instead of paying them, we are deploying Fibre with StorageN Works & HSG80 (over 10TB worth), and we expect that EMC will be out of our way by about June.      L What I learned from this is that EMC intentionally found managers who didn'tK understand the issues, but had approval authority, and sold them on all the M wiz-bang features. The fact that most of features don't work easily, with VMSAO or otherwise, was never important until we (the customer) demonstrated that wasN	 the case.X    O EMC might be able to figure out who I work for, but the mangers they originally5O "smoozed" no longer work here (the EMC purchase is one of the reasons), and the L new managers are not even in this state, so they have no one to complain to.J But Lyndon is just starting: I hope we all get the chance to hear how that deployment goes.     Sean       Bill Todd wrote:  N > What at least *seems* to be abundantly clear is that someone landed - hard -K > on Lyndon.  The question now is, was that reaction EMC-instigated, or dido2 > someone in c.o.v. do something foolish, or what? >B > - bill >IB > Lyndon Bartels <lyndon.bartels@childrenshc.org> wrote in message+ > news:3AC48D02.60F8E941@childrenshc.org... I > > It has come to my attention that there are some concerns regarding myO2 > > earlier post regarding EMC Symmetrics and VMS. > >KI > > There are a few things I wish to make abundantly clear to any and alle > > that read these postings.E > >NI > > 1.) The opinions and views I express are strictly my own. They may orV5 > > may not be the opinions and views of my employer.  > >NJ > > 2.) It is my hope that any concerns, questions, or replies to my viewsL > > are directed to me, personally, and NOT through my employer. Personally,K > > I feel that going through my employer without first talking to me is atK > > best unprofessional. > >EF > > 3.) I am in no way responsible for comments made in response to myF > > postings. And if those responses offend anyone, then it is for the< > > concerned parties, not me, to resolve these differences. > >e > >CG > > Now, Regarding the EMC Symmetric hardware and the chronicles postedN	 > > here.  > > L > > 1.) EMC did not 'smooze' management into the purchase. It was a detailedK > > and drawn out process that lead to the selection of EMC as the solutionUC > > to our requirements. Other vendors were included in the review., > >SG > > 2.) While there were problems mentioned in the chronicles, with the L > > exception of one problem, all problems were resolved AND included in theL > > posting. BTW, that problem has a solution, the solution was not known at > > the time of the posting. > > L > > 3.) Three (3) days ago (Wednesday Morning), we successfully accomplishedH > > the first of a two-phase migration of our production data to the EMC > > based storage. > >sK > > 4.) From a technical stand-point, everything we wish to accomplish withiJ > > EMC appears do-able. While some of our objectives are not as elegantly@ > > solved as I would hope, others are in actually more elagant. > > J > > 5.) Nothing in the article I posted is a false-hood. As far as I know.L > > Everything I wrote, is as true as I know it to be. If any information is> > > incorrect or inaccurate, it is not intentional in any way. > >  > >  > > --J > > My opinions are mine and mine alone. They should never be misconstrued > > as a policy of my employer.s > >s > > Lyndon F. Bartelsf   ------------------------------   Date: 7 Apr 2001 08:26:23 -0700A1 From: nothome@spammers.are.scum (Malcolm Dunnett) $ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:l > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK06f0 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as IdB > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. Anm@ updated memory controller was released later which supported 1MB and 4MB boards.i  G >>  This left very little room for applications of any size, but it was E >> the minimum supported configuration.  Take a look at VMS's minimumeD >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywhere'B >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main costssG >> of systems today tend to be people costs rather than hardware costs,y9 >> which just makes memory even cheaper in any TCO sense.   A    We said much the same thing about VMS back then too ( just addoB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kbnH for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookdB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.1   ------------------------------   Date: 7 Apr 2001 08:26:23 -0700s1 From: nothome@spammers.are.scum (Malcolm Dunnett)-$ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:h > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK06t0 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as I B > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. Ant@ updated memory controller was released later which supported 1MB and 4MB boards.a  G >>  This left very little room for applications of any size, but it waslE >> the minimum supported configuration.  Take a look at VMS's minimumtD >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywheretB >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main costswG >> of systems today tend to be people costs rather than hardware costs, 9 >> which just makes memory even cheaper in any TCO sense.e  A    We said much the same thing about VMS back then too ( just add B more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kbsH for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookoB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.a   ------------------------------   Date: 7 Apr 2001 08:26:23 -0700r1 From: nothome@spammers.are.scum (Malcolm Dunnett) $ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:  > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK06=0 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as IoB > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. Ano@ updated memory controller was released later which supported 1MB and 4MB boards.c  G >>  This left very little room for applications of any size, but it wasdE >> the minimum supported configuration.  Take a look at VMS's minimumhD >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywheretB >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main costsnG >> of systems today tend to be people costs rather than hardware costs,t9 >> which just makes memory even cheaper in any TCO sense.t  A    We said much the same thing about VMS back then too ( just addeB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kbnH for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookgB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.e   ------------------------------   Date: 7 Apr 2001 08:26:23 -0700 1 From: nothome@spammers.are.scum (Malcolm Dunnett) $ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:t > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK06 0 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as IeB > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. Ani@ updated memory controller was released later which supported 1MB and 4MB boards.   G >>  This left very little room for applications of any size, but it wasoE >> the minimum supported configuration.  Take a look at VMS's minimumsD >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywhere B >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main costshG >> of systems today tend to be people costs rather than hardware costs,a9 >> which just makes memory even cheaper in any TCO sense.d  A    We said much the same thing about VMS back then too ( just adddB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kbnH for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookeB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.p   ------------------------------   Date: 7 Apr 2001 08:26:23 -0700j1 From: nothome@spammers.are.scum (Malcolm Dunnett)s$ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:S > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK06j0 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as IwB > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. Ann@ updated memory controller was released later which supported 1MB and 4MB boards.   G >>  This left very little room for applications of any size, but it wasdE >> the minimum supported configuration.  Take a look at VMS's minimum D >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywhereiB >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main costs.G >> of systems today tend to be people costs rather than hardware costs,o9 >> which just makes memory even cheaper in any TCO sense.l  A    We said much the same thing about VMS back then too ( just addeB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kbEH for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookoB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.t   ------------------------------   Date: 7 Apr 2001 08:26:23 -0700O1 From: nothome@spammers.are.scum (Malcolm Dunnett)o$ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:i > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK06 0 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as I B > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. Ani@ updated memory controller was released later which supported 1MB and 4MB boards.N  G >>  This left very little room for applications of any size, but it wasoE >> the minimum supported configuration.  Take a look at VMS's minimumoD >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywhereeB >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main coststG >> of systems today tend to be people costs rather than hardware costs,l9 >> which just makes memory even cheaper in any TCO sense.a  A    We said much the same thing about VMS back then too ( just addhB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kboH for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tooktB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.    ------------------------------   Date: 7 Apr 2001 08:26:23 -0700 1 From: nothome@spammers.are.scum (Malcolm Dunnett)h$ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:b > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK06n0 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as InB > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. Anc@ updated memory controller was released later which supported 1MB and 4MB boards.   G >>  This left very little room for applications of any size, but it wasoE >> the minimum supported configuration.  Take a look at VMS's minimum D >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywhere B >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main costsoG >> of systems today tend to be people costs rather than hardware costs,t9 >> which just makes memory even cheaper in any TCO sense.t  A    We said much the same thing about VMS back then too ( just addhB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kboH for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookaB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.    ------------------------------   Date: 7 Apr 2001 08:26:23 -0700p1 From: nothome@spammers.are.scum (Malcolm Dunnett)o$ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:  > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK06.0 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as I B > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. An2@ updated memory controller was released later which supported 1MB and 4MB boards.i  G >>  This left very little room for applications of any size, but it was,E >> the minimum supported configuration.  Take a look at VMS's minimumrD >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywherehB >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main costsgG >> of systems today tend to be people costs rather than hardware costs,s9 >> which just makes memory even cheaper in any TCO sense.   A    We said much the same thing about VMS back then too ( just addtB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kb H for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookpB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.    ------------------------------   Date: 7 Apr 2001 08:26:23 -0700a1 From: nothome@spammers.are.scum (Malcolm Dunnett) $ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:( > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK0610 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as ItB > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. An2@ updated memory controller was released later which supported 1MB and 4MB boards.i  G >>  This left very little room for applications of any size, but it was,E >> the minimum supported configuration.  Take a look at VMS's minimumrD >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywherehB >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main costsgG >> of systems today tend to be people costs rather than hardware costs,s9 >> which just makes memory even cheaper in any TCO sense.   A    We said much the same thing about VMS back then too ( just addtB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kb H for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookpB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.    ------------------------------   Date: 7 Apr 2001 08:26:23 -0700a1 From: nothome@spammers.are.scum (Malcolm Dunnett) $ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:( > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK0610 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as ItB > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. An2@ updated memory controller was released later which supported 1MB and 4MB boards.i  G >>  This left very little room for applications of any size, but it was,E >> the minimum supported configuration.  Take a look at VMS's minimumrD >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywherehB >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main costsgG >> of systems today tend to be people costs rather than hardware costs,s9 >> which just makes memory even cheaper in any TCO sense.   A    We said much the same thing about VMS back then too ( just addtB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kb H for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookpB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.    ------------------------------   Date: 7 Apr 2001 08:26:23 -0700a1 From: nothome@spammers.are.scum (Malcolm Dunnett) $ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:( > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK0610 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as ItB > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. An2@ updated memory controller was released later which supported 1MB and 4MB boards.i  G >>  This left very little room for applications of any size, but it was,E >> the minimum supported configuration.  Take a look at VMS's minimumrD >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywherehB >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main costsgG >> of systems today tend to be people costs rather than hardware costs,s9 >> which just makes memory even cheaper in any TCO sense.   A    We said much the same thing about VMS back then too ( just addtB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kb H for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookpB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.    ------------------------------   Date: 7 Apr 2001 08:26:23 -0700a1 From: nothome@spammers.are.scum (Malcolm Dunnett) $ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:( > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK0610 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as ItB > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. An2@ updated memory controller was released later which supported 1MB and 4MB boards.i  G >>  This left very little room for applications of any size, but it was,E >> the minimum supported configuration.  Take a look at VMS's minimumrD >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywherehB >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main costsgG >> of systems today tend to be people costs rather than hardware costs,s9 >> which just makes memory even cheaper in any TCO sense.   A    We said much the same thing about VMS back then too ( just addtB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kb H for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookpB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.    ------------------------------   Date: 7 Apr 2001 08:26:23 -0700a1 From: nothome@spammers.are.scum (Malcolm Dunnett) $ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:( > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK0610 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as ItB > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. An2@ updated memory controller was released later which supported 1MB and 4MB boards.i  G >>  This left very little room for applications of any size, but it was,E >> the minimum supported configuration.  Take a look at VMS's minimumrD >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywherehB >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main costsgG >> of systems today tend to be people costs rather than hardware costs,s9 >> which just makes memory even cheaper in any TCO sense.   A    We said much the same thing about VMS back then too ( just addtB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kb H for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookpB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.    ------------------------------   Date: 7 Apr 2001 08:26:23 -0700a1 From: nothome@spammers.are.scum (Malcolm Dunnett) $ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:( > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK0610 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as ItB > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. An2@ updated memory controller was released later which supported 1MB and 4MB boards.i  G >>  This left very little room for applications of any size, but it was,E >> the minimum supported configuration.  Take a look at VMS's minimumrD >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywherehB >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main costsgG >> of systems today tend to be people costs rather than hardware costs,s9 >> which just makes memory even cheaper in any TCO sense.   A    We said much the same thing about VMS back then too ( just addtB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kb H for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookpB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.    ------------------------------   Date: 7 Apr 2001 08:26:23 -0700a1 From: nothome@spammers.are.scum (Malcolm Dunnett) $ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:( > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK0610 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as ItB > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. An2@ updated memory controller was released later which supported 1MB and 4MB boards.i  G >>  This left very little room for applications of any size, but it was,E >> the minimum supported configuration.  Take a look at VMS's minimumrD >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywherehB >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main costsgG >> of systems today tend to be people costs rather than hardware costs,s9 >> which just makes memory even cheaper in any TCO sense.   A    We said much the same thing about VMS back then too ( just addtB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kb H for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookpB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.    ------------------------------   Date: 7 Apr 2001 08:26:23 -0700a1 From: nothome@spammers.are.scum (Malcolm Dunnett) $ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:( > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK0610 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as ItB > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. An2@ updated memory controller was released later which supported 1MB and 4MB boards.i  G >>  This left very little room for applications of any size, but it was,E >> the minimum supported configuration.  Take a look at VMS's minimumrD >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywherehB >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main costsgG >> of systems today tend to be people costs rather than hardware costs,s9 >> which just makes memory even cheaper in any TCO sense.   A    We said much the same thing about VMS back then too ( just addtB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kb H for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookpB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.    ------------------------------   Date: 7 Apr 2001 08:26:23 -0700a1 From: nothome@spammers.are.scum (Malcolm Dunnett) $ Subject: Re: VMS-Related: Affordable, Message-ID: <2c$iMWUXdhKV@malvm1.mala.bc.ca>  . In article <87puep7wur.fsf@prep.synonet.com>, 1    Paul Repacholi <prep@prep.synonet.com> writes:( > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK0610 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as ItB > remember, way back then, 256Kb was the MAX supported memory. 386H > terminals to go with it! (or about that many...) It was WAY worse than > you think. >   @    I don't know about V1.0, but we ran V1.6 with 512KB. I recall6 256KB being the minimum supported. The 780 memory rack6 had room for 16 memory boards. I think that originallyD it only supported 64KB boards, giving a maximum memory of 1MB. Later= they came out with 256KB boards - boosting the max to 4MB. An2@ updated memory controller was released later which supported 1MB and 4MB boards.i  G >>  This left very little room for applications of any size, but it was,E >> the minimum supported configuration.  Take a look at VMS's minimumrD >> supported configuration today, and you'll very likely see that noG >> one feels the need to constrain application-available space anywherehB >> nearly this much - because avidly conserving required memory isD >> *relatively* less important compared with the virtues of having aE >> more responsive, more usable system.  And of course the main costsgG >> of systems today tend to be people costs rather than hardware costs,s9 >> which just makes memory even cheaper in any TCO sense.   A    We said much the same thing about VMS back then too ( just addtB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kb H for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookpB longer in those days to design a TKB overlay structure to get yourC program to fit into memory than it took to write the original code.    ------------------------------  $ Date: Sat, 7 Apr 2001 13:44:14 -0400' From: "Bill Todd" <billtodd@foo.mv.com> $ Subject: Re: VMS-Related: Affordable( Message-ID: <9anjla$bth$1@pyrite.mv.net>  7 Paul Repacholi <prep@prep.synonet.com> wrote in messageS' news:87puep7wur.fsf@prep.synonet.com...e+ > "Bill Todd" <billtodd@foo.mv.com> writes:a   ...r  H > > Incorrect.  It might be the *next-to-last* thing you want to do, butB > > the *last* thing you want to do is create a need for more diskG > > accesses, because the relative speed of disk access has lagged even > > > farther behind than the relative speed of memory accesses. >-D > If we restrict it to sequential read/write, then there is no extra > disk access.  G Even that's not necessarily true.  For example, one of the most visible1I performance wins a Unix development environment has is that its temporaryaK files may never even touch the disk, since they're deleted before the cache  needs to flush their data.  K I'll grant that a development environment is not the best place to look foreK *real* value in better performance (even though it may have the side-effectVF of influencing the production platforms that those developers considerI important...), but allowing both frequently-accessed files and files onlyyL accessed briefly before deletion, whether accessed randomly or sequentially,G to avoid disk latencies and disk-bandwidth consumption can have effectseL elsewhere as well.  I do realize that VIOC and more recently XFC help VMS atI least in frequently-accessed read-only situations here - and the interest G expressed in these facilities tends to validate the net utility of suchrE caching, despite whatever overheads it incurs, in some non-negligibleh percentage of sites.  5  By not buffering at all if possible, you cut out themB > cache sweeping and CPU overhead as well, or at least are able to > minimize it.  L As I pointed out, this has significant value only if your system is at leastI often CPU- or memory-bound - a situation which I suspect is not a typicalyH one, but which would of course change one's attitude toward the relative$ value of disk-oriented optimization.   - bill   ------------------------------  $ Date: Sat, 7 Apr 2001 13:49:19 -0400' From: "Bill Todd" <billtodd@foo.mv.com>e$ Subject: Re: VMS-Related: Affordable( Message-ID: <9anjur$cbg$1@pyrite.mv.net>  < Malcolm Dunnett <nothome@spammers.are.scum> wrote in message& news:2c$iMWUXdhKV@malvm1.mala.bc.ca...   ...e  5 > It was a bit of culture shock to move from a PDP-11aI > RSTS system with its constrained program address space ( generally 56kbmJ > for your program and 8kb reserved for system address space ) and limitedE > physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookrD > longer in those days to design a TKB overlay structure to get yourE > program to fit into memory than it took to write the original code.1  L But what fun it was!  And of course if you wrote the code with overlaying inK mind (which might be hard to go back to nowadays but was second-nature backn2 then) it wasn't all *that* bad - at least usually.  K IIRC VMS early-on still supported overlays as an alternative (or perhaps anyI adjunct) to paging.  I always assumed it was because some people realizedRJ that, at least in a memory-constrained environment, giving the applicationE programer more control over the effective 'paging' activity could, at H noticable additional cost in development effort, result in significantly better performance.(   - bill   ------------------------------   Date: 7 Apr 2001 18:03:00 GMTk1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)l$ Subject: Re: VMS-Related: Affordable+ Message-ID: <9ankok$hvv$2@info.cs.uofs.edu>a  ( In article <9al5at$fa7$1@pyrite.mv.net>,*  "Bill Todd" <billtodd@foo.mv.com> writes: |> LK |>            ext2fs on Linux is a conspicuous exception, however, and many = |> people believe using it carries considerably greater risk.M |> r  H You better don your asbestos underwear before saying that. The last timeD I said anything about the shortcomings of the Linux filesystem I was soundly toasted!!d   bill   -- tJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   o   ------------------------------    Date: 08 Apr 2001 02:58:08 +0800, From: Paul Repacholi <prep@prep.synonet.com>$ Subject: Re: VMS-Related: Affordable- Message-ID: <87ae5s7d1b.fsf@prep.synonet.com>a  ) "Bill Todd" <billtodd@foo.mv.com> writes:i  9 > Paul Repacholi <prep@prep.synonet.com> wrote in message ) > news:87puep7wur.fsf@prep.synonet.com...1  8 > > By not buffering at all if possible, you cut out theD > > cache sweeping and CPU overhead as well, or at least are able to > > minimize it.  N > As I pointed out, this has significant value only if your system is at leastK > often CPU- or memory-bound - a situation which I suspect is not a typical J > one, but which would of course change one's attitude toward the relative& > value of disk-oriented optimization.  E Bill, if you have a system with very fast disk IO, try an experiment.R( BACK/PHYS               <dev> NLA0:./SAV( BACK/PHYS/NOCRC/GROUP=0 <dev> NLA0:./SAV  E The first does the whole 9 yrads, and drags every single byte through E the CPU and cache. The second does not to a major extent. Look at CPUrB time and IO rates for the 2., and ote that the file system is nearF totally out of the loop by using a physical backup. It also is a startD at 0 and go, best case for the disk. I think you will be suprised at@ the difference. The second normally runs at near full disk mediaB speed. Hence the comment for fast disks if possible to get the CPU loaded.    -- I< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.a@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------   Date: 7 Apr 2001 14:41:01 -0700A1 From: nothome@spammers.are.scum (Malcolm Dunnett)i$ Subject: Re: VMS-Related: Affordable, Message-ID: <D$4mFL9g$AGw@malvm1.mala.bc.ca>  ( In article <9anjur$cbg$1@pyrite.mv.net>,-     "Bill Todd" <billtodd@foo.mv.com> writes:i > N > But what fun it was!  And of course if you wrote the code with overlaying inM > mind (which might be hard to go back to nowadays but was second-nature backh4 > then) it wasn't all *that* bad - at least usually. > H    Well I suppose it wasn't "rocket science", but you could spend a fairJ bit of time mapping which routine had dependencies on which other routinesH and comparing sizes of routines to map them into appropriate branches of the overlay tree.   L    The worst part was getting code that wasn't designed to fit into a PDP-11N (Fortran simulation programs originally written for mainframes comes to mind),A and trying to design an overlay structure that would make it fit.n  M > IIRC VMS early-on still supported overlays as an alternative (or perhaps anmK > adjunct) to paging.  I always assumed it was because some people realizedoL > that, at least in a memory-constrained environment, giving the applicationG > programer more control over the effective 'paging' activity could, at-J > noticable additional cost in development effort, result in significantly > better performance.e > K     VMS supported TKB for PDP-11 images ( remember, the 11/780 had a PDP-11.J "compatibility mode" built in ). I don't recall anything like overlays for9 native images, but it might have been in there somewhere.e   ------------------------------  % Date: Sun, 08 Apr 2001 20:41:18 +0000 ) From: Christof Brass <brass@infopuls.com>e$ Subject: Re: VMS-Related: Affordable, Message-ID: <3AD0CCEE.A845228B@infopuls.com>   Paul Repacholi wrote:t > + > "Bill Todd" <billtodd@foo.mv.com> writes:p > ; > > Paul Repacholi <prep@prep.synonet.com> wrote in messagey+ > > news:87wv8xa9w0.fsf@prep.synonet.com...  > F > > In most cases, I would agree - but this is exactly what the peopleD > > who *think* that $PUT completion means their record is safely on > > disk seem to be advocating.  > G > It's called reading the manual Bill. Not done what ever the system...m  ; Could it be that porting apps to VMS is mostly done without ? respecting the special I/O requirements? I don't think that's a @ good idea to use this kind of app to rate the quality of the VMS= I/O system. I would like to know if it is possible to achievek= good I/O performance in using the best technique on VMS whichn? probably means not to use C (which should be avoided anyway) asa5 the C RTL seems to be a major problem on VMS wrt I/O.s  H > > > If you use multi buffering (see SET RMS) it happens automatically. > ; > > That form of control is not one I'm familiar with.  ButeG > > read-ahead/write-behind do not IIRC happen 'automatically' when one D > > simply specifies multiple buffers via the RAB MBC mechanism: you- > > have to request them explicitly in ?ROP?.  > E > Oh dear, I feel the C RTL comming on! If you set multi-buffers, your= > will get read-ahead and write-behind, except in one case...s > E > The VAXC RTL specified a buffer count of 1, and that stamped on anyr/ > process or system value. And killed IO speed.e >  [SNIP]  H > But on the cost side, you will pay; you can pay once and have the codeF > done properly for the system or systems or you can save that and pay > every second it runs.  > H > > Incorrect.  It might be the *next-to-last* thing you want to do, butB > > the *last* thing you want to do is create a need for more diskG > > accesses, because the relative speed of disk access has lagged evend> > > farther behind than the relative speed of memory accesses. > D > If we restrict it to sequential read/write, then there is no extraC > disk access. By not buffering at all if possible, you cut out the B > cache sweeping and CPU overhead as well, or at least are able toE > minimize it. If you have multiple accessors, then the case changes,aH > and the costs of VFC, buffers etc can be a big win in some situations. > F > > A few years ago Jim Gray added to his original '5-minute rule' (anG > > Internet search should turn up the newer paper, likely somewhere on0F > > microsoft.com, since that's where he is these days) some estimates? > > of the relative value of avoiding disk accesses in terms ofaG > > instructions executed that bears directly on this issue (unless, ofMA > > course, your system is CPU- or memory-bound - but most of the.B > > applications relevant to the discussion in this thread clearly > > aren't). > - > Ah, Google time. I'll see if I can find it.a  ? Could it be that UNIX (which should be avoided) is good for thei@ careless developer in that it supports the average case for apps> developed by this type of programmer? If we have a look at the; "advantage" that temporary files never hit the disk if theyh? aren't too big and if they're closed shortly enough after theiri> creation it seems that that (intended) usage of a file is some. sort of abuse, at least the wrong abstraction.  > As long as there is a straight forward way on VMS by adjusting7 the process and API call parameters to achieve good I/Oe< performance, to discuss how VMS could be adjusted to support= badly designed and programmed apps which are ported from UNIXi@ (which should be avoided anyway), is trying to solve the problem@ at the wrong end. Instead there should be a simple porting guide= and a tutorial for programmers to VMS I/O performance and forc# using the appropriate abstractions.t   > --> > Paul Repacholi                               1 Crescent Rd.,9 > +61 (08) 9257-1001                           Kalamunda.oB >                                              West Australia 60760 > Raw, Cooked or Well-done, it's all half baked.   ------------------------------   Date: 7 Apr 01 20:47:50 +0000d/ From: phil@pottsoft.demon.co.uk (Phil Ottewell)>K Subject: Web Counter 2.4 with Purveyor Support and distributed lock managerr/ Message-ID: <GO2$o0pZ8H6L@pottsoft.demon.co.uk>'  " -----BEGIN PGP SIGNED MESSAGE-----  M I have just released an update version of Muhammad A Muquit's Web Counter 2.4iH program ported to VMS . Thanks to Neil Rieck, it now works with Purveyor> (http://www.process.com/), as well as the OSU HTTPD web serverL (http://kcgl1.eng.ohio-state.edu/www/doc/serverinfo.html). In addition, NeilN added proper counter data file locking using the VMS Distributed Lock Manager.J I stress tested this simulating 50 users simultaneously accessing the sameM page over a 5 second period and it worked perfectly (my setup was VAX VMS 6.2y and OSU HTTPD 3.9).4  B You can get the new version at my Freeware "VMS Hobbyist's" sites:  5 http://www.pottsoft.demon.co.uk/pds/pds.html#WebCounty   andl  0 http://www.yrl.co.uk/~phil/pds/pds.html#WebCount  M (latter courtesy of Yezerski Roper Ltd. - visit them at http://www.yrl.co.uk/a*  and tell Elliott that "Phil sent you" :-)  L I have updated these sites recently, and the VMS page now has a bibliographyL based on postings by Professor David D. Miller, Arne Vajhoj and others whichN have appeared on comp.os.vms. I added links to Amazon for as many of the books as I had time for.  N I recently downloaded PGP 6.5.8 with a view to porting that, but it looks likeM an awful lot of work, given the lack of GNU autoconf for VMS, so I suspect itoM will be quite some time before I manage that. If anyone else is working on it  then please get in touch.    - - Phil Ottewelli   -----BEGIN PGP SIGNATURE-----  Version: 2.6.3i  Charset: noconvf  @ iQCUAwUBOs9u3gFrKHWv1IPxAQEXnQP3eLqe4L+f+bOebTDotBrjJ5n+rGdElRVM@ cQhA9C6QR/pH2nYQNYGAu2oxF8vdEIJjUbXg6K1ae/sVRX9jM9J0jG7eZ96a1As2@ kdMbBmh5vf++grhdMKaHb9tw202XNqJQf/lJHPeVs+OSZBAfTxK/8tT4zgIdU0J9 67B8jDX/gA== =OmR8e -----END PGP SIGNATURE-----o   ------------------------------  # Date: Sun, 08 Apr 2001 02:04:40 GMTr. From: "Alphaman" <alphaman64@nixspam-home.com>O Subject: Re: Web Counter 2.4 with Purveyor Support and distributed lock manager < Message-ID: <YGPz6.18925$C51.5500980@news1.rdc1.tn.home.com>  : Phil Ottewell <phil@pottsoft.demon.co.uk> wrote in message) news:GO2$o0pZ8H6L@pottsoft.demon.co.uk...r :fK > I recently downloaded PGP 6.5.8 with a view to porting that, but it looks  likeL > an awful lot of work, given the lack of GNU autoconf for VMS, so I suspect itL > will be quite some time before I manage that. If anyone else is working on it > then please get in touch.n >i > - - Phil Ottewell    Phil et. al.  G A co-worker and I have ported and are testing GnuPG v1.04.  It has some3E quirks, but so far we've had great success in encrypting, decrypting, - signing, and verifying against an NT version.   H We are discussing releasing our build to the Q for the next freeware CD.L After we build a kit with both Alpha and VAX exe's, we may attempt to get it1 in the contrib dir at ftp.gnupg.org/pub/gcrypt...e   AaronM --> Aaron Sakovich  http://members.home.net/sakovich/alphaman.html> Make April 15 just another day:        http://www.fairtax.org/ #ifdef TRUEM  #define TRUE 0   #define FALSE 1 #endif   ------------------------------   End of INFO-VAX 2001.196 ************************