> Begin forwarded message: > > From: Elardus Engelbrecht <[email protected]> > Subject: Re: track submitted jobs > Date: March 23, 2017 at 8:03:48 AM CDT > To: [email protected] > Reply-To: IBM Mainframe Discussion List <[email protected]> > > bILHA ELROY wrote: > >> For accounting purposes we need to know the name of the library/member that >> the job was submitted from. >> Is there any way we can find out. (The job was scheduled not through >> CONTROL-M and similar) > > You already got one reply of "NO". There were some similar threads last year. > Same old "NO" story. > > And Pual said "The most practical approach is to prohibit submitting jobs > except by your scheduler, and let that scheduler do the tracking." - I agree! > > > Sources of jobs: > > - Programs spitting something out in INTRDR (This is, for example, what I do > for every day. I use LISTC and CSI to build up DDs as concatenated input > before submit) > - SJ in SDSF or similar products > - FTP > - Scheduler ( ... and Control-O which can submit something based on activated > rules) > - ISPF panels for other products (DB2 utilities, zSecure, etc.) can build up > jobs for you. > - "Launcher job" - A job which spits something in INTRDR - Note, "launcher > job" is not my invention, it was mentioned last year. [1] > - Submit it yourself from a PS dataset, OMVS file, etc. > - Use Unix or zLinux (and perhaps others) pipe command '|' to pump something > into JES2 > - Exits (My SMFU29 exit does sort of that automagically that when a MANx > fills up. I said sort of, because it is actually it issues 'S <STC>' (not > Submit) to start a STC with that MANx dataset as parameter. Yet another job > from a library. ;-D ) > > There are other sources from where jobs can be submitted... > > > To track: > > You can use RACF and SMF to track who is the OWNER of that job. > Or better, use RACF to control usage of JOB accounting lines and monitor any > changes of libraries. Think about SMF 42 for member auditing. > Implement better security in Control-M and Control-O using that OWNER in your > job schedule. > > (You can try to enforce job standards, but you will get some crazies who like > to bypass any standards your trying to enforce.) > > Or, just close down all INTRDR for fun. Then you have no z/OS to play with, > but have lots of time to battle with angry users... > > Note: Not even JES2 can see from where the job is coming, because another > address space is placing contents from a source into INTRDR. Only when you > close that INTRDR, then JES2 picks up whatever there is and tries to > interpret it. > > Perhaps there is some tracking software/method available... > > Groete / Greetings > Elardus Engelbrecht
One place I worked had strict job naming standards and it was enforced by various exits mostly SMF and JES. *IF* the job *ONLY* came from this one production library then it was given the RACF userid & Password. If it didn’t come from that library it was flushed. If a user submitted a production job he/she better have the rights to access Production datasets if they didn’t it got a 913 abend. We were merciless in our facility that production was KING or emperor if you prefer. There were no arguments no maybe’s no if’s PERIOD. The auditor came down open you like a hammer if they caught you and they looked at everything. A long time ago I was running a SMPE job that applied 5 years of maintenance (we were that far behind). I was getting logged all over the place because I was updating sys1 datasets. I got a call from the auditor asking what I was doing. I told him I would be happy to bring the output to him and explain every message (there were thousands). I brought the output up to him in several carts. I then proceeded to explain each message and why I needed update. After 30 minutes or so his eyes glazed over from so much data he said fine. I never had to explain again why I needed access to sys1 datasets. The big issue is that you have to lock down *EVERYTHING* and stick to it and no BS either. A few years later I was called into a meeting (unannounced) and sat in while a programmer updated a dataset he shouldn’t of (it was a semi production DS meaning it wasn’t used in production but in system assurance testing). I got the general idea he thought he could bluff his way through but he couldn’t and was escorted out of the building right after the meeting. In summary you must be serious and be prepared to back up every decision that you may make and have a damn good reason. And you have to have *EVERYTHING* locked down. Ed ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
