Training Module 8: Common Performance Engine Errors

The slides used in this video are shown below:

Slide 1

Welcome to the training course on IBM Scalable Architecture for Financial Reporting, or SAFR. This is module 8: “Common Errors Encountered When Running the Performance Engine.”

Slide 2

This module provides you with an overview of common errors encountered when running the SAFR Performance Engine. Upon completion of this module, you should be able to:

  • Diagnose and resolve common Performance Engine errors,
  • Set output record limits to assist in debugging, and
  • Analyze the relationships between components using the Dependency Checker.

Slide 3

Under normal circumstances, the SAFR Performance Engine transforms data and provides useful outputs. However, if a Performance Engine program detects an unusual condition, it will display an error message. Errors can occur for many different reasons.

Recall that the SAFR Performance Engine consists of six phases. Each phase creates data sets that are read by subsequent phases. If the JCL that executes a program does not point to the data set that the program is expecting, or if it is missing a needed data set, an error is reported.

Errors can also occur if keywords in JCL parameters are missing or misspelled. On the following slides, we’ll cover the most common error conditions and describe how to remedy them.

Slide 4

Recall that the Select phase produces a control report named MR86RPT, or the MR86 Report. This control report contains useful statistics for the current run and, if an error occurs, an error message to help you diagnose the problem.

Slide 5

A view must be active and saved to the Metadata Repository to be selected by the MR86 program. If it is not, an error message is displayed in the MR86 Report, specifying the view number and name.

To remedy this problem, find the view in the Workbench, activate the view, save it, and then rerun the job.

Slide 6

The MR86 program looks for views only in the environment specified by the ENVIRONMENTID parameter in the MR86 configuration file. If the MR86 Report displays a message saying that no views can be found, the problem is often that the wrong environment has been specified there. This value must match the value that is displayed in the Workbench status line, which is the bottom line of the Workbench window. We can see here that the true environment ID is 7 and the value for ENVIRONMENTID in the JCL is 7777, which is a typographical error. In such cases, you correct the ENVIRONMENTID value in the configuration parameters and rerun the job.

Slide 7

For the MR86 program to find your views, the database connection parameters in the MR86 configuration file must be specified correctly. One connection parameter is the schema. The value of the schema parameter must match the value that is labeled as “database” in the Workbench status line. In this example, the schema value is SAFRTR01, but the SCHEMA parameter is SAFRTR01XXXX. Because these two values do not match, a database error is displayed in the MR86 Report. In such cases, you should correct the SCHEMA value in the configuration parameters and rerun the job.

Slide 8

In the Compile phase, the MR84 program reads the XML file created by the prior step and converts it to a form that can be executed by the Extract phase later. This process, called compiling, checks for syntax errors and other errors in the XML file and displays associated messages in the MR84 Report. This report seldom displays any error messages because under normal circumstances, views that are read by the MR84 program have already been compiled by the Workbench. If you encounter a problem in this phase, report it to SAFR Support.

Slide 9

In the Logic phase, the MR90 program reads the VDP file created by the prior step and converts it into data sets that are used later by the Reference phase and the Extract phase. Errors that occur in this phase are rare and are usually the result of database corruption. If you encounter a problem in this phase, report it to SAFR Support.

Slide 10

In the Reference phase, the MR95 program converts reference data into a form that is appropriate for lookup operations that are executed subsequently in the Extract phase. MR95 produces a control report known as the MR95 Report, which either indicates successful completion or displays errors that must be corrected before proceeding.

Slide 11

The view shown here reads the ORDER_001 logical file and displays data from two lookup fields: CUSTOMER_ID and NAME_ON_CREDIT_CARD.

Slide 12

We can see from the column source properties that the CUSTOMER_ID field receives its value from data accessed by the CUSTOMER_from_ORDER lookup path.

Slide 13

We can also see from the column source properties that the NAME_ON_CREDIT_CARD field receives its value through a different lookup path named CUSTOMER_STORE_CREDIT_CARD_INFO_from_ORDER.

Slide 14

If the JCL for the Reference job does not contain DD statements for all reference files needed to support the selected views, the job terminates with an abnormal end (or “abends”). The MR95 Report displays a message with the DD name of the missing file, which in this case is CUSTCRDT.

Slide 15

The error condition in this case can be remedied by adding the CUSTCRDT file to the JCL and rerunning the job.

Slide 16

