At the first call to tableBASE from an MPR application, tableBASE initializes itself in the region. This consists of reading any TBOPT file, processing the DK1IBASE module, obtaining storage space for control blocks, and acquiring a Data Space for the local TSR. This initialization occurs only once if no transactions abend. If a transaction abends, all resources (memory, TSR) acquired by tableBASE are freed; any tables in the TSR vanish without being stored. If the MPR control task re-attaches the application control task, tableBASE initialization will re-occur at the next call to tableBASE.
This effectively means the contents of the local TSR can be volatile since any updates made to local tables will be lost in the event any transaction abends.
tableBASE treats the entire sequence of transactions, from first call until normal shutdown of the MPR (or until a transaction abends) as a single ‘thread’ of execution. A tableBASE thread has some attributes that persist for the life of the thread, for example, its active ML list, its status switch settings. Those two statements imply that one transaction will inherit the attributes of any earlier transaction that may have set them differently from the default values. Thus writers of MPR transaction modules that call tableBASE must explicitly set a suitable ML list and status switch values to meet the application’s needs. If a TBPARM parameter is used (that is, the application adheres to the tableBASE R5 API definition), then the TB-TURBO field should be set to low values (binary zeros) at the start of each transaction. It should not be changed after that. If a specific VTS-TSR is to be accessed by the application, its name should be put into the TB-SUBSYS field. If no VTS is required, set TB-SUBSYS to low values (binary zeros).
Essentially this states that each transaction module should start off by initializing as if it were its first invocation, no matter how many times it may be used during the MPR’s lifetime.