IBM Mainframe Forum

There is a series of JCLs which I need to submit daily; to reduce the manual effort I tried to connect/automate the entire flow so that if I submit one JCL it will automatically submit the next one in the series; however I have been stuck up in the resolution of SEC error in JCL. I am getting SEC error in some of the JCLs, when I searched on IBM Manuals the resolution of SEC error, I have applied the same but that is not feasible in this case.

The resolution of SEC Error mentioned in IBM Manuals is to give USER and PASSWORD parameters in the jobcard.

However in this case, the solution is not feasible as the project is very critical/confidential that we can't use PASSWORD parameter in the jobcard.

Is there any other way to get SEC error resolved apart from these? If so please share your views on this?

One presumes that "SEC error" is your personal jargon for a S913 abend?

Yes, I guess so as both the errors are due to Authorization failure but I am not sure as the SEC error is occurring because of the submitter of job is different to the executer of the job.

For example: If I am submitting the job manually, then it has been submitted using my ID and password will be automatically validated by RACF and job successfully executed; however if the job is being submitted by previous Job (using INTRDR), then submitter will not be my ID and it will be default ID which is not having access to that particular job and job fails with SEC error.

Hello and welcome to the forum,

Suggest you Stop using your own terminology. As far as i know you are the Only one who calls an s9xx error a SEC error.

One way to fix your problem is to have the job submitted via the scheduler using an appropriate id.

anks wrote:For example: If I am submitting the job manually, then it has been submitted using my ID and password will be automatically validated by RACF and job successfully executed; however if the job is being submitted by previous Job (using INTRDR), then submitter will not be my ID and it will be default ID which is not having access to that particular job and job fails with SEC error.

This appears not to be the case; a job on my machine submitted (via the internal reader or the TSO SUBMIT command) by another job inherits the userid (and therefore the RACF privileges) of the submitter. Look at the IRR010I message in the JES message log (if your shop displays it; not all do) and see what ID the job is assigned by RACF.

anks wrote:... For example: If I am submitting the job manually, then it has been submitted using my ID and password will be automatically validated by RACF and job successfully executed; however if the job is being submitted by previous Job (using INTRDR), then submitter will not be my ID and it will be default ID which is not having access to that particular job and job fails with SEC error.

• Ordinary job submission via an internal reader. In this case the submitted job automatically gets the userid of the job that submitted the new job.
• Surrogate job submission via the internal reader. In this case the JOB statement specifies USER=xxx, but no password. The user change is authorized by a RACF profile that basically says the user submitting the new job is authorized to submit a job for the user specified on the new job's JOB statement. Surrogate job submission is designed for use with job scheduling packages, but it can be used for any situation where user A is submitting jobs to run using user B's userid.
• Specify USER=xxx,PASSWORD=zzz, where zzz is plain text. Obviously not what you want.

This link discusses the RACF profiles used for surrogate job submission.

Thanks Steve for the reply; however I am still bit confused after going through the note mentioned in the link provided that says:

A user should not allow another user to act as surrogate user unless |
| the surrogate user can be trusted as highly as the execution user is |
| trusted. This is because the surrogate user can do anything the |
| execution user can do (unless the surrogate user lacks access to a |
| security label that protects a resource). For example, the surrogate |
| user can submit a job to copy, alter, or delete the execution user's |
| data. |

In my case, the surrogate user is a default user like USER=TESTJOB (which comes due to automation);anybody can use i.e everybody is having access to USER=TESTJOB and if TESTJOB will get access rights to my ID then anybody can submit a job to copy, alter or delete my data.

I do not understand this "default" userid TESTJOB. There is no concept of a "default" userid in any of the big 3 security systems, e.g., RACF, CA-ACF2 and CA-Top Secret. All users must identify themselves, either by

• By specifying a USER=xxx,PASSWORD=yyy on a JOB statement submitted on a "real" card reader.
• By specifying a userid and password to logon to TSO or other interactive system that can submit a job such as CA-Roscoe.
• By inheriting a userid by submitting a job through the internal reader from an user identified by the first 2 bullets.

The only exception is a job submitted through a surrogate arrangement; the import of your quote is security administrators must be very careful about authorizing this capability.

Actually this is not quite true. RACF assigns a default userid to jobs being flushed out of the system because there is no valid userid for the job, but these jobs do not execute and cannot access system resources. Which reminds me of an incident from 40+ years ago. This system was operated by a large university that assigned some sort of allowed resource units to everything; jobs hat were flushed from the system because they did not have any resource units remaining were assigned a system ID that supposedly had an infinite amount of resource units. Well, that wasn't true. One day this system ID ran out of resource units. Oops!