We secure the Jobclasses via RACF, and assign WLM Service class according to Job Class.
We have 5 groups of Inits (and associated WLM Service for those), Production, Prod Control/DBA, Systems Programmer, End User (non IT), and Developer/Programmer. Dev/Programmer in the Prod Sysplex are Discretionary Workloads or have resource caps. Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 738 9443 Corporate Tieline - 89443 If you feel in control you just aren't going fast enough. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Elardus Engelbrecht Sent: Wednesday, January 07, 2015 11:14 AM To: [email protected] Subject: Re: How Does Your Shop Limit Testing in the Production LPAR Karen Herle wrote: >I am curious about how other mainframe shops deal with AD-HOC and test batch >jobs that run in the PRODUCTION LPAR. >We have encountered several issues with programmers or DBAs running non >production jobs on our production LPAR which cause CPU resource issues or DB2 >contention issues that have resulted in performance degradation to our CICS >and production batch jobs. Bad ass programmers. You can always route complainers about response time/transaction rate to these programmers. >How does your shop deal with this? Do you restrict access to your production >LPAR? Are there processes to follow to request test or data mining, non >production jobs in your production LPAR? Do you use your security product >(RACF/ACF2) to control the access to production data? Shared RACF DB or not? If not shared, this should be easy. If shared, consider using different naming standards and then try using PROGRAM class in RACF. Of course, if IBM (CICS/DB2) programs are used, this will probably not work depending on your naming standards. If they're using proclibs, that's easy. Just lock up these proclibs and throw away the keys. Of course, if they're submitting jobs from test LPAR to prod LPAR, you can lock that incoming/outgoing jobs. Or try giving DIFFERENT userids. One set of ids for play/test and another set of ids to work. You can use DB2 grants to lockup the play ids. Or use WLM and change their job priority so they are in 'Siberia work priority'. (absolute low priority, so low, it is freezing) Or use automation package to scan for JCL things like production datasets and block/hold/purge them. >We are actively looking at our options at this time and I am trying to balance >the need for programmers to access the production environment but also need to >protect our 4 hour rolling average and contention with DB2/CICS. You can use automation to prevent/postpone usage of running jobs by owner, initiator, jobname, etc. Or you can use automation to simply cancel the jobs. No sweat. Or drain all your initiators. [1] Hold those annoying jobs and release them when you have spare CPU cycles. Or limit access via DB2 or RACF to DB2 resources. Same goes for CICS transactions. >Any and all comments welcome. Threaten them with pavement promotion or revoke their ids... Involve your management so you have some co-operation. PS: you could ask them to copy datasets to an idle machine and have them run their jobs there. That's what I did. Moved hard working jobs to a LPAR on a machine with lots of spare CPU cycles. I and my colleagues used RACF/automation/tools to enforce that. Groete / Greetings Elardus Engelbrecht [1] - I believe an IBM-MAIN member does that trick. Only one person has access to open/close initiators and release jobs. The rest has to bribe that lucky person... ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN "Email Firewall" made the following annotations. ------------------------------------------------------------------------------ Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. ============================================================================== ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
