Tony > > I also want to block the ability to enter logon applid command (may be by userid, even of the solution will require entering userid & password). How to achive that?
> I doubt you can do that with USS, but I may be wrong. Interesting! This would appear to depend on how the LU was defined to VTAM. If a LOCAL statement is used, there is no avoiding the SSCPFM operand specifying SSCPFM=USS3270 (or SSCPFM=USS3275) which implies that Unformatted System Services (USS) commands will always be valid - and interpreted by VTAM's protocol conversion logic for pre/non-SNA channel- attached 3270 devices. These days this support covers OSA-ICC and the like. If an LU statement is used, following VBUILD TYPE=SWNET or VBUILD TYPE=LOCAL for example, the SSCPFM operands could be set to SSCPFM=FSS which should make it impossible to enter USS commands - I would expect although I've never tried it - any volunteers? If SSCPFM=FSS does work as a way to block the use of USS commands, in order to allow the LU to get into session, the LOGAPPL operand will be needed, perhaps to log onto a session manager application if many business applications are to be accessed. Now if you are using the Communications Server (CS) TN3270 server for access to the SNA part of the network, again USS tables can be used. However, if access is restricted with the RESTRICTAPPL statement, even if the USS table is used, the solicitor panel will (also) be used in order to validate the user with a userid and password. Again, this isn't something I've tried but this is what the description of the RESTRICTAPPL statement in the CS IP Configuration Guide tells me in Chapter 10, "Accessing remote hosts using Telnet", "Mapping methods", "Application mapping statements". However, this may not be what Itschak wants since it is checking access in VTAMA for access to CICSB rather than checking access in VTAMB. > But there is nothing to say you have to provide a USS screen to your users. Indeed, you need to code up an USS table in order to be able to present an USS message 10. If you don't code up an USS table, you will get the default commands and messages so just not having an USS message 10 has no effect on preventing the entry of a LOGON APPLID(xxx) command. A user just has to have the wit to know that he/she can enter the command even if the emulation window is blank. Actually, if he/she is SNA-3270-savvy, he/she will know to look for a "stick man" symbol at the lower left of the window or, strictly if the emulation faithfully follows 3270 device behaviour, to press the key combination corresponding to SysReq in order to change the symbol from a question mark to a "stick man". That's why I told Itschak before that entry of LOGON APPLID(xxx) cannot be prevented by techniques in coding the USS table. However, fiddling with the SSCPFM operand is something I hadn't considered before! Note that, by coding alternative USS LOGON (and LOGOFF) commands, you do not prevent use of the default commands. It's a bit like ISTINCLM and the MODETAB operand. Chris Mason On Tue, 13 Jan 2009 18:53:37 -0500, Tony Harminc <[email protected]> wrote: >2009/1/13 Itschak Mugzach <[email protected]> >> >> Please have a look at this scenario: >> >> CICS of organization "A" is connected (LU6.2 Connection) to CICS of >> organization "B". No problem with that. I looked into the CDRM and found >> some other application of organization "B" defined in VTAMLST of oranization >> "A". Tried LOGON APPLID(xxx) and gpt the GMtran of org. "B" (if it is the >> default, I can travel in this CICS...). I also riched TSO logon etc. >> >> Now, I want to block (at) org "b" ability to get to org "a" applications >> other then the CICS connection that was agreed between Org "A" and "B". Is >> this possible? > >Sure, but you have to code up a VTAM Session Management Exit (SME). >This is described in the SNA Customization book. The summary says "The >session management exit is a multi-function exit that you can use to >control and manage LU-LU session-related functions. You can use the >exit to authorize session establishments, obtain session accounting >data, and better manage SSCP and GWPATH selection." > >Coding a basic SME is not too difficult, but getting it to do what you >want flexibly is a little harder. You could just hard code the >sessions to be allowed, or those to be denied, but then if somone >changes the naming conventions, you have a problem. > >There is at least one commercial product, Blockade For MVS, which has >been around for a long time (since 1988), that manages and authorizes >SNA sessions in a very flexible way based on RACF permissions, and >also provides management of 3270 logons via a session manager. This >was developed by Blockade, was acquired by Proginet in 2005, and has >recently been acquired by Beta Systems Software. I guess I should >mention that I work there... > >> I also want to block the ability to enter logon applid command (may be by >> userid, even of the solution will require entering userid & password). How >> to achive that? > >I doubt you can do that with USS, but I may be wrong. But there is >nothing to say you have to provide a USS screen to your users. > >> What other alternatives are offered to connect to vtam applications when USS >> tab is displaied, other then LOG APPLID and selecting from the uss tab? I >> mean, is there any bypass to LOG APPLID if blocked? > >Um, Blockade For MVS can help with that too. > >Having mentioned this product, since I'm in development, not >marketing, I should say that I'm not sure if it is being actively >marketed any more. Certainly it is still fully supported, and running >happily at a number of customer sites, but controlling SNA connections >is nowadays a "legacy" niche. But if it's what you need, it works very >well. > >Tony H. ---------------------------------------------------------------------- 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
