On 04/23/2012 04:35 PM, Shmuel Metz (Seymour J.) wrote:
In<[email protected]>, on 04/19/2012
at 10:05 PM, "Joel C. Ewing"<[email protected]> said:
If you have multiple people who might have to back each other up and
be able to take over and eventually complete a maintenance project
started by another using SMP/E ISPF dialogs, then they had better
share the same SMPTABL dataset. Otherwise, the only way to continue
their maintenance would be to manually start a new "project",
determine what SYSMODS should be selected, determine the last step
done by the prior person, and spin through the already-done dialog
steps without actually submitting jobs in order to get to the right
starting step.
The flip side of that is that if you have multiple people working
concurrently the variables tracking the work of one are highly
inappropriate for the work of another. If I have to back up somebody
who has started to install service, the CSI will tell me what I need
to know. Chances are that I will receive updated HOLDDATA before doing
anything else, so I may not care what he had previously selected.
SMP/E dialogs do not work that way. Users do not share the same
variables directly, they share the same list of "named" maintenance
projects within each distinct target zone name, and variable values are
associated with a specific maintenance project, not with a user
(internally, SMP/E dialogs generate unique project ISPF table names in
SMPTABL as needed for storing the variables). If you want a new
independent project, you "start" a new project and give it a name to
distinguish it and it has its own set of variables. If you want to
resume/continue a previously started project (yours or someone else's),
you instead select an existing project from the list and the dialog
automatically picks up all the saved variables appropriate to the
options and state of that project. When projects are "completed" either
by advancing to the final step or by an explicit "CANCEL", the project
variables and corresponding ISPF table members are discarded.
It works quite well for tracking the state of multiple projects to
multiple zones from one maintainer or multiple maintainers, and I have
also used it to pick up and resume maintenance started by another when
the other went on vacation and priority of the project was "raised" in
their absence. It is especially useful when there is a relatively long
lag between APPLY and ACCEPT and you want to be sure to ACCEPT the same
SYSMOD set as in APPLY, because a maintenance configuration has proven
to be a stable one and you want it as a potential RESTORE point.
There is nothing to prevent SMP/E ISPF dialogs with a shared SMPTABL DS
from correctly tracking the distinct variables of two different SysProgs
that are concurrently working in ISPF on two independent projects. This
is true even if both projects are within the same TZONE/DZONE; although,
I wouldn't recommend that last level of concurrency as a standard
practice as it complicates the issue of when affected libraries should
be backed up, and potentially their batch jobs would waste initiator
time with enqueue delays waiting for exclusive access to the same CSI
datasets.
Yes, you can deduce most of the state information from the CSI, possibly
with help from the SMP/E log datasets; but it takes much more work and
adds unnecessary opportunity for human error.
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
