| Author |
Message
|
| kamalesh_9988 |
 Posted: Thu Jan 18, 2007 4:47 am Post subject: Using MQ sereis with batch job |
 |
|
Newbie
Joined: 17 Jan 2007
Posts: 5
|
I used MQ Sereis with a batch JOB,in Z/OS (Mainframe Operating system).
Here teh JOB puts a input file of maximum record length 10,000 to a queue through MQPUT command by using a RPC program.
Now whenever the number of records in input file gets increased by 1159 then the JOB gets abbended with abbend code of S0C4.For that i put MQCMIT API call such that the MQPUT API call gets commited say after putting 500(or more) records.But still the job abbended after 1216 numbers of records, with same abbend code.
So their is any problem with the API(MQCMIT) call that i am using or this is the maximum capability of MQ series itself that it will load that amount of data only. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Jan 18, 2007 5:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
S0C4 is (casting my mind back more years than I like to think of) an application protection exception. It sounds to me like there's a buffer in your program that can't hold more that 1216 records. I'd have expected a range of different codes if MQ was having trouble. You don't say what version of MQ or what the queue max size or max depth is set to but each message can be 100Mb so I doubt you're hitting that. Unless you have the limits set ridiculously low.
Please post a bit more information about your set up if you want a more definative answer.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| KevinF23492 |
| Posted: Thu Jan 18, 2007 6:08 am Post subject: |
|
|
Novice
Joined: 26 Dec 2006
Posts: 22
|
This is undoubtably an application error. What language are you writting the code in? Did the link edit step work?
An S0C4 is a protection exception.....either you have, as Vitor says, overrun a program buffer, you have trampled all over your own code somehow, you have incorrectly called a another program, there is a DD card that you are trying to write to that isn't open.....take your pick...I am sure there are others too 
All I can really tell you is that I seriously doubt it is the commit. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 18, 2007 7:35 am Post subject: |
|
|
Guest
|
I couldn't resist this old mainframe riddle:
What's a S0c4? To keep your foot warm. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 18, 2007 7:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
I couldn't resist this old mainframe riddle:
What's a S0c4? To keep your foot warm. |
Now that's an old one.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kamalesh_9988 |
| Posted: Thu Jan 18, 2007 9:13 am Post subject: |
|
|
Newbie
Joined: 17 Jan 2007
Posts: 5
|
To get in depth of the problem, these are the relevent data so required:-
MQ version :- WEBSPHERE MQ FOR Z/OS V5.3.1
Programing Language :- COBOL II
Operating syatem :- Z/OS V1
Queue depth :- 10,000
and yes the link edit steps worked in the job i submitted.
I know the S0C4 is an application error, may be in this case it occurs because of some other factors.
Why?.Let me explain you the real scenario.
In the Job,firstly a fixed length(FB=84) input file is converted in to variable length file(VB),having maximum record length of 10,000. Then the MQ program is called up.
This program firslty connect to queue manager(MQCONN) then opens(MQOPEN) queue and then read the input file. Take the data from the input file and and then put(MQPUT) that data in Queue.
We go on putting the data till we reach to end of file.That is if all the records of file were put to Queue.
Now problem occurs when the number of records in that input file will increase from 1159. It abbends with S0C4 error. Then i introduce that commit (MQCMIT) concept in the program and now job abbends after 1216 number of records.
So this is what the actuall scenario.
And why i am saying that it is not a application error because the problem occurs just befors the MQPUT call for 1217th record of input file.
Hope i clarify maximum doubts that you all have.
Please help me if any one has any clue. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 18, 2007 9:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kamalesh_9988 wrote: |
| And why i am saying that it is not a application error because the problem occurs just befors the MQPUT call for 1217th record of input file. |
Ok, so you've got a record length of 84, albeit in a variable length record with a maximum of 10,000. You take each record & put it as a message, committing after a batch of 500 or so. The 1217th message gives you an S0C4.
I still say it's a bug in the code. I refer to this part of the z/OS Problem Determination Guide:
| Quote: |
Program abends can be caused by applications failing to check, and respond to,
reason codes from WebSphere MQ. For example, if a message has not actually been
received, using fields that would have been set up in the message for calculation
could cause X'0C4' or X'0C7' abends (ASRA abends in CICS).
|
Check your program is properly handling any reason codes from the MQ calls, ensuring that it captures the reason codes for analysis. From there, you should use standard problem determination to find the problem, as documented.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kamalesh_9988 |
| Posted: Thu Jan 18, 2007 10:58 am Post subject: |
|
|
Newbie
Joined: 17 Jan 2007
Posts: 5
|
I uses all the methods of proper error handling technique and even maintaning reason code thing.
I use MQM-REASON..with each API call and even check the COMPCODE after each API calls. Thats why i am saying that this is not the problem mentioned in the explanation provided by you
| Quote: |
Quote:
Program abends can be caused by applications failing to check, and respond to,
reason codes from WebSphere MQ. For example, if a message has not actually been
received, using fields that would have been set up in the message for calculation
could cause X'0C4' or X'0C7' abends (ASRA abends in CICS).
|
actually problem is with using that VB file with the MQ .
When i skip that step of changing FB input file to VB input file then program run succesfully. I even tested that program with input counts of 10,000(equals to depth of the key).Up to that limit also the program went fine. But when i implement the concept of VB input file then it is repetedly abbending. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 19, 2007 12:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kamalesh_9988 wrote: |
| But when i implement the concept of VB input file then it is repetedly abbending. |
So stick with FB records.... 
(MQ doesn't care)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kamalesh_9988 |
| Posted: Fri Jan 19, 2007 1:21 am Post subject: |
|
|
Newbie
Joined: 17 Jan 2007
Posts: 5
|
| Yes i am stick to that beacause after removing that it give me possitive results. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jan 19, 2007 10:51 am Post subject: |
|
|
Guest
|
S0c4's are usually storage overlays of one kind or another. It sounds like the buffer (work area in your cobol code) is being overlayed by the records you are are reading from the flat file; and/or you are using a pointer to point to the next record in the buffer AND the pointer+base of the workarea is outside the workarea.
From the abend dump, identify the offending instruction and what virtual addresses were being touched. Then find the cobol statement the blew up.
Less technical approach: turn on cobol trace, and/or imbed DISPLAYs just ahead of each cobol statement that works with your workarea. DISPLAY pointer value, your data records, and anything else that helps you identify what is happening.
Make the workarea in your program much, much bigger. This may accomodate the largest/larger physical block read from the device where the flat file lives. A block of records is the unit of transfer from disk (tape), and the buffer must be large enough to accomodate the entire block.
By the way, when your application gets a s0c4 or any other abend, the application terminates. This means that any instructions after the one that caused/encountered the s0c4 (like MQCMIT) will not be executed. |
|
| Back to top |
|
|
| kamalesh_9988 |
| Posted: Mon Jan 22, 2007 5:23 am Post subject: |
|
|
Newbie
Joined: 17 Jan 2007
Posts: 5
|
You are correct that the problem is with the buffer size of COBOL program
.I used the display and found out that the problem is not with the MQPUT.Just before the MQ PUT call of 1160th record(of flat file).
Could you please tell me that now how can i get the idea that how that program memory is full and at waht instance that memory will get full.
| Quote: |
| By the way, when your application gets a s0c4 or any other abend, the application terminates. This means that any instructions after the one that caused/encountered the s0c4 (like MQCMIT) will not be executed. |
i put commit counter as 400. So MQCMIT works after each 400 records. But just after 1159 it wont work. and as i mentioned above that the problem is not in a particular MQ call. So it wont matter much
but may be the problm is becasue of the way i am using MQCMIT.
Please suggest me the way by which i can use MQCMIT effiectivily such that it will work fine in this case. means it will cmmit the number of records as per the condition that we want. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 22, 2007 5:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kamalesh_9988 wrote: |
Could you please tell me that now how can i get the idea that how that program memory is full and at waht instance that memory will get full.
|
This is a straightforward COBOL tuning exercise & nothing to do with MQ. Your shop will probably have standards and/or tools to determine this.
Also a search through any z/OS forum will give you bags of help on memory management.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jan 22, 2007 7:25 am Post subject: |
|
|
Guest
|
Look at the physical blocksize of the dataset. You can do this with ISPF Primary Option Menu option 3.4 - the I (information) option for the dataset name of the flat file. The buffer in your application must be at least as large as the blocksize if RECFORM F or FB (fixed or fixed-blocked). If V or VB (variable or variable-blocked), the buffer must be at least as large as the largest blocksize possible.
If you are not an z/OS person, ask someone that is to assist you with this. |
|
| Back to top |
|
|
|
|
