IBM Mainframe Forum

I'm writing a REXX routine that will update a production control file based on user input. This file will be used to trigger a nightly job if there is data in the file. I'm trying to figure out if I can control the update of the file so that it can only be updated through the REXX screen. I don't want anyone to be able to manually update the file by editing it in TSO.

My shop uses ACF2 for security. I know I can restrict the file access to certain userids and give only those userids access to the REXX routine, but I want to make sure those users go through the REXX screen. If I restrict the file access to a "fake" userid, is there a way I could have the REXX routine "log on" with fake ID, so the file could only be updated through REXX with the fake ID? Any other ideas?

My other option is to do this with CICS if I can't figure out how to do it with REXX.

Thanks! Paul

Have you talked to your site security group? If not, you should talk to them -- they most likely know the most about your site set up and how what you want to do can be achieved (if it is possible) at your site.

Thanks for the reply Robert. I have discussed with my security group. They were not aware of any way to handle this situation using REXX, they recommended using CICS. I thought I would throw it out to this forum to see if anyone had an other ideas.

(I am not familiar with ACF2).

I do not think you can do what you want using REXX. However, you can probably do it with an assembler program. Give access to the program.

RACF allows the use of a surrogate userid: one user submitting a job for a different user. However, you still have the problem of the user building their own job to modify the data set rather than using your JCL.

-----------------
I think the user should be allowed to update a staging data set and then have your nightly job read it and verify it before copying from the staging data set to a production data set. Provide a way for the user to verify the data set; likely, he does not want to provide a corrupted data set any more than you do.

There is no such thing as a "Rexx screen."

In any event, to me, when I put on my security auditor hat, the whole idea seems rather flaky. Most likely I'd write up the whole idea as too insecure.

However, the idea of having users some degree of control over periodic production requirements seems, to me, to have merit.

Like Pedro, I don't know ACF2 very well. 35 years ago was a different story, but that was long ago. Most of my current security knowledge these days is RACF. Some RACF details, especially in CICS are still a mystery to me.

None the less, on the face of it I'm inclined to agree with your site security that a CICS based solution might be best or a combination of Rexx and ISPF dialogs might work well. You need to have your production control people involved in this too, so everyone agrees on the types of control your users can specify and the product people can implement. Good luck!

Just a thought - compile and link your REXX program and allow access to that dataset only through the program. I know that RACF has that capability, so I assume that ACF2 has it too.

Thanks for all the suggestions. A little more background. As part of the REXX routine, I would also be updating an audit file to keep track of who is updating the production file. That way if there is an issue, I can track down the cause. I know the users don't want to input corrupt data, but mistakes happen. Also, I know that if it's possible to take a short cut and update the dataset directly, someone will do it. Then I lose my audit trail. I am working with my production control people, they suggested the audit file. But, the more we look into using REXX, the more we are running into challenges. It's a great tool which is quick and easy to use, but might not be robust enough for this application.

I like the idea of the REXX compile/link option, unfortunately, we don't have the REXX compiler here. I'm going to do a little more digging into ACF2, maybe there's something else I can do with ACF2.

but might not be robust enough for this application.

why blame the <others> ?
Your skills might not be robust enough

keep the data in a DB2 table and extract it from there at run time
( one step to read the DB2 table and create a sequential dataset )
the extractor could be written in REXX
btdtgtts

anyway whatever security controls might be in place ( for the dataset update access )
even updating the control dataset with a user written application might result in erroneous data

I would also be updating an audit file to keep track of who is updating the production file

You can easily find that information through SMF type 15. And that is independent on the whether your application or straight ISPF edit is used.
Perhaps your application could do a backup to a GDS, so you always have a restore point.

Since we don't have the REXX compiler, I'm going to call a COBOL program to write to the file. I'll have security set up so only the COBOL program can update the file. Thanks for all the great suggestions. Paul