I was reading up on the new preview of z/OS 2.1. One of the reasons given for not having a way to purges JES output was the requirement for APF authorization. The announcement at: http://www-01.ibm.com/common/ssi/cgi-bi ... SZP13-0013
says:
In z/OS V2.1, the JES2 Extended Status Subsystem Interface (SSI) is planned to be extended to allow programs without APF authorization to cancel, hold, purge, and release jobs, and to change their job classes. New profiles in the RACF JESJOBS class will be used to determine whether a user is allowed to use these functions. This is intended to improve the usability of the Extended Status SSI and allow additional automation to be done using unauthorized programs.
too bad the company that I work for is moribund and likely won't upgrade because I'll bet that 2.1 will include a hefty price increase.
Well, you have "lsjes", how about "rmjes"? You could possibly even use the same options as with lsjes. But I'd include a "-i" option so that a user might do: "rmjes -i -p BUB*" in order to get a prompt, which would include both the job name and jes number, asking permission to "rm" this particular job. If an rmjes matched multiple entries, I might make the "-i" be the default. Which, of course, means that I need a way to say "yes, just kill all the matching output and don't bug me about each match". I'd suggest using -f (for force) for this, matching the -f in the UNIX rm command (to delete read-only files without prompting).
By default, I'd have rmjes only affect jobs on the HELD/OUTPUT queue. If the user wants to affect a job on the INPUT queue, then they'd need use the "-s i" option. If they want to cancel and purge the output, then use the "-s a" option. You might also want an option to only CANCEL a job in execution without doing a PURGE as well (-c for cancel? I don't know if the -s a option should be required in this case or if it should be assumed). You might also want to have a way to cancel by jobid. With lsjes, there are a "-o" and a "-p" for owner and jobname pattern respectively. Perhaps a -j for jobid?
Since I don't have access to what the API can do, I don't know if it has a way to cancel jobs in execution.