Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utcs!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!TCGOULD.TN.CORNELL.EDU!garry From: garry@TCGOULD.TN.CORNELL.EDU.UUCP Newsgroups: mod.computers.vax Subject: Re: VMS and programmer unfriendliness Message-ID: <8607110129.AA02840@tcgould.tn.cornell.edu> Date: Thu, 10-Jul-86 21:29:38 EDT Article-I.D.: tcgould.8607110129.AA02840 Posted: Thu Jul 10 21:29:38 1986 Date-Received: Sat, 12-Jul-86 06:20:16 EDT References: <[AI.AI.MIT.EDU].67100.860708.KFL> Sender: jwl@ucbvax.BERKELEY.EDU Organization: Cornell Engineering && Flying Moose Graphics Lines: 104 Approved: info-vax@sri-kl.arpa This was an interesting list of VMS complaints, contributed by someone who's obviously used VMS a lot, so I'm taking a minute to respond. If you don't like shooting the breeze about VMS, you should skip on to the next message. [One general comment: Many people this last week have been castigating the "need to use assembler, oh my!" No, I'm not going to tell you that assembler is good for you. I'm going to tell you there's nothing you need it for. Easy system stuff I do in Fortran, hard stuff (device drivers &c.) I used to do in PL/1 and Bliss, and now use C. I use assembler only for shareable image transfer tables - obscure! Kernel mode routines that pass things in registers usually require Bliss. User mode stuff usually just requires the right include files, which DEC has gradually been supplying more and more of in the various languages. Forget this assembler nonsense!] In a recent article Keith Lynch said: >1) Uploading files from word processors... VMS prefers record I/O to stream I/O. In the case of terminal input, this means you gotta use QIO's. Even if they're ugly with umpteen arguments and you don't wanna. In this case, you should do a QIO that asks for 'n' characters or a terminator, whichever comes first. Make sure 'n' is significantly less than the type-ahead buffer size (look in Sysgen to find out for sure what that is.) If you're on your own uVax, you can get away with single-character I/O, but VMS is indeed lousy at fielding jillions of tiny I/O requests. >2) ...flames if the user doesn't remember to press CR every few words. Do it right and call QIO, or use SMG or curses. >3) I want to write a SEND program. I easily wrote one where you can > say SEND TXA0: "Hello there! Can't talk long...". But I want it > to not require the quotes... Define it as a foreign command. Stick a trailing quote mark on the definition. >4) Some users are used to using ^H (backspace) to delete mistyped > characters. Some are stuck on terminals where DEL is a shifted key, > or isn't there at all. DEC: "Tough!" I vote with DEC and for less entropy in the universe, in this case. Having the option doesn't seem worth the hassle of finding the right command to invoke it. >5) Most of our users had non-VT100 compatible terminals... DEC seems to be convinced you should buy DEC terminals or at least ANSI-standard ones. There's a termcap-equivalent now, but unfortunately (for the sake of speed) the system editor don't use it. Me, I've got vt200's and I love speedy and clever editors. >6) ...that lets a system manager watch what is on a user's screen? Sounds like a good idea. At present, SET HOST/LOG is a pretty dumb way of getting a session transcript. >7) ...allows you to enter OS commands in a seperate window... I'm not familiar with VMS Emacs. TPU at least is happy to let you do this. >8) DUMP formats its listing for 80 columns if you view it on an 80 > column terminal... But how do you turn it off? ... VMS got a whole lot more consistent with version 4 about making sure that each switch is legal and spelled the same on every command where that switch would be a reasonable thing to have. They missed a few, and the /WIDTH= on DUMP is one of them. --------------------------------------------------------------------- The poster missed the classic VMS deficiency: there's lots of cute things you can do that involve spawning processes, and VMS is *lousy* at spawning. The basic problem is that process creation in VMS version one was a kluge, involving writing a fake process header out to disk and kicking the swapper to bring it in. SLOW. They've never gotten around to doing it right (all in memory). Also, the DCL spawn command tries to push lots of info through a tiny mailbox to the new process. Context switches and scheduling interrupts galore. DUMB! Some kind of shared-memory hack (within DCL, amongst all processes that constitute the same "job") would bring joy to my heart and speed to the system. At least they should use a much bigger mailbox! While I'm at it, disk priority scheduling is lousy too. A disk-bound batch job can make your interactive process crawl, even if the batch job is at arbitrarily lower priority. And while I'm on priority scheduling, interactive graphics processes can slow things down mightily too, because of the automatic priority boosts after any I/O operation (this one can be overcome by changing process priorities tho.) I wish there were a switch on the Sysgen Connect command that would let me can the priority boost mechanism for that device. As long as I'm complaining, I might as well mention: quiescent jobs that are not getting any time-slices, or which are terminal bound, NEVER EVER give up working set memory pages to things which deserve it more. All the fancy working set adjustment business applies ONLY to jobs which are actively computing. More wishes/complaints about VMS, anybody? -- garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu)