Capturing STC SYSOUT when the STC is shut down

[Jon Bathmaker]

Hi,
We are running NVAS and the SYSPRINT file gets directed to SYSOUT=* which is fine as we can browse it if we need to.

For some reason (Audit request?) I am being asked to vacuum up the SYSOUT file and put it into a GDG when the task is recycled, while still leaving it as SYSOUT when the STC is active. . Based on a message I received, a disp of PASS and SYSOUT are incompatible. I am now considering using SDSF in batch so solve this problem (thanks to Lorne Heffer).

Anyone have any ideas? Using a commercial Program Product is a non-starter as, like everyone else the client is only interested in lower cost. Thanks.

Regards,
Jon Bathmaker

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Nims,Alva John , Al]

I think there are at least two options:
1. Since you have already mentioned SDSF, yes I believe you can use SDSF to copy the output and write it to a GDG, I have done it in the past, but unfortunately all that code of mine is gone and I no longer have access to SDSF to help you further.
2. This is also an option in that is readily available as part of z/OS and does not require installing any additional software; it does use a UNIQUE output class (it helps, but is not completely required) that you can start a JES2 external writer to read the SYSOUT and write to a GDG, you might have to submit a JOB or start a "Started Task" before leaving the original JOB to do that, because the SYSOUT must be closed and freed before the external writer can read the output.

There is a 3rd option, but ONLY IF you have $AVERS (Software Engineering of America (SEA)) I think it has options to do this where you do not need a unique output class and can be done by JOBName, I think, so don't quote me on that and if you do not already have $AVERS installed, it is a moot point, unless you are ready to spend money.

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
[phone]

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jon Bathmaker
Sent: Tuesday, August 16, 2016 10:38 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Capturing STC SYSOUT when the STC is shut down

Hi,
We are running NVAS and the SYSPRINT file gets directed to SYSOUT=* which is fine as we can browse it if we need to.

For some reason (Audit request?) I am being asked to vacuum up the SYSOUT file and put it into a GDG when the task is recycled, while still leaving it as SYSOUT when the STC is active. . Based on a message I received, a disp of PASS and SYSOUT are incompatible. I am now considering using SDSF in batch so solve this problem (thanks to Lorne Heffer).

Anyone have any ideas? Using a commercial Program Product is a non-starter as, like everyone else the client is only interested in lower cost. Thanks.

Regards,
Jon Bathmaker

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[saul anthony babonas]

The requirement to keep and archive SYSOUT can be done as
follows............

//SYSOUT DD
DSN=YOUR.SYSPRINT.GDG.DATASET(+1),DISP=(NEW,CATLG,DELETE),etc,etc

The additional requirement to view while the STC is up and running.....
......sorry but retirement has impacted by memory of gadgetry but
there's a simple method to write SYSOUT to 2 DD cards, the 2nd of
which will be SDSF viewable. Someone younger I hope can chime in.

Post by Nims,Alva John , Al
1. Since you have already mentioned SDSF, yes I believe you can use SDSF to copy the output and write it to a GDG, I have done it in the past, but unfortunately all that code of mine is gone and I no longer have access to SDSF to help you further.
2. This is also an option in that is readily available as part of z/OS and does not require installing any additional software; it does use a UNIQUE output class (it helps, but is not completely required) that you can start a JES2 external writer to read the SYSOUT and write to a GDG, you might have to submit a JOB or start a "Started Task" before leaving the original JOB to do that, because the SYSOUT must be closed and freed before the external writer can read the output.
There is a 3rd option, but ONLY IF you have $AVERS (Software Engineering of America (SEA)) I think it has options to do this where you do not need a unique output class and can be done by JOBName, I think, so don't quote me on that and if you do not already have $AVERS installed, it is a moot point, unless you are ready to spend money.
Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
[phone]
-----Original Message-----
Sent: Tuesday, August 16, 2016 10:38 AM
Subject: Capturing STC SYSOUT when the STC is shut down
Hi,
We are running NVAS and the SYSPRINT file gets directed to SYSOUT=* which is fine as we can browse it if we need to.
For some reason (Audit request?) I am being asked to vacuum up the SYSOUT file and put it into a GDG when the task is recycled, while still leaving it as SYSOUT when the STC is active. . Based on a message I received, a disp of PASS and SYSOUT are incompatible. I am now considering using SDSF in batch so solve this problem (thanks to Lorne Heffer).
Anyone have any ideas? Using a commercial Program Product is a non-starter as, like everyone else the client is only interested in lower cost. Thanks.
Regards,
Jon Bathmaker
----------------------------------------------------------------------
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Lizette Koehler]

