Typo in _imft_std_commands.incl.pl1

[anonymous]

'_imft_std_commands.incl.pl1' contains:

/* Standard command/reply types */

dcl (IMFT_DATA initial (0), /* data record */

IMFT_SYNC1 initial (1), /* first half of synchronization sequence */
IMFT_SYNC2 initial (2), /* second half of synchronization sequence */
IMFT_ABORT initial (3), /* abort the current operation */
IMFT_LOGOUT initial (4), /* one side requests that the other logout */
IMFT_RESYNCHRONIZE initial (5), /* reply requesting resynchronization */
IMFT_AIM1 initial (6), /* first half of establsihing AIM ceiling */
IMFT_AIM2 initial (7)) /* second half of establishing AIM ceiling */

fixed binary (7) unaligned unsigned static options (constant);

I don't think the "fixed binary (7)" is correct.

Typical usage is:

if imft_logical_record.type ^{= IMFT_DATA}

where 'type' is declared:

3 type fixed bin, /* types are defined in _imft_std_commands.incl.pl1 */

It seems to me that 'fixed binary (7)' should be 'fixed binary'

[Gary Dixon]

I am why the data attributes of these "Standard command/reply types" were chosen as being unsigned fixed binary(7,0). However, there is no reason why such values cannot be assigned to an imft_logical_record.type field declared as shown below:

declare 1 imft_logical_record aligned based (ilr_ptr),
        2 header,
          3 version char (8),
          3 type fixed bin,                                 /* types are defined in _imft_std_commands.incl.pl1 */
          3 length fixed bin (21),                          /* in characters */
          3 flags,
            4 binary bit (1) unaligned,                     /* ON => record contains characters with 9th bit on */
            4 eight_bit bit (1) unaligned,                  /* ON => record contains characters with 8th bit on */
            4 pad bit (34) unaligned,
        2 contents character (imft_logical_record_length refer (imft_logical_record.length));

The PL/I Language Specification manual (AG94-02) section 8.2.10 describes the rules for Arithmetic Type, Base, and Precision Conversion. For assignment of a fixed bin(7) unsigned unaligned value to a fixed bin(17) aligned signed target, the precision of the source is automatically adjusted to that of the target without error or warning.

I could guess that at one point the alignment of fields in an imft_logical_record were in a more compact unaligned form, with .type being a fixed bin(7) unaligned unsigned .type value, there is no problem in assigning these constants to the existing imft_logical_record.type field.

I therefore recommend closing this ticket as "won't fix".