Programming Release Notes
5.21 HP BLISS Compiler Warnings with RMS Structures (Integrity servers Only)
In addition, if any of these allocations is included in a PSECT that contains
an explicit alignment that is in conflict with ALIGN(3) (that is, is lower than
ALIGN(3)), the BLISS compiler issues an ‘‘align request negative or exceeds that
of psect’’ warning. For example, the warning would be issued for the following
declaration:
PSECT OWN = $OWN$ (..., ALIGN(2), ...)
OWN
FAB = $FAB_DECL, ...
If warnings on PSECT alignment are seen when recompiling a BLISS application,
the correction is to increase the alignment of the PSECT to ALIGN(3) (or higher).
In rare cases, applications may have assumptions on adjacency of data between
PSECTs. Those assumptions could be broken in making this change. Therefore,
check the code for such assumptions and make any necessary corrections.
While a number of OpenVMS utilities are written in BLISS, only a few warnings
were generated in a full OpenVMS build. Changes in OpenVMS to eliminate
warnings did not require other changes to correct assumptions. Based on this,
few user applications likely will require modification.
5.22 Potential Must-Be-Zero RMS Error: Making Room for New File
Options in the FAB
V8.3
There is very little remaining unassigned space in the RMS user file access block
(FAB). To allow for future growth in file-processing options implemented through
the FAB, the last unassigned bit in the file-processing options field in the
FAB
(FAB$L_FOP)
has been defined as the
FAB$V_EXTEND_FOP
option. This option will
be used in the future to request and validate assignments to two new FAB fields
that span previously unused bytes in the FAB:
•
FAB$W_FOPEXT
: The FOPEXT word field is reserved for the definition of new
file-processing options that might require implementation in the future.
•
FAB$W_RESERVED_MBZ
: The
RESERVED_MBZ
word field is being reserved for
future use. Its usage is currently open for future definition.
In a future release, when one or more new file-processing options are
implemented, the
FAB$V_EXTEND_FOP
bit will have to be set in the
FAB$L_FOP
field to take advantage of any new option in the
FOPEXT
field. However, when it is
set, it will also indicate that any undefined bits in the
FOPEXT
field are clear and
FAB$W_RESERVED_MBZ
contains a zero. If these conditions are not met when this
bit is set, a fatal error
(RMS-F-FOPEXTMBZ)
will be returned to the user for any
RMS file-level service.
The addition of the
EXTEND_FOP
option is fully upwardly compatible except if a
user sets this last bit in the
FAB$L_FOP
field by accident and either of these two
new FAB fields happens to be nonzero. Previously, RMS ignored this last bit in
the
FAB$L_FOP
field if it was set by accident.
If the
RMS-F-FOPEXTMBZ
error is returned, you must clear either the
EXTEND_FOP
option in the
FAB$L_FOP
field or the two new fields
(FAB$W_FOPEXT) and
FAB$W_RESERVED_MBZ
.
Programming Release Notes 5–17
