Issue with LE migration - with TRUNC option

saurabh39 · Posted: Tue Nov 13, 2012 8:01 pm

Hi All,

Recently we migrated our code from VS COBOL II to enterprise and we faced one problem.Below code abended in Enterprise COBOL -

MOVE SUB TO FETCH-CNT
01 SUB PIC 9(2) COMP
01 FETCH-CNT PIC 999

In NON LE the trunc coption was OPT.

In LE the trunc option is STD.

My hypothesis was the trunc option is playing the spoilsport, since in LE we are limiting the size of variable SUB to 2 bytes when 100 is moved only 00 is stored and hence the issue.

In NON LE the trunc option is OPT. Since 100 can still be stored in halfword, the truncation is not happening as a result the program is working.

To prove this, I put displays in both LE and NON LE modules. In LE the variable SUB shows 00 and then it is abending. In NON LE, the variable SUB shows 00, but FETCH-CNT shows 100 which means correct data is moved to FETCH-CNT. But my "Dsiplay" is limiting the display to 2 bytes ie 00 only. My question is -
1. Is my hypothesis correct? If so, how can I display that SUB is able to hold 100 in NON LE.

Please let me know in case of any concerns.

enrico-sorichetti · Posted: Tue Nov 13, 2012 8:29 pm

speak to the person/group that customized the new cobol installation
THEY should have read and understood before deploying it the differences between the old and new

and should know how to customize the new defaults option by assembling with the proper parameters the IGYCOPT macro

such a simple issue should have been spotted pretty early in the installation procedure

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

enrico-sorichetti · Posted: Tue Nov 13, 2012 9:02 pm

as usual
they do not have the time to do <things> in the right way
but they have the time to do them twice

saurabh39 · Posted: Tue Nov 13, 2012 9:13 pm

Hi All,

My next step is to go to them only, but before I say or ask them to do something, I wanted to be sure of what I am speaking thats why I came here.

Regards,
Tushar

Bill Woodger · Posted: Tue Nov 13, 2012 9:24 pm

The options you are talking about are Cobol options, nothing to do with LE.

You only want OPT if your data conforms to PICture. Which means, if you have COMP PIC 9(2), then with OPT your results will be unreliable and only predictable from the particular code-sequence the compiler chooses to generate.

You should review all compile options, if one is "wrong" there may be others (plus note it is not "wrong", it is different).

Someone has not done there homework. Time to start it now.

EDIT: Meaning when you are stuffing greater than 99 into it.

Robert Sample · Posted: Tue Nov 13, 2012 9:32 pm

TRUNC(OPT) is a dangerous option, especially in production. From the Enterprise COBOL Programming Guide manual on the TRUNC option:

Bill Woodger · Posted: Tue Nov 13, 2012 10:17 pm

How did you manage to get an "abend" with the line of code you showed? I can think of no possible way to get that line of code, with those data definitions, to abend, so I'm interested.

If your data "conforms to PICture" and is COMP or COMP-4 - ie, PIC 9 has max value of 9, PIC 99 has max of 99, PIC 999 has max of 999, PIC 9999, then you may reliably your TRUNC(OPT), TRUNC(STD), TRUNC(BIN) in Enterprise Cobol.

If your data does not "conform to PICture" - ie, you'd like to store 10 or more, 100 or more, 1,000 or more, 10,000 or more, then only TRUNC(BIN) or defining as COMP-5 will do what you want.

As Robert has indicated, using OPT in your original programs was not a good choice, as you either "got lucky" or you don't yet know how unlucky you got.

This, for me, is one of those "I wish it wasn't like that, but at least we've discovered it now, so let's check on what's gone wrong because of it" moments. If your system has been USING OPT and deliberately not conforming to PICture, then it's been an accident-waiting-to-happen,-or,-that-has-happened-and-is-waiting-to-be-noticed.

