copy [/confirm]

[Willem Grooters]

On installation of a very critical package, the procedure made sure you don't do anything wrong, and asks confirmation on almost every COPY. Here we noticed a possible cause of unneeded panic because the confirmation message: it contains the same version number as the original.
Second, if a version number is explicitly mentiond in the first argument (From), the sane version will be created if the destination (TO) is doesn't contain a version spec. Luckily, a waning message is issued that newer versions do exist so it doesn't have to go unnoticed.

I did some investigation, resulting in the attached procedure. No doubt, there is more to look for, but these two is what caused some frowns.

(originally signalled on VMS 7.1 on VAX, but the same happens on VMS 8.3 on Alpha)

[Hein van den Heuvel · Accepted solution]

Well, that's just how it is.
You can not 'see' which target output version is 'hard' versus 'soft'.

It behooves the writer of the script to try to avoid this potential confusion for the end-user.

- the script could add a /LOG to show what actually is done.

- The script could test for an existing file if an explicit target version is being used. It might then (ask to) delete that target or skip trying a known to fail copy.

fwiw,
Hein.

[Jan van den Ende]

>>>
Luckily, a waning message is issued that newer versions do exist so it doesn't have to go unnoticed.
<<<

If there is any chance of copying to a LOWER version, as you seem to describe here, then the autor of the installation procedure (most certainly in case of "a very critical package" should specify a semicolon ( ";" ) in the target specification!
( If BACKUP is used, /NEW has the same result)

fwiw

Proost.

Have one on me.

jpe

[John Gillings]

Willem,

>originally signalled on VMS 7.1 on VAX,
>but the same happens on VMS 8.3 on Alpha

and the same on all versions back to VAX V1.0 and for all future versions on all architectures.

What you're seeing illustrates standard file name defaulting. The input file is used as defaults for the output file. Thus if you specify an explicit version number on the input file, it will be used for the output file unless you specify an explicit output file version number (which may, of course, be relative).

Assuming you want the destination file to superceed any existing versions in the destination directory, you should code your copy command as:

$ COPY 'from' [-.2];/CONFIRM

This will always do what (I think) you want, and the confirmation question will show the output version as ";".

I also echo Hein's suggestion of adding /LOG. (I routinely use /LOG on all interactive COPY commands to make sure it really did what I wanted).

The filename default mechanism is pervasive throughout all of DCL. It's a good idea to carefully study the behaviour of F$PARSE to make sure you understand it.

FWIW, I'm still learning some of the very slick things that can be done with it.

[Hoff]

Out of curiosity, why is a human in the loop with the installation processing of a very critical package? (Folks tend to get used to dismissing the dialog boxes with a "noisy" application, and it's best if they don't.)

Consider automating the whole verification and only prompting in exceptional conditions; computers are good at that, and humans not so much.

Consider automating the front-end processing on the COPY command to verify whatever it is that you're expecting the human to look for, and adjusting the human-visible prompt accordingly. Then shell, err, spawn the proper COPY command or invoke callable CONVERT (the de facto API for copying files) to perform the transfer.

[Willem Grooters]

Some users don't trust themselves. So they want to be sure they didn't type the wrong thing.

The issue arose when preparing for an update, and the database files needed to be put aside as a backup (there is no other means inside the database package to achieve this). The procedure could be optimized to a more sophisticated method, but this one needed to be created as soon as possible - and as safe as could possibly be achieved in the timeframe. Therefore, to be as sure as possible that the right files were copied, /CONFIRM is used, besides /LOG.

So the user was unpleasently surprised to see that he was to copy version ;1 to version ;1, where version ;4 already existed...

[Hoff]

>>> Some users don't trust themselves. So they want to be sure they didn't type the wrong thing.

Which can be an entirely reasonable degree of paranoia when production servers are involved. My preferred solution here then being "don't let the user enter the failure-prone stuff", and "don't prompt the user for a normal condition." PCSI kits and VMSINSTAL kits are comparatively primitive solutions, but they're also effective solutions.

[Willem Grooters]

I completely agree that a fully automated *and thoroughly tested* procedure would be the best solution: No human intervention required.
Nor possible - and that scares the system manager, because "What if there would be something we didn't think of". They need to be in control, some way...

[Willem Grooters]

Case closed.