Raincode zBridge

Version 6.0.136.0

Raincode Crossbow

Raincode Crossbow is a consistent release of the entire Raincode product line, covering compilers, emulators and ancillary tools.

In practice, Raincode Crossbow is designed with three driving forces:

A focus on performance across the board:
- The internal computation engine for non-binary numeric data types (display numeric or packed decimals) has been entirely overhauled, resulting in performance improvements that can go up to a factor of 5 (depending on the level of dependence on these non-binary data types)
- The file I/O layer has been optimized to ensure the best possible performance when dealing with indexed or sequential files
- RadaR is a revolutionary solution to run batch steps 5 to 10 times faster, without changing the application source code or even the JCL they are called from
- The Visual Studio plugin now runs the heaviest debugging operations asynchronously, thereby dramatically improving response time and the overall user experience, even when debugging programs with hundreds of active variables
- The views generated to access VSAMSql and IMSql data using plain SQL DML statements have been optimized dramatically
Updated .NET platform support running both on Linux and on Windows, on virtual machines or in containers, on the cloud, on laptops or servers managed on premise.
Consolidation of the product suite, allowing all Raincode software to be built and upgraded synchronously, thereby avoiding the headaches that come from multiple products that follow different (and sometimes, incompatible) release cycles.

Version 6.0

In addition to the above description, Raincode Crossbow v6.0 (see release notes) is a technical release that includes the following:

Support for .NET 10.0 and SQL Server 2025 across the board.
The Visual Studio plugin now supports Visual Studio 2022 and 2026, with improved support for JCL debugging.
Support for the File-AID JCL utility.
Support for TLS encryption on QIX and IMS TN3270 terminal servers.
Removal of support for .NET Framework and .NET 6.0.
Removal of support for Microsoft Host Integration Server (HIS) for Db2.
Removal of 32-bit support.

1. Introduction

Many organizations rely on legacy mainframe systems like z/OS or AS/400, where critical business data is stored in non-relational formats such as IMS® DB, VSAM, or sequential files. While highly reliable, these systems pose significant challenges when integrated into today’s environments.

Key reasons for this are the following:

Complex Data Access: Accessing and integrating data from mainframes requires specialized tools and knowledge, often creating operational bottlenecks.
Limited Analytics and Reporting: Non-relational data formats make it difficult to leverage modern business intelligence (BI) and analytics tools, limiting opportunities for insights.
High-Risk Migrations: Migrating data from mainframes to more modern platforms is costly, time-consuming, and comes with the risk of downtime or data loss.
Increasing Maintenance Costs: As mainframes age, the scarcity of skilled professionals drives up maintenance costs, further straining resources.

This is where zBridge comes in. Developed by Raincode, zBridge is an innovative solution that exposes mainframe data as views and tables. It transforms complex, non-relational datasets into easily accessible relational formats and eliminates the need for deep data restructuring or long, laborious cleanups. This allows developers to query mainframe datasets using standard SQL, just like they would with any modern relational database.

As a result, organizations can unlock the value of their data without undergoing a complete migration or disrupting their current systems.

1.1. How zBridge provides for mainframe data management

Figure 1. How zBridge provides for mainframe data management

zBridge is a four-step process:

Non-Relational Data Extraction: Mainframe data from IMS® DB, VSAM, or sequential files is broken down into two components: the structure definitions (e.g., DBD, copybooks) and the actual data.
Data Transfer: Mainframe utilities extract the structure and data, which is then exported from the mainframe.
Automated DB Creation: zBridge uses the structure definitions to create the necessary SQL Server tables and views, reflecting the original structure and format of the data.
Data Loading: After the database schema is set, zBridge loads the exported data into SQL Server tables. This process can be automated to run periodically, ensuring data remains up to date.

1.2. Accessing data with zBridge

zBridge is independent of mainframe applications (whether they are migrated or not). Instead, it enables organizations to efficiently read mainframe data from SQL Server by generating views from copybooks.

The key benefits of zBridge include:

Read-Only Access to Mainframe Data: Without needing a full migration, zBridge exposes your mainframe data through SQL views, providing your team with real-time insights and eliminating the delays typically associated with data retrieval while ensuring data integrity and security.
Minimal Risk, Maximum Value: By avoiding extensive data cleanups and restructurings, zBridge allows for immediate, low-risk access to your data without disrupting existing systems. This mitigates the potential for operational disruptions while maximizing the value of your data assets.
Cost-Effective Modernization: Organizations can leverage SQL Server’s advanced reporting and BI capabilities without the expense and risk of a complete mainframe-to-SQL migration. This facilitates gradual modernization at a lower cost, making it an attractive option for organizations seeking to optimize their IT expenditures.
Reduced MIPS Consumption: By accessing data externally via SQL Server, organizations can significantly lower MIPS usage on the mainframe when the data is utilized outside of the mainframe. This not only optimizes mainframe performance but also helps in managing operational costs, as reduced MIPS consumption can lead to lower licensing and maintenance fees.

2. zBridge/IMS

2.1. Introduction

This guide explains how to export IMS data to an SQL Server database, divided into two main steps:

Creating the Database structure
Transferring the data

The process leverages existing IMS® data descriptions (DBDs) and program copybooks to automatically generate the necessary SQL Server components.

DBDs only specify record length, key field, and optionally other fields. In contrast, copybooks specify all the fields, and there can be several copybooks for the same record. This is why the DBDs are only needed for transferring the data, but the copybooks are needed to access the data via the views.

2.2. zBridge/IMS Workflow

Figure 2. zBridge/IMS Workflow

The process of setting up zBridge/IMS consists of six steps, illustrated in the above figure. Each step is explained in detail below.

2.2.1. Database structure creation

The first part of the workflow creates a database that will store the IMS® data. This involves creating tables and views and is performed only once for each DBD. The DBDs define the structure of the IMS data and can be used to automatically generate the SQL script needed to create the database.

1. Transfer DBDs from the mainframe: These DBDs describe the structure of the IMS® data.

2. Generate the database creation script: Using the transferred DBDs, the tool IMSql.DbGenerator generates the SQL scripts to create the required tables in the database.

The second part generates views from the copybooks, providing easily understandable access to the data:

3. Copybook extraction: Extract the copybooks, which describe the internal structure of the segments, from the mainframe.

4. Generate view creation scripts: The tool CopybookViewGenerator uses the copybooks to generate views that represent the segment data in a human-readable format based on how it is structured in the application programs.

2.2.2. Transferring IMS data to the database

Once the database structure is in place, IMS® data can be periodically transferred to the database to ensure it stays up to date. Here’s how this works:

5. Unload IMS data: Use DFSRRC00, an IBM® utility, to unload IMS data from the mainframe. Transfer it out of the mainframe in binary form.

6. Load data into the database: The IMSql.Load tool transforms the unloaded IMS data into a format suitable for the SQL Server and loads it into the tables created during the database setup.

2.3. zBridge/IMS details

2.3.1. Database model (IMS/DB)

This section provides detailed information about the DB model

On Mainframes, DBDs (Database Description) are compiled to create the database.

On IMSql, DBDs will be used to generate an SQL script that creates the corresponding database on SQL Server.

DB model

DBDs are used to create the underlying database structure. The IMSql.DbGenerator reads all of the DBDs and produces an SQL script with the following database objects.

Table

A table named <DBD name>_<segment name> is created for each physical segment. The table contains the following columns:

Data: A varbinary column that contains all the segment data. The data is stored in the same format as the Mainframe, using EBCDIC encoding.
Each field declared in the DBD is represented by one column:
- A persisted computed column contains the field’s raw data (substring of the Data column).
RID: An identity column (integer).
HID: A varbinary is used to order the segment if it doesn’t have a unique sequence. If the segment has a unique sequence, this column is always NULL.
PID: The foreign key to the physical parent. This column only exists for child segments.
LPID: The foreign key to the logical parent. This column only exists for logical child segments.

The primary indexes are represented by the SQL Server index, while the secondary indexes are represented by tables that are updated by triggers. For more details, refer to the Triggers.

Examples:

Example 1: An SQL script which shows the creation of the table representing the CATALOG segment of the DEALER DBD.

CREATE TABLE [DEALERDB_CATALOG](
    [RID] int NOT NULL IDENTITY,
    [HID] varbinary(892) ,
    [PID] int NOT NULL,
    [Data] varbinary(220) ,
    [LPID] int NOT NULL,
    [MODTYPE] AS (SUBSTRING([Data],1,20)) PERSISTED,
    [COMMENT] AS (SUBSTRING([Data],21,200)) PERSISTED,
    CONSTRAINT [UNIQUE_DEALERDB_CATALOG_SEQ] UNIQUE ([PID],[MODTYPE]),
    CONSTRAINT [PK_DEALERDB_CATALOG_RID] PRIMARY KEY ([RID]),
        CONSTRAINT [FK_DEALERDB_CATALOG_PID] FOREIGN KEY ([PID])
        REFERENCES [DEALERDB_DEALER]([RID])
        ON DELETE CASCADE
);
CREATE INDEX [NONUNIQUE_DEALERDB_CATALOG_SEQ] ON [DEALERDB_CATALOG]([MODTYPE]);

Example 2: Two DBDs and a schema representing the created tables.

Figure 3. DBD and Schema

Views

Concatenated segments are represented as views. The view contains the same columns as the tables representing a segment, with an additional DPRID column, which is the RID of the destination parent. The Data contains the concatenated data from the two segments.

Triggers

The following triggers are defined:

<DBD name>_<segment name>_INSERT: Updates the secondary index table when data is inserted in the segment.
<DBD name>_<segment name>_UPDATE: Updates the secondary index table when data is replaced in the segment.
<DBD name>_<segment name>_DELETE: Updates the secondary index table when data is deleted from the segment
<DBD name>_<segment name>_HID_INSERT: For each segment without a unique sequence, this trigger is used to update the value of the HID column.

Functions

The database creation script includes a few functions to improve performance. The functions are listed below:

DBD level:
- <DBD name>_GN: For each DBD, this function computes the result of a GN without SSA.
Segment level:
- <DBD name>_GU_<segment name>: For each segment, this function computes the GU for the segment with the SSA containing the sequence of the segment.
- <DBD name>_ISRT_<segment name>: For each segment, this function checks if the data can be inserted and then inserts the data into the segment.
- <DBD name>_REPL_<segment name>: For each segment, this function updates the data in the segment.

Stored Procedures

A few utility stored procedures are created to restore database coherence after data loading and database evolution (for example, adding a field in a segment). The stored procedures are listed below:

DBD level:
- <DBD name>_REGENERATE_SECONDARY_INDEX: Insert data into the secondary index tables of the DBD after data loading using the <DBD name>_<segment name>_REGENERATE stored procedures.
- <DBD name>_UPDATE_LPID: Updates the logical parent foreign key of the DBD after data loading.
- <DBD name>_TRUST_FK: The bcp loader marks all the foreign keys as non-trusted. When a foreign key is marked as non-trusted, it’s not verified when data are inserted. These stored procedures mark all the foreign keys of the DBD as trusted.
Segment level:
- <DBD name>_<segment name>_REGENERATE: Insert data into the secondary index tables after data loading.
- RC_DROP_FK_<DBD name>_<segment name>: Drops all the foreign keys with the segment as a target or origin. These stored procedures are used during database evolution.
- RC_CREATE_FK_<DBD name>_<segment name>: Creates all the foreign keys with the segment as a target or origin. These stored procedures are used during database evolution.

2.3.2. Database creation

This section provide command-line options of the tool IMSql.DbGenerator, which is used to generate the SQL script to create the database.

Data

Table 1. Details of command-line options for IMSql.DbGenerator in category Data
Command-line option	Default value	Description
`ConsoleLog`	`False`	The DbContext generated displays the queries in the console
`CreateDatabase`	`True`	The generated creation script contains the "CREATE DATABASE".
`Data`	`True`	Generates outputs for the IMSql DB database.
`DbName`	`IMSql`	The name of the IMSql DB database in the output scripts.
`DebugLog`	`False`	The DbContext generated displays the queries in the debug console
`GenerateDisplayColumn`		The generated table contains computed columns representing the ASCII representation of the raw fields. This is a boolean value.
`SqlDatabase`		The sql database to upload the DBD declaration to.

Miscellaneous

Table 2. Details of command-line options for IMSql.DbGenerator in category Miscellaneous
Command-line option	Default value	Description
`DotNetConfigFile`		This command-line option is an additional .net 'app.config' file.
`Encoding`		Encoding of the DBD files
`Files`		The input dbd files for generating the database scripts.
`GenerateConcatKeyViews`		Generates, for each segment, a view with the concatenated key. This view is used in the optimized GN stored function
`Help`		Displays the tool’s help information.
`IgnoreUnkownArgs`
`Info`	`False`	Displays a description of the program.
`LogLevel`	`WARNING`	Specifies the log level. Valid values are: `SILENT` `ERROR` `WARNING` `PROGRAM_OUTPUT` `PROGRAM` `INFO` `DEBUG` `TRACE` `DIAGNOSTIC`
`OutputDir`	`./imsoutput`	The output folder.
`Version`	`False`	Displays the version information.

Online

Table 3. Details of command-line options for IMSql.DbGenerator in category Online
Command-line option	Default value	Description
`Online`	`False`	Generates outputs for the IMSql TM database.
`OnlineDbName`	`IMSql_Config`	The name of the IMSql TM configuration database in the output scripts.

