home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!usc!sdd.hp.com!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!spool.mu.edu!agate!ucbvax!U.WASHINGTON.EDU!DEREK
- From: DEREK@U.WASHINGTON.EDU
- Newsgroups: comp.os.vms
- Subject: Re: Q: SET DEFAULT and logicals
- Message-ID: <AECC4F7637FF20195D@MAX.U.WASHINGTON.EDU>
- Date: 14 Dec 92 20:28:00 GMT
- Sender: daemon@ucbvax.BERKELEY.EDU
- Distribution: world
- Organization: The Internet
- Lines: 38
-
- In article <1992Dec11.123536.1@vxdesy.desy.de>, pawlak@vxdesy.desy.de writes:
- > A user came to me today complaining about a DCL problem, which can be
- > summarized by the following command sequence:
- >
- > $ SHOW DEFAULT
- > DUA1:[USER]
- > $ DEFINE DIR1 DUA0:[ARCHIVE]
- > $ DEFINE DIR2 DIR1
- > $ SET DEFAULT DIR2
- > $ SHOW DEFAULT
- > DUA1:[ARCHIVE]
- > %DCL-I-INVDEF, DUA1:[ARCHIVE] does not exist
- > $ SET DEFAULT DIR1
- > $ SHOW DEFAULT
- > DUA0:[ARCHIVE]
- ....
-
- Well, this bug has existed in VMS as long as I can remember, and I know that
- it was SPRed at LEAST once. (I SPRed it.) The problem stems from the code
- which decides which PARTs of the default to change. Basically, an attempt
- is made to translate the input parameter as a logical name. If the resulting
- string contains a colon, then SYS$DISK is changed. If not, SYS$DISK is NOT
- changed. Expansion continues until the directory path name is resolved.
-
- I run across this bug every now and then because I use the ASSIGN command
- rather than the DEFINE command. (And if you don't know what the effective
- difference is, check out my article on the subject from, say, four years
- ago. :) )
-
- -Derek S. Haining
- University Computing Services
- University of Washington
- Seattle, Washington 98195
- (206) 543-5579
-
- DEREK@MAX.BITNET
- DEREK@MAX.U.WASHINGTON.EDU
-
-