Hi,

There is some fix for RBD V.9.1.1 ?

I'm getting a different result after migrating from VAG to EGL.

sample statement:

Thanks !

Hsieh

I have a couple of questions. 

Is this for cobolGen, javaGen, RUI or debugger?

If cobolgen, is this for iSeries or zSeries or VSE?

Also, I recall there is a build option, something like "truncate extra decimal". What is the setting for both VAG and EGL?

Can you provide both the cbl for vag and egl?

Hi Jeff,

This difference occurs in cobolgen running in zVSE and EGL Debug.

Ok ! I'll go check this option.

Thanks !

Hsieh

Jeff,

The build option was set to "trucate extra decimal" but the result no changed.

Hsieh,

What are the VAGen record definitions for these fields?

What are the generation options used in VAGen?   (can get from comments at top of the genned COBOL)

As Jeff said, if you can attach or send the generated VAGen and EGL, that would be helpful as well.

Mark

Hi Mark,

Right now I'm not connected to the customer's site, but I made a very simple example in VISUALAGE and EGL, below:

VAGen ESF:

VAGen ITF option:

/NOSP
/NOGENTABLES
/NOSYSCODES

/DATA=31
/TARGNLS=ENU
/PROJECTID=VAG
/COMMENTLEVEL=4

EGL Source:

in this moment If you running this code in VAG ITF and EGL Debug, you can see the different result.

No need gencobol.   But running in gencobol as different too.

later I will capture the generated Cobol and send to you.

thanks ... we can work with this I am pretty sure...so don't worry about the COBOL unless we come back and ask.

Hsieh,

Jeff and I looked at this some more and we now know what is going on.

In the example, the target field of the assignment has no decimals, but the rounding integer is set to -1 (which means round at the first decimal place).

In this specific case,

- VAGen is rounding based on the left hand side of the expression.

- EGL is doing the rounding first based on VALOR1 and then doing the assignment to Valor2.  

The truncateExtraDecimals is controlling the last part of this which is the assignement to Valor2 of 74.5 (the rounded value at one decimal place).  With truncateExtraDecimals=YEs, the result is 74, with =NO, it is 75.

However, since truncateExtraDecimals is a build descriptor which affects all the program/programs...and in general we say "=YES" maintains VAGen behavior, I don't think you want to set this to "NO".

So, there are two other solutions for this case.

Change the assignment statement to use mathlib.assign, so something like this:

mathlib.assign(mathLib.round(VALOR1, WS_DECIMAL), valor2);

Or change the rounding value to match the rounding to the digit you really want to receive the rounding (i.e. the first digit to the left of the decimal point).   This means set the rounding value to 0.

  VALOR1 decimal(13,6) ; // item
  VALOR2 decimal(13,1) ; // item
  WS_DECIMAL int ; // item
  VALOR1 = 74.514915;
  WS_DECIMAL = 0;

 VALOR2 = mathLib.round(VALOR1, WS_DECIMAL);

Both ways get the same results in the debugger and in generated COBOL.

Mark

Hi Mark / Jeff

Thanks for found behavior difference.

Question:

The mathlib.round statement came from program migrated from VAGen to EGL.
How to do EGL compatibility with VAG ?

I must use or not use "truncateExtraDecimals=NO" ?  or update statement to use mathlib.assign ?

Regards,

Hsieh

My suggestion is to use "mathlib.assign" for this particular statement.   This is one of the few cases you need to do manual changes.   I am not suggesting you need to use this on all round operations.... This was a special case where the round value did not match the digit places in the target variable.

Mark

Hsieh,

When I set "truncateExtraDecimals=NO", it gave the same result as VAGen in both the debugger and in EGL.

Did you set it to "yes" (also the default) or "no".

Also, truncateExtraDecimals=yes is the "normal" setting when using VAGen compatibility, so you need to decide what to use.   I think the issue here is that VALOR2 is set with no decimal points, but will let Jeff weigh in.

take care

Mark