The Reference Extract Header (or “REH”) file, with a DD name of GREFREH, is required for the Reference phase to function correctly. If the DD statement for the REH file is missing, an error message is displayed in the MR95 Report, saying that the DCB information for the file is missing. To remedy the problem, add the DD statement for GREFREH to the JCL and rerun the job.

Slide 17

Similarly, a Reference Extract Detail (or “RED”) file associated with every lookup path is required for the Reference phase to function correctly. DD names for RED files begin with the letters “GREF” and end with a 3-digit number. If the DD statement for a RED file is missing, an error message is displayed in the MR95 Report, saying that the DCB information for the file is missing. In this case, the GREF004 file is missing. To remedy the problem, add the DD statement for GREF004 to the JCL and rerun the job.

Slide 18

For reference files to function correctly in SAFR, there are two rules which must be followed:

  • First, records must have unique keys
  • And second, records must be sorted in key sequence.

If either of these rules is broken, a “lookup table key sequence” error message is displayed in the MR95 Report. To resolve the problem, we must first examine the error message and note the DD name associated with the reference work file in error. In this case, the DD name is GREF004. We can then use this to find the DD name of the source reference file. Scanning upwards in the MR95 Report, we can see that GREF004 is written using records read from the DD name CUSTCRDT.

Slide 19

To research this problem further, we must find the length of the key associated with the logical record for customer credit card Info. In this case, it is 10. We must also find the data set associated with the DD name CUSTCRDT. From the JCL, we can see that it is GEBT.TRN.CUSTCRDT.

Slide 20

If we open the data set GEBT.TRN.CUSTCRDT on an ISPF Edit screen, we can see that records 5 through 9 all have the same key value. But rule #1 stated that each key must be unique. We can also see that the records are not in key sequence, which breaks rule #2. To solve our original problem, we remove the duplicate records and sort the records in key sequence. Doing this and then rerunning the job will remove the error condition.

Slide 21

Sometimes when you are debugging a problem, it is useful to limit the number of records written to an extract file. You can set such a limit in the Workbench on the Extract tab of the View Properties screen for a view. Processing for the view will stop after the specified number of records is written. Remember, you must rerun from the Select phase to incorporate the view changes into the Extract phase.

Slide 22

You can set a similar limit for the final output file that is written in the Format phase. You can set such a limit in the Workbench on the Format tab of the View Properties screen for a view. Processing for the view will stop after the specified number of view output records is written. Again, you must rerun from the Select phase to incorporate the view changes into the Format phase.

Slide 23

The Dependency Checker is a useful tool for debugging views. You can select it from the Reports menu of the Workbench.

Slide 24

In this example, you want to see all direct dependencies for view #71. First, select the appropriate environment, and then select the component type, which in this case is View. Then select view #71 from the list.

For debugging purposes, we normally select the Show direct dependencies only check box. Clearing the check box would cause indirect dependencies to be displayed, too, and this is typically useful only when an impact analysis is needed for a project.

Slide 25

After clicking Check, you see a hierarchical list of all the SAFR metadata components that are used by the view. This helps you determine whether any components that should not have been referenced are referenced and whether any components are missing. Portions of the list can be expanded by clicking the plus sign or collapsed by clicking the minus sign.

Slide 26

In the Extract phase, MR95 executes a series of operations that are defined in the Extract Logic Table, or XLT. The MR95 Trace function causes these operations to be written to a report to aid you in debugging a view. The Trace function can be selected and configured in MR95PARM, the MR95 parameter file.

Trace can be used to diagnose many SAFR problems:

  • LR problems
  • Lookup problems
  • View coding errors, and
  • Data errors

The Trace function will be described in detail in an advanced SAFR training module.

Slide 27

When you are developing a view, you should apply several guidelines to make your work more efficient.

Begin by coding a small subset of the requirements for a view, and then testing that. For example, you may choose to code a view with only a small number of columns or a smaller record filter. Once you have successfully gotten this view to work, you can add more complexity and continue until the view is complete.

It is useful to start testing with only a small number of records. In this way, you can more easily see the results of your view logic.

Verify that the output format for each column is correct. If it isn’t, review the column properties.

Check to make sure that the number of records written is what you expected. If it isn’t, check the record filters to verify that the logic is correct.

Finally, verify that the output value for each column is correct. If it isn’t, examine the column logic.

Slide 28

