I have a batch program (1) which calls another onlilne (2) program, which inturn calls another online(3) program. (All programs are COBOL+DB2).
When (1) calls (2), it passes unit of work timestamp value and current timestamp value. The two values are from the same field.
(2) inturn passes these timestamp values to (3). (3) is like the program inserts/updates DB2 tables.
Eg: In (1), I have code as follows
Code:
MOVE TS TO UOW-TS
MOVE TS TO CURR-TS
(3) has to check to see that the row it is updating has a current TS greater than the row's updated TS. But the check was failing, since current TS was having low-values in (3).
The dump shows UOW-TS value, but shows low-values for CURR-TS.
We had two batch jobs executing the same batch program
1. First job, when the job went down because of the above TS check, we did the following steps
- In the first JCL, we added the joblib for DB2.SDSNLOAD library and restarted at the step it abended, but the job failed again.
- Then we restarted the job from top and the job was successful
2. Second job, added the DB2.SDSNLOAD even before the job ran, but the job failed for the same TS check. (that is when we looked at the dump etc.,)
- Restart of the job at the step it abended did not help.
Next night, both jobs included DB2.SDSNLOAD library and both jobs ran fine without any issue (puzzling isn't it?)
I understand that the SDSNLOAD library is actualy required when running some kind of DB2 utility jobs, but somehow the inclusion has helped.
My questions:
1. When or why a linkage value can get corrupted? Could this be related to DB2 library included?
I am trying to find a meaning ful expalnation for this issue, unable to find so far. Also, not able to reproduce this in dev regions because of the way our shop is set up.
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
Quote:
I have a batch program (1) which calls another onlilne (2) program, which inturn calls another online(3) program. (All programs are COBOL+DB2).
When (1) calls (2), it passes unit of work timestamp value and current timestamp value. The two values are from the same field.
(2) inturn passes these timestamp values to (3).
1. How does the batch program call the online program?
2. Does the online program (2) call program (3) via EXEC CICS XCTL, EXEC CICS LINK, or COBOL CALL?
3. How do the programs (1) and (2) pass data?
4. Are the data areas the same size for the data passed between program (1) and (2)?
5. Are the data areas the same size for the data passed between program (2) and (3)?
6. What are the differences between the development region set up and the production region set up (e.g., transaction isolation, storage protection, and so forth)?
I'm sure more questions will be asked, but these are a way to start narrowing down where the problem is. And if the two timestamps are separate variables, your statement that they are from the same field is not only completely useless, it may actively mislead people into thinking the problem is related to the single field instead of the separate variables.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
You can save yourself parm-passing of the Timestamp by using EXTERNAL storage, defined exactly the same way in the WS of all COBOL programs in the call chain. In other words, once the TS is populated into EXTERNAL storage by the highest COBOL caller, it then becomes automatically addressable in all subsequent COBOL programs which you are currently accessing.
1. How does the batch program call the online program?
2. Does the online program (2) call program (3) via EXEC CICS XCTL, EXEC CICS LINK, or COBOL CALL?
3. How do the programs (1) and (2) pass data?
4. Are the data areas the same size for the data passed between program (1) and (2)?
5. Are the data areas the same size for the data passed between program (2) and (3)?
6. What are the differences between the development region set up and the production region set up (e.g., transaction isolation, storage protection, and so forth)?
1. It is a COBOL call
2. No CICS is involved here, all calls are a COBOL Call
3. Using the COBOL all, as follows
CALL WS-PGM2 USING TS-AREA
ERROR-AREA
DATA-AREA
4. Yes, the same copybook for TS-AREA and ERROR-AREA
5. Development always has a include member, which has all the load libraries and DB2 libraries listed in the include member. In prod we do not have any explicit include members, but in this job we included the joblib for the SDSNLOAD library explicitly.
Quote:
I'm sure more questions will be asked, but these are a way to start narrowing down where the problem is. And if the two timestamps are separate variables, your statement that they are from the same field is not only completely useless, it may actively mislead people into thinking the problem is related to the single field instead of the separate variables.
It is correct that the two timestamps are separate variables, however the value comes from the same field. That is what I meant here.
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
Is your online system CICS or something else?
And you will need to get your site support group involved, so they can research the differences between your production and development online environments.
I may need to clarify that by online, I meant COBOL+DB2 modules that can be called from java directly. They are not exactly stored procedures, but our shop has a special structural design to call these COBOL+DB2 modules.
Online in my case is not CICS. If the online term is misleading, may be I should state in more simpler terms, that my issue is with batch program calling other COBOL +DB2 programs.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
You're going to need to show some code.
All the relevant CALL statements. All the relevant LINKAGE SECTION definitions and PROCEDURE DIVISION USING. All of these from the compile listings (so any "pre-processor" data is included). All references to the two fields you have mentioned, either individually or at a group level.
Was this "working" before, or is it "new"? If working before, what has changed in any of the programs. Remember you may be facing a combination of data which is revealing a problem which has always existed, but not come to light before. This may explain the "sometimes it works". When you restarted the job from the top, was all data returned to its original state, or was something already partially updated?
Joined: 29 Oct 2010 Posts: 202 Location: Toronto, ON, Canada
First question: Is your compile jcl using the DB2 precompiler before it calls the COBOL compiler? HINT: If you see a step PGM=DSNHPC then the answer is yes
Second question: in your subroutine are you using the linkage section variables in your SQL?
If the answer to both questions is yes then you need to change the subroutines to use working-storage variables for the sql. Move the linkage section variable to working-storage variable before the EXEC SQL call.
The reason has to do with the way the precompiler handles the variables and sets a static addresss. If you are using the integrated compiler then this is no longer a problem.
The current Enterprise COBOL compiler allows for the use of an integrated DB2 compiler which does the DB2 and COBOL compilation in one step. Much easier.
