Revision/Update Information: This is a new manual.

Operating System and Version: OpenVMS VAX Version 5.5
and higher

Software Version: Kednos PL/I V3.8 for OpenVMS VAX

Published by: Kednos Corporation, Pebble Beach, CA, www.Kednos.com

Kednos Corporation, makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description.

Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Kednos Corporation iauthorized only pursuant to a valid written license from Kednos Corporation or an anthorized sublicensor.

No responsibility is assumed for the use or reliability of software on equipment that is not listed as supported in the Product Description.

Copyright Kednos Corporation, 1980, 1983, 1985, 1987, 1992, 1993, 1995, 1996, 2003. All rights reserved.

Copyright ©2003

The following are trademarks of Hewlett Packard Company: Alpha, AXP, DEC, DECnet, DECtalk, DECUS, Digital, IVP, MicroVAX, OpenVMS, RMS, RMS--11, RX50, TK50, VAX, VAX Ada, VAX BASIC, VAX BLISS, VMScluster, CDD Repository, VAX COBOL, VAX DATATRIEVE, VAX DIBOL, VAX DOCUMENT, VAX FORTRAN, VAXinfo, VAX MACRO, VAX Pascal, VAX SCAN, VAXset, VAXTPU, and the DIGITAL logo.

This document contains release information on Kednos PL/I Version 3.8 for OpenVMS VAX Systems. Release information is necessary for gaining the best results from Kednos PL/I Version 3.8 on the OpenVMS VAX operating system. Kednos recommends that all users read this information. Kednos also recommends that all users review the section of this manual entitled "Known Errors and Restrictions" before submitting an SPR.

1 Overview of Changes Made in V3.8 and Runtime Library V5.7 (October 24, 2003)

• The product name has been changed to Kednos PL/I for OpenVMS VAX.
• This release fixes a problem wherein the the PLI_FILE_DISPLAY structure was filled in by the DISPLAY routine in a different pattern than that defined by the pli_file_display include file.
  To guard against certain mismatches, the GSMATCH version for Runtime Library V5.7 has its minor version changed, so new compilations with PLI V3.8 should be linked against Runtime Library V5.7 and run only on systems that have Runtime Library V5.7 installed.
  This problem was present in V3.7.

VAX PL/I V3.7 contains the following enhancements and fixes:

• This release fixes a problem wherein the promotion of a picture scalar to an aggregrate through an assignment, resulted in a compiler bug check during code generation. This problem, although only recently detected is present in versions 3.5, 3.6 and 3.7.

VAX PL/I V3.7 and Runtime Library V5.6 contain the following enhancements and fixes:

• The runtime is no longer distributed with VMS and is at revision level 5.6.
• There were several issues with picture data types which have been resolved. Presently the only known issue is a problem with *-extents in which a stack overflow can occur if the procedure containing the *-extent is successively called a large number of times.

VAX PL/I V3.5 contains the following enhancements and fixes:

4.1 LMF SUPPORT

VAX PL/I V3.5 contains support of the License Management Facility (LMF). When VAX PL/I V3.5 is invoked, it checks to see whether it is licensed on the machine. If a valid license exists, the compilation continues. If a valid license does not exist, an error message is printed and the compilation is aborted. For example,

$ PLI TEST %LICENSE-F-NOAUTH, VAX PLI use is not authorized on this node -LICENSE-F-NOLICENSE, no license is active for this software product -LICENSE-I-SYSMGR, please see your system manager

Please refer to the VAX/VMS License Management Facility manual for more information.

4.2 BUG FIXES

The following list summarizes the major bugs that have been fixed between PL/I V3.3 and PL/I V3.5.

4.2.1 Compiler

4.2.1.1 SCA Support -

• A structure declaration with unusual numbering of the fields could cause a compiler bugcheck when the /ANALYSIS_DATA qualifier was specified. This problem has been fixed. The following declaration is an example of the type of declaration that would cause a problem.

  DECLARE 1 S, 3 F1 attr, 2 F2 attr;

