1828328 Members
3593 Online
109976 Solutions
New Discussion

DCL confusion

 
SOLVED
Go to solution
Wim Van den Wyngaert
Honored Contributor

DCL confusion

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
Wim
19 REPLIES 19
Antoniov.
Honored Contributor

Re: DCL confusion

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
Antonio Maria Vigliotti
Wim Van den Wyngaert
Honored Contributor

Re: DCL confusion

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 ?
Wim
Jan van den Ende
Honored Contributor

Re: DCL confusion

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

Don't rust yours pelled jacker to fine doll missed aches.
Antoniov.
Honored Contributor

Re: DCL confusion

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
Antonio Maria Vigliotti
Uwe Zessin
Honored Contributor

Re: DCL confusion

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.
$$
.
Wim Van den Wyngaert
Honored Contributor

Re: DCL confusion

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
Wim
Wim Van den Wyngaert
Honored Contributor

Re: DCL confusion

Uwe,

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

Wim
Wim
Guenther Froehlin
Valued Contributor

Re: DCL confusion

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
John Gillings
Honored Contributor
Solution

Re: DCL confusion

"@" 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!
A crucible of informative mistakes
Bojan Nemec
Honored Contributor

Re: DCL confusion

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
Wim Van den Wyngaert
Honored Contributor

Re: DCL confusion

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
Wim
Uwe Zessin
Honored Contributor

Re: DCL confusion

Because DCL is simple-minded. Try this:

$ edit/tpu wim.lis@wim.lis
.
Wim Van den Wyngaert
Honored Contributor

Re: DCL confusion

Uwe,

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

Wim
Bojan Nemec
Honored Contributor

Re: DCL confusion

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
Uwe Zessin
Honored Contributor

Re: DCL confusion

Sure! What did you expect? WIM.LIS is a file, no terminal device.
.
Wim Van den Wyngaert
Honored Contributor

Re: DCL confusion

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
Wim
Uwe Zessin
Honored Contributor

Re: DCL confusion

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.
.
Bojan Nemec
Honored Contributor

Re: DCL confusion

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
Hein van den Heuvel
Honored Contributor

Re: DCL confusion


>>> 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.