In the constantly evolving world of technology, the need to adapt and progress is a steadfast necessity. For businesses that depend on development tools like Synon, which struggle to keep up with rapid changes, a critical question arises:
- how to leave this development environment while preserving the developed applications,
- and how to maintain these applications and make them evolve in a modern environment?
Such a transition is not merely a technical undertaking; it also hinges on the ability to revamp the development process with teams whose knowledge and expertise are essential for the longevity of the applications.
Deciding to phase out Synon wasn’t a spur-of-the-moment decision; it was a calculated move to address both technical needs and human considerations—such as the retirement of pivotal staff, the scarcity of professionals skilled in maintaining these systems, and the challenge of attracting new talent to outdated tools.
Consider the experience of Geodis, a global powerhouse in transport and logistics, which found itself navigating these intricate issues. Guided by Hugues Clement, Solution Center Manager in the Logistics IT Department, and in partnership with ARCAD Software, they embarked on a significant transformation.
You might be curious about how this was all executed in practice. How did the team handle the complex shift to adopting RPG and DSPF/PRTF structures? What challenges and breakthroughs were encountered along the way?
1. The Synon heritage at Geodis: Complexity and the need to transition to sustainable development tools and methods
Geodis faced a significant challenge with the Synon CASE tool, which had stagnated technologically. The dwindling number of experts familiar with this CASE Tool, coupled with its diminishing appeal to the new generation of developers, prompted Geodis to seek a transition to newer programming languages. This shift also aimed to preserve two decades’ worth of development work.
As part of its logistics operations, Geodis utilizes an application originally developed with SYNON to manage portions of its logistics sites, spread across two production servers that hosted about forty different environments.
This complexity made the transition to other tools even more necessary and sensitive, with the capacity to maintain previous versions by integrating newly developed or modified components.
Following an initial failed attempt to switch from Synon to an alternative CASE tool, Geodis opted for a migration that conformed to IBM i standards, namely Free Form RPG and SQL. This move would not only ensure operational continuity but also leverage advancements in development languages and tools. Free Form RPG represented a more approachable option for developers accustomed to CASE tools, compared to earlier versions of RPG (3 / 4…).
2. Training and adaptation: Moving from Synon COBOL to Free Form RPG on IBM i
The Geodis team, consisting of seven Synon developers, brought varied experiences to the table. Two members had proficiency in “3GL” (C++, COBOL) in addition to Synon, whereas the rest were solely versed in Synon COBOL. With decades of Synon experience under their belts, it was crucial for the entire team to commit to the migration project — crucial for their application’s future and a substantial leap to regain developmental proficiency.
Adopting Free Form RPG on IBM i presented several hurdles: acclimating to a new development environment (RDi, Rational Developer for i), deciphering migrated code (particularly for the interactive part, for which the CASE tool generated a large part of the code), understanding “ILE” concepts (modules/service programs), and managing prototypes and SQL cursors.
Prior to the code migration, the team undertook an intensive three-week training program focused on Free Form RPG, RDi, SQL, and ARCAD for DevOps (for version, source control, and delivery management).
Post-training, the developers embarked on their Free Form RPG development journey, prudently beginning with maintenance projects before addressing more complex tasks. For the initial six months, Synon was retained as a reference tool, serving as a safety net in case of difficulties in finding the treatment synopsis. The team recognized that a complete break from Synon would be achieved after this period, marking a pivotal moment in their developmental evolution.
Geodis’s migration strategy involved preserving the long names of Synon data, thereby avoiding the use of the database’s abbreviated names. This facilitated field identification post-migration, eliminating the need to acquaint themselves with over a thousand tables and simplifying the transition from Synon to RPG in terms of code interpretation.