One other complex process to leave it on SPOOL as well as archive it is to do the following

S STC1

//STC1 ...
//SYSOUT dd DISP=(,CATLG),DSN=GDG(+1),....more jcl
//*
//ENDSTP EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=
//SYSUT1 DD DISP=OLD,DSN=GDG(+1)
//SYSUT2 DD SYSOUT=*


This process writes the SYSOUT to a permanent GDG (No viewing while GDG is up) When it comes down the IEBGENER step will then write the SYSOUT to SPOOL and keep the GDG for archive.

But if you want to view the SYSOUT while the SYSOUT is up and then copy it to DASD/TAPE for ARCHIVE then the JES2DISK as the last step would work. I use JES2DISK all the time. Takes up all or part of the output on Spool. I even added a logging function to it so I have jobname/jobnum/date/time/CC in a nice little SEQ file to match my files I just created.


Lizette

Post by Nims,Alva John , Al
-----Original Message-----
Behalf Of saul anthony babonas
Sent: Tuesday, August 16, 2016 11:58 AM
Subject: Re: Capturing STC SYSOUT when the STC is shut down
The requirement to keep and archive SYSOUT can be done as follows............
//SYSOUT DD
DSN=YOUR.SYSPRINT.GDG.DATASET(+1),DISP=(NEW,CATLG,DELETE),etc,etc
The additional requirement to view while the STC is up and running.....
......sorry but retirement has impacted by memory of gadgetry but there's a
simple method to write SYSOUT to 2 DD cards, the 2nd of which will be SDSF
viewable. Someone younger I hope can chime in.

Post by Nims,Alva John , Al
1. Since you have already mentioned SDSF, yes I believe you can use SDSF to

copy the output and write it to a GDG, I have done it in the past, but
unfortunately all that code of mine is gone and I no longer have access to
SDSF to help you further.

Post by Nims,Alva John , Al
2. This is also an option in that is readily available as part of z/OS and

does not require installing any additional software; it does use a UNIQUE
output class (it helps, but is not completely required) that you can start a
JES2 external writer to read the SYSOUT and write to a GDG, you might have to
submit a JOB or start a "Started Task" before leaving the original JOB to do
that, because the SYSOUT must be closed and freed before the external writer
can read the output.

Post by Nims,Alva John , Al
There is a 3rd option, but ONLY IF you have $AVERS (Software Engineering of

America (SEA)) I think it has options to do this where you do not need a
unique output class and can be done by JOBName, I think, so don't quote me on
that and if you do not already have $AVERS installed, it is a moot point,
unless you are ready to spend money.

Post by Nims,Alva John , Al
Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
[phone]
-----Original Message-----

Behalf Of Jon Bathmaker

Post by Nims,Alva John , Al
Sent: Tuesday, August 16, 2016 10:38 AM
Subject: Capturing STC SYSOUT when the STC is shut down
Hi,
We are running NVAS and the SYSPRINT file gets directed to SYSOUT=* which is

fine as we can browse it if we need to.

Post by Nims,Alva John , Al
For some reason (Audit request?) I am being asked to vacuum up the SYSOUT

file and put it into a GDG when the task is recycled, while still leaving it
as SYSOUT when the STC is active. . Based on a message I received, a disp of
PASS and SYSOUT are incompatible. I am now considering using SDSF in batch
so solve this problem (thanks to Lorne Heffer).

