IBM Mainframe Forum

Hi,

I have heard slack bytes do affect the performance of the cobol program!

and it comes when we use comp variable. and it can be solved by using comp sync..

But I have also heard we can avoid these slack bytes by defining the working-storage variables in some order..

I don know that order! if that is true, please comment on what is that order?

Thanks

the slack bytes were needed on older machines where the operand had to be aligned to the proper boundaries
a LOAD register required that the address of the four bytes of data be aligned to a fullword ( multiple of 4 bytes )
the constraint was relieved later on but operation on unaligned operands would cost a few more cycles

the slack bytes do not cause any performance penalty, they just use a few more bytes of storage

"Slack Bytes" do not affect performance in any way. They are bytes of storage which are not used, due to the "alignment" that Cobol carries out in data definitions.

For 77-levels, no alignment is done. The storage for one 77 immediately follows the storage for another.

For 01-levels, each starts on a "double-word bounday", meaning that the minimum number of bytes occupied by an 01 is eight (length of a double-word). If you have an 01 with just PIC X(1), then there will be seven "slack bytes" after it before the next 01. If your 01 is eight bytes long, there will be no slack bytes and the next 01 will start immediately after the it. There may also be slack bytes between the end of the 77's and the first 01, basically 1/8 of the time there won't be.

Using 77's saves space (bytes) but these days not necessary given the amount of storage available on modern mainframes.

SYNC can also generate slack bytes. SYNC causes a binary field to be aligned on a "word boundary". Thus if a COMP field is not on a word boundary, the compiler will generate some slack bytes (up to three) to make sure it is on a word boundary, if SYNC is specified for the field.

I believe it used to make a performance difference, but I'm not sure it does these days.

If you make all your COMPs 01's anyway, they will be alighned on a boundary without having to specify SYNC. If you have binary in a record-layout and you specify SYNC your record will have to extend if there are any slack bytes which have to be generated.

Unless you absolutely have to use it (dynamic sql?) I'd not use it. Never used SYNC myself, never noticed any problems.

You could do a test. Prog1 with 77 COMP PIC S9(4), 2 with 01 COMP PIC S9(4), 3 with 01 but PIC X for 05 before 05 COMP PIC S9(4) and prog 4 with same arrangement as Prog 3 but specifying SYNC, Prog 5 with the 77 specifying SYNC.

Each program has a loop which runs 10,000,000 times, just adding one to the field.

Run each. Look at CPU usage for each. If negligble CPU, increase the number of times the loop is done, or do the ADD multiple times. When you get some noticeable CPU, compare amongst the five programs.

Let us know the results. I suspect there will be no/not much difference.
Then you won't have "heard", you'll have done it yourself.

I have heard slack bytes do affect the performance of the cobol program!

Do not listen any further to whoever told you this, as that person has absolutely NO knowledge of COBOL, nor of mainframes, and ANYTHING said has a high probability of being rwrong.

Hello,

I have heard slack bytes do affect the performance of the cobol program!

Suggest you no longer use this source of "information" - whether a person or something you found on the internet.

No telling how many other "things" are incorrectly known there. . .

The original System/360 required binary data to have a specific alignment in storage. Most (but not all) of this alignment requirement was eliminated in System/370 and in subsequent iterations of the hardware specification, but with the often meaningless caveat that unaligned data would cost extra CPU cycles to retrieve and store the data.

I'm basically an Assembler dinosaur (er, programmer) and we tend to obsess about these details, but only very rarely do they have a significant impact on program performance.

In other words, try to align data to the System/360 specification, but if it does not work out, particularly if the real data is in an I/O buffer and the start of the data record is unaligned, don't sweat it.