AS400 Supporting Tools
Support & Modernization
AS400 iSeries Support & Modernization Offshore iSeries/AS400 software support
G&G’s AS400 iSeries RPG, ILE, Synon, COBOL Programmers-Developers helping in AS400 Modernization & Migration
The reasons businesses want to migrate are as follows
- Reduce the costs of supporting their iSeries RPG application software and hardware
- Move away from RPG, with its shrinking pool of resources, to a modern approach using .Net
- Integrate .Net capabilities with their AS400 or iSeries
User Interface – Screen Modernization of AS400 / iSeries RPG Applications
New interfaces of AS400 are the most visible result of most modernizations. There are mainly two types of screen modernization approaches
Screen Scraping
The screen-scrapping concept gained popularity in the iSeries world way back in the early 90’s. The developing scalable client server applications for the iSeries was then quite difficult. So it was the most effective method for putting a front end on iSeries applications in MS Windows. Over time, the screen scraper vendors evolved to a new model. The 5250 I/O stream between your application and browser was intercepted, analyzed and mapped to new web based screen components. Although this approach was quite popular several years ago it is no longer a common approach as it is very complex to maintain and inflexible.
True Web Pages
This approach creates true web pages (ASP, JSP, PHP) by analyzing display files and RPG application code and creating true web pages that run in a web (or client server) environment such as Microsoft .NET or Java. These use web and application servers just like any other newly developed applications. Their advantage is that they are flexible and highly maintainable. Also they use standard technologies and development techniques that can be maintained by any developer.
Synon, CL, RPG Application
Existing RPG programs and iSeries applications like CL, COBOL and Synon applications have a dramatically different structure than modern object oriented applications in C#, Visual Basic and Java. While the new architecture may still contain some artifacts of the old architecture, it is typically vastly improved and more maintainable.
DB2/400 Database Conversion
Several options exist for DB2/400 database conversion
Native Relational Database:
Here the native DB2/400 schema is mapped to a true relational database schema. Existing physical and logical files are mapped onto appropriate relational database tables and mapping relationships using primary and foreign keys. During this conversion the database keeps a mapping of the DB2/400 to relational model to which acts as a guide when the appropriate SQL codes are generated.
As part of this conversion process, the appropriate database creation code (DDL) would automatically be generated. This DDL could then run to create the new relational database prior to transferring of data from the DB2/400 database to the new relational database.
Database Gateway
In some cases, it may be desirable to leave the DB2/400 database intact, and provide a gateway that interfaces with the iSeries database on one side, and provides a full relational access model (using standard SQL statement) on the other. This enables modernized applications to access the DB2/400 database without any modifications to the database – leaving it running on the iSeries and using it as a powerful database server. The advantages of this approach are several:
You continue to harness the power and stability of the iSeries as a database server
No changes to the database or reloading are required, eliminating any downtime during conversion
The modernized RPG code can continue to use standard iSeries data access methods such as record level access to data.