Ah - forgot you are not an MVS person/programmer. I am not the worlds greatest assembler programmer so I would have to assemble/link/execute to see if it really works. However, some bright spark will be along before I could do all that.

The problem I have is that people can explain things quickly but I can only comprehend slowly.RegardsNic

Other people made good suggestions, my example is the requirement reduced to the absolute minimum. I used RSECT rather than CSECT for two reasons.

RSECT implies that the CSECT is read only, and the Assembler applies the same tests as specifying RENT.

The read only attribute is carried into the load module. No verification is done, but it's there.

The read only attribute is used when linking the z/OS nucleus. The nucleus loader (which is part of the IPL procedure) uses it, but I no longer recall how it's used. Not that any of us are going to relink the nucleus. It's been 30 years, probably longer, since I've done it.

In the 5th post of the original thread you saw an example of setting the return code/condition code/reason code whatever we call it. Can't say I've ever seen 4000 come out of IDCAMS, but worth a try to check, could save you writing, assembling, linking, plus all your testing/release procedures.

I never did understand what was going on with IDCAMS. I looked it up and found it is used to generate and modify datasets, but figured maybe this was some trivial use of the program. Then there was the part about "obviously this can't be done as instream, but hopefully you get the gist", and as I'm sure you now realize, I didn't come close to getting the gist. But it seemed like the end result was to return a completion code of 0, which as I now understand things, wouldn't have helped since the job completion code was still going to be the highest value from any step in the job.

My "program" is really just the IEFBR14 utility with one instruction changed to store 4000 instead of 0 in register 15, and I don't even know if I got that right.