Can Synon developers become RPG Free Form developers?

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 RPG Free Form and SQL. This move would not only ensure operational continuity but also leverage advancements in development languages and tools. RPG Free Form 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 RPG Free Form 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 RPG Free Form 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 RPG Free Form, 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.

3. Synon features missing in RPG

As the Geodis team ventured into writing interactive RPG programs, they immediately noticed a gap where Synon’s features used to be. The productivity levels they were accustomed to with Synon, particularly for interactive tasks, took some time to replicate in RPG.

1. DSPF screen management

Here, CASE tools like Synon had shown their strength, automating much of the coding process. In contrast, RPG development required a hands-on approach right in the source code for the components.

In other words, this was the only area where the “missing functionality” was felt by the team in the new development environments.

2. Data management based on repositories

Synon works on the basis of data repositories, with a table-based approach at development tool level, including lists of associated components.

This repository functionality isn’t native to RDi, presenting a hurdle given the application’s extensive component count, which included over 37,000 items between programs and functions. Initially, this shift posed a considerable challenge.

To address this, Geodis retained the table names in the descriptions, streamlining the process of locating functions related to specific tables.

Moreover, it’s also possible to emulate this feature with data directories using ARCAD For DevOps.

4. Advantages of Transitioning to Free Form RPG

Despite initial hurdles, the transition to RPG Free Form has been decidedly advantageous, a sentiment echoed by Hugues Clement, who underscores the numerous benefits:

1. Increased productivity and ease of maintenance

• Easier handling: The use of RPG Free Form has accelerated and streamlined development processes, especially with string handling and built-in functions. It simplifies date and time management, which are crucial for Warehouse Management Systems (WMS), thanks to data type conversions.

• RDi (Rational Developer for i) benefits: RDi has transformed the development experience, offering ease of use, additional features, and debugging tools. The difference from the SYNON environment is like night versus day.

• Simplified queries by SQL: Transitioning to SQL has facilitated simultaneous access to multiple tables, making complex queries more straightforward. SQL’s ability to manage XML and JSON data has also eased interactions with other systems, unlike the single-table data access approach of Synon.

• Reduced recompilation time: When a procedure or function is modified, only the module in which it is defined needs to be recompiled. This efficiency is due to the ‘Smart Build’ feature in ARCAD for DevOps, significantly reducing recompilation time especially for large programs.

• Minimization of code changes during updates: The decision to migrate SYNON internal functions linked to tables in service programs (CRTOBJ, CHGOBJ, DLTOBJ, RTVOBJ) facilitates maintenance, as you only need to modify them, and this modification is propagated to all processes using them. With Synon, it was necessary to regenerate all the processes with potentially modified components.

• Improved code readability: Procedures and functions can improve code readability by grouping similar blocks of code into separate code units. This makes the code easier to understand and can help identify errors.

• Parameter flexibility: With Synon, adding a parameter to a function meant modifying all the programs calling it, even if the new parameter was not needed in the processes calling it. In RPG Free Form, the “No-Pass” option makes parameters optional, reducing the need for global code modification.

• Publishing programs (PRTF): With Synon, printouts containing several tables generated complex code. In RPG Free Form development, the code is simpler, making maintenance much easier.

• Table management: Managing tables with Synon generated complex code based on table-type functions (CRTOBJ…). With RPG Free Form, code and handling are simplified.

2. Application sustainability

• Successful pre-hiring of young developers: RPG Free Form’s resemblance to contemporary languages such as JavaScript has made it more attractive to the younger generation of developers, ensuring the sustainability of both the applications and the development team.

• Opening up new development opportunities: The move to RPG Free Form has not only simplified development processes but also expanded connectivity across diverse applications, whether on IBM i or other platforms. This enhancement is particularly beneficial for web-based environments and for XML/JSON integrations, as well as for improving customer interface interactions.

5. Strategies for a successful transition from Synon to Freeform RPG development

According to Hugues Clement, there’s no reason to hesitate in making this transition from Synon development to RPG Free Form development. One year after its implementation, he’s observed a notable boost in the team’s productivity and satisfaction, and the journey doesn’t end here.

The team adopted a continuous modernization approach, eyeing DevSecOps by integrating source code management tools like Git, facilitated by ARCAD for DevOps. This toolset paves the way for a seamless integration into modern development standards.

Post-transformation, the team is confidently facing the future, now evolving in a “state of the art” development environment on IBM i, and wouldn’t turn back for anything in the world!

Key tips for a successful transition

• Engage the team from the outset: Involve your team from the beginning, utilizing their input to shape the transition strategy to fit your existing applications.

• Strategic planning: Plan the transition carefully, avoiding overlap with major development projects that could add complexity.

• Timely training: Train developers as close as possible to the transition. Premature training without immediate practical application can reduce its effectiveness.

• Test with a Proof of Concept (POC): Conduct a POC with basic knowledge to confirm the viability of the new approach before full-scale implementation.

• Communication and collaboration: Promote transparent dialogue and collective problem-solving within your team, particularly if skill levels vary.

• Support from the vendor: Don’t hesitate to request assistance from the software vendor to overcome any challenges that may arise.

Following these recommendations can provide organizations with a clear pathway through the challenges and opportunities of such a pivotal transition.