Maybe you should just change your logon clist to allocate the ISPPROF as
SHR, rather than OLD, since ISPF is perfectly capable of sharing the
ISPFPROF dataset now.
On Tue, May 10, 2011 at 3:32 PM, Mueller, David <
david.muel...@ssrc.myflorida.com> wrote:
> 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: david.muel...@ssrc.myflorida.com
>
> 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
confidential and privileged information intended only for the addressee.
If you are not the intended recipient, please be advised that you have
received this material in error and that any forwarding, copying, printing,
distribution, use or disclosure of the material is strictly prohibited.
If you have received this material in error, please (i) do not read it,
(ii) reply to the sender that you received the message in error, and
(iii) erase or destroy the material. Emails are not secure and can be
intercepted, amended, lost or destroyed, or contain viruses. You are deemed
to have accepted these risks if you communicate with us by email. Thank you.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
