Chris, I know all this, but I think that at the end of your answer you started to understand. Org. "A" and org "B" are partners that security shares CICS resources VIA a CICS connection. When defining the connection, you can limit who can use which trx (by identifying the user or by assigning a user to the connection and protect the transactions). Now, there is no way to stop some one in org "A" to simply logon to org "B" CICS. Believe me, I tried it and accessed many vtam applications. few of them where no protected well. Some of them uses default ACB names. the ability to finally logon into is depend on the level of security implemented at org "B". In many cases I tested, it was not a problem to enter in. I am sure I can do it with some success at any site. There are always holes in security.
I started my research at the CDRSC (what i called cross domain "CDRM") and found few CICS systems (including the one which is connected to the local CICS). Luckily, some of them where not up... Now that I found the door, I am looking to see how to limit Access from A to B by LU 6.2 from CICS and not from any terminal at "A". I think that the two organization agrred to connect their CICS systems on a limited services. Not to open a door to any terminal and to any vtam application. Assume that LOG APPL will accept netname.applid as P1... Regards, ITschak On Tue, Jan 13, 2009 at 10:43 PM, Chris Mason <[email protected]>wrote: > 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 > ---------------------------------------------------------------------- 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
