View previous topic :: View next topic |
Author |
Message |
offshore Beginner
Joined: 11 Dec 2003 Posts: 8 Topics: 6
|
Posted: Fri Oct 22, 2004 12:09 pm Post subject: TDQ Internal Reader |
|
|
All,
[Is there way to tell what program/trans is using a specifc TDQ?]
I'm trying to determing if an application is using IEFR, which is define as our TDQ to communicate JES.
So far I've run a few SMF reports and SAS reports, but (if I'm reading it correctly) only says it write something out to TDQ.
I prefer it show me what TDQ the PGM wrote out to.
Thanks, |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12376 Topics: 75 Location: San Jose
|
Posted: Sun Oct 24, 2004 4:52 pm Post subject: |
|
|
offshore,
Can't you just look in the program for the TDQ name which is writting to the TDQ? Alternatively you can also write out the program name/queue name to the TDQ from the program itself
Hope this helps...
Cheers
Kolusu _________________ Kolusu
www.linkedin.com/in/kolusu |
|
Back to top |
|
|
gkb1278 Beginner
Joined: 15 Oct 2004 Posts: 8 Topics: 3 Location: Fort Worth, Texas
|
Posted: Mon Oct 25, 2004 2:46 pm Post subject: |
|
|
Don't of anything that will tell you what program is using what que as the queue name is a variable within any program. _________________ gkb1278 |
|
Back to top |
|
|
Mike Chantrey Intermediate
Joined: 10 Sep 2003 Posts: 234 Topics: 1 Location: Wansford
|
Posted: Tue Oct 26, 2004 5:54 am Post subject: |
|
|
The only obvious way I can think of to do this is to write a CICS GLUE (Global user exit).
E.G. Use exit point XTDOUT, enabling the exit with a suitably sized GWA (global work area). In the exit, first check if the TDQ being written to is the relevant one (UEPTDQUE, the address of the TDQ name, is one of the exit parameters). Then use the XPI (exit programming interface) call INQ_APPLICATION_DATA to obtain the EIB address. Map the EIB with the DFHEIBLK copy code. The EIB field EIBTRNID gives the transaction id.
Log all unique tranids in the GWA, being careful not to write past the end of this area.
You could also use exit point XTDEREQ, this exit is more flexible since it allows EXEC CICS commands (XTDOUT doesn't) but it is more complex - you have to check the 'request type' for example.
Writing GLUEs is a specialist task usually done by your CICS sysprogs so I hope you have a good relationship with them if you want to follow this path. A pint or two of their preferred beverage might help |
|
Back to top |
|
|
Mike Chantrey Intermediate
Joined: 10 Sep 2003 Posts: 234 Topics: 1 Location: Wansford
|
Posted: Tue Oct 26, 2004 5:58 am Post subject: |
|
|
Forgot to mention - the GLUEs and the XPI are documented in the 'CICS Customization Guide', available via this board's manual links. It's important to refer to the correct version of this manual for your release of CICS as the GLUEs can and do change between CICS releases. |
|
Back to top |
|
|
offshore Beginner
Joined: 11 Dec 2003 Posts: 8 Topics: 6
|
Posted: Wed Oct 27, 2004 7:46 am Post subject: |
|
|
Mike,
Thanks I'll check into GLUE's, fortunately (or unfortunately)I am the CICS sysprog so I'll have to write it myself. I've only been doing this for a couple years and haven't written many things.
kolosu, i could look thru the program, but when there are literally 1000s of programs and that could take for ever and a day. The applications folks are telling us that they're going to have to change a bunch of programs because they write to the internal reader TDQ.
When I ran SMF reports I see that the TDQ for the internal reader has been written to (along with several other TDQ's), but that only a few programs are have stats that they're actually writing to a TDQ, but not which one specifically.
Thanks everyone.
Offshore |
|
Back to top |
|
|
Mike Chantrey Intermediate
Joined: 10 Sep 2003 Posts: 234 Topics: 1 Location: Wansford
|
Posted: Wed Oct 27, 2004 11:16 am Post subject: |
|
|
Quote: |
Thanks I'll check into GLUE's, fortunately (or unfortunately)I am the CICS sysprog so I'll have to write it myself. I've only been doing this for a couple years and haven't written many things.
|
Well, you can buy yourself a few drinks if you do this sucessfully.
If you haven't written any GLUEs before:
Always start with a working IBM sample (even if it's for another exit point) rather than start from scratch.
Be very careful about your register use. The XPI affects register use.
Read the sections of the Customization guide about writing GLUEs and using the XPI repeatedly and carefully.
Test, test and test again - your GLUE can and will easily crash the CICS region if it screws up.
Debugging is a pain since (as far as I know) there are no debugging tools that can step through GLUEs. I've used two methods for exits which don't support the EXEC CICS API:
a/ Write values to a known 'safe' area of memory - e.g. an unused section of CWA. You can hardcode the CWA address into the exit debugging code for a given CICS run.
b/ Put in invalid instruction values using DC etc. at strategic points - this will typically crash the CICS region with a system dump so you can inspect registers etc. at the time of the crash.
Also, you might want to extract the code fragment for searching/updating the table of tranids and test this as a non-exit program before plugging it into the exit. |
|
Back to top |
|
|
|
|