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
