Alphanumeric to Numeric move on UNIX

mistah kurtz · Posted: Wed Jul 27, 2016 8:47 pm

We are migrating a COBOL program from Mainframe to Unix System.

In one of the COBOL program there is a MOVE statement to move the data from PIC X(4) to PIC 9(4).

If the alpha nuimeric field is all spaces, then the Numeric field has the value as X'404040F0" in Mainframe. But In Unix environment Numeric field has all the spaces: X'40404040".

I believe that this is due to different platform and compiler differences. But the requirement is that the output should match exactly.

I though of moving the hard coded value X'404040F0" if the alphanumeric field has all spaces. But i was just wondering if this is the only possible way.

Could you suggest if there are any other way to achieve this on UNIX.

Thanks.
K.

Robert Sample · Posted: Wed Jul 27, 2016 9:25 pm

With Enterprise COBOL, when you move a PIC X(4) variable to a PIC 9(4) variable, the compiler generates code to ensure the sign is correct and hence forces the last byte's zone to be X'F?'(which indicates an unsigned value) and F0 is an EBCDIC zero. This will actually be an issue for ANY move of PIC X to PIC 9 -- it is NOT just limited to 4-byte variables.

You have several options:
1. Get rid of the RIDICULOUS requirement that the output of the Unix program match exactly the output of the mainframe program.
2. Investigate the Unix COBOL compiler to see if it has an option to force signs like the Enterprise COBOL compiler.
3. Hard-code moves as you indicated you could -- but this can get complicated, depending upon your data.

And, by the by, a Unix system will NOT put out X'40404040' or X'404040F0' in any case -- since Unix systems use ASCII, you should be seeing X'20202020' for 4 spaces. If you are not, then you have MUCH bigger problems -- such as why is the Unix system not using ASCII?

Bill Woodger · Posted: Wed Jul 27, 2016 9:31 pm

Which compiler? Ask the vendor. There may be a compile option/switch which gets the same behaviour.

Since the value is invalid anyway, which the problem?

Rohit Umarjikar · Posted: Wed Jul 27, 2016 10:04 pm

mistah kurtz · Posted: Wed Jul 27, 2016 10:48 pm

Hi Robert,

Robert Sample · Posted: Thu Jul 28, 2016 12:06 am

My experience has been that when things are properly explained to management -- even by people "at the bottom of the food chain" -- that management has no problems adapting their requirements. It may be that it will take more time and effort to explain it than you're willing to put in, but don't just use the cop-out "the requirement is".

Someone needs to point out to management that while COBOL has a standards committee and defined standards, there are NO COBOL compilers on the market today that completely meet ANY of the standards. Either the compiler doesn't implement certain parts of the standard, or the compiler has extensions to the standard, or (usually) both. Hence having the same output from compiled programs on different platforms match should be more the exception than the norm; this is even more so when you consider the difference in numeric representations on Unix machines and z/OS (big endian and little endian, floating point formats and round-off / truncation errors related to floating point, etc).

mistah kurtz · Posted: Thu Jul 28, 2016 12:48 am

Robert,

Phrzby Phil · Posted: Thu Jul 28, 2016 10:06 am

This is why I'm glad I am now retired.

mistah kurtz · Posted: Thu Jul 28, 2016 12:26 pm

Hi,

We are using COBOL-IT 3.7.58-enterprise-64.0 compiler provided by ESI Services, LLC. There seems to be a compiler option: ebcdic-charset ( which is currently set to no).

Nic Clouston · Posted: Thu Jul 28, 2016 7:47 pm

Surely the requirement is to have matching DATA not ENCODING!

mistah kurtz · Posted: Wed Aug 03, 2016 11:47 pm

Hi,

As suggested by vendor, we tried the several compiler options that was provided.

But in all the cases, when we move an X(4) with all spaces to 9(4), the result is all zeros

Rohit Umarjikar · Posted: Thu Aug 04, 2016 12:52 am

When I tried , I did not observe this X'404040F0" as you do, may be you change the compiler option for zOS instead of UNIX to fix the problem.

mistah kurtz · Posted: Thu Aug 04, 2016 1:05 am

Can you post what you tried in Z/OS, along with compiler options?

Rohit Umarjikar · Posted: Thu Aug 04, 2016 1:15 am

Same as what you tried. I tried with variable and hardcoded space movements.

steve-myers · Posted: Thu Aug 04, 2016 10:33 am

Bill Woodger · Posted: Thu Aug 04, 2016 2:21 pm

Rohit,

You are using Enterprise COBOL V5+. Probably not what is being migrated from. Can you re-run your test with OPT(0) and ARCH(6) or (7) (the lowest ARCH that works)? Can you then post your code? You should get X'404040F0'.

Robert,

COBOL outside the Mainframe also understands codepages, and "migration" vendors are always keen to be able to match results, so I'd expect X'404040F0'.

Mistah,

Who is the vendor?

Steve Myers,

For COBOL, F is, conventionally, the absence of a sign but something present in the position where a sign would be if it were signed.

Having an F in a signed field, in COBOL, is no guarantee that it will just be treated as an alternative for plus. It is bad data.

enrico-sorichetti · Posted: Thu Aug 04, 2016 6:44 pm

when a topic does not reach a conclusion after a reasonable number of replies
it should be locked !
and now it is.

furthermore the topic is not even related to a ZOS Cobol environment
if it were we could have run tests, with another environment we CAN NOT

work with the vendor and the other system support.