"John Hooper" <jhoo...@foodlion.com> wrote in message news:<listserv%201007060855033012.0...@bama.ua.edu>... > This thread has had some interesting comments. I agree that in todays world > it is a terrible idea to develop your own screening or front-end code to provide > functionality. The ENQ front-end was done 15 years ago and has served us > well. It has allowed us to sort-of "have our cake and eat it too". Our > requirement was to prevent "test" jobs from adversely affecting "production" > jobs. This was in the days of a single LPAR and using the security system to > prevent all access was not deemed to be a good idea. I accept the fact that > this facility will be retired. I do have a question. What do most shops do to > prevent this condition? I see three options. I hope there are more. One - I > think CA-MIM can address this problem. Is that true? Two - Totally > physically isolate development from production and do not allow them to even > see production files. Three - Use the security system to not even allow READ > access. Again - how do you address this issue? >
I'd like to bring up another view on the original problem, a production job doing a dynamic allocation of a datasets that is in use. Actually the base problem is, that the a dynamic allocation *request* can generate both a *yes* and a *no* answer. Often applications don't realize the latter and don't cater for it. We had similar situations lately and then the job owners started blaming everybody else, including our backup- and other dasd maintenance jobs for breaking their application flow. Where in fact this is an application error for assuming that it will always get the requested datasets. After explaining this extensively to the development departement, together with written evidence from the IBM manuals on how to use dynamic allocation, they were convinced of their shortcommings. This will not immediately help you in your 15 years ago established situation, but might provide another solution path. Kees. ******************************************************** 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
