Raincode IMSql
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 to IMSql
Raincode IMSql enables the rehosting of IMS/DB (IMS Database Manager) and IMS/TM (IMS Transaction Manager) systems on .NET and SQL Server. Mainframe applications compiled for .NET can interact with IMSql in the same manner as they would interact with IMS®.
IMSql is non-transformational, which means it keeps the sources (COBOL, PL/I) as-is with the IMS® specific CBLTDLI, PLITDLI, CEETDLI, and EXEC DLI calls unaltered. This prevents the introduction of new sources, which plays a crucial role in program maintainability.
IMSql leverages SQL Server as a database, transaction processor, and execution platform.
IMSql operates in three modes:
-
Online
-
Batch
-
Load and Unload
1.2. IMS support
COBOL or PL/I programs use an interface to communicate with the database provided by CBLTDLI (COBOL to DLI), PLITDLI (PL/I to DLI), CEETDLI, and EXEC DLI.
CBLTDLI, PLITDLI, CEETDLI, and EXEC DLI also act as routers for database and transaction-related queries.
The database server hosts the data, while the database controller server holds transactions and online messages. These servers are synchronized.
CBLTDLI and PLITDLI identify the query type using the Program Communication Block (PCB) and route the traffic based on it. All data-related queries are sent directly to the database server, while transaction-related queries are routed to the Queue Management Service.
The Queue Management Service enqueues all requests coming for the transaction. It accepts and enqueues requests from CBLTDLI/PLITDLI.
2. IMS/DB
On Mainframes, DBDs (Database Description) and PSBs (Program Specification Block) are compiled to create the database and the program’s description.
On IMSql, DBDs will be used to generate an SQL script that creates the corresponding database on SQL Server and the Entity Framework DbContext. The DbContext will be used to write and execute queries.
PSBs are converted to XML files used by IMS® aware programs to determine which database segments pertain to them.
The IMSql engine (IMSql.Common.dll) is dynamically loaded if needed.
| Figure 2 shows a high-level overview of the IMS/DB architecture. |
| In Figure 2, blue arrows indicate compilation or transformation, whereas grey arrows indicate execution. |
2.1. 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.
2.1.1. 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.
2.1.2. Views
Logical and 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.
2.1.3. 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.
2.1.4. 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.
-
2.1.5. 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.2. Compile an IMS/DB program
The program itself needs to be compiled using the COBOL or PL/I compiler. Moreover, the database needs to be created, the DbContext
has to be compiled, and the PSB must be translated.
2.2.1. DB and Dbcontext creation
A database creation script and DbContext classes are generated by IMSql.DbGenerator command using the DBD:
IMSql.DbGenerator :DbName=<dbName> :Files=<DBD dir or file> :OutputDir=<outputDir>where,
<dbName>: the name of the database in which the tables, views, triggers and stored procedures will be created
<DBD dir or file>: the path of the DBDs to be translated. It
can be a file or a directory. If it is a directory, all the .DBD files will be translated.
<outputDir>: The directory containing all the generated files, including:
-
the database creation script (named
<dbName>.sql); -
one
.csfile per DBD. This is theDbContextfor the DBD; -
one
.csprojfile per DBD (this is the project to compile theDbContext; it produces a .NET Standard assembly named<DBD>.dll).
To create the database, execute the SQL script.
To compile the DbContext, we use the .NET SDK dotnet command:
dotnet build <DBD>.csproj -o=<dll directory>The generated DLL must be placed in a directory that is included in the rclrun search path (see the rclrun AddAssemblySearchDir option).
2.2.2. PSB translation
Each IMS/DB program requires a PSB. The PSB needs to be translated into an XML file:
IMSql.Psb -OutputDirectory=<outputDir> <psb file>where,
<psb file>: a PSB file
<outputDir>: the output directory where the XML file will be written.
The translated PSB must be in a directory that is included in the rclrun seach path (see the rclrun AddAssemblySearchDir option).
2.3. Run an IMS/DB program
2.3.1. Batch program
An IMS/DB batch program is executed through a JCL using the DFSRRCOO utility:
//G1 EXEC PGM=DFSRRC00,REGION=512K,
// PARM='DBB,DLRSTAT,DLRSTAT,,,,,,,,,,,,,,,,,,DFSRRCOO takes 21 parameters as mentioned below:
1. Program type: Accepted Value: BMP, DLI, DBB
2. Program name to be executed
3. PSB name
4. In Area: Not supported
5. Out Area: Not supported
6. Option (sub-parameters are OPT SPIE TEST DIRCA): Not supported
7. PRLD: Not supported
8. STIMER: Not supported
9. CheckPointID: for Restart
10. PARDLI: Not supported
11. CPUTIME: Not supported
12. NBA: Not supported
13. OBA: Not supported
14. IMSID: The name of the plan used to connect to the database. For more details, refer to Map PLAN Name to Actual Connection String.
15. AGN: Not supported
16. SSM: Not supported
17. PREINIT: Not supported
18. ALTID: Not supported
19. APARM: Not supported
20. LOCKMAX: Not supported
21. DEBUG: Parameter added by Raincode for debugging. For more details, refer to the Debugging section
Typically, a batch program is invoked using a PROC. For example, IMSBATCH
// EXEC PROC=IMSBATCH,MBR=<prg name>,PSB=<psb name>,IMSID=<plan name>,where,
<prg name>: the name of the program (COBOL or PL/I)
<psb name>: the name of the PSB. The PSB should be compiled as an XML file. For more details, refer to the Command line options of IMSql.Psb. The XML file should be in the same directory as the program
<plan name>: the name of the plan used to connect to the database. For more details, refer to Map PLAN Name to Actual Connection String and IMS Batch.
Data prefetch
To improve the access performance, IMSql can prefetch data in a buffer. By default, the cache size is 10. However, the size can be modified using the rclrun IMSqlCacheSize parameter.
2.3.2. Online Program
Refer to the IMS/TM.
3. IMS/TM
The IMS/TM (IMS Transaction Manager) functionality is provided using SQL Server queues and messages (service broker).
The IMSql.Mfs utility translates the MFS files into XML files.
3.1. Configure IMSql/TM
3.1.1. Create IMSql/TM database
The transaction manager is implemented using SQL Server queues and
messages (service broker). The IMSql.DbGenerator is used to generate the database creation
scripts with the option :Online=true.
IMSql.DbGenerator :Online=true :Data=false :OnlineDbName=<TM db name> :OutputDir=<OutputDir>where
<TM db name>: the name of the configuration database. Most tools expect the name of the IMS/DB database with the suffix _config.
<OutputDir>: the directory containing the generated scripts
IMSql.DbGenerator produces two SQL scripts:
<TM db name>_ServiceBroker.sql: script to create the queues, services, and contracts.
<TM db name>_Tables.sql: script to create the tables for the administration of the online environment.
3.1.2. Configuring region
The configuration is done through the Raincode Console or IMSql.Cmd.
Follow the following steps to create a region:
-
In the region tab, click on the
ADD ENTRYand give the region’s name, the system to which it is associated and the different encodings (usually, they are all EBCDIC).
-
Create the list of programs using the programs tab. It only lists the programs that are associated with a transaction.
-
Create the list of transactions using the mapping tab. For each transaction, give its region, name, program, PSB and the size of the scratch pad area (SPA) if necessary.
3.1.3. Customize logon screen
By default, the logon screen is quite basic. Setting up the password is straightforward since no password verification is required (any password is accepted).
After the password validation, the user is prompted to enter the name of the first transaction or command, as shown in the screenshot below.
This setup is sufficient for a demo or prototype, but the login process is more complex for a real system. For example, a customized logon screen with password validation through Active Directory (or other password directories). And when the password is validated, the system should display a main menu depending on the user rights.
All of this can be achieved using the IMS security plugin. For more details, refer to the Security plugin.
3.1.4. Customized disconnect
By default, the command /RCLSDST (or /RCL) disconnects the terminal. However, in some cases, a more configurable workflow is needed. For example, displaying the logon screen or the last screen.
All of this can be achieved using the disconnect plugin. For more details, refer to the Disconnect plugin.
3.2. Launch IMSql/TM servers
IMSql/TM is divided into two servers:
IMSql.ProcessingServer: IMSql Processing Server
IMSql.ProcessingServer :ConnectionString=<connectionString> :RegionId=<region>IMSql.TerminalServer: IMSql 3270 TCP Terminal Server
IMSql.TerminalServer :ConnectionString=<connectionString> :RegionId=<region>| By default, the terminal server is listening to port 32023. So, your terminal emulator must connect to port 32023. |
3.3. Alternate PCB
The alternate PCB can have transaction code names (NAME=) and logical terminal names (LTERM=) as an output message destination. While the mainframe makes distinctions between transactions and terminals, this distinction is not required for IMSql. In IMSql, both message destinations are simple programs, leading to a more uniform treatment of both.
Implementation of these destinations is as follows:
-
NAME=destinations are normalIMS/TMprograms as on the mainframe, with their associated PSB files. -
LTERM=destinations are also normalIMS/TMprograms as if they wereNAME=destinations. The only difference is that these do not have a PSB file.
To specify whether a program is a message destination for a logical terminal name or a transaction-code name, the mappings tab in the Raincode Console contains an Lterm flag. If it is set to true, the program is considered mapped to a logical terminal; if it is set to false, the program is considered mapped to a transaction code.
Writing a C# program as a destination for an alternate PCB message is possible. The program masquerades as a COBOL program, and by performing calls to CBLTDLI, it interacts with IMS/TM as normal. This, in effect, allows a logical terminal to be implemented in C#.
4. Utilities
IMSql provides several utilities that can be used from the command line or some shell language (old-fashioned BAT files, PowerShell scripts, bash, etc.). These utilities are summarized here and described in more detail in this section.
-
IMSql.Load: A data load utility that reads IMS/DB UNLOAD files and loads them into SQL DB. -
IMSql.Unload: A data unload utility that reads the SQL Server database and generates an IMS/DB compatible UNLOAD file. -
IMSql.DbGenerator: SQL Server script generator from DBD files. -
IMSql.TerminalServer: IMSql/TM 3270 Terminal Server. -
IMSql.ProcessingServer: IMSql/TM Processing Server. -
IMSql.Cmd: This utility is used to query and change the status of a region in the command line.
4.1. IMSql.Load
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
-ConnectionStringis 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
bcpto load the data into the database.IMSql.LoadSegment.ps1is an example of a script that loads the data usingbcp. This technique is used if the parameter-BcpOutputFolderis used.
The IMSql.LoadSegment.ps1 can be found in %RCDIR%\scripts\IMSql.
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.
|
4.1.1. 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 byIMSql.Unloadthat needs to be loaded -
connection_string: the connection string to the database
4.1.2. 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.
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_outputdirWhere
-
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 bybcpmust 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 theCHECK_CONSTRAINTShint, anyCHECKandFOREIGN KEYconstraints 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_idThe 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 (%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>
4.1.3. Command-line options of IMSql.Load
Configuration
| Command-line option | Default value | Description |
|---|---|---|
|
Path to place the files for bcp |
|
|
SQL Database connection string to connect. |
|
|
|
Directory where the DbContext dll’s are |
|
Path to the IMS DBD file |
|
|
Name of the DBD. |
|
|
|
Generate format file in non-xml format |
|
Path to Serialize the content of the UNLOADED data This argument is mandatory. |
Miscellaneous
| Command-line option | Default value | Description |
|---|---|---|
|
This command-line option is an additional .net 'app.config' file. |
|
|
Displays the tool’s help information. |
|
|
||
|
|
Displays a description of the program. |
|
|
Specifies the log level. Valid values are:
|
|
|
Displays the version information. |
4.2. 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.UDI21PAR4.3. Command-line options of IMSql.Unload
Configuration
| Command-line option | Default value | Description |
|---|---|---|
|
SQL Database connection string to connect. |
|
|
|
Directory where the DbContext dll’s are |
|
Path to the DBD file to get the segment information. |
|
|
Name of the DBD. |
|
|
Plan name used to get SQL Database connection string to connect. |
|
|
Path to Serialize the content of the UNLOADED data. This argument is mandatory. |
Miscellaneous
| Command-line option | Default value | Description |
|---|---|---|
|
This command-line option is an additional .net 'app.config' file. |
|
|
Displays the tool’s help information. |
|
|
||
|
|
Displays a description of the program. |
|
|
Specifies the log level. Valid values are:
|
|
|
Displays the version information. |
4.4. Command line options of IMSql.DbGenerator
Data
| Command-line option | Default value | Description |
|---|---|---|
|
|
The DbContext generated displays the queries in the console |
|
|
The generated creation script contains the "CREATE DATABASE". |
|
|
Generates outputs for the IMSql DB database. |
|
|
The name of the IMSql DB database in the output scripts. |
|
|
The DbContext generated displays the queries in the debug console |
|
The generated table contains computed columns representing the ASCII representation of the raw fields. This is a boolean value. |
|
|
The sql database to upload the DBD declaration to. |
Miscellaneous
| Command-line option | Default value | Description |
|---|---|---|
|
This command-line option is an additional .net 'app.config' file. |
|
|
Encoding of the DBD files |
|
|
The input dbd files for generating the database scripts. |
|
|
Generates, for each segment, a view with the concatenated key. This view is used in the optimized GN stored function |
|
|
Displays the tool’s help information. |
|
|
||
|
|
Displays a description of the program. |
|
|
Specifies the log level. Valid values are:
|
|
|
The output folder. |
|
|
Displays the version information. |
Online
| Command-line option | Default value | Description |
|---|---|---|
|
|
Generates outputs for the IMSql TM database. |
|
|
The name of the IMSql TM configuration database in the output scripts. |
Repository
| Command-line option | Default value | Description |
|---|---|---|
|
The repository connection string. See also the DBDriver option. |
|
|
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:
|
|
|
|
Parse and scan the DBD, but do not produce any code (.sql or .cs). This is useful for checking DBD syntax for compatibility. |
4.5. Command line options of IMSql.TerminalServer
Configuration
| Command-line option | Default value | Description |
|---|---|---|
|
|
The maximum length of the pending connections queue for the terminals. |
|
The IMSql Configuration Database connection string. This argument is mandatory. |
|
|
Dump server logs in the specified directory. If no directory is specified, logs are only displayed on the console |
|
|
The location of compiled screen and message (dot,dif,mod,mid files) in a form of comma separate list of directory name, default is current directory |
|
|
|
The TCP/IP port on which the terminal server will listen for incoming TN3270 connections. Defaults to 32023. |
|
The queue listen by this terminal server. By default the queue is named "{System name}_{Region name}_{Machine name}". |
|
|
|
The IMS RegionId to bind to the terminal server. |
|
|
For backward compatibility. Transaction code is 1 to 8 bytes delimited by a space. If this flag is set, the transaction code is 8 bytes (it can contain space!). |
Miscellaneous
| Command-line option | Default value | Description |
|---|---|---|
|
This command-line option is an additional .net 'app.config' file. |
|
|
Displays the tool’s help information. |
|
|
||
|
|
Displays a description of the program. |
|
|
Specifies the log level. Valid values are:
|
|
|
Displays the version information. |
Plugin
| Command-line option | Description |
|---|---|
|
The list of plugins to be loaded when the tool executes. |
|
This command-line option specifies the path to plugins that are searched. |
Transport Layer Security
| Command-line option | Default value | Description |
|---|---|---|
|
Path to the Certificate Authority file to be used for client certificate validation. If not specified, the default system trust store will be used. |
|
|
|
Check revocation status of client certificates. Defaults to true. |
|
Require client certificate validation (mutual authentication) to establish TLS sessions. Defaults to false. |
|
|
Path to the server certificate in PEM format to be used for TLS. Enables TLS. |
|
|
Path to the (unencrypted) server private key in PEM format to be used for TLS. Required if TLS is enabled. |
4.5.5. Terminal Server Transport Layer Security
Introduction
Raincode QIX and IMSql both support Transport Layer Security (TLS/SSL) on their Terminal Servers, including mutual authentication through client certificate validation.
| For the sake of the readability of the documentation, this section is repeated identically in the QIX and IMSql manuals. |
Server authentication
To enable TLS on the Terminal Server, the -TlsServerCertificatePath option must be provided, giving a path to the server certificate chain in PEM format. The -TlsServerPrivateKeyPath option must also be provided, giving the path to the (unencrypted) server private key in PEM format.
| The server must be configured with the full certificate chain, i.e. its own certificate and all necessary intermediate CA certificates required to establish a trust chain to the root CA. Without this, server authentication will not succeed. |
| For security reasons, users should ensure that the unencrypted server private key is properly protected, e.g. by way of restrictive file access permissions. |
TerminalServer [other options] -TlsServerCertificatePath=/path/to/cert/server-chain.cert.pem -TlsServerPrivateKeyPath=/path/to/key/server.key.pemClient authentication
The Terminal Server also supports client authentication (also known as mutual authentication). It can be configured to require clients to present a valid certificate, and it also allows the server to use a custom trust store to validate those certificates. By default, client certificates are not required.
| The client authentication only makes sense if server authentication is enabled. |
To enable client authentication, set the -TlsRequireClientAuthentication flag. By default, client certificates are validated using the system’s trust store (e.g. Trusted Root Certification Authorities on Windows, or the OpenSSL trust store on Linux). The trust store used for validation can be overridden by using the TlsCertificateAuthorityFilePath option, which should point to a PEM file containing all the CA certificates trusted by the Terminal Server for client authentication.
By default, the revocation status of client certificates is checked online by way of certificate revocation list (CRL) checks or the OCSP protocol. Client authentication will fail if the client certificate has been revoked by its certificate authority, or if the revocation status cannot be assessed (e.g. if the CRL cannot be accessed through the network). To disable revocation checks (i.e. trust any client certificate signed by a trusted CA, regardless of revocation status), the -TlsCheckClientCertificateRevocation=false flag can be passed to the Terminal Server.
| Revocation status checks are enabled by default. |
TerminalServer [other options] -TlsServerCertificatePath=/path/to/cert/server-chain.cert.pem -TlsServerPrivateKeyPath=/path/to/key/server.key.pem -TlsRequireClientAuthentication -TlsCheckClientCertificateRevocation=false -TlsCertificateAuthorityFilePath=/path/to/store/custom-ca-certificates.pem4.6. Command line options of IMSql.ProcessingServer
Configuration
| Command-line option | Default value | Description |
|---|---|---|
|
Path to the configuration file for the catalog. |
|
|
The IMSql Configuration Online connection string. This argument is mandatory. |
|
|
The IMSql Database connection string (for IMS/DB). By default it’s the 'ConnectionString' where the suffix "_config" is removed from the database name |
|
|
Dump server logs in the specified directory. If no directory is specified, logs are only displayed on the console |
|
|
The queue listen by this processing server. By default the queue is named "IMS_PROC_{region name}". If the queue doesn’t exist, it’s create |
|
|
The args passed to rclrun |
|
|
|
The IMS RegionId to bind to the processing server. |
DB
| Command-line option | Description |
|---|---|
|
Connect to SQL Server to access "DB2" data with the given connection string. |
Miscellaneous
| Command-line option | Default value | Description |
|---|---|---|
|
This command-line option is an additional .net 'app.config' file. |
|
|
Displays the tool’s help information. |
|
|
||
|
|
Displays a description of the program. |
|
|
Specifies the log level. Valid values are:
|
|
|
Displays the version information. |
4.7. IMSql.Cmd
The purpose of IMSql.Cmd is to query and modify a region or server from the command line. To view help for a specific command, use: IMSql.Cmd -Help <command>.
4.7.1. Region management
In region management, the IMSql.Cmd accepts three parameters:
IMSql.Cmd.exe -ConnectionString=<connectionString> <command> -RegionName=<regionName>The valid commands to be used for region management on the IMSql.Cmd command-line are:
Example of Usage:
4.7.2. Server management
In server management, the IMSql.Cmd accepts parameters as mentioned below:
IMSql.Cmd.exe -ConnectionString=<connectionString> [options] <command>The valid commands to be used for server management on the IMSql.Cmd command-line are:
-
servers-status: This command displays a list of all servers filtered by the options, similar to the Raincode console servers page.
-
stop-server: This command sends a
stop-messageto all servers selected by the filter option, causing the server to stop by itself, similar to a stop button on the Raincode console servers page.
| A dry run with the servers-status command with the same filter is recommended before running the stop-server command. |
-
purge-servers: This command removes old servers from the server list provided by the server status or the Raincode console servers page.
| It is not possible to remove a running server with this command. Before running the purge-server command, a dry run with the servers-status command with -OldServers and the same filter is recommended. |
All the server commands accept the following filters:
-
RegionName: only select the server working on the given region name. This filter is optional
-
ServerHostname: only select servers that are/were running on the given server’s name
-
ServerType: can be Processing, Terminal, P, T; this command selects a server of the specified type
-
ServerID: filters servers based on their ID
-
RunningServer: this selects a server with an
active timestampnot older than 33 seconds, and the status is not exiting. This option is activated by default for all commands, except for the purge-server command -
OldServer: this selects servers with an
active timestampolder than the OldServerThreshold parameters. This option is disabled by default for all commands, except for the purge-server command -
OldServerThreshold: the default is 90 days; this allows you to modify the time laps to consider a server
old. This option is a time option; it accepts a number followed by a unit, for example,24h,30min, or90days. The unit specified can be days, hours, min, sec, milliseconds, or abbreviations.
4.7.3. Commands in JSON file
The JSON option takes a JSON file that contains a list of command.
Each command has the following format:
{
"$type": "command name",
"option name": "value",
"option name" : "value"
}And the file has the following format:
{
"$values": [
Command1,
Command2
]
}For example:
{ "$values": [
{
"$type": "AddRegion",
"SystemName": "IMS",
"RegionName" : "TSTR"
},
{
"$type": "AddRegion",
"SystemName": "IMS",
"RegionName" : "TSTR2",
"TMConnectionString" : "$SQLSERVERCONNECTIONSTRING$"
},
{
"$type": "AddTransaction",
"RegionName" : "TSTR",
"PsbName" : "TSTPSB",
"TransactionCode" : "TSTTR",
"ProgramName" : "TSTPRG"
},
{
"$type": "EditRegion",
"SecurityConfig": "security config",
"SystemName": "IMS",
"RegionName": "TSTR",
"LocalEncoding": "IBM037",
"TerminalEncoding": "IBM037"
},
{
"$type": "GetRegion",
},
]
}4.7.4. Options
Command
| Command-line option | Description |
|---|---|
|
Json file containing a list of commands. |
Configuration
| Command-line option | Description |
|---|---|
|
SQL Database connection string to connect. This argument is mandatory. |
Miscellaneous
| Command-line option | Default value | Description |
|---|---|---|
|
This command-line option is an additional .net 'app.config' file. |
|
|
Displays the tool’s help information. |
|
|
||
|
|
Displays a description of the program. |
|
|
Specifies the log level. Valid values are:
|
|
|
Displays the version information. |
4.7.5. SubCommands
start-region: Enable a region
stop-region: Disable a region
region-status: Get region status
stop-server: Stops a server
servers-status: Get servers status
purge-servers: Purges old server from the logs
add-region: adds a new region
remove-region: remove a region
edit-region: Edit a region
add-transaction: adds a new transaction
get: Get list of regions or transactions
edit-transaction: Edit a transaction
IMSql.Cmd start-region
Enable a region
IMSql.Cmd stop-region
Disable a region
IMSql.Cmd region-status
Get region status
IMSql.Cmd stop-server
Stops a server
Miscellaneous
| Command-line option | Description |
|---|---|
|
Displays the tool’s help information. |
Server filter
| Command-line option | Default value | Description |
|---|---|---|
|
Name of the region |
|
|
Allow to change the threshold that concider server to be old, default is 3 month |
|
|
|
Select only servers that are 'old' |
|
Select servers that match given Hostname |
|
|
Select server that match given Id |
|
|
Select server that match given Type Valid values are:
|
IMSql.Cmd servers-status
Get servers status
Miscellaneous
| Command-line option | Description |
|---|---|
|
Displays the tool’s help information. |
Server filter
| Command-line option | Default value | Description |
|---|---|---|
|
Name of the region |
|
|
Select only servers that are running, default is false for server-purge, true for other command |
|
|
Allow to change the threshold that concider server to be old, default is 3 month |
|
|
|
Select only servers that are 'old' |
|
Select servers that match given Hostname |
|
|
Select server that match given Id |
|
|
Select server that match given Type Valid values are:
|
IMSql.Cmd purge-servers
Purges old server from the logs
Miscellaneous
| Command-line option | Description |
|---|---|
|
Displays the tool’s help information. |
Server filter
| Command-line option | Default value | Description |
|---|---|---|
|
Name of the region |
|
|
Allow to change the threshold that concider server to be old, default is 3 month |
|
|
Select only servers that are running, default is false for server-purge, true for other command |
|
|
|
Select only servers that are 'old' |
|
Select servers that match given Hostname |
|
|
Select server that match given Id |
|
|
Select server that match given Type Valid values are:
|
IMSql.Cmd add-region
adds a new region
Miscellaneous
| Command-line option | Default value | Description |
|---|---|---|
|
Displays the tool’s help information. |
|
|
|
The name of the region system |
|
The name of the region to create This argument is mandatory. |
|
|
|
Local encoding |
|
|
Terminal encoding |
|
The TM connection string of the region to create |
IMSql.Cmd remove-region
remove a region
IMSql.Cmd edit-region
Edit a region
Miscellaneous
| Command-line option | Description |
|---|---|
|
Displays the tool’s help information. |
IMSql.Cmd add-transaction
adds a new transaction
Miscellaneous
| Command-line option | Default value | Description |
|---|---|---|
|
Displays the tool’s help information. |
|
|
The name of the transaction This argument is mandatory. |
|
|
The name of the region to create This argument is mandatory. |
|
|
The name of the program attached to the transaction This argument is mandatory. |
|
|
The name of the PSB attached to the transaction This argument is mandatory. |
|
|
|
The size of the SPA (Scratch pad area) of the transaction |
IMSql.Cmd get
Get list of regions or transactions
IMSql.Cmd get regions
returns all the regions
IMSql.Cmd get Transactions
returns all the transactions
Miscellaneous
| Command-line option | Description |
|---|---|
|
Displays the tool’s help information. |
Filter
| Command-line option | Description |
|---|---|
|
Filter based on the region name |
|
The name of the transaction |
|
The name of the program attached to the transaction |
|
The name of the PSB attached to the transaction |
|
The size of the SPA (Scratch pad area) of the transaction |
|
transaction is a Lterm |
IMSql.Cmd edit-transaction
Edit a transaction
Miscellaneous
| Command-line option | Description |
|---|---|
|
Displays the tool’s help information. |
|
Filter based on the region name |
|
Filter based on the name of the transaction |
|
The new name of the program attached to the transaction |
|
The new name of the PSB attached to the transaction |
|
The new size of the SPA (Scratch pad area) of the transaction |
|
The new transaction is a Lterm |
|
The new retry count |
|
The new retry wait (in ms) |
|
The new transaction timeout (in ms) |
5. Parser Utilities
The following are the parser utilities:
-
IMSql.Mfs: This utility parses MFS files to generate XML representations of 3270 screen definitions.
-
IMSql.Psb: This Utility parses PSB files to generate XML representations of 3270 screen definitions.
5.1. Command line options of IMSql.Mfs
It parses MFS files to generate XML representations that are used by the Terminal Server to define 3270 screens. It also loads the MFS definitions into the configuration database.
configuration DB
| Command-line option | Description |
|---|---|
|
The sql database to upload the MFS definition to. |
Configuration
| Command-line option | Default value | Description |
|---|---|---|
|
The directory will contain the generated XML files. |
|
|
|
The number of spaces by which a tab character will be replaced when found in the MFS file. |
Miscellaneous
| Command-line option | Default value | Description |
|---|---|---|
|
This command-line option is an additional .net 'app.config' file. |
|
|
Displays the tool’s help information. |
|
|
||
|
|
Displays a description of the program. |
|
|
Specifies the log level. Valid values are:
|
|
|
Displays the version information. |
Parsing
| Command-line option | Default value | Description |
|---|---|---|
|
|
Directories that will contain the include/copybook files. |
|
|
Provides a semicolon separated set of extensions to use when opening include files. '.' character must be explicitly specified. Example: -IncludeExtension=.foo,.bar. |
|
|
The encoding of the MFS Files. |
5.2. Command line options of IMSql.Psb
It parses PSB files to generate XML representations that are used by rclrun. It also loads the PSB definitions into the configuration database.
Configuration DB
| Command-line option | Description |
|---|---|
|
The sql database to upload the files to. |
Miscellaneous
| Command-line option | Default value | Description |
|---|---|---|
|
This command-line option is an additional .net 'app.config' file. |
|
|
Displays the tool’s help information. |
|
|
||
|
|
Displays a description of the program. |
|
|
Specifies the log level. Valid values are:
|
|
|
Displays the version information. |
Parsing
| Command-line option | Default value | Description |
|---|---|---|
|
|
Directories that will contain the include/copybook files. Several directories can be specified separated by ';'. |
|
|
Provides a semicolon separated set of extensions to use when opening include files. '.' character must be explicitly specified. Example: -IncludeExtension=.foo,.bar. |
|
|
The encoding of the PSB Files. |
|
The directory will contain the generated XML files. |
|
|
|
The number of spaces by which a tab character will be replaced when found in the PSB file. |
Repository
| Command-line option | Default value | Description |
|---|---|---|
|
The repository connection string. See also the DBDriver option. |
|
|
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:
|
|
|
|
Parse and scan the PSB, but do not produce any code (.xml). This is useful for checking PSB syntax for compatibility. |
6. Plugin
6.1. Security plugin
IMSql online security is divided into two parts:
-
The first one, on the Terminal server side, checks if the user can connect to the system.
-
The second one, on the Processing server side, checks if a transaction can be executed. The connection between the Terminal server and the Processing server is made through the SecurityString. This string is created by the logon process and passed to the Processing server to decide if the user of the current session can execute a given transaction.
By default, the Terminal server does not validate the password and creates the SecurityString with the value ok. At the same time, the Processing server allows all the transactions.
To change this behaviour, two plugins are available, one for the Terminal server and another for the Processing server.
6.1.1. Terminal server security plugin
The plugin instance is located at RainCode.IMSql.TerminalServer.Extensibility.SecurityManagerBuilder.
The plugin registration should provide a method that receives a string as an input parameter and returns an RainCode.IMSql.TerminalServer.Logon.ILogonProcess instance.
The ILogonProcess interface provides a method that allows the logon process in the IMSql.
public interface ILogonProcess
{
/// <summary>
/// First method called in the logon process
/// </summary>
/// <param name="context">The session context</param>
void Start(ISessionContext context);
/// <summary>
/// Called for each logon transaction
/// </summary>
/// <param name="context">The session context</param>
/// <param name="userAnswer">The input message received from the screen.
/// This message has the same format as input message in COBOL:
/// 0-1 bytes: data length (including the header)
/// 2-3 bytes: not used
/// 4-* bytes: the input message. Usually, the first 8 bytes
/// are the transaction code</param>
void ProcessUserInput(ISessionContext context, byte[] userAnswer);
}The methods are explained below:
-
Start: This is the first method, called by the disconnect process. Typically, it is used to disconnect the terminal or display the logon screen.
-
ProcessUserInput: Called for each disconnect transaction, i.e., Each time data is received from the Terminal server, the userAnswer contains the data received from the screen in the same format as the input message of a COBOL program.
-
0-1 bytes: Data length (including the header).
-
2-3 bytes: Not used.
-
4-* bytes: The input message. Usually, the first 8 bytes are the transaction code.
-
Both methods receive an ISessionContext that provides different methods to interact with the terminal:
-
SendScreen: Send a screen to the terminal.
-
modName: The mod name (output message name).
-
SingleSegment: The single segment output message.
-
-
CompleteWithPrompt: Finishes the logon process by displaying the prompt.
-
User: The user id used to logon.
-
SecurityContextString: The security string.
-
-
CompleteWithScreen: Finishes the logon process by displaying a screen.
-
User: The user id used to logon.
-
SecurityContextString: The security string.
-
modName: The mod name (output message name).
-
SingleSegment: The single segment output message.
-
-
CompleteWithTransaction: Finishes the logon process by executing a transaction.
-
User: The user id used to logon.
-
SecurityContextString: The security string.
-
transactionCode: The transaction code.
-
SingleSegment: The input message of the transaction.
-
-
ReadOut: Extract from the buffer a string (using the terminal encoding) starting at 'start' for 'length' bytes.
-
WriteIn: Puts in 'buffer', starting at 'start' with a length of 'length', into 'str'.
-
TerminalEncoding: The encoding used by the terminal.
-
6.1.2. Processing server security plugin
The plugin instance is located at RainCode.IMSql.ProcessingServer.Extensibility.AuthorizationManagerBuilder.
The plugin registration should provide a method that receives a string as an input parameter and returns an RainCode.IMSql.ProcessingServer.Security.IAuthorizationManager instance.
The IAuthorizationManager interface contains a method to check if the processing server can execute a transaction:
-
AuthorizeTransaction: Checks if the
IAuthorizationContextpermits the execution of the transaction.
IAuthorizationContext contains a field and attribute about the transaction and SecurityString:
-
TransactionCode: The transaction code.
-
SecurityContextString: The security string.
-
Allow: Allows the user to execute the transaction.
-
Deny: Denies the user to execute the transaction and provides an error message.
6.2. Disconnect plugin
The plugin instance is located at RainCode.IMSql.TerminalServer.Extensibility.DisconnectBuilder.
The plugin registration should provide a method that receives a string as an input parameter and returns an RainCode.IMSql.TerminalServer.Logon.IDisconnectProcess instance.
The IDisconnectProcess interface provides methods allowing disconnect process in the IMSql.
public interface IDisconnectProcess
{
/// <summary>
/// First method called in the disconnect process
/// </summary>
/// <param name="context">The session context</param>
void Start(ISessionContext context);
/// <summary>
/// Called for each disconnect transaction
/// </summary>
/// <param name="context">The session context</param>
/// <param name="userAnswer">The input message received from the screen.
/// This message has the same format as input message in COBOL:
/// 0-1 bytes: data length (including the header)
/// 2-3 bytes: not used
/// 4-* bytes: the input message. Usually, the first 8 bytes are the transaction code</param>
void ProcessUserInput(ISessionContext context, byte[] userAnswer);
}The methods are explained below:
-
Start: This is the first method, called by the disconnect process. Typically, it is used to disconnect the terminal or display the logon screen.
-
ProcessUserInput: Called for each disconnect transaction, i.e., Each time data are received from the Terminal server, the userAnswer contains the data received from the screen in the same format as the input message of a COBOL program.
-
0-1 bytes: Data length (including the header).
-
2-3 bytes: Not used
-
4-* bytes: The input message. Usually, the first 8 bytes are the transaction code.
-
Both methods receive an ISessionContext that provides different methods to interact with the terminal:
-
SendScreen: Sends a screen to the terminal.
-
modName: The mod name (output message name).
-
SingleSegment: The single segment output message.
-
-
StartLogonProcess: Starts the logon process.
-
DisconnectSession: Disconnects the terminal.
-
ReadOut: Extract from the buffer a string (using the terminal encoding) starting at 'start' for 'length' bytes.
-
WriteIn: Puts in 'buffer', starting at 'start' with a length of 'length', into 'str'.
-
TerminalEncoding: The encoding used by the terminal.
7. Raincode Plugins
7.1. Ims.SecurityManagerPlugin
Internal plugin
Class |
|
Field name |
|
Strategy |
Best non null |
SeeAlso |
Plugin API:
RainCode.IMSql.Common.Security.ISecurityPlugin(string arg0)
Description:
Deprecated. Use IMSqlAuthorizationManagerBuilder and IMSqlSecurityManagerBuilder.
7.2. IMSqlAuthorizationManagerBuilder
Class |
|
Property name |
|
Strategy |
Best non null |
Default implementation |
All transactions can be executed |
Plugin API:
RainCode.IMSql.ProcessingServer.Security.IAuthorizationManager(string securityConfig)
-
securityConfig- The security configuration string -
Result - The authorization process
Description:
Check if the current user is allowed to execute the transaction.
For more details refer to the processing server security plugin documentation.
7.3. GetNextTerminalName
Class |
|
Field name |
|
Strategy |
Best non null |
Default implementation |
LPTLP + a random number |
Plugin API:
string(RainCode.IMSql.Common.Config.RegionConfig region)
-
region- The region -
Result - The terminal name
Description:
Provide a terminal name
7.4. IMSqlSecurityManagerBuilder
Class |
|
Property name |
|
Strategy |
Best non null |
Default implementation |
Accept all user/password and return "ok" as security string |
Plugin API:
RainCode.IMSql.TerminalServer.Logon.ILogonProcess(string securityConfig)
-
securityConfig- The security configuration string -
Result - The logon process
Description:
Provide a custom login process.
For more details refer to the terminal server security plugin documentation.
7.5. IMSqlDisconnectBuilder
Class |
|
Property name |
|
Strategy |
Best non null |
Default implementation |
Disconnect the session |
Plugin API:
RainCode.IMSql.TerminalServer.Logon.IDisconnectProcess(string securityConfig)
-
securityConfig- The security configuration string -
Result - The disconnect process
Description:
Provide a custom disconnect process.
For more details refer to the disconnect plugin documentation.
8. Debugging
8.1. Debugging a Batch Program
To debug a batch program, the program must be compiled with debug information, add a parameter to DFSRRC00 in the JCL and submit your job:
-
Compile the program with the
-Debugoption. (cobrc -Debug) -
Add
DEBUG=TRUEas the 21st parameter ofDFSRRCOO
//G1 EXEC PGM=DFSRRC00,REGION=512K,
// PARM='DBB,DLRSTAT,DLRSTAT,,,,,,,,,,,,,,,,,,DEBUG=TRUE'-
Submit the JOB
Submit -FILE=`EXTRACT-STAT.JCL`
-
A debug window will appear in a few seconds. From the list, select the Visual Studio instance where the program you want to debug is currently open.
8.2. Debugging an Online Program
To debug an online program, attach the debugger to the processing server.
-
Compile the program with the
-Debugoption. (cobrc -Debug) -
Start the processing server (
IMSql.ProcessingServer) -
Select
Debug→Attach to Process… (Ctrl+Alt+P)to attach a process.
-
A window will appear, select
IMSql.ProcessingServerand click on Attach.
-
Set a breakpoint in the program.
-
Execute the transaction you want to debug.
8.3. Logging
Log messages will be displayed differently depending on the log level.
If the log level is set to INFO, a message is displayed at the end of the IMS query giving the execution time in milliseconds.
[2023-10-13 12:16:31.538] [10] [INFO] [APPDLI]: IMS Call end: GU with 4 parameters: 447
The following messages are displayed if the log level is set to TRACE.
[2023-10-13 12:16:31.090] [10] [TRACE] [APPDLI]: IMS Call
[2023-10-13 12:16:31.091] [10] [TRACE] [APPDLI]: IMS Call : GU with 4 parameters.
The above message displays the function and the number of parameters.
[2023-10-13 12:16:31.092] [10] [TRACE] [APPDLI]: IMS Call for 4340.
[2023-10-13 12:16:31.093] [10] [TRACE] [APPDLI]: IMS Call for 4340 on DB.
The above message displays the PCB id and the type.
[2023-10-13 12:16:31.532] [10] [TRACE] [IMS.ResultRowCache]: Init cache from reader: 1
The above message displays the number of lines prefetched in the cache.
[2023-10-13 12:16:31.533] [10] [TRACE] [IMS.ResultRowCache]: The current element is 0
The above message displays the element number read in the cache (zero based).
[2023-10-13 12:16:31.534] [10] [TRACE] [APPDLI]: IMS call status: Blanks
The above message displays the query status code.
If the log level is set to DIAGNOSTIC, the SSA used, and the SQL query is displayed. This message only appears into the console, it is not saved if the log is directed to a file (-LogsDirectory option)
[2023-10-13 12:16:31.094] [10] [DIAGNOSTIC] [IMS.Ssa]: Ssa: DEALER(DLRNO EQ DDDD00003)
info: Microsoft.EntityFrameworkCore.Database.Command[20101]
Executed DbCommand (6ms) [Parameters=[], CommandType='Text', CommandTimeout='600']
SELECT TOP(10) N'DEALER' AS [Type], 0 AS [Level], [d].[RID], -1 AS [PID], SUBSTRING([d].[Data], 0 + 1, 10000) AS [Data], [d].[DLRNO] AS [Key], SUBSTRING([d].[DLRNO], 0 + 1, 10) AS [CKey], N'$' + CONVERT(VARCHAR(11), [d].[RID]) AS [CRid], (0x01 + 0x00) + 0x AS [CHid], [d].[HID], N'' AS [QueryType], CAST(1 AS bit) AS [HasChild]
FROM [DEALERDB_DEALER] AS [d]
WHERE [d].[DLRNO] = 0xC4C4C4C4F0F0F0F0F340
ORDER BY [d].[DLRNO]9. Database Connection
There can be two connection strings used by IMSql. The first is the connection to the data database, and the second is the connection to the online database that manages the queues.
9.1. IMS Batch
The plan to be used to retrieve the connection string is the 14th parameter of DFSRRC00. This plan is used to search for a connection string to connect to the database. If a plan with the same name suffixed by _config is found, then this plan is used to connect to the online database.
If no such plan is found, the connection string to the database is used to connect to the online database by adding _config to the database name.
If a batch program also needs to access the Db2® database. The connection string to the Db2® database is given as two environment variables named RC_DB_CONNECTION and RC_DB_TYPE.
9.2. IMS Online
Terminal server
The terminal server has only one connection string to the online database. The -ConnectionString option.
Processing server
The processing server needs two connection strings, one to the database and one to the online database.
-ConnectionString option is used to give the connection string to the online database. This option is mandatory.
-DbConnectionString option is used to give the connection string to the database. This option is optional.
If not present, the connection string to the online database is used by removing the _config prefix from the database name.
If an online program also needs to access Db2® database. The Db2® connection string should be given using the -SqlServer option.
For example:
-SqlServer="Server=tcp:10.0.0.10,1433;Initial Catalog=MY_DB;Persist Security Info=False;User ID=ME;Password=mypwd;MultipleActiveResultSets=True;Encrypt=True;TrustServerCertificate=False;"
10. Refactoring an IMSql segment
This section describes how to perform non-trivial changes to existing IMSql segments and update the corresponding data accordingly. This kind of operation requires an understanding of how IMS® concepts are mapped onto relational technology.
The following steps are provided for a detailed explanation, including manual steps and screenshots to demonstrate their effects on the operations of the database. However, in the real world, automation is recommended. These steps should be consolidated into a script (PowerShell, Bash, or Python).
| This script should be tested extensively on a copy of the data before even considering running it against the production database. This will also allow you to calibrate the duration of the window during which the database will become unavailable. |
| Adequate backups must be taken before running it on the production database to ensure that a stable situation can be restored in case of a last-minute unexpected issue. |
10.1. The starting point
This sample refactoring starts with a simple database with two hierarchies of segments, as shown below (captured from the Raincode Console.)
The CATALOG segment is connected to both parent and child segments, and to a logical parent segment from another DBD.
This segment contains two fields at the IMS® level.
And they are mapped onto a view built according to a COBOL copybook.
| In this case, the IMS® view and the COBOL copybook view are isomorphic, but the COBOL version is significantly more detailed in many instances. |
10.2. Adding a field
Assume the task is to insert a 20-character text field (named MODCLAS) between the MODTYPE and COMMENT fields in this segment. This is not just about modifying the database structure but also updating existing records accordingly. In practice, this means having 20 bytes inserted at offset 20 and initializing this new field with a meaningful value.
10.2.1. The artefacts
First, the DBD must be updated to include this new field:
And the copybook must be updated accordingly:
10.2.2. Code generation
The IMSql.DbGenerator utility can then be used to generate all the SQL scripts (DDL for the tables, stored procedure) by going through all the connected DBDs. Additionally, it updates the CATALOG segment entry in the IMSql configuration database used by the Raincode Console.
The CopybookViewGenerator utility generates the SQL view based on the updated COBOL copybook. This also updates the copybook definition for this segment in the IMSql configuration database to be used by the Raincode Console.
While dealing with the changes to data access layer components (Programs, Mfs, etc.) make sure to recompile .csproj files newly generated by the IMSql.DbGenerator.
|
10.3. Migrating the data
10.3.1. Dropping foreign key constraints
Initially, one may think that all that needs to be done at this point is to drop the old version of this table, create a new one with the newly inserted field, and populate it from the clone.
However, the process is more complex because IMSql enforces foreign key constraints that prevent the dbo.DEALERDB_CATALOG table from being easily dropped.
To get the list of foreign keys, use 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
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
To best address this problem, two dedicated stored procedures are generated by IMSql for every segment, one to create (named RC_CREATE_FK_<SegmentTableName>) and one to drop (named RC_DROP_FK_<SegmentTableName>) the foreign key constraints.
In this context, one must first invoke the latter:
EXEC RC_DROP_FK_DEALERDB_CATALOGAnd ensure that all the foreign key constraints have been dropped:
10.3.2. Create backup
The data migration starts by taking backup of the table representing the CATALOG segment, for example, as below.
SELECT * INTO dbo.DEALERDB_CATALOG_BKP
FROM dbo.DEALERDB_CATALOG10.3.3. Drop the table and view
The view and the table that represent the segment can now be dropped safely:
DROP TABLE dbo.DEALERDB_CATALOGDROP VIEW dbo.DEALERDB_CATALOG_V10.3.4. Create the table and view
Considering the newly created field, one must now recreate the table with the updated structure.
The SQL script generated by IMSql creates many database objects. One must thus extract the part that creates the table that represents the CATALOG segment, as well as its attached indexes, if any:
One can also create the view derived from the (updated) COBOL copybook:
10.3.5. Load the table
The table can now be populated, starting from the backup taken before dropping and recreating the table and appropriately inserting space for the new field in the Data column.
In the example above, this field is initialized with spaces. It can be initialized with any value (as long as it stores 20 bytes exactly). Alternatively, one can first insert 20 characters and then change the value of this field using plain SQL statements operating on the newly created view (see above).
10.3.6. Reinistate foreign key constraints
Now that all the data has been migrated, the foreign key constraints dropped in this process’s early phases can be reinstated.
This can be achieved by running the stored procedure generated to this effect:
EXEC RC_CREATE_FK_DEALERDB_CATALOGOne can then ensure that all the foreign key relations have been successfully reinstated:
If the data has been modified in a way that does not satisfy the foreign key constraints (for instance, if a record from the CATALOG segment was deleted while still referenced by other segments), executing this stored procedure will produce an error message.
If no such error message is produced, the database is reliable regarding its relationships and hierarchies.
10.3.7. Recreate Functions and Stored Procedures
The SQL script generated by the IMSql.DbGenerator can be re-executed, as it updates the functions, stored procedures, triggers, etc., without disturbing the existing segment tables and their data.
In any special case, one may consider extracting the relevant part from the generated SQL script and applying it to the database. For more details, refer to Triggers, Functions, and Stored Procedures generated at the DBD or segment level.
For example:
One is generic to the DBD at hand (dealing with the GN primitive across all segments):
The others are specific to the CATALOG segment:
10.4. The final state
The CATALOG segment now includes the newly inserted field MODCLAS:
Which can also be found in the copybook as reported by the Raincode Console:
10.5. Key Considerations
This section describes a typical case of refactoring of IMS® segments in the context of IMSql. It is important not just to follow the steps blindly but to understand the underlying concept, as every situation is unique and may require specific approaches. For instance, when dealing with leaf segments, foreign key constraints are not a concern, and the steps describing how to drop and reinstate them can be safely ignored. If multiple segments must be updated at once, the operations can be merged into a large, all-encompassing automation script for performance. Even more complex setups, where a segment is split into two or more separate segments, can also be supported. If the amount of data to process becomes big, up to a point where the insertion statement shown in the sample above becomes too slow, one can design a solution based on SQL Server’s bcp for data migration.
11. Telemetry
11.1. Introduction
This section describes Raincode’s approach to Telemetry across all relevant products.
| For the sake of readability of the documentation, this section is repeated identically in the following manuals: QIX, IMSql, and JCL. |
11.1.1. What is Telemetry
According to Wikipedia, Telemetry is the automatic process of measuring and transmitting data for the purpose of monitoring applications and assessing their health and performance.
This definition implies the clear separation between the production of this continuous stream of data and the collection, summarization, storage, etc., of this data. As a response to this separation, the OpenTelemetry standard has emerged, enabling a vibrant market for visualization and monitoring tools. It provides a single, open-source standard and a set of technologies to capture and export metrics, traces, and logs from cloud-native applications and infrastructure.
11.1.2. How about Raincode
Telemetry applies to the subset of Raincode’s products that include a runtime component:
-
QIX, Raincode’s CICS emulator
-
IMSql, Raincode’s IMS emulator (and in the context of Telemetry, focusing on the IMS/TM part of this product)
-
Raincode JCL.
While very different in functionality, these products share the ability to send events that can be used to monitor the health and performance of the running processes.
While the Raincode Console can be used to manage the static aspects of the configuration of these products and some more dynamic aspects (inspecting IMS/TM queues, for instance), it does not offer any telemetry capabilities. This is not an oversight: the Raincode product line is designed to connect to third-party solutions for Telemetry instead.
Further, the section below explains how the Raincode products mentioned above can be configured to external telemetry services for monitoring, visualization, alerts, and more.
11.2. In practice
The Raincode products are agnostic as per the telemetry platform (or even Telemetry standard) they will connect to.
Using user-defined plugins, one has full control over how events produced by the products (starting or stopping a JCL, QIX transactions, etc.) are handled, what to connect to, etc.
The QIX, IMSql, and Raincode JCL distributions include a plugin that connects to an OpenTelemetry endpoint, which can be easily replaced or extended for more functionality or to connect to an entirely different platform if necessary.
11.2.1. Event Structure
The events produced by all Raincode products follow a consistent naming convention. The event names are made of three parts, separated by colons, according to the following pattern:
-
Product: The name of the product, forced in lower case, e.g. qix or ims
-
Name: The type object the event is about, e.g. transaction or aplitdli
-
Verb: The action that was done on that object, e.g. start, stop, abort
For instance, valid event names include:
-
qix:transaction:start
-
ims:transaction:stop
This simple scheme allows optimal flexibility when filtering events by product, object, action or any combination thereof.
| Event | Arguments | Description |
|---|---|---|
ims:transaction:start |
the transaction code |
Start of an IMS transaction |
ims:transaction:stop |
the transaction code |
End of an IMS transaction |
ims:appltdli:start |
the function |
Start of a IMS call (EXEC DLI, CBLTDLI, PLITDLI, CEETDLI, ASMTDLI) using a DB PCB |
ims:appltdli:stop |
the function |
End of a IMS call (EXEC DLI, CBLTDLI, PLITDLI, CEETDLI, ASMTDLI) using a DB PCB |
ims:appltdli_io:start |
the function |
Start of a IMS call (EXEC DLI, CBLTDLI, PLITDLI, CEETDLI, ASMTDLI) using a IO PCB |
ims:appltdli_io:stop |
the function |
End of a IMS call (EXEC DLI, CBLTDLI, PLITDLI, CEETDLI, ASMTDLI) using a IO PCB |
ims:appltdli_alt:start |
the function |
Start of a IMS call (EXEC DLI, CBLTDLI, PLITDLI, CEETDLI, ASMTDLI) using a alternate PCB |
ims:appltdli_alt:stop |
the function |
End of a IMS call (EXEC DLI, CBLTDLI, PLITDLI, CEETDLI, ASMTDLI) using a alternate PCB |
qix:transaction:start |
the transaction code |
Start of on CICS transaction |
qix:transaction:stop |
the transaction code |
End of on CICS transaction |
batch:job:preexecute |
the name of the job |
Start of a job (JCL) |
batch:job:postexecute |
the name of the job |
End of a job (JCL) |
batch:step:preexecute |
the name of the step |
Start of a step |
batch:step:postexecute |
the name of the step |
End of a step |
11.2.2. The Telemetry plugin
The plugin provides a single interface for events behind which the user can customize the filtering and connection to the telemetry API of choice. This interface is made using a single method.
LogTelemetryEvent(name, args…)To which the first parameter will always be the event name, and the following parameters will depend on the event itself.
LogTelemetryEvent("qix:transaction:start", Transaction.ID);
LogTelemetryEvent("qix:transaction:stop", Transaction.ID, transactionResult.Error);If only a subset of the events must be reacted to, one can use an appropriate filtering regular expression, taking advantage of the naming convention described above.
public void LogTelemetryEvent(string eventName, params string[] eventData){
switch (eventName)
{
case "ims:transaction:start":
StartIMSqlTransactionTelemetry(eventData[0]);
break;
case "ims:transaction:stop":
StopIMSqlTransactionTelemetry(eventData[0], eventData[1]);
break;
case "ims:appltdli:start":
StartAppltdliTelemetry(eventData[0]);
break;
case "ims:appltdli:stop":
StopAppltdliTelemetry(eventData[0]);
break;
default:
break;
}
}| The sample telemetry plugin can be found at %RCDIR%\plugins\AppInsights. |
11.2.3. Using a plugin: command line
Providing the telemetry plugin follows the same options as providing any plugin to an application.
Use -Plugin to provide a path to an assembly.
Submit.exe -Plugin=<path to assembly>Or you can use -PluginPath to provide a path to a folder where all the assemblies will be scanned for plugins.
Submit.exe -PluginPath=<path to folder>The screenshot below was captured by connecting Raincode JCL to .NET Aspire® and using Application Insight for visualization.
Appendix A: The repository
This section overviews the Raincode legacy compilers, Raincode IMSql and Raincode JCL JOB repository. The repository contains detailed information on the tables gathered by the legacy compilers, IMSql and JCL JOBs. The repository is structured into several SQL tables and stored in a SQLite database (.DB3 file).
The repository can be explored using DB Browser for SQLite®, which lets you see the database structure, browse data, execute SQL queries, and provide many more options.
| For the sake of readability of the documentation, this section is repeated identically in the following manuals: Stack, IMSql, and JCL. |
Some actions that can be performed using DB Browser are:
-
Exploring the database structure
For example, as illustrated in the screenshot below, the RC_PROGRAM table contains information about program files that have been analyzed by Raincode legacy compilers.
-
Browsing data
For example, as illustrated in the screenshot below, users can explore the data within the RC_PROGRAM table.
-
Executing SQL queries
For example, users can write queries to investigate the database content. The query in the screenshot below displays a list of programs for which the Raincode compiler reported zero errors.
Raincode also provides a PowerBI template called Raincode Insight, to visualise the repository’s contents.
Below are some screenshots from a sample repository captured using the Raincode Insight tool.
The first screenshot illustrates the Raincode Insight dashboard.
The second screenshot displays the general statistics of the portfolio.
Here are the links to the available Raincode repositories:
A.1. IMS DBD repository
This section of the repository contains information extracted from the DBD using IMSql.DbGenerator
A.1.1. RC_IMS_DBD table
The RC_IMS_DBD table contains information regarding the DBD.
| Column | Type | Description |
|---|---|---|
|
Int32 |
The record identifier of DBD. RC_ID is the key to this record. |
|
String |
DBD name |
|
String |
The time when the DBD was parsed |
|
String |
Path to the source file |
|
String |
Access method |
|
String |
Data Capture exit routine |
|
String |
Encoding of the characters in the DB |
A.1.2. RC_IMS_DBD_SEGMENT table
RC_IMS_DBD_SEGMENT table contains information regarding the segments of the DBD.
| Column | Type | Description |
|---|---|---|
|
Int32 |
Foreign key to entry in RC_IMS_DBD. Identifies the DBD on which these data apply. |
|
Int32 |
The pair of |
|
String |
Segment name field |
|
Int32 |
The level of the segment |
|
Int32 |
The maximum size of the segment |
|
String |
The segment parent field. NULL if no parent or parent = 0 |
|
String |
Segment sequence type (NO, UNIQUE, NON_UNIQUE or UNKNOWN) |
|
String |
Segment rules field (can be null) |
|
String |
Segment’s logical parent DBD (can be null) |
|
String |
Segment’s logical child segment (can be null) |
|
Int32 |
Logical parent RC_ID (can be null) |
|
Int32 |
Logical parent RC_SEQ (can be null) |
|
String |
The first segment’s source DBD (can be null) |
|
String |
The first segment’s source segment (can be null) |
|
Int32 |
The first segment’s source RC_ID (can be null) |
|
Int32 |
The first segment’s source RC_SEQ (can be null) |
|
String |
The second segment’s source DBD (can be null) |
|
String |
The second segment’s source segment (can be null) |
|
Int32 |
The second segment’s source RC_ID (can be null) |
|
Int32 |
The second segment’s source RC_SEQ (can be null) |
|
String |
Data capture exit routine |
|
String |
compression exit routine |
|
String |
Encoding of the characters in the DB |
A.1.3. RC_IMS_DBD_LCHILD table
The RC_IMS_DBD_LCHILD table contains information regarding the logical child of the segment.
| Column | Type | Description |
|---|---|---|
|
Int32 |
Foreign key to entry in RC_IMS_DBD. Identifies the DBD on which these data apply. |
|
Int32 |
The pair of |
|
String |
The DBD’s name of the lchild |
|
String |
The LCHILD segment name |
|
String |
The LCHILD INDEX field |
|
String |
The LCHILD POINTER field |
|
String |
The LCHILD PAIR field |
|
Int32 |
The pair of |
A.1.4. RC_IMS_DBD_XFLD table
The RC_IMS_DBD_XFLD table contains information regarding the segment’s XDFLD.
| Column | Type | Description |
|---|---|---|
|
Int32 |
Foreign key to entry in RC_IMS_DBD. Identifies the DBD on which these data apply. |
|
Int32 |
The pair of |
|
String |
The XDFLD Name field |
|
String |
The XDFLD segment field |
|
String |
The XDFLD SRCH fields are separated by a "," |
|
String |
The XDFLD SUBSEQ fields are separated by a "," |
|
String |
The XDFLD DDATA fields are separated by a "," |
|
String |
The index maintenance exit routine |
|
String |
The XDFLD NULLVAL field |
|
Int32 |
The pair of |
A.1.5. RC_IMS_DBD_ERR table
The RC_IMS_DBD_ERR table contains information regarding errors in the DBD parsing.
| Column | Type | Description |
|---|---|---|
|
Int32 |
Foreign key to entry in RC_IMS_DBD. Identifies the DBD on which these data apply. |
|
Int32 |
The pair of |
|
String |
DBD error type |
|
String |
Error message, including the cause of an error |
|
Int32 |
Always 0 |
A.2. IMS PSB repository
This section of the repository contains information extracted using IMSQL.psb
A.2.1. RC_IMS_PSB table
The RC_IMS_PSB table contains information regarding the PSB.
| Column | Type | Description |
|---|---|---|
|
Int32 |
The record identifier for PSB. RC_ID is the key of this record. |
|
String |
The PSB NAME field |
|
String |
PSB path |
A.2.2. RC_IMS_PSB_PCB table
RC_IMS_PSB_PCB table contains information regarding the PCB of the PSB.
| Column | Type | Description |
|---|---|---|
|
Int32 |
The foreign key to entry in RC_IMS_PSB. Identifies the PSB on which these data apply. |
|
Int32 |
The pair of |
|
String |
The DBD is associated with this PCB if the PCB is of type DB or GSAM. NULL otherwise. |
|
String |
The PCB type (DB, TP or GSAM) |
|
String |
The PCB PROCOPT field for DB PCB. NULL otherwise. |
|
String |
The PCB PROCSEQ field for DB PCB. NULL otherwise. |
|
String |
The PCB POSITION field for DB PCB. NULL otherwise. |
A.2.3. RC_IMS_PSB_SEGMENT table
RC_IMS_PSB_SEGMENT table contains information regarding the segment of the DB PCB.
| Column | Type | Description |
|---|---|---|
|
Int32 |
The foreign key to entry in RC_IMS_PSB. Identifies the PSB on which these data apply. |
|
Int32 |
The pair of |
|
String |
The segment name field |
|
String |
Always NULL. Not yet supported. |
|
Int32 |
The pair of |
A.2.4. RC_IMS_PSB_ERR table
The RC_IMS_PSB_ERR table contains information regarding errors in the PSB parsing.
| Column | Type | Description |
|---|---|---|
|
Int32 |
Foreign key to entry in RC_IMS_PSB. Identifies the PSB on which these data apply. |
|
Int32 |
The pair of |
|
String |
PSB error type |
|
String |
Error message, including the cause of an error |
|
Int32 |
Always 0 |