Introduction To TPF

Introduction To TPF
Synopsis
 Need for TPF?
 Comparison with a Conventional OS
 Legend of TPF
 Applications using TPF & TPF users
 Alternatives to TPF
 Disadvantages of TPF
 Supporting Systems
Need for TPF?
The Requirement
 120,000 end users

 Message rate to the system : 3000 Per Second
 Average Storage device access per message : 10
 Average machine instructions per message : 50K
 Required response time -3 seconds. Assuming a communication delay of 99.5% , i.e. a
processing time of 1.2 milliseconds per entry.
 A real time system , Availability requirement : 24 * 365 Days a year
 Disaster Recovery time : 0.5 - 2 Minutes
 Peak message rate : Over 5000 messages per second
 Low cost per transaction : < .2 Cents / Transaction
The Solution

T ransaction . P . F rocessing
Provides platform for high volume mission critical transaction processing.

acility
 Provides high availability, endurance and unsurpassed response times for high message rates.
 Some installations have reported a peak message performance of over 5200 messages per second.
 There is no reliable alternative to TPF as yet.
 Strategically positioned to process billions of transactions with seamless scalability.
 Rapid application development tools, introduction of support for C, C++ and the data repository
enabling object technology.
 A promising future Super Web server that can take on other web servers by storm. E-Commerce
will be TPF's forte with its high volume transaction processing capability.
Comparison with a Conventional OS
TPF Unix
No Preemption Processes Pre-empted
Rigid Database , 3 Record sizes Only Flexible database structure
Unique , Horizontally allocated database Hierarchical File System
No Priority of tasks Processes can be prioritized
Unique Network Protocols Standard Protocols
Traditionally supports Low level assembly

Programs High level languages supported
Shared database , Minimum protection File level access restrictions
Supporting environment required Development can be done in UNIX itself
Doesn't support batch processing Supports batch processing
Restarts to normal operating state in 2 minutes Longer restart period required
Operating System Source code Supplied Not Supplied

Operating cost very miniscule Relatively High operating costs
Real time Mirroring of database Not Supported
Legend of TPF
 Initially developed in 1962 by IBM & SABER on an IBM 7090 Processor as a solution to
automate American Airlines passenger reservation function.
 In 1963 Delta Airline’s Deltamatic system running on an IBM 7074 and PANAMAC the PAN-
AM System running the IBM 7080 Processors were developed.
 IBM Announced in 1964 System / 360 processor and PARS (Programmed Airline Reservation
System) a separate operating system.
 1968 - PARS released as a product. Included both the system and application.
 1969 : Separated PARS into ACP (Airline control program) the operating system and APPS
(Applications) the application portion. First version of ACP Called as ACP4.
 ACP6, ACP8 released in the 70's and ACP 9 released in 1979.
 December 1979, ACP re-christened to ACP/TPF so as not to isolate TPF as an "Airlines Only"
Operating system.
 1983, 1984, TPF2.1 and TPF 2.2 Released. All systems till now could run only on single
processor.
 1985 : Parallel-processing capability introduced with TPF2.3.
 1988 : TPF 2.4, Support for TCMP made available, IBM assured that new hardware support from
IBM would be made available in TPF along with the mainline operating systems of IBM.
 1989 : TPF 3.1 Released
 Early 90's Program Temporary Fixes (PTF's) introducing enhancements to TPF3.1 released.
 1993 : TPF 4.1 Released, virtual memory introduced, increased system security and flexibility,
increased functionality.
 1993 to today : PUT level 3 to PUT Level 9. Includes support for ISOC, support for TCP/IP ,
object oriented programming .
 The future developments are providing TPF with increased functionality and standard interfaces
with other systems ( e.g. POSIX ).
Applications using TPF & TPF users
 Application requiring the Transaction Processing Capability are usually identified with the
following system needs
 Quick Response time
 High Availability
 Huge message rates
 Mission Critical Applications
 Some applications satisfying these definitions and run TPF
 Large Airline Reservation , Cargo , Departure Control , Fares Systems
 Consortiums that hosts a number of Airlines
 Financial Institutions , Banks , Credit Cards , Insurance
 Police Systems
 Railway Reservation Systems
 Hotel Reservation Chains
 Retail store chains and Others
 TPF Users
Airlines :
American, Alitalia, All Nippon, British Airways, Continental, Canadian, Delta, Garuda
Indonesia, JAL, KLM, Pakistani (Now with Sabre), Qantas, Singapore Airlines, Swissair, Thai
Airlines, US Airways
CRS :
Abacus, Amadeus, Apollo, Datas, Galileo, Sabre, System One (Eastern ), Worldspan
Financial Institutions :
American Express, Western Bank Corp, VISA, Bank of America etc.
Police Systems : NYPD
Railway Reservations : British Railways
Hotel Reservation Chains : Marriot Hotels
Alternatives to TPF
 ALCS (Airlines Control System) or MVS/TPF is an alternative to TPF.
 ALCS runs under MVS , Basically an interface between TPF applications and the MVS Operating
System.
 ALCS can not match TPF'S message processing rate, Typically handles 200 messages per second.
 Not an alternative to TPF For users with message rates in the order of 300 and above.
 ALCS users include Indian Airlines, China Airlines, Ansett Australia, Saudia, SITA, SAA, Air
New Zealand and Westin Hotels.
 Open Systems : Microsoft Transaction Server, Oracle SQL Server.
Disadvantages of TPF
 Application development very slow since traditionally assembly language is used for applications
development.
 Need for specialized training with its associated high costs.
 Cannot interface with other systems.
 No portability of codes.
 Low Security.
Supporting Systems
 Traditionally MVS has been the prime supporting system for TPF.
 TPF uses MVS datasets for storing its source and object libraries .
 Offline tasks such as tape post processing, link editing, assembling compiling, system generation
etc.. are preformed in MVS.
 VM/CMS along with XEDIT provides the environment for program development and testing,
version control and program updates are usually done in VM. VM based test systems are normally
used in TPF installations.
 The PC has lately started to play its supporting cast in TPF development with Personal TPF.
 Windows NT based total programming environments for TPF are now being developed. These
come with editors, debuggers and version controllers along with personal test systems.
 OS/2 based automated console experts (ACE) makes the operator's life easier.
 Hardware's such as CPU, DASD, tape drives also are an important lifeline for a TPF system.
TPF Basics
TPF Basics - Synopsis
 TPF Terminology
 Register Usage in TPF
 Programs In TPF
 BEGIN & FINIS macros
 Data Macros
 Reentrancy
 Entry
 Entry Processing
 Entry and Transaction
 Entry Control Block
 Data Levels
 AAA
 PARS Date
TPF Terminology
Main I-stream The main I-stream is the I-stream, which controls the overall functioning of
the system. This I-stream is the master I-Stream, which controls the other I-
streams. This I-stream, most of the times, provides system services to
applications running on other I-streams.
Application I-stream The I-streams, which are in the CPC, other than the main I-stream, running
application processes, are called application I-streams.
Agent Set The terminal user in an airline system is called an agent. This is the TPF
equivalent term for End-user.
CRAS Computer Room Agent Set. A CRAS is a special terminal from where
system related entries could be entered.
Functional messages Functional messages are commands that can only be entered from the
CRAS terminals. These messages result in the operating system servicing
requests, or system parameters being changed. They are also called Z-
messages.
LNIATA This is the way TPF addresses a terminal in its network. This is closely
related to the hard ware addressing. It expands to Line Number Interchange
Address Terminal Address.
Prime CRAS The TPF system's main console. Most of the entries can be given from this
terminal.
RO CRAS The Read Only CRAS is a printer attached to the PRC, to which all the
system messages that need to be intimated to the operator are routed.
PARS Programmed Airlines Reservation System is the set of application programs
used for the airlines.
Control Program The TPF term for the operating system.
E-Type Program TPF programs are broadly classified into two types. CP and E-Type
programs. CP is the collection of programs that make the Operating system.
E-Type programs are normal application programs.
IPL Initial Program Load; this is the same as boot strap loading in other
operating systems.
Register Usage in TPF
 There are two conventions used in TPF to name registers – conventions furnished in the table
given below
 As the new convention is much clearer, use it while coding new programs.
 But, while modifying an existing program use the existing convention.
 TPF takes a few registers for internal use; application programs should never use those registers.
New Convention Old Convention Available for

applications?
R0 RAC Yes
R1 RG1 Yes
R2 RGA Yes
R3 RGB Yes
R4 RGC Yes
R5 RGD Yes
R6 RGE Yes
R7 RGF Yes
R8 RAP No
R9 REB No
R10 RLA No
R11 RLB No
R12 RLC No
R13 RLD No
R14 RDA Yes (see note)
R15 RDB Yes (see note)
 TPF preserves the values stored by the applications program in registers R0-R7 across macro calls.
But, the values of R14 & R15 are not saved and hence will be changed across macro calls. Exhibit
caution while using R14 & R15. It's the programmer responsibility to store them across macro
calls.
Programs In TPF
 There are a few rules and conventions that are present in the TPF environment.
Rules
 Program names should always be 4 character in size.
 Programs are qualified by concatenating the program name with another identifier called the
program version.
 The version is a 2-character identifier.
 Both the program name and the version number can be alphanumeric.
 All TPF programs should be of size 4k or lesser only.
 The restriction is because 4K is the size the largest block which can be stored in the database and
memory.
 One cannot exceed this size, and this limitation includes the code, constant texts, literal pool and
macro expansions.
 All TPF programs should be re-entrant*.
 Multiple versions of the same program can exist in the system.
 When a process has to execute a program that has multiple versions, it will always use the latest
version.
 The old versions will remain active till there are processes using it.
 Once there are no processes using the old version (meaning all the processes in the system is
created after the latest version was loaded), the old version becomes inactive.
 A process will use the same version it was referring till exit.
Conventions
 A package is made up of programs that are correlated.
 The second digit of the Version Number is always a numeric digit.
 Any changes made to the existing segment results in a new version and the new version is the next
higher number (2nd digit).
 The following is the convention for naming a TPF program.
U I I 1 K 3
Package Identifier Version Number

Program Identifier
* - Will be dealt in detail later.

Programs In TPF
Conventions (Contd..)
 The program should be of the following structure.

BEGIN
COPYRIGHT STATEMENT
PROGRAM PROLOGUE
CODE
DSECTS (if any)
CONSTANT DATA AREA
FINIS
 Inserting the DSECT* statement inside the program indicates the beginning of the dummy section.
So, one should insert $IS$ CSECT at the end of the DSECT to resume the CSECT.
BEGIN
-----------------
-----------
ABCD DSECT
PAC DS C
SEC DS CL4
---------
* the end of the DSECT
$IS$ CSECT
FINIS

BEGIN & FINIS macros
 All the E-type programs should start with a BEGIN macro.
 The BEGIN macro does the following.
 Formats the program header.
 Puts the START statement.
 Defines the CSECT statement.
 Defines R8 as the base register of the program
 Calls the equate macros like UXTEQ, SYSEQ, EB0EB.
 The format of the begin statement is :
BEGIN NAME=XXXX,VERSION=YY
 E-type programs should end with a FINIS macro.
 The FINIS macro does the following.
 Puts the date and time of assembly.
 Generates information needed for the loader.
 Puts the END statement.
 Calls the equate macros like REGEQ.
 The format of the FINIS macro is :
FINIS xxxx
Data Macros
What is a Data Macro?
 Designating storage locations inside a program, both data items and statement labels, can be done
using implicit data designation.
 In this case, where the locations are inside a program, the data definition directive DS, will result
in storage being allocated.
 But, designating fields inside a record which is placed in storage location that is external to the
program can’t be done because the items that should fall within the addressable range of a base
register should only be put inside a program.
 For such cases, the DSECT directive should be used.
 A DSECT directive describes the layout of the record that is placed in the storage.
 The DS directive is used to describe the layout of the record that is placed and remember that the
DS directive inside a DSECT will not result in storage being allocated and instead will result just
in displacements for the labels to be computed.
 The concept of data macro (DSECTS) is the same as STRUCTURE definitions in C language.
How to create/use a data macro?
 A DSECT should be started with a DSECT directive and should end with an END directive.
 It is required in most cases that the DSECT is given a name for reference.
 The actual definition of the record layout should follow the DSECT statement.
 The first data item will have a displacement 0.
 In TPF, a DSECT can be of size 4K maximum.
 One can create symbolic constants inside a macro by using EQU directives but should not use DC
directive.
 In the program that needs to refer the fields inside the data macro, one should code a USING
directive with the DSECT name and a base register.
 The base address of the storage block that contains the record read in should be loaded into the
base register.
Data Macros
An example!!
 Assume that there is a data record of the following layout out in the memory.
Employee number 4 digits

Employee name 30 chars
Department 10 chars
Designation 3 chars
Date of birth 10 digits
Date of joining 10 digits
Gross salary 8 digits
The following will be the DSECT definition.
EMPLOYEE DSECT
EMPNUM DS F
EMPNAME DS CL30
EMPDEPT DS CL10
EMPDESG DS CL3
EMPDOB DS XL10
EMPDOJ DS XL10
EMPSAL DS PL5
END
 The following is the method to refer a symbol defined in the DSECT give above. Assume R14
contains the starting address of the storage location that contains the employee record.
USING EMPLOYEE,R1
LA R1,EMPDATA
MVC TEMPNAME(30),EMPNAME move the name to temp
Reentrancy
The problem
 Allocating space for data variables and storing data items inside the program doesn’t pose any
problem in a mono programming environment.
 This is because, the program that is loaded in the memory is not shared across processes and the
values that are stored in the variables within the program will not be corrupted.
 In a multi-programming environment this will not the same.
 When a process is preempted and a new process is under execution, there is a chance that the
values stored by the previously executing process is changed by the current process if both the
processes share the same program.
 The scenario depicted below:
Scene Value of Variable A

Start of Process 1; program ABCD called; variable initialized 0
Process 1 under execution; changes A 10
Process 1 gets preempted 10
Start of Process 1; program ABCD called; variable initialized 0
Process 2 under execution; changes A 20
Process 2 gets preempted 20
Process 1 gets back control; value of A changed!! 20
The Solution
 There are two approaches to solve the problem.
 To allocate a copy of the program for every process that is under execution.
 Data Isolation.
 Though the first solution looks simple, it is not very feasible because of the storage wastage.
 The second solution isolates code area in the program from the data.
 Then for every process that is under execution, a copy of the data area is supplied and the code
area is shared among all the processes.
 This solution is effective because the code area size is quite large.
Reentrancy
TPF Implementation
 Compilers for high level languages support data isolation and the process is totally transparent to
the user.
 But, in TPF assembler programming, the way to achieve this is by writing re-entrant programs.
 A re-entrant program, by definition is a program that can be shared among processes
harmoniously!
 This means that there should not be any storage allocation inside the program whose value gets
altered during program execution.
 Still, storage allocation can be done inside the program with DC directives and the values with
which the locations are initialized should never be modified.
 Does this mean no variables??
 No.. TPF uses ECBs* and data levels to store values that are dynamic.

Entry
 TPF system by definition, is a system that aims at high performance.

 The tasks that a TPF system usually executes, is not CPU intensive.
 This restriction helps in achieving quick turnaround time.
 In TPF, a process or task is usually triggered by the arrival of an Input message.
 The input message, from the terminal, which results in a process being activated in the system, is
called an ENTRY.
 When an entry arrives at the system, TPF allocates all the resources needed for it's processing and
tries to get back the response.
 The TPF processes/entries can’t be preempted; though they give up control for I/O or to give other
processes the processor.
Entry Processing
Entry keyed
The input message
ECB creation
Application
Processing
Response displayed
Entry Processing
 The agent keys in an entry.
 This results in the input message arriving to the TPF system.
 TPF takes the block, constructs an ECB, and dispatches the entry for processing.
 The relevant application/system programs are entered for processing.
 The application program issues API calls whenever needed for performing I/O and other
operations.
 The databases are updated, if required and a response is generated a routed to the agent.
 Each entry should have a response being sent back to the terminal.
 This is mandatory because when an entry is keyed in, the keyboard remain locked (inactive) till a
response clears the keyboard lock.
Entry and Transaction
 The entry is the unit that brings work to the TPF system.
 Whereas, the transaction is a collection of such entries.
 The System's task is to create the ECB and pass on the message to the application.
 The applications should construct the transactions based on the entries.
 The set of entries is well defined, so that a transaction is constructed. The order can vary.
 The AAA serves as a repository for the data.
 The concept of transaction adds to the performance of TPF in the following ways.
 A transaction collects all the information needed to be filed to the DASD and does it in a
single shot. This results in the number of I/O needed being reduced.
 Eliminates the need for rollbacks. If the entries directly result in changes to the database,
rolling back the changes if needed before the end of a transaction is difficult. But,
constructing the transaction and filing at the end makes role back possible at any point
before the final entry.
 It provides a backward reference to the following entries.
 The following example demonstrates the use of the AAA, the mechanics of a transaction and their
advantages.
User keys in entry, seeking availability of flights from Madras to Singapore on 31st July.
A31JULMAASIN <ENTER>
RESPONSE
SAT 31JUL 1200 MAA - SIN SINGAPORE

CHANGI.SG AAA
A3 B8 C8 EASL MAASIN _____________________________
1A MAASIN 30-2320 0550*1 SQ 409 744 0 P9 A0 L2 AVAILABLITY INFORMATION
T0 J9 D0 V4 ------------------------------------------------
U0 Y9 H0 K0 Q9 Z6 G0 O0
2A MAASIN 31-2320 0550*1 SQ 409744 0 P9 A0 L2
T0 J9 D0 V4
U0 Y9 H0 K0 Q9 Z9 G0 O0
User keys in entry, to book one ticket from in the flight

displayed on the second line.
N1Y2 <ENTER>
RESPONSE
AAA
1 SQ 409 Y SA 31JUL MAASIN HS1 2320 0550*1 Y _____________________________
QSISQ AVAILABLITY INFORMATION
------------------------------------------------
PASSENGER ITENARY IS STORED
_____________________________
User keys in entry, to give the name of the passenger.
-ANANTHA/SHRIMANIKANDANMR <ENTER> AAA
_____________________________
RESPONSE
AVAILABLITY INFORMATION
------------------------------------------------
1.1ANANTHA/SHRIMANIKANDANMR PASSENGER ITENARY IS STORED
_____________________________
NAME OF THE PASSENGER
User keys in entry, to give the phone number of the passenger. STORED
9h*2355015<ENTER> -------------------------------------------------
RESPONSE
FONE-QSISQ -H 2355015
AAA
_____________________________
------------------------------------------------
_____________________________
STORED
-------------------------------------------------
Phone number stored
The received from information is keyed in.
6manika<ENTER> AAA
_____________________________
RESPONSE
------------------------------------------------
6manika* PASSENGER ITENARY IS STORED
_____________________________
User ends the transaction request STORED
E*R<ENTER> -------------------------------------------------
RESPONSE Received from name stored.
------------------------------------------------
1.1ANANTHA/SHRIMANIKANDANMR
QSISQZZ 10FEB JPVZP8
1 SQ 409 Y SA 31JUL MAASIN HK1 2320 0550*1 Y
QSISQ
FONE-QSISQ -H 2355015
TL-CMAASQ1800/17JUL/10FEB
RMKS- NOTE AUTO-CANCEL TTL SET BY SYSTEM
ON 10FEB AAA
_____________________________
------------------------------------------------
_____________________________
STORED
-------------------------------------------------
Phone number stored
File changes…..
 Notice in the previous scenarios there was just one I/o at
the end of the transaction.
 There was no explicit reference given. The AAA served as
the reference point for the subsequent entries.
 If one had to clear things half way through, doing an Ignore transaction entry will clear the whole
thing.
Entry Control Block
What is an ECB?
 Each entry that comes into the system results in a process being created.
 Each process in the system will have it’s own unique information that is required for processing.
 The ECB, Entry Control Block, is the data structure that holds these information about the process
stored in it.
 The ECB is analogous to the PCB (Process Control Block) in Unix.
 Remember that ECBs are unique to an entry (process) and hence each entry in the system will have
an ECB associated with it.
More about the ECB

 A part of the Control Program, called OPZERO, creates ECB.
 When a program is under execution, R9 should always point to the ECB.
 The system programs will automatically load R9 with the address of the ECB during ECB
creation.
 Application programs should never use this register.
 The data macro EB0EB describes the layout of the ECB.
 The ECB is a memory data structure and its lifetime is restricted to the life of the entry.
 The ECB is the component in the system that serves as an interface between the control program
and the applications.
 The ECB has in it, data that are used both by the system and application.
 The system has in the ECB, control data that relates to an entry.
 The application puts in it business data. The application uses this ECB as work area.
 Programs store data in the ECB to achieve reentrancy.
Entry Control Block
Anatomy of the ECB
 The ECB is of size 12 K fixed.

 The ECB is divided into three pages each of size 4K.
 The pages are used for different purposes.
 Page 1 is used both by the system and the applications. This has in it the save area, switches and
work area for applications.
 Page 1 of the ECB has a Protect key value 1. Hence, applications can access this page.
 The next page, Page 2, has a lot of system related information required by various components in
the system.
 Page 2 is protected; Protect key value is F.
 Page 3, has in it system information which relates to programs and the application and not much to
do with control.
 This page has a Protect key 1. But, the applications are advised to stay away from the page.
Application Area in ECB.
 The application area in the ECB is used to achieve reentrancy.

 The ECB is a process/entry unique data structure and the values that are stored in it is private to the
process to which it belongs.
 So, TPF provides some space in the ECB for applications to put its data.
 The application area can mainly be divided into two regions based on their functionalities.
 Application data and switch area
 Data Levels
 Each ECB has two application work areas of size 112 bytes each. These areas are made up of 104
bytes of scratch area and 8 bytes for holding switches.
 The first work area begins at label ebw000 in the ECB and ends at ebw013.
 The second work area begins at label ebx000 in the ECB and ends at ebx013.
 These areas are initialized to zeros while the ECB is created by OPZERO.
 The values stored in these areas are retained across program called within a process.
Data Levels
Data Levels : Basics
 Though TPF provides applications with 224 bytes of work area, it is never enough for a normal
scenario.
 All the applications need more area to store the data that is associated with the process.
 Data levels give the process/entry the capability to refer to 16 storage blocks (termed as data
blocks) at a given point of time.
 In essence, the data levels can be considered as an array of pointers that hold references to bigger
blocks of data.
Data Levels : How are they populated?
 When an ECB is created, the data levels will be initialized with zeros.
 But, there are two ways in which the data levels are populated.
 A data block can be acquired by issuing a macro call to the CP.
 A data block is placed in a data level as the result of an Input Operation.
Data Levels : Classification
 The initial understanding of data level is clear and simple. But, the concept is slightly tricky as
there are sub divisions in data levels.
 To make things simpler it’s required that a very brief introduction about the way TPF does file
management is required.
 A file in TPF is not associated with a name & extension but is associated with things like ordinal
number and face type. They are discussed in detail in the later sessions.
 But, the basic thing that is required to know at this point is that in TPF the file access is done by
supplying the actual file address!
 With details about file system in TPF to follow in the later chapters, the data levels are classified
as:
 Core Block Reference Words
 File Address Reference Words
 Extended File Address Reference Words
 Error Indicators
 Remember that there are 16 data levels and each level has a CBRW, FARW, FAXW and Error
Indicators.
Data Levels
Details
 There are 16 CBRWs, 16 FARWs, 16 FAXWs and 16 Error indicators.

 The CBRW, FARW and FAXW are of size 8 bytes each.
 The CBRW contains the address of the core block that is pointed by the data level.
 The FARW holds the file address of the data block that should be accessed.
 The general data set (GDS) support allows a TPF application to read and write MVS BSAM or
QSAM DASD data sets that are used to pass data between MVS and TPF.
 General data sets are BSAM or QSAM multi-volume fixed-length record data sets with records in
TPF sizes (381, 1055, 4095, or 4096 bytes).
 The file address reference word extensions are used to address the general data sets.
 The error indicators are used to indicate abnormalities if any, after an I/O operation is done.
 The term data "level" is slightly eluding. There is no priority assignment or nesting among these
references-data levels.
 The concepts of data levels, the way TPF uses these data levels to do I/O etc will be dealt in
future chapters. At this point a very basic understanding is suffice.
AAA
 An entry brings work to the TPF system.
 There are cases where, an entry results in changes to the system directly.
 But, TPF being a Transaction oriented system, varies significantly from other operating systems.
 Though entry brings work, in most cases, a series of entries are required before changes are made
to the system.
 Imagine a situation where one has to key in an address, and one can key in only one line at a time.
 It will take a few entries before the whole address is keyed in.
 TPF applications use the Agents Assembly Area (AAA) to build the outcome of these entries.
 Relating these entries together is the application's job and the collection of such entries is called a
'Transaction'.
 AAA is a terminal unique data structure, where the transaction is assembled from the entries.
 The AAA also stores in it terminal unique information and some user information need by the
applications and the system.
 The AAA is not a volatile record like the ECB. The AAA resides in the disk and the program
WGR1 brings it to the core.
 Changes to the contents of the AAA are preserved across an IPL.
 The AAA also serves as the data structure that identifies the user.
 TPF applications control the user privileges and rights based on the AAA.
 The AAA has 'areas', which are used for identifying a user, and the same AAA can have the user
