Migration Notes

The at sign (@) and number sign (#) characters are not allowed in identifiers; thus, you must change all identifiers that contain either of these characters.

You must explicitly declare all names (except internal procedure and label constants) There is no I through N rule that provides an implicit declaration of FIXED BINARY to undeclared names. In fact, the compiler defaults all undeclared names to FIXED BINARY and issues a warning message to that effect.

If the attribute FLOAT is specified and neither of the attributes BINARY or DECIMAL is specified with it, the compiler provides a default of BINARY. This should not present a problem; however, if a precision was specified under the assumption that the default floating-point base was DECIMAL, overflow conditions can result if you do not correct the declaration.

You cannot explicitly declare internal entry constants and subscripted label constants; these names are implicitly declared by their appearance. You must remove the declarations from the source file.

You must reprogram ON-units for unsupported conditions. For example, ON-units for SIZE, RECORD, and TRANSMIT should be modified so that they are invoked for the ERROR condition, which is the condition that is signaled for any of these errors.

You cannot specify the ALIGNED and UNALIGNED attributes for a structure in which string variables are to be aligned or unaligned. The attribute must be specified in the declaration of each variable that is to be aligned.

You cannot pass parameters directly to main procedures from the command stream. For examples of techniques for passing values or data to a main procedure, see the Endless PL/I for OpenVMS User Manual.

Changes in virtual memory requirements

The virtual memory requirements for Endless PL/I may be extensive according to the types of PL/I language constructs that you use. Processing the PUT and GET statements, BEGIN blocks and PROCEDURE blocks with the Endless PL/I V5.0 for OpenVMS Alpha compiler tends to require more virtual memory than the same operation would if you were using the Endless PL/I V3.9 for OpenVMS VAX compiler.

Heavy usage of these constructs in your programs may exhaust your user limits for virtual memory. The typical compiler errors that you receive are:

%PLIG-F-TEXT, Compiler abort - virtual memory limits exceeded.

%SYSTEM-F-ABORT, abort

%LIB-F-INSVIRMEM, insufficient virtual memory

You can recover by increasing your user page-file quota (PGFLQUOTA). See the Endless PL/I for OpenVMS Installation Guide or the appropriate OpenVMS Alpha system manual for more information on increasing your user page-file quota.

Changes in behavior for calls to bound procedures

With Endless PL/I, nested procedures can be called by other routines using the PL/I language's entry variable. However, in order to successfully reach these bound-procedure routines and ensure proper execution of uplevel referenced variables within the bound procedures, the user must keep the parent invocation of the bound procedure active.

This ensures that the stack references to uplevel variables are still valid.

The same situation exists with Endless PL/I V5.0 for OpenVMS Alpha. However, you may experience differences in behavior between Endless PL/I V3.9 for OpenVMS VAX and Endless PL/I V5.0 for OpenVMS Alpha if you do not keep the parent invocation active. This is because bound procedures are not created in the same way on the two compilers.

Endless PL/I V5.0 for OpenVMS Alpha creates the bound procedure values on the stack of the parent of the bound procedure. The compiler sends an access violation message or may exhibit other undefined behavior when the parent invocation of the bound procedure is not kept active. Because the parent's stack has been destroyed, the bound procedure code found on the parent's stack may also have been destroyed or corrupted, and the user may not be able to reach the bound procedure.

With Endless PL/I V3.9 for OpenVMS VAX you may receive the same undefined behavior. Cases may exist in which you are able to reach the bound procedure; however, you may still receive errors in results from the uplevel referenced variables within the bound procedure. This is because the bound procedure code on the parents stack may have been corrupted.

The following example shows behavior where the bound procedure entry6a cannot be reached by Endless PL/I V5.0 for OpenVMS Alpha, because the parent procedure, entry6, has exited and its stack is free to be recovered and used by other procedures. Therefore, the bound procedure code has been destroyed.

              program: proc options(main);

              program: proc options(main);
              dcl (ent2) entry variable;
              dcl fnc entry returns(entry) variable;
              dcl evar char (25) var init(' ');

                fnc=entry6;
                ent2=fnc();
                call destroy_stack();
                call ent2;

                put skip list('Evar is =>',evar);

                entry6: proc returns (entry);
                        return(entry6a);

                        entry6a: proc;
                                evar=evar||'entry6a*';
                                return;
                        end entry6a;
                end entry6;

                destroy_stack: proc;

                        /* Declare enough space to destroy previous
                         * stack values before this call.
                         */
                        dcl temp_space char(1000);

                        temp_space = 'hello';
                end;
              end program;

Note that this program also fails with Endless PL/I V3.9 for OpenVMS VAX. However, it fails after having reached the bound procedure entry6a and while trying to access the uplevel referenced variables from the parent, entry6.

Changes in behavior for overlapping static storage initialization

In both Endless PL/I V3.9 for OpenVMS VAX and Endless PL/I V5.0 for OpenVMS Alpha, overlapping initialization of static storage is not supported. When Endless PL/I V3.9 for OpenVMS VAX finds an overlapping static initialization, the compiler uses the value of the last found initialization as the value for the static variable.

In Endless PL/I V5.0 for OpenVMS Alpha, however, you cannot depend on the value of the last found initialization being assigned to the static variable. This behavior may affect the following user constructs:

Changes in behavior for the SUBSTR built-in function

In Endless PL/I V3.9 for OpenVMS VAX, the SUBSTR function is defined only when the position attribute (the integer expression that indicates the position of the first bit or character in the substring) is greater than or equal to 1.

Similarly, in Endless PL/I V5.0 for OpenVMS Alpha, the SUBSTR function is defined only when the position of the first bit or character is greater than or equal to 1. Therefore, if the position of the first bit or character to the SUBSTR built-in function is less than 1 (that is, the SUBSTR BIF is undefined), you may observe different results with Endless PL/I V5.0 for OpenVMS Alpha than with Endless PL/I V3.9 for OpenVMS VAX.

Changes in underflow detection behavior for Endless PL/I V5.0 for OpenVMS Alpha

The Endless PL/I V3.9 for OpenVMS VAX compiler outputs underflow detection code, the Endless PL/I V5.0 for OpenVMS Alpha compiler does not.

Changes for null statements and label behavior in Endless PL/I V5.0 for OpenVMS Alpha

Endless PL/I V3.9 for OpenVMS VAX does not compare the multiple labels of many succeeding combinations of labels and null statements so that they will have the same address. However, Endless PL/I V5.0 for OpenVMS Alpha optimizes these label-null statement sequences and compares the multiple labels so that they result in the same address. The following example shows this difference:

    X67:      PROC options(main);

    A:
    ; /* Null statement. */
    B:
    ; /* Null statement. */
    C:
    ; /* Null statement. */

    IF A=C THEN
         PUT LIST('NULL STATEMENT LABELS COMPARE EQUAL FOR Endless PL/I V5.0 for OpenVMS Alpha');
         ELSE
         PUT LIST('NULL STATEMENT LABELS COMPARE NOT EQUAL FOR Endless PL/I V3.9 for OpenVMS VAX');

    D:   IF C=D THEN
         PUT LIST('ERROR THESE LABELS SHOULD NEVER COMPARE EQUAL');
    END;

In Endless PL/I V5.0 for OpenVMS Alpha you can continue when a GOTO statement with the OTHERWISE option is used to go to an undefined label array element within a BEGIN-END block. Endless PL/I V3.9 for OpenVMS VAX does not support this function. The following example works with Endless PL/I V5.0 for OpenVMS Alpha but not Endless PL/I V3.9 for OpenVMS VAX:

                program: procedure options(main);

                            dcl i fixed binary(31,0);

                            begin;

                          i = 2;
                          goto part(i) otherwise;
                          put skip list('At continue !!');

                            end;

              part(1):

                end program;

Run-time exception handling is more consistent when processing formats of GET EDITs and PUT EDITs in Endless PL/I V5.0 for OpenVMS Alpha than it is in Endless PL/I V3.9 for OpenVMS VAX. If Endless PL/I V5.0 for OpenVMS Alpha encounters an exception when processing a format such as PLI$_INVFMTPARM, a signal is raised. If the exception is handled, then processing continues with the next format item regardless of the nature of the signal and the format item that was being processed when the exception was detected. This is not always the case with Endless PL/I V3.9 for OpenVMS VAX.

Nonlocal returns work properly under Endless PL/I V5.0 for OpenVMS Alpha. A nonlocal return is a RETURN statement that is lexically nested between any number of BEGIN/END pairs; for example:

              nested_proc : proc returns (fixed);
                  begin;
                      begin;
                          begin;
                              begin;
                                  begin;
                                      return (5);
                                  end;
                                  put skip list ('shouldnt be here 1');
                              end;
                              put skip list ('shouldnt be here 2');
                          end;
                          put skip list ('shouldnt be here 3');
                      end;
                      put skip list ('shouldnt be here 4');
                  end;
                  put skip list ('shouldnt be here 5');
              end;

              nested_proc2 : proc returns (float);
                  begin;
                      begin;
                          begin;
                              begin;
                                  begin;
                                      return (5.1);
                                  end;
                                  put skip list ('shouldnt be here 1');
                              end;
                              put skip list ('shouldnt be here 2');
                          end;
                          put skip list ('shouldnt be here 3');
                      end;
                      put skip list ('shouldnt be here 4');
                  end;
                  put skip list ('shouldnt be here 5');
              end;


              program: proc options(main);
                  dcl result1 fixed;
                  dcl result2 float;

                  result1 = nested_proc();
                  result2 = nested_proc2();

                  put skip list (result1);
                  put skip list (result2);
              end;

Two special considerations should be observed for nonlocal returns from OPTIONS(MAIN) procedures. First, an ON unit declared in the scope of one of the BEGIN/END pairs for FINISH will be given a chance to execute. Second, an ON unit declared in the scope of one of the BEGIN/END pairs for VAXCONDITION(ss$_unwind) will NOT be given a chance to execute with the previous construct.

When a program terminates abnormally due to an unhandled exception, Endless PL/I V5.0 for OpenVMS Alpha closes all open files before turning control over to the OpenVMS last-chance condition handler (the utility that prints the error and traceback).

This means that I/O that was being held in a buffer is allowed to reach its destination before the error dump appears on the screen. This is not the case with Endless PL/I V3.9 for OpenVMS VAX, in which I/O held in a buffer is not allowed to reach its destination before the error dump appears on the screen.

Differences in exception handling between OpenVMS Alpha and OpenVMS VAX

Because machine instructions on OpenVMS Alpha systems differ from those on OpenVMS VAX systems, any exception handler written to handle VAX hardware exceptions should be examined to ensure that it handles Alpha hardware exceptions similarly. For example, consider a case in which an exception handler has been written to handle an access violation. You may expect different behavior upon normal completion of the handler. In this case the handler should always perform a nonlocal GOTO to exit the handler so that program execution continues in a predictable way.

Fixed-decimal precision differences between Endless PL/I V5.0 for OpenVMS Alpha and Endless PL/I V3.9 for OpenVMS VAX

The precision specified for a PL/I fixed-decimal data type must be in the range of 1 to 31 for Endless PL/I V5.0 for OpenVMS Alpha. Endless PL/I V3.9 for OpenVMS VAX allows a fixed-point decimal variable to be declared with a precision of zero and also allows built-in functions to specify a fixed-decimal precision of zero. Endless PL/I V5.0 for OpenVMS Alpha does not allow zero to be used in either of these situations and issues an error "FIXDPRECZERO" when the precision specified for a fixed decimal is zero.

Differences in behavior between OpenVMS VAX and OpenVMS Alpha architectures regarding PL/I error conditions

In general, any PL/I operation that overflows on OpenVMS VAX systems will also overflow with Endless PL/I V5.0 for OpenVMS Alpha on OpenVMS Alpha systems. However, the Alpha hardware does not include support for packed decimal instructions that correspond to the PL/I fixed decimal data type; data items of this type are handled on OpenVMS Alpha systems through run-time calls, either to Endless PL/I V5.0 for OpenVMS Alpha run-time library routines or to system OTS routines. These emulation routines perform many operations to compute the result of a fixed decimal operation, which in most cases can be done with a single VAX instruction. Any one of these many emulation operations can and will generate an overflow.

Therefore, Endless PL/I V5.0 for OpenVMS Alpha can guarantee at least one overflow only on OpenVMS Alpha systems for every overflow on OpenVMS VAX systems per PL/I statement. Endless PL/I V5.0 for OpenVMS Alpha cannot guarantee that the resulting behavior or value produced by a PL/I statement that produces an overflow condition will be the same value or behavior as it was on Endless PL/I V3.9 for OpenVMS VAX.

The following PL/I example shows the difference in overflow detection between Endless PL/I V3.9 for OpenVMS VAX and Endless PL/I V5.0 for OpenVMS Alpha. This difference occurs when a PL/I fixed-decimal item with precision of 31 and scale factor of 21 [fixed decimal(31,21)] is converted to a PL/I fixed binary item with precision 31 and scale of 30 [fixed binary(31,30)]. On OpenVMS VAX systems this overflow situation results in two overflow conditions being raised. On OpenVMS Alpha systems this situation results in one overflow condition being raised.

Note that all Endless PL/I V3.9 for OpenVMS VAX cases of overflow are detected on OpenVMS Alpha systems here. However, in this case Endless PL/I V5.0 for OpenVMS Alpha detects one overflow for the two overflows reported by Endless PL/I V3.9 for OpenVMS VAX. This difference is due to a difference in the instruction set between OpenVMS VAX and OpenVMS Alpha systems and a further explanation is detailed below.

The selected program fragment contained here shows two examples of this situation. In each case the fixed-decimal item is converted to a fixed-binary item by a series of three steps.

The VAX macro instructions output by Endless PL/I V3.9 for OpenVMS VAX to perform this conversion are:

 23    1        fixb30 = fixd21;
A0 AD 1F C4 AD 1F 00000000* EF 0A 25    0125      mulp    #10,PLI$B_PAC_2_POWER_30,#31,-60(fp),#31,-96(fp)
       90 AD 1F 00 A0 AD 1F EB 8F F8    0132      ashp    #-21,#31,-96(fp),#0,#31,-112(fp)
          54 90 AD 1F 36    013C      cvtpl   #31,-112(fp),r4
             B0 AD 54 D0    0141      movl    r4,-80(fp)

In this example fragment, overflows are detected during the VAX mulp instruction which causes an overflow to occur and during the VAX cvtpl instruction. The OpenVMS Alpha instruction set does not contain decimal instructions, so the OpenVMS VAX decimal instructions are emulated by a series of OpenVMS Alpha instructions and OTS calls. During the instructions generated on by OpenVMS Alpha systems by Endless PL/I V5.0 for OpenVMS Alpha to emulate the OpenVMS VAX mulp instruction, an overflow is correctly detected. During the instructions to convert packed decimal to integer, an overflow is not detected, however.

Note that after a fixed-overflow condition has been raised, the value resulting from an operation that causes this condition is undefined. In this case, the value from the result of the multiply that caused an overflow is undefined. Therefore, when it is used in the expression no guarantee exists that an overflow will be raised again. This is what is happening when the result of the overflow is shifted right and then converted from decimal to integer. Therefore, in this case it is reasonable to expect a difference in the number of overflows detected from one PL/I statement.

Due to the difference in OpenVMS VAX and OpenVMS Alpha systems instructions, we can not prevent this situation from occurring. If you notice a situation during a conversion in which you receive one overflow on OpenVMS Alpha systems but two on OpenVMS VAX systems this is likely to be the reason.

In general, on a per-statement basis Endless PL/I V5.0 for OpenVMS Alpha can be expected to detect overflow, but the number of overflows detected per statement cannot be guaranteed to be the same on OpenVMS VAX and OpenVMS Alpha systems. The following complete example shows the difference:

              program: procedure options(main);

              dcl fixb30  fixed bin(31,30);
              dcl fixd18  fixed decimal(31,18);
              dcl fixd21  fixed decimal(31,21);
              dcl fixd22  fixed decimal(31,22);
              dcl fixd24  fixed decimal(31,24);

              on fixedoverflow begin;
                put skip list('fixed overflow occurred');
              end;

              fixd18 = 18.36;
              fixd22 = 22.40;

              fixd21 = fixd18+fixd22;
              fixb30 = fixd21;

              fixd18 = 18.42;
              fixd24 = 24.58;

              fixd21 = fixd24+fixd18;
              fixb30 = fixd21;

              end;

Arithmetic to character-string-use the CHARACTER built-in function.

Arithmetic to bit-string-use the BIT built-in function.^[1]

Bit-string to arithmetic-use the BINARY built-in function.

Bit-string to character string-use the CHARACTER built-in function.

Character-string to arithmetic-use the BINARY, DECIMAL, FIXED, or FLOAT built-in function, according to the target data type.

Character-string to bit string-use the BIT built-in function.