substitute into JCL varying by job

[KGherlone]

LOL, I bet those synapses would be happy for the excitement...
No PL/1 or C/370. For mainframe production jobs just really COBOL and Sort for data manipulation... (I know I know...it isn't my choice...)

[Akatsukami]

::sigh:: I was afraid of that. Well, I'll see what I can do.

The data set of cancelled IDs: what is its format?

• Does it have headers or trailers?
• Is there one record type or many?
• Where in the record is the HLQ?
• Is the field or varying length?
• If varying-length, how is it delimited, or how is the length specified?

[KGherlone]

There will only be one record in the file and it will be a fixed-length 9 character alphanumeric value (this is the user's novel id). This value is to be read into a COBOL program where a VSAM file will be read with this 9 character value to ascertain the user's MVS id, which is the 6 character alphanumeric value that is used as the HLQ for the files that are to be deleted, so the RACF entry can be deleted. This 6 character value, therefore, is the one that I desire to have in a variable that can be substituted in the jcl.

[enrico-sorichetti]

This value is to be read into a COBOL program ...

NO NEED FOR PARAMETER SUBSTITUTION,
just create the SYSTSIN dataset wit the proper data

1) modify the aforesaid cobol program to write to a dataset a record with the HRECALL command
use the dataset as input to the TSO step to issue the HRECALL command created

2) use a <sort> step to BUILD the hrecall statement ...

[KGherlone]

After pondering this for a bit, it seems like the best way to go would be a COBOL program to get the record with the UserID to delete, get the HLQ value associated with that ID and then create the JCL to create a job calling a PROC and populating the substation variable for the HLQ in that PRO and sending it to the Internal Reader.
Does anyone see any flaws in that approach?
Kevin

[prino]

The shop standard here is to not use REXX for production jobs (don't ask...)

If REXX is the best tool to do something that's not done before, change the shop standards!

[enrico-sorichetti]

Does anyone see any flaws in that approach?

see my previous post ...
No need to create the JCL, it is enough to create the SYTSTSIN data

[KGherlone]

I agree for the SYSTSIN parms, but unfortunately there are other nodes in the jcl that must be variable based on the HLQ. For example, in the copy step the dsn for the file being copied into will have a node using the HLQ. So I think the COBOL approach is the only way to go..

Kevin

[enrico-sorichetti]

but unfortunately there are other nodes in the jcl that must be variable based on the HLQ.

if You had explained the full requirement from the beginning of the topic
I would not have wasted my time explaining a partial approach

[steve-myers]

...Hello all,
We have a requirement to automatedly remove terminated users from RACF. This cannot be done if there are any files allocated to that user. ...

Actually, the issue is not the data sets; it's the RACF profiles - though you should delete the data sets anyway.

You cannot delete "files" in z/OS. The only "file" in z/OS is the data on magnetic tape between the beginning of the tape and a "tape mark," or between two "tape marks."