Post by Nims,Alva John , Al
Anyone have any ideas? Using a commercial Program Product is a non-starter

as, like everyone else the client is only interested in lower cost. Thanks.

Post by Nims,Alva John , Al
Regards,
Jon Bathmaker

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Ed Jaffe]

Post by Jon Bathmaker
Hi,
We are running NVAS and the SYSPRINT file gets directed to SYSOUT=* which is fine as we can browse it if we need to.
For some reason (Audit request?) I am being asked to vacuum up the SYSOUT file and put it into a GDG when the task is recycled, while still leaving it as SYSOUT when the STC is active. . Based on a message I received, a disp of PASS and SYSOUT are incompatible. I am now considering using SDSF in batch so solve this problem (thanks to Lorne Heffer).
Anyone have any ideas? Using a commercial Program Product is a non-starter as, like everyone else the client is only interested in lower cost. Thanks.

Note: SDSF _is_ a commercial Program Product with an associated price tag.

You might consider a second step in your NVAS STC that will copy the
previous step's SYSPRINT to the disk file of your choosing right before
the STC terminates. Here's how I would likely do it with (E)JES. SDSF
should have a similar capability, but I'm not sure how you get the
"current" job name and/or number into variables you can use for
selection purposes. You might have to do it through REXX instead.

//NVAS EXEC PGM=...
//SYSPRINT DD SYSOUT=*
//*
//COPY2DSK EXEC PGM=EJESLNK
//EJESOUT DD DUMMY,RECFM=FB,LRECL=80
//EJESIN DD *
PRESET;J=&JNU;ST
:S
S SYSPRINT E
//EJESEXT DD DSN=gdg.name(+1),...
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Lizette Koehler]

If you are JES2 you can always setup a TRANSMIT/RECEIVE OFFLOADER function. JES2 can continually write to tape or disk any queue.

Look up JES2 Offloader function. Fairly easy to set up


Other option is John McKown's JES2DISK REXX that uses SDSF functions.
https://gist.github.com/JohnArchieMckown/b27747d0c4750a258997

You can run this in batch. Copy to Disk or Unix file.

Post by Nims,Alva John , Al
-----Original Message-----
Behalf Of Jon Bathmaker
Sent: Tuesday, August 16, 2016 7:38 AM
Subject: Capturing STC SYSOUT when the STC is shut down
Hi,
We are running NVAS and the SYSPRINT file gets directed to SYSOUT=* which is
fine as we can browse it if we need to.
For some reason (Audit request?) I am being asked to vacuum up the SYSOUT file
and put it into a GDG when the task is recycled, while still leaving it as
SYSOUT when the STC is active. . Based on a message I received, a disp of
PASS and SYSOUT are incompatible. I am now considering using SDSF in batch
so solve this problem (thanks to Lorne Heffer).
Anyone have any ideas? Using a commercial Program Product is a non-starter
as, like everyone else the client is only interested in lower cost. Thanks.
Regards,
Jon Bathmaker

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Jesse 1 Robinson]

I think that the problem with writing to *any* data set on whatever medium is that it cannot be read while it's open for output. It seems that the log file must be written to sysout (for concurrent examination) and then captured to a data set after it's closed.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Tuesday, August 16, 2016 9:16 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Capturing STC SYSOUT when the STC is shut down

If you are JES2 you can always setup a TRANSMIT/RECEIVE OFFLOADER function. JES2 can continually write to tape or disk any queue.

Look up JES2 Offloader function. Fairly easy to set up


Other option is John McKown's JES2DISK REXX that uses SDSF functions.
https://gist.github.com/JohnArchieMckown/b27747d0c4750a258997

You can run this in batch. Copy to Disk or Unix file.

