My online program YY991 is failing with the below message in CICS logs:
Code:
IGZ0040S An invalid separate sign was detected in program YY991 on line 7587.
CEE3DMP V1 R13.0: CEEWUCHA-> UNHANDLED CONDITION.
Task Number: 5045 Transaction ID: Y001
CEE3250C The system or user abend 1040 was issued.
From compile unit CEEWUCHA at entry point CEEWUCHA at compile unit offs
29474DEC.
Compile listing of my program:
Line 7587 has SET NULL FIELDS IF Condition:
Code:
7585 ,IF VJY-CAA-DRY-DT-TM-N < ZERO
7586 INITIALIZE VJY-CAA-DRY-DT-TM
7587 END-IF.
Please advise what could be the reason for failure.
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
A Google search on igz0040s turns up this as the first hit:
Quote:
IGZ0040S
An invalid separate sign was detected in program program-name on line line-number.
Explanation
An operation was attempted on data defined with a separate sign. The value in the sign position was not a plus (+) or a minus (-).
You need to figure out why the invalid sign occurred and fix the problem. You didn't say if the error occurred in production or test, nor if the program is being modified.
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
The field you THINK is in error is NOT in error. There are one (or more) variables coded in that program with SIGN LEADING (or TRAILING) SEPARATE. One of those variables does not have a valid + or - in the sign field. The PIC S9(4) COMP variable has NOTHING to do with the problem -- a COMP variable cannot have a separate sign (only DISPLAY or NATIONAL variables are allowed to have separate signs in COBOL).
The error message is pretty descriptive, and the manual I quoted earlier is also descriptive. The reason for the failure is that there is at least one variable with a separate sign in your COBOL program, and that sign does not have a plus or minus value in it when the variable is used.
If it is an elementary value, moving LOW-VALUES to the group would cause this issue. A table overflow could cause this issue. There are other possible reasons. Your responsibility is to identify the particular variable and then find what is causing the issue and fix it.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Robert is correct. Your fist clue was that the line-number points to an END-IF statement, which is obviously nothing to do with SEPARATE SIGN in any way at all.
The implication of that is that you are not looking at the compile listing of the code that is running. You need to find out why, separately. Looking for use of SEPARATE SIGN sign may help, but remember, if the listing you are looking at is wrong, and that comes from the current source, then the current source is wrong, and may not contain the code, if you're really unlucky.
So, find out why you are not looking at the compile listing of the code which is executing.
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
Quote:
Your error is directly connected to the fields definition.
Marso: this is incorrect. Many -- maybe most -- sites do NOT retain the compile listing when a program goes into production. The compile listing the TS posted from is OBVIOUSLY not the compile listing for the production version of the program -- because END-IF cannot, under any circumstances, generate the IGZ0040S error. Hence referring to the variables in the IF / INITIALIZE statement is referring to variables that may (but most likely are not) related to the error. Looking at their definition will NOT help resolve this problem. The error statement is most likely an arithmetic statement (ADD, SUBTRACT, MULTIPLY, DIVIDE, COMPUTE) or possibly a MOVE statement. We know this because the SIGN SEPARARE error message is only invoked when the variable is being used -- the manual I quoted stated this ("operation was attempted"). Furthermore, the field definition is not the problem -- the problem is that the variable has a SIGN SEPARATE clause and that byte of memory does not have a + or - in it.
kishpra, you have asked twice the reason for the failure and you have been told multiple times that the computer is not lying to you -- the problem is a SIGN SEPARATE variable that does not have a valid sign. Since your compile listing is not related to the production program, you need to find other ways to debug the issue. I recommend using a CICS trace (or CEDF) to follow the CICS API calls -- this will at least let you get close to the specific part of the program with the error.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
With these definitions:
Code:
10 SS PIC S9(8) SIGN LEADING SEPARATE.
01 USS PIC 9(8).
01 SSS PIC S9(8).
(the 10-level is just so I can clobber the leading sign)
And this code:
Code:
MOVE SS TO SSS
MOVE SS TO USS
IF SS GREATER THAN ZERO
CONTINUE
END-IF
Here is the generated code:
Code:
000024 MOVE
000384 F247 D0F8 8079 PACK 248(5,13),121(8,8) TS2=0
00038A 954E 8078 CLI 120(8),X'4E' SS
00038E 4770 B05E BC 7,94(0,11) GN=12(00039E)
000392 94F0 D0FC NI 252(13),X'F0' TS2=4
000396 960C D0FC OI 252(13),X'0C' TS2=4
00039A 47F0 B07C BC 15,124(0,11) GN=13(0003BC)
00039E GN=12 EQU *
00039E 9560 8078 CLI 120(8),X'60' SS
0003A2 4770 B072 BC 7,114(0,11) GN=14(0003B2)
0003A6 94F0 D0FC NI 252(13),X'F0' TS2=4
0003AA 960D D0FC OI 252(13),X'0D' TS2=4
0003AE 47F0 B07C BC 15,124(0,11) GN=15(0003BC)
0003B2 GN=14 EQU *
0003B2 58F0 20F4 L 15,244(0,2) V(IGZCMSG )
0003B6 4110 A15F LA 1,351(0,10) PGMLIT AT +343
0003BA 0DEF BASR 14,15
0003BC GN=15 EQU *
0003BC GN=13 EQU *
0003BC F374 8090 D0F8 UNPK 144(8,8),248(5,13) SSS
000025 MOVE
0003C2 D207 8088 8079 MVC 136(8,8),121(8) USS
000026 IF
0003C8 F247 D0F8 8079 PACK 248(5,13),121(8,8) TS2=0
0003CE 954E 8078 CLI 120(8),X'4E' SS
0003D2 4770 B0A2 BC 7,162(0,11) GN=16(0003E2)
0003D6 94F0 D0FC NI 252(13),X'F0' TS2=4
0003DA 960C D0FC OI 252(13),X'0C' TS2=4
0003DE 47F0 B0C0 BC 15,192(0,11) GN=17(000400)
0003E2 GN=16 EQU *
0003E2 9560 8078 CLI 120(8),X'60' SS
0003E6 4770 B0B6 BC 7,182(0,11) GN=18(0003F6)
0003EA 94F0 D0FC NI 252(13),X'F0' TS2=4
0003EE 960D D0FC OI 252(13),X'0D' TS2=4
0003F2 47F0 B0C0 BC 15,192(0,11) GN=19(000400)
0003F6 GN=18 EQU *
0003F6 58F0 20F4 L 15,244(0,2) V(IGZCMSG )
0003FA 4110 A143 LA 1,323(0,10) PGMLIT AT +315
0003FE 0DEF BASR 14,15
000400 GN=19 EQU *
000400 GN=17 EQU *
000400 F940 D0F8 C00D CP 248(5,13),13(1,12) TS2=0
000406 47D0 B0CA BC 13,202(0,11) GN=5(00040A)
That's correct. 15 statements for the first MOVE. One for the second. 16 for the IF. (Note, not all will be executed every time, but obviously more statements will be executed than one MVC).
For an equivalent MOVE for a source field without SIGN, you'd of course expect one instruction also.
DISPLAY will happily accept an invalid sign for a field defined with SIGN. IF will die. MOVE may die, depending on whether the target field is signed or not.
Unless you are sending data to an external source, why are you using SIGN [SEPARATE]?
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Show the levels above DYCOM-SQL-SQLCODE, any REDEFINES of it, and every reference in the PROCEDURE DIVISION to DYCOM-SQL-SQLCODE, any references to any group-items that DYCOM-SQL-SQLCODE belongs to and any references to any REDEFINES of DYCOM-SQL-SQLCODE.
Why is it defined like that anyway? Does it go to an external source (like a web service, other system)?
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
To resolve the problem, you need to find out where DYCOM-SQL-SQLCODE is provided data without a valid sign. The long-term solution is to do this.
To merely avoid the IGZ0040S error, you could code
Code:
IF DYCOM-SQL-SQLCODE NUMERIC
IF DYCOM-SQL-SQLCODE = -922 OR -923 OR -924
This does NOT resolve the underlying problem of having invalid data in a numeric variable and could eventually cause your site other problems. However, the NUMERIC test does validate SIGN SEPRATE to be a + or - value or the test fails.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
If the data is only set in another program, then we need to see the definitions and all relevant PROCEDURE DIVISION statements in that program.
A particular thing to watch for is if the same definitions are not used. You realise your field is 10 bytes long, not the "apparent" nine, for instance?
It looks as though the trailing sign is being used to make it "easy" to report the value. If this is so, you'd do much better to hold the original value, and test (with 88s, not your ugly compound condition) that field, and then use a numeric-edited field to format the number for output.