• The ANA file did not always contain full information about user defined PSECTs when the /SHOW=MAP qualifier was specified. This problem has been fixed so that all relevant PSECT information is produced.

• If a structure declaration contains an error that results in an E level error and the /DEBUG qualifier was specified, then the compiler would often produce the fatal "%PLIG-F-COMPILERR, Previous errors prevent continued compilation." error. This problem has been fixed so that the fatal error is usually not produced.
• The source correlation for SELECT statements has been improved so that PCA produces better results with the SELECT(expression) form of the statement.

• Under certain circumstances, the compiler could get into an infinite loop when attempting to perform inline expansion of a procedure containing a SELECT statement. This problem has been fixed.
• Bad code could be generated if an inlined procedure called a function that returned a CHAR(*) or CHAR(*) VAR result. References to local automatic variables could be made using the wrong stack offset. This problem has been fixed.
• Bad code could be generated if a procedure that makes an uplevel reference to a variable is inlined into a procedure that did not previously make any uplevel references. This problem has been fixed.
• If a block contains an automatic variable whose size is not known until run time, and the block is inlined, then the compiler would sometimes incorrectly use SP in references to local variables. This problem has been fixed so that the references are made using the FP register.
• If some optimization phases were suppressed using the /OPT=NOxxx qualifier but procedure inlining was being performed, it was possible for the call to a procedure to remain even though the procedure was inlined. This has been fixed so that if a procedure call is inlined, then the call instruction is not generated.

• When a field in a structure contained the OFFSET datatype and an array dimension with the REFER attribute, then the compiler would allocate an incorrect number of bytes in an ALLOCATE statement. This problem has been fixed so that the proper amount of storage is allocated.
• In V3.3, references to multipositional parameters passed by value were treated as though the parameter was passed by reference. This problem has been fixed. A multipositional parameter is a parameter that appears in different locations in the parameter lists of multi-entry point procedures.
• Bad code was sometimes generated for a program that contained sufficiently complex nested blocks and loops. The optimizer in the PL/I compiler contained an error in the code that moves invariant expressions out of loops. This problem has been fixed.
• If the first parameter to the SUBSTR function was a string with a length not known before run time (such as the result of the TRIM function), then the compiler would sometimes lose track of the VARYING attribute of the parameter. The two byte length field of the parameter would then be treated as two characters in the string. This problem has been fixed.
• When a CHAR(*) parameter was used with the concatentation operation, the wrong string length would sometimes be used, resulting in some characters at the end of the destination not being set correctly. This problem has been fixed.
• The size of structures which contain bitfield members declared with the refer option is now computed correctly. Previously the structure size was calculated incorrectly because the size of bitfield members was computed from bits to bytes twice.
• Under certain conditions the VAX PL/I compiler would bugcheck when compiling source programs with combinations of blanks and tabulation characters at the end of a source line. This has been corrected.
• In order to shrink the size of object files, the compiler was modified to output weak global symbols only when a program is compiled /debug. If this causes applications that expect weak global symbols to be output all the time to break, the work-around is to compile /debug.
• The compiler now correctly handles the %replace statement when compiling with /ANALYSIS_DATA. Previously when a replaced variable was used in a preprocessor defined function the compiler bug checked.
• The compiler now correctly reports conflicting attributes between structure members and the level 1 parent structure. For example if the level 1 symbol was declared with the GLOBALREF attribute and a member was given the INITIAL attribute (these two are not allowed together), the compiler would not report this as conflicting attributes.
• Unaligned static bit arrays are now initialized properly. Unaligned static bit arrays of 9-15 bits were not correctly initialized if the elements of the array had exactly 8 bits (1 byte) worth of data left to initialize.
• Fixed binary to fixed binary conversions and float binary to float binary conversions now work correctly. In the past the compiler would incorrectly eliminate these conversions, before it checked to see if both elements had the same precision.
• All reported bugs aginst PLI$STARLET have been corrected.
• The compiler no longer bugchecks when compiling based structures that contain an array of fixed binary elements declared with the REFER option, and whose last member is an unaligned bit string. For example the compiler no longer crashes when compiling the following:

  dcl 1 tmp based, 2 tmp2 bit(10), 2 tmp1 fixed, 2 tmp3 (10 refer(tmp1)) fixed, 2 tmp4 fixed, 2 tmp5 bit(10);

