TT

[Wim Van den Wyngaert]

I have a procedure to do task-to-task from my workstation to all my servers. I use it to execute commands (some kind of rsh but I can select many nodes at once).
Some years ago, I used a procedure that sent the output to TT. As a result, net$server.com was overwritten. I hope I do not have to explain what the consequences were ...

Does anyone known why TT in task-to-task is assigned to net$server.com and not to e.g. net$server.log ?

[Jan van den Ende]

Wim,

TT is your interactive communication channel,
ie, it is for Input _AND_ Output.
You take your input from it, and write your output to it.
I only knew it in what may be considered the reverse of what you are doing:
interactive input to an image that wants input from a file can also get if from @TT.
A have the impression that TT is very much synonymous with SYS$COMMAND.

Jan

[Wim Van den Wyngaert]

Jan,

TT is in batch defined as nla0:. That seems a good choice and is not sys$command.

In my opinion t2t should have the same setting.

Btw : (in t2t and in batch) sys$command points to disk (dsaxx).

[Jan van den Ende]

Yes Wim,
I guess that would have been the more consistent implementation.
Anyone from engeneering with a more expert vision, plus reasoning?

Jan

[Antoniov.]

Wim,
as you know vms use 5 logical devices for I/O:
SYS$INPUT, SYS$OUTPUT, SYS$ERROR, SYS$COMMAND and TT.
In interactive mode they assume tha same value (the terminal id).
Inside DCL procedure, SYS$INPUT is command file, while TT is the terminal device; so command that's use SYS$INPUT (as EDIT/EDT) require follow command to work:
$ DEF SYS$INPUT SYS$COMMAND
Command that's access via TT direc work inside DCL commmand too.
In T2T TT has a new logical value, SYS$NET that's the I/O channel to partner I/O. So, if you write (in DCL command) follow code
$ IF (F$MODE().EQS."NETWORK") THEN -
DEFINE SYS$OUTPUT SYS$NET:
every output is send to called output.
Another importat different between SYS$* and TT is type of device. SYS$* can be redirect as file, TT is always a physical device not record oriented; it's wrong the follow code:
$ DEFINE TT "DKA0:"
At lower level this means you can use SYS$QIO to use TT device but you can't use it with SYS$INPUT.

Antonio Vigliotti

[John Gillings]

Wim,

The "TT" logical name is an anachronism. It stands for "teletype" and was included in VMS V1.0 for compatibility with DCL scripts brought from RSX systems.

Documentation is thin - it's defined as "The default device name for terminals". So, it really only makes sense in INTERACTIVE mode where there is a real terminal.

It's created at the same time as SYS$INPUT, with the same device name (which answers your question "why?"). For batch jobs it's specifically redefined as NLA0, presumably to avoid overwriting the command procedure.

For other modes it's sometimes defined and sometimes makes sense. Bottom like is it was obselete more than 25 years ago.

Don't expect it to change now, as if it were changed we're guaranteed it would break something. I'd suggest you either avoid it altogether, (especially in contexts where it may be referenced from non-INTERACTIVE modes) or use LOGIN.COM to define it to be whatever you want it to be, but remember that makes you dependent on your node specific environment. If you MUST use it, remember that it's primarily intended to be for INPUT, not OUTPUT.

The logical name "TT" was only ever intended to be used while porting RSX procedures, which one would hope have all been completed by now ;-) It would have been removed long ago, except for the "VMS way" of always preserving compatibility.

The system logical names SYS$INPUT, SYS$OUTPUT, SYS$COMMAND and SYS$ERROR are always defined, and always "make sense" in all modes. These are what you should be using in new procedures.

[Wim Van den Wyngaert]

John,

I can not imagine that ANYONE needs to write their output to the command procedure it is executing. So it will only lead to accidents and has no usage. It should be replaced by the batch value (nl).

Wim

[John Gillings]

Wim,

> I can not imagine that ANYONE needs to write their output to the command procedure it is executing.

Agreed, but you also shouldn't be using an obselete definition for an INPUT device for output. Directing output to TT can hurt, just as can:

$ WRITE SYS$INPUT "something"

Doesn't make sense. Right? Well that's what you're doing when you direct output to TT.

This is what is refered to in the CSC as a "Doctor-it-hurts-when-I-bang-my-head-against-the-wall" type report. The obvious answer is "So don't do it!".

I recommend you forget "TT" exists and use the correct logical names for input and output streams. Something this old doesn't get changed, especially when there's a better alternative. Changes are almost guaranteed to break something, somewhere.

About the only reasonable use for TT in recent times was the interactive command "@TT/OUTPUT=file" to capture output from commands that don't have a /OUTPUT qualifier. (Note that this uses TT as an INPUT device). Even that is now obselete with

$ PIPE command > file

[Antoniov.]

Wim,
what do you think about me?

Antonio Vigliotti

[Wim Van den Wyngaert]

John,

I often use T2T for executing command procedures "interactively". If I have to check each of them for TT usage I can better log myself on each system and execute it by hand. And the accident I had was with instructions for SDA usage that I received from HP ... (obsolete instructions ?).

Antonio,

No hard feelings but your info was no answer for my question. Keep up the good work !

Wim

[Antoniov.]

Wim,
just for curiosity, did I written something unpleased for you?
Sorry if I made it.
If you prefer write to antoniov at shs-av.it

Antonio Vigliotti