The Enterprise PL/I compiler supports the attributes INONLY, OUTONLY, and INOUT for the following reasons:

- You can make parameter declarations more self-documenting;
- You can tell the compiler more about what you know (always a good thing), and thereby allow it to produce better code.

For example, if a BYADDR parameter is INOUT and you specify a constant for that parameter, the compiler must generate code that copies that constant to a temporary and then passes the address of that temporary. But if a BYADDR parameter is INONLY and you specify a constant for that parameter, then the compiler can generate code that simply passes the address of that constant. The space for the temporary is not needed, and no code needs to be generated to copy the constant to that temporary.

Underlying this performance improvement is the assumption that INONLY also implies NONASSIGNABLE, but prior to version 6.1, this assumption was not enforced by the compiler.

Now with version 6.1, when you specify that a parameter has the INONLY attribute, the compiler will give it the NONASSIGNABLE attribute as well. This change will cause the compiler to issue an S-level message for all assignments to INONLY parameters (since they are now always assignments to a NONASSIGNABLE target).

You should heed this message: these assignments are potentially dangerous because they could quietly change a value in the constant area of your program. This could lead to bad problems. For example, consider these 2 small routines:

    A: proc;

      dcl X fixed bin(31);
      dcl B ext entry(fixed bin(31) byaddr inonly);

      call B(0);
      X = 0;
      . . .

    End A;

 
    B: proc(x);

      dcl x fixed bin(31) byaddr inonly;

      x = x + 1; 

    End B;

The assignment in routine B would change the constant 0 in routine A to the value 1. If the code for A was in read-only storage, this code would cause a protection exception. Otherwise, the intended assignment of 0 to X in this code would assign 1 to X, and that could lead to hard-to-resolve problems and even data-integrity issues.

This example is not meant to discourage you from using the INONLY attribute. Using the INONLY attribute is still a good idea, but it must be used correctly.