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.
For more information about configuring or verifying the path and file name of the Synchronize Members Configuration File, see the Enable members synchronization option that is described Filling the IBM AD Build Client Install Configuration Page.
-
The configuration file must contain the following parameters. Among these parameters, <z/OS> is specific to a z/OS® context.
<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. The library type can be, for example,
PDS(MVS)
,Endevor
,SERENA CHANGEMAN BASELINE
, andSERENA CHANGEMAN PACKAGE
. - 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.Note: Enter this parameter only for the synchronization with a library or source control management tool that resides on z/OS.
- 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.
<Project name>, <Library type>, <Library name>, <Mapped virtual folder>, <Members type>, <z/OS>, <Application>
<Project name>, LOCAL_REMOTE, <Library name>, <Mapped virtual folder>, <Members type>, <Application>
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
ChangeMan Baseline- <PROJECT>, SERENA CHANGEMAN BASELINE, EZL.SERENA.SYNC.EZLX.COB, zOS Cobol, COBOL_MVS, zOSCONN, EZLX
ChangeMan Package- <PROJECT>, SERENA CHANGEMAN PACKAGE, EZLX000020, zOS Cobol, COBOL_MVS, zOSCONN
Available library and SCM types- PDS(MVS), Endevor, SERENA CHANGEMAN BASELINE, SERENA CHANGEMAN PACKAGE
LOCAL_REMOTE
line in the
configuration file, as it is shown in the following code:
<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
example: - 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>
- When using a filter. Note: Only the files that are matched by the filter are synchronized.Examples:
Where:<MyProject>, LOCAL_REMOTE, <C:\IBM AD\Mainframe Sources\Local Sources>, <zOS Cobol>, <COBOL_MVS>, filter<(*.cbl|*.cob)>
*.cbl
- only the COBOL files that have the*.cbl
extension are synchronized.*.cob
- only the COBOL files that have the*.cob
extension are synchronized.
Where:<MyProject2>, LOCAL_REMOTE, <C:\IBM AD\Mainframe Sources\Local Sources>, <zOS Cobol>, <COBOL_MVS>, filter<(a*|*b>
a*
- only the files that start with letter a are synchronized.*b
- only the files that end with letter b are synchronized.
- 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 Procedures 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 Validation Server configuration files (for coding rules enforcement with ChangeMan)
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
<type>,<type1>,….<typen>
FoldersMapping.txt
<Member Type>,<Logical folder>
ServicePort.txt<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.
- 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:
- Create a Container AD project.
- 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:
- Create an AD project Project1 that is used for analysis and other AD capabilities.
- 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>
- Use Synchronize Members feature.