Userid doesn't have access to data set

Hello there,

I'm trying to run a job on zOS mainframe.  I've created my data sets, IND$FILE'd my COBOL and run JCL etc. and I can successfully submit the job.  

The problem is that the job then sits in the input queue.  When I look at the job in sdsf I see reference to the user not having access to the data set.  

I'm not sure what to do.  i created the dataset with my userid but when I submit the job it asks me to add characters to the job.  So, if I type an A for instance, It will say myuserA doesn't have access to the dataset myuser.blah.blah

Any idea what I can do?

Obviously I don't know too much about mainframe.  

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

You will not get an security violation on file access until after the job starts to run.

On z/OS TSO user-ids are limit to 7 characters.  This is so that the system can automatically add a 8th character to uniquely identify jobs.  Job names are limited to 8 characters.  

If the job is not running there are a couple of things that could be going on.

1) Do you happen to have TYPRUN=HOLD on the job card?
2) You have submitted the job in a job class (CLASS=x) that either does not exist, the initiators that are allowed to run CLASS x are drained, or they have jobs already running in them.

You need to check with somebody to see what class you should be using.

Can you copy and paste full message that says you don't have access to a file?
ttist25Author Commented:
Sure - here you go:

 20.58.29 JOB06585 ---- FRIDAY,    16 MAR 2012 ----                            
 20.58.29 JOB06585  IRR010I  USERID AJKB1    IS ASSIGNED TO THIS JOB.          
 20.58.29 JOB06585  ICH70001I AJKB1    LAST ACCESS AT 20:52:00 ON FRIDAY, MARCH
 20.58.29 JOB06585  $HASP373 AJKB1#   STARTED - INIT 48   - CLASS P - SYS SYSB  
 20.58.29 JOB06585  IEF863I DSN = AJKB1.SOURCE.COBOL AJKB1# RC = 04            
O.K.  This is not a security violation, its a "sharing" violation.  Meaning something else has the file open and in use.

Are you by chance browsing or editing the file in TSO?

In your JCL do you have DISP=OLD or DISP=SHR on the DD statement that has DSN=AJKB1.SOURCE.COBOL?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
CompTIA Cloud+

The CompTIA Cloud+ Basic training course will teach you about cloud concepts and models, data storage, networking, and network infrastructure.

ttist25Author Commented:

When I was doing some googling I thought I read something about a bug where a backup would hold open a data set?  Could this be related to that?
ttist25Author Commented:
Thanks again Ggiltjr.  I'm thinking there was some other process holding the data set captive.  It ran fine a while ago.  

Yes, some other process was holding the file.  The system programmers should be able to find out what next time.

As for the bug and backup.  It depends on the backup software and how it works.  It's possible, but unlikely.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Mainframe OS

From novice to tech pro — start learning today.