NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/vmsnet/misc/1096

Internet Message Format | 1993-01-01 | 22.4 KB

Xref: sparky vmsnet.misc:1096 comp.os.vms:20184 news.answers:4850
Path: sparky!uunet!thehulk!munroe
Newsgroups: vmsnet.misc,comp.os.vms,news.answers
Subject: Info-VAX: "Advanced" Common Questions
Message-ID: <[e-mail]>
From: [e-mail]
Date: 1 Jan 93 04:04:44 EST
Followup-To: vmsnet.misc
Expires: 12 Feb 93 00:00:00 GMT
References: <[e-mail]>
Organization: Doyle, Munroe Consultants, Inc., Hudson, Ma. 01749, USA
Approved: [e-mail]
Supersedes: <[e-mail]>
Lines: 476

Archive-name:   info-vax/part03
Last-modified:  1992/09/05

[Changes since last posting: Added a description of how to usefully debug
with ANALYZE/PROCESS/IMAGE.]

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

(Part 1 is an introduction to Info-VAX.  Part 2 is Beginner Common Questions.
Part 4 is about how to find software.)

Save this message for future reference!

Table of Contents:

,BAC   -- Advice on how NOT to backup your VAX            updated 1989-08-03
          [e-mail] (Jerry Leichter)
,BOOT  -- Booting a system whose disk is full.                  1992-08-12
      [e-mail] (Pat Rankin)
,DIR   -- Why is my directory so slow                  1992-08-09
      Various people from vmsnet.internals
,SIG   -- How to set up automatic signatures, etc.          added 1989-09-29
          [e-mail] (Kevin Cole)
,FLA   -- No question is stupid...                          added 1989-10-02
          [A reminder to "us gurus" -TAL]
          [e-mail] (John McMahon)
,IMAGE-DUMP-ANALYSIS
       -- Debugging using ANALYZE/PROCESS/IMAGE.        added 1992-09-05
      Martin Jensen <[e-mail]>
      George Carrette <[e-mail]>
,MCR   -- About MCR (Bruce Wright)                          added 1989-10-02
          rti![e-mail]

