Page 2 of 2

Re: Locking a JCL or PDS but still executing

PostPosted: Wed Jan 04, 2012 1:44 am
by dick scherrer
Hello,

To first lock this jcl so that no users other than me can see it.
Who in your management gave permission to do this?

Why do you believe this is so special that others should not even be able to read the code?

I suspect this was built/installed on your organization's computer(s) and as such probably belongs to the organization not one person. . .

Re: Locking a JCL or PDS but still executing

PostPosted: Thu Jan 05, 2012 1:10 am
by zhinghur
Well. Thank you everyone for your precious time. :)

Re: Locking a JCL or PDS but still executing

PostPosted: Thu Jan 05, 2012 3:10 am
by Ed Goodman
May I ask why you need to hide the REXX code? Does it contain sensitive information, like maybe a list of passwords or something? Maybe a pending layoff list? Or are you just trying to hide working code so that no one steals it and uses it in their project?

As you can see from the responses here, this type of activity is distasteful to most people.

Re: Locking a JCL or PDS but still executing

PostPosted: Fri Jan 06, 2012 12:19 am
by zhinghur
Ed Goodman wrote:May I ask why you need to hide the REXX code? Does it contain sensitive information, like maybe a list of passwords or something? Maybe a pending layoff list? Or are you just trying to hide working code so that no one steals it and uses it in their project?

As you can see from the responses here, this type of activity is distasteful to most people.



Hello Goodman,

You got it right. Actually I don't want to hide Rex, I want to hide JCL. But I thought if I hide the REX itself, even that can be good.

The JCL has got around 15 steps using SORT, IBPTCH, IBUPDATE,TELON, COBOL etc. It will reduce quite a manual effort for all users in a group. But the JCL has got some credential ID's(self) and pass to access data that is other wise not possible for all. So, I cannot let anyone access one.

My organization doesn't approved the idea of password protected, as it doesn't make sense to Business.

So, I was looking for an alternative soln. if possible.

Re: Locking a JCL or PDS but still executing

PostPosted: Fri Jan 06, 2012 12:33 am
by dick scherrer
Hello,

My organization doesn't approved the idea of password protected, as it doesn't make sense to Business.
Yup - most organizations will not permit passwords on mainframe datasets. . .

But the JCL has got some credential ID's(self) and pass to access data that is other wise not possible for all
One common way to do this is to remove the classified info from the process and insert it at run-time (using a front-end screen to enter the data that needs to be secured).

Re: Locking a JCL or PDS but still executing

PostPosted: Fri Jan 06, 2012 1:45 am
by Ed Goodman
If i was backed into that particular corner, I'd take advantage of our scheduler. It has a feature to submit jobs when datasets are created.

I would put the JCL in a directory that only the scheduler and I could read, and make the job name something private so no one else could see it in the spool. Then have the REXX create the flat file with the information in it, which would trigger the job to run.

In a similar process, I asked the user to provide THEIR userid/password and submitted the job with those credentials. That has the huge advantage of showing who actually requested the process.

Re: Locking a JCL or PDS but still executing

PostPosted: Fri Jan 06, 2012 5:57 am
by steve-myers
zhinghur wrote:... My organization doesn't approved the idea of password protected, as it doesn't make sense to Business. ...
The old OS/360 password protection business didn't make very much sense to anyone, so I guess it won't make sense to anyone these days.

The critical data would seem to be the password in the JCL, but there are two possible methods to eliminate that -
  • If the job is executing in the JES2 node where it is submitted, enable "surrogate" support for the user specified in the JCL. "Surrogate" support permits users as specified in RACF profiles to submit jobs with a user id that is different than the user submitting the job. "Surrogate" profiles are the common method for scheduling systems to submit job with userids different than the userid used to run the scheduling system.
  • If the job is being sent to another JESx node or you can't persuade your security folks to create surrogate profiles, use standard Rexx methods to prompt the user for the password and insert the password into the JCL as it is being submitted.
I still think you are trying to write a half-a**** scheduling system here; you really should be using a real scheduling system like I mentioned before.

Re: Locking a JCL or PDS but still executing

PostPosted: Sun Jan 08, 2012 2:08 pm
by zhinghur
Thank You Ed and Steve for your valuable inputs.

I have come across a way to trick the system. Not pretty sure if its gonna work but looks like it should. If the solution works, I will post how I achieved.


Thanks once again, everyone.

Re: Locking a JCL or PDS but still executing

PostPosted: Sun Jan 08, 2012 6:55 pm
by NicC
Why does your JCL have your password coded - TSO submit will supply that - no need to code it.