eCobol conversion issue with move to S99 field 3

[pbw65]

Hello, I have a question about an eCobol conversion that I am working on. What's happening is I am moving a PIC S99 field to another PIC S99 field and the values are changing. The sending field has a value of 90 and the receiving field after the move contains a value of 9{ . I have never seen this on a MOVE statement. Is this a result of an LE compile option that may not be set correctly? Just as a note, the programs compiled as ANS (pre LE) work fine, the move passes the data cleanly. Does anyone have any insite as to what might be going on?
Paul

 

[razalas]

What are the USAGE characteristics for both of these fields? Without seeing how these fields are defined explicitly, I would guess that you are moving from a field with usage COMP-3 to a field with usage DISPLAY.

The trailing "{" is simply how the sign is represented in the usage DISPLAY field (i.e. with an "overpunch" character).

Code what you mean,
and mean what you code!
But by all means post your code!

Razalas

 

[Crox]

I think you just got a sign in the receiving field. If they have the same picture, you can make a pic xx move using redefines or reference modification like

move numfieldsending(1 to numfieldreceiving(1 and if the fields are identical, there will be no conversion.
If the fields are not identical and you know that the sending field contains only unsigned integers, you can define the receiving field with picture 99.

Regards,

Crox

 

[pbw65]

Razalaz and Crox thank you for your posts!! The fields are both display fields which is why it seem so odd that this is happening. The same code is running succesfully in production in ANS form, Convert it to eCob or even cob2 and the data becomes corrupted. I'll try the pic xx redefines an/or reference mods and see what happens. I'll post my code along with my field descriptions and displays on Monday when I get to work. I appreciate your prompt response and have a great weekend!!
Paul

 

[webrabbit]

The standard COBOL rules for an elementary (non-group) move is that the sign in the target is adjusted to conform to its Picture. This is regarless of the Usage. Thus, if the source contains a non-sign (no "overpunch") regardless of its Picture, the target will be given a + sign if it has an "S" in its Picture. Some early compilers did not conform to this rule. Note that if you use reference modification, as Crox suggests, the rules explicitly state that this is treated as a group move. In that case, the Usages must be identical as well as the size (number of bytes) to avoid data corruption.

 

[pbw65]

Here are my field descriptions, code and displays

FIELD DESCRIPTIONS:
Here are the field definitions from each of these
01 WS-DATE-YEAR PIC S99 VALUE ZERO.
04 PC-C-VEH-YEAR-R.
06 PC-C-VEH-YEAR PIC S99.

05 DATER-YEAR2 PIC 99.
05 DATER-YEAR2-D REDEFINES DATER-YEAR2.
10 DATER-YEAR2-S PIC S99.

_________________________________________

CODE:
MOVE PC-C-VEH-YEAR TO DATER-YEAR2-S WS-DATE-YEAR.

_________________________________________

DISPLAYS:

PC-C-VEH-YEAR 90 <-- sending field
WS-DATE-YEAR 9{ <-- receiving field
DATER-YEAR2-S 9{ <-- receiving field

 

[webrabbit]

That is exactly what the COBOL standard says should happen.

 

[PHV]

Use PIC 99 receiving fields ...

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886

 

[webrabbit]

BTW, if you Move PC-C-VEH-YEAR to DATER-YEAR2-D
or PC-C-VEH-YEAR-R to either of the target fields, there will be no sign added, and, because the underlying elementary fields are identical, no data corruption, assuming the original data is valid.

 

[pbw65]

This is what was happening on that move. The current LE compiler option was packing the fields prior to the move where as the ANS compile was not. The assembler code below shows what the compiler was doing:

LE compiler shows fields being packed:
2844 MOVE
001B52 F211 D220 30BB PACK 544(2,13),187(2,3) OPT=0
001B58 F811 D220 D220 ZAP 544(2,13),544(2,13) OPT=0
001B5E F311 316F D220 UNPK 367(2,3),544(2,13) DATER-YEAR2-S
001B64 F311 3000 D220 UNPK 0(2,3),544(2,13) WS-DATE-YEAR

I added compile option CBL NUMPROC(PFD)
and it cleaned up the move. It now looks like this:

2844 MOVE
001B4C D201 316F 30BB MVC 367(2,3),187(3) DATER-YEAR2-S
001B52 D201 3000 30BB MVC 0(2,3),187(3) WS-DATE-YEAR


Thanks to everyone for your help!!!

 

[webrabbit]

The PACK and ZAP are to conform to COBOL's standard. Aparently NUMPROC(PFD) allows the compiler to deviate from the standard. What does PFD stand for?

 

[slade]

Hi Paul,

I think the explanation is that your sending field was never a receiving field of an elementary MOVE when it was populated. It was probably populated as part of a group move, so no sign conversion took place.

That would keep the value at "90" (X'F9F0', an unsigned 90) in spite of the sign in the PIC. When you moved it as an elementary item the X'F0' was converted to X'C0' ("{"), turning the 90 into 9{, (a positive 90).

Regards, Jack.

"A problem well stated is a problem half solved" -- Charles F. Kettering

 

[pbw65]

Webrabbit, my understanding is that PFD is for preferred sign. This is what it actually does. I got this from the IBM Peformance Tuning Manual

Using the NUMPROC(PFD) compiler option generates significantly more efficient code for numeric comparisons.
It also avoids the generation of extra code that NUMPROC(NOPFD) or NUMPROC(MIG) generates
for most references to COMP-3 and DISPLAY numeric data items to ensure a correct sign is being
used. With NUMPROC(NOPFD), sign fix-up processing is done for all references to these numeric data
items. With NUMPROC(MIG), sign fix-up processing is done only for receiving fields (and not for sending
fields) of arithmetic and MOVE statements. With NUMPROC(PFD), the compiler assumes that the data
has the correct sign and bypasses this sign fix-up processing. NUMPROC(MIG) generates code that is
similar to that of old COBOL. Using NUMPROC(NOPFD) or NUMPROC(MIG) may also inhibit some
other types of optimizations. However, not all external data files contain the proper sign for COMP-3 or
DISPLAY signed numeric data, and hence, using NUMPROC(PFD) may not be applicable for all application
programs. For performance sensitive applications, the use of NUMPROC(PFD) is recommended where
possible. (APG: MVS pp 68, 175, 306-307; VSE pp 65-66, 169, 280-281)

Slade: You are correct. The sending field was read in directly from an input file

 

[gobleza]

01 WS-DATE-YEAR PIC S99 VALUE ZERO.
04 PC-C-VEH-YEAR-R.
06 PC-C-VEH-YEAR PIC S99.

05 DATER-YEAR2 PIC 99.
05 DATER-YEAR2-D REDEFINES DATER-YEAR2.
10 DATER-YEAR2-S PIC S99.

Do all these fields fall under the one group level namely ws-date-year?

 

[3gm]

gobleza -

AFAIK, your data definition will not compile on any standards-compliant compiler.

You have a PIC on WS-DATE-YEAR which implies it is an elementary item but you have higher level items under it.

You have an 06 level under the 04 followed by an 05. That's a non-standard use of levels.

Regards,

Glenn

 

[webrabbit]

1) I think the OP has left the building.

2) I think the original posted code was not complete segments of code but rather individual lines selected from the program.

 

[pbw65]

sorry guys didn't mean to leave ya hangin... My problem is solved, it was a compiler issue with the new version of LE we installed. They systems guys did not match compiler options with the ANS4 compiler. Anyway that problem is solved but to answer your outstanding questions:

Gobelza: No they are not part of a single 01 level. I should have put a space in between the 01 and the 04 level. Sorry my bad.

I appreciate all your input into this issue!! I'm sure I'll be back with my next issue... Actually can anyone tell me how to close this issue?

 

[slade]

You just did. Thanx for letting us know.

Regards, Jack.

"A problem well stated is a problem half solved" -- Charles F. Kettering