Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Alphanumeric to Numeric move on UNIX

 
Post new topic   This topic is locked: you cannot edit posts or make replies.    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
mistah kurtz

Active User


Joined: 28 Jan 2012
Posts: 268
Location: Room: TREE(3). Hilbert's Hotel

PostPosted: Wed Jul 27, 2016 8:47 pm    Post subject: Alphanumeric to Numeric move on UNIX
Reply with quote

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.
Back to top
View user's profile Send private message

Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Wed Jul 27, 2016 9:25 pm    Post subject:
Reply with quote

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?
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7234

PostPosted: Wed Jul 27, 2016 9:31 pm    Post subject: Reply to: Alphanumeric to Numeric move on UNIX
Reply with quote

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?
Back to top
View user's profile Send private message
Rohit Umarjikar

Senior Member


Joined: 21 Sep 2010
Posts: 1610
Location: NY,USA

PostPosted: Wed Jul 27, 2016 10:04 pm    Post subject:
Reply with quote

Quote:
If the alpha nuimeric field is all spaces, then the Numeric field has the value as X'404040F0" in Mainframe.
Ideally, you/programmer should have replaced the spaces to zeroes before making the move at first place.
Back to top
View user's profile Send private message
mistah kurtz

Active User


Joined: 28 Jan 2012
Posts: 268
Location: Room: TREE(3). Hilbert's Hotel

PostPosted: Wed Jul 27, 2016 10:48 pm    Post subject:
Reply with quote

Hi Robert,
Quote:
1. Get rid of the RIDICULOUS requirement that the output of the Unix program match exactly the output of the mainframe program.

It's more RIDICULOUS than you think it is when you get to know that this file is used to upload a table and column corresponding to this field is defined as CHAR. But me and the developer guy from the unix side are at the bottom of the food chain. It's really hard for us to explain this to "THE MANAGEMENT". That's why I opted for the hard coded option and that was a copy paste error. In unix it is X'20202020'. I will check if there is a compiler option available else I will proceed with the 3rd option.

Hi Bill,
Thanks to your wonderful post here that helped me a lot to understand why in MF it is coming as X'404040F0'.
Quote:
Which compiler? Ask the vendor. There may be a compile option/switch which gets the same behaviour.

I will check it tomorrow for compiler version and try to contact vendor.

Hi Rohit,
Quote:
Ideally, you/programmer should have replaced the spaces to zeroes before making the move at first place.

I didn't quite follow you here. This is an existing mainframe program running in production for several years. Just now they decided that they want to move to unix.

Thanks
K.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Thu Jul 28, 2016 12:06 am    Post subject:
Reply with quote

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).
Back to top
View user's profile Send private message
mistah kurtz

Active User


Joined: 28 Jan 2012
Posts: 268
Location: Room: TREE(3). Hilbert's Hotel

PostPosted: Thu Jul 28, 2016 12:48 am    Post subject:
Reply with quote

Robert,
Quote:
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".

We are past that point, but they are not willing to consider it. We have spent more time and effort than it takes to "we are willing to put in". And as a last resort, I have posted here, because somehow I'm feeling that the hard-coded-way is NOT the right way!

Thnaks
K.
Back to top
View user's profile Send private message
Phrzby Phil

Active Member


Joined: 31 Oct 2006
Posts: 961
Location: Richmond, Virginia

PostPosted: Thu Jul 28, 2016 10:06 am    Post subject:
Reply with quote

This is why I'm glad I am now retired.
Back to top
View user's profile Send private message
mistah kurtz

Active User


Joined: 28 Jan 2012
Posts: 268
Location: Room: TREE(3). Hilbert's Hotel

PostPosted: Thu Jul 28, 2016 12:26 pm    Post subject:
Reply with quote

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).
Code:
  -febcdic-charset      Compile for a EBCDIC charset runtime

We have contacted the vendor with our query. I will post the response that they come up with.

Thanks
K.
Back to top
View user's profile Send private message
Nic Clouston

Global Moderator


Joined: 10 May 2007
Posts: 1715
Location: UK

PostPosted: Thu Jul 28, 2016 7:47 pm    Post subject:
Reply with quote

Surely the requirement is to have matching DATA not ENCODING!
Back to top
View user's profile Send private message
mistah kurtz

Active User


Joined: 28 Jan 2012
Posts: 268
Location: Room: TREE(3). Hilbert's Hotel

PostPosted: Wed Aug 03, 2016 11:47 pm    Post subject:
Reply with quote

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
Code:
'0000'
and not as in Mainframe
Code:
'   0'


