You could provide a mechanism where their libraries could be included in the logon process.
We had a process that if they had a data set called TSOID.CLIST and a member called STARTUP, we allowed them to specify libraries the would be added into the logon proc. They did not have a choice of where it was allocated. They would code in STARTUP ISPPLIB TSOID.MY.PANELS SYSPROC TSOID.MY.CLIST And so forth. We would then add it to the bottom of the concatentation with a REXX process that would free and reallocate the appropriate libraies. Or we used the CONCAT function from the CBT tape. This was all done through the Logon REXX process. We could not stop them from doing a FREE/ALLOC but by providing a mechanism that would allow their libraries to be added on for that logon session, it did reduce the need for them to want to do it. This also made it difficult for them to use the same names as members already in the concatenation. Lizette > >Is there any mechanism or approach to protect a TSO/ISPF user from >accidentally/intentionally FREEing SYSPROC or SYSEXEC? Until now, our >shop has been mostly Roscoe users outside of tech support. We are >trying to migrate developer's to use TSO/ISPF, and want to protect the >environment where needed. I don't mind them using ALTLIB, and LIBDEF to >create their own "stuff", but I don't want them FREEing and reallocating >SYSPROC/SYSEXEC to concatenate their own stuff ahead of what we want >them to use. We already do not allow them to get to the READY prompt, >but testing shows that even when in ISPF I can still FREE >SYSPROC/SYSEXEC. > >I want to allow some ingenuity, just not too much is all. > ---------------------------------------------------------------------- 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