Post by Nims,Alva John , Al
-----Original Message-----
On Behalf Of Jon Bathmaker
Sent: Tuesday, August 16, 2016 7:38 AM
Subject: Capturing STC SYSOUT when the STC is shut down
Hi,
We are running NVAS and the SYSPRINT file gets directed to SYSOUT=*
which is fine as we can browse it if we need to.
For some reason (Audit request?) I am being asked to vacuum up the
SYSOUT file and put it into a GDG when the task is recycled, while still leaving it as
SYSOUT when the STC is active. . Based on a message I received, a disp of
PASS and SYSOUT are incompatible. I am now considering using SDSF in batch
so solve this problem (thanks to Lorne Heffer).
Anyone have any ideas? Using a commercial Program Product is a non-starter
as, like everyone else the client is only interested in lower cost. Thanks.
Regards,
Jon Bathmaker

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Ed Jaffe]

Post by Jesse 1 Robinson
I think that the problem with writing to *any* data set on whatever medium is that it cannot be read while it's open for output. It seems that the log file must be written to sysout (for concurrent examination) and then captured to a data set after it's closed.

I believe Lizette's proposal does exactly that.

IIUC, the output is written to SYSOUT (where it can be browsed) while
NVAS is running and will be transmitted only after it terminates.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Paul Gilmartin]

Post by Jesse 1 Robinson
I think that the problem with writing to *any* data set on whatever medium is that it cannot be read while it's open for output. It seems that the log file must be written to sysout (for concurrent examination) and then captured to a data set after it's closed.

That may depend on whether you're willing to write to the data set
with DISP=SHR. RACF can protect you a lot. Allocate DISP=NEW in
an earlier job step; lately you can (Admins willing) downgrade the
ENQ to SHR for the later job step.

Decades ago I used ISPF Browse to view data sets being written.
Sporadic I/O errors; buffering latency; need to END and re-enter
to refresh. Processors are so fast now (and SDSF exists) that
I'n no longer tempted to do that.

If the client has or is willing to pay for SDSF a following step
using the Rexx (or other) API can capture the SYSOUT. The SDSF
Ref/Guide has a useful example. Ironically (absurdly) as Ed J.
has noted, the hardest part may be for a job to discern its own
Job ID.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[John McKown]

Post by Jesse 1 Robinson
I think that the problem with writing to *any* data set on whatever medium
is that it cannot be read while it's open for output. It seems that the log
file must be written to sysout (for concurrent examination) and then
captured to a data set after it's closed.

​If, by "data set", you mean a normal z/OS DSN=, that is true. But if you
write to a z/OS UNIX file (PATH=), it is not. A UNIX file can be read by a
separate process while is it still open & being written to. I guess this is
because the physical I/O to the UNIX file is actually done by the z/OS UNIX
kernel address space, or a filesystem colony address space. So the data
producer and consumer are really sending requests to the UNIX subsystem,
much like SPOOL I/O.​

[Jesse 1 Robinson]

My first reaction was to respond acerbically that file integrity never quite made the UNIX afterthought list, but that would have been unkind, so I won't. But if it works, it might be worth a try. It's not customer data anyway...

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
***@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of John McKown
Sent: Tuesday, August 16, 2016 10:31 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Capturing STC SYSOUT when the STC is shut down

Post by Jesse 1 Robinson
I think that the problem with writing to *any* data set on whatever
medium is that it cannot be read while it's open for output. It seems
that the log file must be written to sysout (for concurrent
examination) and then captured to a data set after it's closed.

​If, by "data set", you mean a normal z/OS DSN=, that is true. But if you write to a z/OS UNIX file (PATH=), it is not. A UNIX file can be read by a separate process while is it still open & being written to. I guess this is because the physical I/O to the UNIX file is actually done by the z/OS UNIX kernel address space, or a filesystem colony address space. So the data producer and consumer are really sending requests to the UNIX subsystem, much like SPOOL I/O.​



--
Klein bottle for rent -- inquire within.

Maranatha! <><
John McKown


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[John McKown]

This post might be inappropriate. Click to display it.

[Tom Brennan]

