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 [1] - I once encounter a loop (definition of loop: 'look at definition of loop') from such a job. In one step there was a submitter step using SYSOUT=(?,INTRDR). That job also contains a submitter step. It really helps that we setup JES2 that duplicate jobs are made waiting instead of running immediately. Great fun ... ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
