Re: command=verify
On 10 Jun 2013 12:53:04 -0700, in bit.listserv.ibm-main you wrote: I'm being told we use MacKinney Batch and the open/close commands are within the batch job. We also have Mailbox,job scheduler commands in the JCL. 100's of them. Those both sound like application commands, not operating system commands and thus JES/RACF/etc. would be dealing with them only if the application asked those systems to. Am I missing something? Clark Morris -- 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: command=verify
I'm being told we use MacKinney Batch and the open/close commands are within the batch job. We also have Mailbox,job scheduler commands in the JCL. 100's of them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: command=verify
Hope your auditor doesn't find out;-) ed On Jun 10, 2013, at 2:52 PM, gsg wrote: I'm being told we use MacKinney Batch and the open/close commands are within the batch job. We also have Mailbox,job scheduler commands in the JCL. 100's of them. -- 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: command=verify
Open and close are not z/OS or JES2 commands. (Are they JES3?) In any event, since they are issued by the batch programs they would not be affected by the command=verify setting. Since command=verify is merely an auditor recommendation, it is up to management to either accept the current risk and not implement the recommended setting or direct your staff to develop new procedures that will work with the new setting. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of gsg :: Sent: Monday, June 10, 2013 12:53 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: command=verify :: :: I'm being told we use MacKinney Batch and the open/close commands are :: within the batch job. We also have Mailbox,job scheduler commands in :: the JCL. 100's of them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: command=verify
W dniu 2013-06-05 00:49, gsg pisze: We have been told by auditors that all of our JES2 JOBCLASSes should have COMMAND=VERIFY. This would protect from someone coding an unauthorized command in a JCL that could go undetected. Has anyone else ran into this type of problem and if so, how did you protect against it vs. coding COMMAND=VERIFY. Coding COMMAND=VERIFY could potentially elongate our batch window and overwhelm our operators with replies. Anyone got a solution? Yes, there is a solution, quite good IMHO. It is called OPERCMDS - a RACF class. Instead of operator decision I strongly prefer the rules enforced by security server. Simply use COMMAND=EXECUTE and rely on OPERCMDS profiles. IMHO there is no big reason to deny commands from batch. Protect the resource, not the tool. If the user is not authorized to issue GIVEN command, he will not be able to do it neither from job, nor from EMCS console. And OPERCMDS class allow us to use different rules for different commands, like FORCE and DISPLAY. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: command=verify
Radoslaw Skorupka pisze: Yes, there is a solution, quite good IMHO. It is called OPERCMDS - a RACF class. Instead of operator decision I strongly prefer the rules enforced by security server. Indeed. Ability to block commands despite source [1] is still the best. Here, I agree to agree with Radoslaw!!! Note: there are TWO sources of COMMAND in JCL: //[name] COMMAND 'command ...' and /*$command-verb, Both resulting commands can still be blocked by RACF or any other ESM. On the otherside, we limit usage of that JCL statements by JOBCLASS. If the user is not authorized to issue GIVEN command, he will not be able to do it neither from job, nor from EMCS console. Agreed. Even if you open up the SDSF '/', you still need to open up the OPERCMDS class for that user. The OP needs to re-train his/her auditor. Groete / Greetings Elardus Engelbrecht [1] - Including SVC 34. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: command=verify
John McKown wrote: Have IT management risk accept they way you need. Then tell the auditors that. Auditors do not have any authority beyond what management gives them. Agreed. Actually, as Ted always said, auditors only recommends. They cannot enforce. This assumes management has tener cojones. Spanish for 'having the courage'/'have the balls'. ;-) See http://en.wikipedia.org/wiki/Cojones for background info. When working with auditors and managers, you need all the courage [1] to work with them... ;-) Groete / Greetings Elardus Engelbrecht [1] - In a galaxy far far away on a very lonely planet full of hungry aliens some centuries ago, I have a really hard time to convince auditors and management that I don't need no stinking ADSP in RACF. ;-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
command=verify
We have been told by auditors that all of our JES2 JOBCLASSes should have COMMAND=VERIFY. This would protect from someone coding an unauthorized command in a JCL that could go undetected. Has anyone else ran into this type of problem and if so, how did you protect against it vs. coding COMMAND=VERIFY. Coding COMMAND=VERIFY could potentially elongate our batch window and overwhelm our operators with replies. Anyone got a solution? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: command=verify
Have IT management risk accept they way you need. Then tell the auditors that. Auditors do not have any authority beyond what management gives them. This assumes management has tener cojones. On Jun 4, 2013 5:49 PM, gsg gsg_...@yahoo.com wrote: We have been told by auditors that all of our JES2 JOBCLASSes should have COMMAND=VERIFY. This would protect from someone coding an unauthorized command in a JCL that could go undetected. Has anyone else ran into this type of problem and if so, how did you protect against it vs. coding COMMAND=VERIFY. Coding COMMAND=VERIFY could potentially elongate our batch window and overwhelm our operators with replies. Anyone got a solution? -- 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: command=verify
Unfortunately, no one wants to challenge audit. I can understand the the risk, but just not this solution. It will create too many replies for the operators. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: command=verify
On Tue, 4 Jun 2013 18:05:04 -0500, gsg wrote: Unfortunately, no one wants to challenge audit. I can understand the the risk, but just not this solution. It will create too many replies for the operators. It's the boy-who-cried-wolf. Automate it. The auditors will moan that you shouldn't mindlessly grant authority. But the automated process can be more selective and more consistent than overworked operators. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: command=verify
We have run COMMAND=IGNORE for as long as I can remember. There are other far better and more controlled ways to issue commands. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 06/04/2013 04:24 PM Subject:Re: command=verify Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Tue, 4 Jun 2013 18:05:04 -0500, gsg wrote: Unfortunately, no one wants to challenge audit. I can understand the the risk, but just not this solution. It will create too many replies for the operators. It's the boy-who-cried-wolf. Automate it. The auditors will moan that you shouldn't mindlessly grant authority. But the automated process can be more selective and more consistent than overworked operators. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: command=verify
That is one thought we had and we'll be doing some testing for that. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: command=verify
Or . . . work with your Comp Ops to project how many Operators would need to be hired to properly respond to all of the new message traffic and project out the increase to annual expense. Then see who wants to sign off on that. Setting the value to command=ignore wasn't what they told you to do, they said set it to command=verify and if nobody's willing to challenge them then play the $$ card and tell them exactly how much it will cost to do that which they insist must be done. That said, FWIW, for all of the non-sysprog batch jobclasses we have command=ignore. But in your case I'd hold that in my back pocket after presenting them with sticker shock just for the fun of it - but then I'm known for having a strange sense of fun. ___ Karl S Huf | Senior Vice President | World Wide Technology 50 S LaSalle St, LQ-11, Chicago, IL 60603 | phone (312)630-6287 | k...@ntrs.com Please visit northerntrust.com CONFIDENTIALITY NOTICE: This communication is confidential, may be privileged and is meant only for the intended recipient. If you are not the intended recipient, please notify the sender ASAP and delete this message from your system. IRS CIRCULAR 230 NOTICE: To the extent that this message or any attachment concerns tax matters, it is not intended to be used and cannot be used by a taxpayer for the purpose of avoiding penalties that may be imposed by law. For more information about this notice, see http://www.northerntrust.com/circular230 P Please consider the environment before printing this e-mail. IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 06/04/2013 06:45:37 PM: From: gsg gsg_...@yahoo.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 06/04/2013 06:45 PM Subject: Re: command=verify Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU That is one thought we had and we'll be doing some testing for that. Thanks -- 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: command=verify
Am I the only one curious why your batch jobs have that many operator commands in the JCL? What we did was specify command=verify for all classes except one and we restricted that class so only sysprogs and operators could submit jobs in it. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of gsg :: Sent: Tuesday, June 04, 2013 3:49 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: command=verify :: :: We have been told by auditors that all of our JES2 JOBCLASSes should :: have COMMAND=VERIFY. This would protect from someone coding an :: unauthorized command in a JCL that could go undetected. Has anyone else :: ran into this type of problem and if so, how did you protect against it :: vs. coding COMMAND=VERIFY. Coding COMMAND=VERIFY could potentially :: elongate our batch window and overwhelm our operators with replies. :: Anyone got a solution? :: :: -- :: 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: command=verify
We never allowed *ANY* commands to come through a reader (of any type). The programmers had a field day with this until I put the rules in place. Got a few gripes from programmers but nothing to management. My management (and the auditors) were strictly against commands from readers. There were just too many issues. Ed On Jun 4, 2013, at 5:49 PM, gsg wrote: We have been told by auditors that all of our JES2 JOBCLASSes should have COMMAND=VERIFY. This would protect from someone coding an unauthorized command in a JCL that could go undetected. Has anyone else ran into this type of problem and if so, how did you protect against it vs. coding COMMAND=VERIFY. Coding COMMAND=VERIFY could potentially elongate our batch window and overwhelm our operators with replies. Anyone got a solution? -- 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
