>Everyone agrees that such exposures must be identified and fixed. Unfortunately, not true. Don't get me wrong, I would like very much to get the exposure fixed, but I am fairly alone here with this wish, exactly for the reasons Mark stated: It has been running that way forever without problems, and the vendor (in our case BMC) clearly stated that they won't fix their exposure, take it or leave it. Those using the product just shrug and say they take it. Functionality IMEXEC SUBMIT, apar/ptf BAO6741, this is the text:
"ACTION: After many attempts to solve this that failed, it was decided that we could not support IMFEXEC SUBMIT in this context. A new message was added to Exec Manager to block the use of IMFEXEC SUBMIT and give the user a RC=16. The message documentation suggests that the user switch to using JESSUBM instead. CIRCUMVENTIONS: Run the PAS in key8. Under z/OS 1.8, this may require setting the DIAG parameter named ALLOWUSERKEYCSA to YES." Needless to say, I was told that my colleagues cannot use JESSUBM. I am currently waiting for a wide awake auditor who knows what he's doing. Also, I will NOT delete the health check stating that we don't run with the default. >IgvNoUserKeyCsa was discussed at SHARE by Bob Shannon many years ago. (A >"Bit Bucket" presentation IIRC.) Users could have helped to identify >exposures by enabling the TRAP on test/sandbox systems. Some did. Most >did not. Sorry that many Europeans don't attend Share. First time I heard about this trap was sometime in the early 2000's when Jim Mulder mentioned it. You cannot really call that 'it was published', in my opinion. Best regards, Barbara -- 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
