479 lines
22 KiB
Plaintext
479 lines
22 KiB
Plaintext
|
|
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:
|
|
***> 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 |
|
|
|
|
--------------------------------------------------------------------------------
|
|
,IMAGE-DUMP-ANALYSIS
|
|
>Subject: Analyzing a process dump
|
|
>From: mjensen@BBN.COM (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: gjc@mitech.com (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!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
|
|
--
|
|
Dick Munroe Internet: munroe@dmc.com
|
|
Doyle Munroe Consultants, Inc. UUCP: ...uunet!thehulk!munroe
|
|
267 Cox St. Office: (508) 568-1618
|
|
Hudson, Ma. USA FAX: (508) 562-1133
|
|
|
|
GET CONNECTED!!! Send mail to info@dmc.com to find out about DMConnection.
|
|
|