IBM Mainframe Forum

Hi,

I want to submit a JCL to get access on other user's datasets. for this i have used USER and PASS parameters of the other user's details in my jobcard. even then i'm getting not authorized messages.

find below the JCL that i'm submitting to get access on other user's dataset.



My final requirement is to get read access on TARGET.DB2.PDS
what can be the solution for this ?

the error i'm getting for this JCL is

There are many problems here.

• The syntax of your JOB JCL statement is incorrect, so the USER=xxx statement was ignored. The job was run under your ID.
• It's PASSWORD=xxx, not PASS=xxx.
• Your ADDSD statement is incorrect. You are creating what is known as a "discrete" profile. You want to create a generic profile by specifying GENERIC.
• The ID parameter in the PERMIT command is a userid, not a job name. You also want to specify GENERIC if you altering a generic profile.

You are much better off going through your security people rather than exposing TARGET to being fired for revealing his password to you. They will do the profile correctly.

Many sites consider it a violation of their policies to do what you're attempting to do, and the penalties may range from mild up to termination of the employee. It is NEVER a good idea to attempt to avoid the site security group. Contact your site security group and have them give you proper access. This will help prevent the security auditor(s) from asking you LOTS of questions.

Hello,

I want to submit a JCL to get access on other user's datasets

Why does someone believe this is acceptable? If your management wants you to have this capability, your management should request the security admins provide proper permissions. . .

Why is it ok for you to know someone else's password? Often this is grounds for one or both people to be disciplined or even terminated. It violates the security standards nearly everywhere.

Maybe "TARGET" has been fired, and TS is trying to clean up their mess. Maybe TS went to security group and they just gave them the password and told them to do it this way.

Ed Goodman wrote:Maybe "TARGET" has been fired, and TS is trying to clean up their mess. Maybe TS went to security group and they just gave them the password and told them to do it this way.

Ed, that's a nice try, but it won't fly.

• If TARGET has been fired, the ID will have been either revoked or completely deleted; that approach won't work.
• If TARGET has been deleted, no one can create TARGET.xxx profiles.
• Security will have cleaned up the mess, not some third party.
• If security handed the TS TARGET's password to the TS, they are just as culpable as TARGET was, and they should be fired.
• If the TS has TARGET's password, the TS should have logged onto to TSO and done it directly, not submitted a batch job.
• If TARGET wanted to give the TS access, he could do it himself, not give the TS his password.

After thinking about the messages, I realized TARGET.TEST.PDS is an alias. The profile the TS proposed will not give him access.

Hi Steve.. I rectified those syntax errors and now its working pretty fine whatever I need..

For others... It's my mistake showing and asking only part of my code. I'm not violating any security issues here and not even cleaning up the mess done by TARGET!

I'll just give an overview the reason for doing like this.. I'm actually copying the contents of vsam into windows and creating an excel or showing in a browser. So the user enters his password and vsam name that has to be downloaded in Windows browser. Using MQ the password and filename reaches into mainframe and I have to execute a set of JCL REXX CObol prog that access his dataset from my address region. Since I don't have permission to view his datasets directly, I submit the above JCL to get read access and after finishing everything the access will b revoked. So there is no security violation since d during execution of prog only the access is there.

Hi scherrer.. the password is present In a variable that has dynamic data based on what user enters in Windows.

For the sake of simplicity I hardcoded the password and DSN name in the jcl. Both are dynamic in my tool.

Thank you for the followup

d

Sivapradeep wrote:... So the user enters his password and vsam name that has to be downloaded in Windows browser ...

Was this scheme approved by security??? There are mechanisms in the security packages to handle this type of issue.

There are more issues here than meets the eye. For example, it appears the password is sent in the clear from the user's terminal to your application, and then in the JCL your application submits. This is not a good design. A better design has your application validating the alleged userid and password. This way the password, if sent in clear text from the user's terminal, can be discarded. You do not want clear text passwords hanging around in storage!

Your application can submit the job to retrieve the data using "surrogate" authority which allows it to submit the job with the USER=xxx JOB statement parameter without the password. "Surrogate" authority is normally used by job scheduling packages, but this is probably a valid use of it.

Hi Steve.. giving surrogate access to my tool might not be possible easily I guess from the admin team.
Instead I'll try to implement some encrypt algorithm using java at Windows and correspond decrypt algorithm in MF side.. this may eliminate the problem which u told about " clear password "