Data in the ECB private area cannot be shared with, or accessed by, another
ECB. To share data between ECBs, modify your application programs using
one of the following methods:
- Use common blocks.
First find the data to be shared. Then acquire a common block with the
GETCC COMMON=YES macro. The application program moves the data to
the common block and the original block is released. Once the data is
in a common block, everything that worked in the TPF 3.1 system still
works (such as unhooking blocks, hiding blocks, passing block addresses as
CRETC parameters, and so on).
Two new parameters were added to the GETCC macro.
- COMMON
- Gets common storage (instead of storage from frames)
- Note:
- The COMMON parameter is a restricted parameter that requires
authorization.
- FILL
- Used to initialize the core block.
There are two disadvantages when using common blocks:
- They are shared among all ECBs so that any ECB can corrupt this storage
- There are a limited number of common blocks in the TPF 4.1
system.
- Use the CRETC macro.
The new LEVEL parameter of the CRETC macro allows you to pass a block from the
ECB issuing the CRETC macro and attach it to CBRW level 0 of the ECB being
created. This works when you want to pass data from an ECB that already
exists to a new ECB.
- Note:
- The block itself is not actually moved. Instead, a copy is made of the
data in a block that becomes part of the private area of the new ECB.
The disadvantage of using the CRETC macro for this purpose is that unlike
common blocks, the two ECBs are not really sharing the same storage, so
two-way communication does not exist between the ECBs.
- Use the CREEC macro. This works the same way in the TPF 4.1
system as
it does in the TPF 3.1 system.
Like the CRETC macro,
the disadvantage of using the CREEC macro for this purpose is that the two
ECBs are not really sharing the same storage, so there is no two-way
communication between the ECBs.
- Rewrite portions of the application program to allow sharing of data
through find and file interfaces or through the EVENT facility. The
data being passed is protected when not in use and will reside in the private
area for a single ECB when in use.
The disadvantages of this method are that performance may suffer, and
converting to use system services can require more than a simple modification
to the existing code.
- Pass global area addresses. Global areas are common to all ECBs on
the same I-stream. Global area addresses can be passed between these
ECBs without translation problems. You can modify your application
programs to use global areas instead of working storage blocks for some
utility functions.
The disadvantage of using these global areas is that they are shared by all
ECBs on the I-stream, any one of which can corrupt the storage.