(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 [e-mail] ("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

---------------------------------------------------------------------
,BOOT

>Subject: Re: How to boot VMS from a failed AUDIT writing
>From: [e-mail] (Pat Rankin)
>
>In newsgroup vmsnet.misc, article <[e-mail]>,\
> [e-mail] (Shinn-Tzong Wu) writes...
>> Hi, we just encounteded one of our worst nightmare, the VAXStation 3100
>> (running VMS 5.3) died probably because it ran out of disk space for
>> the AUDIT process.  Since the AUDIT process tried to write into the
>> full disk in the process of rebooting, there seemed to be no way that we
>> can bring the system up.  We tried to boot it from a stand alone tape but
>> it won't access to any of the disks.  Can anyone suggest any help?  Thanks...
>
>     Use a conversational boot to bring up a minimum system.  For a 3100,
>use B/1 at the `>>>' console prompt.  (If you have a console password
>enabled, you'll have to enter it in order to use any variant of the boot
>command other than just "B".)  From B/1, you'll get a `SYSBOOT>' prompt
>where you can modify SYSGEN parameters; do the following
>SYSBOOT> SET STARTUP_P1 "MIN"
>SYSBOOT> CONTINUE
>from there the system will boot normally, except that under a minimum
>system many things are suppressed, including the audit server.  (Also
>systartup_v5, the site-specific startup procedure, is suppressed, as are
>sylogin and login.com once the system is up.)
>
>     Log in immediately as SYSTEM, use SET LOGIN/INTERACTIVE=1 to keep
>ordinary users out, and then purge, delete, or move files to recover
>sufficient disk space for normal operation.  Lastly, reset the system
>parameters
>$ run sys$system:sysgen
>SYSGEN> USE CURRENT
>SYSGEN> SET STARTUP_P1 ""
>SYSGEN> WRITE CURRENT
>SYSGEN> EXIT
>and then reboot.
>
>     This kind of stuff should be covered in the "emergency procedures"
>section of the system manager's manual(s).  Followups redirected to
>vmsnet.sysmgt.
>
>        Pat Rankin, [e-mail]
>
[Ed. note: The instructions to perform a minimum boot vary from
processor to processor.  The instructions here are specific to a VAX
3100 (although most of the 3xxx product line seems to follow this
"standard") NOT to all VAXen.  Check the Installation Supplement manual
for your specific processor for the conversational boot procedure.]
---------------------------------------------------------------------
,DIR

>Subject: Why does emptying a dir take so long?
>From: [e-mail] (Maarten Landzaat)
>
>I'm sorry if this is a FAQ. I don't often read VMS newsgroups.
>A friend of mine using VAXstations 3100 and 4000(?) running
>5.4 and 5.5 told me this striking story:
>
>He has a few directories containing a few hundred files. Sometimes, these
>dirs need to be emptied. He then issues a simple delete *.*;* or whatever.
>then VMS takes an INCREDIBLE time of 2 hours (5.4) or 45 minutes (5.5)
>to delete the files.
>
>Now I've been working with VMS and unix, and didn't find that many
>performance differences. But this is a VERY big difference. I've seen
>lots of unix directories with hundreds of files, and delete time
>seems linear. Deleting a few files on VMS does not take a long time,
>at least IMO. Is VMS file deletion then not linear?
>
>Does anybody know why VMS takes such a long time?
>Is it fundamental to the VMS filesystem structure?

#From: [e-mail] (Ed Wilts)
#
#I would hazard a guess that the size of the directory file exceeds 127 blocks.
#The size of this file is proportional to the number of files in the directory
#and the length of each file name.  I am surprised that you're seeing it with
#only a few hundred files.
#
#Once you hit this magical limit [127 blocks], all hell breaks loose and you
#wait forever to get any work done.  Spread your files over multiple
#sub-directories if possible.

#From: [e-mail] (Mark H. Granoff)
#
#Try deleting the files in reverse alphabetical order.  It'll take a little more
#code (DCL, for example) than a simple DELE *.*.* command, but it'll improve the
#performance of that logical operation.
#
#Directory files are maintained in alphabetical order.  If you delete the first
#file in a directory, the directory file must be compressed and/or shuffled to
#remove that first entry.  In a directory containing many files, this will take
#some time.

#From: [e-mail]
#
#If all access to the directory becomes VERY SLOW (including DIR's) then
#I would suggest looking at the SYSGEN parameter ACP_DIRCACHE. This is the
#number of blocks of a directory file that are kept in cache. Although a few
#hundred files should NOT create an extremely large directory, if there were
#ever a lot more (i.e., thousands) then this could be your problem since
#directory files are not automatically compressed when files are deleted.
#
#ACP_DIRCACHE should be slightly larger than your largest directory file.
#The parameter is dynamic, so you can change it without rebooting and see
#if it fixes your problem.
---------------------------------------------------------------------
,SIG
>From: "Kevin Cole at Gallaudet U. Washington DC" <[e-mail]>
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
          <[e-mail]>
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: [e-mail]|
| Code 630.4 - Building 28/W255       |  Bitnet: FASTEDDY@DFTBIT              |
| NASA Goddard Space Flight Center    |GSFCmail: JMCMAHON                     |
| Greenbelt, Maryland 20771           |   Phone: x6-2045                      |

--------------------------------------------------------------------------------
,IMAGE-DUMP-ANALYSIS
>Subject: Analyzing a process dump
>From: [e-mail] (Martin Jensen)
>
>    I've got an executable that runs with the /dump qualifier.  I expect
>    that, on occasion, the process will crash.  (as a matter of fact, we
>    intentionally crash it if software detects an unrecoverable condition
>    in the code).
>
>    The problem is that the dump files are pretty useless.  'show  calls'
>    reports  only the module names - no routine names - and I've only got
>    access to universal symbols.  The program is compiled with the /debug
>    switch and linked with /trace.
>
>    Ideally, I would like to be able use anal/proc/image=xxx against the
>    dump from the normally linked executable - where xxx would be an
>    image containing the full DST and GST.  The couple of options I have
>    tried allow me to analyze the dump, but the symbol locations don't
>    match properly between the images.
>
>    Any ideas???

>Subject: Re: Analyzing a process dump
>From: [e-mail] (George J. Carrette)
>
>The trick people use is to LINK/DEBUG and then use a command
>procedure that calls VMS PATCH to change the image back to thinking
>it was LINK/NODEBUG.
>
>That way you get all the symbols in the image without having it start
>up in the debugger.
>
>You can get a SETDEBUG.C or NSETDEBUG.COM, or other various of that
>from various places. Probably VMSNET.SOURCES archives.
>
>-gjc

--------------------------------------------------------------------------------
,MCR
Subject: Response to Question about "MCR"
>From: Bruce Wright <rti![e-mail]>
Date: Thu, 28 Sep 89 15:31:08 GMT

In article <[e-mail]>, [e-mail] 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
--
Dick Munroe                Internet: [e-mail]
Doyle Munroe Consultants, Inc.        UUCP: ...uunet!thehulk!munroe
267 Cox St.                Office: [phone]
Hudson, Ma. USA                FAX: [phone]

GET CONNECTED!!! Send mail to [e-mail] to find out about DMConnection.