with various operational authorities signed into different area.
PARS Date
 PARS date is the system day number.
 Two byte global field @UIDAY.
 Largest number allowed is 32767 that will be 19 Sep 2055.
 Applications convert the date in DDMMYY format to PARS date before they store it in the record.
 During display/printing the process is reverted.
 The utility program at SQ to do this is UCDR.
 The reason behind PARS date is that this saved 4 bytes in those days when memory was
expensive.
 Easy to sort as the days are represented in binary.
 Problem in 2055!!
 The terms ‘process’ and ‘ECB’ will be used interchangeably in this book from here onwards.
Memory Management
Memory Management : Synopsis
 DAT implementation in TPF
 Storage blocks in TPF - Classification
 Block sizes
 Data levels
 Block check mode
 Memory management related macros
DAT implementation in TPF
Dynamic Address Translation
 Dynamic Address Translation (DAT) is the process of converting virtual addresses into real
address at execution time.
 Every address that is generated in the system, both instruction and data addresses, are converted
from virtual to real form before the access operation is done.
 The concept of Virtual addressing is supported by DAT and virtual addressing provides the
processes an illusion that they share the same addresses; but internally this ‘same’ virtual address
will resolve to a different real address for each process.
Conventional Use of Virtual Memory
 The concept of virtual memory is often used to implement two things:

 Demand Paging
 Process Address Space Isolation
 TPF, because of its performance consciousness# doesn't use the page faults for Swap initiation.
 TPF uses page faults to provide support address space isolation among ECBs.
 The segment and page tables of an ECB have "Invalid" flags for all the pages that are not a part of
it's ECB Private Area*.
 Attempts to access those pages (which belong to other ECBs) will result in a system error.
# - All programs in the TPF system are assumed to use only a trivial amount of processor time. The
overhead for paging out is greater than simply allowing a TPF program to complete. Hence, TPF’s
architecture loads all the pages that are required by the ECB in the memory and hence there is no need
for paging.
* - EPA is the range of addresses that the ECB can refer to.
Physical Storage Blocks
 The physical storage in TPF is a composition of two components.
 Fixed Storage.
 Working Storage.
 Those areas of the memory whose sizes are determined during system generation are referred to as
Fixed Storage.
 System Data records and system tables are examples of fixed storage.
 Those areas of the memory which are available to applications, and those areas, which are, used by
the system to manage/process an entry are called working storage.
 Working storage blocks are further classified into five groups.
 Input Output Blocks (IOB)
 System Work Blocks (SWB)
 Entry Control Blocks (ECB)
 Frames
 Common Blocks (CMB)
Type Purpose Description
Input Output Blocks (IOB) System I/O blocks are used to hold data to be transferred to
DASDs and memory. They are used exclusively for
this purpose. They are 4k in size.
System Work Blocks (SWB) System System Work blocks are used by the control program
as work blocks. They are 4k in size.
Entry Control Blocks (ECB) System / The Entry Control Block is used for entry processing.
Application They are 12 K in size. They are used to store
information related to the process as described in the
previous chapter.
Frames Application Frames are used as work blocks by applications (E-
type programs). They are 4k in size.
Common Blocks (CMB) Application Like frames Common blocks are also used as work
blocks. But, the difference being that they can be
shared between ECB's. They are 4k in size.
 Applications should avoid using common blocks. Common block usage can impact the system.
Block Sizes - Dissection of frames
 The work block required for the ECBs are dispensed from frames.
 Blocks of size 128 bytes, 381 bytes, 1055 bytes can be carved out from a 4k frame and attached to
the ECB.
 A whole frame can also be acquired for the ECBs use, by specifying the block size to 4K.
 The frames are carved into smaller blocks to optimize storage usage.
 The same classifications apply to common blocks as well.
 TPF blocks and their typical usage.
Block type Usage Blocks / frame

128-byte block Work block , Message block 10 blocks
381-byte block Message block, data records, and work. 10 blocks
1055-byte block Message block, data records, and work. 3 blocks
4k block Message block, data records, work, 1 block
program segments and keypointing.
 If the request is for a non-4K block, TPF services that request by carving out the required block
from a frame.
 Carving out blocks from the same frame satisfies further requests for the same sized block from
the ECB.
 When all the blocks are carved out from the frame, a new frame is dispensed.
 TPF does not dispense heterogeneous sized blocks from the same frame.
 When an ECB releases a block, the frame is released from the EPA if it is the last block.
 If the request is for a 128 byte block, TPF still dispenses a 381 byte block. This is to reduce the
number of block sizes for ease of management and at the same time provide compatibility to old
applications that use 128 byte blocks.
 Note that this style of carving out blocks is for only frames. Though common blocks are available
in different sizes, a request for a common block, irrespective of the size, will result in a fresh frame
to be dispensed.
Block Check Mode
Problem:
 The TPF system provides total isolation between ECB working storage by implementing virtual
addressing.
 But, this mechanism has its limitations. An ECB can write beyond it's block boundary as the next
location will still be a valid virtual address in the EVM.
Frame attached to the ECB
Block 0 Block 1 Unassigned
 If the ECB is writing into Block 0 and has reached the end of the block and continues to write
beyond the block, there will be no problems.
 This is because, the next block, Block 1, still belongs to this ECB and is within the EPA!!
Solution:
 TPF uses an ingenious scheme called block check mode to deduct such occurrences.
 When the system is running in block check mode TPF does the following.
 All block requests are satisfied by dispensing them in a fresh frame.
 The block is allocated at the last slot available in the frame.
Block 0
Block 1
 With this, when a program overwrites beyond a block boundary, it will result in a page fault,
resulting in an access exception.
 This will help in getting a page fault if the ECB uses the released block again.
 Also, the ECB exit processing inspects all the frames during exit time and if it finds any block
marked in use, hits a dump.
 This mechanism may fail in the following situations.
 The block requested was a 128 byte block and the number of bytes overwritten is less
than 381 bytes.
 The next address referred outside the block belongs to a valid frame in the EPA.
Core Block Reference Word
 Do you remember that there are 16 data levels in each ECB and each of these data levels had a
CBRW, FARW, FARX and an error field?
 Now lets have a look at the components that make the CBRW in detail.
 CBRWs are of 8 bytes in length and start on a doubleword boundary.
 The CBRWs are made up of the following fields.
 Virtual address of the core block (4 bytes)
 Type of block held at the level (2 bytes)
 Size of the block (2 bytes)
 The first four bytes of the CBRW hold the virtual address of the core block that is being held.
 The next two bytes hold the type of the data block and the last two bytes, the size of the data block
held.
 The following are the values in the block type indicator.
Indicator Meaning Notation used

0001 No block attached
0011 128-byte block L0
 Only the Block type indicator reflects the current status of the data level.
 The values present in address field and size field are not meaningful when the block type indicator
marks the absence of a block.
 The address field and size field are not cleared when a block is released and the only field that is
reset is the type field.
 Applications should never modify the core block reference words.
GETCC – Get Core Block
Function  Assigns a storage block of the specified size and type to the ECB.
 The ECB's CBRW at the level specified is updated with the address of the
block, the size and type.
 The storage key of the page is set optionally.
Format
GETCC
Dn,Ln,COMMON=NO,YES,PROTECTED,FILL=hh
Description  Dn - Specifies the data level on which the core block has to be retrieved.
The values may be (D0-DF)
 Ln - Specifies the block type needed. The block size is implicit. The
values may be L0, L1, L2 and L4.
 COMMON - Specifies if the core block required should be a common
block. The default option is NO and this results in a core block being
attached to the ECB which is not accessible by other ECBs. Specifying
YES results in a common block being dispensed. The block is accessible to
all the ECBs in the system. Specifying PROTECTED results in a common
block with protection key 'F' set to the block. The program requires
authorization for obtaining a common block.
 FILL - Specifies a hexadecimal value with which the core block will
be initialized. The contents of the core block will be unpredictable if the fill
parameter is not specified.
Input Conditions  No core block should be attached at the specified level.
Return Conditions  The CBRW at the specified level is updated.

 R14 has the address of the block assigned.
Errors Possible  Ctrl-C. There are no frames available in the system. Catastrophic
error.
 Ctrl-6. The level specified is already holding a block.
 Ctrl-EB. The program is not authorized to issue macro with COMMON
= YES option.
 Ctrl-6DB. The ECB private area is exhausted.
Restrictions  If a common block is requested for, the program should have authorization
to get common block.
Programming  Common Blocks are scarce resources. Usage of common blocks should be
Considerations avoided.
 Only one storage block can be obtained with a single call.
 Using FILL option takes more CPU resources than not initializing the block.
 Returning common blocks should be ensured. They are not automatically
returned.
GETCC – Get Core Block
Example  The following macro call gets a 4K block on level 6.

GETCC D6,L4
 The following macro call gets a 1055 K block on level F and initializes it
with zeros.
GETCC DF,L2, FILL=00
 The following macro call gets a 128 bytes common block on level 1.
GETCC D1,L0,COMMON=YES
 The following macro call gets a 381 bytes common block on level 0, fills it
with spaces and sets the storage key.
GETCC D0,L1,COMMON=PROTECTED,FILL=40
RELCC – Release Core Block
Function  Release the storage block at the specified level and returns it to the working
storage pool.
Format
RELCC Dn
Description  Dn - Specifies the data level from which the core block has to be released.
The values may be (D0-DF)
Input Conditions  A storage block should be attached at the specified level.
Return Conditions  Control is restored to the next sequential instruction (NSI).

 The contents of R15 & R15 are unknown. All other user registers are saved
across the call.
 The CBRW at the specified level is updated to indicate that the block is no
longer held.
Errors Possible  Ctrl-7. There is no block attached at the level specified.
 Ctrl-B. The block type in the specified level is invalid.
 Ctrl-6D9. The user attempts to release the block twice.
 Ctrl-6DA. The address in CBRW at the level is invalid or not a block
boundary.
Restrictions  No authorization required.
Programming  Only one storage block is released with each. Requires multiple calls to
Considerations release multiple blocks.
Example  The following macro call releases the block held at level 6.
RELCC D6
LEVTA – Level Test
Function  Checks if a core block is held on the specified level.
 Control is transferred to the instruction at the label upon the presence or
absence of the block.
Format
LEVTA LEVEL=n,INUSE=label1 NOTUSED=label2
Description  LEVEL - n specifies the data level on which the check has to be performed.
An absolute value 0-F is expected.
 INUSE - Specifies the address to be branched to, if a block is present.
 NOTUSED - Specifies the address to be branched to, if a block is not
present.
Input Conditions  Either INUSE, NOTUSED or both should be coded.
Return Conditions  All user registers are saved across the call.
Errors Possible  None.

Programming  It's recommended to use CRUSA instead of LEVTA if the test is done
Considerations before release. Since CRUSA = LEVTA + RELCC if block present.
Example  The following macro call branches to the routine FOUND if block is held at
level 5 and ABSENT if no core block is held at level 5.
LEVTA LEVEL=5,INUSE=FOUND,NOTUSED=ABSENT D6
CRUSA – Test and Release Data Level
Function  Checks if a core block is held on the specified level and branches to a label
if core block is not held.
 Tests a level and if core block is held release it.
Format
CRUSA TEST=n,PARAM=label1 Sx=m
Description  TEST - n specifies the data level on which the check has to be performed.
An absolute value 0-F is expected. The default value is NONE. This
parameter is used with the PARAM parameter to test and branch if core
block not held.
 PARAM - Specifies the address to be branched to, if a block is not
present. If block is held the control is transferred to the next sequential
instruction.
 Sx - m specifies the data levels to be tested. If core block is held at the
level, the core block is released. If this Sx option is used, at least one level
must be specified.
 X indicates the number of core blocks to be released and it is an incremental
parameter, meaning, the values should be order 0, 1, 2, 3, 4……, 14, 15. X
does not indicate the level and m is the one, which specifies the level.
Input Conditions  TEST and PARAM parameter are mutually inclusive. One should either
code both or ignore both.
Return Conditions  The contents of R14 and R15 are unknown.
 All other user registers are saved across the call.
 If TEST parameter is not used, the control is transferred to the NSI
irrespective of whether a core block is held or not.
 If Sx parameter is used, the CBRWs of all the data levels whose core blocks
were released, will be set to indicate that there is no level held.
 If TEST parameter is coded and Sx parameter not coded, the core block at
the specified level is not released if held. The control is transferred to the
NSI.
Errors Possible  CRUSA is a combination of LEVTA and RELCC. A block to be released
can hit an exception as in case of RELCC.
Programming  Use LEVTA if either positive branch or both positive and negative branch is
Considerations required, for a level specified with TEST option.
 When TEST and Sx options are used together, exhibit caution. If the same
level is specified with both the options, Sx is invoked first and TEST is
invoked next.
CRUSA – Test and Release Data Level
Example  Test and release data level 5.

CRUSA S0=5
 Test and release data level 4, 8, 1, F, 2 and 0.
CRUSA S0=4,S1=8,S2=1,S3=F,S4=2,S5=0
 Test and release data level 7 also branch to NOEIGHT if no block is held at
data level 8.
CRUSA TEST=8,PARAM=NOEIGHT,S0=7
FLIPC - Interchange status of data levels
Function  Interchanges the contents in the ECB control fields related to the two data
levels specified.
 The Core Block Reference Word, File Address Reference Word, its
extension and the detail error indicator field of the levels are the fields that
are interchanged.
Format
FLIPC Dx,Dy
Description  Dx and Dy - The data levels whose control fields have to be interchanged.
Input Conditions  Both the level specified should not have any pending I/O operations.
Return Conditions  All other user registers are saved across the call.
 Control is transferred to the NSI.
Errors Possible  None.
Programming  Even if no blocks were held on both the levels, a change in the control fields
Considerations can be observed though it is meaningless.
 If the same level is specified in both parameter fields, it will result in a
'NOP' instruction.
Example  To interchange data levels 1 and 5.
FLIPC D1,D5
DETAC - Detach working storage block
Function  The DETAC macro detaches a block at the specified data level from the
ECB.
 The block is saved and can be attached back to the ECB with the ATTAC
macro.
 This macro permits the user to reuse the data levels.
Format
DETAC Dx,CHECK=YES/NO
Description  Dx - The data level from where the data block should be detached.
 CHECK - When a DETAC macro is issued without a data level being held
on the specified level and with CHECK = YES, then a system error is
issued. Specifying NO will result in making the data level reusable without
confirming the presence of a data block. YES is the default value.
Input Conditions  The level specified should have a data block attached to it, while CHECK =
YES.
Return Conditions  The data level will not be holding the storage block and the data level is free
for reuse.
Errors Possible  Ctrl-D2 - If block not held in the specified level or number of detachments
on an ECB level exceeds 255.
Programming  Usage of this macro can cause exhaustion of storage. So, this macro should
Considerations be used carefully.
 Only 255 DETACs can be issued on a data level. This count is maintained
in the ECB and such count exists for each data level in the ECB. System
error is issued if this limit is crossed.
Example  To detach the block held at data level 1.
DETAC D1
 To detach the block held at data level C without verifying the validity.
DETAC DC,CHECK=NO
ATTAC – Reattach working storage block
Function  The ATTAC macro attaches a block at the specified data level from the
ECB.
 There should be a block that was already detached from the level using a
DETAC macro.
Format
ATTAC Dx
Description  Dx - The data level from where the data block should be attached.
Input Conditions  The ECB should have detached a data block from the level specified
previously.
 The data level should not hold any data block.
Return Conditions  The recently detached storage block will held at the data level specified.
 The CBRW, FARW and FARW extension will be restored with the
respective values from the recent detach.
Errors Possible  Ctrl-D1 - If a data block is held in the specified level or there was no block
detached from the level specified.
Programming  The ATTAC and DETAC macro work like stack calls. ATTAC will attach
Considerations the last data level that was detached from that data level.
Example  To attach the block held at data level 1.
ATTAC D1
TPF Database and File system
Synopsis
 TPF Online Database and Organization
 Fixed Files
 Pool Files
 Fixed Files Vs Pool Files
 FACE Table (FCTB)
 Record Header
 Record ID Attribute Table (RIAT)
 FACE & FACS
 File Retrieval
 File update Mechanism
 Find type macros
 File Type Macros
 Pool File Macros
TPF Online Database and Organization
 The TPF Online database is unique in many different ways. The TPF online database is made up
of a Range of DASDs (Direct access storage Devices)
 These DASDs are Pre-formatted at the time of System Generation.
 All users can access all the files in the database.
 The TPF system unlike other multitasking operating systems, imposes no security/access
restrictions on any of the file.
 Like there are classifications in working storage with respect to the size, there are classifications in
the TPF file system also in terms of the sizes of the physical data blocks.
 Take note that physical data blocks are called records in TPF and a logical record (collection of
fields) is called an item/lrec.
 TPF Supports 3 Standard Record Sizes
 Small (381 bytes)
 Large (1055 bytes )
 4K (4095 bytes)
 While formatting the DASDs, separate storage areas are allocated for each record size.
 Each record is identified by a 4 byte address called the Symbolic Ordinal Number address (SON
address).
Concept of Record Type and Ordinals
 The TPF Database organization is different from other operating systems in many ways.
 In other systems, a file is identified by its file name and directory. Essentially these files systems
support hierarchical file structure where there is a root directory and there are other subdirectories
that
 TPF on the other hand, is a flat file system, which means there are no directories!
 There are also no file names or extensions. Instead the file is identified by its “Record Type”.
 In TPF, each lrecs that belong to a record type is stored into multiple sub-divisions called
‘ordinals’.
 These ordinals can be individually accessed. This allows concurrent access to logically different
parts of the file.
 For example assume that there is a file that has the list of flights scheduled on all the days of a
week.
 In a typical operating system, this information will be stored in a file, sequentially.
 In TPF, this information is put into a file and is associated with a record type.
 A record type can be of size 8 bytes in length.
 Now, the lrecs that belong this record type can further be distributed across many ordinals, say 7
ordinals for this example, and each ordinal holding the information about the flights that is
scheduled on a day of the week.
 This means, a maximum of 7 ECBs can update the file at the same time (assuming that they update
different ordinals) and any number of ECBs can read the file at the same time.
Concept of Record Type and Ordinals
Record Type = #FLTLIST
Sun Mon Tue Wed Thurs Fri Sat
 In this case, more than one process can update the information in different ordinals.
 It’s obvious that the information that can be stored in a block is limited.
 For example, if the flight information lrecs are of size 100 bytes, each record in this record type is
of size 1 k, then we can store only 10 lrecs in record.
 The next 10 lrecs should be stored in another data block. This though trivial, is transparent in
other operating system.
 In TPF this set records that belong to a particular ordinal is called a ‘Chain”.
 The first record in the chain is called the ‘Prime Block’ and the rest of them are called
‘Overflows’.
Horizontal Database Allocation
 TPF divides file types into ordinals and the provision that allows access to ordinals directly
enhances the performance of the TPF system.
 Even in a set up like this, there can be bottle necks in accessing information in different ordinals if
they are stored in the same module.
 To improve on this, TPF database allocation is horizontal.
 Successive ordinals of the same record type are distributed across successive modules.
Vertical Database Allocation:

Module – 1 Module – 2 Module – 3
1 2 3
4 5 6
7 8 9
Horizontal Database Allocation:

