Any issues/concerns with Gen (COBOL) using PROCESS ARITH(EXTEND)

[Douglas Seaver]

We have an interface to an external application that needs an amount specified as

Column Name        Col No Col Type Length Scale

*                       * *             *      *

------------------ ------ -------- ------ ------

PYMNT_AMT              25 DECIMAL      26      3

To use these large numbers in COBOL programs, you have to add the PROCES ARITH(EXTEND) statement.

This is not part of normal compile options, which we can change.  Question is, is it OK to do this globally for all generated COBOL, or are there caveats?  Don't want to introduce any problems if it can be avoided.

Added 7/22/2024 based on Teresa's response:

What about inline code?  We are trying to avoid writing a separate EAB by using inline code.

[Attila Fogarasi]

From a COBOL standpoint, this support was added in Cobol v5 (so circa 20 years ago).  If you compile with ARCH(8) option then the DFP (Decimal Floating Point) hardware instructions are used, which were added in the z10 hardware (again over a decade ago).  If hardware DFP is not available COBOL uses software which involves calling runtime to do calculations.  With hardware DFP the speed is comparable and often faster than ARITH(COMPAT), but without hardware assist it is slower.  For most applications using ARITH(EXTEND) is superior.  Note the z10 hardware was EOL in 2019 by IBM, so reasonable to expect all machines have DFP today.  

  I don't know if there is any GEN impact (expect there would not be).  Others may be able to comment on that.  

[Lynn Williams]

Hi Doug,
Further to Attila's reply, I did find a support case from around 2 years asking how ARITH(EXTEND) could be added to Gen 8.6 COBOL compiler options and i saw that Engineering did not highlight any possible problems with doing that. I will however ask their opinion again.

Regards

Lynn

[Teresa Bredenkamp]

Doug,

The response to your question " is it OK to do this (=add the PROCES ARITH(EXTEND) statement globally ) for all generated COBOL, or are there caveats?  Don't want to introduce any problems if it can be avoided." is that you should not/must not use ARITH(EXTEND) for all Gen generated COBOL because the Gen runtimes will not be able to handle numbers larger than 18 digits.

If you want to call non-Gen code passing larger numbers, you can customize the interface to the external application (assume this is an EAB) to your needs but you must ensure that what is returned to Gen is within 18 digits or you will experience problems.  

If you want to discuss specific requirements please open a support case.

Regards, 

Teresa

[Douglas Seaver]

Added 7/22/2024 based on Teresa's response:

What about inline code?  We are trying to avoid writing a separate EAB by using inline code.

[Teresa Bredenkamp]

Doug,

The same applies to Inline code. As long as you return 18 digits to Gen generated code this would be fine. 

Regards,

Teresa 

[Douglas Seaver]

Is there is a way to tell inline code that it needs to add a PROCESS ARITH statement to the generated COBOL code?

[Attila Fogarasi]

The PROCESS statement in Cobol applies to the entire compilation unit, and when coded inline it must be before the IDENTIFICATION DIVISION header -- so it is the same as having compilation options in JCL, for example.  Cobol has no facility for dynamically turning on and off ARITH(EXTEND) for individual source statements or parts of programs.  

[Teresa Bredenkamp]

There is no way to have inline code to add the PROCESS Statement to the source code before Compiling it. You would have to manually edit after generation. 

Regards,

Teresa