Synchronize Members Configuration File Examples

The configuration file is intended to instruct IBM® AD Build Client on whether it needs to update against specific libraries, where to add/remove the related members in/from the project (that is, which virtual folder to use) and also which type of members IBM AD Build Client must use when you add members. The basic assumption is that the specified libraries do not contain members that do not have to be added even though they are there.

Note: It is highly recommended to use one single version of your source code per project in IBM ADDI. If you want to analyze two versions of source code, use two different projects in this case. For example, supposing that you plan to load in IBM ADDI and analyze one COBOL program of two versions (one is currently found in a Production PDS Library, while the other is in a Development PDS Library), you need to have two separate projects for those versions instead of adding both versions of the program into the same ADDI project.

The configuration file must contain the following parameters:

<Project name>, <Library type>, <Library name>, <Mapped virtual folder>, <Members type>, <z/OS> ,Application

Project name
The name of the project that needs to be synchronized with the mainframe system.
Library type
The type of the library from which members are added.
Library name
The name of the library against which the synchronization takes place.
Mapped virtual folder
The name of the project folder where the members are added/updated/deleted.
Members type
The type of the members that are synchronized. The allowed types are presented in the Member types names table.
z/OS®
The name of the connection to the mainframe system, as defined in the zOS tab of the IBM Application Discovery Build Configuration window. For more information, see The zOS Tab.
Application
The name of the application as defined for ChangeMan ZMF in zOS Configuration screen.

Examples for creating configuration files based on Library types

Following are some examples for configuration files, based on Library types.

Note: Each line in the configuration file must contain a unique <Project name>, <Library type , <Library name>, <Mapped virtual folder>, <z/OS> tuple. If not, the configuration file is invalidated. Also, if the synchronization process runs for more than one Library/Project, a unique line must be added for each project that needs synchronization.

To comment a line in the configuration file, add * at the beginning of that line.

PDS Library- <PROJECT>, PDS(MVS™), ITLS.COBOL.II, zOS Cobol, COBOL_MVS, zOSCONN

Endevor- <PROJECT>, Endevor, SMPLTEST.EZLPROJ.EZLCOMP.COBOL.T, zOS Cobol, COBOL_MVS, zOSCONN

Start of changeChangeMan BaselineEnd of change- <PROJECT>, SERENA CHANGEMAN BASELINE, EZL.SERENA.SYNC.EZLX.COB, zOS Cobol, COBOL_MVS, zOSCONN, EZLX

Start of changeChangeMan PackageEnd of change- <PROJECT>, SERENA CHANGEMAN PACKAGE, EZLX000020, zOS Cobol, COBOL_MVS, zOSCONN

Available library and SCM types- PDS(MVS), Endevor, SERENA CHANGEMAN BASELINE, SERENA CHANGEMAN PACKAGE

The synchronize process against Local/Remote Folders is supported. Each line in the configuration file must contain:
Project name in IBM AD Build Client, LOCAL_REMOTE, Full path of the folder where the sources exist, Virtual folder in IBM AD Build Client, Members type within Virtual Folder, (optionally) Filter the files found in the source folder (search criterias are separated by | )
For examples:
  1. When not using a filter.
    Note: The entire folder's content is synchronized.
    MyProject, LOCAL_REMOTE, C:\IBM AD\Mainframe Sources\Local Sources, zOS Cobol, COBOL_MVS
  2. When using a filter.
    Note: Only the files that are matched by the filter are synchronized.
    Examples:
    MyProject, LOCAL_REMOTE, C:\IBM AD\Mainframe Sources\Local Sources, zOS Cobol, COBOL_MVS, filter(*.cbl|*.cob)
    Where:
    • *.cbl - only the COBOL files that have the *.cbl extension are synchronized.
    • *.cob - only the COBOL files that have the *.cob extension are synchronized.
    MyProject2, LOCAL_REMOTE, C:\IBM AD\Mainframe Sources\Local Sources, zOS Cobol, COBOL_MVS, filter(a*|*b)
    Where:
    • a* - only the files that start with letter a are synchronized.
    • *b - only the files that end with letter b are synchronized.
  3. Member types names
    Virtual Folder FileTypeName
    AAuto Scheduling AAUTO_SCHEDULING
    AAuto Scheduling AAUTO_DS_FLAG_REPORT
    ADS Dialog ADS_DIALOG
    ADS Map ADS_MAP
    ADS Process ADS
    Assembler ASSEMBLER
    Assembler Include ASM_INCLUDE
    Assembler Macro ASM_MACRO
    BMS BMS
    Cobol IDMS COBOL_IDMS
    Cobol IDMS Record COBOL_IDMS_RECORD
    Cobol Include COPY
    Configuration CSD
    Configuration IMST_PGM
    Configuration JCL_PGM
    Configuration PGM_ALIAS
    Data Area LDA
    DBD DBD
    IMS Map MFS
    JCL JCL
    JCL Control files JCL_CTRL
    JCL Include JCL_INCLUDE
    JCL Processes JCL_PROCLIB
    Log LOG
    MQ MQ_CONFIG
    Natural NATURAL
    Natural Include NATURALINCLUDE
    Natural Map NATURALMAP
    PL1 PL1
    PL1 IDMS Record PL1_IDMS_RECORD
    PL1 Include PL1_INCLUDE
    PSB PCB
    Schema SCHEMA
    Subschema SUBSCHEMA
    zOS Cobol COBOL_MVS
    PreProc Before EXTENS_PREPROC_BEFORE
    PreProc MetaData EXTENS_PREPROC_META
    PreProc Config EXTENS_PREPROC_CONFIG