Module – 1 Module – 2 Module – 3
1 4 7 2 5 8 3 6 9
Duplication
 TPF achieves data Integrity and Improves Performance by duplicating Records (Mirroring).
 A TPF Database can be
 Non-duplicated
 Selectively duplicated
 Fully duplicated
 Each module has a corresponding dupe module in a fully duplicated database.
 Duplication provides data integrity ensured against hardware malfunctions.
 All requests to "Read" a record serviced from module that has the least queue.
 All "Writes" to records written both to Prime and Dupe .
 The performance overhead in maintaining two copies of a Record (2 I/O's per write) is offset by
the fact that there are two alternate path's to retrieve a record.
Prime Mod 0 Prime Mod 1 Prime Mod 2
Duplicate Mod 0 Duplicate Mod 1 Duplicate Mod 2

Fixed Files
 Fixed files are:
 Records defined before being referenced by application programs
 Mostly contain static data , Serves as indices to dynamic data
 Once defined exists till the lifetime of the applications that use it
 A Set of fixed file records identified to belong to a Record type.
 Each Fixed file in a record type identified with a record type Ordinal number.
 Logically ordinal numbers of a particular record type are sequential records but, Physically, they
are located in different modules (Horizontal database allocation !! )
 A Fixed file record is uniquely identified by its Record type and ordinal number
 The lrecs that are present in a fixed file can be altered during online operation.
 New Fixed files cannot be created during application execution.
 Fixed records are allocated in the online database so as to ensure faster access and improved
performance.
 Fixed file records are allocated by the Database administrator on request from application
Programmers.
 The application programmer defines the record type and number of ordinals as required by his
application
 Record types can be either specific or Miscellaneous.
 Miscellaneous record types used for application requests that do not require more than a few
ordinals , The Miscellaneous record types that are pre-defined are:
 #MISCS,#MISCL,#MISC4 , for 381 byte , 1K and 4K records respectively
 Installations define their own miscellaneous record types , Normally one for each application
departments use.
 Misbehaving applications can inadvertently corrupt a Miscellaneous Record.
 Specific Record types are named record types
 System equates defined to associate a set of fixed file records to a Specific record type in the Face
table (FCTB)
 The SYS equate along with a ordinal number is used by application programs to get to a particular
fixed file.
Pool Files
 Dynamic file storage requests satisfied from storage areas known as pool file storage, or just pool.
 The pool file area is shared by all applications
 Dispensed as and when needed and are returned back to the system when no longer required and
are re-dispensed.
 System locates available record and returns pool file address on requests by application programs
for pool files
 Typically the address is saved in a fixed file record for subsequent reference. Here the fixed file
acts as an index record.
 Pool file storage area in DASD carved out during system generation
 Pool files also have a SON address and an MCHR
 Pool Records can be classified into two types
 Short term pool records
 Long term pool records
 Short term Pool records :
 Very short span of life, measured in minutes
 Typically, exists for the life of a single Transaction
 Mostly used for temporary storage , e.g.. display map
 Long term pool records :
 Used by applications needing file storage for a sustained period of time (Days to months)
 Example , list of passengers booked on a flight
 Pool file records supported by TPF classified according to the attributes of size , duplication and
Longevity (Short or Long) into:
 Small short-term pool (SST)
 Small long-term (not duplicated) pool (SLT)
 Small long-term duplicated pool (SDP)
 Large short-term pool (LST)
 Large long-term (not duplicated) pool (LLT)
 Large long-term duplicated pool (LDP)
 4K short-term pool (4ST)
 4K long-term (not duplicated) pool (4LT)
 4K long-term duplicated pool (4DP)
 Only the long term pool records can be duplicated. This applies for installations using duplication
or mirroring.
Accessing Files
 Every record in the TPF system is addressed with a four byte SON address.
 The only way to access a file in TPF is to access the record that contains the information.
 In order to do that one needs to specify the SON address directly.
 The SON addresses for the fixed files can be computed.
 But, the pool file addresses should be stored in some records – either fixed records or some other
pool record.
 FACE comes to picture at this place.
 The FACE (File address compute) table (FCTB):
 Resides in main storage
 Gives the SON address of a fixed file.
 The Record types, number of ordinals are defined in the FCTB.
 FACE table used to determine the SON address of a file from the record type and ordinal number
 The TPF System does the conversion for the application programs when requested.
 The FACE Table is generated offline for every modification to the face table (New record type
definitions) and is then loaded to the Online TPF System using TLDR
Accessing Files
 Example of Fixed and Pool file usage
 Consider a Passenger names database, With Fixed records holding passenger names and
pool records holding passenger details such as ticket number, flight date, passenger facts,
segment etc..
 The Database would have 26 ordinals (0-25) of record type #NAMES, The first character
of the name would decide the ordinal number of the passenger name file , Atul would go
to ordinal 0 , While Don would go to ordinal 3 as depicted in the figure below.
A = ORd 0 B=ORD 1 C=ORD 2 ………… Z=ORD 5
Aadharsh Balaji Cambell Zusar
Aashsish Barry -----
-------- -----
| |
Ameer Catherine
--------
|
Azhar
---------
 The records that lie above the line are fixed files; addresses are computed using FACE.
 The records below the line are pool files and their addresses are gotten from the previous record.
 In order to access the lrec ‘Azhar’ the application has to access the prime block, which in this case
is a fixed file, by computing it’s address.
 Then should access all the subsequent records till it reaches the lrec ‘Azhar’.
 Remember that the prime block need not be fixed file always; they can be pool files. In such
cases, the prime block will be accessed using indices that point to them from some other fixed/pool
file structure.
 Also, take note that the overflows can be fixed too! In this case, there are two ways to access the
overflow records. By computing the address with FACE or by traversing the chain.
 You can also chain blocks of different sizes!
 Rule is simple! To chain a block you put a 4 byte SON address. All blocks have address of size 4
bytes!!
FACE and FACS
 FACE & FACS are system programs that are used to calculate the SON address of a fixed file
record.
 Takes as input Decimal Record type and Ordinal Number; looks up into the FACE table for the
corresponding SON address.
 FACS serves the same purpose as FACE
 FACS unlike FACE can calculate the SON file address with a symbolic record type and Ordinal
Number
 Interface :
 Application Programs enter the utility Program FACE by issuing the macro call - ENTRC FACE.
 FACS is preferred over FACE.
 The following is the set-up required before calling FACE
FACE FACS
R6  Contains the Hexadecimal Record type  Contains the symbolic record type
R0  Contains the Ordinal Number
R7  Address of an 8-byte field where the system file reference is to be placed. Normally, the
location of FARW because the address must be there before the find or file function can be
called.
 Return from FACE/FACS:

 Normal return
System file reference at the 2nd full word from the specified location
R0: maximum ordinal number for record type
R1-5: contents unchanged
R6-7: contents changed
 Error or Exception Return

R0: 0
R1-5: contents unchanged
R6-7: contents changed
FACE and FACS
Example of FACS usage
LA R0,0 Load ordinal number
LA R6,=CL8'#AAAATRN' Symbolic record type
LA R7,CE1FA7 Load address of FARW
ENTRC FACS Call FACS
LTR R0,R0 Test for Error return
BZ EXCEPT Branch to error return
Before Call to FACE/FACS
FARW :
Before call to FACE/FACS
After call to FACE/FACS
FILE ADDRESS
Record Header
 All TPF Records have a standard Record header
 Record ID
 Control Byte
 Record code check
 Program stamp
 Optionally Some records also maintain Forward chains and Backward chains
 Standard Record Header Format :
BID CH USER
CTL PGM STAMP FCH BCH
K DATA
0 2 3 4 8 C 10
Record Id Record Code Control Byte last filing program Forward Chain (optional) Backward Chain (optional)
User data
Check
 The First 2 bytes in any TPF record is the "Record ID" , uniquely identifies a Record type
 The 3rd Byte is the Record Code Check or the RCC Byte
 Check byte to ensure integrity of the data structure
 Overflows have the same RCC as the Prime record
 The 4th Byte is the Control Byte
BIT 0 1=FORWARD CHAINING
BIT 1 1=BACKWARD CHAINING
BIT 2 1=L2 RECORD (1055)
BIT 3 SPARE
BIT 4 0=PRIME RECORD 1=CHAIN RECORD
BIT 5-6 SPARE
BIT 7 1=RECORD IN USE
 If set to X'00' the control byte is not used.
 TPF Program's Record Header is Different in that case, it has the size of the program instead of
RCC and Control Byte
 Program Stamp Field is the 4-character TPF Program name
File Address Reference Word & Error Indicators
 Let’s have a look at the components that make the FARW in detail.
 FARWs are of 8 bytes in length and start on a doubleword boundary.
 The file address reference word address has in it a reference to a file address.
 The following the is the format of File Address Reference Word.
 Record Id
 Record Code check
 Control byte
 File address
 To access a record, it is required that all these fields are set by the application.
 If the record accessed is a fixed file, the file address can be computed. In case of pool files, it
should be copied from the embedded source.
 Two fields in the ECB are used to indicate unusual conditions associated with I/O requests:
 CE1SUG is a 1-byte gross or summary indicator of all unusual conditions occurring on any level.
 CE1SUD is a series of 16 indicators--1 byte for each level.
 The application should never clear or modify CE1SUG, and check CE1SUD immediately after an
I/O request has ended.
 TPF resets CE1SUG and CE1SUD after each WAITC function call.
Record Id Attribute Table (RIAT)
 System Table Describing Record characteristics by Record ID
 Contains information for all fixed and Pool records
 Describes for each record ID
 Record size for prime
 Record size for overflow
 Type of Pool to be used
 Other characteristics used by TPF, Like logging, exception logging, VFA Candidacy,
DASD Caching.
 Characteristics looked up by TPF , When applications request for File pools based on Record ID'S
File Retrieval
 Application Requests to retrieve a file (Fixed or Pool ) is Serviced by TPF
 Interface between Application and TPF for File Retrieval via FARW in the ECB
 Need to know file address before Retrieving a File
 TPF issues I/O to retrieve the File from Disk to Memory
 Need to wait for I/O to complete
 Find Request should be followed by an explicit wait if not implied
 ECB Loses control if implied wait specified
 Record ID in FARW compared with Record ID in the File copy of Record if Record ID in FARW
not set to X'0000'
 RCC in FARW if not X'00' is compared with the RCC of the file copy
 Record ID , RCC mismatches are indicated in CE1SUG and CE1SUD Fields of the ECB by TPF
 On successful completion of I/O ,
 TPF attaches a core block to the CBRW of the same data level
 The core block has the copy of the file contents
 FARW Set-up for File Retrieval
NOT
RECORD ID RCC USE FILE ADDRESS
D
Record Id Record Code Unused File address

Check
 Record ID can either be setup or set to X'0000'

 RCC can be setup or set to X'0000'
 File address should contain the 4-Byte SON address of the file being retrieved
 CE1SUD & CE1SUG are return codes by TPF in the ECB
 CE1SUG
 EQU X'80' I/O HARDWARE ERROR

 EQU X'40' ID CHECK FAILURE
 EQU X'20' RCC CHECK FAILURE
 EQU X'02' INVALID FILE ADDRESS
 All file retrieval requests are read into a Software cache area in Main memory , VFA (Virtual File
Accessing)
 It remains in the VFA if it is a VFA Candidate , Candidacy defined in the RIAT
 Subsequent Requests for file retrieval is done from the VFA Copy
 No I/O issued for Reads satisfied from VFA , ECB Does not lose control
 VFA : Transparent to applications, Designed to improve performance , Reduces DISK I/O
FINDC - Find a File and attach to ECB
Function  Reads a record from File and attaches it to ECB
 A Core block the size of the record is attached to data level CBRW
 The file could be retrieved from VFA
Format
FINDC Dn
Description  Dn - The datalevel at which the FARW is set up and the CBRW that will
have the core block attached , the values may be (D0-DF)
 FARW Should contain a file address
 Record ID , RCC can be optionally set up in the FARW.
Return Conditions  CBRW Contains address ,size and type of core block with copy of file if
located
 FARW Remains unchanged
 On error , CE1SUG and CE1SUD have error codes
Errors Possible  Ctrl-22 Find issued on a data level already holding a block
 Ctrl-2D Zero File address
Programming  An explicit wait should be issued to lose control after FINDC
Considerations
Examples  The following code Finds the file in the FARW and gets a copy attached to
data level 6.
FINDC D6
WAITC - Wait for all I/O for ECB to complete
Function  Suspends the ECB when it has an outstanding I/O request ,
 WAITC macro checks for outstanding I/O if any for the ECB , The ECB
Field CE1IOC is checked for this
 If there is one it suspends the ECB and resets the Program time-out counter
to '0'
 If there was an error return from the I/O , control is transferred to the
location of the error_label
 For successful I/O's or when there is no Pending I/O's control is passed to
the NSI
Format
WAITC error_label
Description  Dn - The datalevel at which the FARW is set up and the CBRW that will
Input Conditions  None.
Return Conditions  ECB Suspended if I/O outstanding
 Return to NSI if normal I/O completion
 Transfer to error_label on a hardware error or an unusual condition
Errors Possible  None.
Programming  Single WAITC can be issued for multiple I/O requests , Two FINDC'S
Considerations followed by a WAITC.
Examples  Wait for I/O,FINDERR if find error
WAITC FINDERR
FINWC - FINDC & WAITC
Function  Reads a record from File and attaches it to ECB
 Issues a WAITC to ensure completion of I/O
 Resets the Program time-out counter to '0' if not reading from VFA
Format
FINWC Dn,error_label
 error_label - Program location to branch to on error returns from FINWC
 FARW of the data level should contain a file address
 Record ID , RCC can be optionally set up in the FARW

located
 All pending I/O for this ECB is completed , CE1IOC = 0
 On error , CE1SUG and CE1SUD have error codes and control is
transferred to error_label
 Ctrl-2D Zero file address
Examples  The following code Finds the file in the FARW and gets a copy attached to
data level 6.
FINWC D6,FINDERR
File update Mechanism
 To achieve data integrity and to ensure sequential updation, The File update mechanism is
controlled by TPF
 Need to Hold any Record before updating it
 To update an overflow record hold the Prime Record (This is an application programming rule to
be strictly adhered to)
 Simultaneous hold requests are queued up by TPF
 Only one ECB Can hold a record at one instance
 Application should know the SON File address to update
 A "FIND with HOLD" should be issued
 The ECB Could lose control (If Record not in VFA)
 Need to wait for I/O to return Implicitly or Explicitly
 TPF Maintains a "HOLD TABLE" to keep track of ECB'S holding records and Queues for a file
 Release "as soon as" you have finished updating the file , so that other ECB's in queue can gain
hold status on the file
 A record in the hold table can still be accessed by an ECB that wants to retrieve it without
updating
 Avoid Holding more than a Record at one instance in a ECB Life
 Could Lead to a "DEADLOCK" condition
Example :
Program ABCD Program ZZZZ
HOLD Record "A" -----------------
WAIT TO GET FILE HOLD Record "B"
------------------- WAIT TO GET FILE
------------------- -------------------
HOLD Record "B" -------------------
WAIT TO GET FILE -------------------
------------------- HOLD Record "A"
------------------- WAIT TO GET FILE
 Both Programs ABCD and ZZZZ will wait for ever hoping that the other Program would
unhold the file , This is a Deadlock situation , caused due to Simultaneous Hold of more
than a Record
File update Mechanism
 TPF Maintains a Hold counter in the ECB in a one byte Field CE1HLD
 Maximum files that can be held by an ECB at one instance is 256
 Installations have Deadlock detection mechanisms to solve deadlocks caused by misbehaving
applications
 On successful completion of I/O request to hold ,
 TPF attaches a core block to the CBRW of the same data level
 The core block has the copy of the file contents
 The CE1HLD Hold counter is incremented by 1
 After updates done to a file Application has to "FILE" the record to write to DASD (or VFA)
 The FARW set up for "FIND with HOLD" is the same as for a "FIND without HOLD" (File
retrieval)
 The CBRW at the data level used for filing should have a core block attached which will be used
to write over the file copy , No core block : Dump Taken
 FARW Set-up for File update
NOT
RECORD ID RCC USE FILE ADDRESS
D
Record Id Record Code Unused File address

Check
 Record ID in FARW should be same as in Core block at that level , Record ID X'0000' in FARW
will lead to a System error (Dump!!)
 RCC in FARW is checked against RCC in core block, RCC of Zero indicates no RCC used
 File address should contain the 4-Byte SON address of the file being retrieved (Previously used to
Find with Hold!!)
 Core block released from CBRW after file
 VFA Delay Candidate records get written to VFA and not to DASD
 Subsequent retrieval requests for these records for read or update is satisfied from VFA
FINHC - Find a File with Hold
Function  Reads a record from File attaches it to ECB and Holds it
 Gives the ECB Exclusive ownership to update the File
 Hold table is updated with the ECB and file address
Format
FINHC Dn
located
 CE1HLD incremented by 1 , after find and hold successful
 Ctrl-FC ECB attempts to hold more than 256 Records
 Ctrl-21 (Catastrophic) Record hold table full
 Ctrl-35 Attempt to hold same record more than once
Programming  An explicit wait should be issued to lose control after FINHC
Considerations  You can Hold only upto 256 records at a time
 Advisable not to hold two records at a time , Unless inevitable and not a
potential deadlock situation
 Can not hold the same record more than once without releasing it
 Do not issue a DEFER macro while holding a record
Examples  The following code Finds with hold the file in the FARW and gets a copy
attached to data level 6.
FINHC D6
FIWHC - FINHC & WAITC
Function  Reads a record from File attaches it to ECB and Holds it
 Issues an implicit wait to ensure completion of I/O
 Gives the ECB Exclusive ownership to update the File
 Hold table is updated with the ECB and file address
Format
FIWHC Dn,error_label
 error_label - Program location to branch to on error returns from FINWC
Return Conditions  Control is restored to the next sequential instruction (NSI) if no hardware
error or unusual error conditions occur.
 On error , CE1SUG and CE1SUD have error codes and control is
transferred to error_label
 The content of R14 and R15 is unknown. All other user registers are saved
across the call.
 CBRW Contains address ,size and type of core block with copy of file if
located
 CE1HLD incremented by 1 , after find and hold successful
 Ctrl-FC ECB attempts to hold more than 256 Records
 Ctrl-21 (Catastrophic) Record hold table full
 Ctrl-35 Attempt to hold same record more than once
Programming  You can Hold only upto 256 records at a time
Considerations  Advisable not to hold two records at a time , Unless inevitable and not a
potential deadlock situation
 Can not hold the same record more than once without releasing it
 Do not issue a DEFER macro while holding a record
 Returning common blocks should be ensured. They are not automatically
returned.
FIWHC - FINHC & WAITC
Examples  The following code Finds with hold and implicit wait the file in the FARW
and gets a copy attached to data level 6.
FIWHC D6,FINDERR
FILEC - Update the File copy of a Record
Function  FILEC writes a record in storage (core block ) to file
 Updates both Prime and dupe copy of the file
 File could write to VFA alone (If VFA Delay file candidate)
 Returns storage block to the system (RELCC) and out of the ECB EVM
 Filing program name updated in the record header by TPF
Format
FILEC Dn
Description  Dn - The datalevel at which the FARW is set up and the CBRW that has
the core block attached to be filed , The values may be (D0-DF)
Input Conditions  Core block must be attached to the specified data level
 File address , Record ID and RCC have to be set up in FARW
 File address, RID, RCC have to be equal in FARW and core block
Return Conditions  Record written to DASD or VFA
 CBRW block type set to indicate no block held (0001)
 Program stamp filed in record
 Core block invalidated from ECB EVM
 Control passes to NSI , No loss of control
 Filing errors reported to RO , TPF Schedules write when it is free
Errors Possible  Ctrl-2D Zero file address
 Ctrl-30 (Snap) Unable to file record to DASD
 Ctrl-2F File - RCC Check failure
 Ctrl-32 File - Block and record size disagree
 Ctrl-23 CBRW not holding a block
 Ctrl - 2E Record ID Check failure
Programming  Make sure RID is same in Core block and FARW , RID should not be =
Considerations x'0000'
 Use RCC = 0 if not using Record code check
 Do not use the core block in the CBRW after FILEC
 Success of FILE cannot be checked by the program
 CBRW / FARW can be used for other purposes on return
 Ensure size of record and size in CBRW are the same
FILEC - Update the File copy of a Record
Example  The following code Files a record attached to data level 5 to DASD.
FILEC D5
FILNC - File a record with no release
Function  FILNC writes a record in storage (core block ) to file
 Core block in storage not removed from the ECB EVM
 Core block accessible only after file completes , Need to wait
 File could write to VFA alone (If VFA Delay file candidate)
 Filing program name updated in the record header by TPF
 Equivalent to checkpointing a record to file
Format
FILNC Dn
Input Conditions  Core block must be attached to the specified data level
 File address , Record ID and RCC have to be set up in FARW
 F.A ,RID ,RCC have to be equal in FARW and core block
Return Conditions  Record written to DASD or VFA
 Program stamp filed in record
 Control passes to NSI , No loss of control
 FARW , CBRW Remains unchanged
 Filing errors reported to RO , TPF Schedules write when it is free
Errors Possible  Ctrl-2D Zero file address
 Ctrl-30 (Snap) Unable to file record to DASD
 Ctrl-2F File - RCC Check failure
 Ctrl-32 File - Block and record size disagree
 Ctrl-23 CBRW not holding a block
 Ctrl - 2E Record ID Check failure
 Ctrl - 27 Core block held at data level at post interrupt time
 Ctrl - 3F error occurred during FILNC Processing (Return to appln)
Programming  Make sure RID is same in Core block and FARW , RID should not be =
Considerations x'0000'
 Use RCC = 0 if not using Record code check
 Success of FILE cannot be checked by the program
 Ensure size of record and size in CBRW are the same
 Have to code WAITC after FILNC
FILNC - File a record with no release
Example  The following code checkpoints a record attached to data level 5 to DASD
without releasing the core block.
FILNC D5
UNFRC - Unhold a File record
Function  Releases the ECB Hold from a file address
 Gives hold on file to any ECB in hold Queue
 Updates Hold table
 Decrements CE1HLD by 1
Format
UNFRC Dn
Description  Dn - The datalevel at which the FARW is set up , The values may be (D0-
DF).
Input Conditions  FARW Should contain a file address held by the ECB
Return Conditions  Control is returned to NSI

 ECB in Hold Queue gets hold status
 No loss of control
 The contents of R14 , R15 is unknown , All other user registers are saved
across the call
 CE1HLD decremented by 1
Errors Possible  Ctrl - 2D Zero file address
 Ctrl - 24 Attempt to unhold an address not being held
Programming  Do not issue a unhold on a record not being held
Considerations  UNFRC immediately after filing (FILEC)
Examples  The following code Unholds a record in data level 5 after filing it
UNFRC D5
FILUC - FILEC & UNFRC
Function  Same as a combination of FILEC and UNFRC
 Cannot use the core block attached to CBRW after FILUC
 ECB in hold queue gets ownership of file
 CE1HLD Decremented
 Update prime & dupe , May write to VFA
Format
FILUC Dn
Input Conditions  FARW Should contain a file address held by the ECB
Return Conditions  FARW Remains unchanged

 ECB in Hold Queue gets hold status
 No loss of control
 The contents of R14 , R15 is unknown , All other user registers are saved
across the call
 CE1HLD decremented by 1
 Core block released from ECB EVM
Errors Possible  All system errors that could occur on either FILEC or UNFRC
Programming  Programming considerations of FILEC and UNFRC apply

Considerations  This mechanism to File and unhold is preferred over FILEC followed by
UNFRC
Example  The following code file and unholds a record in data level 5 after filing it
FILUC D5
RCHKA - Get Record code check
Function  Generates a Record code check value
 Returns a value from 1 to 254
 Can be used to generate a check value to use in a record' RCC
 Uses Global field @RCHKA
Format
RCHKA REG = Rn
Description  Rn - Any application register (other than R0, R14, and R15) that will
contain a variable value to be used as the record code check. If not coded
defaults to register R15
Input Conditions  GLOBZ should have been issued and base register should be valid
Return Conditions  The new value of RCC IS IN Low order byte of input register
 Global field @RCHKA is incremented by 1
Programming  Use RCHKA to get RCC for prime record and use the same RCC for
Considerations overflows to ensure integrity
 RCHKA issues GLMOD and FILKW
Examples  The following code gets an RCC From system and uses it
RCHKA REG=R5
GETFC - Get pool file storage address , any size
Function  Obtains a pool file storage record address of any size
 Pool type and size is based upon the Record ID as defined in RIAT
 Returns File address that can be used for storage
 Only means of obtaining a 4K File pool address
 Optionally can obtain a core block
Format
GETFC Dn,[P/O],ID=sd/RyERROR=,BLOCK=,COMMON=,FILL=
Description  Dn - The datalevel at which the FARW will be set up and the CBRW that
could have the core block attached , The values may be (D0-DF)
 P/O - P stands for Prime and O stands for Overflow , RIAT attributes are
specified separately for Prime and overflow of a record , This field specifies if
Prime pool file is required or an overflow pool file is required
 ID - A valid Record ID defined in the RIAT , sd , A self defining term or Ry a
register which has a right justified Hexadecimal Record ID
 ERROR - YES|NO , If yes return is made to caller on an error , If NO then a
system error occurs on errors , Defaults to NO
 BLOCK - YES|NO , If YES , a storage block the size of the file pool will be
attached to the designated level , If NO, no storage block is obtained , Defaults
to NO
 COMMON - YES|NO , If YES is coded, then the storage comes from the pool
of shared main storage . Any ECB can access the storage block. If NO is
coded then the storage is unique to this ECB, NO is the default.
 FILL - Used in combination with the Block parameter , Specify a One-byte
hexadecimal value to initialize the storage block with , If FILL not specified
the storage block could have junk
Input Conditions  The Record ID , should be defined in the RIAT Table
 The data level should not be holding a core block if BLOCK=YES is specified
Return  R14 and R15 is corrupted , If BLOCK = YES is coded then R14 contains the
Conditions base address of the core block
 A SON pool file record address is placed in the FARW of the data level as
defined by the RIAT attribute
 If ERROR= YES Is coded , CC= 0 is a good return , CC=3 means Record ID
is invalid or the Record ID is not defined in the RIAT
GETFC - Get pool file storage address , any size
Errors Possible  Ctrl - 6E2 Record ID not present in RIAT

 Ctrl - 6E4 Invalid RIAT attributes for Record ID
Programming  Only One record address can be obtained at a time
Considerations  All addresses obtained should be released back to the system after use (By this
ECB or by subsequent ECB'S)
 Release a record only once
 GETFC may result in an implied wait
 Do not use COMMON = YES unless required , Common blocks are scare
resources
 Initializing Storage with a fill value takes more CPU Resource
 The macro should only be issued above 1052 state
Examples  The following code gets a Large Long term file pool address for Record ID
C'AB' at the FARW in level D0 and also attaches a block to the CBRW at D0
and initializes it with X'00'
GETFC D0,O,ID=C'AB',BLOCK=YES,FILL=00
RELFC - Release a file pool address
Function  Releases and returns back a file pool address back to the system
 The released address will be reused , TPF will issue to other ECB'S
Requesting file pool address
 TPF Determines if short term pool or long term pool , size etc and releases
to appropriate pool
 Separate mechanisms to release pools for short term and long term pools
Format
RELFC Dn
Description  Dn - The datalevel at which the FARW is set up , The values may be
(D0-DF)
Input Conditions  The FARW in the data level must contain a File address which has been
previously issued from the system using a get file pool macro and should
not have been released as yet
Errors Possible  Ctrl - F Double release of file pool address
Programming  Only One record address can be released at a time

Considerations  All addresses obtained should be released back to the system after use
 Release a record only once
Example  The following code releases a pool address at the FARW in level D0
RELFC D0
RLCHA - Release chain of file addresses
Function  Releases the file address of a record and any files chained to it as forward
chains
 Matches Record ID and RCC in FARW with that in file before releasing
 The released address will be reused , TPF will issue to other ECB'S
Requesting file pool address
 TPF Determines if short term pool or long term pool , size etc and releases it
to appropriate pool
 Separate mechanisms to release pools for short term and long term pools
 Issues system error on ID/RCC mismatch , hardware error etc
 Creates ECB'S to release chained addresses
Format
RLCHA
Input Conditions  R14 should be available for use

 R15 must point to a 12-Byte field formatted as follows
Bytes Contents
0-1 Basic ID
2 Record Code Check
3-7 Not used
8-11 File address of first record to be released.
Return Conditions  The CBRW at the specified level is updated.
 R14 has the address of the block assigned.
Errors Possible  Ctrl - F Double release of file pool address (Name of program that issued
RLCHA is flagged in the dump)
 Ctrl - FFFFFC Error while trying to release chain of pool addresses ,
Remaining chain not released
Programming  All records in chain should have same record ID and code check as the first
Considerations record in chain
 After RLCHA R14 will contain F'12'
 RLCHA is expensive , Creates ECB'S may deplete storage
Example  The following code releases a pool address chain set up at location EBX000
RLCHA
Processor Management
Synopsis
 Lists in TPF
 Job arrival to TPF
 Control Transfer between programs
 Enter-back macros
 Created ECBs
 ECB creation macro
 Related areas
Lists in TPF
 TPF employs 'Job lists' (also called Queues) for job execution.
 TPF Priorities Queues while servicing them.
 Processes are serviced in a First come First served basis within the same Queue
 The following are the lists in TPF (highest priority to lowest priority order)
 Cross List
 Ready List
 Input List
 Defer List
 Time Available Supervisor
 Cross list is used to exchange work items between I-Streams in a tightly coupled multiprocessor
system.
 Ready list contains processes that have completed the I/O operations they initiated .
 Input list contains input messages that have arrived into the system. These messages will wait to
get processed.
 Defer list contains processes which are of low priority. A process will end up in this list by issuing
a macro to give up control or if it was created and designated by the parent ECB to this list.
 Time available supervisor (TAS) is the queue designated for low priority jobs.
 The lists are processed in the order specified.
 TPF services lists one after another, i.e. All the items in a queue will be dispatched before the next
list is handled.
Job arrival to TPF
 Job arrives into TPF from any of these three roots.

 An entry given from a terminal
 An ECB which was suspended, waiting for I/O completion.
 An ECB creates another ECB.
 The following table shows to which list the job goes after entering into the system.
Terminal Entries / Other Hosts Input list, TAS (if low priority)*
Waiting ECBs Ready List
Created ECBs Ready list, Input list, Defer list

Control Transfer between Programs
 To process an entry, a process has to enter many programs in TPF.

 TPF supports four mechanisms of control transfers between E-type programs in TPF.
 Enter and No return (ENTNC)
 Enter and return (ENTRC)
 Enter and drop references (ENTDC)
 Return control back (BACKC)
 BACKC - Returns the control back to the recent calling program.
 When a program is entered, the execution is started from the first instruction in the program.
 Where as, when the control is handed back as the result of a BACKC macro, the NSI after the
ENTER call is executed.
ENTRC
 When a program issues a return call, control is transferred to the called program. The control is
returned back to the calling program on BACKC.
Program ABCD
-----------------
---------------
Program XYZ1 Program XYZ2
--------------
----------------- -----------------
-----------------
--------------- ---------------
ENTRC XYZ1
-------------- --------------
Label1 --------
----------------- -----------------
-------------------
ENTRC XYZ2 BACKC
Label2-------- ---------------
------------------- -------------------
BACKC
None ABCD ABCD,XYZ1 ABCD,XYZ1,XYZ2 (Nesting on

entry)
None None ABCD ABCD,XYZ1 (Nesting on
return)
Control Transfer between Programs
ENTNC
 When a program issues a no return call, the control is transferred to the called program. The ECB
doesn't come back to the calling program.
Program ABCD Program XYZ1 Program XYZ2

----------------- ----------------- -----------------
--------------- --------------- ---------------
-------------- -------------- --------------
----------------- ----------------- -----------------
ENTRC XYZ1 ENTNC XYZ2 BACKC
Label1 -------- Label2 -------- ---------------
------------------- ------------------- -------------------
None ABCD ABCD ABCD (Nesting on entry)

None None -NOCONTROL- ABCD (Nesting on
return)
ENTDC
 This call forces the control to be transferred to the called program, like the no return call. In
addition, the program nesting area is cleared.
None ABCD XYZ1 XYZ1 (Nesting on entry)
Program ABCD Program XYZ1 Program XYZ2

----------------- ----------------- -----------------
--------------- --------------- ---------------
-------------- -------------- --------------
----------------- ----------------- -----------------
ENTRC XYZ1 ENTDC XYZ2 BACKC
Label1 -------- Label2 -------- ------ --------
------------------- ------------------- -------------------
BACKC (??!!)
None None None XYZ1 (Nesting on return)

Point of no-return!!! (ECB dumps and exits)
ENTRC - Enter Program with return
Function  Transfers control to the specified program.
 Saves the NSI for return when a BACKC is issued.
Format
[Label]ENTRC prog
Description Prog - The name of the program to which the control should be transferred.
Macro Type FLM
Input Conditions R9 should be pointing to the ECB that is being processed.

 Contents of R14 and R15 are unknown.
 Registers R0-R7 have the values as it was when BACKC was issued. The
values are not preserved across control transfer.
Error Conditions  Ctrl-65. The file address of the program is incorrect. ECB exited.
 Ctrl-67. Program retrieval error other than hardware and File address
corruption. ECB exited.
 Ctrl-68. The program type in PAT is invalid. ECB exited.
 Ctrl-6A. Invalid program name or PAT index corrupted.
 Ctrl-6B. Attempt to enter dummy program.
 Ctrl-6C. Attempt to enter spare program.
 Ctrl-60. ECB exits program nesting levels allowed.
 Ctrl-63. Program not found in the system or program header corrupted.
Macro Restrictions No authorization required.
Programming None
Considerations
Examples The following piece of code enters the program LOL1.
ENTRC LOL1 Enter utility for send
LTR R1,R1 Check if error returned
BNZ ERROR If error branch out.
ENTNC - Enter program without return
 The control will not be returned to this program if a BACKC is issued.
Format
[Label] ENTNC prog
Macro Type FLM
Input conditions R9 should be pointing to the ECB that is being processed.
Return Conditions  Control is never restored to the next sequential instruction (NSI).
Restrictions  Control is restored to the next sequential instruction (NSI).
Programming Beware of the fact that the sequence of instructions after ENTNC, will be
Considerations unreachable code, if there is no branch targeting them.
ENTNC LOL1 Enter utility for send
ENTDC - Enter program drop reference

 Releases all the program records held by the ECB and clears the program
nesting levels.
 Control will not be returned to this program if a BACKC is issued.
Format
[Label] ENTDC prog
Macro Type FLM
Restrictions  Control is restored to the next sequential instruction (NSI).
Programming  Beware of the fact that the sequence of instructions after ENTDC, will be
 Using an ENTDC between a ENTRC and a BACKC call results in an error.
ENTDC LOL1 Enter utility for send
BACKC - Go to the previous program
Function Transfers control to the last program held by the ECB that issued an ENTRC.
Format
[Label] BACKC
Description Takes no parameters.
Macro Type FLM
Error Conditions  Ctrl-61. No program nested. BACKC cannot find a program to return back
control.
Programming Beware of the fact that the sequence of instructions after BACKC, will be
Examples The following piece of code returns control back to the caller.
BACKC Lets go back
DLAYC - Delay processing
Function  Delays entry processing and gives up control for some other ECB.
 Puts the ECB at the end of the Ready list.
Format
[Label] DLAYC
Macro Type SVC
Return Conditions  Control Transferred to NSI

 All other registers are preserved.
 The condition code is unknown.
Error Conditions None
Programming  Issuing delay hurts the performance as this causes core depletion.
Considerations  An ECB holding a record or a resource should not issue a delay. This may
result in input list lockout.
Examples The following piece of code delays the processing.
DLAYC lets wait for sometime.
DEFRC - Defer processing
Function  Defers entry processing and gives up control for some other ECB.
 Will wait until the system activity is low.
 Places the ECB at the end of the defer list.
Format
[Label] DEFRC
Macro Type SVC
Input conditions  R9 should be pointing to the ECB that is being processed.

 No file record should be held.
Return Conditions  Control is returned to the next sequential instruction (NSI).
 All other registers are preserved.
 The condition code is unknown.
Error Conditions Ctrl-D. Defer issued holding a record.
Programming Issuing delay hurts the performance as this causes core depletion.
Considerations
Examples The following piece of code defers the processing.
DEFRC lets wait for sometime.
EXITC - Exit the ECB
Function  Ends the life of the ECB.

 All the core blocks, program records held by the ECB are automatically
released.
 The ECB itself is released.
Format
[Label] EXITC
Macro Type SVC

 All records held should have been released.
Return Conditions Control is never restored to the program issuing the call.
Error Conditions  Ctrl-8. Holding a record during exit

 Ctrl-13. Tape open at exit time.
Programming None
Considerations
Examples The following piece of code exits the ECB.
EXITC Time to rest in peace!!
Created ECBs
 It's very often needed to subdivide a task and entrust the function to multiple processes.
 This is to achieve multi threading, which will result in faster execution and response time.
 TPF achieves this by a set of macros that can create ECBs.
 Once an ECB is created by TPF, the ECB is totally independent from the parent.
 The only association is the CE1TRC field which will have the parent program name.
 The parent can pass information through work areas.
 Some deviants allow passing core blocks.
 Different macros permit putting the ECBs in different lists.
CREDC - Create a deferred Entry
Function  Creates an ECB for deferred processing.

 The caller can pass up to a maximum of 104 bytes of parameters to the
newly created ECB.
 The parameters are copied to a SWB and is filed to the defer list.
 Once this block is serviced, the OPZERO creates the ECB.
 Copies the parameters in work area EBW000 onwards.
 ENTNCs to the program specified.
Format
[Label] CREDC prog
Macro Type SVC

 R14 should have the number of bytes to be passed.
 R15 should have the beginning address of the parameter list.
Return Conditions  The control is returned back to the NSI.
 The contents of R14 and R15 are unknown.
 Other registers are preserved across the call.
Error Conditions  Ctrl-14. The length of the parameter list more than maximum.
 Ctrl-E4. The program file address found corrupted.
Programming Use this macro with care as this macro can cause core depletion.
Considerations
Examples The following piece of code creates an ECB, transfers control to program LOL1.
LA R14,4 length
LA R15,EBX034 address
CREDC LOL1 let the child do the job!
CREMC - Create ECB for immediate Entry
Function  Creates an independent ECB.

newly created ECB.
 The parameter is copied to a SWB and is added to the ready list.
Format
[Label] CREMC prog
Macro Type SVC

Programming  The parent ECB issuing the macro may have to wait if there is insufficient
Considerations working storage.
 Use this macro with care as this macro can cause core depletion.
LA R14,4 length
CREMC LOL1 Time to rest in peace!!
CREXC - Create a deferred Entry
Function  Creates an ECB for deferred processing.

newly created ECB.
 The parameters are copied to a SWB and is filed to the defer list.
 Functions exactly the same way CREDC does, but the difference lies in the
fact that CREXC does extra checking regarding the availability of working
storage, before it creates the ECB.
Format
[Label] CREXC prog
Macro Type SVC

Programming The parent ECB issuing the macro may have to wait if there is insufficient
LA R14,4 length
CREXC LOL1 let the child do the job!
CREEC - Create ECB with core blocks
Function  Creates an independent ECB.

newly created ECB.
 The parameters are copied to a SWB and is added to the ready list or defer
list.
 Also, passes on the core block to the child ECB and attaches it at level D0
of the child ECB.
Format
[Label] CREEC prog,level/D0,R/D
Level - The data level in the parent ECB holding the core block to be passed. If
omitted, data level 0 is taken as default.
R - The created child should be put in the ready list for processing.
D - The created child should be put in the defer list for processing and this is the
default.
Macro Type SVC

 The CBRW at the level specified in the parent, will show that there is no
core block held.
 Ctrl-D0. The level specified is not holding a block.
CREEC - Create ECB with core blocks
Programming  The parent ECB issuing the macro may have to wait if there is insufficient
 Use this macro with care as this macro can cause core depletion.
 Passing parameter is optional. To ignore parameters, R14 should be made
zero.
 But, passing core block is mandatory with CREEC.
XR R14,R14
CREEC LOL1,D0,R Let the child work!!
CRETC - Create time initiated entry

Function  Enters the specified program after the given time interval is elapsed.
 The caller can pass 4 bytes of parameters to the newly created ECB.
 Also, passes on the core block to the child ECB and attaches it at level D0
of the child ECB.
 But, all these happen only when the specified time interval is elapsed.
Format
[Label] CRETCM/S,prog,level=Dn
Level - The data level in the parent ECB holding the core block to be passed. If
omitted, no core block is passed.
M - The time increment is in minutes.
S - The time increment is in seconds.
Macro Type SVC

 R14 should have the time interval specified in the rightmost 3 bytes.
 R15 should have the 4 byte parameter.
 The CBRW at the level specified in the parent, will show that there is no
core block held, if a core block is passed.
Error Conditions  Ctrl-D0. The level specified is not holding a block.
 Ctrl-E. CRET table full.
Programming  The parent ECB issuing the macro will return immediately.
Considerations  Passing parameter is mandatory. But, passing core block is optional with
CRETC.
Examples The following piece of code creates an ECB, transfers control to program LOL1,
after 10 minutes. It also passes a core block at level 0.
XR R14,R14
ICM R14,14,=XL3'10'
L R15,=C'DCOB'
CRETC M,LOL1,LEVEL=D0
Resource Checks
 TPF provides mechanisms so that the ECB can continue processing or give up control - gauging
the system resource availability.
 This sounds contradictory to the TPF phenomenon 'Allocate resource to entry - process it as early
as possible - exit it'.
 But, this is used only by those ECBs that do 'monster' processing by themselves, or by creating
siblings.
 Those ECBs will check the system resource levels and decide if they have to be 'suspended'.
 LODIC macro is used to achieve this.
 The resources checked for are the storage blocks.
 The ECB's suspension, depends upon the parameters passed during the macro call.
 The suspended ECBs will resume execution once the system resources are available.
System Errors
Synopsis
 System Dumps - Concepts
 Control Dumps
 OPR Dumps
 SNAP Dumps
 System Error Macro's
System Dumps - Concepts
 The TPF system takes a dump of core whenever an error occurs to provide information to debug .
 An error condition can either be detected by the system or by an application.
 Error detected by the system is usually a result of a program check like a protection exception or
an addressing exception.
 A deliberate System error dump can be issued by either the TPF SYSTEM (CP) or an application
program on error cases.
 This is done by coding a System error macro that simulates a program check and passes control to
the TPF System error Handler ( CPSE).
 On a System error the TPF System can
 Return control to the ECB
 Exit the ECB and go to the CPU Loop
 Take a catastrophic system error which can cause a Re-IPL
 A catastrophic system error may occur if there was a protection exception or an addressing
exception while the CP was executing or some other condition where the integrity of the system is
endangered.
 During a system dump core storage is written to Real time tapes RTA/RTL.
 These dumps are post-processed on offline systems (MVS) and analyzed to fix erring application
codes.
 Taking a system dump is expensive since all operations are suspended till the dump completes, all
I-streams paused, no I/O entertained.
 This to ensure that no core storage is altered at dump time.
 On system errors a message is sent to the RO Cras along with a dump to the tape.
 System dumps are classified into 3 categories
 Control Dumps
 Operational Dumps
 Snap Dumps
Control Dumps
 Control Dumps are issued by the TPF Control Program.
 Are taken when program exceptions are encountered and if error conditions occur.
 Example of program exception control dumps
 CTL - 3 : Protection exception
 CTL - 4 : Addressing exception
 Example of error condition control dumps
 CTL - 22 Find issued on a data level already holding a block
 CTL - FC ECB attempts to hold more than 256 records
 Control Dumps can also be catastrophic dumps, which can cause a System IPL. These are usually
fatal errors.
 Example of Catastrophic Dumps
 CTL - 1 Program error detected in CP
 CTL - 2 Virtual storage error in CP
 CTL - C No ECB's / SWB's / IOB's / FRAME's / CMB's available
 CTL - 21 Hold Table full
 On Catastrophic system errors
 Returns to top of CPU loop
 If another catastrophic dump in next 5 minutes , soft-IPL
 The contents in control dump are as follows
 Information on System configuration
 Status of each I-stream in the configuration
 System Trace table for each I-stream (Collated macro trace table and I/O trace table)
 ECB Virtual memory
 System storage beginning at X'1000' to end of SVM (This can be limited by setting up
individual dump options)
 Any other storage area required with a CTL-Dump can be specified in the dump storage
area definition for the dump.
 Control dumps are usually the result of bad application programs. These should be debugged and
fixed immediately.
 Control dumps usually exit the ECB and system continues normal operation after taking the dump.
OPR Dumps
 These are system errors issued by operational E-type application programs.
 These are issued by application programs while application errors are encountered.
 Example : OPR - A00500 : Carrier found in more than one
 flight record
 Operational Dumps are expensive since system is paused and all I/O is stopped during the period
of dump.
 Should not be coded by application programs if not necessary . Snapshot dumps should be
considered as an option.
 Operation dumps may choose to return to the ECB or exit the ECB.
 The contents in an operational dump are as follows
 Information on System configuration
 Status of each I-stream in the configuration
 System Trace table for each I-stream (Collated macro trace table and I/O trace table)
 ECB Virtual memory
 Contents of operational dump can be varied by setting up dump options.
SNAP Dumps
 Snap dumps take a snap shot of core areas.
 Inexpensive, since system is not paused and I/O's are not stopped.
 Effective alternative to system error dumps.
 Should be used if little information is necessary to describe an error condition.
 E.g. an invalid unprintable character can be found in an Output message block held in a data level.
The storage dump of the data block should suffice to fix the error. SNAP should be used to dump
the core block.
 TPF provides a mechanism to allow the operational program to decide the areas to be snap
dumped.
 Applications should code SNAP dumps whenever possible and avoid system error dumps.
SERRC - Issue System Error
Function  Take a storage dump and send message to console.
 Used whenever the Control program or an operational program detects an
error.
 All activity in all I-streams in the CPC suspended, I/O's frozen during the
period of system dump .
Format
[Label] SERRC Action,Errnum,Prefix=,
Msg=,ECB=,Sysdump=
Description Action - E|R
E : Exit the ECB associated with the error
R : Return to Next sequential Instruction
Errnum - 6 digit Hexadecimal error number (000001 - FFFFFF) ,
May be coded in one of the Following ways ,
A Hex number
A Symbolic equate defined in CZ1SE
In a Register ( 0 . . . 7 , 14 , 15 ) , If MSG = YES is
coded , then Register must not specify R0 .
Prefix - One character uppercase letter , I and W-Z are reserved by IBM ,
Defaults to I if issued from IBM code , U for user code
MSG= - YES|NO , If YES R0 should point to a storage location that contains
the message to be sent to console , The first byte of the message should have the
Length (MAX : 256 Bytes) , Simply MSG also can be coded , Default NO
ECB = YES|NO , If YES then EVM of the associated ECB is dumped , ECB
alone can be coded . Default NO
SYSDUMP = YES|NO , If YES then system storage is also dumped , Defaults to
NO for Operational programs and YES for the control program .
Macro Type INLINE (Invalid opcode, Operation exception)
Input conditions None.
Return Conditions  Control is restored to the next sequential instruction (NSI) if R is specified
on SERRC
 ECB exited if option E is specified on SERRC
 All Registers preserved on return to ECB.
SERRC - Issue System Error
Programming Consider using SNAP dumps wherever possible instead of coding SERRC.
Considerations
Examples  The following dump is issued by an operational program with exit
SERRC E,(D10267),PREFIX=D OPR-D10267 with exit
 The following dump is taken by an operational program with return and a

message is sent to console , also the EPA and SVM is dumped
LA R0,ERRMSG
SERRC R,
(CDF011),PREFIX=R,ECB,MSG,SYSDUMP=YES
ERRMSG DC AL1(ERREND-*-1)
DC C'ERROR DUE TO INVALID DATA'
ERREND EQU *
SNAPC - Take a snapshot Dump
Function  Takes a dump of storage areas specified by the Application.
 Can be used as an alternative to SERRC.
Format
[Label] SERRC Action,Errnum,Prefix=,
Msg=,Regs=,ECB=,List=,
Prefix=
Description Action - E|R
E : Exit the ECB associated with the error
R : Return to Next sequential Instruction
Snpnum - This is the snap number
May be coded in one of the Following ways ,
A Hex number X,0-7FFFFFFF'

A Symbolic equate enclosed in parentheses
In a Register ( 0 . . . 7 , 14 , 15
Prog - Label pointing to name of the program to be used in the

snap dump , If not specified 4 bytes beginning at
displacement 4 from R8 taken as program name
MSG= - Label which points to a storage location that contains the message to be
sent to console , The first byte of the message should have the Length (MAX :
256 Bytes)
ECB = - YES|NO , If YES then SS , SSU and terminal address is taken from the
ECB , Default YES , Do not code ECB=NO in application program since
control will go to CPU Loop
Prefix - One character uppercase letter , I and W-Z are reserved by IBM ,
Defaults to U
REGS - YES|NO , YES includes GPR's in dump , Defaults to NO
LIST = Label pointing to a location that describes the location and length of
storage to be dumped , Described by LISTC macros (Discussed next)
Macro Type INLINE
Return Conditions  Control is restored to the next sequential instruction (NSI) if R is specified ,
Exited if E is specified in SNAPC
 All Registers preserved on return to ECB
 Storage dump of specified core taken and CRAS set is notified.
SNAPC - Take a snapshot Dump
Programming SNAPC may use upto 8 4K blocks , Overflow data's will be truncated
Considerations
Examples The following Snap dump 666 is issued , with an error message defined at label
MESG , Terminal address is picked from ECB and Registers are included in the
Snap Dump
SNAPC R,666,MSG=MESG,REGS=YES,ECB=YES,
*
PREFIX=R Take snap Dump 666
MESG DC AL1(L'MESSAGE)
MESSAGE C'INVALID AIRLINE CODE'
LISTC - Generate Data items to dump
Function  LISTC Macro is used to generate a list of data items for SNAPC or SERCC
to dump
 Generates constants that identify the name , size and location of items to be
included in the SNAPC/SERRC dumps when LIST parameter is supplied
Format
[Label] LISTC TAG=,NAME=,LEN=,INDIR=,
level=
LISTC END
Description TAG = - Label that specifies the location of the data to be dumped , Required
unless LEVEL parameter is used
NAME= - Specifies name of the field to appear in the dump
LEN= - Symbolic or Passed in a user register , If not coded length defaults to
length of TAG
INDIR= - YES | NO , If YES then TAG Parameter points to a location of the 4-
byte address of the data to be dumped , NO which is the default specifies that
TAG points to the location of data to be dumped
LEVEL= - Dn , Specify a data level (D0 - DF) , Can be used instead of
TAG,LEN and INDIR , CE1CRx should contain storage address and CE1CCx
the length of data to be dumped , SNAPC ignored if level not holding block
END - Mutually exclusive with all other parameters , Signals the end of LISTC
items.
Macro Type INLINE
Input conditions  If LEN=Rx is coded , Rx should hold the length value

 If LEVEL=Dn is coded , Level should be holding a core block
Examples The following code uses a Snap dump 666 is issued with the List parameter
where the LISTC parameters are coded to dump 104 bytes of data beginning
from EBW000 , This will be identified in the dump under label WORKAREA ,
Datalevel 0 will also be dumped under the label DATALEV0
SNAPC R,666,REGS=YES,ECB=YES, *
PREFIX=R,LIST=SNAPLIST Take snap-
666
SNAPLIST
LISTC NAME=WORKAREA,TAG=EBW000,LEN=104
LISTC NAME=DATALEV0,LEVEL=D0
LISTC END
Globals
Synopsis
 Globals - The concept
 Organization of Global data
 Global Directories
 Global Blocks and Global Fields
 Global Records
 Accessing and updating Globals
 Globals Related Macros
Globals - The Concept
 Ancient mechanism to keep high access data in main memory.
 Quick response times on data accesses even at high system activity periods
 Avoids I/O Operation delay
 Used to
 Hold frequently accessed data in core e.g. Today's date , Host airline code
 Pass data between programs
 Data held in Global storage area is called as Global data or Just "Globals"
 Globals can be modified and accessed quickly without any delay for DASD I/O
 Can hold fields , Records or multiple records
 Data in Globals exists in fixed locations in Main memory (Core)
 Global data may also have a File copy in DASD
 Resides partly below the 16MB line called as primary Globals
 The Global data residing above the 16MB line is referred to as Extended Globals
 Primary Globals can be accessed even by programs running in 24-bit mode.
 Globals are initialized and loaded to the core during system restart as part of the cycle up process.
 TPF provides special mechanisms for applications to access Globals.
 Serialization and Synchronization of Globals as required in TCMP and LCMP environments is
also supported by TPF
 Global updates in core should also be filed to disk by Keypointing , TPF Provides mechanisms to
achieve this
 Inadvertent corruptions of Globals could prove disastrous.
Organization of Global data
 Organization of Globals in main memory (Core)
High
Page 0s
.
.
.
Extended
Extended ( Protected)
Globals Global Area 3
Extended
( Unprotected)
Global Area 2
Extended ( Protected)
Global Area 1
.
.
.
16MB .
.
.
GAT
Application Records
Global Blocks: Global

Area 3 ( Protected )
GLOBP, GLOBQ 4K
Directory – GLOBY
Primary
Globals
Records
Global
( Unprotected)
Area 2
Application Records
Global Blocks: Global

GLOBB, GLOBC, GLOBD, GLOBE, Area 1 ( Protected )
GLOBF, GLOBG
4K
Directory – GLOBA
.
.
.
Control Program Area
Low
Organization of Global data
 A Global directory acts as an index to Global Fields and Global records
 2 Global Directories are shipped with TPF
 Global Fields are organized into Global blocks
 Global Blocks immediately follow Global directories in core
 The Global directory and its Global block together cannot exceed 4K , This is a limit imposed by
the displacement in an effective address , since data in global blocks and global directory are
directly addressable using a displacement
 Global Records immediately follow Global Blocks in core
 Extended Globals are also indexed out of Global directories residing under the 16 MB line
Global Directories
 Global Directories are indices to Global Blocks (made up of Global Fields) and Global Records
 Two Global Directories come with TPF
 GLOBA
 GLOBY
 GLOBA is the Global directory for Global area 1 or GL1
 GLOBY is the Global directory for Global area 3 or GL3
 Global Directories consist of core address , file address pairs for Global blocks and Global records
 Core address and File address of a Global block or a Global Record in the directory is referred to
as a Directory slot
 A maximum of 256 directory Slots can be held in a global directory
 Both Directories have a Protect Key 'C'
 GLOBA and GLOBY are DSECTS that describe Global block and Global record slots
Global Directories
 Directory Structure
Core File address Core File

address of of Global address of address of
Global block1 Global Global
block1 block2 block2
Core File address Core File Core File

address of of Global address of address of address of address of
Global record1 Global Global Global Global
record1 record2 record2 record3 record3
Start of End of
Global Global
block1 block1
Start of
Global
block2
Start of
Global
record 1
Start of Global record 2

Global Blocks and Global Fields
 Global blocks follows Global directories in core
 Global Blocks are made up of Global Fields
 Each Global field is directly addressable using a Global field label after gaining addressability to
the Global directory as a base
 Each Global field could be from 1 to 256 bytes
 Normally names of Global fields start with a '@'
 Each global block is of size 1055 bytes
 Each Global Block has a DSECT defining individual Global fields layout within the Global block
Example:
@P9PDC DS F MAX # FLTS PER POST DEP CHKLST
@STTSF DS F FILE ADDR OF TYPE F STATUS TBL
@HAALC DS H H.A. AIRLINE CODE
@P9PNL DS H MAX # CONCURRENT PNLS PER FLT
 Conventionally Global blocks are named beginning with GL0B

 IBM Defined Global block DSECTS are named
In GL1 - GL0BB,GL0BC,GL0BD,GL0BE,GL0BF,GL0BG
In GL3 - GL0BP & GL0BQ
 Installations defined Global blocks also can be created
 Global blocks also have File copies , These are 1K Fixed file records with record type #GLOBL
and record ID 'GL'
Global Records
 Global Records Follow Global blocks immediately in core
 Global records are frequently accessed Fixed Files
 Example layout of global directory pointing to global records:
@3DAD8C DS F RES ABACUS DIRECT LINK RECORD CORE ADDRESS
@3DAD8F DS F RES ABACUS DIRECT LINK RECORD FILE ADDRESS
@3ALPRTA DS F RES AIRLINES DISPLAY PRIORITY TABLE C.A
@3ALPRTAF DS F RES AIRLINES DISPLAY PRIORITY TABLE F.A
@3COTCC DS F RES COT RECORD CORE ADDRESS
@3COTCCF DS F RES COT RECORD FILE ADDRESS
 The base core address and disk file address of these records follow directory slots for Global
blocks in the Global directory
 Only those part of the record that is necessary is held in core
 The number of bytes of record to be held in core is specified in number of double words in GOA
(Global allocator)
 Multiple records , header stripped and concatenated also can form a global record
Accessing and Updating Globals
Accessing:
Global Fields
i) Get addressability to Global Directory
ii) Access fields directly by name
Global Record
ii) Get core address of record
iii) Use core address as base address for the record and access it
Updating:
Global Field
ii) Change Protect Key to that of the Global
iii) Update value in fields directly by name
iv) Request to Keypoint if the global is Keypointable
Global Record
ii) Change Protect Key if Record protected
iii) Load the core address of the Global record
iv) Use core address as base address for the record and update it
v) Request to keypoint if Keypointable
Virtual File accessing (VFA)
 Software cache used to hold Frequently accessed files in core
 Records defined as VFA candidates in RIAT by record ID
 A Record can be defined as
 VFA delayed Filing
 VFA Immediate Filing
 VFA Immediate Filing Candidate Records are written to DASD for every update
 VFA delayed filing records are written to DASD only when
 They age out of VFA
 System Cycling down
 VFA Buffers flushed forcefully
 For all Read requests TPF looks up VFA first
 For all Writes , Written to VFA , Records are retained in VFA or filed to DASD depending upon
their VFA Characteristic
 VFA is ineffective in a LCMP configuration
 VFA Provides quick response to find and file Requests, Reduces number of Physical I/O to
DASD’s, TPF maintains a VFA Visit counter CE1VCT in the ECB.
GLOBZ - Get addressability to Globals
Function  Calls Global definition macros (Dsect using') for GL1 and GL3
 Establishes addressability to Global area in a specified register
 Establishes addressability to GLOBA or GLOBY
 Symbolic global field names can be used after the macro to access global
fields
 Symbolic record address names can be used to load base addresses of global
records after the macro is issued
Format
[Label] GLOBZFLD=,REGR=,REGS=
Description FLD - Specify a Global Symbol ,Global symbol used to determine the
global area in which the record descriptor is stored. Optional.
The GL0BA/GL0BY address will be returned in the specified register. One of
the REGx-keywords may be specified with FLD.
REGR - <Rx/NO>
Regr is an optional parameter , If Rx a register is coded , Rx is loaded with the
base address of GLOBA the GL1 Directory
If REGR = NO is coded , Only GL1 DSECTS are called , No addressability
established
REGS - <Ry/NO>
Regs is an optional parameter , If Ry a register is coded , Ry is loaded with the
base address of GLOBY the GL1 Directory
If REGR = NO is coded , Only GL3 DSECTS are called , No addressability
established
Macro Type INLINE
Input conditions At least one Regx parameter should be coded

 The content of R14 and R15 is unknown. All other user registers are saved
across the call.
 The register(s) defined as the operand(s) of the REGx=keyword(s) will be
loaded with the address(es) of the appropriate global area(s).
System Errors None
Programming None
Considerations
GLOBZ - Get addressability to Globals
Examples  The following code gets addressability to GL1 directory GLOBA in register
R15 and then reads the value of global field @U1DAY
GLOBZ REGR=R15 Get GLOBA addressability
MVC DATE,@U1DAY Move value in @U1DAY into DATE
This wouldn't work if @U1DAY is not defined in GL1

OR
GLOBZ FLD=@U1DAY,REGR=R15 GetGLOBA addressability
OR
GLOBZ FLD=@U1DAY,REGS=R15 Get GLOBA addressability

This would still work since , GLOBZ would know that @U1DAY is in GL1 and
would load the address of GLOBA in R15
 The following code gets addressability to GL1 directory GLOBA in register
R15 and then reads the core address of &RECORD and accesses it
L R3,@RECORD Load core addr of RECORD in R3
RECORD REG=R3 Use R3 as base address

CLC RECFLD,=C'FIELD' Access record field
This wouldn't work if @RECORD is not defined in GL1

OR
GLOBZ FLD=@RECORD,REGR=R15 Get GLOBA addressability
OR
GLOBZ FLD=@RECORD,REGS=R15 Get GLOBA addressability

This would still work since , GLOBZ would know that @RECORD is in GL1 and
would load the address of GLOBA in R15 after GLOBZ and subsequently the
address of RECORD in R3
GLMOD - Get Protect Key to update Globals
Function  Sets the Protect key in the PSW to that of the Global area to be updated
 Must restore Protect key after updating global
 Used for updating Globals
Format
[Label] GLMOD Symbol
Description Symbol - GLOBAL1 , for Global area 1
GLOBAL3 for Global area 3 (At SQ)
Both are equal Since both areas have the same protect Key , If no symbol
specified Defaults to GLOBAL1
Macro Type INLINE (Generates an SVC to another macro)

 PSW Protect key changed to that of the Global area
 R14,R15 corrupted across call , User registers preserved
System Errors None
Programming  No changes can be made to any main storage area other than the global
Considerations fields and core-resident application data records
 Don’t issue an implied or explicit WAIT
 Reset protect key after modifying global immediately after update
 Do not issue any ENTER to other programs
Examples The following code updates the @FIELD Global in GL1

L R3,@FIELD Load Global value of @FIELD
LA R3,1(R3) Increment @FIELD
GLMOD Get protect key to update Global
ST R3,@FIELD Update @FIELD
Reset Protect Key back
KEYRC - Restore Protect Key
Function Resets the Protect key to application protect key , in the PSW
Format
[Label] KEYRC
Description KEYRC
Macro Type SVC

 PSW Protect key changed to that of Working storage , The same as ECB'S ,
Data blocks and unprotected core
System Errors None
Programming  Use only when you have altered a Global or protected storage and to reset to
Considerations resume with the application code
 Issue KEYRC before accessing working storage and after updating a global
Examples The following code updates the @FIELD Global in GL1 and resets Protect key
back to normal

GLMOD Get protect key to update Global
KEYRC Reset Protect Key back
Keypoint the Global if it is Keypointable
FILKW - Request to keypoint Globals
Function  Sets keypointing of a global field or record
 Optionally resets Protect key
Format
[Label] FILKW symbol,
keypoint1,…,keypooint8,
FLD=
Description Symbol - R|N
R - Restore protect Key
N - Do not restore protect key , Keypoint only
Keypoint1 …. Keypoint8
Names of Keypointable Globals that have to be filed to DASD as they appear in

GLOBA / GLOBY
FLD - YES/NO
YES - Indicates one of the keypointed records is a Global field
NO - Indicates only global records are keypointed , Default
Macro Type INLINE ( Generates SVC for other macro's)
Input conditions Global fields must have been defined

 PSW Protect key changed to that of Working storage if 'R' Parameter is used
 If keypointing is active the file copies will be updated
System Errors None
Programming  Use only when you have altered a Global or protected storage and to reset to
Considerations resume with the application code
 Issue only on keypointable Globals
FILKW - Request to keypoint Globals
Examples The following code updates the @FIELD Global in GL1 and keypoints and
resets protect key if updated else simply resets the Protect key

TM INDIC,#BIT0 Should it be updated ?
BZ CONT No , do not update
GLMOD Get protect key
FILKW R,@FIELD,FLD=YES Keypoint Global
* field and reset protect key
CONT DS 0H
Tapes
Synopsis
 Tape Support in TPF
 Real Time tapes
 General Tapes
 Blocked Tapes support
 Real time Tape macros
 General Tape Macros
 Physical Tape macros
Tape Support in TPF
 TPF supports usage of magnetic tapes for online and offline processing.
 Tapes are used for both input and output to and from TPF system.
 Tapes are TPF's prime means of passing data to and receiving data from other systems.
 TPF Supports two categories of tapes:
 Real-time tapes
 General tapes
 Tapes are usually symbolically identified by a 3-character name.
 TPF System has tape drives attached to it. TPF can read or write to tapes mounted to these drives.
 TPF provides mechanisms for applications to reserve, open, read, write, assign tapes.
 Physical tape operations like rewind, backspace also can be done online on tapes by applications.
 Tapes are physically identified by their volume serial numbers.
 Output tapes are normally processed offline to analyze data by other systems such as MVS.
 This analysis can provide information such as system usage, performance. System errors and other
application related data.
 Tape devices are unique to a CPC.
 TPF uses labels to identify tapes.
 Tape labels hold details such as volser, tape status, retention period, date of creation, mode of
writing, etc.
 Tapes are used for data collection, recoup, capture, restore, dump processing and other application
data recording
Real Time tapes
 Real time tapes are used to
 Log transactions
 Collect System information
 Record storage dumps due to system errors, to be analyzed offline and debugged
 Real time tapes are used for output only.
 Any ECB can write to a real time tape.
 No exclusive ownership can be attained for a real time tape.
 Order of data is not guaranteed. Hence cannot expect consecutive record in a real time tape.
 Offline programs processing these tapes identify records of their need by special identification
mechanisms in data, like the Record ID.
 Real time tapes are named beginning with RT e.g. RTx.
 Example of real time tapes - RTA, RTL, RTU, RTV.
 Real time tapes - RTA and RTL should always be mounted to the system.
 RTA is the primary real time tape and RTL is the secondary real time tape.
General Tapes
 General tapes can be used for input or output.
 Used by application programs to transfer data to and from TPF.
 General tapes are mounted to the TPF System only when requested.
 Example: NSD, VPH, FAL etc
 General tapes must be opened before use and must be closed after use.
 General tapes can be reserved and assigned by an ECB. This provides a serialized use of a general
tape by ECB's.
 Special macros exist for operations on general tapes.
TPF Utilities & Advanced Mechanics
File Recoup
 File recoup is the process of returning released, reusable Long term file pool addresses to the
System
 It’s a critical Part of TPF System maintenance , Since Long-term pools are a limited resource
 Runs in multiple phases , Partly Online and the rest Offline under MVS
 Applications failing to release Pool addresses back to the system after use can cause pool depletion
 Long term pool addresses are lost in the following ways
 Application coding errors , That do not release file addresses when they should and
release file addresses when they should not , Referred to as Lost addresses and
erroneously available addresses respectively
 System Restart , Loses some addresses , Since last keypointed Directory records are used
after restart and addresses dispensed in the period is marked unused
 File Recoup
 Reconciles pool directories with actual status of pool area
 Provides summary error reports that can isolate an erring application
 Chain chases pool files from every fixed file and also from references
 Builds Pseudo directories reflecting actual status of pool area
 Consists of 7 phases , 3 Online and 4 Offline
 Running Recoup Phases 1- 4 is mandatory
 Recoup uses magnetic tapes as Recoup General tapes for creating the Pseudo Directories
 Reference to every Pool address in the system from fixed files should be defined to Recoup to
enable chain chasing
 Multiple releases of long term pool file addresses are also flagged out by Recoup
 Examples:
LOST ADDRESS:
Clearing the cargo detail record pool address from the cargo booking record without releasing the
address using RELFC
ERRONEOUSLY AVAILABLE ADDRESS:
Releasing the cargo detail record address using RELFC, but not cleaning up the reference to the
address in the Cargo booking record by clearing the field to zeroes
MULTIPLE RELEASE:
RELFC More than once on the same address, Sequel to erroneously available address
Utilities – Assorted
PDU
 All long term pool addresses released by applications using RELFC macro are written to RTA
Tapes
 PDU is the process of reading the RTA tapes and returning the addresses in the RTA Release
blocks back to the system
Capture
 Process of backing up copies of DASD Files on secondary storage media such as other DASD'D or
Tapes
 To ensure that critical data can be replaced in emergencies such as malfunctioning software and/or
hardware
 TPF Provides an Online capture facility that captures data records during normal system operation
 Usually performed during low activity periods , Affects system performance
 Each file storage device is copied to magnetic tape
Exception Logging
 Updates to files during capture is not reflected in the capture tapes since capture runs during
system operation
 These modifications should also be recorded to reflect the exact database state after capture
 When capture is running , CP intercepts all file requests , Checks if the file is captured already , If
yes then writes a copy of the record to the Exception tape if the record ID marked as an exception
recording candidate
 Records are marked as Exception recording candidates in the RIAT
 Short term pool records are not exception recording candidates
 Critical records should be exception logged
 The XCP tapes along with the Capture tapes (BXx) reflect the exact state of the database after the
completion of the capture
Restore
 File restore is the mechanism to restore a previously captured database in magnetic tapes to real
time DASD's
 A total restore (All modules) or a partial restore (Selected modules) can be performed
 File restore is rarely used , Only used when the Online database is destroyed
 Restore runs only in the UTIL System state , i.e. No system activity possible during restore
 Restore is most often used to update the Test systems to reflect the Production system
Utilities – Assorted
File Logging
 Record logging allows to log all updates to use specified record tapes to real - time logging tapes
 Record logging candidacy is defined by Record ID's in the RIAT
 Logging can be started or stopped during normal system operation
 Logged records are written to RTL or other logging tapes
 Record logging can be used as a means for file recovery against hardware failure
 Record logging requires additional system load and device requirements (Tapes ) during peak
activity periods
VPARS
 Software enhancement to VM that allows TPF to run in a Virtual machine without modifying
records on a TPF database
 Records modified by TPF are maintained on a VPARS database consisting of a few minidisks that
are attached as R/W minidisks to the VM VPARS ID
 There exists a TPF Base system that can be shared by many VPARS each having its own formatted
VPARS Database
 Read Only links needs to be provided to the TPF Base disks from the VPARS
 VPARS intercepts I/O from TPF , Files are written to the VPARS Database and the base system
remains unchanged
 VPARS Reduces hardware required to run Multiple TPF Test systems
 Backup , Restore , Checkpoint and Clear facilities are provided with VPARS
 These enable resuming testing from any point , or to start testing with a clean database
 Checkpoints can be set and cleared from the VPARS Database at any time , to ensure against data
corruption in the VPARS
DSECT Layouts
WA0AA – AAA
 Only the part of the DSECT that is needed for the practical labs is given here. The DSECT given
here is not complete.
WA0BID&S DS H RECORD ID=AA

WA0CHK&S DS X RECORD CODE CHECK
WA0CTL&S DS X CONTROL BYTE=X'A0'
WA0PGM&S DS F LAST PROGRAM ID
WA0FCH&S DS F FORWARD CHAIN ADDRESS
WA0BCH&S DS F NO BACKWARD CHAINING
* USED AS WA0AGA
ORG WA0BCH&S
WA0AGA&S DS F AGENT A SUSPENDED AAA ADD.
* (18-WS)
WA0AGB&S DS F AGENT B SUSPENDED AAA ADD.
WA0AGC&S DS F AGENT C SUSPENDED AAA ADD.
WA0AGD&S DS F AGENT D SUSPENDED AAA ADD.
WA0AGE&S DS F AGENT E SUSPENDED AAA ADD.
WA0SIO&S DS X SIGN IN CONTROL BYTE (18-WS)
* BIT 0=1 IF AGENT A SIGNED IN
* BIT 1=1 IF AGENT B SIGNED IN
* BIT 2=1 IF AGENT C SIGNED IN
* BIT 3=1 IF AGENT D SIGNED IN
* BIT 4=1 IF AGENT E SIGNED IN
* BITS 5-7 SPARE
WA0IOT&S DS X AGENT ACTIVE BYTE (18-WS)
* BIT 0=1 IF AGENT A ACTIVE
* BIT 1=1 IF AGENT B ACTIVE
* BIT 2=1 IF AGENT C ACTIVE
* BIT 3=1 IF AGENT D ACTIVE
* BIT 4=1 IF AGENT E ACTIVE
* BITS 5-7 SPARE
WA0SIN&S DS H TWO INITIALS OF AGENT
* USING SET. IF TTY ORIGINATED
* TWO CHAR. ALPHA OFFICE
* DESIGNATOR
WA0SIS&S DS H TWO ALPHA CHAR. AGENT DUTY CODE.
* IF TTY ORIGINATED TRANS. THEN
* TWO ALPHA AIRLINE CODE
WA0EX4&S DS XL2 AAA ORDINAL NO.(SET BY WGR)
WA0TY1&S DS X AGENT TYPE BYTE 1
WA0AA – AAA
* BIT 0=1 IF GENERAL SALES AGENT
* BIT 1=1 IF AGENCY SALES AGENT
* BIT 2=1 IF POST DEPARTURE AGENT
* BIT 3=1 IF TTY REJECT AGENT
* BIT 4=1 IF CENTRAL RES. CTL.
* BIT 5=1 IF SUPERVISOR
* BIT 6=1 IF PROGRAMMER
* BIT 7=1 IF TRAINING AGENT
#TASINE&S EQU X'01' TRAINING AGENT CY579S/H7
#PRSINE&S EQU X'02' PROGRAMMER CY579S/H7
#SUSINE&S EQU X'04' SUPERVISOR CY579S/H7
#RCSINE&S EQU X'08' CENTRAL RES. CTL. CY579S/H7
#TRSINE&S EQU X'10' TTY REJECT AGENT CY579S/H7
#PDSINE&S EQU X'20' POST DEPARTURE AGENT CY579S/H7
#ASSINE&S EQU X'40' AGENCY SALES AGENT CY579S/H7
#GSSINE&S EQU X'80' GENERAL SALES AGENT CY579S/H7
* CY579S/H7
WA0TY2&S DS X AGENT TYPE BYTE 2
* BIT 0=1 IF MESHING
* BIT 1=1 IF MSG. SWITCHING INTERCEPT
* BIT 2=1 IF CUSTOMER ENGINEER (CE) R/H6
* BIT 3=1 IF CIP AGENT JS587R/H6
* BIT 4=1 IF RCCA SUPVR (RS) (ULD) 7S/H2
* BIT 5=1 IF RCCA AGENT (RA) (ULD) 7S/H2
* BIT 6=1 IF FARE CONTROL AGENT (FC)
* BIT 7=1 IF ABACUS SYNCHRONISATION AGT
#FCSINE&S EQU X'02' FARE CONTROL AGENT CY579S/H7
#RASINE&S EQU X'04' RCCA AGENT (RA) (ULD) CY579S/H7
#RSSINE&S EQU X'08' RCCA SUPVR (RS) (ULD) CY579S/H7
#IPSINE&S EQU X'10' CIP AGENT CY579S/H7
#CESINE&S EQU X'20' CUSTOMER ENGINEER (SE) CY579S/H7
#MSSINE&S EQU X'40' MSG.SWITCHING INTERCEPT CY579S/H7
#MASINE&S EQU X'80' MESHING CY579S/H7
* CY579S/H7
WA0TCF&S DS H RO OFFICE DESIGNATOR(03-TOQ)
* IF WA0ET9(2)=1 OFFICE DESIGN'R
* FOR RO TTY.IF WA0ET9(2)=0 AND
* WA0TP3(1)=1, THEN IT CONTAINS
* THE LAST ENTERED TICKET PRINTER.
WA0OLD&S DS X BIT0=1 IF RET.PNR CONTAINS
* CORPORATE NAME
WA0AA – AAA
* BIT1-7 OLD NO.IN PARTY
WA0XPR&S DS X
ORG WA0XPR&S
DS X USED BY CARGO FOR TIME SHIFT AH067T/H5
WA0DCB&S DS H AIRLINE CODE THIS SET LOC.(WGR)
WA0TME&S DS H LAST RETRIEVED TIME. USED TO
* CONTROL THE MOVING OF
* INTERACTIVE AAAS OUT OF LCS.
WA0DAY&S DS CL2 SIGN IN DAY FIELD.
* GMT DAY NUMBER ON WHICH
* AGENT LAST SIGNED IN. MAY
* BE USED BY DATA COLLECTION
WA0ADR&S DS 0XL3 LNIATA OF TERMINAL SC749S/HJ
WA0LNB&S DS X A/S LINE NUMBER
EB0EB - ECB
EB0EB&CG1 DSECT
DS 0D
CE1CHW&CG1 DS F CHAIN WORD
CE1BAD&CG1 DS F POST INTERRUPT BRANCH ADDRESS
EBW000&CG1 DS 1C WORK AREA
EBW001&CG1 DS 1C *
EBW002&CG1 DS 1C *
EBW003&CG1 DS 1C *
EBW004&CG1 DS 1C *
EBW005&CG1 DS 1C *
EBW006&CG1 DS 1C *
EBW007&CG1 DS 1C *
EBW008&CG1 DS 1C *
EBW009&CG1 DS 1C *
EBW010&CG1 DS 1C *
EBW011&CG1 DS 1C *
EBW012&CG1 DS 1C *
EBW013&CG1 DS 1C *
EBW014&CG1 DS 1C *
EBW015&CG1 DS 1C *
EBW016&CG1 DS 1C *
EBW017&CG1 DS 1C *
EBW018&CG1 DS 1C *
EBW019&CG1 DS 1C *
EBW020&CG1 DS 1C *
EBW021&CG1 DS 1C *
EBW022&CG1 DS 1C *
EBW023&CG1 DS 1C *
EBW024&CG1 DS 1C *
EBW025&CG1 DS 1C *
EBW026&CG1 DS 1C *
EBW027&CG1 DS 1C *
EBW028&CG1 DS 1C *
EBW029&CG1 DS 1C *
EBW030&CG1 DS 1C *
EBW031&CG1 DS 1C *
EBW032&CG1 DS 1C *
EBW033&CG1 DS 1C *
EB0EB - ECB
EBW034&CG1 DS 1C *
EBW035&CG1 DS 1C *
EBW036&CG1 DS 1C *
EBW037&CG1 DS 1C *
EBW038&CG1 DS 1C *
EBW039&CG1 DS 1C *
EBW040&CG1 DS 1C *
EBW041&CG1 DS 1C *
EBW042&CG1 DS 1C *
EBW043&CG1 DS 1C *
EBW044&CG1 DS 1C *
EBW045&CG1 DS 1C *
EBW046&CG1 DS 1C *
EBW047&CG1 DS 1C *
EBW048&CG1 DS 1C *
EBW049&CG1 DS 1C *
EBW050&CG1 DS 1C *
EBW051&CG1 DS 1C *
EBW052&CG1 DS 1C *
EBW053&CG1 DS 1C *
EBW054&CG1 DS 1C *
EBW055&CG1 DS 1C *
EBW056&CG1 DS 1C *
EBW057&CG1 DS 1C *
EBW058&CG1 DS 1C *
EBW059&CG1 DS 1C *
EBW060&CG1 DS 1C *
EBW061&CG1 DS 1C *
EBW062&CG1 DS 1C *
EBW063&CG1 DS 1C *
EBW064&CG1 DS 1C *
EBW065&CG1 DS 1C *
EBW066&CG1 DS 1C *
EBW067&CG1 DS 1C *
EBW068&CG1 DS 1C *
EBW069&CG1 DS 1C *
EBW070&CG1 DS 1C *
EBW071&CG1 DS 1C *
EBW072&CG1 DS 1C *
EBW073&CG1 DS 1C *
EB0EB - ECB
EBW074&CG1 DS 1C *
EBW075&CG1 DS 1C *
EBW076&CG1 DS 1C *
EBW077&CG1 DS 1C *
EBW078&CG1 DS 1C *
EBW079&CG1 DS 1C *
EBW080&CG1 DS 1C *
EBW081&CG1 DS 1C *
EBW082&CG1 DS 1C *
EBW083&CG1 DS 1C *
EBW084&CG1 DS 1C *
EBW085&CG1 DS 1C *
EBW086&CG1 DS 1C *
EBW087&CG1 DS 1C *
EBW088&CG1 DS 1C *
EBW089&CG1 DS 1C *
EBW090&CG1 DS 1C *
EBW091&CG1 DS 1C *
EBW092&CG1 DS 1C *
EBW093&CG1 DS 1C *
EBW094&CG1 DS 1C *
EBW095&CG1 DS 1C *
EBW096&CG1 DS 1C *
EBW097&CG1 DS 1C *
EBW098&CG1 DS 1C *
EBW099&CG1 DS 1C *
EBW100&CG1 DS 1C *
EBW101&CG1 DS 1C *
EBW102&CG1 DS 1C *
EBW103&CG1 DS 1C *
EBSW01&CG1 DS 1B INTER-PROGRAM SWITCHES
EBSW02&CG1 DS 1B *
EBSW03&CG1 DS 1B *
EBRS01&CG1 DS 1B *
EBCM01&CG1 DS 1B INTRA-PROGRAM SWITCHES
EBCM02&CG1 DS 1B *
EBCM03&CG1 DS 1B *
EBER01&CG1 DS 1B *
ORG EBW000&CG1
CE1WKA&CG1 DS CL112 ECB WORK AREA
EB0EB - ECB
CE1FA0&CG1 DS F FILE ADDRESS REFERENCE WORD - 0
CE1FM0&CG1 DS C *
CE1FC0&CG1 DS C *
CE1FH0&CG1 DS C *
CE1FR0&CG1 DS C *
CE1FM1&CG1 DS C *
CE1FC1&CG1 DS C *
CE1FH1&CG1 DS C *
CE1FR1&CG1 DS C *
CE1FM2&CG1 DS C *
CE1FC2&CG1 DS C *
CE1FH2&CG1 DS C *
CE1FR2&CG1 DS C *
CE1FM3&CG1 DS C *
CE1FC3&CG1 DS C *
CE1FH3&CG1 DS C *
CE1FR3&CG1 DS C *
CE1FM4&CG1 DS C *
CE1FC4&CG1 DS C *
CE1FH4&CG1 DS C *
CE1FR4&CG1 DS C *
CE1FM5&CG1 DS C *
CE1FC5&CG1 DS C *
CE1FH5&CG1 DS C *
CE1FR5&CG1 DS C *
CE1FM6&CG1 DS C *
CE1FC6&CG1 DS C *
CE1FH6&CG1 DS C *
CE1FR6&CG1 DS C *
CE1FM7&CG1 DS C *
CE1FC7&CG1 DS C *
CE1FH7&CG1 DS C *
CE1FR7&CG1 DS C *
EB0EB - ECB
CE1FM8&CG1 DS C *
CE1FC8&CG1 DS C *
CE1FH8&CG1 DS C *
CE1FR8&CG1 DS C *
CE1FM9&CG1 DS C *
CE1FC9&CG1 DS C *
CE1FH9&CG1 DS C *
CE1FR9&CG1 DS C *
CE1FAA&CG1 DS F FILE ADDRESS REFERENCE WORD - A
CE1FMA&CG1 DS C *
CE1FCA&CG1 DS C *
CE1FHA&CG1 DS C *
CE1FRA&CG1 DS C *
CE1FAB&CG1 DS F FILE ADDRESS REFERENCE WORD - B
CE1FMB&CG1 DS C *
CE1FCB&CG1 DS C *
CE1FHB&CG1 DS C *
CE1FRB&CG1 DS C *
CE1FAC&CG1 DS F FILE ADDRESS REFERENCE WORD - C
CE1FMC&CG1 DS C *
CE1FCC&CG1 DS C *
CE1FHC&CG1 DS C *
CE1FRC&CG1 DS C *
CE1FAD&CG1 DS F FILE ADDRESS REFERENCE WORD - D
CE1FMD&CG1 DS C *
CE1FCD&CG1 DS C *
CE1FHD&CG1 DS C *
CE1FRD&CG1 DS C *
CE1FAE&CG1 DS F FILE ADDRESS REFERENCE WORD - E
CE1FME&CG1 DS C *
CE1FCE&CG1 DS C *
CE1FHE&CG1 DS C *
CE1FRE&CG1 DS C *
CE1FAF&CG1 DS F FILE ADDRESS REFERENCE WORD - F
CE1FMF&CG1 DS C *
CE1FCF&CG1 DS C *
CE1FHF&CG1 DS C *
CE1FRF&CG1 DS C *
EB0EB - ECB
CE1FAP&CG1 DS 2F FARW FOR PROGRAM CALL
ORG CE1FAP&CG1+4
CE1FMP&CG1 DS F *
CE1CR0&CG1 DS F CORE BLOCK REFERENCE WORD - 0
CE1CT0&CG1 DS H *
CE1CC0&CG1 DS H *
CE1CT1&CG1 DS H *
CE1CC1&CG1 DS H *
CE1CT2&CG1 DS H *
CE1CC2&CG1 DS H *
CE1CT3&CG1 DS H *
CE1CC3&CG1 DS H *
CE1CT4&CG1 DS H *
CE1CC4&CG1 DS H *
CE1CT5&CG1 DS H *
CE1CC5&CG1 DS H *
CE1CT6&CG1 DS H *
CE1CC6&CG1 DS H *
CE1CT7&CG1 DS H *
CE1CC7&CG1 DS H *
CE1CT8&CG1 DS H *
CE1CC8&CG1 DS H *
CE1CT9&CG1 DS H *
CE1CC9&CG1 DS H *
CE1CRA&CG1 DS F CORE BLOCK REFERENCE WORD - A
CE1CTA&CG1 DS H *
CE1CCA&CG1 DS H *
CE1CRB&CG1 DS F CORE BLOCK REFERENCE WORD - B
CE1CTB&CG1 DS H *
CE1CCB&CG1 DS H *
CE1CRC&CG1 DS F CORE BLOCK REFERENCE WORD - C
EB0EB - ECB
CE1CTC&CG1 DS H *
CE1CCC&CG1 DS H *
CE1CRD&CG1 DS F CORE BLOCK REFERENCE WORD - D
CE1CTD&CG1 DS H *
CE1CCD&CG1 DS H *
CE1CRE&CG1 DS F CORE BLOCK REFERENCE WORD - E
CE1CTE&CG1 DS H *
CE1CCE&CG1 DS H *
CE1CRF&CG1 DS F CORE BLOCK REFERENCE WORD - F
CE1CTF&CG1 DS H *
CE1CCF&CG1 DS H *
CE1CRP&CG1 DS F CBRW FOR PROGRAM CALLS
CE1CTP&CG1 DS H *
CE1CCP&CG1 DS H *
CE1FX0&CG1 DS 2F FARW EXTENXION - 0
CE1FXA&CG1 DS 2F FARW EXTENXION - A
CE1FXB&CG1 DS 2F FARW EXTENXION - B
CE1FXC&CG1 DS 2F FARW EXTENXION - C
CE1FXD&CG1 DS 2F FARW EXTENXION - D
CE1FXE&CG1 DS 2F FARW EXTENXION - E
CE1FXF&CG1 DS 2F FARW EXTENXION - F
CE1SUD&CG1 DS XL17 DETAIL DATA LEVEL ERROR INDICATORS
AIF (&BG117 OR '&CG1' NE '').NOSUDEQ PRIOR CALL
.* THE FOLLOWING ARE EQUATES FOR THE BITS IN CE1SUD & CE1SUG
CXSGHE EQU X'80' I/O HARDWARE ERROR
CXSGIE EQU X'40' ID CHECK FAILURE
CXSGRE EQU X'20' RCC CHECK FAILURE
CXSGSE EQU X'10' SHORT LENGTH RECORD
CXSGLE EQU X'08' LONG LENGTH RECORD
CXSGEE EQU X'04' EOF
CXSGAE EQU X'02' INVALID FILE ADDRESS
EB0EB - ECB
CXSGDLK EQU X'01' DEADLOCK ECB @PJ25094
CXSGNO EQU X'88' DEVICE NOT OPERATIONAL
CXSGTE EQU X'44' TAPE SWITCH ON DEVICE @PJ14605
.* SPECIFIC I/O
.NOSUDEQ ANOP
ORG CE1SUD&CG1+16
CE1SUP&CG1 DS X DETAIL PROGRAM LEVEL ERROR IND
CE1SUG&CG1 DS X GROSS DATA LEVEL ERROR INDICATOR
CE1PBN&CG1 DS H SAVE CURRENT PBI- ENBK ROUTINES
CE1ODBI&CG1 DS H DBI IN ECB AT SEND TIME
CE1FLS&CG1 DS CL1 FAST LINK SAVE AREA
CU1DBO&CG1 DS CL1 TPFDF - NBR OF FILES OPEN @411.074
CU1DBS&CG1 DS F TPFDF - ADDRESS OF DBIFB @411.074
CU1DBT&CG1 DS F TPFDF - ADDR OF CENTRAL DATABASE
SPACE 1
DS 0D @411.074
CE1CTRS&CG1 DS 0XL40 RESOURCE CONSUMPTION COUNTERS
*
CE1DSTMP&CG1 DS D DISPATCH TIME STAMP (TOD FORMAT)
CE1EXTIM&CG1 DS D EXIT TIME STAMP (TOD FORMAT)
CE1ISTIM&CG1 DS D TOTAL I-STREAM TIME (TOD FORMAT)
CE1FINDS&CG1 DS F NUMBER OF FINDS REQUESTED @411.074
CE1FILES&CG1 DS F NUMBER OF FILES REQUESTED @411.074
CE1GETPOOLS&CG1 DS F NUMBER OF GETFCS REQUESTED @411.074
CE1USERID&CG1 DS F USER IDENTIFICATION OF ECB @411.074
*
CE1DFDMP&CG1 DS F TPFDF DUMP PROCESSING AREA @PJ22962
CE1DFSTK&CG1 DS F TPFDF FASTLINK STACK @PJ25684
*
CE1VRA&CG1 DS 12F IBM RESERVED - ONLY TO BE USED TO
* FULFILL VENDOR REQUEST FOR ECB SPACE
ORG CE1VRA&CG1 @411.074
CE1STDB&CG1 DS H --| @411.074
CE1CODB&CG1 DS H | @411.074
CE1STDF&CG1 DS H | SST RESERVED FIELDS @411.074
CE1CODF&CG1 DS H | @411.074
CE1SSQ&CG1 DS F | @411.074
CE1SST&CG1 DS X --| @411.074
*
CE1ESPM&CG1 DS XL3 --| ESMP RESERVED FIELDS @411.074
EB0EB - ECB
DS 8F @411.074
* END OF VENDOR RESERVED AREA
*
CE1FDET&CG1 DS F ADDRESS OF FIRST ECB DBT @411.074
CE1LDET&CG1 DS F ADDR OF LAST DBT IN OVERFLOW BLOCK
CE1LPNL&CG1 DS F ADDR OF LAST PNL IN OVERFLOW BLOCK
CE1WAB&CG1 DS F ADDR OF WTOPC ASSEMBLY BLOCK
*
CE1GLA&CG1 DS F SSU GLOBAL A POINTER
CE1GLY&CG1 DS F SSU GLOBAL Y POINTER
CE1RDA&CG1 DS F REGISTER SAVE AREA - RDA (R14)
CE1S14&CG1 EQU CE1RDA&CG1 REGISTER SAVE AREA - R14 WP12599
CE1RDB&CG1 DS F REGISTER SAVE AREA - RDB (R15)
CE1S15&CG1 EQU CE1RDB&CG1 REGISTER SAVE AREA - R15 WP12599
CE1SVR&CG1 DS F REGISTER SAVE AREA - RAC (R0)
CE1S00&CG1 EQU CE1SVR&CG1 REGISTER SAVE AREA - R0 WP12599
CE1SV1&CG1 DS F REGISTER SAVE AREA - RG1 (R1)
CE1S01&CG1 EQU CE1SV1&CG1 REGISTER SAVE AREA - R1 WP12599
CE1SVA&CG1 DS F REGISTER SAVE AREA - RGA (R2)
CE1S02&CG1 EQU CE1SVA&CG1 REGISTER SAVE AREA - R2 WP12599
CE1SVB&CG1 DS F REGISTER SAVE AREA - RGB (R3)
CE1S03&CG1 EQU CE1SVB&CG1 REGISTER SAVE AREA - R3 WP12599
CE1SVC&CG1 DS F REGISTER SAVE AREA - RGC (R4)
CE1S04&CG1 EQU CE1SVC&CG1 REGISTER SAVE AREA - R4 WP12599
CE1SVD&CG1 DS F REGISTER SAVE AREA - RGD (R5)
CE1S05&CG1 EQU CE1SVD&CG1 REGISTER SAVE AREA - R5 WP12599
CE1SVE&CG1 DS F REGISTER SAVE AREA - RGE (R6)
CE1S06&CG1 EQU CE1SVE&CG1 REGISTER SAVE AREA - R6 WP12599
CE1SVF&CG1 DS F REGISTER SAVE AREA - RGF (R7)
CE1S07&CG1 EQU CE1SVF&CG1 REGISTER SAVE AREA - R7 WP12599
CE1SVP&CG1 DS F REGISTER SAVE AREA - RAP (R8)
CE1CPNL&CG1 DS F ADDRESS OF CURRENT PNL @250.074
CE1FPNL&CG1 DS F ADDRESS OF FIRST ECB PNL @250.074
CE1CXR&CG1 DS CL8 CONTROL TRANSFER FIELD
CE1ISN&CG1 DS H ASSIGNED I-STREAM
CE1INC&CG1 DS H INTERRUPT CODE USED BY RTT
CE1SYN&CG1 DS H GLOBAL SYNCHRONIZATION FIELD
CE1CRI&CG1 DS H FUNCTIONAL CRAS SUPPORT INDICATORS
CE1STP&CG1 DS F ADDRESS OF STP BLOCK @411.069
CE1CNF&CG1 DS F BSS CINFC TABLE ADDRESS @411.074
EB0EB - ECB
CE1CSC&CG1 DS F C STATIC STORAGE CNTRL BLK POINTER
CE1CSP&CG1 DS F CURRENT C STATIC STORAGE POINTER
CE1EHT&CG1 DS F POINTER TO EHT SLOT FOR THIS ECB
CE1TRT&CG1 DS F POINTER TO C LANGUAGE TRANSLATE TBL
CE1TCA&CG1 DS F BASE OF THE C LANGUAGE __PERM AREA.
* CAN BE USED TO DERIVE BASE OF FIRST
* 'C' STACK BLOCK CHAINED TO THE ECB
CE1STK&CG1 DS F C LANGUAGE CURRENT STACK FRAME PTR
* ZERO IF TOP OF C STACK
CE1VCT&CG1 DS H COUNTER FOR VFA TRIPS
CE1TKN&CG1 DS H ASYNC I/O TOKEN NUMBER @411.011
CE1DET&CG1 DS F ADDRESS OF CURRENT DBT ENTRY
CE1DCT&CG1 DS CL16 DETACHED LEVEL COUNTERS @411.074
ORG CE1DCT&CG1 @411.074
CE1DT0&CG1 DS X D0 DETACHED BLOCK COUNT @411.074
CE1DTA&CG1 DS X DA DETACHED BLOCK COUNT @411.074
CE1DTB&CG1 DS X DB DETACHED BLOCK COUNT @411.074
CE1DTC&CG1 DS X DC DETACHED BLOCK COUNT @411.074
CE1DTD&CG1 DS X DD DETACHED BLOCK COUNT @411.074
CE1DTE&CG1 DS X DE DETACHED BLOCK COUNT @411.074
CE1DTF&CG1 DS X DF DETACHED BLOCK COUNT @411.074
CE1ADB&CG1 DS CL1 USER DETACHED BLOCK COUNTER @411.074
*
CE1LML&CG1 DS X MAXIMUM ECB LIFE TIME (MINUTES)
CE1LCL&CG1 DS X ECB LIFE TIME TO DATE (MINUTES)
CE1LFL&CG1 DS X HUNG/LOOPING ECB INDICATORS
CE1LLNG&CG1 EQU X'80' ECB HAS EXCEEDED MAX LIFE
CE1LEXT&CG1 EQU X'40' LONG ECB SCHEDULED TO EXIT
CE1LHN1&CG1 EQU X'20' HUNG ECB INDICATOR 1
CE1LHN2&CG1 EQU X'10' HUNG ECB INDICATOR 2
CE1PSI&CG1 DS X PAUSE STATE INDICATOR
EB0EB - ECB
* TM CE1PSI,X'80' IS ONE IF SYSTEM IS CURRENTLY PAUSED BY THIS ECB
CE1RTK&CG1 DS X RTT WORK AREA.
CE1AIO&CG1 DS X ASYNC I/O INDICATORS @411.011
.* THE FOLLOWING ARE EQUATES FOR THE FIELD CE1AIO
CE1EVAA&CG1 EQU X'80' 1 = ASYNC I/O EVENT ACTIVE
.*
CE1SEF&CG1 DS CL1 SYSTEM ERROR FLAG.
CE1SEW&CG1 EQU X'80' ECB CREATED BY SYSTEM ERROR.
CE1CPS&CG1 EQU X'40' PREVENT LOOPING IN CPSA WP12718
CE1DTX&CG1 EQU X'20' PREVENT LOOPING IN DUMP DATA @411.074
* EXIT
CE1SNP&CG1 EQU X'10' ECB CREATED BY SNAPC @411.074
CE1CSA&CG1 EQU X'08' HAS ECB SWISC'D TO CPSA @PJ19048
CE1CRS&CG1 DS CL4 USED BY CROSC TO SAVE R8 (GLBAC)
CE1CPX&CG1 DS F CONTROL PROGRAM WORK AREA
ORG CE1CPX&CG1
CE1CPA&CG1 DS CL1 CONTROL BYTE A
CE1ALMT&CG1 EQU X'80' BYPASS LMT SWITCH
* 1 = BYPASS, 0 = DON'T BYPASS
CE1AINT&CG1 EQU X'40' SENDC A/C/L INTERCEPT SWITCH
* 1 = DON'T USE SEND INTERCEPT
* ROUTINE (SYSTEM SEND)
* 0 = GO TO SEND INTERCEPT FOR
CE1ARFA&CG1 EQU X'20' SMP/CVIT FILE ADDRS RETRIECED
* 0 = POOLS ACTIVE, FILE ADDRS RTRVD
* 1 = POOLS WERE NOT ACTIVE, NO
* FILE ADDRESS WAS RECEIVED
CE1ASCR&CG1 EQU X'10' SMP/UI SCROLL REQUEST SWITCH
* 1 = SCROLLING REQUESTED
* 0 = NO SCROLLING
CE1AFMT&CG1 EQU X'08' SMP CHIANED-MESSAGE FORMAT SWITCH
* 1 = REFORMAT MSG ENTERING SM
* NO-FORMAT ENTERY POINT
* 0 = DON'T REFORMAT
CE1ACVT&CG1 EQU X'04' SENDC CONVERSION SWTICH
* 1 = SENDC ALREADY CONVERTED
* 0 = CONVERT SENDC TO ROUTC
CE1ANPR&CG1 EQU X'02' SMP MDBF PREFIX SWITCH
* 1 = DON'T ATTACH MDFB PREFIX
* 0 = ATTACH MDBF PREFIX TO NEXT
EB0EB - ECB
* MESSAGE FROM THIS ECB
CE1AEOM&CG1 EQU X'01' SMP WTOPC LAST BLOCK SWITCH
* 0 = NOT LAST BLOCK
* 1 = LAST BLOCK
CE1CPB&CG1 DS CL1 CONTROL BYTE B
CE1BCHN&CG1 EQU X'80' SMP WTOPC CHAIN SWITCH
* 0 = NO CHAINING IN PROGRESS
* 1 = MESSAGE CHAINING ACTIVE
CE1BCAN&CG1 EQU X'40' CSC1 3270 CANNED MESSAGE SWITCH
* 0 = NORMAL MESSAGE
* 1 = SPECIAL MESSAGE FROM CSC1
CE1BUIO&CG1 EQU X'20' UIO RESTORE SWITCH
* 1 = RESTORE DATA LEVEL 3 & 4
* 0 = RESTORE NOT REQUIRED
* EQU X'10' RESERVED FOR IBM USE
CE1CPC&CG1 DS CL1 *
CE1CPD&CG1 DS CL1 *SYMBOLIC CPU ID
CE1SDBI&CG1 DS F MDBF SAVE FIELD
ORG CE1SDBI&CG1
CE1SVS&CG1 DS H SS SAVE AREA
CE1SVU&CG1 DS H SSU SAVE AREA
CE1PBI&CG1 DS H PROGRAM BASE ID
CE1DBI&CG1 DS H DATA BASE ID
AIF ('&CG1' NE '').DBIOK @PJ25089
CE1DBI_DISPLACEMENT EQU CE1DBI-EB0EB @PJ25089
LCLA &DBIDSP @PJ25089
&DBIDSP SETA CE1DBI_DISPLACEMENT @PJ25089
AIF (&DBIDSP EQ 818).DBIOK @PJ25089
MNOTE 8,'__DBIDSP IN C HEADER C$FSQU.H NEEDS TO BE CHANGED TO \
&DBIDSP' @PJ25089
.DBIOK ANOP @PJ25089
CE1SSU&CG1 DS H SSU ID
CE1TRV&CG1 DS H TRANSFER VECTOR FIELD
CE1PSW&CG1 DS D PROGRAM STATUS WORD
CE1IOC&CG1 DS H INPUT/OUTPUT COUNTER
CE1HLD&CG1 DS X HOLD COUNTER
EB0EB - ECB
CE1TAP&CG1 DS C SYMBOLIC TAPE MODULE NUMBER
CE1TIN&CG1 DS H TAPE STATUS INDICATORS
CE1URM&CG1 DS H UNIT RECORD
CE1REC&CG1 DS CL8 RECORDING/TEST OPTIONS
ORG CE1REC&CG1
CE1TOP&CG1 DS X TRACE OPTIONS
CE1OUT&CG1 DS CL3 TERMINAL ADDRESS
CE1TST&CG1 DS CL4 RECORDING/TEST
ORG CE1REC&CG1
DS C
EBROUT&CG1 DS CL3 TERMINAL ADDRESS
DS CL4
CE1AII&CG1 DS X ECB ACTIVE/INACTIVE INDICATOR
.* THE FOLLOWING ARE EQUATES FOR THE FIELD CE1AII
CCE1AVL&CG1 EQU X'80' ECB ACTIVE INDICATOR
CCE1IPC&CG1 EQU X'40' ECB BELONGS TO IPC
CE1EVAF&CG1 EQU CE1AII&CG1 ECB CREATED AN EVENT
CE1EVAG&CG1 EQU X'20' 1 = YES
CCE1TPS&CG1 EQU X'10' ECB FOR TAPE SERVICE WP12123
CE1EVWF&CG1 EQU CE1AII&CG1 ECB WAITING ON EVENT
CE1EVWG&CG1 EQU X'08' 1 = YES
CCE1MPI&CG1 EQU X'04' ECB BELONGS TO MPIF &240.072
*
* THE FOLLOWING INDICATOR SHOULD BE USED TO INDICATE THAT AN ECB
* SHOULD NOT BE EXITED WITH A CTL-E1 BY CYCLE DOWN.
*
CCE1CYC&CG1 EQU X'02' ECB CYCLE STATUS
*
* THE FOLLOWING INDICATOR SHOULD BE USED TO INDICATE THAT THIS
* ECB WILL CREATE OTHER ECB'S THAT CAN SURVIVE A CYCLE DOWN TO 1052
* STATE. ECB'S CREATED BY THIS ONE VIA CREMC, CREDC, CREEC, CREXC,
* OR SWISC, WILL HAVE THEIR CCE1CYC BIT SET ON. THIS FIELD IS
* >>> NOT <<< CHECKED IN CRETC, SIPCC, OR CXFRC CREATE MACROS.
*
CCE1CRE&CG1 EQU X'01' CREATE ECB'S THAT CAN SUR- WP12397
* VIVE A CYCLE-DOWN TO 1052.
SPACE
CE1DIX&CG1 DS X @411.074
CE1SUC&CG1 DS X CONTROL PROGRAM FLAG
CE1SUI&CG1 DS X SYSTEM ERROR INDICATORS
EB0EB - ECB
ORG CE1SUI&CG1
CE1SYE&CG1 DS X
* THE FOLLOWING ARE EQUATES FOR THE BITS IN CE1SUI & CE1SYE
SUIDMP&CG1 EQU X'80' BYPASS SYSTEM ERROR PROCESSING
* INDICATOR
* 1 = BYPASS SYSTEM ERROR PROCESSING
* 0 = NORMAL ERROR PROCESSING
SUISYSE&CG1 EQU X'40' SYSTEM ERROR INDICATOR @411.074
* 1 = PROCESSING SYSTEM ERROR
* 0 = NORMAL PROCESSING
* EQU X'20' IBM RESERVED
SUISCH&CG1 EQU X'10' STATE CHANGE ECB INDICATOR @411.074
* 1 = STATE CHANGE ECB
* 0 = NORMAL ECB
SUITCL&CG1 EQU X'08' TAPE CLOSE INDICATOR @411.074
* 1 = TAPE IS TO BE CLOSED
* 0 = NORMAL PROCESSING
SUISNA&CG1 EQU X'04' SNA ECB INDICATOR @411.074
* 1 = SNA ECB
* 0 = NON-SNA ECB
SUIFF&CG1 EQU X'FF' HEX FF CONSTANT @411.074
CE1TRC&CG1 DS F TRACE CNTRL XFER/CREATES
DS X IBM RESERVED @411.074
CE1TIM&CG1 DS CL5 ECB TIME STAMP, OPZO TOD TIME
* Note: CE2TIME has full TOD value
*
*
CE1IN1&CG1 DS X INDICATOR BYTE
IN1CPF&CG1 EQU X'80' TYPE E PGM FOR CP FUNCTION
IN1VFW&CG1 EQU X'40' WAITC TO RESET APPL TIMEOUT
IN1CYC&CG1 EQU X'20' SET FOR CYCLE ECBS
IN1CRO&CG1 EQU X'10' ECB CHANGED PBI USING CROSC @PJ18846
* IN1SVP INDICATES THAT CE1SVP IS NOT POINTING TO THE ACTIVE
* PROGRAM. TPFDF USES IT TO INFORM CPSL THAT SERRC WAS ISSUED
* FROM A TPFDF WORK AREA, NOT THE ACTIVE PROGRAM (HOWEVER, THE
* BIT CAN BE USED BY FACILITIES OTHER THAN TPFDF).
IN1SVP&CG1 EQU X'08' @PJ21223
IN1DEA&CG1 EQU X'04' DEACTIVATE ECB INDICATOR @PJ25294
EB0EB - ECB
*
*
CE1RTT&CG1 DS X TRACE OUTPUT SELECTION
CE1TTA&CG1 DS F TEST TOOLS AREA
CE1AUT&CG1 DS F ALASC AUTOSAVE AREA
CE1ARS&CG1 DS 10F USER (APPLICATION) REG. SAVE AREA
ORG CE1ARS&CG1
CE1URA&CG1 DS F REGISTER SAVE AREA - RDA (R14)
CE1URB&CG1 DS F REGISTER SAVE AREA - RDB (R15)
CE1UR0&CG1 DS F REGISTER SAVE AREA - RAC (R0)
CE1UR1&CG1 DS F REGISTER SAVE AREA - RG1 (R1)
CE1UR2&CG1 DS F REGISTER SAVE AREA - RGA (R2)
CE1UR3&CG1 DS F REGISTER SAVE AREA - RGB (R3)
CE1UR4&CG1 DS F REGISTER SAVE AREA - RGC (R4)
CE1UR5&CG1 DS F REGISTER SAVE AREA - RGD (R5)
CE1UR6&CG1 DS F REGISTER SAVE AREA - RGE (R6)
CE1UR7&CG1 DS F REGISTER SAVE AREA - RGF (R7)
EBX000&CG1 DS 1C WORK AREA TWO
EBX001&CG1 DS 1C *
EBX002&CG1 DS 1C *
EBX003&CG1 DS 1C *
EBX004&CG1 DS 1C *
EBX005&CG1 DS 1C *
EBX006&CG1 DS 1C *
EBX007&CG1 DS 1C *
EBX008&CG1 DS 1C *
EBX009&CG1 DS 1C *
EBX010&CG1 DS 1C *
EBX011&CG1 DS 1C *
EBX012&CG1 DS 1C *
EBX013&CG1 DS 1C *
EBX014&CG1 DS 1C *
EBX015&CG1 DS 1C *
EBX016&CG1 DS 1C *
EBX017&CG1 DS 1C *
EBX018&CG1 DS 1C *
EBX019&CG1 DS 1C *
EBX020&CG1 DS 1C *
EBX021&CG1 DS 1C *
EBX022&CG1 DS 1C *
EB0EB - ECB
EBX023&CG1 DS 1C *
EBX024&CG1 DS 1C *
EBX025&CG1 DS 1C *
EBX026&CG1 DS 1C *
EBX027&CG1 DS 1C *
EBX028&CG1 DS 1C *
EBX029&CG1 DS 1C *
EBX030&CG1 DS 1C *
EBX031&CG1 DS 1C *
EBX032&CG1 DS 1C *
EBX033&CG1 DS 1C *
EBX034&CG1 DS 1C *
EBX035&CG1 DS 1C *
EBX036&CG1 DS 1C *
EBX037&CG1 DS 1C *
EBX038&CG1 DS 1C *
EBX039&CG1 DS 1C *
EBX040&CG1 DS 1C *
EBX041&CG1 DS 1C *
EBX042&CG1 DS 1C *
EBX043&CG1 DS 1C *
EBX044&CG1 DS 1C *
EBX045&CG1 DS 1C *
EBX046&CG1 DS 1C *
EBX047&CG1 DS 1C *
EBX048&CG1 DS 1C *
EBX049&CG1 DS 1C *
EBX050&CG1 DS 1C *
EBX051&CG1 DS 1C *
EBX052&CG1 DS 1C *
EBX053&CG1 DS 1C *
EBX054&CG1 DS 1C *
EBX055&CG1 DS 1C *
EBX056&CG1 DS 1C *
EBX057&CG1 DS 1C *
EBX058&CG1 DS 1C *
EBX059&CG1 DS 1C *
EBX060&CG1 DS 1C *
EBX061&CG1 DS 1C *
EBX062&CG1 DS 1C *
EB0EB - ECB
EBX063&CG1 DS 1C *
EBX064&CG1 DS 1C *
EBX065&CG1 DS 1C *
EBX066&CG1 DS 1C *
EBX067&CG1 DS 1C *
EBX068&CG1 DS 1C *
EBX069&CG1 DS 1C *
EBX070&CG1 DS 1C *
EBX071&CG1 DS 1C *
EBX072&CG1 DS 1C *
EBX073&CG1 DS 1C *
EBX074&CG1 DS 1C *
EBX075&CG1 DS 1C *
EBX076&CG1 DS 1C *
EBX077&CG1 DS 1C *
EBX078&CG1 DS 1C *
EBX079&CG1 DS 1C *
EBX080&CG1 DS 1C *
EBX081&CG1 DS 1C *
EBX082&CG1 DS 1C *
EBX083&CG1 DS 1C *
EBX084&CG1 DS 1C *
EBX085&CG1 DS 1C *
EBX086&CG1 DS 1C *
EBX087&CG1 DS 1C *
EBX088&CG1 DS 1C *
EBX089&CG1 DS 1C *
EBX090&CG1 DS 1C *
EBX091&CG1 DS 1C *
EBX092&CG1 DS 1C *
EBX093&CG1 DS 1C *
EBX094&CG1 DS 1C *
EBX095&CG1 DS 1C *
EBX096&CG1 DS 1C *
EBX097&CG1 DS 1C *
EBX098&CG1 DS 1C *
EBX099&CG1 DS 1C *
EBX100&CG1 DS 1C *
EBX101&CG1 DS 1C *
EBX102&CG1 DS 1C *
EB0EB - ECB
EBX103&CG1 DS 1C *
EBXSW0&CG1 DS 1X *
EBXSW1&CG1 DS 1X *
EBXSW2&CG1 DS 1X *
EBXSW3&CG1 DS 1X *
EBXSW4&CG1 DS 1X *
EBXSW5&CG1 DS 1X *
EBXSW6&CG1 DS 1X *
EBXSW7&CG1 DS 1X *
ORG EBX000&CG1
CE1WKB&CG1 DS CL112 INTRA-PROGRAM WORK AREA
*
************************************
* *
* THE FOLLOWING 6 FIELDS ARE FOR THE TPF/APPC SUPPORT CODE USE *
* ONLY. THE FIELDS ARE REDEFINED IN THE IWBL MACRO TO *
* USE LONGER, MORE MEANINGFUL NAMES. *
* *
************************************
*
EBCCBID&CG1 DS XL4 TPF/APPC CCB ID @411.034
EBTCBID&CG1 DS XL4 TPF/APPC TCB ID @411.034
EBVERBT&CG1 DS C TPF/APPC VERB TYPE @411.034
EBTPPCI&CG1 DS X TPF/APPC INDICATOR @411.034
EBL62PS&CG1 EQU X'01' ECB RUNNING IN PS LAYER @411.034
EBSVCLU&CG1 EQU X'02' TP RUNNING IN SERVICE LU @411.034
EBSVCSE&CG1 EQU X'04' SERVICE LU SPECIAL SEND ERROR
EBS0846&CG1 EQU X'08' SEND SENSE 0846 BEFORE FMH7
*
EBTPPCF&CG1 DS X TPF/APPC LEVEL F INDICATOR @411.034
EBTPPCD&CG1 DS X TPF/APPC DEALLOCATION CLEANUP IND
EBTPORD&CG1 DS XL2 ITPICB ORDINAL NUMBER @411.069
*
************************************
*
CE1RCI&CG1 DS XL1 I-S ON WHICH $RECVC UNIT WAS ARMED
CE1FLG&CG1 DS X ECB FORMAT FLAG
DS F Reserved for future IBM use @PJ25459
CE1MAC&CG1 DS CL268 WORK AREA FOR E-TYPE MACROS @PJ14252
CE1RID&CG1 DS CL32 RIDCC OUTPUT SAVE AREA @PJ14252
EB0EB - ECB
ORG CE1RID&CG1 This is a doubly used field
CE1CEN&CG1 DS 0CL8 CLAW event name @PJ21791
CE1CEA&CG1 DS F socket remote FDT/thread @PJ23180
CE1CEE&CG1 DS F Socket API ECB SVA @PJ23180
ORG CE1CEE&CG1 @PJ23180
CE1CEO&CG1 DS H Socket API opcode @PJ23180
CE1CES&CG1 DS H Socket sequence number @PJ23180
DS CL24 Reserved for SOCKET/CLAW interface
*
CE1USA&CG1 DS CL2752 USER AREA
ORG CE1SUD&CG1
EBCSD0&CG1 DS X DATA LEVEL ERROR INDICATOR - 0
EBCSDA&CG1 DS X DATA LEVEL ERROR INDICATOR - A
EBCSDB&CG1 DS X DATA LEVEL ERROR INDICATOR - B
EBCSDC&CG1 DS X DATA LEVEL ERROR INDICATOR - C
EBCSDD&CG1 DS X DATA LEVEL ERROR INDICATOR - D
EBCSDE&CG1 DS X DATA LEVEL ERROR INDICATOR - E
EBCSDF&CG1 DS X DATA LEVEL ERROR INDICATOR - F
EBCSDP&CG1 DS X PROGRAM LEVEL ERROR INDICATOR
ORG CE1SUG&CG1
EBCSUG&CG1 DS X
ORG CE1SUC&CG1
EBCSUC&CG1 DS X
ORG CE1FA0&CG1
EBCFW0&CG1 DS D
ORG EBCFW0&CG1
EBCID0&CG1 DS H
EBCRC0&CG1 DS X
EBCCN0&CG1 DS X
EBCFA0&CG1 DS F
ORG EBCFA0&CG1
EB0EB - ECB
EBCFM0&CG1 DS X
EBCFC0&CG1 DS X
EBCFH0&CG1 DS X
EBCFR0&CG1 DS X
ORG CE1FA1&CG1
EBCFW1&CG1 DS D
ORG EBCFW1&CG1
EBCID1&CG1 DS H
EBCRC1&CG1 DS X
EBCCN1&CG1 DS X
EBCFA1&CG1 DS F
ORG EBCFA1&CG1
EBCFM1&CG1 DS X
EBCFC1&CG1 DS X
EBCFH1&CG1 DS X
EBCFR1&CG1 DS X
ORG CE1FA2&CG1
EBCFW2&CG1 DS D
ORG EBCFW2&CG1
EBCID2&CG1 DS H
EBCRC2&CG1 DS X
EBCCN2&CG1 DS X
EBCFA2&CG1 DS F
ORG EBCFA2&CG1
EBCFM2&CG1 DS X
EBCFC2&CG1 DS X
EBCFH2&CG1 DS X
EBCFR2&CG1 DS X
ORG CE1FA3&CG1
EBCFW3&CG1 DS D
ORG EBCFW3&CG1
EBCID3&CG1 DS H
EBCRC3&CG1 DS X
EBCCN3&CG1 DS X
EBCFA3&CG1 DS F
ORG EBCFA3&CG1
EBCFM3&CG1 DS X
EBCFC3&CG1 DS X
EBCFH3&CG1 DS X
EBCFR3&CG1 DS X
EB0EB - ECB
ORG CE1FA4&CG1
EBCFW4&CG1 DS D
ORG EBCFW4&CG1
EBCID4&CG1 DS H
EBCRC4&CG1 DS X
EBCCN4&CG1 DS X
EBCFA4&CG1 DS F
ORG EBCFA4&CG1
EBCFM4&CG1 DS X
EBCFC4&CG1 DS X
EBCFH4&CG1 DS X
EBCFR4&CG1 DS X
ORG CE1FA5&CG1
EBCFW5&CG1 DS D
ORG EBCFW5&CG1
EBCID5&CG1 DS H
EBCRC5&CG1 DS X
EBCCN5&CG1 DS X
EBCFA5&CG1 DS F
ORG EBCFA5&CG1
EBCFM5&CG1 DS X
EBCFC5&CG1 DS X
EBCFH5&CG1 DS X
EBCFR5&CG1 DS X
ORG CE1FA6&CG1
EBCFW6&CG1 DS D
ORG EBCFW6&CG1
EBCID6&CG1 DS H
EBCRC6&CG1 DS X
EBCCN6&CG1 DS X
EBCFA6&CG1 DS F
ORG EBCFA6&CG1
EBCFM6&CG1 DS X
EBCFC6&CG1 DS X
EBCFH6&CG1 DS X
EBCFR6&CG1 DS X
ORG CE1FA7&CG1
EBCFW7&CG1 DS D
ORG EBCFW7&CG1
EBCID7&CG1 DS H
EB0EB - ECB
EBCRC7&CG1 DS X
EBCCN7&CG1 DS X
EBCFA7&CG1 DS F
ORG EBCFA7&CG1
EBCFM7&CG1 DS X
EBCFC7&CG1 DS X
EBCFH7&CG1 DS X
EBCFR7&CG1 DS X
ORG CE1FA8&CG1
EBCFW8&CG1 DS D
ORG EBCFW8&CG1
EBCID8&CG1 DS H
EBCRC8&CG1 DS X
EBCCN8&CG1 DS X
EBCFA8&CG1 DS F
ORG EBCFA8&CG1
EBCFM8&CG1 DS X
EBCFC8&CG1 DS X
EBCFH8&CG1 DS X
EBCFR8&CG1 DS X
ORG CE1FA9&CG1
EBCFW9&CG1 DS D
ORG EBCFW9&CG1
EBCID9&CG1 DS H
EBCRC9&CG1 DS X
EBCCN9&CG1 DS X
EBCFA9&CG1 DS F
ORG EBCFA9&CG1
EBCFM9&CG1 DS X
EBCFC9&CG1 DS X
EBCFH9&CG1 DS X
EBCFR9&CG1 DS X
ORG CE1FAA&CG1
EBCFWA&CG1 DS D
ORG EBCFWA&CG1
EBCIDA&CG1 DS H
EBCRCA&CG1 DS X
EBCCNA&CG1 DS X
EBCFAA&CG1 DS F
ORG EBCFAA&CG1
EB0EB - ECB
EBCFMA&CG1 DS X
EBCFCA&CG1 DS X
EBCFHA&CG1 DS X
EBCFRA&CG1 DS X
ORG CE1FAB&CG1
EBCFWB&CG1 DS D
ORG EBCFWB&CG1
EBCIDB&CG1 DS H
EBCRCB&CG1 DS X
EBCCNB&CG1 DS X
EBCFAB&CG1 DS F
ORG EBCFAB&CG1
EBCFMB&CG1 DS X
EBCFCB&CG1 DS X
EBCFHB&CG1 DS X
EBCFRB&CG1 DS X
ORG CE1FAC&CG1
EBCFWC&CG1 DS D
ORG EBCFWC&CG1
EBCIDC&CG1 DS H
EBCRCC&CG1 DS X
EBCCNC&CG1 DS X
EBCFAC&CG1 DS F
ORG EBCFAC&CG1
EBCFMC&CG1 DS X
EBCFCC&CG1 DS X
EBCFHC&CG1 DS X
EBCFRC&CG1 DS X
ORG CE1FAD&CG1
EBCFWD&CG1 DS D
ORG EBCFWD&CG1
EBCIDD&CG1 DS H
EBCRCD&CG1 DS X
EBCCND&CG1 DS X
EBCFAD&CG1 DS F
ORG EBCFAD&CG1
EBCFMD&CG1 DS X
EBCFCD&CG1 DS X
EBCFHD&CG1 DS X
EBCFRD&CG1 DS X
EB0EB - ECB
ORG CE1FAE&CG1
EBCFWE&CG1 DS D
ORG EBCFWE&CG1
EBCIDE&CG1 DS H
EBCRCE&CG1 DS X
EBCCNE&CG1 DS X
EBCFAE&CG1 DS F
ORG EBCFAE&CG1
EBCFME&CG1 DS X
EBCFCE&CG1 DS X
EBCFHE&CG1 DS X
EBCFRE&CG1 DS X
ORG CE1FAF&CG1
EBCFWF&CG1 DS D
ORG EBCFWF&CG1
EBCIDF&CG1 DS H
EBCRCF&CG1 DS X
EBCCNF&CG1 DS X
EBCFAF&CG1 DS F
ORG EBCFAF&CG1
EBCFMF&CG1 DS X
EBCFCF&CG1 DS X
EBCFHF&CG1 DS X
EBCFRF&CG1 DS X
ORG CE1CR0&CG1
EBCCR0&CG1 DS F
EBCCT0&CG1 DS H
EBCCC0&CG1 DS H
ORG CE1CR1&CG1
EBCCR1&CG1 DS F
EBCCT1&CG1 DS H
EBCCC1&CG1 DS H
ORG CE1CR2&CG1
EBCCR2&CG1 DS F
EBCCT2&CG1 DS H
EBCCC2&CG1 DS H
ORG CE1CR3&CG1
EBCCR3&CG1 DS F
EBCCT3&CG1 DS H
EBCCC3&CG1 DS H
EB0EB - ECB
ORG CE1CR4&CG1
EBCCR4&CG1 DS F
EBCCT4&CG1 DS H
EBCCC4&CG1 DS H
ORG CE1CR5&CG1
EBCCR5&CG1 DS F
EBCCT5&CG1 DS H
EBCCC5&CG1 DS H
ORG CE1CR6&CG1
EBCCR6&CG1 DS F
EBCCT6&CG1 DS H
EBCCC6&CG1 DS H
ORG CE1CR7&CG1
EBCCR7&CG1 DS F
EBCCT7&CG1 DS H
EBCCC7&CG1 DS H
ORG CE1CR8&CG1
EBCCR8&CG1 DS F
EBCCT8&CG1 DS H
EBCCC8&CG1 DS H
ORG CE1CR9&CG1
EBCCR9&CG1 DS F
EBCCT9&CG1 DS H
EBCCC9&CG1 DS H
ORG CE1CRA&CG1
EBCCRA&CG1 DS F
EBCCTA&CG1 DS H
EBCCCA&CG1 DS H
ORG CE1CRB&CG1
EBCCRB&CG1 DS F
EBCCTB&CG1 DS H
EBCCCB&CG1 DS H
ORG CE1CRC&CG1
EBCCRC&CG1 DS F
EBCCTC&CG1 DS H
EBCCCC&CG1 DS H
ORG CE1CRD&CG1
EBCCRD&CG1 DS F
EBCCTD&CG1 DS H
EBCCCD&CG1 DS H
EB0EB - ECB
ORG CE1CRE&CG1
EBCCRE&CG1 DS F
EBCCTE&CG1 DS H
EBCCCE&CG1 DS H
ORG CE1CRF&CG1
EBCCRF&CG1 DS F
EBCCTF&CG1 DS H
EBCCCF&CG1 DS H
MI0MI - Input Block Format
MI0HDR&CG1 DS 0CL16 HEADER

MI0BID&CG1 DS CL2 FILE ID
MI0CHK&CG1 DS X BLOCK CHECK CHARACTER (NOT USED)
MI0CTL&CG1 DS B CONTROL BYTE (NOT USED = 0)
* BLOCK SIZE L1 OR L2
*
MI0PGM&CG1 DS F LAST FILING PROGRAM STAMP
MI0FCH&CG1 DS F FORWARD CHAIN ADDRESS (NOT USED)
MI0BCH&CG1 DS F BACKWARD CHAIN ADDRESS (NOT USED)
*
MI0CCT&CG1 DS CL2 CHARACTER COUNT INCL MI0ADR + MI0ACC
* L1 = MAX 323 BYTES
* L2 = MAX 987 BYTES
*
MI0ADR&CG1 DS 0CL3 AGENT SET ADDRESS
MI0LNO&CG1 DS X LINE NUMBER (OLD)
MI0INO&CG1 DS X INTERCHANGE ADDRESS (OLD)
MI0TNO&CG1 DS X TERMINAL ADDRESS (OLD)
*
MI0ACC&CG1 DS CL2 ACTION CODE
* MESSAGE AND EOM FOLLOWING HERE
CA0CAL - Cargo Booking Record
CA0BEG&S DS 0CL32 BEGIN

CA0RID&S DS H Record ID C'AB'
CA0RCC&S DS X Record code check
CA0CTL&S DS X Control Byte
CA0PGM&S DS F Filing Program
CA0FCH&S DS F Forward Chain
CA0BCH&S DS F Backward Chain
CA0NAB&S DS H Next available Byte
CA0ALC&S DS CL2 Airline Code
CA0FLN&S DS CL4 Flight Number
CA0WGT&S DS H Total Weight
CA0DAT&S DS H PARS date
CA0LIT&S DS CL3 Last updated LNIATA
CA0SP1&S DS X Spare
CA0ITM&S DS 0XL24
CA0AWB&S DS CL5 Airway bill number
CA0STA&S DS X Status field
CA0CAN EQU X'FF' Item cancelled
CA0NEW EQU X'00' Item active
CA0TAP EQU X'80' Item moved to tape
CA0PCS&S DS CL2 Number of pieces
CA0IWT&S DS CL2 Consin weight
CA0ORG&S DS CL3 Origin City
CA0DES&S DS CL3 Destination City
CA0AIN&S DS CL2 Agent Initial
CA0ADY&S DS CL2 Agent duty code
CA0CAR&S DS CL4 Cargo detail file (381 long term)
DS 41XL36
CA0SP3&S DS XL10
CR0CAR – Cargo Detail File
CR0RID&S DS H Record ID C'2C'

CR0RCC&S DS X Record code check
CR0CTL&S DS X Control Byte
CR0PGM&S DS F Filing Program
CR0AWB&S DS CL5 Airway Bill Number
CR0PCS&S DS CL2 Number of pieces
CR0IWT&S DS XL2 Consign weight
CR0ORG&S DS CL3 Origin City
CR0DES&S DS CL3 Destination City
CR0NAM&S DS CL10 Name of Consignor
Lab Descriptions
LAB 0 – Learn to Code in TPF
Lab Objective To make the following concepts familiar
 Editing TPF programs in VM/CMS
 Assembling TPF programs
 Linking TPF programs
 Loading TPF programs
 Code XMSG subroutines
 Display the participant’s address (stored as constant in the program)
Input Message ZTRNx
 Where TRNx is the program name of the participant.
Output Shrimanikandan A
Expected 123, Einstein Enclave,
Newton Street,
San Jose, CA 23423
Algorithm Move the assembler code supplied to you into a TPF program assigned to you and
do the following
Initialize XMSG
Repeat
Move line to address pointed by R1
Increment R1 by length of item+1
Call XMSG
Until (no more lines to display)
Call XMSG final
XMSG Supplied in your VM3 reader list as XMSG TEXT
Routines
Duration 4 Hours
LAB 1 – Input Validation & Extraction
 DSECTs
 SST
Input Messages Display Cargo records  ZTRNx D
Add record to prime and  ZTRNx A awb/pi/wt/org/des
overflow awb 5 chars
pi &wt 2 chars
org & des 3 chars
Add Cargo detail file  ZTRNx C awb/name
Name will be of length 1 to 10 chars.
Cancel Cargo item  ZTRNx X awb
Note  All inputs will be terminated with a ‘+’ character.
 Where TRNx is the program name of the participant.
 The weight field is received in character format but should be stored in
hexadecimal format.
Output  The values in all cases should be extracted and stored so that the subsequent
Expected labs can use them.
DSECT  MI0MI
Duration 4 Hours
LAB 2 - Display Cargo Shipment List
 Core Block Management
 Data levels
 FACE
 Find Type Macros
Input Message ZTRNx D
File  Face type #AAAATRN
Characteristics  Ordinal Number 0
 RID c’AB’
 RCC 00
 Size of record 1K Prime & Overflow
Output CARGO SHIPMENT RECORD ON SQ0409
Expected
AWB PIECES WEIGHT ORIGIN DESTN AGT DCODE
A0001 01 10 MAA SIN MN PR
A0003 04 98 SIN MAA MB ZZ
Or
A relevant error message
DSECT  CA0CAL
 Lrec size x’0018’
 42 lrecs can fit in one block
 NAB value if block empty = x’0020’
 NAB value if block full = x’FFFF’
LAB 2 - Display Cargo Shipment List
Algorithm Get prime block address at D3 – Face
Do while File Address at D3 != 0
Find the block in D3
# of items = 42
If Nab != ‘FFFF’ Then
Validate the nab value (nab value-length of header)/size of item
If reminder == 0 then
# of items in the block = Quotient
Else
Nab invalid
End if
End if
If 1st item to be displayed then
Print Title
End If
For I = 1 to # of items
If status != Cancelled
Move fields and construct line
End if
Next I
File Address at D3 = Forward Chain Value
End while
Duration 8 Hours
LAB 3 - Add Cargo Shipment List – Only to prime
 File type macros
 Accessing AAA fields
 Accessing ECB fields
Input Message  ZTRNx A awb/pi/wt/org/des
File  Face type #AAAATRN
Characteristics  Ordinal Number ____
 RID c’AB’
 RCC 00
Output 1. Item added or
Expected 2. Item already present or
3. Item replaced or
4. No space left in the prime block or
5. A relevant error message
DSECT  CA0CAL
LAB 3 - Add Cargo Shipment List – Only to prime
Find the block in D3 with hold
# of items in the block = 42
If Nab != ‘FFFF’ Then
Validate the nab value (nab value-length of header)/size of item
If reminder == 0 then
# of items in the block = Quotient
Else
Nab invalid
End if
End if
For I = 1 to # of items
If awb == input awb then
If status == Cancelled then
Replace item
Update AAA and ECB Fields
Else
Item present
Endif
Else
If # of items in the block = 42 then
No more space left
Else
Add item in the position pointed by NAB
Endif
End if
Update AAA and ECB fields
Get agent duty code and initial from AAA
LNIATA from ECB
Move it to prime record
File and release D3
End sub
Duration 8 Hours
LAB 4 - Add Cargo Shipment List
 Pool type macros
 Chaining records
Input Message  ZTRNx A awb/pi/wt/org/des
File  Face type #AAATRN
Characteristics  Ordinal Number ____
 RID c’AB’
 RCC 00
Output 1. Item added or
Expected 2. Item already present or
3. Item replaced or
4. A relevant error message
DSECT  CA0CAL
LAB 4 - Add Cargo Shipment List

Do While record not found && block full && FCH != 0 Then
Set up D4 with FCH
Get block in D4
End while
If record found then
If status == Cancelled then
Replace item
Else
Item present
Endif
Else
If block full && FCH == 0 then
Get new pool file at level 5
Set initial value of nab and add item
Chain records
Else
Add item in the position pointed by NAB
Endif
End if
Get agent duty code and initial from AAA : Store in Lrec
LNIATA from ECB : Move it to prime record
File and release D3
File D4 and D5 if present
End sub
Chain records
If D4 is empty then /* chain with prime */
FCH of D3 = FADR in D5
Else
FCH of D4 = FADR in D5
End sub
Duration 8 Hours
LAB 5 - Add Cargo Detail Record / Cancel Cargo record
 Releasing pool files
Input Message  ZTRNx C awb/name
 ZTRNx X awb
File  CA0CAL
Characteristics  Face type #AAAATRN
 Ordinal Number ____
 RID c’AB’
 RCC 00
 Size of record 1K Prime & Overflow
 CA0CAR
 Pool File
 RID c’2C’
 Size of record 381 bytes
Output  For detail add
Expected  Item not found/cancelled
 Details added
 A relevant error message
 For Cancellation
 Item not present
 Item found cancelled
 Item cancelled
 A relevant error message
DSECT  CA0CAL
 Lrec size x’0018’
 42 lrecs can fit in one block
 NAB value if block empty = x’0020’
 NAB value if block full = x’FFFF’
 CA0CAR
 Lrec size 25 bytes
 Only one lrec stored in a block
LAB 5 - Add Cargo Detail Record / Cancel Cargo record
Algorithm To add detail file

Get prime block address at D3 – Face
Set up D4 with FCH
Get block in D4
End while
If status != Cancelled then
If CAR file Address == 0 Then
Get pool file in D6, move information
Copy FADR in D6 into CAR file address field
Else
Item present
Endif
End if
End if
Item not found
File and release D3
File D4 D5 and D6 if present
End sub
Cancel Record
Set up LNIATA and the AWB number field in parameter area, create child and exit.
CHILD PROCESS
Get prime block address at D3 – Face
Set up D4 with FCH
Get block in D4
End while
If status != Cancelled then
Mark Status as cancelled
Else
Item found cancelled
Endif
Else
Item not found
End if
Duration 8 Hours
LAB 6 – Update PARS date in Prime
 Globals.
Input Message  All entries that modify the file
File  CA0CAL
Characteristics  Face type #AAAATRN
 Ordinal Number ____
 RID c’AB’
 RCC 00
 Size of record 1K Prime & Overflow
Output  The expected output for all the entries as usually.
Expected  The global field PARS dates value is stored in the prime record
DSECT  CA0CAL
 Lrec size x’0018’
 42 lrecs can fit in one block
 NAB value if block empty = x’0020’
 NAB value if block full = x’FFFF’
 CA0CAR
 Lrec size 25 bytes
 Only one lrec stored in a block
Algorithm Update AAA and ECB fields
Get global value PARS date and update the prime record
File and release D3
File D4 D5 and D6 if present
End sub
Duration 8 Hours
How to create a TPF program?
Synopsis
 A Few definitions
 Updating Programs using SALS
 Getting into the test system
 GFOL & Loadsets
 The ZOLDR Functional message
A Few Definitions
Defining The Librarian:
The librarian is a Collection of Datasets in MVS, accessible By a tool named ELIPS (Extended
Librarian interactive Productivity Services). The Librarian Datasets store the source codes of all the
programs and macros.
The Librarian Datasets where Programs/Macros reside are as Follows.
TPF.LIBR.SRCE.PGM ---- TPF Source Programs Librarian
TPF.LIBR.SRCE.MAC --- TPF Macros Librarian
Defining Maclibs and Object Libraries :
MACLIBS:
“MACLIBS” are MVS Datasets that are used to store Macro Source. When a Macro is updated it is
written to a MACLIB .
During testing test macros are written to a Dataset named TPF.V41.TEST.MACLIB
When You assemble an Assembler Real Time Program that “uses” a macro , The Program should be
assembled against the maclib where the macro resides.
Object Libraries (OBJLIB):
Object Libraries are MVS Datasets that are used to store the Object codes produced by the
Assembler ,The Object is Then Loaded to the Shared GDS and Loaded Online to the TPF Online
System.
Object library we will use for the labs is "TPF.TRN.OBJLIB"
Updating Programs using SALS
 SALS is a utility that enables a TPF Developer to access , update a TPF Program source under the
XEDIT editor in VM
 SALS is an interface between the Source Librarian Datasets and VM
 Updating a TPF Program using SALS :
 From VM Ready Prompt enter ,
SALS U XXXXVV PTRNG
 U indicates that a Program update is to be done
 XXXX is the 4-Character name of the TPF Program
 VV is the 2-Character Version of the TPF Program
 PTRNG indicates that the training Object library should be used
 This Command takes you to a XEDIT Screen, where you have an edit session on for the program
source XXXXVV
 Make your updates to this program and "FILE" it . You can come out of XEDIT without making
any updates by hitting PF3
 The Following Screen Pops up prompting for an update code
 Every TPF Program update in the librarian is associated with an update code consisting of a 2
Character programmer initial , 3 character number and a one character alphabet denoting the
development department . Updated lines will be flagged with this update code in the source
The update code we will use for Training will be AB123S

SALS UPDATE version: 3 date: 22apr84

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Have you completed your updates ?

+-------------------+-----------------------------------------+
| - if INCOMPLETE | hit 'enter' key |
+-------------------+-----------------------------------------+
| - if COMPLETE, | key in... |
| and SAME | = and Update code |
| version | |
| required | e.g. = FH056R |
+-------------------+-----------------------------------------+
| - if COMPLETE, | key in... |
| and New Program | $ Update code and New Pgm Name |
| Name required | |
| (for pgm with | |
| no version) | e.g $ FH056R NEWPGM |
+-------------------+-----------------------------------------+
= AB123S
VM READ VM3
 In this screen enter your update code if you want to commit the updates you have made in this
session to the librarian
 Note that the update code should have a Space after the '='
 Hit enter on this panel if you do not want to commit the update to the Librarian source , Your
updates will remain in your A-disk and on subsequent SALS
 Do not try the third option !!
 If an update code is entered , then a JCL comes to the Xedit Screen that calls the assembler in
MVS to assemble TPF Program XXXXVV
An Example JCL
SALPTRNG SALJOB A1 F 80 Trunc=80 Size=15 Line=0 Col=1 Alt=0

====> FILE
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7..
00000 * * * Top of File * * *
00001 //TCMCTZTP JOB (9999,TACP),MSGLEVEL=0,CLASS=D,MSGCLASS=W
00002 //* +------------------------------------------------------------+
00003 //* | |
00004 //* | TPF.LIBR.SRCE.PGM -> TPF.TRN.OBJLIB |
00005 //* | ( TPF.V41.G.SYMACLIB ) |
00006 //* | ( TPF.MACRO.REL41 ) |
00007 //* | ( TPF.V41.CP.MACLIB ) |
00008 //* | ( TPF.V41.APP.MACLIB ) |
00009 //* | ( TPF.LIVE.APP.MACLIB ) |
00010 //* +------------------------------------------------------------+
00011 //P7560 EXEC PTRNG,CLASS=J
00012 //LIBR.SYSIN DD *
00013 -SEL TRS1S0 AB123S/
00014 //* SALS: INPUT BEFORE THIS LINE - DO NOT MESS UP
00015 //
00016 * * * End of File * * *
 Hit FILE here on the XEDIT Command Prompt , This takes you to another Panel in VM as follows
to confirm the JCL Submit request
 It also files the job in your A-Disk as OLD SALJOB A
Do you wish to submit the job ?

Please key in - YES to submit
- NO to suppress submission
(the job is still kept)
(hit 'QUIT' to abort)
YES
 A "YES" here in this panel submits the JCL to MVS , You would get back an acknowledgement
and job number on your screen , and The Job is submitted in D Class . After the job is executed the
Listing is spooled to your reader. The Object code is written to TPF.TRN.OBJLIB
 A "NO" here in this panel does not submit the JCL to MVS and saves the JCL in the A-disk as
SALPTRNG SALJOB
 "QUIT" aborts , Doesn't save , and Doesn’t submit .

Getting into the test system
 To get into the Training test system
 Enter 'K' on SIA Main menu and get into VM3 Test system
 Now type "D VPTPFA" to dial onto the TPF Test system
 Key in "I" after dialing in to get into the system
 Having dialed in to the test system , enter "BM*" to see the set identity
BM*
SET AD TYPE CIT TASF AL SINED IN/ACTIVE REF DTY MODE
010000 CRT C QSC SQ A A ZZ PR RES
 A 2-character reference code under REF and 2-character reference code under DTY indicates that
the set is already signed in .
 If not enter "BSIA0000ZZ/PR" in your TPF Sessions to sign in as a programmer
 This enables you to key in entries to test the applications you have written .
 The entry to invoke training programs are as follows
 ZXXXX , Where XXXX is the name of the TPF Program you have been assigned to.
GFOL & Loadsets
 GFOL expands to general file Online load
 GFOL is a VM based utility that provides panels to create loadsets that can be loaded to the Online
TPF System
 GFOL takes as input the TPF program segment names , Looks at TPF.TRN.OBJLIB for the object
codes , creates a loadable program object code in the form of a loadset onto a Loader general data
set that can be written to by MVS and Read by TPF
 GFOL also resolves external references in the object code like program PAT indices etc .
 The loadsets in the TPF loadable format is written to TPF.V41.G.TRAIN which is mounted to
TPF
 TPF Provides functional messages to load the TPF Programs online to the TPF System
 Following is a GFOL Panel :
GFOL41 TPF 4.1 - ONLINE-LOADER 21:34:28 3 Mar 1999
--------------------------------------------------------------------------------
TPF Version ==> V41 <==

System ID ==> K <== 'K' FOR TPF4.1 SMALL TEST
'K' ONLY OPTION FOR NOW
Loadset Name ==> TCMCTA00 <== Loadset No : 1
Loaderfile Group No ==> 00 <== " " or group # to include
Sysout-class ==> W <==

Screen No : 1
TRNxS0 ...... ...... ...... ...... ...... ...... ......
...... ...... ...... ...... ...... ...... ...... ......
...... ...... ...... ...... ...... ...... ...... ......
...... ...... ...... ...... ...... ...... ...... ......
...... ...... ...... ...... ...... ...... ...... ......
...... ...... ...... ...... ...... ...... ...... ......
...... ...... ...... ...... ...... ...... ...... ......
PF1 =Finish / PF2 =Next Loadset /

PA2 or PF3 = EXIT / PF7 =Scroll-BWD / PF8 =Scroll-FWD
 TPF Version should always be V41
 Always make sure that the System ID is 'K' , Choose a 1 to 8 character loadset name and always
use the same name
 Loaderfile group name is not of importance , can be set to 00
 Enter the program names with versions on the dotted line , Press PF1 after entering program names
 The load JCL comes up on the xedit screen , Press PF1 to submit the JCL for load .
 If the job returns with a '0' return code then the loadset was created successfully, using the same
name for the loadset will overwrite the previous version.
GFOL & Loadsets
 Diagram representing Workflow :
LOADER
OBJECT GENERAL
LIBRARY DATA SET
LIBRARIAN
DATASET
LOADSET
UPDATED SOURCE
OBJECT CODE
SALS U TRS1S0 PTRNG

GFOL
VM
ZOLDR
LOADER TPF
GENERAL
DATA SET
The ZOLDR Functional message
 ZOLDR is the functional message provided by TPF to load a loadset to TPF and to activate the
programs of the loadset in the TPF System
 To load a loadset to the TPF System:
 ZOLDR LOAD XXX LSNAME
 XXX is the DDNAME of the shared loader data set.
 We will use TRN as the DDNAME for this course
 LSNAME is the name of the loadset you want to load to the system
 Example :
ZOLDR LOAD TRN TCMCTZ00

OLDR1016I 22.10.19 CELA - LOAD REQUEST RECEIVED
LOADED PGM- TRS1S0 LOADSET- TCMCTZ00 ASMDATE- 99062
OLDR3000I 22.10.20 CLD0 - LOADSET TCMCTZ00 HAS BEEN LOADED FROM DDNAME
TRN
OLDR3001I 22.10.20 CELL - LOAD FOR DDNAME TRN COMPLETED
 An activate of the loadset has to be done after a load has been performed in order to activate the
version in the program immediately
 To activate a loadset in the TPF System:
 ZOLDR ACTIVATE LSNAME
 LSNAME is the name of the loadset you want to activate
ZOLDR ACT TCMCTZ00

CSMP0099I 22.13.57 010000-K ZOLDR ACT TCMCTZ00
OLDR1016I 22.13.57 CELA - ACTIVATE REQUEST RECEIVED
OLDR4023I 22.13.58 ACTIVATE OF LOADSET TCMCTZ00 SCHEDULED
ACTIVATE PGM- TRS1S0 LOADSET- TCMCTZ00 ASMDATE- 99062
OLDR2015I 22.13.59 CEL2 - LOADSET TCMCTZ00 ASSIGNED ACTIVATION
NUMBER 3 ON CPU K
OLDR2030I 22.13.59 ACTIVATE OF LOADSET TCMCTZ00 COMPLETED
The ZOLDR Functional message
 The ZOLDR deactivate and delete commands have to be issued before loading a loadset of the
same name .
 To deactivate a loadset in the TPF System:
 ZOLDR DEACTIVATE LSNAME
 LSNAME is the name of the loadset you want to deactivate
ZOLDR DEA TCMCTZ00

OLDR1016I 22.18.04 CELA - DEACTIVATE REQUEST RECEIVED
OLDR4025I 22.18.04 DEACTIVATE OF LOADSET TCMCTZ00 SCHEDULED
DEACTIVATE PGM- TRS1S0 LOADSET- TCMCTZ00
OLDR1057I 22.18.05 CLE4 - DEACTIVATE LOADSET TCMCTZ00 FOR
CPU K COMPLETE
 After the deactivate is completed the last active version of the program in the TPF System
becomes the active program
 To delete a loadset from the TPF System:

 ZOLDR DELETE LSNAME
 LSNAME is the name of the loadset you want to delete
ZOLDR DEL TCMCTZ00

OLDR1016I 22.20.06 CELA - DELETE REQUEST RECEIVED
OLDR5207I 22.20.06 COLE - LOADSET TCMCTZ00 IS NOW SCHEDULED FOR DELETION
OLDR5252I 22.20.06 COLF - LOADSET TCMCTZ00 DELETED
DELETE PGM- TRS1S0 LOADSET- TCMCTZ00 ASMDATE- 99062
 After deleting a loadset of the same name can be loaded again using a ZOLDR LOAD functional
message
Step - by - Step Trace
Overview
 SST, is a terminal based command driven test tool provided to follow an entry in the TPF system.
 SST can trace only one entry at a time.
 It can be used to trace following :
 Any input message from the terminal.
 Input message from other terminals.
 Entries toa specific program.
 ECBs creayted due to ROUTC
 Any created ECB.
 SST can stop the entry traced at any of the following places.
 Before and after execution of macro.
 C function calls.
 TPFDB calls.
 Entry into specified programs.
 Reference to selected memory locations.
 General purpose register alterations.
 Before executing any instruction.
 If the traced ECB hits a system error, the entry is stopped.
 All the memory locations, registers and other areas associated with the entry can be displayed or
modified during tracing.
 One can suppress the execution of an instruction or macro if needed.
 An ECB traced can be exited using any time using ZEXIT.
 SST also provides features to collect statistics about the entry traced.
Getting into & out of SST Session
 Access the TPF Test system.
 Sine on to application using
BSIA0000ZZ/PR
 Load the loadset and activate loadset containing your program using
ZOLDR LA TRN TCMCTOS0
 To sign into SST use the command
ZUSST IN
 To sign out SST use
ZUSST OUT
 Deactivate and Delete your loadset using
ZOLDR DD TCMCTOS0
 Sine Off application using
BSO
 After we have entered the SST, the basic trace options need to be set up, which will specify what's
to be traced.
 The most basic and frequently used case, when we trace all the macros calls that are executed
issued from the traced program.
ZSSTM TRS1 -ALL
 To clear the trace options, either sign out of SST or by issuing the command.
ZSSTM
 ZSSTM takes no parameters and clears the trace options set.
Tracing an Entry
 The entry is keyed in that's to be traced like
ZTRS1 D
 SST will trace the entry when the control reaches the program specified in the option TRS1.
 The entry to trace is intimated by SST as the prompt
STARTING IN TRS1 008
 The execution is stopped now, and one can start the trace by hitting the ENTER key.
Instruction Trace
 Instruction-by-instruction (IBI) mode of SST allows you to step through an instruction at a time
rather than a macro at a time.
 To trace the program or entry instruction by instruction, the following command is issued.
ZSSTI ON
 The following command will turn select the instructions which are to be traced. Now, to start, let's
trace all the instructions without knowing the groupings.
ZSSTI ALL ON
 To turn off IBI trace, issue the following command.
ZSSTI ON
 Step through code one instruction at a time using ZSTEP (or by hitting ENTER key).
 When fifnished diagnosing at instruction level, remove stop at all intstructions using
ZSSTI ALL OFF
 Turn instruction mode tracing off using ZSSTI OFF
 You are returned to macro level trace of SST.
Note : Rather than trace every instruction, use IBI parameters to trace within a range of code, or stop
only on specific instructions.
Example - want ot trace at IBI level in a range of code that is executed following (not necessarily
imediately) a macro that is working correctly, say a FINWC (Uses the PS proram segment option of IBI
mode)
 ZUSST IN
 ZTRSx D ( the entry )
Hit ENTER key untill positioned in your program at the correct FINWC macro. Then,
 ZSSTI ON
 ZSSTI PS TRSx ddd.rrr
Where ddd = displacement within TRSx
rrr = address range
Each ENTER will stop before execution of instruction in ddd.rrr.
 ZEXIT or ZSTEP GO
 ZSSTI PS OFF
 ZSSTI OFF
 ZUSST OUT
Display and Alter commands
ZDECB GPR To display the Register contents

ZDECB CBR To display the CBRWs
ZDECB FAR To display the FARWs
ZDECB EBWnnn T To display the ECB work area
ZDECB EBXnnn T To display the ECB work area
ZDLEV Dn To display the Contents of Data level
ZDEVM sss.rrr To display the memory locations
Note :
 While displaying the Work Areas the following is the rule, to be noted while using nnn.
 nnn specifies the decimal work area location (000-048) form which the traced ECB work area
display should begin. This value will be rounded down to the nearest 8-byte boundary unless it is
above 048, in which case it will be rounded down to 048, always, results in 48 bytes being
displayed.
ZDISP aaaaaaaa.hh To display core address aaaaaaaa for hh (in hex) bytes
ZDISP b.hh To display address referenced by register b for hh (in hex) bytes.
ZDISP reg To display contents at address in register reg.
ZDECB MIN To display current instruction
ZDECB (opts) To display ECB as requested by options
ZDECB APP TPF User Area (CE2USER)

ZDECB CBR CBRWs 0-15 ....
ZDECB CRW CBRWs 0-6, R0-R9, R14-R15 ....
ZDECB FAR FARWs 0-15 ....
ZDECB FAW FARWs 0-6, R0-R9, R14-R15 ....
ZDECB USR user-specific fields (defined in ECBUDS)
ZDECB EBWnnn{T} 56 bytes of work area 1 from EBWnnn (translated)
ZDECB EBXnnn{T} 56 bytes of work area 2 from EBXnnn (translated)
ZALEV Dn ddd hh.hh Alter Core Block attached at a Data Level where ddd is hex displacement
with upto 16 bytes of hex data hh..hh
ZAEVM b ddd hh..hh alter core defined by a register and displacement in hex
Other useful commands
ZSSTI DI To display all trace options
ZSTEP To step through the code one instruction(or more) at a time
ZSTEP CReate begin tracing created entry, and stop at the next trap
ZSTEP RETRY {NEXT} retry the trapped macro/instruction, and stop at the next trap
ZSTEP DISPLAY (re-)display the output resulting from the last ZSTEP
ZSTEP NEXT stop at the next macro (or instruction if in IBI mode)
ZSTEP ABOVE|BELOW stop when executing location is above/below current value
ZSTEP GO continue tracing without stopping until entry completes
ZFLIP interchange data levels x and y OR Dx Dy.
ZHELP display a list of available SST commands & on-line user guide
information for SST command
ZHOLD hold current traced ECB
ZRELC release core block at level x
ZGETC get core block of size n at level x

To trace a created ECB
 To trace (i.e. take over) a Terminal or Program candidate entry:
 Specify the required candidate (via ZCAND). The response will be :
CAND0138I TERMINAL CANDIDATE NOW ACTIVE
Or CAND0139I PROGRAM CANDIDATE NOW ACTIVE
Or CAND0165I UNABLE - NO TERMINAL CANDIDATE DATA EXISTS
Or CAND0166I UNABLE - NO PROGRAM CANDIDATE DATA EXISTS
 When an entry is selected for tracing (i.e. take over), and providing that the origin address can be
determined, the originating terminal will be sent the message:
BGT10141I YOUR ENTRY HAS BEEN INTERCEPTED - NOW TRACED BY lniata
 And the tracing terminal will be sent the message:
BGT10001I INPUT FROM TERMINAL lniata INTERCEPTED
 The intercepted entry will be suspended at the first instruction in the 'target' program , allowing
trace options to be changed to reflect the path of the new entry.
 To determine whether an entry has been taken over use ZDECB.
Topics for further reading
Topics for further reading
 In order to make the book a comprehensive material for begineers, a few concepts are omitted.
 The participants can learn about these topics if they are comfortable with the basics or based on
their project requirements.
 The list for further reading as follows:
 System States
 MDBF
 Types of executive macros
 Address Spaces
 Heap Storage
 MCHR and File addressing in TPF
 File address Conversion
 FARF
 Pool Management
 GETLC, GETSC and pool related comination macros
 CPU loop
 SWISC macro
 SAL and PAT
 Transfer Vector
 Long life ECB
 Time Slicing
 Dump Options and Suppressing
 Globals – classifications, Details about VFA
 COFRA
 Process Syncronisation and Serialisation mechanisms in TPF
 General Tape macros
 Details about the utilities in TPF
 Information about these can be found in the book manager.
Acknowledgements

Introduction To TPF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction To TPF

Uploaded by

Copyright:

Available Formats

Introduction To TPF

 120,000 end users

Provides platform for high volume mission critical transaction processing.

No Preemption Processes Pre-empted

Rigid Database , 3 Record sizes Only Flexible database structure

Unique , Horizontally allocated database Hierarchical File System

No Priority of tasks Processes can be prioritized

Unique Network Protocols Standard Protocols

Traditionally supports Low level assembly

Shared database , Minimum protection File level access restrictions

Supporting environment required Development can be done in UNIX itself

Doesn't support batch processing Supports batch processing

Restarts to normal operating state in 2 minutes Longer restart period required

Operating System Source code Supplied Not Supplied

New Convention Old Convention Available for

Package Identifier Version Number

* - Will be dealt in detail later.

 The program should be of the following structure.

* - Will be dealt in detail later.

What is a Data Macro?

How to create/use a data macro?

Employee number 4 digits

The following will be the DSECT definition.

Scene Value of Variable A

* - Will be dealt in detail later.

 TPF system by definition, is a system that aims at high performance.

The input message

SAT 31JUL 1200 MAA - SIN SINGAPORE

User keys in entry, to book one ticket from in the flight

More about the ECB

Anatomy of the ECB

 The ECB is of size 12 K fixed.

Application Area in ECB.

 The application area in the ECB is used to achieve reentrancy.

Data Levels : Basics

Data Levels : How are they populated?

Data Levels : Classification

 There are 16 CBRWs, 16 FARWs, 16 FAXWs and 16 Error indicators.

Dynamic Address Translation

Conventional Use of Virtual Memory

 The concept of virtual memory is often used to implement two things:

Type Purpose Description

Block type Usage Blocks / frame

Frame attached to the ECB

Block 0 Block 1 Unassigned

Indicator Meaning Notation used

Return Conditions  The CBRW at the specified level is updated.

Example  The following macro call gets a 4K block on level 6.

Return Conditions  Control is restored to the next sequential instruction (NSI).

Errors Possible  None.

Restrictions  No authorization required.

Example  Test and release data level 5.

Restrictions  No authorization required.

Sun Mon Tue Wed Thurs Fri Sat

Vertical Database Allocation:

Horizontal Database Allocation:

Prime Mod 0 Prime Mod 1 Prime Mod 2

Duplicate Mod 0 Duplicate Mod 1 Duplicate Mod 2

 Return from FACE/FACS:

 Error or Exception Return

After call to FACE/FACS

Record Id Record Code Unused File address

 Record ID can either be setup or set to X'0000'