Converting from RPGLE to DB2/400 SQL
My shop just announced that it intends to convert from RPGLE on the ISeries 400 platform, to SQL, such that the procedures will be portable to other hardware platforms. What documentation to I need to acquire to train on writing SQL procedures; initially within DB2/400?
Software/Hardware used:
Software/Hardware used:
ASKED:
June 21, 2010 8:30 PM
UPDATED:
June 22, 2010 8:04 AM
Answer Wiki:
The starting place should the Information Center topic on <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/sqlp/rbafyroutines.htm">Database Routines</a>. The Related Information topic under Database lists numerous other resources.
One listed resource that you might find particularly useful is the <a href="http://www.redbooks.ibm.com/abstracts/sg246503.html?Open">Stored Procedures, Triggers, and User-Defined Functions on DB2 Universal Database for iSeries</a> Redbook.
And, of course, the actual SQL Reference manuals will always be needed for reference about the SQL statements themselves. (They can be downloaded from the Information Center.)
However, since the purpose is "cross-platform compatibility", you might want to be familiar with how other platforms do things. You won't find a lot of IBM info on how to port <b>from</b> DB2 to other RDBMSs -- you'll have to go to other vendors to see what porting guides they offer. But maybe the <a href="http://www-304.ibm.com/partnerworld/wps/servlet/ContentHandler/servers/enable/site/db2_porting_i.html">IBM DB2 for i Porting Information</a> page will be helpful. It can help with how to port specifications from some others to DB2, so you might be able to work out how to go in the opposite directions.
Tom
To see all answers submitted to the Answer Wiki: View Answer History.
My experience with Procedure/Java programming was very different from RPG.
The basic construct is likely to be differet.
Procedural environments, RPG, flow from task to task under program control.
Web based systems are “session-less” requests for action. When the procedure receives the request it doesn’t have a known past or known future, just a present.
For instance you do not lock a record when fetching the data for display because you do not know what the next action will be.
Requests from a single web session may be processed by different 400 jobs so the use of Qtemp, SETTING LIBRARY LISTS, ETC will only be reliable within the single call to the procedure. Next call my have a different processing job, different QTEMP, ETC.
Phil