Repository

Table 4. Details of command-line options for IMSql.DbGenerator in category Repository
Command-line option	Default value	Description
`RepoConnectString`		The repository connection string. See also the DBDriver option.
`RepoDriver`		Sets the connection string to use for the repository persistence system as an ODBC connection string if ODBC persistence is used or as a physical file name if SQLITE is used instead. See also the DBConnectString option. Values can be any of the following: Valid values are: `ODBC` `Sqlite`
`ScanOnly`	`False`	Parse and scan the DBD, but do not produce any code (.sql or .cs). This is useful for checking DBD syntax for compatibility.

2.3.3. View Creation

After the raw data tables are created, a view needs to be created for each table. The view presents the data in a structured, readable format based on the copybook definitions. This allows users to query the data as it is used by the application programs. To generate the SQL that creates such view, the CopybookViewGenerator tool is used.

2.3.4. Unload data from the Mainframe

To unload data from the Mainframe, DFSRRC00 must be executed with the DFSURGU0 HD Reorganization Unload utility, with a JCL step of the form:

//ULU     EXEC PGM=DFSRRC00,PARM='ULU,DFSURGU0,DI21PART'

When the data is unloaded from IMS/DB, the resulting file must be transferred from the Mainframe to the target platform as a binary file (not a text file!).

For instance, please find below a sample JCL to unload the data of the DI21PART DBD onto a file called DR01.IMS.UDI21PAR.

//DR01DI21 JOB ACTINFO1,
// 'PGMRNAME',
// CLASS=A,
// MSGCLASS=A,MSGLEVEL=(1,1),
// NOTIFY=&SYSUID,
// REGION=64M
//*
//*JOBPARM PROCLIB=PROC01
//IMS1010 JCLLIB ORDER=(IMS1010.PROCLIB)
//* SCRATCH DATA SETS
//*
//SCRATCH EXEC PGM=IDCAMS,DYNAMNBR=200
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  DELETE DR01.IMS.UDI21PAR -
         NONVSAM SCRATCH
//*
//* ALLOCATE DATA SETS
//*
//ALLOCATE EXEC PGM=IDCAMS,DYNAMNBR=200
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  ALLOCATE -
      DSNAME('DR01.IMS.UDI21PAR') -
      FILE(UNLOAD1)               -
      RECFM(V B)                  -
      DSORG(PS)                   -
      NEW CATALOG                 -
      SPACE(1) CYLINDERS         -
      VOL(RC0001)              -
      UNIT(SYSDA)