• The compiler no longer allocates too much memory when ALLOCATE is used to allocate space for based structures that contain an array of unaligned bit strings declared with the REFER option. For example the following structure is now allocated correctly.

  dcl 1 tmp based, 2 tmp1 fixed, 2 tmp2 (4) bit ( 10 refer (tmp1)), 2 tmp3 fixed;

Since PLIRTL is normally distributed with the VMS operating system, the fixes below are listed by VMS version.

4.2.2.1 VMS V5.0 -

1. The proper output is now produced by the Bn format of the PUT EDIT statement for bit strings longer than 128 bits and for fixed binary expressions with a non-zero scale factor.
2. The VIRMEMDEAL error will no longer be incorrectly raised when all the following conditions are true: a file with fixed length records is being closed, the file was read using the SET option of the READ statement, and an ENVIRONMENT option was specified on the CLOSE statement.
3. The ONCODE function will no longer ACCVIO when called from inside an ON-unit that was entered due to a hardware error such as overflow.
4. The INDEX function has been fixed so that the proper result is returned when searching for a pattern that is longer than 32 bits. Previously, the wrong result was sometimes returned for certain complex cases.

1. Certain G and H floating values were improperly truncated when they were converted to either a fixed decimal or pictured datatype. Improved conversion routines are now used to minimize the truncation errors. Even if the /G_FLOAT qualifier is not specified and there are no floating point variables large enough to require H float, the V3.n compiler can generate code that uses H floating data when intermediate calculations require the extra precision.

1. The COL and DCOL key types are now supported as datatypes for keys in indexed files. This allows PL/I programs to read indexed files containing keys with user-defined collating sequences. You can use the National Character Set utility to create these collating sequences.
2. When converting from PICTURE to a FIXED or FLOAT datatype, the pictured value is first converted to an intermediate FIXED DECIMAL value with the same precision and scale as the PICTURE variable. This intermediate value is then converted to the desired FIXED or FLOAT datatype. Previously the picture value was converted to a FIXED DECIMAL (31,0) intermediate value, which resulted in the loss of all fractional digits.
3. It is now possible to specify a boolean value with the record-locking options of the READ statement. The format for the options is NOLOCK(boolean), LOCK_ON_READ(boolean), LOCK_ON_WRITE(boolean), MANUAL_UNLOCKING(boolean), NONEXISTENT_ RECORD(boolean), READ_REGARDLESS(boolean), and WAIT_FOR_RECORD(boolean), where boolean is a BIT(1) expression. Either a constant or a run-time variable expression is acceptable. The record-locking option is either enabled or disabled for the duration of the READ statement. For example:

   DECLARE BOOL BIT(1) ALIGNED; READ FILE(F) INTO(BUFF) OPTIONS(NOLOCK(BOOL), LOCK_ON_READ(^BOOL));

4. The correct status RMS$_BUSY is now returned when you attempt to start a new I/O operation while another operation is in progress. Previously, the RMS status from an earlier I/O operation was returned rather than RMS$_BUSY.
5. When a file is implicitly opened in response to an I/O request, the RTL now uses the declared file attributes rather than the default file attributes. This helps avoid conflicts between declared and default attributes. For example, the following READ statement now implicitly opens the file REL1 with the UPDATE attribute rather than the default attribute INPUT.

   DCL REL1 FILE KEYED DIRECT UPDATE; READ FILE(REL1) INTO(INREC) KEY(PART0);

