Process-permanent SYS$OUTPUT, WRITE SYS$OUTPUT and DEFINE /USER vs DEFINE /PROCESS

[Mark_Corcoran]

A colleague had recently made some changes to a command procedure that is invoked from the DCL command line, and it invokes another command procedure.

In the calling procedure, he changed it to do DEFINE /USER SYS$OUTPUT temporary_file before invoking the called procedure, and when the calling procedure was invoked, WRITE SYS$OUTPUT calls in the called procedure failed with the warning message "%DCL-W-UNDFIL, file has not been opened by DCL - check logical name".

Changing the code to wrap the invocation of the called procedure inside a DEFINE (/PROCESS) and DEASSIGN (/PROCESS) of SYS$OUTPUT works.

I was intrigued enough to try and find an explanation as to why this is the case, but I've been unable to (looked in DCL Dictionary, Programming Concepts, IDSM, User Manual).

I get that SYS$OUTPUT is a process-permanent file, and has special handling and does not need to be OPENed in order to WRITE to it.

I can't fathom why WRITE fails to write to SYS$OUTPUT if it has been redefined with DEFINE /USER, but does write to it if it has been redefined with DEFINE /PROCESS (the DEFINE /PROCESS doesn't create the file, and WRITE does not of itself open a channel to a new file).

My only thoughts are "magic jiggery-pokery" being undertaken by the CLI - can anyone provide a more detailed reason?

Mark

[Steven Schweda]

> A colleague [...]

> [...] had recently made some changes to a command procedure that is
> invoked from the DCL command line, and it invokes another command
> procedure. [...]

   An actual test case might be more helpful than any such (vague)
description.

> [...] In the calling procedure, he changed it to do DEFINE /USER
> SYS$OUTPUT temporary_file before invoking the called procedure, [...]

   Did anyone actually open that file?  The default SYS$OUTPUT may not
need it, but some plain-old file might.  For example:

ITS $ define /user_mode sys$output fred.out
ITS $ write sys$output "ABC"
%DCL-W-UNDFIL, file has not been opened by DCL - check logical name

   There's no need for nested DCL scripts to get that effect.

> [...] but does write to it if it has been redefined with DEFINE
> /PROCESS [...]

   I know nothing, but I might guess that invoking ("@") the sub-script
causes DCL to do things with whatever SYS$OUTPUT is at that time.

    So, your actual complaint is that invoking the sub-script makes it
all work better (or more easily) than it would if everything were at the
same level?

   I might stick some "show logical /full sys$output" statements in
various places if I were desperate for clues.

[abrsvc]

What you are missing is the reason/definition of the "/user" qualifier.  This qualifier means that the logical name assignment will last for one program execution.  Since many DCL commands are actually "programs" this means that the assignment will last for perhaps one or two commands at most..  This qualifier is used for truly temporary assignments.

For example, if you wanted to place the output of a program into file X.X, you could simply use the following:

$ ASSIGN/USER X.X SYS$OUTPUT

$ RUN PROGRAM_XYZ

With the above sequence there is no need for any DEASSIGN command as the logical assignment will be removed during the program rundown process.

In order to use the logical name assignment across a command procedure, you will need to ASSIGN and DEASSIGN the logical prior to entry and after exit respectively.

Hope this helps,

Dan