sasaki@HARVARD.HARVARD.EDU.UUCP (07/07/86)
I'm not going to deny that VMS is rather arcane at times, but the examples that are being given are ridiculous. Doesn't anyone know about subroutines and functions? Whatever happened to program libraries? I don't know of any experienced programmer (on any system) who doesn't have a bunch or routines that are callable to do things that might be a little complicated to do directly. For instance, way back in VMS version 1.5 I had a sleep function. Yes, it did use strange VMS system calls that I had to look up in the manual to figure out how to call, but after it was written, whenever I wanted to sleep 2 seconds, then I just did a "sleep(2.0)" (I used a floating point number to be able to use fractions of seconds). I have routines to translate logical names, and to read a single character (with and without echo), create character string descriptors for C programs, do quad arithmetic, etc. When I need to do one of these things, I just call one of these routines. If it becomes clear that I need to have a program run faster, and removing the calls will speed things up, then I use my subroutine library routines as examples of how to call a system service, and I do it. No big deal. VMS tries very hard to provide flexibility in the way a programmer can do things. As an example, the Emacs text editor (any implementation) will run a lot more efficiently on VMS if it took advantage of the qiow more fully to read in N printable characters, but to return as soon as it found a control character (normal characters insert, control characters are usually commands). Instead, most implementations read in a single character (no echo) then decide whether the character should be echoed or not (echo it if it should be echoed). Is the tradeoff a reasonable one? Sometimes it is and sometimes it isn't. I'm more than willing to take the time and effort to VMS make an enviroment that I can program in. ---------------- Marty Sasaki uucp: harvard!sasaki Harvard University Science Center arpa: sasaki@harvard.harvard.edu One Oxford Street bitnet: sasaki@harvunxh Cambridge, MA 02138 phone: 617-495-1270
KFL@AI.AI.MIT.EDU.UUCP (07/09/86)
From: sasaki@harvard.harvard.edu (Marty Sasaki)
VMS tries very hard to provide flexibility in the way a programmer can
do things. As an example, the Emacs text editor (any implementation)
will run a lot more efficiently on VMS if it took advantage of the
qiow more fully to read in N printable characters, but to return as
soon as it found a control character (normal characters insert,
control characters are usually commands). Instead, most
implementations read in a single character (no echo) then decide
whether the character should be echoed or not (echo it if it should be
echoed).
I see your point, but this would not be a good idea in an Emacs.
Printing characters normally self-insert, but can be and often are
rebound to be commands. Especially in packages such as RMAIL and DIRED.
And what about expansion of abbreviations? And what happens in the last
column? Or on the last line of the screen? Are you sure VMS will echo
every character in the same place as Emacs would?
In general, echoing should occur as deep as possible. It is better for
your modem to echo than for your terminal to do so. It is even better for
the host to do so. It is best of all for the applications program on the
host to do so.
This is one of my main problems with VMS. Getting it out of the way.
I want to handle things myself. This is not because I like low level
programming. I don't. It is because VMS so often does things in ways
I don't like. For instance:
1) Uploading files from word processors. The WPs often want to send
thousands of characters none of which happen to be CRs. VMS is the
only OS I know of which has a problem with this. I don't think this
is complicated or hairy. I just want to do a read. I don't care if
it is done in characters, words, lines, or whatever. So why do I have
to use SYS$QIOW? I don't mind funny FORMAT statements or unusual
arguments to OPEN. I *LIKE* the VMS Fortran extensions. But suddenly,
it isn't Kansas anymore. The manual is talking about pointers to
double longwords in P0 space. It doesn't say a word about what lines
to put in my FORTRAN program. It might be nice learning MACRO
someday, but not when I've got a deadline.
a) A Wizard gives me a character-at-a-time FORTRAN callable
input routine. I use it to upload the WP files through a
1200 baud modem. This is too fast for the 11/785, so it sends
^S. The WP doesn't recognize ^S so it keeps sending. Disaster.
b) With the 11/785 all to myself, I am later able to upload it.
It uses massive amount of CPU and DIO.
c) A couple years later. Same problem, different solution. I
write a program in Pascal on a PC. The program requires no
internals or escape to assembler, just plain (Turbo) Pascal.
I am able to upload the WP files at 4800 baud just fine. After
inserting CRs every few dozen characters, it is easily uploaded
to the 11/785. Why should this be much easier and faster on
a micro?
2) Same problem (sort of). I want to write a simple word processing
program without it falling down in flames if the user doesn't remember
to press CR every few words.
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. Wizard: "DCL will turn it to uppercase,
expand what's after the apostrophe into any logical name match, and
discard what's after any exclamation point." Me: "Cute. How do I
turn it off." Wizard: "Turn it off...?"
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!"
5) Most of our users had non-VT100 compatible terminals. No VMS
programs support them. I was willing to write a sort of CRTSTY
or PTY type program to map VT100 sequences into the equivalent
sequences on the Telerays, LearSieglers, H19s, etc. But there
doesn't appear to be any way to do this.
6) I have had to travel miles just to see what a user was typing that
VMS doesn't like. Why isn't there a utility, or some documented
way to write one, that lets a system manager watch what is on a
user's screen?
7) The Emacs we had, like all good Emacses, allows you to enter OS
commands in a seperate window. This would have been a lot more
useful if VMS had recognized the process as an interactive one
rather than batch. I suppose it is possible that this would be
easy, and the Emacs implementors messed up. Somehow I doubt it.
8) DUMP formats its listing for 80 columns if you view it on an 80
column terminal. If its output it directed at a printer or a
file, it is formatted for 132 columns. Cute feature. But how
do you turn it off? I want to direct it at a file for study on
an 80 column terminal. How do I get it to format 80 columns in
a file? It took me three years to figure out how.
Sorry this is so long. Just got carried away.
...Keithgarry@TCGOULD.TN.CORNELL.EDU.UUCP (07/11/86)
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)
KFL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU.UUCP (07/11/86)
From: <JMS@ARIZMIS.BITNET> (A Virtually Vegetal Nonentity)
In any case, the one problem I wanted to point out was your initial
remarks about echoing. FROM AN APPLICATION'S POINT OF VIEW, you're
right. Echo back at the host; hell, it knows the best stuff to
echo anyway.
However, as a network architect, I shudder whenever anyone talks about
doing something like that.
Making the packetizing invisible to the program should be done in the
OS, just as making the details of how virtual memory is mapped into
physical memory is mercifully taken care of. I mean, this is why OS's
cost so much, right?
...Keith