Barry Schwarz said: ". . . you should also spend some time figuring out how
you ended up with uncatalogued SMS datasets, a situation the system goes to
some lengths to prevent."
I can give you one mechanism, at least for ISPPROF datasets.
We have two systems (both z/OS-1.11) - one a production system and the
other a development system. They share user-catalogs, DASD, SMS, HSM, and
RACF. They are in a GRS-ring. All TSO-userid datasets (userid.*) are
SMS-managed. Developers and systems staff have multiple IDs (for multi-system
TSO access, among other things). Most of us use IPT (formerly Spiffy), but I
believe the following situation happens with or without IPT.
If a person is in TSO on system 'A' with an ID and attempts to sign on
to system 'B' with the same ID, GRS spots that their 'userid.ISPF.ISPPROF' is
already in exclusive use. Instead of being denied access, they get a screen
that says their profile dataset is in use, and asks them if they want to
continue with a default profile. The screen has a field to confirm that they
do, the cursor is on that field, and it is pre-filled with the '/' that
indicates 'yes, they do want to continue'. We have seen two bad things happen
from this screen.
1. If they press <enter>:
a. the existing ISPPROF dataset is un-cataloged (but not deleted);
b. a new ISPPROF dataset is built, with default settings (they lose
all their customizations).
When they complain about the loss of customizations, we delete the new
ISPPROF dataset, use an inventory to locate the prior ISPPROF dataset, and
re-catalog it to the SMS volume using a 'DEFINE NONVSAM' in a batch IDCAMS job
(ISPF 3.4 does not allow a 'C' line command - part of the protection Barry
referred to).
2. If they blank out the '/' and then press <enter>:
a. the existing ISPPROF dataset is un-cataloged (but not deleted);
b. their TSO sign-on attempt to system 'B' fails;
c. once they are signed off the other system ('A'), that ID is 'dead'
(they cannot sign on to TSO because we do not dynamically create an ISPPROF
dataset, and their ISPPROF dataset is no longer cataloged).
When they complain that they can no longer sign on, we verify that
their 'userid.ISPF.ISPPROF' dataset is not cataloged, use an inventory to
locate it, and re-catalog it to the SMS volume using a 'DEFINE NONVSAM' in a
batch IDCAMS job.
In both of the above two cases, their TSO session on the other system ('A')
continues to function until sign-off. And an 'orphaned' SMS-managed ISPPROF
dataset is left behind (until we are asked to fix the problem).
David Mueller | Systems Programmer
SSRC (Southwood Shared Resource Center)
2002 Old St. Augustine, W-67
Mail: 2585 Shumard Oak Blvd, Tallahassee, FL, 32399
Phone: 850-414-9134 || Fax: 850-488-3600
E-mail: [email protected]
Please Note: Florida has a very broad public records law. Most written
communications to or from state officials regarding state business are public
records available to the public and media upon request. Your e-mail
communications may therefore be subject to public disclosure.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
