On 29 October 2014 11:23, Thomas Conley <[email protected]> wrote:
> On 10/29/2014 7:50 AM, [email protected] wrote: > >> I appreciate all of the responses. I did a profile prefix(atljp), which >> fixed the problem. I have never seen such an odd occurrence in ISPF before. >> >> John >> > It might have been useful to see what the output of a PROFILE LIST showed before changing it. > This is not an ISPF issue. The corruption of the PREFIX data is a serious > issue affecting your external security manager (ESM, such as RACF, ACF2, or > TopSecret). I'm assuming you have an ESM and are not using UADS. The TSO > PROFILE PREFIX command can't corrupt the data and store a value > 8 > characters. This is a bad problem to have, and you should continue to > research to figure out what happened. The earlier suggestion to unload > your ESM database to check the prefix value is a good one. You should > check to see if other prefix values are corrupted, and if so, open a PMR > with your ESM vendor > Keep in mind that this information is kept in the User Profile Table (UPT), which is in user-key storage, and so is writable intentionally or by accident by any program running in the address space. It is rewritten to the security system at logoff, and I'm sure RACF and friends don't check the content in any detailed way. To the security system it's an object to be stored and retrieved. It seems to me far more likely that a program run at some time under the userid in question updated (clobbered?) the field than that RACF corrupted it. There is (should be) no integrity exposure no matter what such a program does, as authorized system components know well that this is user-modifiable data and cannot be trusted. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
