Info-Vax-REQUEST@KL.SRI.COM.UUCP (05/05/87)
Info-Vax Digest Tuesday, 5 May 1987 Volume 0 : Issue 10
Today's Topics:
Re: How do you NOT write a <RETURN>? (was:ring bell in DCL file)?
Reasons not to digestify
Mailboxes and standard input.
Last access date for files.
Login-time definitions.
Make subject field informative.
PC EMULATOR
Digests in addition to direct messages - appreciation.
Submission for mod-computers-vax
Re: MAIL in NETWORK processes
More details on the DECserver problem
----------------------------------------------------------------------
Date: 4 May 87 18:40:04 GMT
From: hal9000!root@RUTGERS.EDU (Robert J. Drabek)
Subject: Re: How do you NOT write a <RETURN>? (was:ring bell in DCL
file)?
In article <102@blic.BLI.COM>, garvey@blic.BLI.COM (Robert Garvey) writes:
>
> This is an example of how that could be done:
> $ clear == "WRITE SYS$OUTPUT esc_chr,""[H"",esc_chr,""[2J"""
I have been using the above type of statements to do clear screens, but
they really leave the cursor on the second row since there is a
<return> effectively at the end of the write sys$output.
Is there someway around that? (In Unix echo -n does the job.)
--
Robert J. Drabek
Department of Computer Science
University of Arizona
Tucson, AZ 85721
------------------------------
Date: 5 May 87 01:47:00 EDT
From: "TODD AVEN" <todd@cincom.umd.edu>
Reply-to: "TODD AVEN" <todd@cincom.umd.edu>
Subject: Reasons not to digestify
1. *Sources* come across this mailing list from time
to time, and while the majority of readers may or
may not have intelligent mail reading programs to
undigestify these digests, it would be nice if it
were simpler to snatch code out of mail messages.
[Amazing! Every line is exactly the same length!]
2. I read mail messages in a peculiar fashion: I
read mostly first pages, since Subject: lines are
frequently enough meaningless, and can even obscure
some real gems. Unfortunately, this means hitting
every message, and they're not *all* gems. Now, if
it's a long-winded, include-filled, UUCP-bounced,
multi-header piece of trash and a decent article
follows, we all lose. Promote selectivity!
Todd Aven
the Softwear Sweatshop
------------------------------
Date: 4 May 87 17:45 -0100
From: Matts Kallioniemi <matts%QZ.sunet%chalmers.se@RELAY.CS.NET>
Subject: Mailboxes and standard input.
When on the subject of subprocess creation with input from a mailbox,
you should be aware that the default protection of mailboxes is
S:RWED,O:RWED,G:RWED,W:RWED. I.e. anybody can write to the mailbox,
and get their commands executed by your process. The last time I looked,
even Digital's own program TPU does this with the DCL command...
Cheers,
Matts Kallioniemi
Systems Programmer, KOMunity Software AB, Stockholm, Sweden
------------------------------
Date: 5-MAY-1987 10:40:39
From: MACALLSTR%vax1.physics.oxford.ac.uk@Cs.Ucl.AC.UK
Subject: Last access date for files.
Setting retention dates works fine as an indicator of last file access but
beware that for INSTALLED files this date is not updated. The same may also
apply to other files which are mapped as global sections and also to files
which may only be read at boot time - watch out for that if you tend to have
long periods between reboots. Otherwise the retention date is probably a good
indicator for deciding when to archive files.
I have found, too, that setting retention dates allows you to examine file
activity on disks - with some surprising results! For example, on some of our
congested disks I have found that nearly 30-40% of files haven't been touched
in the last six months. It's clear that a good archiving package could increase
disk space on a average system by about a factor of about 2!
John
------------------------------
Date: 5-MAY-1987 11:01:13
From: MACALLSTR%vax1.physics.oxford.ac.uk@Cs.Ucl.AC.UK
Subject: Login-time definitions.
I don't really understand the aversion to defining all symbols/logicals for
everyone at login time. If this is done within a program, the time taken is
a small fraction of the total elapsed login time. If logical names don't
NEED to be defined in the user or group tables they can be defined ONCE in
a system table at boot time thus saving a little more time at login.
MOST users don't want to KNOW what packages or particular pieces of packages
they are using - only what commands to use to perform certain tasks. Take,
for example, the VAX Information Architecture, software : CDD, DBMS, RdB,
DATATRIEVE, TDMS, ACMS, FMS, etc. How do you sort that lot out into SETUP,etc
commands when there are so many interconnections?
There are, perhaps, instances when two packages use the same symbol/logical
for different purposes. In such cases, one would PERHAPS, have explicit
definitions in the user's LOGIN.COM file. Even in these instances, all
the unique stuff could be defined system-wide AND the conflicting items
defined in the package startup sequence ( easily done, perhaps via a
command file for the package if there's no access to the code ).
There are so many advantages for the 'normal user' in defining everything for
everyone that I'd recommend this approach to everyone and especially to those
who are new to VAX/VMS. Looking up and opening several files is such a slow
process, especially at login time when you're waiting eagerly to start typing,
that it should be avoided if possible. The problem is worse on the low-end
VAX's and may be less of a nuisance on 8800's,etc.
John
------------------------------
Date: 5-MAY-1987 11:53:46
From: MACALLSTR%vax1.physics.oxford.ac.uk@Cs.Ucl.AC.UK
Subject: Make subject field informative.
In the case of 'Submission for ... ' subjects, it looks as if some intermediate
software ( gateway? ) is intercepting the messages and placing a new subject
field in the header. The original Subject field is still there. The Info-VAX
mailer could take charge and enter the Subject field it finds nearest in position
to the beginning of the user text. I'd also like to see rejection of mail
without a subject field - reject with some informative message for the sender
to indicate that a subject is required.
Multiple messages are also a nuisance : can't the mailer maintain a counter and
restart at ( or near ) the counter if there is some failure during transmission
of a list? It looks as if lists are retransmitted from the beginning when a
retry is required?
I like to receive original messages as the sender intended them to be read.
Summaries may be useful at the end of a series of correspondence but should
be sent out in ADDITION to the normal mail and not as a replacement.
John
------------------------------
Date: 5 May 87 07:59:00 EST
From: "DAVE DOROSZ" <dorosz@esdvax.arpa>
Reply-to: "DAVE DOROSZ" <dorosz@esdvax.arpa>
Subject: PC EMULATOR
Charles Herman wrote:
> Where did you get a VT240 emulator which runs on a PC? I have been looking
> for such software for quite a while.
We use CALL writtten by MicroSystems Co., 16987 Frank ave.,Los Gatos Ca. 95030
its licensed to the U.S. military and it is fasr becoming the standard PC
VT240 emulator for the Air Force. It seems to work well and the documentation
is fairly detailed. It emulates both DEC vt2xx and TEKTRONIX 4010, 4014
terminals. It does 132 column displays, double wide, double high characters,
boldface etc. At least that's what the manual says, I've not tried any of
these features on the Zenith 248 machines we use at Hanscom.
Dave Dorosz
Hanscom AFB
DOROSZ@ESDVAX.ARPA
------------------------------
Date: 5-MAY-1987 13:03:42
From: MACALLSTR%vax1.physics.oxford.ac.uk@Cs.Ucl.AC.UK
Subject: Digests in addition to direct messages - appreciation.
I really appreciate receiving these Info-VAX digests which are now being
sent out in addition to direct messages. Thanks to whomever takes the
time to compile them.
I realise from looking at the digests that I'm losing about 30% of the
Info-VAX mail : 30% of digest entries appear to be news to me - on a
quick scan.
John
------------------------------
Date: 5 May 87 12:54:58 GMT
From: Gary Upchurch <ecsvax!ncatgu@mcnc.org>
Subject: Submission for mod-computers-vax
Path: ecsvax!ncatgu
From: ncatgu@ecsvax.UUCP (Gary Upchurch)
Newsgroups: comp.os.vms,comp.sys.dec,mod.computers.vax
Subject: tty_altypahd
Message-ID: <3042@ecsvax.UUCP>
Date: 5 May 87 12:54:56 GMT
Distribution: usa
Organization: NC A&T State Univ. Comp. Ctr.
Lines: 9
Keywords: xon-xoff data overruns
I just got trhough reading the article concerning data overruns on systems
that do not use xon-xoff. I have just run into the same problem, could some-
one point out the article for me. It referenced the alternate typeaphead buffer.
Thanks.
--
Gary Upchurch
Systems Programmer
{decvax,akgua}!mcnc!ecsvax!ncatgu
------------------------------
Date: Tue, 5 May 87 10:33:43 edt
From: rlb@rtpark.rtp.ge.com (Bob Boyd,8*274-3627 05-May-1987 1030)
Subject: Re: MAIL in NETWORK processes
In response to the message from Ian MacPhedran:
MAIL is a multimodal image -- if it is invoked inside of a NETWORK
process it tries to receive mail from SYS$NET -- when a mail link
is made to a node, the NETACP process fires up a network server process
with the image SYS$SYSTEM:MAIL.EXE. Because of how MAIL decides what
mode it is in you just can't use it to send mail from inside a NETWORK
mode process. You may be able to do what you want some other way --
e.g. create a detached process or batch job or maybe even a subprocess
would work.
Bob Boyd
(919)549-3627
RLB@RTPARK.GE.COM
------------------------------
Date: 5 May 87 08:23:00 PDT
From: "Oberman, Kevin" <oberman@lll-icdc.arpa>
Reply-to: "Oberman, Kevin" <oberman@lll-icdc.arpa>
Subject: More details on the DECserver problem
>I'm not sure, since I've never worked with DECservers, but I suspect the only
>ways to set the terminal characteristics for LTAn are:
> a) Set them up interactively after the line is active; or
> b) Set the appropriate SYSGEN parameters for default terminal
> characteristics to be what you want for the LTA's.
Unfortunately, this does not work. ALTYPEAHEAD is a parameter that may not
be set after the terminal line is allocated, which it is at the time of
creation. And the System Generation Utility Reference Manual, page SGN-83,
states the the ALTYPEAHEAD bit should not be set.
RE: Dave Dorosz's reply, I'm trying to slow it down. NBI denies any delay
timer between lines.
Thanks for the help,
R. Kevin Oberman
Lawrence Livermore National Laboratory
arpa: oberman@lll-icdc.arpa
(415)422-6955
------------------------------
End of Info-Vax Digest
**********************