sys$input question

[Layne Burleson_1]

When logging into VMS 7.3-2 alpha server, a show logical cmd will show the NTY device as the definition for sys$input. If you create a .com procedure with a show logical sys$input as the top line, it will display dsa2: as the definition. I put a $set verify in the top of the .com procedure but can't find anywhere that redefined sys$input. Any ideas why it is different or where I can look?

[Hein van den Heuvel · Accepted solution]

The command file is reading from a file on disk right? So the (sys$)input device is a disk. Makes sense?

Try this command file
$show log sys$input
$show log sys$command
$type sys$input

this data line can from the command file

now switch to input fromthe terminal

please enter some text, end with control-Z"

$define /user sys$input sys$command
$type sys$input
$
$write sys$output "demonstration with EDT (quit to exit)"
$EDITTTT/EDT/NOCOM sys$login:login.com
s/blah blah/blah blah/
$write sys$output "at DCL level, go back into edt for real...
$define /user sys$input sys$command
$EDITTTT/EDT/NOCOM sys$login:login.com
$exit


Cheers,
Hein.

[Robert Gezelter]

Burleson,

As Hein has noted, the command file is a disk.

SYS$INPUT is the "current" input device. I do not have the time for a full exposition, but my recollection is that there is a good description of the behavior of the various logical names (SYS$INPUT, SYS$COMMAND, and SYS$ERROR) in either the OpenVMS User's Manual or in the DCL Dictionary, both of which are online at http://www.hp.com/go/openvms (if my recollection is faulty, then it is is one of the other manuals).

- Bob Gezelter, http://www.rlgsc.com

[Layne Burleson_1]

Thanks Hein & Bob. That answers it.

[Jess Goodman]

Burleson,

This is one of the great features of VMS. When you are entering commands from a terminal there are two different logicals you could use to get input, SYS$INPUT and SYS$COMMAND. From a terminal they will both work the same.

But when you execute commands from within a DCL .COM file SYS$INPUT is automatically redefined to be that .COM file (Unfortunately, as you discovered, SHOW LOGICAL SYS$INPUT only shows the device name but it has a hidden binary value that points to the current command file). When the .COM file exits SYS$INPUT will point to the terminal again.

SYS$COMMAND will always point to the terminal for an interactive process.

This behaviour allows you to write a .COM file that runs programs which can get their input either from the command file, or from the user running the command file. For example...

Interactive commands:
$ RUN PROGRAMS:DINNER
Enter Ingrediant: DOUGH.FOOD
Enter Ingrediant: TOMATO_SAUCE.FOOD
Enter Ingrediant: CHEESE.FOOD
Enter Ingrediant: TOPPINGS.FOOD
Enter Ingrediant:
***Your dinner will be ready in 20 minutes***

But that's a lot of typing just to get a pizza. My wife complained about how cooking was a lot of work, so I wrote her a command file:

$!! PIZZA.COM
$ IF (F$MODE() .EQS. "INTERACTIVE")
$ THEN
$ WRITE SYS$OUTPUT "Enter your toppings."
$ DEFINE/USER SYS$INPUT SYS$COMMAND:
$ EDIT TOPPINGS.FOOD
$ ELSE
$ CREATE TOPPINGS.FOOD
MUSHROOMS
PEPPERONI
$ ENDIF
$!
$ RUN PROGRAMS:DINNER
DOUGH.FOOD
TOMATO_SAUCE.FOOD
CHEESE.FOOD
TOPPINGS.FOOD
$!
$ IF (F$MODE() .NES. "INTERACTIVE")
$ THEN
$ MAIL /SUBJECT="Dinner Time" SYS$INPUT ME
The pepperoni and mushroom pizza is ready.
$ ENDIF
$ EXIT

She really likes that if she will be out for the day she can just do:
$ SUBMIT PIZZA /AFTER=18:00

Note that DINNER and CREATE, like most programs, read input from SYS$INPUT. When they are run interactively this will be the terminal and end-of-input is indicated by typing .

When programs are run from a command file SYS$INPUT are the lines in the command file that immediately follow the command line that runs the program. End of input is indicated by the next line that begins with a $ from within a command file.

So lines in a command file that begin with a $ are interpreted by DCL and lines that don't (other than continuation lines) should be program input.

The EDIT command also reads its input from SYS$INPUT, but here even though you are running it from a command file you want EDIT to get its input from the terminal. This is accomplished by temporarily redefining SYS$INPUT to point to SYS$COMMAND right before running EDIT.

The last trick shown is the MAIL command line which expects a file name for its first parameter. Here I use SYS$INPUT for the file name so that the mail text that is used can follow the MAIL command line in the .COM file. This avoids having to create a file every time with the same text.