On Tue, 23 Sep 2014 17:29:56 -0500, Ron Thomas <[email protected]> wrote:
>Sorry the old one is as below > >OLD :- PARSE VAR DATA.A CLUB +3 ITEM +6 PCT +3 . > >So then the new one to be right , which will handle 5 byte data ? > >PARSE VAR DATA.A CLUB +4 ITEM +6 PCT +3 . > >Thanks >Ron T > On Tue, 23 Sep 2014 17:09:25 -0500, Ron Thomas <[email protected]> wrote: >Hello > >Below is the existing structure of the copybook > >01 WRKFL2-REC. > 03 WF2-CL PIC 9(4) COMP-3. > 03 WF2-IT13 PIC X(6). > 03 WF2-PERCWS PIC S999V9 COMP-3. > > >Modified one is > >01 WRKFL2-REC. > 03 WF2-CL PIC 9(5) COMP-3. > 03 WF2-IT13 PIC X(6). > 03 WF2-PERCWS PIC S999V9 COMP-3. > > >This structure is read by a Rexx program , here in the parse do we need to >make any changes ? > >DO A = 1 TO DATA.0 > PARSE VAR DATA.A CLUB +4 ITEM +6 PCT +3 . > IF SYMBOL('INFO.ITEM.1') \= 'VAR' THEN DO > INFO.ITEM.1=0 > INFO.ITEM.2=0 > ITEMPTR = ITEMPTR + 1 > LIST.ITEMPTR = ITEM > END > PARSE VALUE C2X(PCT) WITH PCT +5 SIGN > IF SIGN = 'D' THEN PCT = PCT * -1 > ELSE PCT = PCT + 0 > INFO.ITEM.1 = INFO.ITEM.1 + PCT > INFO.ITEM.2 = INFO.ITEM.2 + 1 >END > > >Thanks >Ron T No you would not have to change anything in the REXX code. The COBOL code you show defines the first field as a Packed (Comp-3) so the Pic(ture) clause defines the number of Digits in the field, not the number of Bytes. Pic 9(4) and Pic 9(5) defined as a Packed field will both occupy 3 Bytes in the record. Packed fields always contain an odd number of Digits plus a sign nibble, (even if it is defined as "unsigned" in the COBOL definition). <Pet Peeve On> All COBOL Packed fields should be defined as Signed and contain an odd number of Digits. COBOL has to generate extra instructions if a Packed field is defined as an even number of Digits and/or as "unsigned". COBOL will also respect the Picture clause when assigning values to the field. With WF2-CL defined as 9(4) Comp-3 and you move 99999 to it, it will only contain 9999, the high order digit will be truncated, even though the Packed field has room for it. With WF2-CL defined as 9(5) Comp-3, then it would contain 99999. And of course, since it is "unsigned", don't even think about moving a negative number to it or subtracting something from it that should cause it to go negative, since it can't go negative. COBOL 5.1 may improve the efficiency of having an unsigned even number of digits, but why rely on a Compiler when its so easy to code it the right way in the first place. <Pet Peeve Off> -- Dale R. Smith ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
