Bob Please see the post which adds to my initial post in this thread.
> When IBM suggests UACC(NONE) for a system dataset, this is usually an > indicator the dataset contains security control information that should be > kept secret. If you rely on the VTAMAPPL class for proper security, VTAMLST partitioned data sets don't - with the possible exception of the means to reconstruct configuration information of a business rival which no longer applies in these post-SNI days - see my earlier post. > In this particular case, it may ... I'm not interested in "may" but precisely what. System programmers should not have to be dealing with "Smoke and mirrors"! > ... such as the ability to specify clear text passwords with PRTCT= on VTAM > APPL definitions. I'm also not interested in "such as" but "precisely as". Taking the case of PRTCT, this was what passed (playing with words!) for security in the mid-1970s and - rather a joke - development described it as being a "password". So very obviously the VTAMAPPL class knocks spots off the PRTCT operand. Do you have any VTAM features in mind other than PRTCT or was "such as" an application of the "mushroom" principle? > Whereas the RACF team at IBM may not always provide detailed information > about why they made a particular suggestion, I have always found them to be > very thoughtful and never arbitrary. That Table 48, "UACC values for system data sets" in the z/OS Security Server RACF Security Administrator's Guide manual falls foul of the principle that you cannot - a priori - take what product A says about product B as reliable.[1] I will accept they are not arbitrary and demonstrate thought when they justify their pontifications and indicate what their wise thoughts actually were! > Whereas the RACF team at IBM may not always provide detailed information > about why they made a particular suggestion, ... IMNSHO this is an unacceptable approach. Even if they discuss RACF topics where we might hope that they are reliable, there should be reasonable explanations. However RACF would not be alone in exhibiting such a deficiency; the Communications Server product, which I know best if it wasn't obvious, can be found wanting in this regard also. - [1] One example of this I mention from time to time and have done so recently is the sample APPL statement for the secondary LUs managed by the SNA-oriented TELNET server provided in SEZAINST member VTAMLST. It is IMNSHO approximately half-right and so is approximately half wrong - and this is one side of the same product talking about the other side![1.1] TCP00001 APPL AUTH=NVPACE,EAS=1,PARSESS=NO,MODETAB=ISTINCLM,SESSLIM=YES Wrong half: The AUTH=NVPACE operand is utter, unmitigated rubbish! The MODETAB=ISTINCLM operand is addlepated! Right half: The EAS=1 operand is obviously correct and saves 4K in comparison with the default EAS=509. The SESSLIM=YES operand is obviously correct and has a rather complex role to play in some configurations as indicated by an APAR the text of which is no longer available. Dubious (tending to wrong): PARSESS=NO is pointless since it is a default for which PARSESS=YES is the override which adds function. [1.1] Well, we must recognise that z/OS Communications Server originally was a product A, VTAM, and a product B, "TCP/IP for MVS" . - Chris Mason On Sat, 10 Mar 2012 06:40:35 -0500, Robert S. Hansel (RSH) <[email protected]> wrote: >Chris, > >When IBM suggests UACC(NONE) for a system dataset, this is usually an >indicator the dataset contains security control information that should be >kept secret. In this particular case, it may have to do with options such as >the ability to specify clear text passwords with PRTCT= on VTAM APPL >definitions. Whereas the RACF team at IBM may not always provide detailed >information about why they made a particular suggestion, I have always found >them to be very thoughtful and never arbitrary. > >Regards, Bob ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
