Discussion:
SYS$CREPRC output to file but its overriding and not appending
Add Reply
HCorte
2021-11-04 15:52:15 UTC
Reply
Permalink
Running a script/command procedure using the CREPRC with the image LOGINOUT the OUTPUT_PATH is a logical name as is the SCRIPT_PATH and ERROR_PATH.
The logical name OUTPUT_PATH point to a file.LOG;1 specifying the version 1 to not generate multiple files since its running every 5 seconds the script/SYS$CREPRC.

ISTAT = SYS$CREPRC(pidadr,"SYS$SYSTEM:LOGINOUT.EXE",
* SCRIPT_PATH, !input
* OUTPUT_PATH, !output log
* ERROR_PATH, !error log
* ,,"MILLCON",,,,) !process name

But instead of appending the new log information to the preexisting one its simply overriding.

In documentation
VSI_PROGRAM_CONCEPTS_VOL_I.pdf

page 28 refers to
"In a program that creates a subprocess, you can cause the subprocess to share the input, output, or error device of the creating process"

that's not the case that interest me but later on talks about

"Use the Assign I/O Channel (SYS$ASSIGN) system service to assign an I/O channel to the device for input/output operations."

so my question is SYS$ASSIGN the way to go to make the new log info append to the existing one on file.LOG;1? a bit lost at this point ...

Thanks for any help.
Simon Clubley
2021-11-04 19:02:38 UTC
Reply
Permalink
Post by HCorte
Running a script/command procedure using the CREPRC with the image LOGINOUT the OUTPUT_PATH is a logical name as is the SCRIPT_PATH and ERROR_PATH.
The logical name OUTPUT_PATH point to a file.LOG;1 specifying the version 1 to not generate multiple files since its running every 5 seconds the script/SYS$CREPRC.
That is as expected given the specification of a version number.

Normally VMS handles this by creating an higher version of the existing
log files, but you have overridden that.

However, VMS has the concept of a Process Permanent File (PPF).
I wonder if there's any way to open a file in DCL and then pass a
reference to it in the output descriptor of your sys$creprc() call ?

I vaguely remember that PPF files are referenced via some internal
structure instead of via a normal filename, but I don't know if that's
anything which you can access (even if I have remembered that correctly).

However, rather than starting a new process every 5 seconds, can whatever
you are doing stay within an ongoing loop, pausing every 5 seconds ?

You can always use something like a control file (which the subprocess
looks for) to shutdown the subprocess.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Lawrence D’Oliveiro
2021-11-05 00:48:22 UTC
Reply
Permalink
Post by Simon Clubley
However, VMS has the concept of a Process Permanent File (PPF).
I wonder if there's any way to open a file in DCL and then pass a
reference to it in the output descriptor of your sys$creprc() call ?
No, because channels open in one process are not passed to another process. You’re thinking in “fork” terms, but VMS does “spawn”, not “fork”.
Simon Clubley
2021-11-05 18:36:14 UTC
Reply
Permalink
Post by Simon Clubley
However, VMS has the concept of a Process Permanent File (PPF).
I wonder if there's any way to open a file in DCL and then pass a
reference to it in the output descriptor of your sys$creprc() call ?
No, because channels open in one process are not passed to another process. You?re thinking in ?fork? terms, but VMS does ?spawn?, not ?fork?.
sys$creprc() itself runs in the context of the parent process.
It just happens to create a subprocess while its running.

The question is, does the output file get created in the context of
the parent process during the execution of sys$creprc() or in the
context of the subprocess ?

IOW, does sys$creprc() create the output file or does something in
the newly created subprocess do that ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
V***@SendSpamHere.ORG
2021-11-05 21:33:12 UTC
Reply
Permalink
Post by Simon Clubley
Post by Simon Clubley
However, VMS has the concept of a Process Permanent File (PPF).
I wonder if there's any way to open a file in DCL and then pass a
reference to it in the output descriptor of your sys$creprc() call ?
No, because channels open in one process are not passed to another process. You?re thinking in ?fork? terms, but VMS does ?spawn?, not ?fork?.
sys$creprc() itself runs in the context of the parent process.
Correct.
Post by Simon Clubley
It just happens to create a subprocess while its running.
Not necessarily so. It's true if the $CREPRC is invoked to create a
subprocess.
Post by Simon Clubley
The question is, does the output file get created in the context of
the parent process during the execution of sys$creprc() or in the
context of the subprocess ?
IOW, does sys$creprc() create the output file or does something in
the newly created subprocess do that ?
$CREPRC does not create any file.

Hint: In the original post in this thread there is a snippet of code
with the answer.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Simon Clubley
2021-11-06 20:20:23 UTC
Reply
Permalink
Post by V***@SendSpamHere.ORG
Post by Simon Clubley
The question is, does the output file get created in the context of
the parent process during the execution of sys$creprc() or in the
context of the subprocess ?
IOW, does sys$creprc() create the output file or does something in
the newly created subprocess do that ?
$CREPRC does not create any file.
Thank you Brian. I couldn't fully remember _what_ created the output file.

