💾 Archived View for gemini.spam.works › mirrors › textfiles › hacking › VMS › vaxfaq3.txt captured on 2022-06-12 at 08:53:52.
-=-=-=-=-=-=-
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
LEICHTER@VENUS.YCC.YALE.EDU (Jerry Leichter)
,BOOT -- Booting a system whose disk is full. 1992-08-12
rankin@eql.caltech.edu (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
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)
,IMAGE-DUMP-ANALYSIS
-- Debugging using ANALYZE/PROCESS/IMAGE. added 1992-09-05
Martin Jensen <mjensen@BBN.COM>
George Carrette <gjc@mitech.com>
,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
---------------------------------------------------------------------
,BOOT
>Subject: Re: How to boot VMS from a failed AUDIT writing
>From: rankin@eql.caltech.edu (Pat Rankin)
>
>In newsgroup vmsnet.misc, article <1992Aug10.142728.4397@mic.ucla.edu>,\
> shinn@agsm.ucla.edu (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, rankin@eql.caltech.edu
>
[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: qb7g6@fel.tno.nl (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: ewilts@galaxy.gov.bc.ca (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: granoff@ranger.enet.dec.com (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: dfilip@colornet.UUCP
#
#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" <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: