This is the first in a series of blog posts detailing core concepts and practical knowledge for the z/TPF Database Facility Enterprise Edition (z/TPFDF) product. Each new post will build on the ideas and skills learned in the previous installments.

Where z/TPF excels in processing mission-critical transactions at the lowest possible cost, z/TPFDF enables high-speed access to persistent databases. As a co-requisite product to the operating system, your workloads would be impossible without the ability to read and update real-time data. And when it comes to meeting the needs of end-users—customers swiping credit cards or booking travel tickets—it’s essential that this data is accessible by your applications, secure from malicious actors, and always accurate.

Whether you’re a database administrator, a z/TPF application programmer, or just regularly interacting with z/TPF data, you should be familiar with the components and capabilities of z/TPFDF. 

In this blog post, we’ll discuss how data is organized on z/TPFDF.

A Different Kind of Database

z/TPFDF is a database management system originally developed for use by z/TPF applications. Since its inception, its usefulness has been extended: the platform now supports a MongoDB interface, allowing distributed systems and Java on z/TPF to read and update z/TPFDF data. 

z/TPFDF is a NoSQL database (although it far predates the coining of the term "NoSQL")—that is, data in z/TPFDF databases is not stored in the table-like relational structure popularized by database systems like MySQL. Instead, it use a hierarchical structure to store data. It also provides a level of abstraction above traditional z/TPF find/file databases, allowing users to manage their data without worrying as much about the nitty-gritty details of how to store data on DASD.

To better understand the unique advantages of z/TPFDF, let's dive into how it defines and organizes data.

Files, Subfiles, and LRECs

z/TPFDF data is stored in a hierarchical structure of files, subfiles, and logical records (also known as LRECs).

A typical z/TPFDF database could consist of many files. Note that "file" in the context of z/TPFDF should not be conflated with the more common concept of files in a file system. Each z/TPFDF file is identified by a unique record ID. A record ID is 4 hexadecimal characters (for example, "B426" is a valid record ID). Each file contains many pieces of the same "type" of data.

For example, you may have a file for Passenger Number Records (PNRs), where the file contains information on every passenger in your system. Each PNR in that file is called a subfile. A subfile is one "unit" of the type of data contained in the file. Each subfile can contain many LRECs. For example, a particular PNR may contain the following LRECs:

• Passenger Number Record: unique number to identify the passenger
• Passenger Name Record: the passenger's name
• Address Record: the passenger's address
• Credit Card Record: the passenger's credit card information
• Notes Record: notes on the passenger. Do they have allergies? Do they prefer window seats or aisle seats?

Note that a subfile may contain several of each type of LREC. For example, a passenger may have more than one credit card on file, or may have multiple Notes records describing different factors to consider.

Database Definitions and DSECTs

The attributes of each z/TPFDF file are contained in a database definition (DBDEF), which is coded as a macro in an assembly language file. When you assemble and load a DBDEF to the z/TPF system, z/TPFDF will be able to reference the DBDEF when accessing records with that file ID. The DBDEF macro can have dozens of potential parameters, many of which are advanced parameters that are out of the scope of a preliminary lesson on z/TPFDF. For reference, here is an example of a DBDEF macro. We will examine some particular options on this macro in future topics.

The DSECT macro for a file ID describes file attributes that are not specified on the DBDEF macro. The DSECT macro also describes the format of the data inside of a file. z/TPFDF DSECTs are just like any other DSECT in IBM's High-Level Assembler Language. z/TPFDF DSECT macros should follow a pre-defined format that IBM provides in its sample code. A z/TPFDF DSECT will contain definitions for each type of LREC that a subfile could contain. For reference, here is an example of a segment of the DSECT macro corresponding to the above DBDEF macro. This DSECT represents the fields in one LREC representing a hotel guest; it contains fields for the passenger’s name, address, spare space, balance, and credit card number.

In addition to DSECT macros, you may also create C structures in header files, to allow C/C++ programs to work with z/TPFDF data. Here is an example representing the same type of LREC, but this time as a C struct.

You should now have a basic understanding of how z/TPFDF databases are structured, along with some of the essential terms and concepts that keep z/TPF data organized and how those concepts apply to the example of a PNR.

In the next installment, we’ll dive into practical concepts around basic application usage. If you have any questions about what you learned in this article, get in touch with a member of the z/TPF development lab, or try consulting our documentation for z/TPFDF.