6. The ENCODE built-in function has been fixed to return the string "0" when the first parameter to ENCODE is 0. Previously the null string was returned.

1. The VAX PL/I RTL now clears the active bit before signaling an area full condition. This allows an on-unit written to handle an AREA condition to copy the full area to a new area and free the full area.
2. The condition ONFILE was modified to return the file handle for record operations.
3. The maximum record size was changed from 16383 to 31998, which is maximum allowed by RMS.
4. VAX FORTRAN procedures can now call VAX PL/I with the correct results.
5. The error signaled when a PL/I internal FAB or RAB condition occurs is now set up correctly.
6. Previously an operation subsequent to a read statement with the option manual unlocking would release the lock on a record. This no longer occurs. Now to unlock the record you must call free or release the record.

4.3.1 Inline Expansion Of Procedure Calls

VAX PL/I V3.4 introduces support for the Program Design Facility (PDF). Used with LSE and SCA, this new capability provides an integrated software development environment that includes the low-level design phase of the software development life cycle. During the design phase, VAX PL/I can be your Program Design Language (PDL). In the VMS environment, you create detailed designs as follows:

• Using VAX PL/I or another traditional programming language
• Embedding design information in comments
• Writing algorithms with pseudocode and regular placeholders

VAX PL/I V3.4 provides an enhancement to the DECwindows FileView "Compile" verb in which compile command options can be selected using a window interface instead of the usual DCL qualifiers. The compiler defaults are used as the initial configuration; new configurations with different settings of options can be given names, saved, and used for later compilations. The new interface is used automatically when you use the FileView "Compile" verb to compile a source file that has a file type of ".PLI". More information is available by using the Help menu in the "Compile a VAX PL/I Program" dialog box. The DECwindows Compiler Interface (DWCI) for VAX PL/I is entirely separate from the compiler image and is contained in the following files:

SYS$COMMON:[VUE$LIBRARY.USER]PLI$DWCI.EXE SYS$COMMON:[VUE$LIBRARY.USER]PLI$DWCI.UID SYS$COMMON:[SYSHLP]PLI$DWCI.HLB

4.3.4 PL/I V3.5 TYPE

The TYPE attribute is a superset of the LIKE attribute. The TYPE attribute applies to DECLARE, PROCEDURE, and ENTRY statements. When used in a DECLARE statement, it allows the variable being declared (or typed variable) to inherit the attributes of a previously declared variable (type definition). Similarly, when the TYPE attribute is used in the RETURNS option of a PROCEDURE or ENTRY statement, the attributes of the return value will be the same as the attributes of the type definition. The type definition must be explicitly declared before it can be used in a DECLARE, PROCEDURE, OR ENTRY statement.

Please refer to the PL/I documentation for more information on the type attribute.

4.3.5 PL/I V3.5 OTHERWISE

The OTHERWISE Option applies to the GOTO (or GO TO) statement. This statement has the following syntax:

({[GOTO] [GO TO]} label-reference [OTHERWISE])

The OTHERWISE option can be present only when the label-reference is a subscripted label with a variable subscript. If present in any other case, it will be reported as an error. If the OTHERWISE clause is used the label subscript cannot be a multi-term expression. If the variable subscript is out of range and the OTHERWISE option is not present, the statement following the GOTO (or GO TO) will be executed next. If the variable subscript is out of range and the OTHERWISE option is not specified, the subscript is reported out of range at run-time and the process will be terminated. In addition to the above syntax a default label for the label array has been added. If used the default label must be the last label in the GOTO case. The syntax of the default label is:

label (*):

The following is a code example of this case.

goto case (k) case(1): . . . goto end_case case(3): . . . goto end_case case(*): /* default case */ . . . goto end_case end_case:

Please refer to the PL/I documentation for more information on OTHERWISE.