This module provided an overview of common errors encountered when running the SAFR Performance Engine. Now that you have completed this module, you should be able to:

  • Diagnose and resolve common Performance Engine errors
  • Set output record limits to assist in debugging, and
  • Analyze the relationships between components using the Dependency Checker

Slide 29

Additional information about SAFR is available at the web addresses shown here.

Slide 30

Slide 31

This concludes the Module 8. Thank you for your participation.

Training Module 2: Performance Engine Overview

The following slides are used in this on-line video :

Slide 1

Welcome to the training course on IBM Scalable Architecture for Financial Reporting (or SAFR). This is module 2, “Performance Engine Overview.”

Slide 2

This module provides you with an introduction to the SAFR Performance Engine and how to use it. By the end of this training, you should be able to:

  • Identify the phases of the Performance Engine
  • Identify the main inputs and outputs for each phase
  • Give a high-level overview of the reports from each phase, and
  • Run a Performance Engine job stream

Slide 3

As we noted in the “Introduction to SAFR Views” module of this training course, SAFR consists of two software components: a PC-based Workbench and a mainframe-based batch process known as the Performance Engine. Developers use the Workbench to build applications that are stored in a metadata repository in an IBM® DB2® database. These applications are then executed by the Performance Engine, which reads data from source files or databases, transforms it, and writes it to output files. In this sense, SAFR is an application development tool and is not fundamentally different from any other tool or language.

Slide 4

The Performance Engine comprises six phases:

  • The SELECT phase, where the desired views are selected from the Metadata Repository
  • The COMPILE phase, where the selected views are converted to an executable form
  • The LOGIC phase, where logic from multiple views is consolidated and optimized for execution
  • The REFERENCE phase, where values are retrieved from lookup tables and optimized for execution
  • The EXTRACT phase, where data from source files is retrieved, merged with lookup data, and transformed for output, and
  • The optional FORMAT phase, where data is sorted, summarized, and formatted if necessary

Slide 5

The primary SAFR program in the Select phase is GVBMR86 (The names of all programs in the SAFR Performance Engine start with the letters “GVB,” so it is common to refer to this program as MR86). MR86 reads a list of view numbers and finds the corresponding views in the SAFR Metadata Repository. It then processes these views and converts them to an Extensible Markup Language (or XML) file. It also produces a control report known as the MR86 Report, which indicates successful completion or displays errors that may have to be corrected before proceeding.

Slide 6

The view numbers for the desired views are placed in the JCL, using a DD name called VIEWLIST. In this example, we are specifying view 90, which is the view we created in the “Introduction to SAFR Views” module of this training course.

Slide 7

For a view to be selected, it must first be set to Active status in the Workbench. If the view is not active, the MR86 Report will contain the error message “View is inactive.” A view that is inactive cannot be run.

Slide 8

When errors occur, MR86 also issues a condition code of 8 for the job step, which typically causes the remaining job steps to be skipped.

Slide 9

Once the view is activated in the SAFR Workbench, MR86 can be rerun and the view should be successfully selected for processing. If no other errors are encountered, the MR86 Report does not contain the word “ERROR” at the beginning of any row, and MR86 returns a condition code of 0 for the job step, allowing remaining jobs steps to run.

Slide 10

The primary SAFR program in the Compile phase is GVBMR84. MR84 reads the XML file created by the previous step and converts it to a form that can be executed by the Extract phase later. This new file is called the View Definition Parameters (or VDP) file. Because multiple versions of the VDP file are used in the SAFR job stream, this one is referred to as the MR84 VDP to indicate the program that wrote it. MR84 also produces a control report known as the MR84 Report.

Slide 11

The MR84 Report indicates successful completion or displays XML syntax errors and view compile errors that have to be corrected before proceeding. If there are no errors, the process continues. 

The MR84 Report also shows how columns in the view are translated into a specialized SAFR construct known as a logic table.

Slide 12

The primary SAFR program in the Logic phase is GVBMR90. MR90 reads the MR84 VDP file created by the previous step and creates a new VDP and logic tables that are used by the next steps, the Reference and Extract phases. The new VDP is called the MR90 VDP to distinguish it from the input VDP file. The logic tables are known as the MR90 JLT (for “Join Logic Table”) and the MR90 XLT (for “the Extract Logic Table”).

The next programs in the Logic phase, which are not shown here, read these files and produce converted versions known as the MR77 VDP, the MR76 JLT, and the MR76 XLT.

Slide 13