I think you're right Skip. My impression from some old coding attempts,
is that Unix by default lacks the kind of integrity we're used to seeing
on MVS. Clists and Rexx's die if they get an error but a shell script
just chugs along as if nothing happened. I remember coding a multi-task
program in C and if I wrote to stdout (the screen) from 2 tasks at about
the same time, one message might end up in the middle of another. This
is strange stuff that I would have thought would be taken care with an
enqueue under the covers.

My guess is it's just a different mentality. If you want to lock your
open file in Unix, you have to lock it yourself, otherwise a simpler
(and quicker) method is used where anybody can access and even write to
the same file at the same time as someone else.

I could be wrong with a lot of this... it's just my impression as a
part-time Unix user/programmer.

Post by Jesse 1 Robinson
My first reaction was to respond acerbically that file integrity never quite made the UNIX afterthought list, but that would have been unkind, so I won't. But if it works, it might be worth a try. It's not customer data anyway...

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Paul Gilmartin]

This post might be inappropriate. Click to display it.

[Tom Brennan]

Post by Paul Gilmartin
Ummm... no. A syntax error is immediately fatal to both shell script and
Rexx alike. Both provide means to trap the error and recover. In both
cases an error in a host (system) command sets a status (RC) value
which the programmer can test and process as proper.

I was thinking more of an RC <> 0 case with no extra code or settings to
catch errors. Maybe like this example where TEMP.DATA doesn't exist and
we never see "HERE 2" displayed:

WRITE HERE 1
ALLOC F(X) DA(TEMP.DATA) SHR REUSE
WRITE HERE 2

In Unix I might code this:

mkdir somedir
touch somedir/new.file

And I can run that as many times as I want and the script doesn't die if
the directory already exists (which is what I want anyway).

Post by Paul Gilmartin
Does C under z/OS behave differently from C under UNIX? From

I don't know. In the past (maybe with the pre-linker?) if the target
was a PDS, I'd get a perfectly good load module that ran under MVS. If
I pointed to a USS file, I'd get a perfectly good executable USS file.
I do remember needing code changes when trying to port from mainframe to
Windows or Linux, but MVS to USS needed no changes other than the
target. I think I did write a mini NNTP server on the mainframe one
day, with multiple tasks, and I don't remember any overlaying of
messages. But under testing there probably wasn't nearly enough
activity for that.

Post by Paul Gilmartin
UNIX protects directory integrity even as z/OS protects VTOC integrity.

Well that's good to know, at least the file system is protected!

Post by Paul Gilmartin
In both cases, UNIX and z/OS, it's elective.

I can't completely remember, but the one time I needed unix fopen() to
be exclusive, I think I also needed to call flock(). So I had to add
extra code to match what was already built in to z/OS.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Paul Gilmartin]

Post by Tom Brennan
I was thinking more of an RC <> 0 case with no extra code or settings to
catch errors. Maybe like this example where TEMP.DATA doesn't exist and
WRITE HERE 1
ALLOC F(X) DA(TEMP.DATA) SHR REUSE
WRITE HERE 2

And you want no chance to recover, perhaps by writing a message
to the terminal such as "Try a different data set name"?

In Rexx the error is non-fatal. Does this make Rexx unacceptable?

I recall discovering long ago that FREE DD(X) was fatal if X was not
allocated, but ALLOCATE DD(X) when X was already allocated issued
an error message but was not fatal. So I resorted to protecting myself
by routinely coding:
ALLOCATE DD(X) DUMMY
FREE DD(X)

... works all the time, but I felt like washing my hands whenever I had
to do that.

Post by Tom Brennan
mkdir somedir
touch somedir/new.file

Well, "sh -e" makes all errors fatal. But that's the "extra code or settings"
that you appear to loathe. Or you could just test the status after "mkdir".
Oops! Extra code again.

Sometimes I want an error to be fatal; sometimes I want to be able
to check status and decide whether I want to quit. In any case, I
like to have the choice.

Post by Tom Brennan
And I can run that as many times as I want and the script doesn't die if
the directory already exists (which is what I want anyway).

Post by Paul Gilmartin
UNIX protects directory integrity even as z/OS protects VTOC integrity.

