topic Re: DCL confusion in Operating System - OpenVMS

DCL confusion

Wim Van den Wyngaert — Tue, 14 Sep 2004 01:09:59 GMT

I accidently typed :

edit/tpu lat_ports|@ops$proc:x.com

It seemed that x.com was executed in a special way (line per line). Why ?

Wim

Re: DCL confusion

Antoniov. — Tue, 14 Sep 2004 02:01:43 GMT

Hi Wim,
what were your real intention?
Reading your command line I guess you forgot PIPE command and the output of edit is input of x command file.
Without PIPE, DCL ignore edit and execute x.com.

Antonio Vigliotti

Re: DCL confusion

Wim Van den Wyngaert — Tue, 14 Sep 2004 02:03:58 GMT

Antonio,

I tried to edit a file.
But my command was screwed while doing cut/paste.

But why did edit execute the part of the name of the file ?

Re: DCL confusion

Jan van den Ende — Tue, 14 Sep 2004 02:26:54 GMT

Wim,

the @-sign essentially specifies indirection.

Even in
@commandoprocedure.com
you essentially just specify:
I want a number of commands executed, and they are in Commandprocedure.com

In case of your accidental command construct, it is taken to mean: find your actions to be performed on SYS$PIPE in ops$proc:x.com
How this exactly works out in case of edit/tpu appears to be doing something, but I don't dare guess at details.

Although, you did NOT use the PIPE command??
On second thought I would GUESS that it is interpreted more or less similar to
edit/tpu /command=...

fwiw

Jan

Re: DCL confusion

Antoniov. — Tue, 14 Sep 2004 02:30:21 GMT

Wim,
old problem; @ Symbol is parsed before any other token in line.
If you type
$ @x.com
the parser execute x.com;
I don't know why but this happens since V6.2.

Antonio Vigliotti

Re: DCL confusion

Uwe Zessin — Tue, 14 Sep 2004 02:38:57 GMT

It is not a 'problem' and it is not 'new' (V6.2) - it is an old hang-over from the RSX operating system where it was called 'command indirection' and as far as I can tell has always been present in VMS.

$$ create a.tmp
sys$login:*.com;
*Exit*
$$ directory @a.tmp

Directory USER_XYZ:[ZESSIN]

LOGIN.COM;1 LOGIN2.COM;1

Total of 2 files.
$$

Re: DCL confusion

Wim Van den Wyngaert — Tue, 14 Sep 2004 15:26:48 GMT

Uwe,

Do I understand correctly : the contents of the file is placed on the command line.

But how to explain that EDIT/TPU executes it as a command file but line per line ?

WIm

Re: DCL confusion

Wim Van den Wyngaert — Tue, 14 Sep 2004 15:27:47 GMT

Uwe,

And where is this documented (or is it undocumented ??) ?

Wim

Re: DCL confusion

Guenther Froehlin — Tue, 14 Sep 2004 16:23:37 GMT

It's in the DCL Dictionary under '@'.

Basically what it does DCL extends your EDIT command line with the 1st line from the command procedure which I guess caused an error. The '@' redirected (temporarily) DCL input to your command procedure and DCL executes it line-by-line.

/Guenther

Re: DCL confusion

John Gillings — Tue, 14 Sep 2004 16:28:44 GMT