On the question of the DISPLAY, the only way you'll get it to show the full value in itself is by redefining it as a PIC XX and displaying that, then look at it in HEX. OPT is assuming, not unreasonably, that if your have PIC 99 then you only want two digits when you DISPLAY it.

saurabh39 · Posted: Wed Nov 14, 2012 1:26 am

The line of code i showed was the culprit and not exactly the line of code at which program abended. Basically the receiving field FIXED-CNT is used as a subscript, so when 100 was moved, the FIXED-CNT had 00, so when the data was inserted into the table..it abended with Array out of bound.

Anyways, thanks everyone for response, I will talk to the admin team on this now.

Bill Woodger · Posted: Wed Nov 14, 2012 2:23 am

OK, that makes more sense. However, to move a binary field to a USAGE DISPLAY field to use it as a subscript... where it will get turned back into a binary (each time going via converting it to packed) is a little wasteful :-)

Bill O'Boyle · Posted: Wed Nov 14, 2012 3:56 am

Define the variable as an unsigned PIC 9(09) COMP or COMP-5 (if supported) and you won't go wrong.

Many years ago, out of the new fangled internal definition of the TRUNC compile option, I recommend programmers avoid halfwords and instead, use fullwords.

If you use TRUNC(OPT) and COMP-5 is not supported, your maximum is 999999999, which should cover you.

If your compiler supports COMP-5 (Native Binary), then use it instead.

The TRUNC option has no effect on COMP-5 variables and is ignored.

Bill Woodger · Posted: Wed Nov 14, 2012 5:31 am

Yes, if you have a need to not conform to PICture, then use COMP-5 to define the item(s) in question.

You can then compile with either TRUNC(STD) or TRUNC(OPT) (OPT only if you are certain all other fields conform to PICture) without affecting the items defined as COMP-5.

If, however, it was just original coder-laziness to make something COMP PIC 99, then change it to 9(4)/9(9) (for TRUNC(STD)) or 9(4)/9(8) (for TRUNC(OPT)).

NOTE: TRUNC(OPT) behaves poorly with PIC 9(9). If you need that many digits and performance is a criteria use PIC 9(10)! This is according to R. J. Arellanes' Performance Tuning papers.

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

For anyone reading this thread later, a good example of NEEDING to not conform to picture:

IMS message length is 2 bytes binary, so PIC 9(04) COMP-5 works great.

Bill O'Boyle · Posted: Wed Nov 14, 2012 8:36 pm

Bill,

PIC 9(10) through PIC 9(18) COMP is treated as a Binary-Doubleword to COBOL (not that friendly to the language) and the last time I looked, COBOL uses run-time routines to perform arithmetic, which isn't that efficient. But, this was a while ago and the newer compilers may have changed and now do arithmetic in-line, especially if it's defined as COMP-5 and/or use 64-Bit register-instructions.

Bill Woodger · Posted: Wed Nov 14, 2012 10:32 pm

Bill,

The paper says it is only an issue for TRUNC(OPT). TRUNC(BIN) (and COMP-5) and don't make no nevermind about 9(9).

With TRUNC(OPT), 9(10) is faster to process than 9(9), apparently :-)

With OPT, the 9(10) through 9(17) are processed in doubleword format, but so is the 9(9), needing conversion from, and to, fullword, so slower. 9(18) goes to a higher precision than doubleword, apparently, so is slowest of all.

With TRUNC(STD) the 9(18) is also treated differently, as is the 9(9), slower than 1-8, but faster than 10-17.

With TRUNC(BIN) or COMP-5 the 9(18) remains as doubleword, it seems.

All big fun, and information tucked away.

Despite all the above, OPT is consistently faster overall, followed by STD, followed by BIN/COMP-5.

Of course, wait for all of the above to change with the new Compiler.

TRUNC(BIN) reflects the ANSI 85 standard. OPT and STD are IBM Extensions.

Bill Woodger · Posted: Thu Nov 15, 2012 1:25 am

This is IF field equal to 1, add 1 to field, for COMP PIC 9(9) and 9(10), TRUNC(OPT).