gtpm1m45 | TPF V4R1 Migration Guide: 3.1 to 4.1 |
All ECB-controlled (E-type) programs run in the ECB virtual memory
(EVM), which consists of private and shared storage. There is private
storage in two areas:
- The 1-MB ECB private area under 16 MB
- The 1-MB heap private area above 16 MB.
Private storage cannot be shared between ECBs. ECBs can share
storage in common blocks and other areas of the EVM. Shared storage
consists of common blocks and the remainder of of the EVM that maps directly
to the virtual memory of an I-stream (also known as system virtual memory
(SVM)). See Figure 6 for more information.
In the TPF 4.1 system, all programs are 4 KB in size. ECBs
are now 12 KB and are comprised of three sections:
- The user portion, page 1, which is mapped by EB0EB
- The protected system portion, page 2, which is mapped by IEQCE2
- The unprotected system or trace portion, page 3, which is mapped by
IEQCE3.
There are significant changes to the allocation of E-type programs,
which are described in Allocating Programs, Transfer Vectors, and Pools. These changes include specifying 24- or 31-bit
operating mode, authorization privileges, and residency. Any
application programs that access the system tables, which have moved above the
16 MB, must be allocated to run in 31-bit mode. If you issue a MODEC
macro to
switch to 24-bit mode from one of these programs, you will get unpredictable
results. All IBM C language programs must be allocated in 31-bit
mode.
Other changes that you need to be aware of include:
- All E-type programs provided with the TPF 4.1 system are
reentrant. Your E-type programs can remain non-reentrant or you
can change them to reentrant programs.
- There are no corefast programs. Corefast and coreslow storage are
no longer supported with the TPF 4.1 system.
- You cannot manipulate the program demand counter;
use the GETPC and RELPC macros to lock or unlock programs in storage.
Locking is discouraged.
- The first 24 bytes of the BEGIN macro header, which were stripped at load
time in the TPF 3.1 system, are no longer supported. The 8-byte
program header still exits, and consists of a 2-byte record ID of
X'00FF', 2-byte program length, and 4-byte program name.
Therefore, there is no longer a X'18' displacement between object code
and listings. If you are subtracting this displacement in your
application programs to calculate addresses, your code will be incorrect for
reassembled programs.
- If you have programs that get the file address of a program record or a
data record from either an ENTxC expansion or from the
Enter/Back V-type constants (VCONs), this will no longer work.
Use the GETPC macro with the FILE parameter to retrieve this information from
the program allocation table (PAT).
- If you have code that gets address attributes directly from addresses,
you should replace this code with SONIC calls.
- Application programs should not issue instructions that use real
addresses, such as Set Storage Key Extended (SSKE).
However, if you have applications programs that use real addresses, modify
them to issue a Load Real Address (LRA) command prior to the command
that uses the real address.
- Note:
- This instruction requires supervisor state, which in turn requires
authorization.
- If you have programs that issue a VM Diagnose, then you must change them
to use real addresses for the Diagnose parameters. You should use the
Load Real Address (LRA) instruction to obtain the real address.
- In the TPF 4.1 system, it is possible to modify some of the system
generation bits online with the ZSYSG commnd. If you code a Conditional
Branch (AIF) instruction to test the bit setting you will get the value at
assembly time, which will be incorrect if the value was changed online by
using the ZSYSG command. Use the SYSTC macro to get the current setting
of the bit.
- You can no longer use the CROSC macro to get pools from another
subsystem.
You must change your database index (DBI) using the CEBIC macro, get a pool
using the GETFC macro, and subsequently return to your DBI.
- Calls to certain critical TPF system services are implemented using the
Monitor Call instruction, which generates a program check. The branch
trace function generates frequent program checks. Therefore, during
application program development under VM, you can no longer use TR
PROG, you must specify a range as in:
TR PROG 1-15
- The functions of the REHKA and UNHKA macros changed in the TPF 4.1
system. Therefore, you should consider researching the different uses
of the REHKA and UNHKA macros before migrating your application programs
because these types of functions (hook and unhook) are no longer supported in
the TPF 4.1 system.
Despite all these changes, many application programs that do not share data
and are reentrant can be used in the TPF 4.1 system without
change.
The following sections describe:
- How to manage private and shared storage
- Which macros require authorization privileges
- Changes to application utilities.