The advantages of RPG
The developers in my company came from the mainframe using COBOL. They continue to use COBOL on the iSeries, but do not understand the iSeries technology the same way as veteran iSeries RPG programmers. I have coded in both RPG and COBOL. From my experience, I believe RPG to be the more efficient language from a development perspective. Do you have additional insight into the advantages of RPG? Java is certainly in our future, but I'm a bit concerned that COBOL may hold disadvantages of which we are not aware.

    Requires Free Membership to View

    Login

    Register today to access targeted resources from our editorial writers and independent industry experts including news, tips, and advice to help you do your job more efficiently and effectively. Stay informed on the hottest topics and biggest challenges faced by IT professionals working with iSeries products and services.

    By submitting your registration information to Search400.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of Search400.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

While mainframe COBOL and iSeries COBOL are similar, your developers will have a learning curve moving from and environment where all file processing including defining, sorting and setting up keys is handled in the COBOL program on the Mainframe, on the iSeries, the world is a little different. Files and indexes (Logical files) are defined externally and are only referenced by name in the iSeries world. In addition, using the latest techniques of RPG will move the staff towards separation of business logic from normal program operations. Using Modules/prototypes and service programs will further define the environment.

As an example:

 
D/Copy CustInfoDS
D Rc       S       10I 0
...
C                Eval   Rc = GetCustomerInfo(CustNum:CustInfoDs) 
C                If     Rc < 0
C                Eval   ErrData = %Editc(CustNum:'Z')
C                Eval   Rc = SndMyMsg("INVCUSTNUM":ErrData)
C                Iter
C                Else
C                Eval   Rc = CalcEOMAmounts(CustNum:CustInfoDs)
C                If     Rc < 0
C                Eval   ErrData = %Editc(CustNum:'Z')
C                Eval   Rc = SndMyMsg("CALCEOM":ErrData)
C                Iter
C                Else
C                Eval   Rc = UpdCustomerInfo(CustNum:CustInfoDs) 
C                If     Rc < 0
C                Eval   ErrData = %Editc(CustNum:'Z')
C                Eval   Rc = SndMyMsg("CUSTUPD":ErrData)
C                Iter
C                Endif
C                Endif
C                Endif

This would assume that standard modules for retrieval, calculation and updating of customer information would return a -1 for failure and a standard error routine to send the message to the user or joblog for batch processes. In COBOL, this would likely be hundreds of lines of code for file definition, retrieval and error message handling. The simplification of coding and maintenance should be apparent. Separate business logic from physical data logic and user interfaces allows the routines to be quickly adapted to different applications and environments.

==================================
MORE INFORMATION ON THIS TOPIC
==================================

The Best Web Links: tips, tutorials and more.

Ask your programming questions--or help out your peers by answering them--in our live discussion forums.

Ask the Experts yourself: Our application development gurus are waiting to answer your programming questions.


This was first published in December 2003

Back to top