Well that's good to know, at least the file system is protected!

Post by Paul Gilmartin
In both cases, UNIX and z/OS, it's elective.

I can't completely remember, but the one time I needed unix fopen() to
be exclusive, I think I also needed to call flock(). So I had to add
extra code to match what was already built in to z/OS.

"Built in"? You mean you didn't even have to code DISP=OLD!?

In a few cases, the syntax of JCL is more economical. In the great
majority the syntax of UNIX shell is more economical. An example

//STEP EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=(,)
//SYSIN DD *
//SYSUT2 DD DISP=(,CATLG),SPACE=(1000,1000),UNIT=SYSALLDA,DSN=OUTPUT.FILE
//SYSUT1 DD DISP=SHR,DSN=INPUT.FILE

versus:

cp input.file output.file

I see some "extra code or settings" in the first example. There aren't
even any defaults.

A modern desktop system provides a means of presenting an urgent
unsolicited message to the user, such as sounding the audible alert,
popping up a window with attributes "always on top, on all screens"
and text "System coming down in 5 minutes; please save your data!"
that I could ponder, dismiss, and take proper action.

Older desktop systems sounded the audible alert and presented the
message, yes, interleaved with other output. Still, I could refresh
the screen (ctrl-L), save my data, and log off.

ISPF/TSO/MVS/3270 believes erroneously that it's protecting the
integrity of something if I turn away with the keyboard unlocked to
consult a manual for those 5 minutes. I type another half-screen
of text and press ENTER. Only then do I hear the audible alert
and see the warning (which may vanish immediately), much too
late to save my data. I don't consider this integrity. At least it
should sound the audible alert regardless of the state of the terminal.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Paul Gilmartin]

Post by Ed Jaffe

Post by Jon Bathmaker
Hi,
We are running NVAS and the SYSPRINT file gets directed to SYSOUT=* which is fine as we can browse it if we need to.
For some reason (Audit request?) I am being asked to vacuum up the SYSOUT file and put it into a GDG when the task is recycled, while still leaving it as SYSOUT when the STC is active. . Based on a message I received, a disp of PASS and SYSOUT are incompatible. I am now considering using SDSF in batch so solve this problem (thanks to Lorne Heffer).

The SDSF Ops and Customization manual admits that Rexx is a better
alternative to SDSF in batch. That's easily true.

Post by Ed Jaffe

Post by Jon Bathmaker
Anyone have any ideas? Using a commercial Program Product is a non-starter as, like everyone else the client is only interested in lower cost. Thanks.

Note: SDSF _is_ a commercial Program Product with an associated price tag.

Yes, but is it nonetheless available to Jon's client?

Post by Ed Jaffe
You might consider a second step ... SDSF
should have a similar capability, but I'm not sure how you get the
"current" job name and/or number into variables you can use for
selection purposes. You might have to do it through REXX instead.

I can get job number with:
address ISPEXEC 'vget (ZSEQ) shared'

... I just need to claw my way upward from a batch job step,
through TSO, then through ISPF, then adapt the sample in
the SDSF manual.

I wonder whether it works while the job is executing?
Yes, at least in PoC. If it logs what it's doing, the output
ends in the middle of SYSTSPRT, right after the line that
says it's unloading SYSTSPRT. Very nice!

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[g***@gmail.com]

Post by Jon Bathmaker
Hi,
We are running NVAS and the SYSPRINT file gets directed to SYSOUT=* which is fine as we can browse it if we need to.
For some reason (Audit request?) I am being asked to vacuum up the SYSOUT file and put it into a GDG when the task is recycled, while still leaving it as SYSOUT when the STC is active. . Based on a message I received, a disp of PASS and SYSOUT are incompatible. I am now considering using SDSF in batch so solve this problem (thanks to Lorne Heffer).
Anyone have any ideas? Using a commercial Program Product is a non-starter as, like everyone else the client is only interested in lower cost. Thanks.
Regards,
Jon Bathmaker
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