The MR90 Report displays summary statistics for the Logic Table Creation process. In this case, the Extract Logic Table contains nine records. This view included no joins, so no records were written to the Join Logic Table. The report also displays, in detail format, the contents of the Extract Logic Table and the Join Logic Table if applicable.

Slide 14

The primary SAFR program in the Reference phase is GVBMR95. MR95 reads the MR77 VDP file and the MR76 JLT file created by earlier steps and one or more Reference Data files. It then produces a Reference Extract Header (or REH) that describes the format of the reference data being processed. It also creates one Reference Extract Detail (or RED) file for each Reference Data file read. These files contain only the data required to perform joins in the Extract phase. Finally, MR95 produces a control report known as the MR95 Report, which indicates successful completion or displays errors that may have to be corrected before proceeding.

Slide 15

If this job stream does not access any Reference Data files, the MR95 Report displays a warning message saying that there is an “empty or abbreviated logic table.” If you do not intend to access any Reference Data files, this is considered a normal condition and you may proceed to the next step.

To be processed correctly, reference data must be sorted in key sequence and have no records with duplicate keys.

Slide 16

The primary SAFR program in the Extract phase is GVBMR95, which is the same program that is run in the Reference phase. In reviewing the job stream output, you should take care not to confuse the outputs of the two executions of MR95.

MR95 reads the MR77 VDP file, the MR76 XLT file, and the REH, and RED files created by earlier steps, along with source data for the process (Source data is sometimes referred to as business event data or just event data).

MR95 executes various transformations and, depending on specifications in the selected views, produces one or more View Output files. It may also produce one or more Extract Work files, which are temporary files processed by the Format phase. Finally, it produces an MR95 Report, which presents summary statistics for the process. 

Slide 17

Before running the Extract phase job, you must make sure that DD statements for any required input files are included, containing the data to be scanned and extracted according to the view requirements. The DD names (such as CUSTOMER or ORDER001) must match those in the Workbench physical files referenced by the views being run.

Slide 18

Similarly, you also must ensure that DD statements for any required output files are included. These DD names are determined by view parameters in the Workbench.

Slide 19

The Extract phase MR95 Report displays statistics that are useful for audit trails and performance tuning. In this example, we can see that 12 records were read from the ORDER001 file, 12 records were processed by view 90, and 12 records were written to the OUTPUT01 file.

Slide 20

A secondary program in the Extract phase is GVBUT90, which produces the UT90 Report. This report displays information from the Extract Logic Table (XLT), which shows each step that is executed in a data transformation. This is useful information for debugging views. A more detailed discussion of the logic table is presented in the training module entitled “Basic Debugging.”

Slide 21

The primary SAFR program in the Extract phase is GVBMR88. MR88 reads the MR77 VDP, REH, and RED files created by earlier steps, along with the temporary Extract Work files for the process. It then sorts, summarizes, and formats the data, producing one or more View Output files. Additional details will be provided in the training module entitled “Introduction to the Format Phase.”

Slide 22

This module provided an overview of the SAFR Performance Engine. Now that you have completed this module, you should be able to:

  • Identify the phases of the Performance Engine
  • Identify the main inputs and outputs for each phase
  • Give a high-level overview of the reports from each phase, and
  • Run a Performance Engine job stream

Slide 23

Additional information about SAFR is available at the web addresses shown here.

Slide 24

Slide 25

This concludes the Module 2. Thank you for your participation.

Training Module 1: Introduction to Views

The following slides are used in this on-line video :

Slide 1

Welcome to the training course on IBM Scalable Architecture for Financial Reporting, or SAFR. This is Module 1: Introduction to SAFR Views.

Slide 2

This module provides you with a broad overview of the SAFR product and the basics of its graphical user interface. By the end of this training, you should be able to:

  • Identify the two major software components of the SAFR product
  • Identify the major types of SAFR metadata
  • Navigate the SAFR Workbench, and
  • Create a simple view. 

Slide 3

SAFR is a software application development tool that solves high-volume data analysis and reporting problems. SAFR provides capabilities for data transformation, data mining, database query, and financial reporting.

Slide 4

SAFR consists of two software components: the PC-based Workbench and the mainframe-based batch process known as the Performance Engine. Developers use the Workbench to build applications that are stored in a metadata repository in an IBM®  DB2®  database. These applications are then run by the Performance Engine, which reads data from source files or databases, transforms it, and writes it to output files.

Slide 5

