🚀 go-pugleaf

[Last changed: 2-AUG-1990]
[Changes since last posting: None.]

           The Info-VAX Monthly Posting
           ----------------------------
           PART 3 -- Advanced "Common Questions".
           (Coordinated by Terry Poot, written by many others)

(Part 1 is an introduction to Info-VAX.  Part 2 is Beginner Common Questions.)

Save this message for future reference!

Table of Contents:

,BAC   -- Advice on how NOT to backup your VAX            updated 1989-08-03
          LEICHTER@VENUS.YCC.YALE.EDU (Jerry Leichter)
,SIG   -- How to set up automatic signatures, etc.          added 1989-09-29
          CADS_COLE@GALLUA.BITNET (Kevin Cole)
,FLA   -- No question is stupid...                          added 1989-10-02
          [A reminder to "us gurus" -TAL]
          FASTEDDY@DFTNIC.GSFC.NASA.GOV (John McMahon)
,MCR   -- About MCR (Bruce Wright)                          added 1989-10-02
          rti!bcw@MCNC.ORG

(the ",BAC", ",SIG", etc are keywords.  If you search for that text
(including the ",") you will be brought to the beginning of that article.)

---------------------------------------------------------------------
,BAC
Subject: VMS Backup tips
>From LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter") Tue Aug  1 10:01:00 1989
Lines: 74

>[Various messages concerning long BACKUP times on a MicroVAX II, along with a
>recommendation of the command line:
>   $ back/log/ver *.*/ignore=inter mua0:backup.bck/sav/buf=5/blo=17408-
>        /nocrc/group=0
>]
>
> I think that Bob's response addresses part of the major problem with
> BACKUPs on uVAX-IIs:  that of CRC.  On uVAX-IIs, the CRC instruction is
> emulated in software as opposed to being in hardware as it is in its
> bigger brothers.  As you might imagine, doing CRCs takes forever on a II.
> /NOCRC is a MUST in your BACKUP command line.

In general, both of these pieces of advice - ESPECIALLY the first one!  -
are EXTREMELY BAD.  They are the equivalent of "Locksmiths are SO expensive,
I won't bother to install locks on my front door".  Such advice might make
sense in some parts of the country, but try it in New York City....

Before considering this advice, decide for yourself just WHY you are doing
backups.  Is it because you've heard that it's a good idea, or because it
appears on your job description, but you don't REALLY expect ever to USE all
those tapes you are writing?  Or is it because you want a safe copy of your
data in case something goes wrong with your disk, or in case you just
acciden- tally delete something important?

If it's the former, I'll suggest that you can actually make BACKUP run even
faster; just add /CREATED/SINCE:TOMORROW.  Try it - you should see amazing
results.  In fact, the results will be so good that you should be able to
save all the typing for those other tacky qualifiers.

It it's the latter, consider what chances you are taking:

 - If you use /NOCRC, you are relying on the error detection capabilitites
of the tape hardware.  This varies in ability to detect problems, depending
on the kind of tape and the density.  Even at its best, it provides no
protection against problems with the tape interface, with the bus, with
memory, and so on.  ALL of these are known potential failure points.

- If you add /GROUP=0, you are disabling BACKUP's ability to recover from
errors that develop on the tape while it is in storage, among other things.
What you are getting in return is about 10% more data on the tape.  Sounds
like a very poor tradeoff to me.

 - I don't know how the block size of 17408 was selected.  The default value
(2048) was chosen by people with some data about tape failure statistics.
It's a tradeoff:  The larger the block size, the more data you can fit on
the tape - but the larger the probability of two blocks in a redundancy
group suffering simultaneous errors, so that the data is irretrievably lost.

Of course, since redundancy groups have been disabled (by /GROUP=0) this
makes little difference anyway.

 - Also about /BLOCK:  The combination of a large blocksize with a large
buffer count can cause a reel-to-reel tape to run off the end of the reel.
(Tapes have reflective "end of tape" markers well in from the end of the
tape, but if enough data is already "in the pipe" it can be impossible to
stop the drive in time.  Ever try threading a tape backwards?)

I can think of almost no reason to play with the redundancy group size,
except for things like BACKUP savesets used to transfer stuff across a
network where errors are unlikely and you can get another copy of the
damaged stuff if you need it.

I can think of few reasons to play around with the block size.

I personally can't imagine a serious backup policy based on use of /NOCRC,
at least as a universal policy.  (I suppose you MIGHT do weekly backups
/CRC, and nightly incrementals /NOCRC, figuring that the cost of having to
go back, at the very worst, to the weekly backup is small enough to justify
the additional risk.)

There are significant tradeoffs to be made here.  "Speed of backup" is only
one factor.  You have to decide for your own site how to balance this factor
against the others.  But do it in an informed way!  Also, be ready to
re-examine your conclusions as the data change:  BACKUP in VMS V5.2 should
be much faster.  In particular, the CRC algorithms have been SIGNIFICANTLY
sped up.

       -- Jerry

