Topic
  • No replies
SystemAdmin
SystemAdmin
403 Posts

Pinned topic Porting cobol to TX Series

‏2013-01-22T19:09:45Z |
I have mainframe code that moves comp data to a 9(9) field.
The comp data is part of an Alphanumeric group field.

Ex:
01 ws-employee-nbr PIC 9(9).
01 ws-employee-nbr-temp PIC PIC S9(09).
01 employee-group.
05 employee-nbr PIC 9(9) comp.
05 employee-name PIC X(40).
...
Procedure Division
move employee-group(1:4) to ws-employee-nbr-temp
move ws-employee-nbr-temp to ws-employee-nbr

Will the above work the same in TX Series? Is the offset lengths of group fields the same in TX as it is on the mainframe?

Thanks in advance
  • TX Newbie
Updated on 2013-01-24T11:05:01Z at 2013-01-24T11:05:01Z by BillWoodger
  • BillWoodger
    BillWoodger
    137 Posts

    Re: Porting cobol to TX Series

    ‏2013-01-23T02:02:56Z  
    Are you sure that the code is correct? Looks "unusual" to me...

    I suppose if you want to know if you get the same results, try it out.
  • outlaw
    outlaw
    41 Posts

    Re: Porting cobol to TX Series

    ‏2013-01-23T21:13:55Z  
    TX Series is a transaction server, running on AIX and Windows (at least, possibly also Linux) - and is called CICS on z/OS. It can run programs written in COBOL, PL/I, C, ASM, ... Its API differs slightly betwixt z and the workstation platforms.

    To which workstation COBOL (AIX or Windows) are you porting to (note that TX Series is not relevant) ?

    All that said, the answer to you question lives within the COBOL for <os dujour> Programming guides.

    The important piece being that on all three platforms:
    PIC 9(9) COMP. will occupy 4 bytes (32bits) of storage - this true binary - big endian on z and AIX, little endian elsewhere
    PIC 9(9) packed and PIC S9(9) packed will occupy 5 bytes (12 34 56 78 9s; where s=sign nibble)
    PIC 9(9) display zoned will occupy 9 bytes (one per digit)

    The only comment about the code I'll make is that group moves/compares of non-displayable character data a fraught with peril - likely to cause data exceptions, odd printouts, add in unmatched sizes, and ... Just don't go there, if at all possible.
    Richard A Nelson (Rick)
    COBOL Development IBM Silicon Valley Laboratory
    http://www.ibm.com/software/awdtools/cobol/
  • BillWoodger
    BillWoodger
    137 Posts

    Re: Porting cobol to TX Series

    ‏2013-01-24T11:05:01Z  
    Are you sure that the code is correct? Looks "unusual" to me...

    I suppose if you want to know if you get the same results, try it out.
    From the code, I started off with an employee number of 1111.

    01 WS-EMPLOYEE-NBR PIC 9(9), ends up with

    
    00000   7 FFFFF000F 000000047
    


    This is whether using NUMPROC(PFD) or (NOPFD) (as the field is unsigned).

    If you use this field in a MOVE to something else, you will end up with 47, with however many leading zeros for the target field.

    If you compare WS-EMPLOYEE-NBR to a literal 47 or to a field containing 47, you may or may not get a match (you won't with the literal). With the compare to a field, it depends on the type of field, and maybe the lengths, and the NUMPROC compile option. Since you'd have to be very careful to get a test which would work for the wrong value (not 1111) then the code as shown I'd regard as not worth much. I can't imagine that it "works" in any reasonable way, and I doubt it would "work" in any reasonable way on any OS, so in those terms the outcome would be the same (not working), even if actual results were different.

    Using a different initial value (other than 1111), lets say 255, and you'd end up with WS-EMPLOYEE-NBR which may give a S0C7 in a compare, and would definitely S0C7 in any arithmetic (which you'd not do with that field).

    That's what I meant by "unusual".