This Document Describes Recommended Naming Conventions for Optim Objects (E.G. Access

This document describes recommended naming conventions for Optim objects (e.g. Access Definitions, Extract Requests, etc.) and output files from Optim processes (e.g. Extract files, Convert files, etc.). These conventions are contained in two sections – Mainframe and Distributed Systems. Functional examples that can be applied to both platforms are found at the end of the “Distributed Systems” section.

Depending on the platform and database, it may be necessary to abbreviate certain entries. For example, some of these standards recommend using “table name” as a value, but that field is limited to 12-bytes. Using that example, it is necessary to abbreviate table names longer than 10-bytes to satisfy the limitation of the field length (2-bytes are reserved by the standard)

Also, Optim objects all allow for a 40-byte description in the Optim directory. These Description Fields of an Optim Artifact should be used rigidly to contain as much relevant information as possible. Descriptions appear in the object information displays on both the mainframe and distributed versions of Optim.

At a minimum the description should reflect (in unabbreviated form) the same information as the name. Next it should have the initials of the creating Optim user and the Optim User who was last to modify the artifact. Finally, depending on the nature of the object, additional information should be stored in the description such as the number of tables, number of steps and number of cycles in the case of Access Definitions. Mainframe

Access Definition (AD): applicationhlq.DMVnnRnn.starttablenn

Standard:

1. For the first node, “applicationhlq” (8-bytes) use the preponderate HLQ associated with the application. 2. The second node is 12-bytes. “DM” is the project (Data Masking); “V” is version; “nn” is the version number; “R” is release; and “nn” is the release number. a. This allows the flexibility of building additional ADs within the same PST using the same table names, but with different creator names and/or relationships b. Using this convention simplifies troubleshooting and testing of changes to ADs c. Allows easy testing of different masking strategies w/o affecting the original 3. The last node (12-bytes) is the name of the “start table” specified in the AD. The two digit number (“nn”) allows the same start table to be used in multiple ADs within the same version and release (specified in the second node of the name).

Table Map (TM): applicationhlq.starttablenn

Standard:

In order to use an extract file (which is created using an AD) a TM is required. This standard matches the TM name as closely as possible with the name of the AD.

Column Map (CM): applicationhlq.tablenamenn

Standard:

1. For the first node (8-bytes), using “applicationhlq” matches the application to which the CM belongs, back to the TM (which also matches back to the AD) 2. For the second node (12-bytes), CMs are specific to tables. This standard uses the “tablename” that will be masked by the CM. The “nn” is used to distinguish between multiple column maps for the same table a. simplifies testing of new versions and releases b. Allows testing of new masking techniques without affecting the original CM Legacy Table Definitions ddname_nnn

Standard:

Legacy data stores have names up to 44-bytes in length. Optim allows an 18- byte name that must be in “DB2 like” syntax. Assuming that a ddname (or similar identifier) is used for all legacy tables, this is a good choice. The “nnn” is a requirement because any legacy data store that has multiple copybook definitions must have a separate legacy table definition for each “01 level” in the copybook(s).

Extract File Naming Conventions applicationhlq.DMVnnRnn.starttable.SNnn.XF(+1)

Standard:

1. Nodes for mainframe data stores are limited to 8-bytes each (total length of 44-bytes [35-bytes for a GDG]). 2. The second node maintains the version naming schema from the AD 3. The third node is “starttable”. This will cross-reference the extract back to the AD. However, the “start table” name in the AD was up to 10-bytes (12 – 2 for “nn”). It must now be further abbreviated down to 8-bytes. 4. The “nn” for the start table was retained in this fourth node (should match the “nn” in the AD) 5. The fifth node identifies the file as an extract file (XF) GDG “(+1)” recommended for batch processing

Convert File Naming Conventions * applicationhlq.DMVnnRnn.starttable.SNnn.XFC(+1)

Standard:

1. Nodes for mainframe data stores are limited to 8-bytes each (total length of 44-bytes [35-bytes for a GDG]). 2. The second node maintains the version naming schema from the AD 3. The third node is “starttable”. This will cross-reference the extract back to the AD. However, the “start table” name in the AD was up to 10-bytes (12 – 2 for “nn”). It must now be further abbreviated down to 8-bytes. 4. The “nn” for the start table was retained in this fourth node (should match the “nn” in the AD) 5. The fifth node identifies the file as a converted extract file (XFC) GDG “(+1)” recommended for batch processing Control File Naming Conventions applicationhlq.DMVnnRnn.starttable.SNnn.CF(+1)

Standard:

1. Nodes for mainframe data stores are limited to 8-bytes each (total length of 44-bytes [35-bytes for a GDG]). 2. The second node maintains the version naming schema from the AD 3. The third node is “starttable”. This will cross-reference the extract back to the AD. However, the “start table” name in the AD was up to 10-bytes (12 – 2 for “nn”). It must now be further abbreviated down to 8-bytes. 4. The “nn” for the start table was retained in this fourth node (should match the “nn” in the AD) 5. The fifth node identifies the file as a control file (CF) 6. GDG “(+1)” recommended for batch processing Distributed Systems

DB Alias (DBAlias): (12-Bytes)

Name Standard: AAAADDDDE#DB

1. 4 characters for application abbreviation 2. 4 characters for database abbreviation 3. 1 character for environment (e.g. D – dev, T – Test, I – Integration, P – Production) 1 character for environment increment (e.g. 1, 2, 3) 4. 2 characters for DBMS:  D2 – DB2  OR – Oracle  SS – SQL Server  SY – SYBASE  IM – IMS  IX - Informix

Access Definition (AD):

Name Standard: applicationname.starttablenn

1. For the first node, “applicationname” (8-bytes) is more suitable than “database name” because applications may use more than one database 2. The last node (12-bytes) is the name of the “start table” specified in the AD. The two digit number (“nn”) allows the same start table to be used in multiple ADs within the same application

Description Standard: applicationname starttable - t#tabless#stepc#cycles – CNM/RNM

1. The Description Field of an Optim Artifact should be used rigidly to contain as much relevant information as possible. Descriptions (40-bytes) appear in the Explorer-like interface in Optim when File->Open is picked from the launch window. 2. At a minimum it should reflect (in unabbreviated form) the same information as the name. Next it should have the initials of the creating Optim user and the Optim User who was last to modify the artifact. Finally, in the case of Access Definitions and the Archive and Extract Requests that use the Access Definitions, the number of tables, number of steps and number of cycles should be noted in the form t<#table>s<#steps>c<#cycles>. For example if an AD contained 50 tables and indicated 35 steps including 3 cycles in the Show Steps display then the notation would be t50s35c3.

Table Map (TM):

Name Standard: applicationname.starttablenn In order to use an extract file (which is created using an AD) a TM is required. This standard matches the TM name with the name of the AD. Column Map (CM): applicationname.tablenamenn

Standard:

1. For the first node (8-bytes), using “applicationname” matches the application to which the CM belongs back to the TM (which also matches back to the AD) 2. The last node is 12-bytes. CMs are specific to tables. This standard uses the “tablename” that will be masked by the CM. The “nn” is used to distinguish between multiple column maps for the same table a. Simplifies testing of new versions and releases b. Allows testing of new masking techniques without affecting the original CM

Extract Request: applicationname.starttablenn

Standard:

1. For the first node (8-bytes), using “applicationname” matches the extract request with the same application name used for the AD. 2. The last node (12 bytes), matches back to the AD associated with the request

Convert Request: * applicationname.starttablenn

Standard:

1. For the first node (8-bytes), using “applicationname” matches the convert request with the same application name used for the AD. 2. The last node (12 bytes), matches back to the AD and TM associated with the request

Insert and Load Requests: applicationname.starttablenn

Standard:

1. For the first node (8-bytes), using “applicationname” matches the insert or load request with the same application name used for the AD and TM 2. The last node (12 bytes), matches back to the AD and TM associated with the request Extract File Naming Conventions applicationname.starttablenn_MMDDYY_SEQ.xf

Standard:

1. For the first node (8-bytes), using “applicationname” matches the extract request with the same application name used for the AD. 2. The second node is “starttablenn”. This will cross-reference the extract file back to the AD. 3. Third node should be a date generated using Optim Macros follow by a sequence number. This is achieve as follows: a. <$MM $DD $YY _ $SEQ>.xf 4. An extension of “xf” is required

Convert File Naming Conventions * applicationname.starttablenn_optionaldescriptor_conv.xf

Standard:

1. For the first node (8-bytes), using “applicationname” matches the extract request with the same application name used for the AD 2. The second node is “starttablenn”. This will cross-reference the extract file back to the AD and TM 3. An optional third node may be used as a supplemental descriptor if necessary 4. The fourth node (or third in the absence of the optional node) identifies the file as a converted extract file (conv) 5. An extension of “xf” is required

Control File Naming Conventions applicationname.starttablenn_optionaldescriptor.cf

Standard:

1. For the first node (8-bytes), using “applicationname” matches the extract request with the same application name used for the AD, TM, and CM 2. The second node is “starttablenn”. This will cross-reference the extract file back to the AD and TM 3. An optional third node may be used as a supplemental descriptor if necessary 4. An extension of “cf” is required Functional Examples

The global insurance giant – Big Insurance Company, is required to mask customer confidential information in their test systems. The first application chosen for masking (Big Life) processes life insurance. There are two tables:

 Customer_Profile  Customer_Medical_Records

The follow names were used for Optim objects and files:

 AD: biglifet.cust_prof01  TM: biglifet.cust_prof01  CM: o biglifet.cust_prof01 o biglifet.custmd_rec01

 Extract Request: biglifet.cust_prof01  Extract File: biglifet.cust_prof01_101909_145.xf

 Convert: biglifet.cust_prof01  Convert File: biglife.cust_prof01_conv.xf  Control File: biglife.cust_prof01.cf

 Insert / Load Requests: biglifet.cust_prof01  Control File: biglife.cust_prof01.cf

After the masking project, Optim was used to extract subsets of data from Big Life to populate a test environment for a new product – Big Big Life.

 AD: biglifet.cust_prof02  TM: biglifet.cust_prof02  CM: o biglifet.cust_prof01 o biglifet.custmd_rec01

 Extract Request: biglifet.cust_prof02  Extract File: biglifet.cust_prof02.xf

 Insert / Load Requests: biglifet.cust_prof02  Control File: biglife.cust_prof02.cf

* Note: Convert processes used primarily for testing (i.e. ensuring that the Optim process works correctly prior to loading tables from an unmasked extract file (.xf).