× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Mohammad,

I have seen so many "hopeless" discussions on this subject...

I am not aware of any tools that could migrate from RPG to some "portable"
SQL/CLI code and I can hardly imagine that it would possible of even
useful.
I understand some suggestions about reverse engineering tools, but from
what I know, those will only help to describe the current program
situation...
I have actually not seen any output easily usable as input in an SOA
design from the analysis of an application that has not been designed in
that way...

The main question in migration or evolution is not about tool or language,
it is about architecture implemented in the application...

If your application is monolithic and completely integrated in I5/OS and
relies on DB400, RPG language, OS facility (JOB number, name,, status,
current user..) any CL basic command (SBMJOB, CPYF,...) or OS facilities
(CALL QCMDEXC,...) it cannot be migrated: the application must be
rewritten...

This is the experience I can share:
I have been involved in the migration to "modern technology/Java" of an
application written for AS/400 (for which I was responsible) in the 90's
....these are the basic steps,
Please notice that it was only possible because the architecture of the
application was existing, described and flexible from the beginning.
This is how the application was designed architecturally back in 1990's
and implemented in RPG and CLP on the AS/400 platform...
a subsystem in running more than 35 tasks (any daemon is waiting
on a specific queue to do a specific task)
5250 interactive programs makes update of the database
5250 programs send requests to data queues and reads the result
back from data queues
batch jobs (or api's) sends requests to data queues
batch jobs produces result files or reports.

Over the years , we have been able to provide several versions to our
customers with ad hoc functionalities...
a TCP IP server receiving requests and sending from sockets and
interfacing with data queues
a Visual basic presentation application (Windows 95...) able to
exchange message using sockets with our applications... (rewritten to
windows 98; then W2K,... then abandoned...)
a WEB gateway able to receive CGI requests from an Apache Server
sending requests to data queue and building html responses from data queue
responses...
The database ha been migrated to SQL DDL and includes date fields,
null; fields and includes referential integrity (constrains, etc..°
(SQL/RPG migration at this step...)
a WEB application to update the parameters database
web services wrappers to data queues

We have then provided a standard Java application (running in an
application server websphere, Jboss,...) that
could update our parameter data base and has JMS beans doing the same
functionality than our batch jobs waiting on data queues...

To make the story short... the current interface has a rich XHTML
interface using full angularJs, Jquery, etc... can use any SQL data base
(including MS SQL, DB2fori, My SQL, Oracle)... runs in Any J2EE
Application server environments (Wbsphere, JBoss..) on any platform
(Wintel, Linux, IBMi, AIX, etc... ) ... NO longer RPG involded and no
platform dependency...

The key to achieve this has been the initial design.
If your application is written for IBMi regardless of any architecture
design and you want to migrate it to any other platform the only option is
rewrite...
If you have the architecture design... you can think about migrating any
component of your architecture using or proprietary, open components ...
If you do not have an architecture independent of the platform... my only
suggestion would be to start with that point....

Our experience with that application is that with the availability of an
application architecture it took us 20 years of continuous development
process, just to keep current...

In the same company I was working for, other applications are still
running in RPG on IBM i,.. they are still distributed and trying to have
some 'modern/accepted' interface and have tried Jwalk... RPG/OA,
Webfacing, Hats or other tools to adapt the interface to users
requirements... Most of customers are still using the 5250 interface and
the fact is that they are all declining... (but still have a strong
audience within the old AS/400 base...).. the global perception being that
the application is old and diificult to migrate....



thank you
kind regards
Paul





From: Mohammad Tanveer <surgum@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 11/01/2017 22:48
Subject: Re: Road Map to move a home grown application from RPG to
DB2 SQL or to any other data base platform
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



Thanks for your information. I will consider all of it.

My idea is to migrate RPG into SQL/CLI procedures on System i First; in
such a way that it is easily portable to another platform like db2 on
windows or SQL Server or Oracle. We have a home grown application
developed over 30 years of hard work..its becoming impossible to find new
generation and motivate them to work on RPG regardless of which flavor it
is.. New generation is coming out of school using SQL and its easy for
them to pick up SQL and support the application.

Re-writing 30 year old RPG code into java is an option too but I think it
will not be as efficient... it might even require a lot of software
engineering and might become difficult to support..





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.