By Madhur Arya.
My last blog discussed the challenges faced in z/TPF migrations by companies worldwide and the ways to overcome them. In this concluding part, I will present a detailed z/TPF migration approach and share some best practices for a smooth z/TPF migration.
A z/TPF migration approach
Migration to z/TPF involves several tasks right from careful planning to rigorous testing of the complete solution before the actual implementation. Migration is not just porting of applications to a different platform but instead, requires a robust and extensive project planning to ensure successful final implementation.
The phases involved in z/TPF migration are:
- Planning Phase – In the Planning Phase, the team defines the solution in detail: what to build, how to build it, who will build it, and when will it be built. Migration Planning requires the following key action items:
- Sound Documentation – All the hardware, software tools including the ones that are currently used but will no longer be supported by the new system, followed by identification of the future requirements as well
- Requirement Understanding – Any new hardware and software requirements, network requirements, new or changed data set requirements
- Identification of Changes – Identification of Interface modification such as changes to commands and messages that will affect the automation procedures may be required
- Environment Preparation – This is basically the identification of the migration tasks that would be done to the existing TPF 4.1 system and TPFDF 1.1.3 product before receiving the z/TPF system and z/TPF-DF product
- Receipt of Packages – – Packages are a group of segments related to specific functionalities which are received from the client.
- Remediation –Remediation is the process to make the code z-compliant.
- Tool Kit Usage – IBM TPF Toolkit converts the application source code from TPF 4.1 system to single source for z/TPF system. The TPF Toolkit can scan Assembler, Sabretalk and C/C++ language source and identify problems that would prevent the user from having a single source code. This tool is capable of detecting migration issues and can also fix them automatically. This happens when the tool has detected a problem with 100% accuracy.
- Manual Checks – In some cases where the IBM TPF Toolkit can detect migration issues but the errors cannot be fixed automatically; a manual fix is required.
- Testing/UTD (Unit Test Definition) – Testing is the key to success. The test strategy should have following considerations:
- Preparation of various test plans such as integration, system and regression
- Test high-exposure operations & application programs
- Test the utilities
- Perform system test, regression test & network test
- A separate UTD team is created which assists the development team by preparing tailor-made test scenarios to ensure that the modified code is executed.
- 3 Level Reviews –To ensure a fool-proof review, a detailed code review checklist is prepared and enhanced regularly for thorough reviews. Reviews are done at 3 levels to ensure accuracy of the delivery.
- Offshore reviews
- Onsite reviews
- SME reviews
- Regression testing – Regression testing is done to ensure that the current business logic still works with the new changes.
- Go Live – After completion of testing & reviews, the code is loaded to the production.
- Fall-back Plan – Planning for a fall-back is as important as looking forward to a successful implementation. What happens if it is decided to roll-back to TPF 4.1? Would it be simply about switching the traffic back to 4.1 or something more than that? A rollback process to revert to the TPF4.1 environment therefore needs to be in place.
Best practices for z/TPF Migration
- Follow a Check list – There should be a check list including activities like the version contention, proper manual checks, ASM to C file calling, code comparison, obsolete code deletion from the files & files clean-up which should be cross checked before the file is moved to copy (pre-prod) system.
- Manual Checks – Recurring issues occur in the memcpy (in C files, copying the data from one field to another field), where 8 byte data is moved to 4 byte data or vice versa. Each file needs to be manually checked & taken care off. This exercise reduces the defect counts significantly.
- Review processes (3rd level review for complex files) – The files which are not tested due to complex nature of entries or procedures should be followed for a 3rd level review.
- Regression testing – Regression testing should be done when files comes to the copy system. This would further reduce the risk of getting the dump on PROD system.
- Impact Analysis Sheet (taking an approval from the BAU-other functional teams) – All the files going on production system should be sent to other functional teams, so that they verify their functionality changes if any.
- Upload Test cases on ALM or similar (repository for future reference)- Test cases should be uploaded to ALM, so that they can be referenced anytime when required
- Guidelines – Guidelines should be compiled and shared with the team for PRE Environment and Toolkit usage
- Identifying Technical Issues – z/TPF environment specific technical issues need to be identified from PRE migration (i.e. CALOC, GLOBZ and memory instructions) . The experience would also prove useful in remediating other cores to reduce run time issues to minimum.
Making the move to z/TPF is a critically important undertaking for any business that is reliant upon transaction processing. Following the best practices mentioned above will ensure that the migration project is smooth, timely, safe and successful.
About the Author
Madhur Arya is the CoE practice head for the TPF practice at IGT. Madhur holds a Bachelor of Technology degree from the University of Kurukshetra and has 15+ years of IT experience. He has been focussing on continuous improvement and implementing accelerators for development, maintenance and migration projects in the ALCS/TPF area. He can be reached at Mktg@www.igtsolutions.com