On Wed, 21 Dec 2011 10:06:21 -0600 "McKown, John" <john.mck...@healthmarkets.com> wrote:
:>We are upgrading, finally, to z/OS 1.12 next month. One thing that I would like to do is allow certain people the ability to logon to TSO on all systems concurrently. It appears this is possible, for all users, simply by not propagating the SYSIKJUA enqueue via the GRSRNL. In fact, I have tested this and it works. I know about the ISPF "problem" and basically have risk accepted it. But my manager has thrown a wrench into the works. He likes the idea of us (Tech Services) and Production Control being able to do this. But he does not want any other TSO users to be able to do it. Well, I thought, use the new APPL support in TSO and just allow the other users READ access to the appropriate z/OS image. But that's not acceptable either. We need others to be able to logon to any system, but only on to one at a time. The only solution that I have figured out, so far, is to change the TSO logon PROC to allocate a user specific DSN with a DISP=(NEW,DELETE,DELETE). Perhaps something ! li! :> ke: :>//@PROFILE DD DSN=&SYSUID..ISPF.PROFILE, :>// DISP=(NEW,DELETE,DELETE), :>// SPACE=(TRK,0), :>// UNIT=SYSDA,VOL=REF=SYS1.MACLIB :>I need to disguise the DD so that it does not "stand out" and looks "required". Of course, once someone figures this out, they will simply logon to SY1, do a FREE, then logon to SY2, and so on. It is, at best, a poor "solution". But if I don't come up with something, we will continue to progagate the SYSIKJUA enqueue, limiting everyone to a single logon. To add to the misery, I'm not allowed to write an exit, such as the IKJEFLD, because we have a policy against doing exits. Or much of anything in HLASM, due to maintenance fears. :>Any other ideas? Curious as to why you wish to prevent it. If they can arbitrarily choose to logon to any system, why prevent concurrent logons? -- Binyamin Dissen <bdis...@dissensoftware.com> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
