|
1). Fundamental principals that I follow are that no two qmgrs have
the same name and no two msgs have the same msg id.
2).
The simplest method is to use the same userids across systems. But
sometimes that method is not practical or not secure enough. There are many
alternatives--everything from proxies to elaborate login screens and exchange of
security tokens to establish who is sending requests. One scheme does not fit
all and figuring out a satisfactory solution is one of the most difficult parts
of an implementation. So much so, that it is often given lip service and
swept under the rug.
Not all applications have the requirement to
discriminate userids at the message level. But some
do--and not to lose sight of my original point--when that's the case, it simply
does not work to switch userids in the trigger monitor (as we know it).
regards,
Dennis
-----Original Message-----
From:
Adiraju, Rao [mailto:[EMAIL PROTECTED]
Sent: Thursday, March
04, 2004 8:00 PM
To: [EMAIL PROTECTED]
Subject: Re: MQ
Triggering in CICS
Dennis
Sorry to be pedantic BUT
1) if the first transaction "browse" the message and
decide the user-id, start the second transaction - how do you make sure that
the second transaction is reading the "exact" message that first transaction
has in mind for that user-id. In ME we don't have any Unique identifier/key concept
that identifies a message for subsequent retrieval. Correct me if I am wrong.
In absence of it, second transaction may read totally different message and
process it under "wrong" user-id. Unless of course, you are assuming that
either message-id, correlation-id or group-id uniquely identifies an user
(and not the identity context). Because only these three attributes can
be used as filters or indexes on MQ-GET.
Else the first application has to pass the identity
context as a commarea to the second transaction and then the second
transaction also has to do the browse first until it finds the matching
identity context and then issue a GET at the current cursor
. Is this what you have done in your design
??
2) Secondly how does one set the main-frame user-id - by
retrieving from ACF2 / RACF databases or build another database in
parallel to these security systems (with ongoing parallel maintenance with
these external security systems whenever an employee joins and leaves). Or are
you talking of a handful of proxy user-ids set by front-ends in user-id field
of the message.
I am asking these detailed questions
to learn from others experiences - so that next time I can use these
solutions.
Cheers
Rao
ps: I have seen some clients - where they keep
handful of mainframe proxy user-ids on the internet servers, and when the
client comes with digital certificate, translate it to one of proxy user-ids
and pump the data through MQ. On the main-frame CICS runs the
transactions under these proxy user-ids. If that's scenario, one is
talking about - I can see some point of it. Even there, the front end systems
keep changing their digital certifies to user-id combinations left and right.
So if some one has to track the "real user" - who has done a
particular transaction say three months back - good
luck.
1).
The design I've found most effective is for ABCD to browse the queue and START
the transaction with the desired userid. The transaction then reads the
message, calls a program to service the message and commits the
whole sha-bang after sending the reply.
3). Primarily it's to allow CICS security to
control who is allowed to do what. Often times we are using legacy apps
that are already designed around the CICS security model. Other times,
it's just more convenient than building a more sophisticated
security scheme into the application. I do agree that it only
provides a mediocre level of security and is not suitable for
all occasions. But sometimes the show fits.
regards,
Dennis
Yes agreed - if the logic is based on Message
(message-id or user-id) what you are saying is perfectly correct.
But from my experience the whole saga of setting a
user-id is a "can of worms" and frankly speaking I don't know what it
achieves. Don't take me wrong I did this in few sites but we lost the track
of "final" objective.
1) First of all in your scenario, ABCD transaction has
to "read" the message to interpret the message descriptor or
data, determine the user-id and then "somehow" has to
put the message back before it starts another application
transaction. This "somehow" may result into another trigger and so
on. Or secondly, move the message from MQ for good but save it
in either DB2 or CICS CMDT/UMDT tables, so that next transaction will have
somewhere to look for in case of recovery.
2) Most of important thing is to set any user-id the
current user-id of CKTI / ABCD should be "authorised" to do
so.
3) Critical question is what is this all for - is it
for accounting or security and audit trail on your databases. If you are
translating that to a real user-ids, there is NO non-repudiation and it is
not easy to "prove" the actual user is logged-on somewhere sometime to
put the original message. Unless one has a tight securities across
entire MQ middleware (not even allowing set identity context). If it is for
accounting - how on earth one is going to break down the CPU cost
for CKTI and ABCD transactions across various projects in the
organisation.
So if this does NOT stand for any security audit and
NOT for any accounting - why does it need to be done.
This dilemma I have gone through as an Enterprise
Architect and didn't get any satisfactory solutions and I did as we
"normally" do in I.T industry - just ignore the core problem and
continue building some beautiful solutions.
I am interested to hear others experiences.
Cheers
Rao
ps: my apologies if it offends any "beautiful"
solution
developers
Wait...there's a very important distinction between
those two approaches that is being overlooked. CKTI processes the INITQ
while ABCD processes the triggered queue. Therefore, unless you
radically alter the CKTI design, CKTI can only change the userid on a
per-queue basis, whereas ABCD can change userid on a per-message
basis.
Also, with respect to option 2, the
role of the TM is to start program ABCD. Once ABCD gets started,
the TM has been consumed and no longer has a purpose; "losing it", if
you want to call it that, is inconsequential. Perhaps you mean to
be concerned about losing a task that was intended to process one of the
messages on the triggered queue. Depending on how robust you want
the ABCD SIL to be, you may want to provide a contingency for
that. (Remember, a SIL is supposed to process the queue until EMPTY).
But even in the worst case scenario, if the SIL quits prematurely, it
would just re-trigger again and eventually find the stranded message.
-----Original Message-----
From:
Adiraju, Rao [mailto:[EMAIL PROTECTED]
Sent: Wednesday,
March 03, 2004 12:04 PM
To:
[EMAIL PROTECTED]
Subject: Re: MQ Triggering in
CICS
Peter
Yes - either you can customise CKTI transaction (the
sample code is provided by the IBM as part of WebSphere MQ) and plug
in your own logic to determine the user-id and issue
a
EXEC CICS START TRNID(ABCD)
USERID(xxxxxxxx)
Or alternatively
CKTI starts application ABCD by
default. In ABCD transaction issues another start for actual application
transaction with appropriate user-id similar to as shown
above.
My personal preference is for option-1. In option-2,
ABCD transaction has to pass the trigger message to the next transaction
and in the process it has all ready cleaned up the trigger message from
initiation queue. If for some reason, second transaction doesn't start or
fails half way through, then you would have lost one trigger
message.
Apart from that both are same.
Cheers
Rao
From: Heggie,
Peter [mailto:[EMAIL PROTECTED]
Sent: 4 March 2004
2:12 AM
To: [EMAIL PROTECTED]
Subject: Re: MQ
Triggering in CICS
Is there a way to
dynamically set the userid? As long as we are creating a SIL in CICS, is
there a way for the SIL to specify the userid when issuing the EXEC CICS
START ?
-----Original
Message-----
From:
MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Adiraju, Rao
Sent: Tuesday, March 02, 2004 3:11
PM
To:
[EMAIL PROTECTED]
Subject: Re: MQ Triggering in
CICS
Few more points
to add: (I was quick in pressing the send button):
As a design
principle the CICS program always should issue a EXEC CICS RETRIEVE
- 1) as Joe mentioned, to determine whether this transaction has
triggered by CKTI (or one of the equivalents) and secondly to retrieve the
trigger message. Trigger message gives you the information about which
queue has resulted the trigger, trigger data (that is defined on the base
queue), Process name, application data and user data that was put in the
PROCESS definitions etc.. Usually the program should determine the
queue that it is supposed to read from this trigger message (which is more
reliable) rather than hard-coding / soft-coding in the
program.
Also, most of the
times CKTI starts with a default user-id (or CICS userid) and hence your
transaction also runs under the same user-id. So watch out for
your security rules.
Cheers
Rao
From:
Adiraju, Rao
Sent: 3
March 2004 8:59 AM
To:
'MQSeries List'
Subject:
RE: MQ Triggering in CICS
John
Additional point
to what Joe mentioned - yes, the default you look for is "CKTI" in
Rtransid field. But check with your CICS guys as well - because it is
possible one CICS region to have multiple initiators and/or different
transaction codes (for various reasons).
If that's
case you need to check for those codes as well (or instead).
Cheers
Rao
Adiraju
WebSphere MQ
Specialist
The National Bank of NZ
Ltd.
Wellington - New
Zealand
Tel: +64-4-494
4299
Fax: +64-4-802
8509
Mbl:
+64-211-216-116
From:
DeBlassio, Joe [mailto:[EMAIL PROTECTED]
Sent: 3 March 2004 2:56
AM
To:
[EMAIL PROTECTED]
Subject: Re: MQ Triggering in
CICS
John,
Perform the following CICS RETRIEVE at the
beginning of your program and check the RTRANSID. If it contains the
value CKTI, then you know that the trigger monitor started your
program.
EXEC
CICS
RETRIEVE
SET (ADDRESS OF MQTM)
LENGTH
(LENGTH OF MQTM)
RTRANSID
(VARIABLE-RTRANSID)
RESP (VARIABLE-EIBRESP)
END-EXEC.
Make
sure you include copybook CMQTML in your linkage section.
And define the variables in
working storage.
Good
luck,
Joe
-----Original Message-----
From: Dawson, John [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 01,
2004 3:19 PM
To: [EMAIL PROTECTED]
Subject: MQ Triggering in
CICS
Folks,
In a
CICS program, how can I tell that the CICS program was started from
a
MQ
trigger?
Thanks,
John
Dawson
Instructions for managing your mailing list
subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
This communication is confidential and may contain
privileged material. If you are not the intended recipient you must
not use, disclose, copy or retain it. If you have received it in
error please immediately notify me by return email and delete the
emails.
Thank you.
This
e-mail and any files transmitted with it, are confidential to National
Grid and are intended solely for the use of the individual or entity to
whom they are addressed. If you have received this e-mail in error, please
reply to this message and let the sender know.
This
communication is confidential and may contain privileged material.
If you are not the intended recipient you must not use, disclose, copy or
retain it. If you have received it in error please immediately
notify me by return email and delete the emails.
Thank
you.
This communication is confidential and may contain
privileged material. If you are not the intended recipient you must
not use, disclose, copy or retain it. If you have received it in error
please immediately notify me by return email and delete the emails.
Thank
you.
This communication is confidential and may contain
privileged material. If you are not the intended recipient you must not
use, disclose, copy or retain it. If you have received it in error
please immediately notify me by return email and delete the emails.
Thank
you.
|
