COMP-3 or COMP-4 1

[mfcobol2002]

Microfocus Cobol.

I use comp-3 now in numeric fields.
which the advantage of changing the comp-3 for the comp-4?

01 var-the pic s(9)v9(4) comp-4.

is that correct?

 

[3gm]

Choice of data USAGE is somewhat an art. You have to know your target platform(s) and understand how they support the various COMP formats.

As I understand it, COMP-4 is roughly equivalent to BINARY. For fields that are short enough to be handled as a short int or long int, COMP-4 is probably the fastest choice on a PC platform. Fields that are longer than a long int may be converted to an intermediate form (COMP-3?), or may not depending on compiler design and specific hardware platform. For most internal uses, I'd say COMP-4 is fine.

If the data is going to be exported to another platform, I'd be more likely to go with USAGE DISPLAY SIGN SEPARATE. It avoids big/little endian issues and ASCII/EBCDIC issues at the cost of longer records and more data conversion time to/from internal formats.

Glenn

 

[webrabbit]

For speed in Microfocus, use COMP-5. Microfocus has defined COMP-5 as platform native binary. For this reason, avoid COMP-5 to be platform independent. 3gm's discussion on platform independence is right-on.

 

[Truusvlugindewind]

In the original question a piece of coding was included with the question "correct or not".

I'd say: No, not correct. COMP-4 means integer so no "V" (assumed decimal position) may not be part of the PICTURE clause.

Comp-3 in a Micro Focus environment is only usefull when you want to efficient memory usage.
E.g:

01  pretty-big-array occurs 10000 indexed by whatever-idx.
    03 whatever-amount pic S9(9)V9(2) usage display.
    03 whatever-percent pic 9(2)v9(1) usage display.

This array occupies a lot of RAM.
Changing the

 usage display

into

comp-3

will divide the memory consumption by 2, but calculations will not be efficient (yes very efficient on mainframes, but no Micro Focurs there).

When you want best of both worlds you could code:

01  pretty-big-array occurs 10000 indexed by whatever-idx.
    03 whatever-amount-in-cents pic S9(11) comp-5.
    03 whatever-promille        pic  9(04) comp-5.

promille english? don't know. hope you understand what I mean

But now you must change your compute's. You gain on speed and memory usage, but you loose the easy and intuitive way you can calculate in cobol.

I am learning JAVA now and I am suprised that the easy way in which cobol can cope with all kinds of numeric data and "tricks" with redefines and so on are not part of this new language. Never realized how "easy & relaxed" cobol really is!

 

[mfcobol2002]

THANKS

 

[webrabbit]

In Microfocus COBOL, COMP-3 is faster than display, COMP and COMP-4 are still faster and COMP-5 is faster yet.

In all versions of COBOL, fractional numbers, except for COMP-1 and COMP-2, are processed as "fixed point" (an old FORTRAN term). This means that they are processed internally as integers and the compiler keeps track of the decimal point. Non-integers are always valid in COBOL (except for some wierd variations such as COMP-0 and COMP-X). This is because COBOL is not permitted to have rounding errors. It is a Business Oriented Lanquage.

 

[Truusvlugindewind]

I've just tried it Webrabbit, and you're right.
Stupid of me to assume that COMP-5 must always be an integer.

 

[mfcobol2002]

respected friends,
after you helped me to assist better COMP-3 and COMP4 I received that email of the Support of Microfocus.See their answer:

-----------------------------
Hi, Marcos
The decision is really depends upon what you are going to do with the data. On all platforms, using COMP-5 is the most efficient
from an execution standpoint. All arithmetic functions are done in COMP-5 format. This means that, if you have your data defined
as non-COMP-5 data, the data in those fields are converted to COMP-5 data prior to any of the arithmetic functions being performed
and then the result is converted back from COMP-5 to the result field's definition type. As you can expect, those field format
conversions will add additional time to the execution of an application, with the effect felt most with those that are heavy with
arithmetic functions.

However, execution efficiency is only one aspect. If the data is to be used in interfacing with other languages or packages, then you
will obviously need to carry that data in a format appropriate for the interface to those. Yes, you could still carry all internal data in
COMP-5 and move the data needed for the interfacing to the appropriate format field types before calling the other language or
package. Depending upon the application, that may or may not be the more efficient way to do so and you need to make the
decision based upon the individual situation.

In terms of being platform independent, usage of COMP-5 is still indicated and does not impair the platform independence other than
for the initial conversion of data (as the physical format of the data can vary from one platform to another). So, that is more of an
installation consideration vs a long term application efficiency issue.

I hope this answers your question. If not, if you can restate your specific issue, that would help.

Regards,

 

[webrabbit]

What the vendor is saying is that COMP-5 is always the most effecient format for data that is strictly internal to the program, such as subscripts and line counters. Other cases are platform or application dependant.