---------------------------------------------------------------------
,SIG
>From: "Kevin Cole at Gallaudet U. Washington DC" <CADS_COLE@GALLUA.BITNET>
Subject: Automatic Signatures, Emblems and ">" a la EDT

Several people have asked me about automatic emblems.  I'm not saying this is
the best way to do things...  I'm just saying it's the way I do things.  Seems
to work OK for me.  Well, here's how I do it:
     
        1) Create a file with your particular emblem or signature in it.
           (I called mine SIGNATURE.TXT.)
     
        2) Add the following lines in your LOGIN.COM:
            $ DEFINE/NOLOG MAIL$EDIT    SYS$LOGIN:MAILEDIT.COM
            $ MAIL      :== MAIL/EDIT=(SEND,REPLY=EXTRACT,FORWARD)
     
        3) Cut out the following two files (MAILEDIT.COM and MAILEDT.INI)
     
<Cut here>-------------------- MAILEDIT.COM -------------------------<Cut here>
$ SET TERM/NOBROADCAST
$ DEFINE /USER SYS$INPUT 'F$TRNLNM("SYS$OUTPUT")'
$ IF P1 .EQS. "" THEN GOTO NOINPUT
$ EDIT /COMMAND=SYS$LOGIN:MAILEDT.INI/OUTPUT='P2' 'P1'
$ SET TERM/BROADCAST
$ EXIT
$NOINPUT:
$ EDIT /COMMAND=SYS$LOGIN:MAILEDT.INI 'P2'
$ SET TERM/BROADCAST
$ EXIT
<Cut here>-----------------------------------------------------------<Cut here>
     
     
<Cut here>-------------------- MAILEDT.INI --------------------------<Cut here>
SET CURSOR 0:20
SET SCREEN 80
SET WRAP 79
SET SEARCH BEGIN
SET ENTITY WORD '^H^I^J^K^L^M !"#$%&''()*+,-./:;<=>?@[\]^_`{|}~'
SET WORD NODELIMITER
DEFINE KEY GOLD 14 AS "5SHL."
DEFINE KEY GOLD 15 AS "5SHR."
DEFINE KEY GOLD D AS "DATE."
C; ER -L 32000(62ASC -2L) ER EX
INC SYS$LOGIN:SIGNATURE.TXT
F BEG
C; IDate sent: ^Z DATE ^M EX
SET MODE CHANGE
<Cut here>-----------------------------------------------------------<Cut here>
     
     
NOTE: Change the ^H^I^J^K^L^M to control characters in the SET ENTITY command.
      Change the ^Z to control-Z (but NOT the ^M) in the second last line.
     
Explaination:
     
The above does a bit more than what is asked for...  The reason I spawn instead
of using callable EDT or TPU is because I prefer to turn off broadcasts while
I'm editing, and because the COM file runs a non-standard INI file.  The
special INI file is what adds the emblem/signature.  It also does a few other
handy things like adding the time the message was sent, and adding the ">"
character to the beginning of every old line in a reply.  (That's a trick I
learned from someone on this list ages ago.)  The guts are in the last five
lines.
     
First we move to the end of the buffer (ER).  Backup one line (-L).  Insert a
">" (62ASC) and go to previous line (-2L) 32000 times.  When we've finally
added as many ">" as we can, go back to the end of the buffer (ER).  Add the
signature file. (INC SYS$LOGIN:SIGNATURE.TXT).  Go back to the top of the file
(F BEG) and add the current time and date (IDate sent: ^Z DATE ^M EX).  Lastly
give control back to the sender (SET MODE CHANGE).

---------------------------------------------------------------------
,FLA
Subject:  No question is stupid...
>From:     John McMahon - NASA GSFC ADFTO - 301-286-2045
          <FASTEDDY@DFTNIC.GSFC.NASA.GOV>
Date:     Thu, 3 Aug 89 12:18:10 EDT

(Commentary having very little to do with Vaxen follows...)

Sample antagonistic response to novice question:
***> RTFM! Page 7-7 in binder 8B, the version 4 doc set. Just set
***> bit 28 and you're done! And stop asking such silly questions,
***> which are so easily answered, will you!

It seems to me that usefulness of Info-Vax/Comp.Os.Vms is decreased when
someone out on the net asks a question and is greeted with comments like those
above.  To you the question may seem trivial...  However, it wasn't to the
person posting.

First thing to keep in mind:  Even if it's in the manuals, the person may not
be able to find it.  If you posted a question about "How do I increase the
maximum record size for DECnet I/O", I could easily answer RTFM.  But that's
only because I found it once...  It took a couple of hours, several manuals,
and a little luck.  Some people aren't that lucky, and some don't have access
to full documentation sets.  Also, when was the last time you actually read an
index that pointed to exactly what you wanted the first time ?  Most indexes
imply that the user knows approximately what he/she is looking for first...
What is a user to do when he/she doesn't know where to look ?  How about ask
the Info-Vax gurus...