And since this file goes to another system so everyone feels that we should make it as per mainframe (the last working thing). Hence we have decided that after the output is produced, we will add a post script in UNIX to make that field look like the way they want it before FTP.

Thank you all for your valuable suggestions. I was not able to convince them to change the requirements, nevertheless I have learnt a few more things which are of great value.

Thanks
K.
Back to top
View user's profile Send private message
Rohit Umarjikar

Senior Member


Joined: 21 Sep 2010
Posts: 1610
Location: NY,USA

PostPosted: Thu Aug 04, 2016 12:52 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
mistah kurtz

Active User


Joined: 28 Jan 2012
Posts: 268
Location: Room: TREE(3). Hilbert's Hotel

PostPosted: Thu Aug 04, 2016 1:05 am    Post subject:
Reply with quote

Can you post what you tried in Z/OS, along with compiler options?
Back to top
View user's profile Send private message
Rohit Umarjikar

Senior Member


Joined: 21 Sep 2010
Posts: 1610
Location: NY,USA

PostPosted: Thu Aug 04, 2016 1:15 am    Post subject:
Reply with quote

Same as what you tried. I tried with variable and hardcoded space movements.
Code:
NOADATA                 
NOADV                   
  APOST                 
  ARCH(10)               
  ARITH(COMPAT)         
NOAWO                   
BLOCK0                   
  BUFSIZE(4096)         
NOCICS                   
  CODEPAGE(1140)         
NOCOMPILE(S)             
NOCURRENCY               
  DATA(31)               
NODBCS                   
NODECK                   
NODIAGTRUNC             
NODLL           
NODUMP         
NODYNAM         
NOEXIT         
NOEXPORTALL     
NOFASTSRT       
  FLAG(I,W)     
NOFLAGSTD       
  INTDATE(ANSI)
  LANGUAGE(EN) 
  LINECOUNT(60)
  LIST         
  MAP           
NOMDECK         
NONAME         
  NSYMBOL(DBCS)
NONUMBER         
  NUMPROC(NOPFD)
  OBJECT         
NOOFFSET         
  OPTIMIZE(2)   
  STGOPT         
  OUTDD(SYSOUT) 
  PGMNAME(COMPAT)
  RENT           
  RMODE(AUTO)   
NOSEQUENCE       
  SIZE(5000000) 
  SOURCE         
  SPACE(1)       
NOSQL           
  SQLCCSID       
 NOSSRANGE             
 NOTERM                 
   TEST(NOEJPD,SOURCE) 
 NOTHREAD               
   TRUNC(OPT)           
 NOVBREF               
 NOWORD                 
   XMLPARSE(COMPAT)     
   XREF(FULL)           
   ZWB                 
SQL("APOSTSQL,DEC(31)")
Back to top
View user's profile Send private message
steve-myers

Active User


Joined: 30 Nov 2013
Posts: 461
Location: The Universe

PostPosted: Thu Aug 04, 2016 10:33 am    Post subject:
Reply with quote

Robert Sample wrote:
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) ...
Not true. A packed decimal sign of F is an alternate for plus.
Robert Sample wrote:
...
1. Get rid of the RIDICULOUS requirement that the output of the Unix program match exactly the output of the mainframe program. ...
Agreed. *nix (unless you consider Unix System Service in z/OS a *nix environment) is ASCII. For better or worse, z/OS is EBCDIC. It is absolutely impossible to get binary equivalence between EBCDIC and ASCII.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7234

PostPosted: Thu Aug 04, 2016 2:21 pm    Post subject: Reply to: Alphanumeric to Numeric move on UNIX
Reply with quote

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.
Back to top
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10202
Location: italy

PostPosted: Thu Aug 04, 2016 6:44 pm    Post subject: Reply to: Alphanumeric to Numeric move on UNIX
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   This topic is locked: you cannot edit posts or make replies.    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
This topic is locked: you cannot edit posts or make replies. How to move a long alphanumeric data ... lind sh COBOL Programming 8 Mon Dec 05, 2016 7:51 pm
No new posts Sort records based on numeric field. Alks SYNCSORT 2 Wed Oct 19, 2016 10:14 pm
No new posts Protection Exception while move 0 to ... Kevin Vaz CICS 10 Tue Oct 18, 2016 4:19 pm
No new posts Casting a Binary Number to Numeric in... Bob Steinkraus Java & MQSeries 6 Tue Aug 09, 2016 5:58 pm
No new posts How to copy Tape dataset to unix main... chaky All Other Mainframe Topics 4 Fri Jul 08, 2016 2:52 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us