Another option is to spin off this sysout (for examplemid-night) and pick this upvia an external writer.
See:
//SYSOUT DD SYSOUT=(O,,LOG),SPIN=(UNALLOC,'00:00')

[John Mattson]

My suggestion would use the KISS principle. Yes, you can write (and
maintain) SDSF code or REXX, or use special software, or do it the simple
way. Remember an STC is just a JCL job for most practical purposes.
1) Change the STC //SYSPRINT to go to DISP=(NEW,CATLG),DSN=SOME.GDG(+1) ...
2) ADD a new STEP PGM=ICEGENER and gener SOME.GDG(+1) to SYSOUT=*
Mission accomplished. Audit has the GDG they want for heaven only
knows why, and the sysout is still in the STC's sysout.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[John McKown]

Post by John Mattson
My suggestion would use the KISS principle. Yes, you can write (and
maintain) SDSF code or REXX, or use special software, or do it the simple
way. Remember an STC is just a JCL job for most practical purposes.
1) Change the STC //SYSPRINT to go to DISP=(NEW,CATLG),DSN=SOME.GDG(+1) ...
2) ADD a new STEP PGM=ICEGENER and gener SOME.GDG(+1) to SYSOUT=*
Mission accomplished. Audit has the GDG they want for heaven only
knows why, and the sysout is still in the STC's sysout.

​As best as I understand the OP's request, he has two "demands": One from
auditing that the output be in a data sets; the second from some users that
they be able to read the output while the STC is still running (apparently
preferably via SDSF because they know it). Your solution addresses the
first, but precludes the second.​

​What the OP really seems to need is a way to direct one output stream to
both the SPOOL and a data set. This sort of thing is (conceptually) done in
a UNIX environment by piping output into the "tee" command. "tee" takes its
input (the output of the command) and writes it to all the output files in
its parameter list and to stdout as well (so that the user can see it as it
is being written).​ In JCL, that could do this (assuming the existence of
the TEE subsystem) might looks something like:

//SYSPRINT DD SUBSYS=(TEE,'DISK,SPOOL')
//DISK DD DISP=(NEW,CATLG,DELETE),DSN=...
//SPOOL DD SYSOUT=*

​That might actually be an interesting project.​

[Paul Gilmartin]

Post by John Mattson
My suggestion would use the KISS principle. Yes, you can write (and
maintain) SDSF code or REXX, or use special software, or do it the simple
way. Remember an STC is just a JCL job for most practical purposes.
1) Change the STC //SYSPRINT to go to DISP=(NEW,CATLG),DSN=SOME.GDG(+1) ...
2) ADD a new STEP PGM=ICEGENER and gener SOME.GDG(+1) to SYSOUT=*
Mission accomplished. Audit has the GDG they want for heaven only
knows why, and the sysout is still in the STC's sysout.

I inferred the OP has the requirement (although he didn't explicitly state it) to
be able to view the incomplete SYSPRINT with SDSF while the job is running.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Paul Gilmartin]

Post by John McKown
​What the OP really seems to need is a way to direct one output stream to
both the SPOOL and a data set. ...​ In JCL, that could do this (assuming the existence of
//SYSPRINT DD SUBSYS=(TEE,'DISK,SPOOL')
//DISK DD DISP=(NEW,CATLG,DELETE),DSN=...
//SPOOL DD SYSOUT=*
​That might actually be an interesting project.​

One might do this in Rexx with:
SYSCALL pipe
SYSCALL spawn tee
bunch-of-allocates
LINKMVS started-task

... and BPXBATCH to launch the Rexx (that's what it was invented for).

Tee might not be able to deal with data sets, so you might also need
another pipe, then:
SYSCALL spawn cp /dev/fd/0 //DATA.SET.NAME
(Assuming all this conforms to RACF rules.)

I believe the JCL OUTPUT statement allows direction of SYSPRINT to
several streams, but they must all be SYSOUT. Why not add
regular data sets to the mix?

I hate JCL! John's suggestion might be a palliative.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN