I kind of figured that *someone* would rise to this.... What I wanted to address is the fact that there are quite a few sysprogs who don't care to solve a CSA key8 problem like the one described by that BMC apar. If it had been me, I would have attempted to use the suggested circumvention and get rid of the functionality that relies on CSA key8. I am not an IMS person, so I have no clue what distinguishes IMEXEC submit and JESSUBM and why they say they cannot use JESSUBM. In addition, I did not want to quote the full apar for the security reasons described by others in this thread.
>The problem is being caused by an IBM module that NOT conforming to >expectations, i.e., that any >module that changed states would be expected to return to the caller's state, >not arbitrarily assume >that the caller was in a particular key or state. Now, haven't I heard *that* excuse five too many times? As far as I know (and I have been out of this loop fo almost a decade now), it has always been IBMs stated requirement that a module expects control back in exactly the same state that it got control in. Mind you, I am NOT attempting to lay the blame on anyone. And thanks for that additional information, which I wasn't given before. >REQUIREMENTS were submitted to get it changed. They were routinely REJECTED. What was the reason for the rejection? Usually IBM tells you in great detail why they won't change a behaviour. After all, that's a lot faster than actually changing anything. Regards, Barbara Nitz -- Psssst! Schon das coole Video vom GMX MultiMessenger gesehen? Der Eine für Alle: http://www.gmx.net/de/go/messenger03 ---------------------------------------------------------------------- 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
