Padding amount incorrect in mcs_echo_neg.incl.pl1

[charles.unix.pro@…]

mcs_echo_neg.incl.pl1 contains the declaration of echo_neg_data:

dcl 1 echo_neg_data based (echo_neg_datap) aligned,

/* Echo negotiation data */

2 version fixed bin,
2 break (0:255) bit (1) unaligned,

/* Break table, 1 = break */

2 pad bit (7) unaligned,
2 rubout_trigger_chars (2) unaligned, /* Characters that cause rubout action */

3 char char (1) unaligned,

2 rubout_sequence_length

fixed bin (4) unsigned unaligned,

/* Length of rubout sequence, output */

2 rubout_pad_count fixed bin (4) unsigned unaligned,

/* Count of pads needed */

2 buffer_rubouts bit (1) unaligned, /* 1 = put rubouts and rubbed out in buffer */
2 rubout_sequence char (12) unaligned; /* Actual rubout sequence */

'version' is at offset 0.

'break' starts at bit 0 of word 1 and extends to bit 3 of offset 8. (256 bits is 7 words plus 4 bits).

'pad bit (7)' starts at offset 8, bit 4 and extends to bit 10.

rubout_trigger_chars is data type char, so the compiler forces alignment to the next char boundary at bit 18.

The 'pad bit(7)' is harmless but misleading. Looking at the version 1 of the structure, we see that 'break' was resized but pad was not adjusted to compensate.

'pad' should be declared 'pad bit (14)' to correctly describe the actual layout generated by the compiler.