1 INFO-VAX	Sat, 07 Apr 2001	Volume 2001 : Issue 195       Contents: Re: Another Win for OpenVMS  Re: Another Win for OpenVMS  Re: Another Win for OpenVMS   Re: DCL question: piping command  Re: DCL question: piping command  Re: DCL question: piping command DEC Server software question. Flipping from big-endian to little endian in C2 Re: Flipping from big-endian to little endian in C Re: FTP hijacking of VMS sitesA Re: How do I redefine the alias between SYSCOMMON and VMS$COMMON?  PC #1 SECURITY SOFTWARE  1516 ( Re: Seeking CD-R/CD-RW SCSI INQUIRY data 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   F ----------------------------------------------------------------------  # Date: Sat, 07 Apr 2001 07:35:56 GMT  From: Dirk Munk <munk@home.nl>$ Subject: Re: Another Win for OpenVMS' Message-ID: <3ACEC35A.C39ADBA4@home.nl>   L It is not Netscape that is the problem, but the junk that is produced by web programmers or their tools. N Internet Exploder accepts all kind of poorly written HTML code, and presents aO readable page. Netscape V4.x  is a bit more critical about what it will accept,  and Netscape V6 even more.N If everyone would stick to the rules for HTML, everything would be fine and weN would not have problems. A good way to tell if a page has good HTML code is toL use the Opera browser I have been told. If it works with Opera, it will workM with any browser. And of course there are syntax checkers available that will O check the HTML code for errors. Now if web designers would act professional and N use these tools so that their web pages work on any browser on any platform as; was the intent of HTML, we would not have so many problems.    "Terry C. Shannon" wrote:    > 
 > > <SNIP> > > J > > Oh heck, this seems to be a symptom of old browser syndrome.  NetscapeH > > 4.03 had an expired Verisign certificate, which caused a warning but+ > > usually allows a connection after that.  > I > Ah, Netscape... the browser for crash test dummies. I used to use it on N > Windoze, but got sick of the multiple daily browser crashes and went over to@ > Internet Exploder. At least it is more reliable than Netscape.   ------------------------------   Date: 7 Apr 2001 11:31:01 -0000 4 From: Doc.Cypher <Use-Author-Address-Header@[127.1]>$ Subject: Re: Another Win for OpenVMS6 Message-ID: <20010407113101.29087.qmail@nym.alias.net>  " -----BEGIN PGP SIGNED MESSAGE-----  4 On Sat, 07 Apr 2001, Dirk Munk <munk@home.nl> wrote:M >It is not Netscape that is the problem, but the junk that is produced by web  >programmers or their tools.O >Internet Exploder accepts all kind of poorly written HTML code, and presents a P >readable page. Netscape V4.x  is a bit more critical about what it will accept, >and Netscape V6 even more. O >If everyone would stick to the rules for HTML, everything would be fine and we O >would not have problems. A good way to tell if a page has good HTML code is to M >use the Opera browser I have been told. If it works with Opera, it will work N >with any browser. And of course there are syntax checkers available that willP >check the HTML code for errors. Now if web designers would act professional andO >use these tools so that their web pages work on any browser on any platform as < >was the intent of HTML, we would not have so many problems.  I I have to agree. However, it would seem that everyone and their dog is an 0 HTML expert. http://www.quizpeople.com/doobydog/  K At least this isn't one of those pages where the designer thought that HTML  was only for layout control.   Personally I liked this one...  6 http://cold-dead-fish.com/reviews/worst_of_the_web.htm     Doc.   -----BEGIN PGP SIGNATURE-----  Version: 2.6.2  @ iQEVAwUBOs5KcsriC3SGiziTAQGKugf+KWCJgcc1k7n3PyfD1RxBgs64iZephlYw@ Ey0UQ4DzDBY1WpBtFQ4CLmuyk5+SuJz+WK3cCZKTcZ3u93pV6591K2wAM68z5/Lj@ Y8QVHP+CanSd23MxLbpDqVdBZFX4l+IM2frEjZbZGGKqmzioyMZcPpZvQBVWoXTN@ lexA3OI5DdRpuvWu+ybXwh0UESx5icEz0hq2CaL4gqJkSP3pDEh/jcpY1qG1UvJ7@ HMZPZhK1j0kABM9sS6mD1JnYeCaH025i4eidWns1+vslz6azAsSo7O2JP1or+IDG8 W7pmy7vu/u2JOoNXDDyLKIjgZ7yPEJorkGOQ74lQZ9gUtr03/6jYjw== =3B+Y  -----END PGP SIGNATURE-----    ------------------------------    Date: 07 Apr 2001 21:37:04 +0800, From: Paul Repacholi <prep@prep.synonet.com>$ Subject: Re: Another Win for OpenVMS- Message-ID: <87d7ao96gv.fsf@prep.synonet.com>   6 Doc.Cypher <Use-Author-Address-Header@[127.1]> writes:    > Personally I liked this one... > 8 > http://cold-dead-fish.com/reviews/worst_of_the_web.htm   Droll, very droll.  E I'd hate to have to go a 'worst of the web'. Not know where to start, # and do know that it will never end.    --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------  # Date: Sat, 07 Apr 2001 11:39:06 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) ) Subject: Re: DCL question: piping command 0 Message-ID: <009FA2BE.4A1E2D5A@SendSpamHere.ORG>  I In article <3ACE9E51.7DB52CD4@home.com>, Andy <kicsi2l8@home.com> writes: A >thanks for the help,....I got it working. I have @home and using G >netscape. Your post I guess didnt come through for a while, but i have  >it now. > 
 >this worked:  >$ PIPE SHOW QUEUE | -C >  SEARCH SYS$PIPE STOPPED/OUTPUT=retain.tmp ; PRINT/QUEUE=whatever  >retain.tmp  > ; >I even added del retain.tmp;* to delete it after printing.  > H >Thanks again! You'll see my posts here more often. This NG is a whealth
 >of info!! >   J The above command you've concocted is a quick-and-dirty that will probablyI work for you but I'd rather -- if it were my systems -- follow Hoff's ad- , vice.  F$getqui(...) in a command procedure. --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              O city, n., 1. a place where trees are cut down and streets are named after them.    ------------------------------  % Date: Sat, 07 Apr 2001 08:16:01 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> ) Subject: Re: DCL question: piping command , Message-ID: <3ACF04FC.E009859A@videotron.ca>   > >$ PIPE SHOW QUEUE | -E > >  SEARCH SYS$PIPE STOPPED/OUTPUT=retain.tmp ; PRINT/QUEUE=whatever 
 > >retain.tmp  > > = > >I even added del retain.tmp;* to delete it after printing.   F You should instead use PRINT/DELETE retain.tmp. This will take care ofM deleting your file once it has completed printing. Remember that printing may L actually happen hours later if the printer is turned off, without paper etc.K If you delete the file prematurely, the print job will print a page stating , that the printed file doesn't exist anymore.   ------------------------------  # Date: Sat, 07 Apr 2001 12:23:38 GMT 1 From: CSABA  HARANGOZO   <csabah@zipworld.com.au> ) Subject: Re: DCL question: piping command 9 Message-ID: <eFDz6.1228$CN.207059@nostril.pacific.net.au>    Andy <kicsi2l8@home.com> wrote: B > thanks for the help,....I got it working. I have @home and usingH > netscape. Your post I guess didnt come through for a while, but i have	 > it now.    > this worked: > $ PIPE SHOW QUEUE | - D >   SEARCH SYS$PIPE STOPPED/OUTPUT=retain.tmp ; PRINT/QUEUE=whatever > retain.tmp  < > I even added del retain.tmp;* to delete it after printing.  ? 	Use "PRINT/DELETE/QUEUE=whatever retain.tmp" and there will be * 	no need for the "del retain.tmp;*" bit... 							Csaba  I    ---------------------------------------------------------------------- E    * Csaba I. Harangozo     |    'To err is human', said the hedgehog E    * csabah@zipworld.com.au |           as he dismounted a wirebrush. I    ---------------------------------------------------------------------- ;    EARTH::AUSTRALIA:[SYDNEY]HARANGOZO.CSABA;1, delete? [N]:    ------------------------------  $ Date: Sat, 7 Apr 2001 11:17:57 -04003 From: "Patrick Massey" <pmassey@lakecountyohio.org> % Subject: DEC Server software question ) Message-ID: <9anb2v$lp8$1@iac5.navix.net>    Hello,H I've recently installed a DS900TM and found that only the first 16 of 32L ports work.  The software it's loading WWENG2 ver 1.1a makes it think it's aJ DS700.  I really need to get the other 16 ports working.  Does anyone knowK where I can find an updated loadfile?  I've contacted Compaq and the vendor 8 I ordered the part from, neither have been very helpful. Thanks in advance.   -Pat Massey    ------------------------------  % Date: Sat, 07 Apr 2001 04:32:02 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 7 Subject: Flipping from big-endian to little endian in C , Message-ID: <3ACED07F.4CA8A637@videotron.ca>  L 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.    N If I have a entire row of 4800 big-endian signed shorts in consecutive memory,K what would be the most efficient to flip all of them to litte-endian ? (VAX  architecture, DEC-C).     0 And while I am at it, a question on descriptors:  ' I used to declare descriptors such as : 4 $DESCRIPTOR(my_time_desc,"dd-mmm-yyyy hh:mm:ss.mm");  K and in the program, my_time_desc.dsc$a_pointer was filled with actual data. L However, since DEC-C, the default ahs been to made the string in $DESCRIPTORK 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 14:12:35 GMT ' From: jmcmahon38@home.com (Jim McMahon) ; Subject: Re: Flipping from big-endian to little endian in C % Message-ID: <3acf1e19.562724040@news>   . JF Mezei <jfmezei.spamnot@videotron.ca> wrote:  M >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.  > O >If I have a entire row of 4800 big-endian signed shorts in consecutive memory, L >what would be the most efficient to flip all of them to litte-endian ? (VAX >architecture, DEC-C). >  > 1 >And while I am at it, a question on descriptors:  > ( >I used to declare descriptors such as :5 >$DESCRIPTOR(my_time_desc,"dd-mmm-yyyy hh:mm:ss.mm");  > L >and in the program, my_time_desc.dsc$a_pointer was filled with actual data.M >However, since DEC-C, the default ahs been to made the string in $DESCRIPTOR L >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 ?    F I'm newly back to VAX after a 12 year absence so I don't know if thereE is a better way, but I've recently just had to fix a bug in some code D where the exact same mechanism was used to fill in descriptor values at run-time.    ? The problem:  strings were either truncated or padded with null 
 characters.     A The reason:  original coder didn't update the length field of the D descriptor structure to account for it's actual resultant length, if6 that was different that the size initially declared.    D Just a heads up if you hadn't thought of it, since I just ran across
 it myself.    6 Being ordinary and nothing special is a full-time job.. jmcmahon38@home.com (Jim McMahon in real life)   ------------------------------  % Date: Sun, 08 Apr 2001 09:36:59 +0000 ) From: Christof Brass <brass@infopuls.com> ' Subject: Re: FTP hijacking of VMS sites , Message-ID: <3AD0313B.793B31EA@infopuls.com>   Jim Becker wrote:    [SNIP]   > A > Using passwords is in some ways even less secure than anonymous 7 > access. Anonymous access doesn't blast an unencrypted D > username/password pair over the Internet. Anonymous access doesn'tE > require you to send usernames and passwords to people who might not D > protect the passwords very well. If you don't do anything to avoidD > easily guessed usernames and passwords, you won't be all that safeG > anyway. Basically, password-controlled ftp is like a conventional car H > lock. Anyone who's determined or skilled can get past it, but at least# > it deters the casual opportunist.  >    [SNIP]   >  > -- > Jim Becker- > The Urban Institute (http://www.urban.org/) ) > Encompass (http://www.encompassus.org/) 0 > ESILUG (http://encompasserve.org/lugs/esilug/)  @ The advantage of having each user to authenticate him/herself is? that you could track who is careless about keeping the password < safe. Moreover you could adjust the disk quota according the> needed upload space that abuse is restricted to the account in	 question.    ------------------------------  % Date: Sat, 07 Apr 2001 11:12:59 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)J Subject: Re: How do I redefine the alias between SYSCOMMON and VMS$COMMON?L Message-ID: <rdeininger-0704011113000001@user-2iveb27.dialup.mindspring.com>  < In article <87itkic82x.fsf@prep.synonet.com>, Paul Repacholi <prep@prep.synonet.com> wrote:  6 > rdeininger@mindspring.com (Robert Deininger) writes: > L > > I don't remember all the icky little details any more.  I sort of recallL > > than VMS$COMMON was an alias, and was a subdirectory of [000000.SYSE] or > > some such. > C > That is the sign of a VMS update than did not complete correctly. : > Seems for some reason, it got part way through, then???? > F > Sys$common is put into syse, a new sys$common built then all syse isC > nuked after a boot into the new standard root. But this one seems : > to have been interupted, or the roots resored from syse.  F Not at all unlikely.  Whatever happened, it was years before I saw theJ machine. I was convinced at the time the original sickness happened duringJ an upgrade _other_ than the last one.  I found the strangeness while goingE into the VMS 5.5-2 --> 6.x --> 7.1 upgrade.  There had been a 5.5 --> @ 5.5-2 upgrade previously; before that was lost to mortal memory.  I Backups were not in the best of shape back then.  I know a data revcovery J service had been used around that machine (unsuccessfully) at least twice.   --   Robert Deininger rdeininger@mindspring.com    ------------------------------  # Date: Sat, 07 Apr 2001 09:46:33 GMT  From: rboyer@secure.co.uk & Subject: PC #1 SECURITY SOFTWARE  1516, Message-ID: <ZlBz6.6101$s02.5044@NewsReader>  a You must have read all the reports,  E Eliminator is undoubtably the best software on the market.   C You can not safely delete files on your computer without it........   N Do you want your family or the authorities to find out what sites you surfed? , Hidden files are kept on your comuter !!!!!!D For example.......... every click you make on Windows 98 Start Menu W is logged and stored for ever on a hidden encrypted database within your own computer?    ) That is not fair.  Who is playing dirty ?   5 View all those files now and delete them forever with 3 http://www.evidence-eliminator.com/go.shtml?A654845   C fhvvvdcteejevcbztcdttjouvwcjikzqoqohsyizwbvjgwrzxcpcpjwvrkhmpruhjww    ------------------------------  # Date: Sat, 07 Apr 2001 07:57:22 GMT  From: Dirk Munk <munk@home.nl>1 Subject: Re: Seeking CD-R/CD-RW SCSI INQUIRY data ' Message-ID: <3ACEC85C.CFC6414B@home.nl>    Hoff,    We all see your point that every manufacturer is making his own extensions etc. for CD-R/RW drives. But on the other hand not every  CD-Rom drive works with VMS either. As far as I know Digital / Compaq has been using rebadged Toshiba drives for a long time now in w Alpha systems, so I suppose Compaq has some agreement with Toshiba that their drives confirm to certain specifications.    I can imagine that Compaq (incl. the Billybox division) makes a deal with one or two manufacturers of CD-R and DVD-R (!!) writers to coperate in the development of the SCSI specific parts of such devices. AFAIK the firmware of Compaq DLT drives is also changed / improved, and is not the same as the standard Quantum DLT drives. Of course I am not asking for a for a rebadged drive for three times the normal price :-)).   Regards,   Dirk   ------------------------------    Date: 07 Apr 2001 19:50:04 +0800, From: Paul Repacholi <prep@prep.synonet.com>$ Subject: Re: VMS-Related: Affordable- Message-ID: <87puep7wur.fsf@prep.synonet.com>   ) "Bill Todd" <billtodd@foo.mv.com> writes:i  9 > Paul Repacholi <prep@prep.synonet.com> wrote in message ) > news:87wv8xa9w0.fsf@prep.synonet.com...r  D > In most cases, I would agree - but this is exactly what the peopleB > who *think* that $PUT completion means their record is safely on > disk seem to be advocating.l  E It's called reading the manual Bill. Not done what ever the system...e  F > > If you use multi buffering (see SET RMS) it happens automatically.  9 > That form of control is not one I'm familiar with.  ButME > read-ahead/write-behind do not IIRC happen 'automatically' when oneAB > simply specifies multiple buffers via the RAB MBC mechanism: you+ > have to request them explicitly in ?ROP?.-  C Oh dear, I feel the C RTL comming on! If you set multi-buffers, you>; will get read-ahead and write-behind, except in one case....  C The VAXC RTL specified a buffer count of 1, and that stamped on anyu- process or system value. And killed IO speed.r  ; > The key word is 'relatively'.  VMS V1 was designed to runHD > (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK06/ > drives, though it might have required RK07s).e  = I don't know if anyone has a V1 SPD around to check, but as Ie@ remember, way back then, 256Kb was the MAX supported memory. 386F terminals to go with it! (or about that many...) It was WAY worse than
 you think.  F >  This left very little room for applications of any size, but it wasD > the minimum supported configuration.  Take a look at VMS's minimumC > supported configuration today, and you'll very likely see that nolF > one feels the need to constrain application-available space anywhereA > nearly this much - because avidly conserving required memory is C > *relatively* less important compared with the virtues of having abD > more responsive, more usable system.  And of course the main costsF > of systems today tend to be people costs rather than hardware costs,8 > which just makes memory even cheaper in any TCO sense.  F Yes, it is the down stream costs that totally dominate, and the bodies make up most of that.w  F But on the cost side, you will pay; you can pay once and have the codeD done properly for the system or systems or you can save that and pay every second it runs.r  F > Incorrect.  It might be the *next-to-last* thing you want to do, but@ > the *last* thing you want to do is create a need for more diskE > accesses, because the relative speed of disk access has lagged even < > farther behind than the relative speed of memory accesses.  B If we restrict it to sequential read/write, then there is no extraA disk access. By not buffering at all if possible, you cut out thed@ cache sweeping and CPU overhead as well, or at least are able toC minimize it. If you have multiple accessors, then the case changes, F and the costs of VFC, buffers etc can be a big win in some situations.  D > A few years ago Jim Gray added to his original '5-minute rule' (anE > Internet search should turn up the newer paper, likely somewhere ontD > microsoft.com, since that's where he is these days) some estimates= > of the relative value of avoiding disk accesses in terms ofrE > instructions executed that bears directly on this issue (unless, of ? > course, your system is CPU- or memory-bound - but most of thes@ > applications relevant to the discussion in this thread clearly
 > aren't).  + Ah, Google time. I'll see if I can find it.o   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------   Date: 7 Apr 2001 08:26:23 -0700o1 From: nothome@spammers.are.scum (Malcolm Dunnett)1$ 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:5 > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK06G0 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as I3B > 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. An @ 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 wasCE >> 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 anywhereoB >> 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 costscG >> of systems today tend to be people costs rather than hardware costs,o9 >> which just makes memory even cheaper in any TCO sense.Y  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 56kblH for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tooksB 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.X   ------------------------------   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:F > < >> The key word is 'relatively'.  VMS V1 was designed to runE >> (marginally) in 256 KB of memory (and IIRC using just 2 30 MB RK06m0 >> 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. Anm@ updated memory controller was released later which supported 1MB and 4MB boards.h  G >>  This left very little room for applications of any size, but it wasaE >> 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 anywhereaB >> 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,a9 >> which just makes memory even cheaper in any TCO sense.o  A    We said much the same thing about VMS back then too ( just adduB 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 tookSB 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)t$ 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 RK06m0 >> drives, though it might have required RK07s). > ? > I don't know if anyone has a V1 SPD around to check, but as IcB > 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 wasnE >> 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 costs@G >> of systems today tend to be people costs rather than hardware costs,a9 >> which just makes memory even cheaper in any TCO sense.e  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 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 tookCB 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.v   ------------------------------   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:  > < >> 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 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. An @ 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 wasiE >> 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 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 costswG >> of systems today tend to be people costs rather than hardware costs,d9 >> which just makes memory even cheaper in any TCO sense.r  A    We said much the same thing about VMS back then too ( just addlB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kbrH for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often tookkB 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: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 RK06r0 >> 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. An,@ 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 wassE >> 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 costs0G >> of systems today tend to be people costs rather than hardware costs,T9 >> which just makes memory even cheaper in any TCO sense.   A    We said much the same thing about VMS back then too ( just addbB more memory ). It was a bit of culture shock to move from a PDP-11G RSTS system with its constrained program address space ( generally 56kbiH for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often took8B 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.n   ------------------------------   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:c > < >> 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 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. An @ 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 wassE >> 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 anywherepB >> 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 costsdG >> of systems today tend to be people costs rather than hardware costs,p9 >> which just makes memory even cheaper in any TCO sense.d  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 56kbtH for your program and 8kb reserved for system address space ) and limitedC physical memory ( the PDP 11/40 maxed out at 128KB ). It often took:B 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.-   ------------------------------   End of INFO-VAX 2001.195 ************************