Examples for validating configuration files

Following are some examples for the validation of configuration files.

ProjectMapping.txt

This file is the configuration file for defining the Project Name, Serena Application Name, and the Subsystem that is used for the validation process. Valid means that the format is correct and the Project does exist.

<Project Name>, <Serena Application Name>, <Subsystem> (comma separated values)

IncludesOrder.txt

This file is the configuration file for defining the Baseline Libraries types and the order, of Cobol Includes locations. This configuration file is used later on while you set up the path for the Cobol Include folders. 
<type>,<type1>,….<typen>
Note: It is EXTREMELY important to add the types in the order in which the include files must be looked after.

FoldersMapping.txt

This file is the configuration file for defining a mapping between a Logical Folder of the project and the type of a member that is part of the validation process. This configuration file is used during the validation stage of the Synchronize Members process.
<Member Type>,<Logical folder>
ServicePort.txt
This file is the configuration file for defining the Service’s port. If you use a firewall, make sure that the port is added as an exception.
<Port Number>

Examples for synchronizing members based on type

Following are some examples for the synchronization of members based on type.

If you have more than one member type in the same PDS Library/Directory, you can synchronize the members depend on the type. AD Build Client now can automatically determine and distribute each member in its correspondent AD project logical folder.

Take this case as an example. A PDS Library that contains Assembler and COBOL source code files (members) exists, and you need to use the source code in an AD Project. In the 6.1.0 or earlier versions, members need to be manually identified and added in the AD project to their corresponding logical (virtual) folder. Depending on the number of members, this task might be time-consuming. Moreover, if one or more members are updated or deleted on the mainframe, the maintenance can be challenging.

Starting with 6.1.1 version, you can use this feature to automatically determine and add the source code files to AD project by type.

You can use this feature with the following cases.
  • A Container AD project needs to be created, and the Container project will be used to retrieve PDS Libraries that contain multiple mainframe member types in bulk. In this case, you can follow these steps:
    1. Create a Container AD project.
    2. Add configuration parameters in the sync file, and use the Synchronize Members feature on the Container project. For example,
      Container,PDS(MVS),[YOUR PDS LIBRARY WITH MULTIPLE MEMBER TYPES],zOS Cobol,COBOL_MVS,[zOS endpoint attached to project NAME]
  • A conventional AD project Project1 is created, and all the members that are retrieved in the Container project now can be automatically distributed in the logical folders of Project1 by their type. You can use the synchronize process against local folder where the mainframe members of the Container project are located. In this case, you can follow these steps:
    1. Create an AD project Project1 that is used for analysis and other AD capabilities.
    2. Add configuration parameters for local synchronization of all source code file types. For example,
      Project1,LOCAL_REMOTE,[PATH TO YOUR LOCAL FOLDER WHERE CONTAINER PROJECT MEMBERS WERE RETRIEVED],zOS Cobol,COBOL_MVS,filterByType
      Project1,LOCAL_REMOTE,[PATH TO YOUR LOCAL FOLDER WHERE CONTAINER PROJECT MEMBERS WERE RETRIEVED],ASSEMBLER,ASSEMBLER,filterByType
    3. Use Synchronize Members feature.