Paul Gilmartin wrote: > On Thu, 14 Jun 2007 20:30:43 -0500, Tony Harminc wrote: >> I've looked at this, and "it isn't pretty" doesn't even begin to describe >> it. Unless IBM has severely modularized things since the last non-OCO >> version of this stuff, it is full of hardcoded knowledge of not only VTAM >> (and TCAM!) module names, but of their various quirky behaviours. >> > So how does IKJEFT01 in batch bypass all that stuff? How does it bridge > the userid==address space name pitfall? > > -- gil
Some of the things that rely on userid=jobname probably include inter-ASID TPUT (incl. OS SEND command) and LOGON RECONNECT. If you are not fussed about those two things (and anything else that I should have listed) then it is "easy" to allow a single TSO-authorised userid to logon to TSO multiple times concurrently on a single "MVS" image. (Stroking chin for flashback sequence...) It all began because for years I wanted the RACF user name (of up to 20 characters) to be placed into the programmer name field of the JOB card of the TSO session's JCL. I complained about this somewhere - maybe even here - and whined about a RACF deficiency when compared to ACF2 which does do this. Walt the RACF wizard kindly pointed out that this is not up to RACF to do but TSO. So, whipping up a TSO Logon Post-Prompt Exit (IKJEFLD3) from the sample, the RACF user name went into the JOB card. Nice. Now, for my next trick, I change IKJEFLD3 to fiddle the job name by adding a character after the TSO userid (which has a max length of 7 chars) to form the new job name. This allows up to 40 TSO user address spaces from the one id (blank or "TSO classic", 26 alphabetic, 10 numeric, and 3 national). Oh, and of course the other thing to handle is the SYSIKJUA ENQ on the userid. This is deftly dealt with by cunningly converting these ENQs to shared (instead of exclusive) - achieved by a simple front-end to SVC 56. Warning: the way I did it makes no allowance for SYSPLEX or shared SPOOL (Didn't JES2 enforce unique TSU job ids in a MAS? Was this ever changed?) because the decision of which suffix character to use for the job name is made by scanning the address space names in the virtual storage of *this* system only. It all seemed to work okay but it was OS/390 and not the most heavily-loaded system in the world (although I still think it would work on z/OS and I don't think system load affects it's viability). And as I say, the ability to LOGON RECONNECT goes out the window, which may not be an issue if you use session manager software or have a reliable network. And as far the ISPF profile data set, we settled on a scheme where the session's profile data set (perhaps userid.jobname.ISPPROF) was cloned from the user's original or base profile data set by the logon CLIST. It may have even been deleted and cloned anew each time so that updates to the base profile got promulgated. And I may have even written a function which returned the current job name into a CLIST variable. The method is described in member MULTITSO of CBT file 134. The JCL and source code for the TSO exit and the SVC 56 front-end and its loader are also present in other members of that file. And that was about six and a half years ago... (stops stroking chin). Cheers, Greg P. ---------------------------------------------------------------------- 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
