|
View previous topic :: View next topic
|
| Author |
Message |
rulerofera
New User
Joined: 03 Jun 2008
Posts: 30
Location: India
|
|
|
|
The other day I was looking for a way to override the USER and PASSWORD parameter of job card from within STEP, probably first STEP of JCL, and also want it to apply for rest of the job i.e. should function same as been mentioned in job card. IF this can be achieved possibly through some utility, and reading the parameters through dataset, so as to hide the USER name and PASSWORD from prying eyes.
Is this possible, can please anyone help ??  |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
ask Your security support group -
what is the serious business reason to change user in the middle of a job ?
please don' t reply "that' s the requirement"
since You want to do it in the first step, what reason not to submit the job with the right user to start with
furthermore no need to have passwords hanging around..
scheduler support to submit jobs on behalf of different users,
jes early validation, user propagation, surrogate user id, ...
have been around for years
so there is no need to play useless tricks |
|
| Back to top |
|
|
rulerofera
New User
Joined: 03 Jun 2008
Posts: 30
Location: India
|
|
|
|
See... to put out real scenario.. we use USER and PASSWORD in job card for production retrieval while testing, since other normal programmers ID dont have access rights to production loadlibs.
So when we draft a production retrieval JCL, we mention that USER and PASSWORD. Now sometimes on account of human negligence this passwords gets violated, so was thinking if there is a way out to update this at one place .. probably within a dataset and use that in some step... and then make everybody include that step for production retrieval jobs...
there is no such business requirements as such.... but a fix of sort the way i see it... if there is any other way please suggest .... |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
looks like Your security design is flawed..
| Quote: |
| since other normal programmers ID dont have access rights to production loadlibs |
the loadlib hierarchy shoud have read/execute access permission for all the development groups...
nobody will get hurt by using a production version of a program...
development should have access (read/execute at least ) to all the load libraries
during the development stages a mix of unmodified and modified programs will be used
the real protection should be done on the data
or, but thats the worst thing to do, play around with the surrogate userid capability
- i.e. the possibility for a user to submit jobs with somebody else userid specified in the job card
worst thing because all the rights of the surrogate user will be used
strong advice, review with Your security group the access permissions for the load libraries |
|
| Back to top |
|
|
HappySrinu
Active User
Joined: 22 Jan 2008
Posts: 194
Location: India
|
|
|
|
| if using any SCm tool like Endevor/CHangeman you can retrieve your production stuff using these tools as well. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
| HappySrinu wrote: |
| if using any SCm tool like Endevor/CHangeman you can retrieve your production stuff using these tools as well. |
Even if you do not have the required access ?
As Enrico has said, the best option is to discuss your needs / requirements with the security team.
Surrogate user seems a good idea, especially as it can be setup with a static password which need not be coded on the jobcard, and its usage can be limited to those authorised to use it. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
I reread the whole topic,
is the issue is only for load libraries no reason at all to give execut access to all the development groups
unless as usual, the topic was poorly described, or the requirement were not clear to start with |
|
| Back to top |
|
|
|
|
