Info-Vax-REQUEST@KL.SRI.COM (Ramon Curiel) (05/02/87)
Info-Vax Digest Saturday, 2 May 1987 Volume 0 : Issue 5 Today's Topics: Wanted: NEWS SOURCES for native VMS Re: vi written in TPU Re: vi written in TPU Re: Saving the commands in the Recall buffer Re: Sending mail from a remote DECnet task (Problems) Re: compute bound jobs & terminal response time Re: VAXBI-Ethernet controller Re: Hardcopy terminal with video output ? Tape REWIND on file closes OLD BUSINESS - YORK BULLETIN SOFTWARE ---------------------------------------------------------------------- Date: 29 Apr 87 14:20:36 GMT From: soma!nuchat.UUCP!abbadon@seismo.CSS.GOV (David Neal) Subject: Wanted: NEWS SOURCES for native VMS >From watching the flames on mod.computers.vax about whose mail system is the best, can I assume usenet mail (NEWS) has been ported to NATIVE VMS? If so, could anyone who has the sources please pass them along? Porting the Unix V version to VMS 4.5 looks pretty gruesome from here. Thanks in advance, David Neal ...!killer!uhnix!nuchat!david or Voice (713) 871-9222 ------------------------------ Date: 30 Apr 87 14:19:11 GMT From: vax1!george@cu-arpa.cs.cornell.edu (George R Boyce) Subject: Re: vi written in TPU Please, no more editor wars. Lets stop it now before it gets started again. (But I would like to just add that (gnu) emacs has a vi mode for those that prefer that editor but occasionally want the "power" of emacs. :-) ------------------------------ Date: Thu, 30 Apr 87 08:55:05 PDT From: blia.UUCP!ted@cgl.ucsf.edu (Ted Marshall) Subject: Re: vi written in TPU I too dislike vi's explicit insert/noinsert modes. However, I recognize that this is mainly because most of the screen editors I have used do not have this feature. I personally would rather use special keys (arrows, "cut", "move by screen") on a keypad. On the other hand, versions of emacs that are not set up for a keypad and thus require control characters for just about everything are also not real comfortable. Just personal opinion. However, what drives me totally crazy about vi is the fact that New-line is treated specially. I am use to editors where I can backup over the beginning of a line or rub-out a New-line while in insert mode. I think that it is very funny that the major screen editor for VMS, a system which uses records for i/o, treats a NL (end-of-record) as just a character and the screen editor for UNIX, which uses byte streams for i/o, treats NL as a special hard line break. ------------------------------ Date: Fri, 1 May 87 14:16 N From: <SCHOMAKE%HNYKUN53.BITNET@wiscvm.wisc.edu> Subject: Re: Saving the commands in the Recall buffer Richard Steinberger <STEINBERGER@KL.SRI.COM> writes: >Does anyone have any code that saves the commands in the recall buffer so >they will or can be restored at the next login? It would be convenient >if the last 20 commands I typed were always present even if I have logged >out in the interim. Let us look at this problem in a more general way: how can we save the total working environment (LOGICAL & SYMBOL tables, DEFINED KEYS, RECALL buffer) and restore it fast at a later login session? In interpreted-language environments, there is often such a mechanism available (Lisp, Apl). The scenario would be: 1) saving the relevant data of the current user (=root) process in a binary file on logout of this process. 2) On a later login we say (e.g.) Username:JONSON/COMM=RESTORE_LOGIN.COM 3) The things that are not already defined are restored. The restoring could be fast since no DCL interpreting has to be done. Is this feasible? Could there be dangerous consequences? * ^^^^^ KKKKKUUUUNNNNN KKK UUUU NNNN Lambert Schomaker K UUUU NNN SCHOMAKE@HNYKUN53.BITNET KKK UUUU NN Nijmegen, The Netherlands. KKKKK UU N ------------------------------ Date: 1 MAY 1987 08:29:35 EST From: <LEICHTER-JERRY@YALE.ARPA> Reply-to: <LEICHTER-JERRY@YALE.ARPA> Subject: Re: Sending mail from a remote DECnet task (Problems) ...[T]he following file: $! TESTMAIL.COM $ MAIL NLA0: ONODE::MACPHEDRAN/SUBJ="TEST OF MAIL" $ EXIT It will send me a null message (which I intended) when run as a) a regular command procedure ($ @MAILTEST); b) a subprocess ($ SPAWN/NOWAIT/INPUT=TESTMAIL.COM/OUTPUT=TT:); c) a batch process ($ SUBMIT/NOPRINT TESTMAIL.COM); but does nothing when run as a network task ($ TYPE ONODE::"0=MAILTEST" {I have a proxy across}). The process starts up MAIL, but does not send anything, and appears to `hang'. Does anyone know why this happens, You've run into an age-old "gotcha'" with MAIL: The single MAIL.EXE image implements both the "user agent" and the "delivery agent" sides of the MAIL-11 protocol. The problem is that it decides which role to play by testing the mode of the process it is running in. When MAIL is started up in a network process, it decides to act as a delivery agent. Hence, what you see is MAIL waiting patiently for someone to talk MAIL-11 to it. and if there is a way around it, other than spawning off a subprocess, or submitting a batch job from my network task? You've enumerated all the alternatives I know of. (Well, I guess you could talk MAIL-11, but that hardly seems worth the trouble!) -- Jerry ------------------------------ Date: 1 MAY 1987 08:38:17 EST From: <LEICHTER-JERRY@YALE.ARPA> Reply-to: <LEICHTER-JERRY@YALE.ARPA> Subject: Re: compute bound jobs & terminal response time I have the impression that the SYSGEN parameter QUANTUM has a rather large default value of 20 (meaning 20 ticks = 200 msec), and that reducing that value to, e.g., 5 does give better terminal response iff your system load is cpu-bound and there are several processes in COM state. I never "formally" measured the effect and would be interested in anyone's experiences. I do realize that it will cost some cpu performance - there is at least 1 context switch per quantum - but 10 msec is a long time, isn't it. If a process does I/O from the terminal, when the I/O completes it gets a priority boost and a rescheduling event takes place, quite independent of quantum end. The rescheduling from quantum end events is there to ensure that processes of equal priority share the CPU among themselves. Decreasing QUANTUM slightly - maybe even all the way to 10 - MIGHT help in situations where you have many active processes. But it will definitely cost you. A small quantum value can get VERY expensive if you don't have enough memory for all your processes: A processes is almost certain to remain resident for one full quantum after it is swapped in. The bias against swapping such processes out is that otherwise compute-bound processes will simply oscillate between main memory and the swap file, never getting enough work done while resident to justify the expense of moving them back and forth. Any system on which you might even THINK that a QUANTUM value of 5 will help is almost certainly so overloaded that trying this will only push it over the edge. Still, you never know - 8800's are fast and can have TONS of memory. Since QUANTUM is a dynamic parameter, it's pretty easy to experi- ment. I'm sure everyone would like to see some real data...from someone else's system. :-) -- Jerry ------------------------------ Date: 1 MAY 1987 08:48:05 EST From: <LEICHTER-JERRY@YALE.ARPA> Reply-to: <LEICHTER-JERRY@YALE.ARPA> Subject: Re: VAXBI-Ethernet controller The Digital Review, April 20, 1987 issue, page 3 notes that the Local Area VAX Cluster software doesn't work on the VAXBI-Ethernet controller (DEBNA?) and DEC is requiring VAX 8[23578]00 customers to buy a Unibus adaptor (DWBUA) and a DELUA. My understanding was that except for 802.3 protocol usage, the DEUNA, DEQNA, DELUA and the DEBNA(?) had exactly the same QIO interface and a program that correctly uses one will work fine on any of the others. I am interested in this because I support an XNS ACP that uses the XE/XQ/ET driver. I has been tried at one or more customer sites with DEBNAs and seems to work ok but I'd really like to know what the difference is so I can be sure that it won't cause me problems. Anyone know exactly why LAVC doesn't like the DEBNA? The word I got is as follows: The software works with any of the interfaces; they are indeed software compatible. However, the BI interface has some hard- ware problems that show up at high loads - loads that are much more likely to be seen in LAVC's than in "typical" - whatever that means - Ethernets. The result is that DEC isn't willing to guarantee the LAVC software on this inter- face. The problems are being examined, and the intention is to eliminate this limitation as soon as possible. In the mean time, the LAVC stuff will work fine "most of the time", but it isn't supported. Chances are your XNS application won't have any problems; but if you see strange things happening at high loads.... -- Jerry ------------------------------ Date: 1 May 87 06:17:37 PDT (Friday) From: "Bruce_G._Kahler.rochX2"@Xerox.COM Reply-to: bkahl.rochX2@Xerox.COM Subject: Re: Hardcopy terminal with video output ? Instead of my current Decwriter terminal as 780 Operator console, I would like a hardcopy terminal with video output; hardcopy so there is permanent record of what goes on, video so an operator can see 'interesting' events/requests from a distance away. Does anyone know make/model of a hardcopy terminal having video output capability ? What about a video terminal with hardcopy capability? I think you can hook a printer to a VT220 terminal (maybe even your existing DECwriter) and have the console display go to both. ------------------------------ Date: Fri, 1 May 87 10:01 EST From: <KGOODMAN%SMITH.BITNET@wiscvm.wisc.edu> (Kaile Goodman) Subject: Tape REWIND on file closes I have written a PASCAL program which, among other things, reads files off of tapes. To do the copy, I first open the file to see if it exists and to get some file structure info. Then I close the file and call a MACRO routine which actually does the copy. The problem I am having is that each time I close the file the tape rewinds. Now all of the documentation I have says that the default on close is norewind. I can find ways to tell it to REWIND, but there are no corresponding NOREWIND flags. (This is both in PASCAL and MACRO.) The program is being run on a VAX 8500, although it had the same problem on an 11/785, VMS version 4.5. Please let me know if you have a solution to this, as our tape drive is slow to begin with. Thanks for any help. Kaile Goodman kgoodman@smith.bitnet ------------------------------ Date: 1 May 87 10:40:00 EDT From: "Daniel J. Graham" <graham@drcvax> Reply-to: "Daniel J. Graham" <graham@drcvax> Subject: OLD BUSINESS - YORK BULLETIN SOFTWARE Greetings and Hallucinations, As a new Info-Vax reader, I was taking advantage of the archives yesterday when I noticed mention of the York University Bulletin board program. I noticed several references to it being available to ARPA sites via FTP. However I never could find out what host/directory/filename it was on. The archive where I saw these references was a year old, and I don't know if the program is still available. Could somebody please let me know if York Bulletin is still out there, and how I can FTP it to my ARPA site. (since Info-Vax is going digest for awhile, reply to me directly to save room.) 1000 Thanks Dan Graham GRAHAM@DRCVAX.ARPA ------------------------------ End of Info-Vax Digest **********************