Second thing to keep in mind:  Not everyone here is at the same level of
experience.  Just because you are talented/knowledgeable you don't have to hold
that over a novice who is lost in VMS.  Remember that at one point, all of the
gurus (including you) were novices.  How far would you have advanced if people
you asked for help from said "Read the manuals...  You ask silly questions..."
Probably not as far as you have gotten.
     
Third thing:  Behind each posting is a person.  The network creates an
'artificial buffer' which keeps us separate enough that we forget.  Just
because it's e-mail doesn't meen you shouldn't be polite.  We are humans after
all...  We are supposed to be civilized...
     
Boiled down to a point:  Info-Vax is a technical discussion involving everyone
from the Novice to Guru level.  Let's keep it polite and technical...  Don't
post personal editorial comments...
     
(I know, I probably just violated that...)
     
Please direct comments to me (not the list)...
/-------------------------------------+---------------------------------------\
| John "Fast Eddie" McMahon           |    Span: SDCDCL::FASTEDDY (Node 6.9)  |
| Advanced Data Flow Technology Office|    Arpa: FASTEDDY@DFTNIC.GSFC.NASA.GOV|
| Code 630.4 - Building 28/W255       |  Bitnet: FASTEDDY@DFTBIT              |
| NASA Goddard Space Flight Center    |GSFCmail: JMCMAHON                     |
| Greenbelt, Maryland 20771           |   Phone: x6-2045                      |

---------------------------------------------------------------------
,MCR
Subject: Response to Question about "MCR"
>From: Bruce Wright <rti!bcw@MCNC.ORG>
Date: Thu, 28 Sep 89 15:31:08 GMT

In article <22331@cup.portal.com>, Wiley_M_Sanders@cup.portal.com writes:
>    MCR stands for "Monitor Console/Control Routine", and is a vestigial
> element left over when PDP-11 programs could be run under VMS. MCR is/was
> the RSX-11 equivalent of the RUN command, although it really RUNS the
> image as a foreign command, as opposed to RUN, which launches the
> installed image. In that way it's not exactly a synonym for
> RUN SYS$SYSTEM.
     
Sorry if this is too pedantic for the net.censors, if you don't like it
just hit the "n" key.
     
The MCR command on VMS is more-or-less like RUN on VMS, though with some
of the slight differences that have been mentioned here and elsewhere - but
MCR on RSX was NOT the RSX equivalent of RUN.  VMS doesn't have an exact
equivalent of MCR - the closest thing is DCL;  MCR was the user command
line interface module under RSX.  As noted, MCR stands for "Monitor
Console Routine" and was the prompt that the user saw:
     
	MCR>your-RSX-command
     
RUN was a very respectable RSX command - it ran a user image as a task.
RSX commands were one-to-three letter commands which were derived from the
names of installed tasks (sort of like an installed image on VMS, but when
it was invoked it would start a new task [=process on VMS]).
     
RSX commands were one-to-three letter commands which were derived from the
names of installed tasks.  These were run as separate tasks (=process on
VMS) when the corresponding command was entered (everything on RSX was a
task, image activation corresponded to task activation).  Since there were
a number of different versions of RSX (RSX-11A, RSX-11B, RSX-11C, RSX-11D,
RSX-11M, RSX-11M+, RSX-11S, IAS, POS, and maybe others), some of which
shared only a few architectural and historical things in common, the
precise details of the implementation differed somewhat between members
of the family.
     
Later versions of RSX (and some of its derivatives such as IAS) did include
a DCL interpreter which had numerous similarities (and differences) with
respect to VMS DCL.  Because of the architecture of the systems, many of
the DCL commands in the RSX family would start a new task (=process) rather
than run an image in the same process as on VMS - but the effect from the
user point of view was very similar.
     
>    Alas, the MCR command interpreter seems to be absent from VMS 5.2. At
> least when I type SPAWN/CLI=MCR, it can't be found.
     
The MCR command is left over from when the RSX compatibility mode software
was bundled in with VMS.  Those of you that have been around since VMS V1.0
probably remember that, for example, DIRECTORY was implemented as PIP /LI
and that many commands (including DIRECTORY) would spit out RSX-like error
messages like "PIP -- No such file(s)".  It started out as much as an aid
for DEC to get all that utility software running on the VAX as it did as an
aid for helping customer conversions.
     
Since at least V4.0 this has been separate product (VAX-11 RSX) which sites
with an earlier license automatically had a license to use.  When it was
made a separate product, all the RSX code (MCR, PIP, TKB, FLX, and all the
other friends from the RSX world, and BACKTRANS.EXE and other things from
the VMS world which made the whole mess work) were removed and made part
of the VAX-11 RSX product.
     
When this was done, the MCR command was probably left in the DCL tables
because removing it would break too many command files and annoy too many
people who had gotten used to typing "MCR mumble" instead of the wordier
"RUN SYS$SYTEM:mumble".
     
     
						Bruce C. Wright
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!ksuvax1!deimos!mccall!tp) 615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA