CA View - Can you have View Send Sysouts Straight to Tape Based on Sysout Name?
Article ID: 145866
Updated On:
Products
Deliver
View
Issue/Introduction
In the client's environment, there are some large sysouts going to CA View.
The reports cannot be evaluated against a line limit, as they need all data to be available for auditing purposes.
As a solution, the client is using ERO (SARINIT EROOPT=YES and PRETAIN=TABLE, with a //SARPATAB DD in the SARSTC task).
Within //SARPATAB is, for example:
The reports cannot be evaluated against a line limit, as they need all data to be available for auditing purposes.
As a solution, the client is using ERO (SARINIT EROOPT=YES and PRETAIN=TABLE, with a //SARPATAB DD in the SARSTC task).
Within //SARPATAB is, for example:
/sysout_ID DRETPD=0 RETPD=180 ALL DELETE
Even with use of this statement, View is allowing sysout to stay on disk by the SARINIT NGEND parameter, currently set at 5 generations.
Can this report be sent direct-to-tape using ERO or another sysout_ID?
They want the large sysouts to go direct-to-tape, so as to not be on disk for even a single generation.
SARINIT TAPECLSL cannot be used, as those sysouts have the default class setup for our CA View instance, and the developers will not change their JCL MSGCLASS to a specific one.
Environment
Release : 14.0
Component : CA View
Resolution
The usual way that View functions is:
. Reports are collected to disk.
. At the next View backup, the report is written to tape.
. Now, as the report resides on both disk and tape, the retention parameters are applied, determining how long to keep the report on disk, and how long to keep the report on tape.
If the Sysout ID matches one of the sysout_IDs in the ERO table, those retention parameters will be used.
For those Sysout IDs where there is not a match in the ERO table, it will then use the SARINIT NGEND and NGENT parameters.
Usually, the use of PRETAIN=TABLE would keep things to just what is in the ERO table, but if the ERO table does not have a "catch all" entry at the end (/* ...), here too can NGEND and NGENT be used for retention.
The usual way to send reports directly to tape is via the use of SARINIT TAPECLSL=...
If TAPECLSL is not to be used, the only other possible way for sysouts to be written direct-to-tape would be with use of a modified SARSTCUX exit.
Of the SARSTCUx sources provided in the CVDEOPTN library, the SARSTCU3, SARSTCU6, and SARSTCU9 sources all revolve around the number of lines in a sysout.
So, if not for use of the TAPECLSL parameter, the only other way to have sysouts written direct-to-tape would have to somehow be based on the number of lines.
. Reports are collected to disk.
. At the next View backup, the report is written to tape.
. Now, as the report resides on both disk and tape, the retention parameters are applied, determining how long to keep the report on disk, and how long to keep the report on tape.
If the Sysout ID matches one of the sysout_IDs in the ERO table, those retention parameters will be used.
For those Sysout IDs where there is not a match in the ERO table, it will then use the SARINIT NGEND and NGENT parameters.
Usually, the use of PRETAIN=TABLE would keep things to just what is in the ERO table, but if the ERO table does not have a "catch all" entry at the end (/* ...), here too can NGEND and NGENT be used for retention.
The usual way to send reports directly to tape is via the use of SARINIT TAPECLSL=...
If TAPECLSL is not to be used, the only other possible way for sysouts to be written direct-to-tape would be with use of a modified SARSTCUX exit.
Of the SARSTCUx sources provided in the CVDEOPTN library, the SARSTCU3, SARSTCU6, and SARSTCU9 sources all revolve around the number of lines in a sysout.
So, if not for use of the TAPECLSL parameter, the only other way to have sysouts written direct-to-tape would have to somehow be based on the number of lines.
Feedback
Yes
No
Powered by