//*
//*********************************************************************
//* FUNCTION: UNLOAD DATA BASE - MIGRATE = YES
//*********************************************************************
//*
//ULU     EXEC  PGM=DFSRRC00,PARM='ULU,DFSURGU0,DI21PART'
//STEPLIB  DD DSNAME=IMS1010.SDFSRESL,DISP=SHR
//DFSRESLB DD DSNAME=IMS1010.SDFSRESL,DISP=SHR
//IMS      DD DSN=IMS1010.DBDLIB,DISP=SHR
//         DD DSN=IMS1010.PSBLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
//RECON1   DD DSNAME=IMS1010.RECON1,DISP=SHR
//RECON2   DD DSNAME=IMS1010.RECON2,DISP=SHR
//SYSUDUMP DD SYSOUT=*
//DFSURGU1 DD DSNAME=DR01.IMS.UDI21PAR,DISP=OLD
//DI21PART DD DSNAME=IMS1010.DI21PART,DISP=SHR
//DI21PARO DD DSNAME=IMS1010.DI21PARO,DISP=SHR
//DFSVSAMP DD *
VSRBF=4096,5
VSRBF=2048,5
VSRBF=512,5
IOBF=(2048,5)
//*
//SYSIN    DD *
MIGRATE=YES
/*
//DFSCTL   DD *
SBPARM ACTIV=COND
/*

IMSql’s data migration process does not support compressed IMS/DB data. If some segments of the DBD are compressed (i.e., the segment definition contains a COMPRTN parameter), then the data should be decompressed during the unload. To unload uncompressed data, the option DECOMPRESS=YES should be added to the unload JCL.

When the file (DR01.IMS.UDI21PAR in this example) is created, it should be transferred from the Mainframe using a file transfer utility such as FTP. Beware, however: this is a binary file with variable-length records, that must be transferred in binary mode with the record length given in front of each record.

ftp mainframe.mycompany.com
ftp> binary
200 Representation type is Image
ftp> literal site RDW
200 SITE command was accepted
ftp> get DR01.IMS.UDI21PAR

Command-line options of IMSql.Unload

Configuration

Table 5. Details of command-line options for IMSql.Unload in category Configuration
Command-line option	Default value	Description
`ConnectionString`		SQL Database connection string to connect.
`DbContextDir`	`RC_EXE_SEARCH_PATH environment variable`	Directory where the DbContext dll’s are
`DBDFile`		Path to the DBD file to get the segment information.
`DBDName`		Name of the DBD.
`Plan`		Plan name used to get SQL Database connection string to connect.
`UnloadFile`		Path to Serialize the content of the UNLOADED data. This argument is mandatory.

Miscellaneous

Table 6. Details of command-line options for IMSql.Unload in category Miscellaneous
Command-line option	Default value	Description
`DotNetConfigFile`		This command-line option is an additional .net 'app.config' file.
`Help`		Displays the tool’s help information.
`IgnoreUnkownArgs`
`Info`	`False`	Displays a description of the program.
`LogLevel`	`WARNING`	Specifies the log level. Valid values are: `SILENT` `ERROR` `WARNING` `PROGRAM_OUTPUT` `PROGRAM` `INFO` `DEBUG` `TRACE` `DIAGNOSTIC`
`Version`	`False`	Displays the version information.

2.3.5. Data loading and refreshing

IMSql.Load import data from a flat file into an SQL Server database created by IMSql for IMS/DB storage. The flat file’s format is compatible with the DFSRRC00/ULU, and DFSURGO0 standard utilities (for more detail, refer to the section Unload data from the Mainframe). Incidentally, this format is also used by the IMSql.Unload utility, as described below.

IMSql.Load supports two different techniques to import the data into the database:

Insert: uses plain Sql INSERT statements to insert the data into the database. This technique is used if the parameter -ConnectionString is used.
bcp: This version doesn’t explicitly load the data into the database but creates the files (data and format) that can be used by bcp to load the data into the database. IMSql.LoadSegment.ps1 is an example of a script that loads the data using bcp. This technique is used if the parameter -BcpOutputFolder is used.

The IMSql.LoadSegment.ps1 can be found in %RCDIR%\IMSql, for more details, refer to the Raincode Crossbow.

The insert technique is the easiest to use because it directly inserts the data into the database. However, it is much slower (20 times) than the bcp technique, which should thus be preferred for importing large volumes of data.

Load with insert

IMSql.Load -DbdFile=path_to_dbd_file -UnloadFile=path_to_data_file -ConnectionString="connection_string"

Where

path_to_dbd_file: the path to the DBD
path_to_data_file: the flat file extracted from the Mainframe or produced by IMSql.Unload that needs to be loaded
connection_string: the connection string to the database

Load with `bcp`

In bcp mode, IMSql.Load does not directly load the data but prepares it to be loaded by the high performance SQL Server bcp command, specially designed for bulk data insertion into SQL Server. The input file is split into one file per table (or segment). For each table (or segment), a format file (.fmt) is also created, that specifies the format argument used by the bcp command to import the data.

In bcp mode, IMSql.Load also produces a file named IMSqlLoad_seg.csv that lists all the tables (segments) in which data should be loaded.

When the data has been processed, and all the output files are created, they must be loaded into the target SQL Server database using bcp. After the raw data has been loaded successfully, the foreign keys representing logical links must be updated, and the secondary indexes must be rebuilt.

In order to achieve this, two stored procedures must be executed, namely <DBD_name>_UPDATE_LPID and <DBD_name>_REGENERATE_SECONDARY_INDEX.

IMSql.Load -DbdFile=path_to_dbd_file -UnloadFile=path_to_data_file -BcpOutputFolder=path_to_outputdir

Where

path_to_dbd_file: the path to the DBD
path_to_data_file: the data file to be imported into the SQL Server database
path_to_outputdir: the output directory, where all the intermediate files to be processed by bcp must be stored

When bcp is invoked, in addition to connection parameters, specific parameters must be provided:

-E: Specifies that identity value or values in the imported data file are to be used for the identity column (RID column).
-h "CHECK_CONSTRAINTS": Specifies that all constraints on the target table or view must be checked during the bulk-import operation. Without the CHECK_CONSTRAINTS hint, any CHECK and FOREIGN KEY constraints are ignored, and after the operation, the constraint on the table is marked as not-trusted.

To check that all the foreign keys are trusted, execute the following query:

SELECT
FK.name [constraint_name]
,T.name [referencing_table_name]
,TabC.name [referencing_column_name]
,RefT.name [referenced_table_name]
,RefC.name [referenced_column_name]
,FK.delete_referential_action_desc delete_referential_action_desc
,FK.update_referential_action_desc update_referential_action_desc
,FK.is_disabled
,FK.is_not_trusted,
concat('ALTER TABLE ', t.name, '  WITH CHECK check  CONSTRAINT ' , fk.name) [query_to_trust]
FROM   sys.foreign_keys AS FK
   INNER JOIN sys.foreign_key_columns FKC
     ON FK.object_id = FKC.constraint_object_id
   INNER JOIN sys.tables AS T
     ON T.object_id = FK.parent_object_id
   INNER JOIN sys.columns AS TabC
     ON TabC.column_id = FKC.parent_column_id
     AND TabC.object_id = FKC.parent_object_id
   INNER JOIN sys.tables AS RefT
     ON RefT.object_id = FK.referenced_object_id
   INNER JOIN sys.columns AS RefC
     ON RefC.column_id = FKC.referenced_column_id
     AND RefC.object_id = FKC.referenced_object_id

The column is_not_trusted should be equal to 0. If not, you should execute the query given in the column [query_to_trust] to mark the Foreign Key (FK) as trusted. For each DBD, there is a stored procedure (<DBD name>_TRUST_FK) that tries to mark all the FK’s of the DBD as trusted.

When the data is loaded using bcp, the foreign keys representing the logical parent links are not correctly set, and the secondary indexes are not updated because the triggers are not activated when executing bcp. For each DBD, there are thus two stored procedures (generated automatically by IMSql) to update them:

<DBD name>_UPDATE_LPID: update the logical parent FK of the DBD
<DBD name>_REGENERATE_SECONDARY_INDEX: regenerate the secondary index of the DBD

A sample script ($env:RCDIR\scripts\IMSql\IMSql.LoadSegments.ps1) is provided. This script performs the following actions: it calls IMSql.Load for each DBD, bcp for each table and finally, for each DBD, executes the stored procedures to update the logical links, foreign keys, and secondary indexes. Before using this script, you should personalize it by changing the value of some variables:

$srcDir: the root directory of DBD and data files
$wrkDir: directory where temporary files will be stored
$bcpOptions: options used by bcp (connection and database name)
$sqlcmd: options used by sqlcmd (connection and database name)
$todo: list of DBDs to be loaded in a CSV format: <name of the DBD>,<DBD path relatif to $srcDir>,<data file relatif to $srcDir>

Command-line options of `IMSql.Load`

Configuration

Table 7. Details of command-line options for IMSql.Load in category Configuration
Command-line option	Default value	Description
`BcpOutputFolder`		Path to place the files for bcp
`ConnectionString`		SQL Database connection string to connect.
`DbContextDir`	`RC_EXE_SEARCH_PATH environment variable`	Directory where the DbContext dll’s are
`DBDFile`		Path to the IMS DBD file
`DBDName`		Name of the DBD.
`NonXmlFormatFile`	`False`	Generate format file in non-xml format
`UnloadFile`		Path to Serialize the content of the UNLOADED data This argument is mandatory.

Miscellaneous

Table 8. Details of command-line options for IMSql.Load in category Miscellaneous
Command-line option	Default value	Description
`DotNetConfigFile`		This command-line option is an additional .net 'app.config' file.
`Help`		Displays the tool’s help information.
`IgnoreUnkownArgs`
`Info`	`False`	Displays a description of the program.
`LogLevel`	`WARNING`	Specifies the log level. Valid values are: `SILENT` `ERROR` `WARNING` `PROGRAM_OUTPUT` `PROGRAM` `INFO` `DEBUG` `TRACE` `DIAGNOSTIC`
`Version`	`False`	Displays the version information.

3. zBridge/File

3.1. Introduction

zBridge can export files to a relational database, with current support for SQL Server and PostgreSQL.

To export file data into a database, the process consists of two main parts:

Database Creation: Set up tables and views to store the file data. This step is only done once for each file.
Data Transfer: Periodically transfer the data from the mainframe file into the database to ensure it remains up to date.

Files on the mainframe, such as VSAM files, store basic metadata like record format (fixed or variable), record length, and key positions. The detailed structure of the records is typically defined in application programs using copybooks. These copybooks ensure all programs interacting with the file use the same record structure.

zBridge supports two export workflows:

Binary (views): The table stores data in a binary format within a single column. Views are then created to present this data in a more human-readable form.
Copybook (tables): The table stores already translated data, with one column for each field defined in the copybook. In this case, views are not needed.

3.2. zBridge/file - Binary Workflow

The database creation process starts with creating a table for each file to store the raw data. Each record in the file is stored in a single column in binary format. Then, a view is created to represent the data in a readable format based on the copybook.

Figure 4. zBridge/file process (Binary)

The process of setting up zBridge/File for binary is illustrated in the above figure. Each step is explained in detail below.

3.2.1. Database Structure

1. Extract File Metadata: Information such as file name, format, record length, and key positions is extracted from the mainframe catalog and encoded into a catalog configuration file (Raincode.Catalog.xml).

2. Generate SQL Script for Table Creation: Using the Raincode.Catalog.xml, VSAMSql.DbGenerator tool generates the SQL script (Create.sql) to create the necessary tables.

3. Extract Copybooks: The COBOL copybooks are compiled using cobrc, and the structure definitions (Descriptor.xml) are extracted from the mainframe.

4. Generate View Creation Script: The CopybookViewGenerator tool uses copybooks to generate SQL scripts for creating views that map the data into a readable format.

3.2.2. Transferring data to the database

5. Transform Data: VSAMSql.Load transforms the file received from the mainframe into data and format files that can be read by a utility for loading into the database. Currently, we support two databases: SQL Server and PostgreSQL. For SQL Server, data is loaded using bcp, and for PostgreSQL, the COPY command is used.

6. Load Data: The data is loaded into the database using the load utility.

3.2.3. Pros/Cons

Pros:

Broad data structure support: Can work with both tables and views for flexible data.
High performance loading: Binary format makes data transfer and processing much faster.
Operational simplicity: Easy to set up and maintain with fewer steps than a copybook.

Cons:

Limited flexibility for rehosting: Binary format ties the data to the mainframe, making it hard to move to distributed or cloud platforms.
Storage overhead: Binary files may take up more space, increasing storage costs and capacity concerns.
View performance: The data is translated every time the view is accessed.

3.3. zBridge/file - Copybook Workflow

During database creation, a table is generated for each file to hold its data. Each table includes one column for every variable defined in the copybook. When loading data, the columns are populated with values converted from the mainframe format into the SQL native format. With this method, views were not required.

Figure 5. zBridge/file process (Copybook)

The process of setting up zBridge/File is illustrated in the above figure. Each step is explained in detail below.

3.3.1. Database Structure

2. Extract Copybooks: The COBOL copybooks are compiled using cobrc, and the structure definitions (Descriptor.xml) are extracted from the mainframe.

3. Generate SQL Script for Table Creation: Using the Raincode.Catalog.xml and the structure definitions Descriptor.xml), VSAMSql.DbGenerator tool generates the SQL script (Create.sql) to create the necessary tables.

3.3.2. Transferring data to the database

4. Transform Data: The VSAMSql.Load utility processes mainframe files and generates corresponding data and format files compatible with the database load utility. Currently, we support two databases: SQL Server and PostgreSQL. For SQL Server, data is loaded using bcp, and for PostgreSQL, the COPY command is used.

5. Load Data: The data is directly loaded into the database using the load utility.

3.3.3. Pros/Cons

Pros:

Rehosting compatibility enables seamless migration by translating data via COBOL copybooks for easier application and dataset modernization.

Cons:

Performance trade-off occurs as copybook-based parsing adds overhead, reducing throughput and increasing latency versus direct binary processing.
Could not be used for applications rehosting.

3.4. zBridge/file details

3.4.1. Table Creation

A table is created for each file. The VsamSql.DbGenerator uses the DataMapping section of the Raincode.Catalog.xml configuration file to determine which tables need to be created. For each file, an entry must be added to the catalog configuration file.

The table VSAM_META contains meta-information about the files stored in the database:

ID: an SQL Server identity column
FILE_NAME: the name of the file
TABLE_NAME: the name of the table in which the data of this file are stored
PARTITION: the partition number (see Partitions)

A table can store data from multiple files, provided that all the files have the same structure, including the same record length, keys, and record structure. Each data table contains the following columns:

RID: an SQL Server identity column
FILE: the foreign key to the VSAM_META.ID column
PARTITION: the partition number (see Partitions)
Data: the actual data as a binary array (VARBINARY)
KEY: this column is only present for the VSAM file. It contains the key of the record. It is a computed-persistent column that is a substring of the Data column.
KEY_[1…n]: there is one column for each alternate key of the VSAM file. It is a computed-persistent column that is a substring of the Data column.

If the catalog is stored in the database, two additional tables are created: CATALOG_META and CATALOG_LOCK.

CATALOG_META contains information about the catalog. There is one line representing each file.

CATALOG_LOCK is used to manage the locking of the files.

3.4.2. Partitions

When a file needs to be deleted, all its records must be deleted from the table. Deleting many rows (records) from a table with a DELETE statement is inefficient because lines are deleted individually. If the table contains only one file, the statement TRUNCATE can be used more efficiently.

If the table is partitioned, TRUNCATE can be used to delete all the data of one partition. So, if a table contains more than one file, one partition can be used for each file. Similarly, when a file needs to be deleted, TRUNCATE can be used to delete all the data of the corresponding partition.

During the generation of the creation script, the partitions element of the catalog configuration is used to know which partition need to be created. If a file isn’t associated with a partition, its data will be stored in the default partition (partition 0).

3.4.3. Stored procedures

One stored procedure is associated with each data table: DELETE_<table name>. This stored procedure is used to delete all the data of a file. It decides if DELETE or TRUNCATE should be used, depending on how many files are stored in the partition.

Some stored procedures are used to manage the catalog: WRITE_CATALOG, KEEPLOCK_CATALOG, LOCK_CATALOG, UNLOCK_CATALOG.

3.4.4. Database creation

The creation script of the database is generated by VsamSql.DbGenerator. This program reads the catalog configuration file, whose path is given as an argument, and generates a SQL file that contains the tables creation SQL script. This SQL script then needs to be executed on the database server.

VsamSql.DbGenerator can take a connection string to the database as an argument (-SqlDatabase), then it generates only the missing tables and updates the partition function.

An example table script generation is as follows:

VsamSql.DbGenerator.exe -CatalogConfiguration="C:\ProgramData\Raincode\Batch\Raincode.Catalog.xml" -OutputFile="output.sql"

For more details on VsamSql.DbGenerator arguments refer to command line options.

3.4.5. View Creation

3.4.6. Using VSAMSql.load

Data must be loaded into the tables while creating the catalog and database objects (such as tables, indexes, and views).

There are two ways to load data:

Using JCL: Copy the data from a disk file into VSAMSql.
Using the SQL Server bcp utility:bcp requires a more complex setup and is more efficient for handling large volumes of data.

Loading data using a JCL

Loading data using a JCL is the same as migrating a dataset, as described in Dataset Migration, because JCL sees the VSAMSql file as a dataset.

Loading data using bcp

The VsamSql.load utility does not directly load the data. Instead, it prepares the data to be loaded by the high-performance SQL Server bcp utility, specially designed for bulk data insertion into the SQL Server. This process involves transforming the input file into a format compatible with bcp. It generates a format file (.fmt) that specifies the format argument used by the bcp to import the data.

Once the data has been processed and all the output files are created, they must be loaded into the target SQL Server database using bcp.

For the demonstration on how to load the data using VsamSql.load and bcp refer to an example script, VsamSql.LoadData.ps1 located at "%RCDIR%\scripts\VsamSql".

You can also refer to the VsamSql.Load Command Line Options for details on how to use this tool.

3.4.7. Refreshing the data

Once the database is created, file data should be periodically refreshed to keep the database in sync with the mainframe. The SQL Server bcp (Bulk Copy Program) utility is the most efficient way to import data into the SQL Server.

bcp requires:

Table name
Format file: An XML file that describes how the data should be mapped into the table.
Data file: The file containing the actual data to be imported.

VSAMSql.Load takes care of producing the format file and the data file.

For PostgreSQL, the psql copy command can be used to quickly and efficiently import large amounts of data from files directly into a table.

4. Querying the database

Once the data is loaded into SQL Server, the views created from the copybooks are used to query the database. These views provide a readable format of the file data, allowing you to easily access and manipulate the information.

Figure 6. Querying the database

The User can review the details of the SQL data views and their related data source through the Raincode Console. For more information, refer to the Raincode Console documentation.

5. CopybookViewGenerator

Raincode offers two products that map non-relational mainframe data into SQL Server relational databases:

IMSql is a comprehensive IMS emulator, that stores IMS/DB data into relational tables
VSAMSql allows sequential and indexed file’s data to be stored into tables as well. It allows for multiple isomorphic files (record structure and indexing) to be stored in a single table.

In both cases, the ambition is the same, namely to preserve the existing program’s behavior without requiring any change to the source code. Both for IMSql and VSAMSql, each (IMS/DB or VSAM) record is materialized as a relational row, where a column appropriately named Data contains a bitwise copy of the entire original mainframe record, without conversion, cleansing or normalization of any kind.

This allows unmodified mainframe application programs written in PL/I, COBOL and Assembler to read and write these records without having to even be aware of the fact that they no longer come from IMS/DB, sequential or VSAM files.

The ability to migrate data to a relational database is valuable in its own right. One can rely on all the facilities they offer in terms of performance, security, fault-tolerance, replication, etc. On the other hand, if things were to stop there, the data stored in this fashion would be useless except for the legacy applications: one cannot write a SQL statement to read (and even less write) data into these tables, as the record is represented by a raw byte array without further structure.

What the CopybookViewGenerator utility does is all in the name: it takes a COBOL copybook (or PL/I include) that contains a data structure definition, and generates a matching SQL Server view on top of the table that allows you to read and write data from and into the binary record, using the field names and data types as specified in the data structure.

This generated views cares for all underlying technicalities, including conversion to and from EBCDIC (if applicable) and support for the mainframe-specific numeric types, in such a way that the legacy data can be used as any standard SQL table, using standard SQL data types, for ad hoc queries and updates or even brand new applications.

The following figure illustrates the process:

Figure 7. View creation

In more technical terms, the CopybookViewGenerator utility generates a SQL script that can be executed to create a view containing one column for each atomic (non-composite) field defined in the data structure. Optionally, the view can also contain all the columns of the original table.

The generated SQL script also contains the definition for triggers that will be activated automatically when updating, inserting or deleting data on the view. These triggers map the SQL operation at hand onto the underlying binary representation so that any operation on a column of the view is ultimately performed on the underlying binary representation.

Before such a generated SQL script can be executed for the creation of the view and its triggers, one must first create ancillary functions by running the scripts Functions.sql and EbcdicFuncs.sql that can be found at the %RCBIN%\sql location.

For example, given the ORDERS IMS segment declared as follows in a DBD:

SEGM  NAME=ORDERS,BYTES=240,PARENT=CATALOG
      FIELD NAME=(ORDNBR,SEQ,U),BYTES=20,START=21,TYPE=C
      FIELD NAME=DETAILS,BYTES=200,START=41,TYPE=C

and a copybook refining the structure of ORDERS as such:

01 CPY-ORDERS.
      05 CPY-PRE                  PIC X(20).
      05 CPY-ORDNBR               PIC X(20).
      05 CPY-DETAILS.
         10 CPY-DESCR             PIC X(176).
         10 CPY-DATE-9            PIC 9(8).
         10 CPY-TOTAL             PIC 9(5)V9(2) COMP-3.
         10 CPY-VAT               PIC 9(7)V9(2) COMP.
         10 FILLER                PIC X(8).

the CopybookViewGenerator utility produces a SQL view of the form:

Create or alter View [dbo].[DEALERDB_ORDERS_V]
as select
-- the columns of the original table
  [DEALERDB_ORDERS].[RID]
  ,[DEALERDB_ORDERS].[HID]
  ,[DEALERDB_ORDERS].[PID]
  ,[DEALERDB_ORDERS].[Data]
  ,[DEALERDB_ORDERS].[SEGDATA1]
  ,[DEALERDB_ORDERS].[ORDNBR]
  ,[DEALERDB_ORDERS].[DETAILS]
-- the columns representing the copybook variables
  , ... as [CPY_PRE]
  , ... as [CPY_ORDNBR]
  , ... as [CPY_DESCR]
  , ... as [CPY_DATE_9]
  , ... as [CPY_TOTAL]
  , ... as [CPY_VAT]
  , ... as [FILLER_1]
  from [dbo].[DEALERDB_ORDERS];

The actual expressions used for the columns of the view are ignored in the example above, for the sake of brevity. They are complex and convoluted, and the whole point of the CopybookViewGenerator utility is to generate them for you so you don’t have to write them yourself.

The example above shows that:

By default, the generated view is named after the IMS segment name with a _V postfix
The generated view contains all the colums from the ORDER table (this behavior can be changed by using the appropriate command-line option)
The names of the columns is derived directly from the field names as specified in the original copybook
The aggregate field names (CPY_DETAILS in the example above) are ignored and not materialized in the generated view.

The generated triggers allow you to write SQL statements such as

UPDATE DEALERDB_ORDERS_V SET CPY_PRE = 'TZ123' WHERE RID=10082

and

SELECT CPY_PRE FROM DEALERDB_ORDERS_V WHERE RID=10082

which will then display:

TZ123

demonstrating how the DEALERDB_ORDERS_V view behaves just like a table, and CPY_PRE behaves like an updatable column even though it is not materialized in the database.

While this example is based on an IMS/DB segment, the very same capability is available for VSAMSql, since the only mandatory component is the availability of a binary column named Data.

5.1. View generation

In practice, these views are generated in two steps:

Extraction of one or more COBOL or PL/I declarations from copybooks or entire programs, and production of a synthetic XML representation of these data structures
Based on this synthetic XML representation, generation of script containing the creation of the view and triggers.

In extreme cases, it may even be conceivable to create this XML representation manually, for instance, if the data structure is not defined in COBOL or PL/I but in Assembler. Alternatively, one can also just encode a COBOL copybook for the sole purpose of documenting the structure of the generated view.

5.1.1. COBOL copybook to XML

The Raincode COBOL compiler (cobrc) can be used to parse a copybook with one or more root variables, and produce the corresponding XML representation.

The compiler is invoked with the :DeclDescriptors command-line option to indicate the path to the XML output file. The second option (cust_rec.cpy in the example below) is the name of the source file for the copybook.

cobrc :DeclDescriptors=cust_rec.xml cust_rec.cpy

The XML file contains the description of all the fields defined in the copybook.

The step of parsing the copybook and transforming it into the corresponding XML representation is performed automatically by the CopybookViewGenerator utility when it is used with the -cpy command-line option.

5.1.2. COBOL or PL/I program to XML

Alternatively, the structures can be extracted from a complete (and valid) COBOL or PL/I program directly.

The Raincode COBOL compiler (cobrc) and the Raincode PL/I compiler (plirc) can be used to parse complete and valid source files and generate an XML file that describes all the variables they contain. To achieve this, the compiler must be invoked with the :DeclDescriptors command-line option, to indicate the path to the XML output file with the specification of the variables:

cobrc :DeclDescriptors=rep.xml REP0081.cbl
plirc :DeclDescriptors=inv.xml INVSY01.pli

Unlike Raincode’s COBOL compiler that can process copybooks that contain one or more well-formed data structures, the PL/I compiler can only parse entire PL/I programs. One way around this limitation can be to create a dummy PL/I program for the sole purpose of including an include file that contains a variable declaration:

dummy: proc options(main);
    %include myinclude;
end dummy;

5.1.3. XML to SQL

The CopybookViewGenerator utility can then read the XML file produced in the previous step and generate the SQL script to create the SQL view and the matching triggers. If the XML file contains more than one variable declaration, the :struct command-line option can be used to specify the name of the variable to use as a model for the view generation.

CopybookViewGenerator :xml=custll.xml :struct="cust-addr" :table="caddr" :output=caddr.sql

By default, the generated view also contains all the columns of the original table. By using the :OnlyTech command-line option, one can ensure that only the truly indispensable technical columns of the original table are made available in the generated view.

5.1.4. Annotations

COBOL and PL/I source code can be annotated with meta comments; see Meta Comments to mark some variables with information used by the copybook generator.

IGNORE

A field annotated with IGNORE will not be mapped to a column, nor will its sub-fields if any.

Annotations

Resulting view in SQL

01 CPY-ORDERS.
 10 CPY-NUM.
  15 CPY-TOTAL PIC 9(5)V9(2) COMP-3.
  15 CPY-VAT   PIC 9(7)V9(2) COMP.
*RC:IGNORE
  10 CPY-STR REDEFINES CPY-NUM
         PIC X(8).

Create or alter View [dealerdb_orders_V]
as select
[dealerdb_orders].*
, cast
(dbo.RC_COMP3_TO_NUM(substring([data],1,4),2) as NUMERIC(8,2)) as [CPY_TOTAL]
, cast
(dbo.RC_COMP_TO_NUM(substring([data],5,4),2) as NUMERIC(10,2)) as [CPY_VAT]
from [dealerdb_orders];

AGGREGATE

A composite field annotated with AGGREGATE and which only contains sub-fields with types PIC X or PIC 9 will be mapped onto a single column in the generated view. An array (OCCURS) can also be aggregated in this way.

Annotations

Resulting view in SQL

01 CPY-ORDERS.
*RC:AGGREGATE
   10 CPY-AGG.
     15 CPY-ELT1 PIC X(9).
     15 CPY-ELT2 PIC 9(9).
*RC:AGGREGATE
   10 MY-ARRAY OCCURS 5.
     15 MY-ARRAY OCCURS 10.
       20 ELT PIC X(2).

Create or alter View [dealerdb_orders_V]
as select
[dealerdb_orders].*
, cast
(dbo.RC_EBCDIC_TO_ASCII(substring([data],1,18)) as VARCHAR(18)) as [CPY_AGG]
, cast
(dbo.RC_EBCDIC_TO_ASCII(substring([data],19,100)) as VARCHAR(100)) as [MY_ARRAY]
from [dealerdb_orders];

RENAME

An annotation to a variable of the form RENAME:NEW_NAME will cause the column name in the generated view to be renamed accordingly.

Annotations

Resulting view in SQL

01 CPY-ORDERS.
*RC:RENAME:DATE-NUM
   10 CPY-DATE-9 PIC 9(8).
   10 CPY-DATE-X
       REDEFINES CPY-DATE-9
                 PIC X(8).

Create or alter View [dealerdb_orders_V] as select
[dealerdb_orders].*
, cast
(dbo.RC_DISPLAY_UNSIGNED_TO_BIGINT(substring([data],1,8)) as INT) as [DATE_NUM]
, cast (dbo.RC_EBCDIC_TO_ASCII(substring([data],1,8)) as VARCHAR(8)) as [CPY_DATE_X]
from [dealerdb_orders];

5.2. Redefines

When mapping legacy data structures, the question of how to deal with redefinitions must be addressed. Legacy languages allow for the definition of overlapping definitions, as in:

01 CUST-REC.
  10 CUST-DETAILED-NAME.
    15 CUST-FIRST-NAME PIC X(20).
    15 CUST-LAST-NAME PIC X(20).
  10 CUST-FULL-NAME
    REDEFINES CUST-DETAILED-NAME PIC X(40).

where the customer name can either be read and written using the first and last name as separate fields or used as an aggregate (in effect, the padded concatenation of the first and last name) as CUST-FULL-NAME.

The view generated by the CopybookViewGenerator utility will contain three columns named CUST_FIRST_NAME, CUST_LAST_NAME and CUST-FULL-NAME. Reading these columns will mimic the behaviour of COBOL or PL/I when facing redefinitions by returning either the detailed sub-field or the concatenated full name.

5.2.1. Updating overlapping fields

Things get a bit trickier when one tries to write or update value onto these columns.

As long as there are no overlapping columns in a single SQL statement, the generated view behaves as expected. The two following statements will have the same effect on the database:

UPDATE CUST SET CUST_FIRST_NAME='John',
                CUST_LAST_NAME='Doe'
                WHERE RCID=779

and

UPDATE CUST SET
            CUST_FULL_NAME='John                Doe'
            WHERE RCID=779

Please note that in the second example, the first name must be padded to 20 characters to ensure that the last name is put at the appropriate location as defined in the COBOL copybook.

On the other hand, when one updates overlapping columns in a single SQL statement, as in:

UPDATE CUST SET
            CUST_FULL_NAME='John                Doe',
            CUST_FIRST_NAME='Daniel'
            WHERE RCID=779

the assignments will be performed in the order in which the fields are defined in the original data structure. In this case, the trigger attached to the view will first assign the CUST_FIRST_NAME column before assigning the CUST_FULL_NAME column, in effect overwriting the value 'Daniel' with 'Joe'.

In other words, the order in which the updates are performed does not depend on the order in which they are specified in the SQL statement. The behavior would have been the same if the example above had been expressed as:

UPDATE CUST SET
            CUST_FIRST_NAME='Daniel',
            CUST_FULL_NAME='John                Doe'
            WHERE RCID=779

where the two update clauses are swapped.

5.3. Command-line options

The CopybookViewGenerator utility supports the following command-line options:

FunctionGeneration

Table 9. Details of command-line options for CopybookViewGenerator in category FunctionGeneration
Command-line option	Default value	Description
`EbcdicEncoding`	`IBM01047`	The EBCDIC encoding used for the EBCDIC to and from ASCII conversion function.

GenerateViews

Table 10. Details of command-line options for CopybookViewGenerator in category GenerateViews
Command-line option	Default value	Description
`compileroptions`		Additional options to pass to the compiler when generating the XML form of the copy book.
`ConfigConnectionString`		The IMSql config database to upload the copybook to.
`conn`		Specify the connection string for the data source to query the table structure.
`cpy`		Specify the copybook to use when creating the view. An XML form is generated by the Raincode COBOL compiler then used as if it were provided though the -xml option.
`db`		Specify the database name to be referred to explicitly in generated SQL source files.
`DbdName`		The Dbd Name used to upload the copybook to config database,if not provided then it will be derived from the 'table' commandline option.
`debugmode`		Generate additional debugging information.
`EbcdicFuncs`		Instead of generating the view and trigger(s), generate the EBCDIC to and from ASCII conversion function.
`OnlyTech`	`False`	The view contains only the technical columns (RID, PID, LPID, HID) of the table and not all the columns of the table
`output`		Specify the file in which sql must be generated.
`rawcolumns`		Matching raw slices of the record in the form of unconverted binary values (default is false).
`readonly`		When set, generate only the read-only view, not the triggers that allow this views to be used as a read/write table (default is false).
`schema`		Specify the schema name to be referred to explicitly in generated SQL source files.
`schemabinding`		When set, ensures that all generated artefact are bound to the schema for better performance and to allow for the generated views to be indexed(default is false).
`SegmentName`		The Segment Name used to upload the copybook to config database,if not provided then it will be derived from the 'table' commandline option.
`struct`		Specify the name of the structure to use when generating the view.If no such structure is specified, the first structure in the copy books is used.
`table`		Specify the table for which the view must be generated.
`testdb`		NOT DOCUMENTED (TODO)
`type`	`sql`	Specify the output type. The only supported type is -type=sql for SQL Server. Default is sql.
`ViewName`		Name of the view. By defaul, the name of the view is the name of the table with the suffix "_V"
`WithoutTimestamp`	`False`	Suppress the timestamp generated at the begining of the file
`xml`		Specify the XML form of the copybook to use when creating the view,as generated by the Raincode COBOL and PL/I compilers.

GenerateView

Table 11. Details of command-line options for CopybookViewGenerator in category GenerateView
Command-line option	Default value	Description
`VariableLengthRecord`	`False`	Generates view for variable length record

Miscellaneous

Table 12. Details of command-line options for CopybookViewGenerator in category Miscellaneous
Command-line option	Default value	Description
`DotNetConfigFile`		This command-line option is an additional .net 'app.config' file.
`Help`		Displays the tool’s help information.
`IgnoreUnkownArgs`
`Info`	`False`	Displays a description of the program.
`LogLevel`	`TRACE`	Specifies the log level. Valid values are: `SILENT` `ERROR` `WARNING` `PROGRAM_OUTPUT` `PROGRAM` `INFO` `DEBUG` `TRACE` `DIAGNOSTIC`
`Version`	`False`	Displays the version information.

Plugin

Table 13. Details of command-line options for CopybookViewGenerator in category Plugin
Command-line option	Description
`Plugin`	The list of plugins to be loaded when the tool executes.
`PluginPath`	This command-line option specifies the path to plugins that are searched.

Raincode zBridge

Raincode Crossbow

Version 6.0

1. Introduction

1.1. How zBridge provides for mainframe data management

1.2. Accessing data with zBridge

2. zBridge/IMS

2.1. Introduction

2.2. zBridge/IMS Workflow

2.2.1. Database structure creation

2.2.2. Transferring IMS data to the database

2.3. zBridge/IMS details

2.3.1. Database model (IMS/DB)

DB model

Table

Views

Triggers

Functions

Stored Procedures

2.3.2. Database creation

Data

Miscellaneous

Online

Repository

2.3.3. View Creation

2.3.4. Unload data from the Mainframe

Command-line options of IMSql.Unload

Configuration

Miscellaneous

2.3.5. Data loading and refreshing

Load with insert

Load with bcp

Command-line options of IMSql.Load

Configuration

Miscellaneous

3. zBridge/File

3.1. Introduction

3.2. zBridge/file - Binary Workflow

3.2.1. Database Structure

3.2.2. Transferring data to the database

3.2.3. Pros/Cons

3.3. zBridge/file - Copybook Workflow

3.3.1. Database Structure

3.3.2. Transferring data to the database

3.3.3. Pros/Cons

3.4. zBridge/file details

3.4.1. Table Creation

3.4.2. Partitions

3.4.3. Stored procedures

3.4.4. Database creation

3.4.5. View Creation

3.4.6. Using VSAMSql.load

Loading data using a JCL

Loading data using bcp

3.4.7. Refreshing the data

4. Querying the database

5. CopybookViewGenerator

5.1. View generation

5.1.1. COBOL copybook to XML

5.1.2. COBOL or PL/I program to XML

5.1.3. XML to SQL

5.1.4. Annotations

IGNORE

AGGREGATE

RENAME

5.2. Redefines

5.2.1. Updating overlapping fields

5.3. Command-line options

FunctionGeneration

GenerateViews

GenerateView

Miscellaneous

Plugin

Load with `bcp`

Command-line options of `IMSql.Load`