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.
[email protected] (Alan Schwartz) wrote:
Or have someone stay logged on to TSO while updating the logon procs. If
there's a problem they can fix it.
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
