On Jul 7, 2015, at 10:37 AM, John Eells wrote:
That works for updating the procs themselves, and it's an
outstanding precaution everyone should use as a matter of routine.
But it does not work so well for a volume failure, when a data set
named in the proc is moved (and referenced by volser) or renamed,
or when the concatenation limit is exceeded for one of the DD names
after a change causes a data set to extend (I can hear TomC
already, yelling, "but-but-but...don't *do* it that way to begin
with!"), or...etc.
A TSO/E-only proc's purpose is to provide a way to recover (nearly)
no matter *what* happens to the regular procs or the data sets
named in them. With native TSO EDIT, you can list, alter, and save
changes to the logon proc you really want to use. Or, you can edit
the one you want to use to make it a batch job, save it in a new
member, submit it, and use the OUTPUT command to read the output
and locate the problem. You can do this in a standalone single-
system environment, too, without NJE or FTP access.
Everyone should have one. Really. Even if you are sure you will
never need it. Just because "can" beats "can't" when things go
wrong.--------------------------snip-------------
In one of my experiences VTAM get up because of a lazy sysprog not
double checking his work (left a comma off in the APF list).
I had to concoct a tso batch edit to put the comma in and save it
then IPL'd
I think he was let go.
Ed
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
