Searching through the archives, I quickly saw that this has been a repeat heated discussion, but all of the discussions seem to ignore the fact that CICS initializes as an authorized address space, performs authorized work, and then disables authorization to load unathorized programs from the DFHRPL tasklib. It does what so many people deem to be a security integrity violation.
I have an unauthorized address space that collects information from the system and uses MQ or CICS EXCI (if MQ is unavailable) to transport the data to another address space which stores the data to DB2. Having the ability to execute authorize services would greatly increase the functionality of this address space. Since neither of these transport mechanisms are authorized, i cannot run authorized in the current setup. The idea is to execute the authorized requests as non-system supervisor PC routines. One of the PC routines would be to simply disable JSCBAUTH (ONLY disable. NEVER enable). Before invoking this PC routine, I perform a MODESET to switch back to problem state and key 8. The only authorized services performed before this switch would be the LXRES, ETDEF, ETCRE, and ETCON services to build the PC routines. After invoking the JSCBAUTH disable PC routine from the job step program, I cannot switch back. Invoking a MODESET after the switch abends address space with a 047. >From this point forward, all of the ATTACH and LOAD services are performed with the supplied tasklib. The unauthorized code is COBOL. Before this program is invoked, it initializes LE and replaces the default CEEZLOD and CEEZDEL with my own version that loads from the tasklib. Thank you, Brian Chapman ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
