Re: track submitted jobs
On Thu, 23 Mar 2017 08:03:48 -0500, Elardus Engelbrecht wrote: > >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 > That, and many others below, use ISPF Edit/Browse, which uses TSO SUBMIT after copying to a temp DS, making tracing harder. >- 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 > That would be /bin/submit which uses the Rexx submit() function. >- 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 ' (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... > - Certainly NJE. - For a guest z/OS, another guest may spool punch to that guest's virtual reader. IIRC, Ed J. (Mark Z.?) said that still works. But that reader could be varied off. Do any of these *not* use INTRDR? >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... > Restrict allocating SYSOUT(,INTRDR) to APF authorized programs, then front-end all (how many?) authorized programs/services to write tracking records (SMF?) And you may find your worst offenders have fairly high privilege. That *should*not* involve a collateral requirement that all INTRDR input be Fixed-80. >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. > That just makes it harder to meet the OP's requirement which I see as somewhat legitimate. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Fwd: track submitted jobs
> Begin forwarded message: > > From: Elardus Engelbrecht <elardus.engelbre...@sita.co.za> > Subject: Re: track submitted jobs > Date: March 23, 2017 at 8:03:48 AM CDT > To: IBM-MAIN@LISTSERV.UA.EDU > Reply-To: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > 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 ' (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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: track submitted jobs
Worst case scenario, the TYPE26 JES Purge Record Contains three fields that might you can control for accounting purposes using RACF to control which USERID can access which Library (but I don't think MEMBER name control is available). SUBMUSER $EBCDIC8. /*SMF26SUI*SUBMITTING*USERID */ NOTIFYND $EBCDIC8. /*SMF26NN-JOB END EXECUTE*NOTIFY*NODE*/ NOTIFYUS $EBCDIC8. /*SMF26NU-JOB END EXECUTE*NOTIFY*USERID*/ Barry Merrilly yours, Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive technical questions: supp...@mxg.com Dallas, TX 75229 http://www.mxg.comadmin questions: ad...@mxg.com tel: 214 351 1966 fax: 214 350 3694 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of bILHA ELROY Sent: Thursday, March 23, 2017 6:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: track submitted jobs 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) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: track submitted jobs
Elardus Engelbrecht wrote: >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! Argh! To Paul Gilmartin, I humbly apologize for misspelling your valued name. It was a honest typo. Sorry, Paul. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: track submitted jobs
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 ' (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
Re: track submitted jobs
On 2017-03-23, at 05:24, Vernooij, Kees (ITOPT1) - KLM wrote: > There was an extensive discussion about this subject a few months ago. > Short answer: No. > Slightly longer answer: There are many ways to submit a job other than from a "library/member". The most practical approach is to promibit submitting jobs except by your scheduler, and let that scheduler do the tracking. >> -Original Message- >> From: bILHA ELROY >> Sent: 23 March, 2017 12:10 >> >> 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) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: track submitted jobs
There was an extensive discussion about this subject a few months ago. Short answer: No. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of bILHA ELROY > Sent: 23 March, 2017 12:10 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: track submitted jobs > > 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) > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
track submitted jobs
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) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