Several types of metadata make up a SAFR application. The most common are the environment definition, the physical file definition (or PF), the logical file definition (or LF), the logical record definition (or LR), the view definition, and the view folder. 

Note that, when discussing SAFR metadata, we often omit the word definition because it is usually clear from the context whether we mean the metadata or the entity it refers to. 

Slide 6

An environment definition describes a logical collection of metadata within the SAFR Workbench. Typical types of environments include development, production, or training environments. Access to an environment can be restricted to a certain set of users. 

Slide 7

A physical file definition, or PF, describes a data source. Examples include customer or order files. A logical file definition, or LF, describes a collection of one or more physical files. A logical record definition, or LR, describes a record layout. In COBOL programs, record layouts are often found in copybooks. In relational databases, they are found in table definitions.

Some examples of these metadata types are shown here. 

  • A logical record for a customer is used to map data to a customer logical file. The customer logical file refers to data in a customer physical file. 
  • An order logical record is used to map data from a logical file named ORDER_001, which refers to data in a single physical file named ORDER_001. 
  • The order logical record can also be used to map data from a logical file named ORDER_ALL. ORDER ALL refers to a collection of order physical files.

Slide 8

A view definition describes a data transformation. It is analogous to a program or a query. Views are the basic units of work that are performed by the Performance Engine. 

Views are often grouped together into view folders for ease of maintenance. View folders are often named for a particular developer or function. Security can be applied to view folders to prevent unauthorized access. 

Slide 9

The SAFR Workbench is used to add, change, and delete SAFR metadata. It contains a menu and toolbar, and consists of multiple display areas, or frames. 

  • The Navigator area displays the types of metadata available. 
  • The Metadata List area displays a list of items for the selected metadata type. 
  • And the Editor area is the part of the screen where you modify metadata items.

Slide 10

  • By expanding the View Folders item in the Navigator area, you can see a list of all view folders. 
  • The contents of the selected folder are displayed in the Metadata List area.
  • From there, you can select a view for editing and the view will be displayed in the Editor area.

Slide 11

View information is displayed on two separate screens:

  • The View Editor screen, where you can define specific data transformations.
  • The View Properties screen, where you can modify information that applies to the whole view. 

Slide 12

You use the General tab on the View Properties screen to specify the output format – flat file or hardcopy report – and other related information. 

This tab also displays information about when the view was created and last modified and by whom. 

Slide 13

In addition, the General tab displays the name of the view folder where the view is stored.  

Slide 14

You can access advanced features on the Extract Phase tab and the Format Phase tab. You can open these tabs by single-clicking them. 

Slide 15

You can toggle back and forth between the View Properties screen and the View Editor screen by clicking the first icon in the Editor area toolbar, or by pressing the F9 key.

Slide 16

In View Editor mode, the Workbench displays several frames of view information. 

Slide 17

The View Editor grid displays the characteristics of view output columns. These characteristics include the data type, the length, and the alignment, such as left, right, or center. 

Slide 18

You can display information about the data source for the view by right-clicking a blue cell in the View Editor grid. This information includes the logical record and the logical file. 

Slide 19

To open a frame showing the column source properties, you right-click a green cell. The source of a column’s data can be a field in the source file, a constant, a lookup value, or the result of a formula. 

Slide 20

The View Editor incorporates several functions, such as inserting a column or activating a view. You can run a View Editor function in several ways:

  • Select it from the Edit menu or the Action menu for the Workbench
  • Left-click the function icon on the View Editor toolbar
  • Right-click in the View Editor grid and select the function from the pop-up menu
  • Or press the appropriate key combination, which is noted on the Workbench menu and the pop-up menu. 

Choose whichever technique you prefer. 

Slide 21

To add a new view source, you right-click on the grid to display the pop-up menu, and then select Insert and View Source

Slide 22

The Insert View Source window opens. You can select from a list of data sources in the window. 

Slide 23

Now let’s take what you’ve learned and create your own view. The following example is a simple data transformation, reading data from the ORDER001 file and writing out only the Order ID, Customer ID, and Total Amount fields. 

Slide 24

If we were to code a conventional program, we would:

  • Define the file attributes
  • Define the record layouts
  • Code the business logic
  • Compile the program
  • Link the program and
  • Run the program

Slide 25

With the SAFR tool, the first three steps are performed in the Workbench and the last three are performed for you by the Performance Engine. 

Slide 26

