Itschak I'm afraid you'll need to clarify rather a lot here!
A CICS application in session with another CICS application is one thing. A session initiated by means of Unformatted System Services (USS) is quite another. Your CICS-CICS session is LU type 6.2. Any session initiated with the aid of USS will never be LU type 6.2. It is very likely to be LU type 2 or - unlikely - LU type 1 or, if using pre/non-SNA channel-attached 3270 or 3270 look-alike, LU type 0 with a 3270 data stream.[1] So we can ignore your mentioning the CICS-CICS session as irrelevant. I have no idea what you might mean by "looking into the CDRM". Please explain. You will find the names of cross-domain LUs which may be application LUs in CDRSC major nodes. Normally today - since the early '80s - same-network CDRSCs will be allowed to be defined dynamically. Of course, inertia lasting nearly 3 decades now may have allowed such definitions still to exist. Again a bit of clarification and possibly correction is needed here. "GMtran" is the term using for the CICS "Good Morning" message I believe. If you get this you must have logged onto CICS so I'm not sure why you are talking about other cross-domain applications. You had better explain how you knew how to log onto the other, cross- domain, TSO. You need only explain where you found the name to use in the LOGON APPLID(the-other-tso). You should make sure you are not talking about session monitor applications. If you can log onto a session monitor application on the other, cross-domain, system, you will be able to access whatever is presented - but normally access can require a userid and password. You seem to be confused by USS. USS traffic happens only same-domain. It operates over the SSCP-LU session which is, by definition, same-domain. Or maybe I'm just confused by the way you have expressed yourself. If you want to prevent some combinations of session, you can do so by means of the session management exit. Alternatively, you can discard all the nice dynamic capabilities for which VTAM customers cried out in agony at having to create so many definitions all those years ago and forbid the dynamic creation of CDRSCs.[2] You can define CDRSCs in both systems for the other CICS system so that only that session can be established cross-domain. I now see - I think - why you mentioned the CICS-CICS session. I think I may finally have fought my way through the obfuscations to that to which what you are really driving. Have I? Incidentally, back in the early '80s, I recall my colleagues and I trying to work out whether or not use of LOGON APPLID could be prevented by some particular coding of the USS table. It can't! Chris Mason [1] There are others historically but very, very unlikely today. [2] Post again if you need help with this. Essentially, it's in the definition of the CDRM statements. On Tue, 13 Jan 2009 21:33:35 +0200, Itschak Mugzach <[email protected]> wrote: >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? >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? >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? > >Regards, > >ITschak ---------------------------------------------------------------------- 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
