Use assembler listing

[Truusvlugindewind]

On the mainframe, an assembler listing can be included in the compiler-output.

It can be used to "educated guess" the impact of a choosen solution. You know: code a section like this, code anohter section like that, both with the same funcionaliy and count the number of assembler lines (= instructions more or less) to see wich is more efficient.

This way you can deal with nagging collegues "why can't I use a 'usage display' field for my subscript?"
Just code

add 1 to bad (i-usage-display)
add 1 to better (i-half-word-binay)
add 1 to best (i-indexed-by)

and see for yourself.

Nothing new, right? To force another open door:
The use of MOVE CORR is very often not allowed. That is so obvious that even I understand that.
But, during development, dealing with large structures...
why do not code:

move corr DCLGEN-level to OUTPUT-REC

and compile.

In that same assembler listing you'll get an overview off all the fields which get moved. Copy/Paste is your friend

Do not forget to take the MOVE CORR out before giving the source to production.

 

[3gm]

In the good ole days, one could tell how long an instruction took by looking at the Principle of Operations manual. It was useful to note that a single MVC or CLC, for instance, ran in an amount of time that was proportional to the Length of the operands. With the advent of new, more complex microcode, pipelining techniques, etc., instruction timing has become much more complex and difficult to predict.

An assembler listing can help in a general way, but be wary of simply counting instructions; you may make a bad inference.

Glenn

 

[webrabbit]

I never saw anything wrong with MOVE (or ADD, SUBTRACT, MULTIPLY, DIVIDE) CORRESPONDING except that it is so seldom usefun. Either the code must be specially contrived to have it do anything helpful, or you must code all groups without unique prefixes, which makes the coding of non-CORRESPONDING references combersome, with the field-name IN group-name format.

 

[slade]

Here's something Bill Klein put together. Everthing you wanted to know about numeric moves and then some:

***********************************************************************
Performance Comparison of COMP/COMP-3/DISPLAY Arithmetic
***********************************************************************
On the IBM mainframes, COMP is much faster than COMP-3 up through 9
digits. After 9 digits, COMP fields are processed with a subroutine,
which is very much slower." That is true when TRUNC(OPT) is used.
If, however, TRUNC(BIN) (for example) is used, the following is from
the Enterprise COBOL V3R1 "performance tuning" paper,"Comparing Data
Types" When selecting your data types, it is important to understand
the performance characteristics of them before you use them. Shown
below are some performance considerations of doing several ADDs and
SUBTRACTs on the various data types of the specified precision.

Performance considerations for comparing data types (using ARITH(COMPAT)):

Packed decimal (COMP-3) compared to binary (COMP or COMP-4) with TRUNC(STD)

using 1 to 9 digits: packed decimal is 30% to 60% slower than binary
using 10 to 17 digits: packed decimal is 55% to 65% faster than binary
using 18 digits: packed decimal is 74% faster than binary Packed

decimal (COMP-3) compared to binary (COMP or COMP-4) with TRUNC(OPT)

using 1 to 8 digits: packed decimal is 160% to 200% slower than binary
using 9 digits: packed decimal is 60% slower than binary
using 10 to 17 digits: packed decimal is 150 to 180% slower than binary
using 18 digits: packed decimal is 74% faster than binary Packed

decimal (COMP-3) compared to binary (COMP or COMP-4) with TRUNC(BIN) or COMP-5

using 1 to 8 digits: packed decimal is 130% to 200% slower than binary
using 9 digits: packed decimal is 85% slower than binary
using 10 to 18 digits: packed decimal is 88% faster than binary
using 1 to 6 digits: DISPLAY is 100% slower than packed decimal
using 7 to 16 digits: DISPLAY is 40% to 70% slower than packed decimal
using 17 to 18 digits: DISPLAY is 150 to 200% slower than packed decimal

DISPLAY compared to binary (COMP or COMP-4) with TRUNC(STD)

using 1 to 8 digits: DISPLAY is 150% slower than binary
using 9 digits: DISPLAY is 125% slower than binary
using 10 to 16 digits: DISPLAY is 20% faster than binary
using 17 digits: DISPLAY is 8% slower than binary
using 18 digits: DISPLAY is 25% faster than binary

DISPLAY compared to binary (COMP or COMP-4) with TRUNC(OPT)

using 1 to 8 digits: DISPLAY is 350% slower than binary
using 9 digits: DISPLAY is 225% slower than binary
using 10 to 16 digits: DISPLAY is 380% slower than binary
using 17 digits: DISPLAY is 580% slower than binary
using 18 digits: DISPLAY is 35% faster than binary

DISPLAY compared to binary (COMP or COMP-4) with TRUNC(BIN) or COMP-5

using 1 to 4 digits: DISPLAY is 400% to 440% slower than binary
using 5 to 9 digits: DISPLAY is 240% to 280% slower than binary
using 10 to 18 digits: DISPLAY is 70% to 80% faster than binary

Bill Klein

Regards, Jack.

"A problem well stated is a problem half solved" -- Charles F. Kettering