"@" on the command line has worked like this since VMS V1.0 (I know, I logged a question similar to Wim's with the CSC back in 1978). You can place parts of the command line into a file and access them

For example, consider LIST.COM:

FILE1.TXT, FILE2.TXT, FILE3.TXT

$ TYPE/PAGE @LIST

will substitute the contents of LIST.COM into the TYPE command. Everything needs to be placed on the first line, or use continuation lines.

What's very strange is that lines following the first are executed after completion of the command. So changing LIST.COM to

FILE1.TXT, FILE2.TXT, FILE3.TXT
$ SHOW TIME

will execute the SHOW TIME command after TYPE completes.

The procedure also takes parameters like any other procedure. Consider:

FILE1.TXT, 'p1'.TXT, 'p2'.TXT
$ SHOW TIME
$ 'p3'

$ TYPE @LIST FILE2 FILE3 "SHOW PROCESS"

This will type the 3 files, then show time then show process.

I've often thought this *looks* useful, but never really found a compelling use for it.

It is documented, see "HELP @" - " or requests the command interpreter to read subsequent command input from a specific file or device"

Also note it's caused MAIL all kinds of trouble!

Re: DCL confusion

Bojan Nemec — Wed, 15 Sep 2004 01:26:39 GMT

Hi,

The documentation is there http://h71000.www7.hp.com/doc/732FINAL/9996/9996pro_001.html#blue_3

As mentioned by John is very important what is in the first line of the command procedure. The contents of the first line must be a logical continuation of the line before the @ sign.

The explanation (my) is that DCL substitute the input from the current input, in which you are typing or executing the command, with the command precedure after the @ sign. When read encounters the end of line (which is end of command line) executes that line (prefixed with the start of the line which contains the @ sign) and (when finished) continue with other lines in the command procedure.

You can test this, with a command procedure which starts as this:
SYS$INPUT
.
.

and then run with:
$ show logical @x.com

You will see that the sys$input is the disk where x.com resides.

About the key pipe separator (|) I receive only a file specification error. The file name cannot end with |.

Bojan

Re: DCL confusion

Wim Van den Wyngaert — Mon, 20 Sep 2004 01:26:44 GMT

Thanks John, Bojan.

TPU handles it correctly. It expanded the command line. That resulted in too many parameters (the | was not even analyzed because part of a parameter).

After that it started executing line 2, 3 ... of the command procedure.

Strange is :

$ ty wim.lis
/read
$ show time
$ x=1
$ sh symbol x
show time
$ exit

$ edit/tpu wim.lis @wim.lis
%DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters
20-SEP-2004 08:24:53
X = 1 Hex = 00000001 Octal = 00000000001
20-SEP-2004 08:24:53

Why the too many parameters ?

Wim

Re: DCL confusion

Uwe Zessin — Mon, 20 Sep 2004 01:33:22 GMT

Because DCL is simple-minded. Try this:

$ edit/tpu wim.lis@wim.lis

Re: DCL confusion

Wim Van den Wyngaert — Mon, 20 Sep 2004 01:35:26 GMT

Uwe,

$ edit/tpu wim.lis@wim.lis
%TPU-E-NONANSICRT, SYS$INPUT must be supported CRT

Re: DCL confusion

Bojan Nemec — Mon, 20 Sep 2004 01:38:07 GMT

Hi,

The response is in the link I posted in my previous post.

"If the file begins with qualifiers for the command, do not precede the @ command with a space."

So
$ edit/tpu wim.lis@wim.lis
will be right.
But now you will get:
%TPU-E-NONANSICRT, SYS$INPUT must be supported CRT
because SYS$INPUT is wim.lis

Bojan

Re: DCL confusion

Uwe Zessin — Mon, 20 Sep 2004 01:38:47 GMT

Sure! What did you expect? WIM.LIS is a file, no terminal device.

Re: DCL confusion

Wim Van den Wyngaert — Mon, 20 Sep 2004 01:41:16 GMT

Yes Bojan. But why ?

It seems that the @wim.lis is done and that the first line is prefixed with edit/tpu wim.lis.

And why was this feature invented ?

Wim

Re: DCL confusion

Uwe Zessin — Mon, 20 Sep 2004 01:45:54 GMT

The input file is not closed, because DCL only read one line to finish the current command:

$$create a.tmp
sys$login:*.com;
$ write sys$output "?"
Exit
$$directory @a.tmp

Directory USER_XYZ:[ZESSIN]

LOGIN.COM;1 LOGIN2.COM;1

Total of 2 files.
? <=========
$$

Again, the feature predates VMS. It is powerful, but as you can see it can have side-effects.

Re: DCL confusion

Bojan Nemec — Mon, 20 Sep 2004 03:00:31 GMT

Wim,

As Uwe says (and me in my post from Sep 15) the command edit/tpu wim.lis is continued with the first line of wim.lis and terminated (executed) at the end of the first line. The SYS$INPUT is now redirected to wim.lis.

This feature can be used to have more flexible commands. For example:

$ open/write b bac.lis
$ prefix=""
$l:
$ f = f$search(spec)
$ if f.eqs."" then goto b
$ if SOME_TEST_ON_FILE
$ then
$ write b prefix,f,"-"
$ prefix = ","
$ endif
$ goto l
$b:
$ write b "TAPE:"
$ close b
$ backup @bac.lis

(Dont know if this works, it was not tested, I write this only to explain the usage)

Bojan

Re: DCL confusion

Hein van den Heuvel — Mon, 20 Sep 2004 09:21:27 GMT

>>> Yes Bojan. But why ?

Why now?
- Because it has been like that since version 1 and some customer out there MIGHT be relying on this behaviour (I doubt it, but that's irrelevant).

Why in V1?
Guess-1) I looked back through old notes, but the only thing I can come up with is RSX compatbility. The 'at' processor must have worked that way? Maybe.
Guess-2) In an attempt to deal with the lack of symbol substitution in the data stream? Nah.
Guess-3) Just as 'convenient', but poorly designed, way to stick a bunch of commonly used switches and arguments in a file!? Hmmm... could be. This was (well) before command line editting remember!?

Why execute the commands?
- Because it would me more work to do anything else? Because SYS$INPUT is redirected 'unconditionally'. No special check whether the command that started this was all done.

Why in RSX? (if that was the reason)?
Because of coding/QIO restrictions limiting command length read from termail versus file?
I'm kinda making this up, because the command buffer itself still needs to be as big.

In summary, my best guesses are:
- It started to allow for short command lines
- The implementation caused the 'command' side effect.
- The latter behaviou got documented instead of fixed and now we are stuck with it.

Hein.