we are just referring to parmlib and other systems settings here -not RACF databases or sensitive application data. for whatever reason an applications programmer has to look at this stuff, be it a real buisness need or just their own curiousity and desire to expand their knowledge, there is no real reason not to let them do so, including the say-so of some clueless auditor.
as for SMPE datasets, I was only referring to being able to look at other compoenents SMPE datasets for which there is a real need for in debugging a product using a different SMPE environment. Which SMPE datasets a product uses is a function of the vendors installation requirements, not some management security policy. Fortuneatly, this issue was resolved here a long time ago. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Thursday, June 21, 2007 1:43 PM To: [email protected] Subject: Re: how to list LE options -------------------------<snip>------------------------------- > that in most medium to large organizations, lines do need to be drawn > > >>in order to keep people focused on the jobs they are hired to do >> >> > >I take this to mean keep them stupid so that they cannot get a job >anywhere else. > > -----------------------<unsnip>------------------------ Not necessarily. But how often do these same people look at the whole picture, instead of just their piece of it? ------------------------<snip>-------------------------- >And just why is it a security breach to allow someone to look at a >dataset they cannot update? > > -----------------------<unsnip>------------------------- Just ask your auditors. Would you want your users browsing the RACF database? Or payroll information in the accounting department's files? NOT ME!!! -----------------------<snip>----------------------------- >Certain applications programmers can also utilize things like >linklists and apf datasets as well as LE options so they should have >the right to at least look at how they are defined to the system. > > ------------------------<unsnip>------------------------- Each shop has its own needs and viewpoint. In our shop, all applications were run from a NON-APF, NON-LINKLIST library set. Language-related libraries were sometimes in LINKLIST, but we made this known and allowed browsing. LE options were copied to an application parmlib, as were COBOL Compiler defaults, SORT options, etc. We found alternative mechanisms to give applications programmers the information they had legitimate need for, then we locked the PARMLIB, with (finally) management approval. ------------------------<snip>---------------------- >a long time ago the MVS group here would not even allow the CICS and >other groups to browse their SMP datasets. >Well we saw how long that lasted! A good portion of the systems >problems I encounter in CICS are due to bugs in other components like >LE, DFSMS, VTAM, etc. > > ----------------------<unsnip>--------------------- There's no reason that Database, CICS and other groups can't maintain their own SMP/E datasets, though I found that some guidance always made for happier relations between systems and other groups in this area. Not edicts, but suggestions and the benefit of experience for new users of SMP/e. Cooperation is a key aspect of dealing with SMP/E in all the different environments. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
