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
