JES2 files defined in a processor step are opened under the User ID. Since these files are also created with the User ID as the high level qualifier, there are generally no security issues.
However, if a JES2 file is dynamically allocated by a program that is being executed in a processor it is created with the Alternate ID as the high level qualifier and, since it is still opened by the User ID, this can lead to security violations if the user is not authorized to update files with that high level qualifier.
Generally, the violation messages will include an IEC150I 913-74 message pointing to the file (DD name) in question.
This problem is most commonly seen with Compuware's XPEDITER program, which dynamically allocates its CWPERRM file, but there have been other instances as well.
There are 2 possible solutions for this problem:
- Hard-code the offending DD name(s) in the processor. In the XPEDITER case, for example, you would simply code //CWPERRM DD SYSOUT=* in the processor step.
- Add ALTID=N to the EXEC statement of the step concerned, to have it run under User ID security instead of Alternate ID security. A consequence of this method is that the User ID would also need authority to access any other data sets that might be referenced in that step.