| Author |
Message
|
| TJB |
 Posted: Tue Oct 18, 2005 12:01 am Post subject: Processing MQxxMSTR/CHIN job output via a C program. |
 |
|
Newbie
Joined: 26 May 2005
Posts: 4
|
Hi folks,
This is a little off topic, but I was wondering if it's possible to directly view and process MQxxMSTR/CHIN SDSF output via a C program...? If all else fails I had planned on just dumping the job output via batch to a sequential file and then processing it, but I'm sure there has to be a lot better and cleaner ways of doing it.
I couldn't find anything on my Google travels, but if anyone has any clues it'd be much appreciated. |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Tue Oct 18, 2005 5:20 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
The answer is obviously 'Yes' otherwise how would SDSF manage it 
Having said that it is not easy. You have to work your way down JES2 control blocks and stuff like that.
Will 'OUTLIST' give you what you need? (TSO Option 3.7)
What are you trying to achieve? (or rather what is the C programming looking for?) |
|
| Back to top |
|
|
| javagate |
| Posted: Tue Oct 18, 2005 6:18 am Post subject: |
|
|
Disciple
Joined: 15 Nov 2004
Posts: 159
|
What exactly is it that you want to process? Are you just wanting the joblog (jesmsglg, jesjcl,jesysmsg,csqoutx,csqout1,csqout2) in a seq file? If you just want the listings in a seq file try
print odsn 'hlq.xxxxxx' * new
print
print close
Otherwise what do you think you are going to process? Kindly explain.
_________________
WebSphere Application Server 7.0 z/OS &
MQ 6.0. I work with WebSphere in the real world not in some IBM lab. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Tue Oct 18, 2005 6:31 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
it even works in batch like this:
| Code: |
//SDSF EXEC PGM=SDSF
//ISFOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//MYPRT DD DSN=MQSERIES.SDSF.OUTPUT5(+1),
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,
// SPACE=(CYL,(4,4),RLSE),
// DCB=(RECFM=FB,LRECL=132,BLKSIZE=13200)
//ISFIN DD *
PREFIX CSQXCHIN
DA
FIND CSQXCHIN
++?
FIND JESMSGLG
++S
PRINT FILE MYPRT
PRINT
PRINT CLOSE
/* |
Second Step could then be the C Program to analyze the output.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| TJB |
| Posted: Tue Oct 18, 2005 3:38 pm Post subject: |
|
|
Newbie
Joined: 26 May 2005
Posts: 4
|
Sorry all, I should have explained it a little better. What we’re planning on doing at the moment is quite simple; we’re just interrogating the CHIN logs to get some reasonable DISCINT values for our channels. It needs to be done across a lot of Chl's/QMgr’s, which is why I wasn’t real keen on manually doing it.
Thanks for all the suggestions though. The JCL Mr Butcher kindly posted is similar to what I’m currently doing, but I was interested to know if it was possible to read the SDSF output directly from a C program. Not dumping it out first.
But.... if I need to delve down into the control blocks etc, it sounds like I may have better things to spend my time on though... 
It’s not a big issue for what I’m currently doing, but I guess I was just curious… |
|
| Back to top |
|
|
| wschutz |
| Posted: Tue Oct 18, 2005 4:18 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| What we’re planning on doing at the moment is quite simple; we’re just interrogating the CHIN logs to get some reasonable DISCINT values for our channels. It needs to be done across a lot of Chl's/QMgr’s |
So why not just use channel start / stopped event messages to do this? (See the Monitoring MQ manual)
_________________
-wayne |
|
| Back to top |
|
|
| TJB |
| Posted: Tue Oct 18, 2005 4:31 pm Post subject: |
|
|
Newbie
Joined: 26 May 2005
Posts: 4
|
ah, the simple answers are always the best! I must admit that never even crossed my mind... 
Thanks Wayne... that's the way to go. |
|
| Back to top |
|
|
| javagate |
| Posted: Wed Oct 19, 2005 4:27 am Post subject: |
|
|
Disciple
Joined: 15 Nov 2004
Posts: 159
|
Look like you are going about this in a round about way. Have you looked at the SMF MQSeries records? Support pac MP1B has some good samples. What do you hope to do with the DISCINT values?
_________________
WebSphere Application Server 7.0 z/OS &
MQ 6.0. I work with WebSphere in the real world not in some IBM lab. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Wed Oct 19, 2005 5:30 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
What do you hope to do with the DISCINT values?
|
Just a guess but I suspect he is wanting to make sure that the disconnect interval is set such that trigger doesn't pop the channel too soon after a disconnect interval disconnect.
If I have a disconnect interval set to 10 minutes and a minute after that a message triggers the channel again (and this happens frequently) then I could tweak the disconnect interval to 15 minutes and save the extra processing need when triggering occurs.
At least that is the only reason I can think of . |
|
| Back to top |
|
|
| TJB |
| Posted: Wed Oct 19, 2005 2:49 pm Post subject: |
|
|
Newbie
Joined: 26 May 2005
Posts: 4
|
| kevinf2349 wrote: |
| Just a guess but I suspect he is wanting to make sure that the disconnect interval is set such that trigger doesn't pop the channel too soon after a disconnect interval disconnect. |
Yes, that's the reason for it. I don't think it's been looked at for years - there are huge amounts frequent starts/stops evident in the CHIN logs. Just trying to tidy things up a bit.
Thanks all for the ideas/suggestions... |
|
| Back to top |
|
|
| javagate |
| Posted: Thu Oct 20, 2005 3:47 am Post subject: |
|
|
Disciple
Joined: 15 Nov 2004
Posts: 159
|
Just a word of note on z/OS there are large amounts of CPU overhead associated with the starting and stopping of channels such as SVRCONN
etc.... The overhead comes in with the tons of console messages that are displayed. Suppressing the console message does not save any CPU time (per IBM). At my shop some of the .Net apps had a lot of PC users aps starting and stopping the client channels and that had a major impact on CPU time ( we are talking millions here) . However the flip side when the channels stay active you tend to use a lot of storage and the qmgr/chin has to spend time chaining through the control blocks. Between a .Net app and an IVR we might have up to 800 SVRCONNs open in 1 qmgr. Leaving them open saved on cpu time.
Peace
_________________
WebSphere Application Server 7.0 z/OS &
MQ 6.0. I work with WebSphere in the real world not in some IBM lab. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 20, 2005 3:59 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
And a couple of distributed QMs on relatively cheap hardware might have been less expensive than the combination of the CAF and the time it took you to manage the CPU usage and the CPU usage itself... 
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| javagate |
| Posted: Thu Oct 20, 2005 4:14 am Post subject: |
|
|
Disciple
Joined: 15 Nov 2004
Posts: 159
|
We are a large mainframe shop . There are other issues involved such as licensing costs and then the cost of salaries + benefits for the staff to maintain the distributed environments  . Also not previously stated the .Net applications are accessing legacy data on the mainframe and require CICS and DB2. The new .Net application voided the unix queue-managers . The application is less complex now. Not my decision this is what the applications departments decided before moving the apps to our data center. Managing the cpu time and diagnosing the problem is all in a days work... Go Mainframe!
_________________
WebSphere Application Server 7.0 z/OS &
MQ 6.0. I work with WebSphere in the real world not in some IBM lab. |
|
| Back to top |
|
|
|
|
