|
View previous topic :: View next topic
|
| Author |
Message |
Crunch
New User
Joined: 27 Jan 2010
Posts: 17
Location: Louisville, Ky
|
|
|
|
| We have a program that is performing an IMS message switch with another program. I'm getting some weird test results when Xpediting the program. When executing the program outside of Xpediter, the program does not pass the correct data to the program being called. However, when the program is re-compiled in Xpediter the program works as it should. The correct data gets passed to the called program. Has anyone else had this issue? Thanks in advance!! |
|
| Back to top |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Sounds like a bug in your code which is masked when you recompile it for Xpediter, most likely storage being overwritten.
Compile with SSRANGE. Check order, number, and lengths of parameters from CALL to PROCEDURE DIVISION. |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
|
|
| How does it execute in production then? if it is a new program then you have to explain what is "Correct data" means, is it truncated? check the copybook , it may happen you are picking up wrong one out side expd. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
SSRANGE must be used together with the LE option CHECK being set to Y. You should NEVER use CHECK in Production....  |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
CHECK=YES is (usually) the installed default.
You can use SSRANGE and CHECK=NO in Production (until you get to Enterprise COBOL V5) but there is an overhead (less than doing the CHECK=YES, but still an overhead).
For V5, CHECK in Language Environment is redundant. You either compile with SSRANGE or NOSSRANGE. You can't compile with SSRANGE and decide not to use it at run-time. |
|
| Back to top |
|
|
Crunch
New User
Joined: 27 Jan 2010
Posts: 17
Location: Louisville, Ky
|
|
|
|
Solved. Somehow the module was compiled to the wrong LOADLIB, which happened to be the first library in the concatenation. We removed that load module from the first LOADLIB which corrected the problem. The correctly compiled version of the program used the 4th library in the concatenation.
I appreciate the input. Thanks!! |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
It's always a waste of time when you execute the wrong version of a program. So, make sure you know for next time:
| Code: |
01 W-WHEN-COMPILED PIC X(8)BX(8).
...
MOVE WHEN-COMPILED TO W-WHEN-COMPILED
DISPLAY "prognm " W-WHEN-COMPILED |
You do that "first time" in a program (store it somewhere in CICS instead of the DISPLAY, or route it to a log).
When the program fails or when looking into something, find the date/time of the actual program. Saved loads of time over the years. |
|
| Back to top |
|
|
|
|