Oh, well. So much for that idea. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Lawrence D’Oliveiro
2021-11-06 00:45:43 UTC
Reply
Permalink
Post by Simon Clubley
sys$creprc() itself runs in the context of the parent process.
There is only the bare minimum EXE$CREPRC can do there. Remember that open files are accessed through I/O channels, which are indexes into the CCB array. Which lives in P1 space. Which, for the new process, doesn’t exist yet.

Reference: Chapter 25, “Process Creation”, of the latest version of the IDSM I can find <http://bitsavers.trailing-edge.com/pdf/dec/vax/vms/training/EY-C171E-DP_VMS_Internals_and_Data_Structures_5.2_1991.pdf>. The bulk of process setup happens in the context of the new process itself, in EXE$PROCSTRT. You will notice that there is no mention of it actually opening any files (apart from the image being activated, of course).

SYS$INPUT, SYS$OUTPUT and SYS$ERROR are predefined, but a program still needs to open them before it can use them.
Stephen Hoffman
2021-11-04 19:05:21 UTC
Reply
Permalink
Post by HCorte
Running a script/command procedure using the CREPRC with the image
LOGINOUT the OUTPUT_PATH is a logical name as is the SCRIPT_PATH and
ERROR_PATH.
...
so my question is SYS$ASSIGN the way to go to make the new log info
append to the existing one on file.LOG;1? a bit lost at this point ...
LOGINOUT creates new logs. LOGINOUT will not append to existing logs.

If you want that—and I don't recommend the approach—then you'll likely
best aim the process output at a mailbox, and then write an app (or use
COPY, if you're hacking this) that drains and logs the mailbox traffic.

Parsing command output from OpenVMS commands has long been considered
unstable and unsupported and subject to change without notice, too.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2021-11-04 20:04:59 UTC
Reply
Permalink
Post by HCorte
Running a script/command procedure using the CREPRC with the image LOGINOUT the OUTPUT_PATH is a logical name as is the SCRIPT_PATH and ERROR_PATH.
The logical name OUTPUT_PATH point to a file.LOG;1 specifying the version 1 to not generate multiple files since its running every 5 seconds the script/SYS$CREPRC.
ISTAT = SYS$CREPRC(pidadr,"SYS$SYSTEM:LOGINOUT.EXE",
* SCRIPT_PATH, !input
* OUTPUT_PATH, !output log
* ERROR_PATH, !error log
* ,,"MILLCON",,,,) !process name
But instead of appending the new log information to the preexisting one its simply overriding.
In documentation
VSI_PROGRAM_CONCEPTS_VOL_I.pdf
page 28 refers to
"In a program that creates a subprocess, you can cause the subprocess to share the input, output, or error device of the creating process"
that's not the case that interest me but later on talks about
"Use the Assign I/O Channel (SYS$ASSIGN) system service to assign an I/O channel to the device for input/output operations."
so my question is SYS$ASSIGN the way to go to make the new log info append to the existing one on file.LOG;1? a bit lost at this point ...
Thanks for any help.
I'm too lazy to look, been a while since I've been into CREPRC. But I
think I'll be getting back into it soon.

How about not specifying an output, and then in the created process,
open for append the desired log file?

Are you using a command file in the created process, or just invoking
a program?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Andrew Commons
2021-11-06 11:35:41 UTC
Reply
Permalink
Running a script/command procedure using the CREPRC with the image LOGINOUT the OUTPUT_PATH is a logical name as is the SCRIPT_PATH and ERROR_PATH.
The logical name OUTPUT_PATH point to a file.LOG;1 specifying the version 1 to not generate multiple files since its running every 5 seconds the script/SYS$CREPRC.
ISTAT = SYS$CREPRC(pidadr,"SYS$SYSTEM:LOGINOUT.EXE",
* SCRIPT_PATH, !input
* OUTPUT_PATH, !output log
* ERROR_PATH, !error log
* ,,"MILLCON",,,,) !process name
But instead of appending the new log information to the preexisting one its simply overriding.
In documentation
VSI_PROGRAM_CONCEPTS_VOL_I.pdf
page 28 refers to
"In a program that creates a subprocess, you can cause the subprocess to share the input, output, or error device of the creating process"
that's not the case that interest me but later on talks about
"Use the Assign I/O Channel (SYS$ASSIGN) system service to assign an I/O channel to the device for input/output operations."
so my question is SYS$ASSIGN the way to go to make the new log info append to the existing one on file.LOG;1? a bit lost at this point ...
Thanks for any help.
So, is the OUTPUT for the main script assigned to the OUTPUT_PATH so that the process and the sub-process are actually sharing it?
Loading...