Defining files and records will be covered in the SAFR training module entitled “Creating Metadata.” The Performance Engine will be introduced in the “Performance Engine Overview” module. The topic of coding business logic will be introduced in the next few slides. 

Slide 27

In the example described in the following slides, metadata has been pre-populated in the Workbench for ease of instruction. 

To create a new view, click the Administration menu, select New and then select View.

Slide 28

The View Properties tab opens. 

Slide 29

Enter a descriptive name for the view, such as “Simple_Transformation_View.” Note that embedded spaces are not allowed in names, so you must use underscores to separate words. Next, clear the Format Phase check box; this feature is not needed for this simple view.

Slide 30

To display the View Editor Grid, select Show Grid or Properties, from the Edit menu (Alternatively, you can click the toolbar icon or press the F9 key).

Slide 31

From the Edit menu, select Insert, and then select View Source (Alternatively, you can right-click and select Insert and then select View Source from the pop-up menu, or you can press the Shift key and the Insert key). The Insert View Source window opens.

Slide 32

From the Logical Record list, select ORDER. Then, from the Logical File list, select ORDER_001

Slide 33

From the Edit menu, select Add Column (Alternatively, you can click the plus sign icon on the toolbar or press Alt and the Insert key). A new column is added to the grid. 

Slide 34

Click the green cell. The Column Source Properties frame opens on the right. 

Slide 35

In the Column Source Type field, click the list box and select Source File Field

Slide 36

In the Column Source Value field, click the list box and select ORDER_ID.  

Slide 37

Repeat the previous steps to add columns for Customer ID and Order Total Amount. Then save the view by selecting Save from the File menu, or by clicking the Save icon in the Workbench toolbar, or by pressing Control and S. 

Slide 38

To activate the view, use any of these methods:

  • Select Activate from the Action menu
  • Press the Activate icon on the View Editor toolbar
  • Press F5. 

The view title bar now displays the word “active”. Save the view again to preserve this active state. The view is now ready to be run.

Slide 39

This module provided an overview of SAFR. Now that you have completed this module, you should be able to:

  • Identify the two major software components of the SAFR product
  • Identify the major types of SAFR metadata
  • Navigate the SAFR Workbench and
  • Create a simple view

Slide 40

Additional information about SAFR is available at the web addresses shown here.

Slide 41

Slide 42

This concludes the Module 1. Thank you for your participation.

SAFR Overview for Technical Audiences: 2012

Although this deck was started in 2009, it was the primary tool used in talking about GenevaERS (renamed as the IBM Scalable Architecture for Financial Reporting in 2009) since 2012.

Documentation of its development is contained in the book Balancing Act: A Practical Approach to Business Event Based Insights, available for download from ledgerlearning.com.

Technical Team Resources: 1994

In the development of the system, the team learned certain documents were handy to have around (before the Internet, these types of documents were the Internet). The following were used to debug the system during development, testing, implementation projects, and subsequent maintenance.

More about this time can be read in Balancing Act: A Practical Approach to Business Event Based Insights, Chapter 23. Development and Chapter 38. Abends.

Logic Table Codes

The following diagrams were carried by many of the support team so as to be able to understand the GenevaERS “p-code” if you will, called the Logic Table.

IBM s/390 “Yellow Card”

The “Yellow Card” was not really a “card” at all, but a booklet containing short descriptions of all the essential elements of the System 390 mainframe. This was carried to work and home from work by some of the support team, and was often used in understanding the generated machine code and subsequent problems. In these pages one can find:

– The op codes or hex values for those instructions, if one is looking at machine code and trying to decide what the code is attempting to tell the machine to do.

– What the corresponding instruction name and intent of those machine instructions are.

– The various formats each of the assembler instructions take for s/390 assembler take.

– Other important things, like block sizes for various data storage devices

S/360 Green Card

Although never used on the commercial GenevaERS system (but likely used in some manner in the original system development at the State of Alaska), some technical team members were proud to receive a reprinted S/360 “Green Card” (from which the “Yellow Card” received it name)

CICS and Other Price Waterhouse Technical Helps

The following were also used at times; these were produced by Price Waterhouse as part of its Mitas Technical Training Program.

Technical Diagrams–Internal Memory Structures 1994

The following diagrams were created by Doug Kunkel probably in 1994 to explain the maintenance team the internal memory structures and pointers to them in the Extract Engine, MR95.

More about this time can be read in  Balancing Act: A Practical Approach to Business Event Based Insights, Chapter 38. Abends