Date: Thu, 2 Sep 2010 11:32:07 -0400
Reply-To: CICS List <CICS-L@LISTSERV.UGA.EDU>
Sender: CICS List <CICS-L@LISTSERV.UGA.EDU>
From: Jim Mooney <jmooney@PRINCESSCRUISES.COM>
Subject: CSMI - a fact of life? was Re: CICS Monitors?
Rob, Thanks for this thought-provoking post. It took a couple days
to 'sink in'. I don't know if passing the TRANID on the EC LINK has been
attempted here by the apps group, but I will find out. To be honest, I
didn't know that was possible. And I can see there may be some benefit.
Also, it never occurred to me until your post, to define multiple tranids
for DFHMIRS. I always thought that background tasks running as CSMI were
just a fact of life. So, thanks again for sharing.
As for the AOR-AOR DPL, this application is entirely VSAM. I am told the
design intent was to split browse activity from update activity, so we
don't have the flexibility to 'run everything locally', without a complete
re-design, that is.
-Jim
On Mon, 30 Aug 2010 10:36:09 EDT, Robert Zenuk <Robzenuk@AOL.COM> wrote:
>How do you define your transactions and programs in the source and target
>regions that are involved in DPL's? Are you using static links? If so,
do
>you define each transaction in the candidate target region with
>PROGRAM(DFHMIRS)? While there is always a mirror involved, with
correct definitions
>the mirror in the AOR will show up with the correct tranid. We use
>dynamic routing with CPSM's EYU9XLOP and we have the applications (our
Web
>Services Pipeline Handler transaction) move EIDTRNID into the TRANSID
parm of the
>EC LINK otherwise you continue to get the CSMI... Why this wasn't the
>default has always baffled me. However, depending on where you start the
>whole chain you might be able to code the trandef in both the TOR and
AOR with
>PROGRAM(DFHMIRS) then get the tranid in both the TOR and the AOR. We had
>an older application that used to do a START from a CICS/6000 environment
>into a TOR and simply pass through (using CPSM WLM) to an AOR. I
reviewed
>the old CICS/6000 code and did not see any EC LINK's with a TRANSID. It
>always seemed like magic to me...
>
>We haven't used function shipping for over a decade, so I don't remember
if
> this had any effect in our QOR's (pre Temp Storage Server).
>
>Personally, I hate CSMI transactions. Not the functionality, just the
>lack of visibility to the actual work. So, I actually have CPSM
monitoring
>functions watch for CSMI's and review each for correct definitions.
When I
>find something is missing, it is added at the earliest convenience. Many
>times is simply points out an obsolete reason for the condition. We are
all
>DB2 and Datacom for our stuff but do have some small VSAM vendor
>applications. We removed all remote files by using local definition for
all
>read-only VSAM (mostly CODE1). We do not have any update VSAM, but
would use RLS
>for those if we did (we thought we did at one point, but further
>investigation with the application proved it was not necessary). Almost
all of our
>other reasons for Function Shipping CSMI's have evaporated over time by
>exploiting other Sysplex compliant approaches.
>
>While this does not resolve the issue of knowing exactly which task is
part
> of an MRO UOW for a problem, it at least makes security, auditing,
>performance analysis, tuning, and capacity planning easier...
>
>A final comment is AOR to AOR DPL's. If all target regions involved in
>DPL's are all on the same set of shared DASD, why even allow a DPL. Add
the
>LOADLIB to the DFHRPL of all participating AOR's and run it local
(assuming
>no non-RLS VSAM update requirements).
>
>Rob
>
>
>
>
>In a message dated 8/26/2010 11:04:20 A.M. US Mountain Standard Time,
>jmooney@PRINCESSCRUISES.COM writes:
>
>We have all those types of CSMIs - link, DPL and FS. And we are a single
>sysplex. But most of this MRO happens on a single mvs image, though a
>limited amount occurs between 2 lpars. Another thought....concerning
your
>size, I cannot comment on the overhead of searching across 200 regions,
or
>even 100. Here, we never have to search more than... say... 40.
>
>-Jim
>
>On Thu, 26 Aug 2010 12:33:42 EDT, Robert Zenuk <Robzenuk@AOL.COM> wrote:
>
>>2 Quick follow-up questions... Are your CSMI's from EC LINK DPL's or
>>Function Shipping requests (like an FOR or QOR)? Is this in a single
>Sysplex
>>(or monoplex) with shared DASD?
>>
>>Rob
>>
>>
>>
>>In a message dated 8/26/2010 9:27:32 A.M. US Mountain Standard Time,
>>jmooney@PRINCESSCRUISES.COM writes:
>>
>>I thought about this a little more. Maybe this is obvious, but I will
>>spell it out. We are MRO. Our primary use of this is to get the
original
>>tranid.
>>
>>Given a tranid, RDBH, in a TOR, it's hypothetical UOW includes 7 CSMI
>>tasks:
>>
>>TOR1 -> AOR1 - AOR2 - AOR3 - AOR4
>>RDBH CSMI CSMI CSMI CSMI
>>CSMI CSMI
>>CSMI
>>
>>If we get alerts from AOR4, we look there first. Of course everything
>>running there is a CSMI. But by searching across all region's task
>>history, we quickly find that the 'sore thumb' is part of the UOW for
>>RDBH. We also learn:
>>
>>- AOR3 was used 3 times by the UOW (sometimes we are suprised by this).
>>- The time stamps show us the exact sequence; how each piece flows to
the
>>next (often more surprises).
>>
>>- We now have a complete scope of the problem for tuning/debugging
>>opportunities.
>>
>>Before, we would often work 'in a vacuum', focusing only on AOR4,
>>mistakenly attempting region-specific remedies, when the 'problem' was
>>outside the region.
>>
>>-Jim
>>
>>
>>On Wed, 25 Aug 2010 11:44:29 +0100, Dave Key <dave_key@UK.IBM.COM>
>wrote:
>>
>>>Hi Jim,
>>>
>>>I noticed your reference to using monitoring to track a UOW across
>TORs &
>>>AORs and I wondered if you, and/or anyone else on the list, would be
>>>prepared to detail the particular reasons for doing this. For example
is
>>>it for an operator to diagnose a particular problem, or an application
>>>developer to debug an application flow in test etc. etc. ?
>>>
>>>I'm asking because, whilst I have my own personal reasons for
tracking
>>>applications and my own views on why applications are tracked, my
role,
>as
>>>one of the System Testers of CICS TS, is to ensure that what we do we
is
>>>genuinely reflecting both the actual requirements and, possibly more
>>>importantly, the purpose behind those requirements as accurately as
>>>possible.
>>>
>>>So any information that you feel comfortable sharing, whether via the
>list
>>>or privately, on what you do and why you do it would be fantastic.
>Also,
>>>any information on what you would like to be able to do would be
useful
>>>too.
>>>
>>>Any, and all, of this helps me build a better picture of usage and
that
>>>really does help us "build a better mouse-trap" :-)
>>>
>>>Thanks in advance,
>>>
>>>Cheers
>>>Dave Key
>>>
>>>CICS TS System Test
>>>IBM Hursley Park
>>>
>>>
>>>
>>>Jim Mooney <jmooney@PRINCESSCRUISES.COM>
>>>Sent by: CICS List <CICS-L@LISTSERV.UGA.EDU>
>>>24/08/2010 19:55
>>>Please respond to
>>>CICS List <CICS-L@LISTSERV.UGA.EDU>
>>>
>>>
>>>To
>>>CICS-L@LISTSERV.UGA.EDU
>>>cc
>>>
>>>Subject
>>>Re: CICS Monitors?
>>>
>>>
>>>
>>>
>>>
>>>
>>>We converted from Omegamon to Mainview about 4 years ago. At that
>time,
>>>one of the significant differences was Mainview's ability to
search/view
>>>task history data across multiple regions simultaneously. We found
this
>>>useful when tracking a UOW across TOR-AOR regions. This was not
possible
>>>in Omegamon at the time. -Jim
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>Unless stated otherwise above:
>>>IBM United Kingdom Limited - Registered in England and Wales with
>number
>>>741598.
>>>Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6
>>3AU
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
| 
