Hi Listers:
I'll tell 'ya, I get some real beauts.
We have a batch cobol program that runs in our dev and test environment
fine. In production it gets a S0C4 sometimes.
Other times it runs. When we insert the dev loadlib in front of the
production loadlib we run it again and it works!!!
When I migrate this program from dev to test the cobol compiler step
always returns 00. When I migrate it to production
the cobol compiler step always returns an 04.
The difference in the production cobol compile is this message but it is
only a warning:
8022 IGYOP3091-W Code from ""procedure name 4162-STRIP-PO-PT"" to ""EXIT
(line 8049.01)"" can never be executed and was therefore discarded.
The only difference between production with dev and test environments is
that I have a zap trap in rhdccsa from level2. but L2 has assured me
this has no affect as far as the batch job goes. That makes sense being
the S0C4 is in the batch region. This batch job is a local mode
retrieval job.
Does anyone have any clues or suggestions? Is a compiler option causing
this? Is it a cobol system parameter? Anything else?
We are 15.0 sp5.
TIA
J. Wayne Doneker
BAE Systems
York Pa.,
717 225 8109
John.Doneker@baesystems.com
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Re: S0C4 batch cobol IDMS
"SSRANGE is a compile option used to check subscript and index ranges for
internal tables. Here is some information from a manual I found on
Google.
SSRANGE
SSRANGE option syntax
.-NOSSRANGE-.
-----------------------------------------------------------><
'-SSRANGE---'
Default is: NOSSRANGE
Abbreviations are: SSR|NOSSR
Use SSRANGE to generate code that checks if subscripts (including ALL
subscripts) or indexes try to reference an area outside the region of
the table. Each subscript or index is not individually checked for
validity; rather, the effective address is checked to ensure that it
does not cause a reference outside the region of the table.
Variable-length items will also be checked to ensure that the reference
is within their maximum defined length.
Reference modification expressions will be checked to ensure that:
The reference modification starting position is greater than or equal to
1.
The reference modification starting position is not greater than the
current length of the subject data item.
The reference modification length value (if specified) is greater than
or equal to 1.
The reference modification starting position and length value (if
specified) do not reference an area beyond the end of the subject data
item.
If SSRANGE is in effect at compile time, the range-checking code is
generated. You can inhibit range checking by specifying CHECK(OFF) as a
run-time option. This leaves range-checking code dormant in the object
code. Optionally, the range-checking code can be used to aid in
resolving any unexpected errors without recompilation.
If an out-of-range condition is detected, an error message is displayed
and the program is terminated.
Remember: You will get range checking only if you compile your program
with the SSRANGE option and run it with the CHECK(ON) run-time option.
I am assuming that the program you are running has internal tables and
that is where your problem is coming from. Since it works some times in
production and not others it is probably related to the data.
Kirk out.