Itschak Let's see I have got your problem straight.
You have two VTAM nodes, VTAMA and VTAMB. There is a CICS application running in each node, CICSA and CICSB. You want to allow CICSA to have sessions with CICSB and you want to prevent all other possible sessions between VTAMA and VTAMB, say from a terminal subordinate to VTAMA, TERMA, in session with CICSB or TSOB and from a terminal subordinate to VTAMB, TERMB, in session with CICSA or TSOA. Let us now go back to the beginning of VTAM time, or actually not quite so far back - the early '70s, before SNA even[1] - but to the late '70s when VTAM got cross-domain function from being purely single domain before - and you had to start paying for it! If you wanted actually to have a cross-domain session you needed to roll up your sleeves and get defining. First of all you needed to arrange that the SSCP of one VTAM could be in session with the SSCP of the other VTAM: In VTAMA's VTAMLST VBUILD TYPE=CDRM VTAMA CDRM ISTATUS=ACTIVE,VPACING=63 the home CDRM VTAMB CDRM ISTATUS=ACTIVE,VPACING=63 one of the away CDRMs In VTAMB's VTAMLST VBUILD TYPE=CDRM VTAMA CDRM ISTATUS=ACTIVE,VPACING=63 one of the away CDRMs VTAMB CDRM ISTATUS=ACTIVE,VPACING=63 the home CDRM Note how only the comments change; this allows you to use the same definition in all VTAMLSTs - as long as you omit the comments which would now become confusing! Scanning the operands of the CDRM statement today I'm guessing that these two, ISTATUS and VPACING, are the only two available when the CDRM statement was first introduced. On the principle that the default value for an operand represents the behaviour before whatever function introduced with the operand was introduced, we can see that the two important operands to which I want to draw your attention have the following values: CDRDYN=NO[2] CDRSC=REQ[3] The footnotes have the explanations of what these operands actually do. I imagine that VTAM system programmers have been habitually coding CDRDYN=YES and CDRSC=OPT for so long - copied from some redbook sample like as not - that they have forgotten that these operands have these other values with just the effect you want. Thus that's all you need to prevent all cross-domain sessions. Except that with the introduction of APPN in VTAM, CDRDYN got sort-of copied to the start options so you need to make sure that CDRDYN=NO is specified in the start options. But now you need to permit those sessions you actually want. Here's where the hard work used to come in when cross-domain was first available. However for you it's easy since there is only one session you want to allow. In VTAMA's VTAMLST VBUILD TYPE=CDRSC CICSB CDRSC CDRM=VTAMB,ISTATUS=ACTIVE In VTAMB's VTAMLST VBUILD TYPE=CDRSC CICSA CDRSC CDRM=VTAMA,ISTATUS=ACTIVE Again, I can't see CDRSC statement operands other than the two I've shown being relevant. QED! And there's no need to reach for your cheque book buying products which offer no function - for you anyhow - other than VTAM provides at no extra cost.[4] If you have other systems, domains, and you want sessions to be established with those other domains with dynamic definition of CDRSCs, you need to be sure that you so specify the CDRM definitions that only VTAMB resources are restricted. For example, you will need to ensure that VTAMB's definition of the VTAMA CDRM specifies CDRSC=REQ in order to prevent TERMA from being defined as a CDRSC within VTAMB and thus is allowed to have a session with CICSB given that CICSB has a CDRSC definition within VTAMA. Chris Mason [1] Not a lot of people remember that! [2] <quote> Specifies whether the host CDRM is authorized to dynamically define CDRSC representations of cross-domain or cross-network resources when a session request is received from or sent to an adjacent SSCP or CP. CDRDYN=NO Causes the failure of any cross-domain or cross-network session request for a cross-domain or cross-network resource that has no predefined CDRSC entry. CDRDYN=YES Authorizes dynamic definition of cross-domain or cross-network resources by the host CDRM, eliminating the need to predefine certain CDRSCs. Both origin logical units and destination logical units can be dynamically defined. Note that for subarea nodes (HOSTSA start option is specified), the DYNLU=YES operand is meaningful only when CDRDYN=YES. Notes: 1. To allow dynamic resource definition, code CDRDYN=YES on the CDRM definition statement for the VTAM host CDRM and CDRSC=OPT on the CDRM definition statement for the owning SSCP. 2. An intermediate host can also build dynamic definitions for CDRSCs. 3. The CDRDYN start option overrides the CDRDYN operand value. You can use the MODIFY VTAMOPTS command to change the value of CDRDYN. </quote> [3] <quote> Determines whether resources owned by the CDRM being defined by this statement can be dynamically defined at the time a session request is received from or sent to the external CDRM that manages the resource. The value you specify determines whether dynamic CDRSC definitions are allowed when cross-domain or cross-network session requests are received from or sent to certain domains. Note: CDRSC is used only for SSCP-SSCP sessions. CDRSC=OPT Authorizes dynamic definition of cross-domain or cross-network resources from this CDRM, eliminating the need to predefine certain CDRSCs. To allow dynamic resource definition, code CDRSC=OPT on the CDRM definition statement for the owning SSCP and code CDRDYN=YES on the CDRM definition statement for the VTAM host CDRM. CDRSC=REQ Causes the failure of any cross-domain or cross-network request to or from this CDRM for a cross-domain resource that has no predefined CDRSC entry. </quote> [4] A can't say "for free" since, as I said before, VTAM from ACF/VTAM V1R1 became a "program product". On Wed, 14 Jan 2009 08:00:36 +0200, Itschak Mugzach <imugz...@gmail.com> wrote: >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 <chrisma...@belgacom.net>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 >> <imugz...@gmail.com> 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html