Using SYNCSORT (or DFSORT) to Automate Mainframe Code Migration

My development team was involved in a project years ago that required migrating 200 Configuration Items (CI's) such as JCL, PROC, SYSIN Cards, Source code, DBRMLIB members, Loadlib members, not to mention running BIND Packages on DB2 programs. The scarier part is that the migration needs to be done in a day. Our installation does not have a tool to help us migrate CI's so everything had to be done manually.

The way we did this before this project was to keep a list of CI's to be migrated and days before migration, we would prepare the JCL, two people will go through the list, making sure that all the CI's are listed.

With the risks involved, I needed to come up with a way to make sure all the CI's are migrated correctly and accurately. I figured that if I can keep a list of the items to be migrated, from what PDS's, and the dependent components to be migrated, and then use that list to generate a JCL to migrate the components, I can use that list through the SDLC process.

Enter SYNCSORT (or DFSORT)

I kept a list of the items as a flat file. The process at that time was quite crude because I was not familiar yet with the power of SYNCSORT. The list of items had the source PDS, the member. Based on the PDS name, the job will generate JCL to perform other functions.

For example, if it was a SYSIN card, then the generated job will copy the member from source PDS to target PDS using IEBCOPY. If it was a source, the generated job will copy the source, copy the Loadlib member, copy the compile listing, and if it was a DB2 program, copy the DBRMlib member and do a BIND Package.

Advantages of this approach. The advantage of this approach is that if you keep the list during development and used this to migrate to test, you would have also tested your list of CI's to be migrated, so that once you are ready to deploy to Production, you know you have the complete list of CI's to be deployed and also the corresponding processes needed to make the deployment correct. There is no more room for the migrator to forget doing a step because everything is generated correctly.

Deployment Day

Another advantage of this approach also is the migration JCL is generated the day before and you can review the JCL to make sure everything is right. When we planned for this project, we allotted about 1 day for the migration. On Deployment day, the entire migration took about half an hour and that includes verification that all items were migrated properly and succeeding steps were performed.


If you wish to know more about this process, feel free to contact me.