Slack bytes

Support for OS/VS COBOL, VS COBOL II, COBOL for OS/390 & VM and Enterprise COBOL for z/OS

Slack bytes

Postby thangaraaj555 » Thu Oct 13, 2011 12:29 pm


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?

Posts: 10
Joined: Thu Oct 13, 2011 12:17 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Slack bytes


Re: Slack bytes

Postby enrico-sorichetti » Thu Oct 13, 2011 1:25 pm

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
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort
Global moderator
Posts: 2490
Joined: Fri Apr 18, 2008 11:25 pm
Has thanked: 0 time
Been thanked: 119 times

Re: Slack bytes

Postby BillyBoyo » Thu Oct 13, 2011 1:31 pm

"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.
Global moderator
Posts: 3732
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 254 times

Re: Slack bytes

Postby Robert Sample » Thu Oct 13, 2011 4:43 pm

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.
Robert Sample
Global moderator
Posts: 3094
Joined: Sat Dec 19, 2009 8:32 pm
Location: Bellevue, Iowa
Has thanked: 1 time
Been thanked: 176 times

Re: Slack bytes

Postby dick scherrer » Thu Oct 13, 2011 10:05 pm


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. . .
Hope this helps,
User avatar
dick scherrer
Global moderator
Posts: 6308
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 90 times

Re: Slack bytes

Postby steve-myers » Thu Oct 13, 2011 10:53 pm

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.
Global moderator
Posts: 1772
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 167 times

Return to IBM Cobol


  • Related topics
    Last post