Paul Gilmartin wrote: > Why not multiple logons on a single LPAR? The > integrity and serialization issues ought to be the same; the sole > obvious exception would be contention for the job name; this could > be resolved by using a generated jobname (SMOP), or prompting the > user for a suffix character, as in SUBMIT. If concurrent batch > IKJEFT01 job steps (with different job names) are feasible, why > not similarly for foreground?
If you want you could dig up CBT file 134 and look at the MULTITSO member which describes what I did to get multiple TSO sessions on a system. It references other members in the file for source code. I'm not sure how useful it would be in your environment because because I did nothing to cater for SYSPLEX issues. I doubt a GQSCAN macro would help because when I last looked at it (decades ago?) SYSIKJUA enqs are acquired when the job name is 'STARTING'. OTOH, if you add &SYSNAME as a qualifier into your ISPPROF data set name maybe most of the issues would be solved. We used a logon CLIST which added a the jobname as the second level qualifier to the ISPPROF dsname if it did not equal the userid. If the data set did not exist I think it was copied from the original data set. (Primary input area at the bottom of the screen, anyone? Blargh! Not me! Well, not usually, anyway....) Cheers, Greg ---------------------------------------------------------------------- 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
