Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
I think you'll find that the VS Cobol II compiler generated an MVC (move character) to move the field that "should" contain packed decimal rather than the decimal instruction that Enterprise Cobol 5.2 is generating. You can check this out by compiling with the LIST option. An MVC will never get a S0C7 abend.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Far from running without issue, the code you have shown will be giving you garbage in VS COBOL II.
I don't have a VS COBOL II compiler handy, so you are going to have to generate the pseudo-assembler and show us what code the compiler creates.
Code:
05 WS-TEST1-VAR PIC S9(6)V99 SIGN LEADING SEPARATE.
05 WS-TEST2-PKD PIC S9(10)V99 COMP-3.
05 WS-TEST3-ALP PIC X(9) VALUE '---------'.
PROCEDURE DIVISION.
MOVE WS-TEST3-ALP TO WS-TEST1-VAR
DISPLAY WS-TEST1-VAR
MOVE WS-TEST1-VAR TO WS-TEST2-PKD
DISPLAY WS-TEST2-PKD
That's horrible code. I've never MOVEd an alpha-numeric to a field with decimal places. Add to that, the leading separate sign.
WS-TEST1-VAR will be positive (since the source is an alpha-numeric field). Then you'll get six "-"s. Then two zeros (for the decimal part).
So, expected result of the first DISPLAY would be:
Code:
+------00
You got:
Code:
+-----000
Without the leading sign I'd expect:
Code:
-----000
Which is a curious extra zero. Only the generated code will explain where that has come from.
It may be (probably is) that the compiler generates the same "sign-rectification" for the low-order digit when SIGN IS SEPARATE is specified. There is some sense in this, so that a comparison of fields with or without SEPARATE SIGN would be the same when the same data is MOVEd to those fields.
The hex for "-" is '60'. So when the above value is "packed" you'd expect to get zero, and the DISPLAY confirms.
No S0C7 expected for COBOL II.
Now, an issue is that you've put garbage into a numeric field.
If your data is good, V5.2 will give you the same results as older IBM COBOLs.
You say you get a S0C7, somewhere, with V5.2 and that you expect it.
I'd not expect it to S0C7 with V5.2 necessarily. So we need to see the generated code from that, and you need to identify where the abend occurs.
And, yes, we need to see the compile options you are using for both.
Inside the Code tags, as previously suggested.
Are you jumping from VS COBOL II to Enterprise COBOL V5.2?
Garry, as you mentioned, VS cob II is using MVC and Ent cob 5.2 is using PACK.
Compiler option for VS cob II is NUMPROC(MIG) and for Ent Cob 5.2 it is NUMPROC(NOPFD). MIG option is not available in Enterprise. Is there any option available in Ent 5.2, to make it work like Vs Cob?
Bill,
I hope below information is what you are looking for. (and yes we are moving to 5.2 :-) )
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Yes, thanks, those are the options, both sets, that I wanted to see.
You have LIST,NOOFFSET so you already have the generated pseudo-code in the listing. Find the line-numbers of your two MOVE statements in the source-listing, then find those line-numbers (which will show they are MOVEs) and copy/paste here.
You also need to indicate where the V5.2 abended.
You also need to establish why MOVEing nine dashes to a numeric field with decimal places, then further to a packed decimal with decimal places, was thought to be a good idea in the first place.
Going from NUMPROC(MIG) to NUMPROC(NOPFD) is interesting. Check that that setting of ZONEDATA is what you want.
Also compile the V5.2 with OPT(0) and see if the program still abends when you run it.
00027E F267 9009 9001 PACK 9(7,9),1(8,9)
000284 954E 9000 CLI 0(9),X'4E'
000288 58B0 C010 L 11,16(0,12)
00028C 4770 B0E0 BC 7,224(0,11)
000290 94F0 900F NI 15(9),X'F0'
000294 960C 900F OI 15(9),X'0C'
000298 47F0 B0FE BC 15,254(0,11)
00029C GN=8 EQU *
00029C 9560 9000 CLI 0(9),X'60'
0002A0 4770 B0F4 BC 7,244(0,11)
0002A4 94F0 900F NI 15(9),X'F0'
0002A8 960D 900F OI 15(9),X'0D'
0002AC 47F0 B0FE BC 15,254(0,11)
0002B0 GN=10 EQU *
0002B0 58F0 21CC L 15,460(0,2)
0002B4 4110 A0AB LA 1,171(0,10)
0002B8 05EF BALR 14,15
0002BA GN=11 EQU *
0002BA GN=9 EQU *
0002BA F844 900B 900B ZAP 11(5,9),11(5,9)
Job is abending in first move statement
Code:
CEE3207S - The system detected a data exception (System Completion Code=0C7). From compile unit IMBTEST at entry point IMBTEST at statement 63 at compile unit offset +000001DC at entry offset +000001DC at address 0C9001DC.
Well the real issue is happening between 'N' number of programs/subprograms At the end the problem is this - one move to zoned decimal and then to packed . Iam also checking why ------- is coming in the first place.
Will check about ZONEDATA. I tried with OPT(0), but job is still abending
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Thanks. That's the stuff.
I can see the abend (the SRP), although the abend you have quoted is for a different program (look at the failing offset).
Can you remove the decimal places from WS-TEST1-VAR?
The problem you have is having used bad data and a bad definition (the one like WS-TEST1-VAR) your program was "working" per COBOL II.
However, for Enterprise COBOL V5 there has been a substantial rewrite (I don't know the extent) and you can't rely on having been "saved" by the way an older COBOL operated in the past and now have the same behaviour in V5.
It's bad code with bad data. As I suggested previously, you're going to have to find out what the intention of it was, and do it a better way.
EDIT: I'm using "your" in the sense of it being the program you are working on, not a program that you wrote :-)
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Why can't you use that?
The code does not work with the bad data. If you have to give it bad data, you will have to fix the code.
If someone has said "do the conversion but don't change a line of code," then they've been "shortsighted".
If WS-TEST1-VAR (I know it is a dummy name, I hope) is not used for anything else, defining it without decimal-places is a much more accurate thing to do (an alpha-numeric can never have decimal places).
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Just an update on a couple of things here.
TS/OP is already using ZONEDATA(MIG). This is a new compiler option for V5.2 which, for comparisons only, forces the use of decimal instructions.
Since the problem was not with a comparison, ZONEDATA(MIG) has no effect.
Deliberately putting bad data into a zoned-decimal field and expecting it to "work" in the same way in V5 as in a previous compiler is not a sustainable idea.
To assist, a new compiler option for V5.2, ZONECHECK, is available via APAR.
This does an implicit NUMERIC test for each zoned-decimal field in a program. If a field is not NUMERIC, then depending on setting, a message is produced (ZONECHECK(MSG)) or a run-time user-abend (ZONECHECK(ABD)).
This option will identify all "invalid" use of zoned-decimal fields, and such invalid use should be corrected.
Depending on the number of zoned-decimal fields in a program, and the amount of data, there will be a significant CPU impact, so, like SSRANGE, it is more of a "testing" option, than intended for Production.
EDIT: ZONECHECK and ZONEDATA are also available for V5.1, via APAR.
)
At the end the problem is this - one move to zoned decimal and then to packed . Iam also checking why ------- is coming in the first place.
