BACKUP /N(ew) change in behaviour

[Art Wiens]

I'm migrating a system to a CHARON-VAX platform (VMS v6.2). I thought I'ld take the time to apply a few patches were were "a bit" overdue (only by about a decade!).

The customer has command procedures with the BACKUP command utilizing the abbreviation /n to specify /new. It would appear that VAXBACK03_062 introduced a new switch called /no_incremental and their procedures now give eg.:

$ backup/log vupometer.com;0 *.*/n
%DCL-W-ABKEYW, ambiguous qualifier or keyword - supply more characters
\N\

I downloaded VERB and extracted the BACKUP cld, took out the: qualifier NO_INCREMENTAL and replaced the BACKUP command in the correct DCLTABLES, replaced the installed image, logged out and back in.

Now it gives a different error whether using /n , /new or /no eg.:

$ backup /log vupometer.com;0 *.*/n
%CLI-F-SYNTAX, error parsing 'NO_INCREMENTAL'
-CLI-E-ENTNF, specified entity not found in command tables

Have I done something wrong, or is it not a legitimate "fix" to modify commands in this fashion?

I have no idea how many procedures are affected ... waiting for that answer. If it's a couple then there is no issue, some simple edits can deal with it, but if it's "lots" ...

Cheers,
Art

[Dean McGorrill]

hi Art, well it certianly knows about the switch name 'NO_INCREMENTAL' but has no definition for it. I havn't used "VERB",
maybe you missed removing something. Can you put /NEW in the procedures, it would
certainly make the clearer to read. Dean

[Guenther Froehlin · Accepted solution]

You are out of luck! BACKUP code specifically does a lookup for 'NOINCREMENTAL'. You have to change the code in BACKUP. Actually I think this is a mini-design flaw in that it should not have used 'NOINCREMENTAL' but add negation to the existing 'INCREMENTAL' qualifier. And no, making that change in the CLD would still need a code change.

Guenther

[Art Wiens]

Dean - I agree it would be clearer to say /new ... laziness doesn't pay (sometimes ;-)

Guenther - thanks.

Hopefully it's not "hundreds" of procedures to edit!

Cheers,
Art

[John Gillings]

Art,

You can adjust some things by modifying the CLD, but you can't remove stuff that the program image looks for if the program considers missing entities to be fatal.

Use of contracted commands and/or qualifiers is not recommended in command procedures, for precisely the reason you've posted this question! Just because a particular contraction is unambiguous now, doesn't mean it will remain so in future.

The usual recommendation for writing DCL command procedures is to spell all DCL tokens (verbs, qualifiers and keywords) in full. If you MUST contract them, don't go below four letters.

There is even an undocumented command to force fully spelled DCL tokens (I'll post it if I can find it...)

[John Gillings]

(thanks to John Brodribb at the Sydney CSC for digging this out...)

WARNING - be very careful with this, it seems to be badly broken on V7.3 and above, not sure about other versions:

$ SET COMMAND SYS$INPUT
DEFINE VERB SETDCL
CLIROUTINE SETDCL
QUALIFIER SPELL_CHECK, NEGATABLE
^Z
$ SETDCL/SPELL

should turn on spell checking.

$ SETDCL/NOSPELL

to turn it off,

It's supposed to issue a warning "%DCL-I-MISSPELL" for any command token which isn't completely spelled properly, BUT it appears the message string overflows into junk, and may even corrupt some DCL structures. Unsupported and even less documented than most unsupported stuff.

[Hoff]

Using less than four characters for the verb, the keyword, or the qualifier is, as a rule, risky DCL code. There's no guarantee that an abbreviation will remain unique.

One of the two interfaces to VERB port found on Freeware V8 is busted. There's a work-around (fix), or you can use the other command interface. See topic 3537.* over in the EISNER::VMS notes conference for a recent discussion of VERB.