Victor, I was going to say that ENCRYPTION was not a start option (ENCRYPTN) nor an operand of the APPL statement (ENCR) nor, indeed, the MODEENT macro of the MODE table (ENCR) , another VTAM entity you just mentioned. However, I realised that you were reporting some text from a DISPLAY ID=x, where x is the name of the LU entity, in this case corresponding to an APPL definition.
It might actually have helped if you had your VTAM man raise these issues - but perhaps he/she is shy. :-) So it looks as if you are getting ENCR=OPT by default from your APPL statement definitions. If you use the D NET,VTAMOPTS command, or, to be more precise, D NET,VTAMOPTS,OPTION=ENCRYPTN, I expect you will see ENCRYPTN=YES, this, again, being the default value. The consequence of all this is that - I'm guessing now - when you start an LU 6.2 session from one mainframe to another mainframe on both of which the ICSF product has been installed, you will get these messages, one for each of the parallel sessions. If you really don't want VTAM to use ICSF and you want to avoid having to ask your RACF group to open some security window - I know I had to have a very good story prepared when I had to go through this hoop, you can simple ask your shy VTAM person to code ENCRYPTN=NO whenever and wherever you install the ICSF product - which is also obviously "danger-free". > (like you said, the manuals do not explain too much this point). In addition to beating on the manual authors for getting the APPL statement ENCR operand value default plain wrong, I think I'll have a go at the VTAM developers for being really rather silly enabling cryptography support by default if a cryptography product is installed. Unfortunately it's bad practice - not to say that it hasn't been done! - to change defaults "on the fly" between releases or with an APAR. Perhaps the best we can expect is a message during VTAM initialisation whenever a cryptography product is detected and the ENCRYPTN start option is not coded. Incidentally, you are correct that the BIND image which corresponds to a named mode table (MODETAB) entry is certainly something you want to avoid. Taking a look at the ENCR operand of the MODEENT macro, it seems to be setting values having some relationship with the values specified on the APPL statement and, wildly guessing, they are there for encrypted sessions when the secondary LU is not capable of modifying the BIND image. In other words, I strongly suspect that the ENCR operand of the MODEENT macro has no bearing on the current issue. Chris Mason ----- Original Message ----- From: "Víctor de la Fuente" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Wednesday, 08 March, 2006 12:25 PM Subject: Re: Annoying ICSF-RACF message For sure RACF message is pointing JOB and STEP. My problem is not grant access, it is/was knowing why VTAM is trying to use ICSF. I already said I'm not the VTAM guy, so I don't know about APPL definitions. But I was looking at some definitions and I realized the nodes with ENCRYPTION=OPTIONAL are those defined as is, without using the MODETAB word (which I think* it's some kind of template). So I supposed the OPTIONAL option was the default parameters (like you said, the manuals do not explain too much this point). But now that we know why was these VTAM access to ICSF, I'm almost sure we'll grant the access to VTAM (I'm neither the RACF guy), because there is no danger in that. Again, thank you all very much for your answers! *I can't afford nowadays wasting time in looking for that information. ---------------------------------------------------------------------- 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
