gtps2m28 | ACF/SNA Data Communications Reference |
The following information describes the NCB records and their related control block structures.
NCB records are processor-shared TPF/SNA records that contain information about the message queues for LU resources. The following types of NCB records exist in the TPF system:
Although there are two different types of NCB records, the content of these NCB records is the same.
The 381-byte fixed file NCB records are assigned to the LU resources that are defined using the offline ACF/SNA table generation (OSTG) program. One 381-byte fixed file NCB record is created and assigned to each LU resource when the OSTG resource definitions are loaded to the TPF system using the SNA fresh load or dynamic load function.
Each NCB record is assigned an ordinal number, which is the same across all of the processors in a loosely coupled TPF system.
The 381-byte long-term pool file NCB records are assigned to LU resources that are defined using dynamic LU support. These types of resources are referred to as dynamic LU resources.
As many as 8 different 381-byte long-term pool file NCB records can exist for each dynamic LU resource. This allows a dynamic LU resource to log on to different applications and maintain separate message queues. The address of each NCB record assigned to a dynamic LU resource is stored in an entry in the NCB directory records. Each NCB directory record entry contains 8 NCB slots (0-7), which are used to maintain the addresses of the NCB records for a dynamic LU resource. See NCB-Related Control Block Structures for more information about NCB directory records.
You can use the DEVTYPE parameter in the MSGRTA macro to define for each application in the TPF system the NCB slot that is used when a dynamic LU resource logs on to that application. For example, if you want dynamic LU resources that log on to the APPL application to use the NCB record whose address is stored in the last NCB slot in the NCB directory record entry (that is, NCB slot 7), you would specify the option for the DEVTYPE parameter in the MSGRTA macro that corresponds to the last NCB slot. A dynamic LU resource can use different NCB records when it logs on to different TPF applications or it can use the same NCB record for all of the TPF applications.
See TPF System Generation for more information about the MSGRTA macro.
Unlike 381-byte fixed file NCB records, 381-byte long-term pool file NCB records are not assigned to non-LU resources. These NCB records are assigned to only LU resources and only when sessions are started with those LU resources.
The following control block structures are used to organize and access the 381-byte long-term pool file NCB records that exist in the TPF system. These control block structures are located on file.
There are actually two types of NCB directory records defined in the TPF system; the current and staged NCB directory records. Specify the number of current and staged NCB directory records to define in the system initialization program (SIP) stage I deck when the TPF system is generated.
The TPF system uses the current NCB directory records to organize and access the 381-byte long-term pool file NCB records. The current NCB directory records are generically referred to as the NCB directory records.
The staged NCB directory records are used only by the NCB reorganization function to increase the number of NCB directory records in the TPF system.
Initially, the current NCB directory records have a record type of #NCBN4 and the staged NCB directory records have a record type of #NCBN5. Each time you perform the NCB reorganization function, these record types are swapped. That is, if the current NCB directory records have a record type of #NCBN4 before you start the NCB reorganization function, they will have a record type of #NCBN5 after the NCB reorganization function ends.
See Increasing the Number of NCB Directory Records in the TPF System for more information about the NCB reorganization function.
When a session is started with a new dynamic LU resource, the TPF system creates a 381-byte long-term pool file NCB record and an entry in the NCB directory records for that dynamic LU resource. The address of the NCB record is stored in the appropriate NCB slot in the NCB directory record entry. The NCB slot used depends on the application with which the dynamic LU resource is starting a session.
Entries are created in the NCB directory records for only dynamic LU resources. LU resources that were defined using the OSTG program are assigned 381-byte fixed file NCB records and, therefore, do not require an entry in the NCB directory records.
Figure 86 is a simplified example of the NCB directory records and how they are organized.
Figure 86. NCB Directory Record Example. The RVT1 delimiters are not included in this figure.
In Figure 86:
The NCB directory records do not contain entries for resources that were defined using the OSTG program because these resources use 381-byte fixed file NCB records.
The TPF system determines the ordinal number of the NCB directory record for a particular LU resource using the DHASHC macro, which is a hashing function that is based on the name of the LU resource. See TPF System Macros for more information about the DHASHC macro.
Enter the ZNNCB DISPLAY command to display information about a particular NCB record or the NCB directory records. See TPF Operations for more information about the ZNNCB DISPLAY command.
The TPF system initializes all of the 381-byte fixed file NCB records each time a fresh load is performed.
You can also use the NCB initialization function at any time to initialize the NCB records in the TPF system. This function initializes both the 381-byte fixed file NCB records and 381-byte long-term pool file NCB records.
Enter the ZNNCB command to start the NCB initialization function. See TPF Operations for more information about the ZNNCB command.
The TPF system creates 381-byte long-term pool file NCB records and NCB directory record entries for dynamic LU resources that start sessions with the TPF system. Periodically reclaim the NCB records and NCB directory records that are no longer in use. Otherwise, the TPF system can run out of resources and no new dynamic LU resources can start sessions with the TPF system.
You can use the NCB reconciliation function to reclaim the NCB records and NCB directory record entries that are no longer in use. This function returns to the TPF system the following resources:
See To Run the NCB Reconciliation Function for information about how to run the NCB reconciliation function.
After you run the NCB reconciliation function, the following information is displayed:
You can use this information to determine if you need to define more NCB directory records. For example, if the largest number of entries in an NCB directory record is approaching the maximum number of entries that can exist in an NCB directory record (which is 84 entries), increase the number of NCB directory records in the TPF system. See Increasing the Number of NCB Directory Records in the TPF System for more information about increasing the number of NCB directory records.
Use the following procedure to run the NCB reconciliation function and reclaim the unused NCB records and NCB directory record entries:
If the TPF system is not in NORM state, enter ZCYCL NORM to cycle the TPF system to NORM state.
If the NCB reorganization function is running, wait for it to be completed or end it before starting the NCB reconciliation function. See Increasing the Number of NCB Directory Records in the TPF System for more information about the NCB reorganization function.
If the NCB initialization function is running, wait for it to be completed before starting the NCB reconciliation function. See Initializing NCB Records for more information about the NCB initialization function.
The TPF system displays statistical information about the NCB directory records and NCB records when the NCB reconciliation function has been completed.
Once you start the NCB reconciliation function, you can end it at any time by entering the ZNNCB RECON command with the ABORT parameter.
If you are ending the NCB reconciliation function from a processor other than the processor where it was started, you must also specify the BP parameter for the ZNNCB REORG command.
See TPF Operations for more information about the following commands:
When the NCB directory records start to become full, run the NCB reconciliation function to return the unused NCB directory record entries to the TPF system. If most of the entries in the NCB directory records are being used and the NCB reconciliation function does not return many unused NCB directory record entries to the TPF system, increase the number of NCB directory records in the TPF system using the NCB reorganization function.
See Reclaiming NCB Directory Records and NCB Records for more information about the NCB reconciliation function.
The NCB reorganization function allows you to increase the number of NCB directory records in any TPF system state while the SNA network is active. The function is performed as follows:
Remember that after all of the entries are copied to the staged NCB directory records, there are fewer entries per record than there were in the current NCB directory records because more staged NCB directory records exist.
There are now more NCB directory records defined in the TPF system and the NCB reorganization function is completed.
For more information about how to run the NCB reorganization function, see To Run the NCB Reorganization Function.
You can enter the ZNNCB DISPLAY command with the ALL parameter to display the number of current and staged NCB directory records that are defined in the TPF system.
Use the following procedure to run the NCB reorganization function and create more NCB directory records:
If there are not enough staged NCB directory records defined, define more before continuing.
If the NCB reconciliation function is running, wait for it to be completed or end it before starting the NCB reorganization function. See Reclaiming NCB Directory Records and NCB Records for more information about the NCB reconciliation function.
If the NCB initialization function is running, wait for it to be completed before starting the NCB reorganization function. See Initializing NCB Records for more information about the NCB initialization function.
If the online file recoup function is running, wait for it to be completed or end it before starting the NCB reorganization function. See TPF Operations for more information about the online file recoup function.
A completion message is displayed when the NCB reorganization function has been completed.
Once you start the NCB reorganization function, you can end it at any time by entering the ZNNCB REORG command with the ABORT parameter.
If you are ending the NCB reorganization function from a processor other than the processor where it was started, you must also specify the BP parameter for the ZNNCB REORG command.
See TPF Operations for more information about the following commands:
There are no performance considerations for accessing NCB records in the TPF system.
The TPF system uses the CSNB segment to access NCB records. This segment uses the NCB directory record to determine the file address of the NCB record for a dynamic LU resource only when the session is first started. The CSNB segment then saves the file address of that NCB record in the RVT, which is located in main storage. The next time the TPF system tries to access the NCB record, the CSNB segment uses the address stored in the RVT.
See Retrieving NCB and SPA Data Records (CSNB) for more information about the CSNB segment.
When developing your own applications, you must use the CSNB segment to access NCB records. This segment returns the file address of the appropriate 381-byte fixed file NCB record or 381-byte long-term pool file NCB record based on the RID that it is given.
See Retrieving NCB and SPA Data Records (CSNB) for more information about the CSNB segment.
The TPF system does not allocate an SPA ordinal when a dynamic LU is created. You can, however, assign a spare SPA ordinal to a dynamic LU with user exits CDLX and CDLY and save the SPA ordinal at RV1ORDN in the RVT. The SPA ordinal can be saved at RV1ORDN for dynamically created resources. For static resources, the NCB and SPA ordinal (generated by OSTG) will be saved at RV1ORDN.
If you intend to retrieve the SPA for a dynamic LU using the CSNB segment, initialize the SPA fixed file record before entering the CSNB segment or the CSNB segment will set an error return code and return to the calling segment.