Format and Compile RPG to Use Embedded SQL Let's explore the nuts and bolts of using embedded
SQL: file type, syntax, and compiling. In a previous article, "Why Use Embedded SQL Within RPG?," I talked about why you would use embedded SQL in RPG. In this article, I will talk about how you could use embedded SQL within RPG. We'll start with an existing RPG program that is written with CHAIN and READ, and then we'll convert it to use embedded SQL.
Source Member Type SQLRPGLE
First things first. We need to make sure we are using the new type for your source member, which is SQLRPGLE.
Figure 1: Here's a list of my SQLRPGLE and RPGLE source member types. (Click images to enlarge.) Why does the type of member matter? Well, it doesn't matter to the compiler; you can keep it as RPGLE, and it will compile just fine, but PDM won't be happy about it when you're trying to create the code. Here is what will happen if you try to put embedded SQL in a member of type RPGLE.
EMPLOYEE contains account number and name. What if I'm using IBM Rational Developer for Power Systems Software?
Figure 3: And this is what you'll see in IBM Rational Developer for Power Systems Software if you attempt SQL in an RPGLE source member.
Physical File Descriptions
For our example. date of pay. and net amount of pay. you will get the same results as you would using an RPGLE source member type. in order to be able to code your embedded SQL using either of these tools. you will want to use the SQLRPGLE source member type to keep your editor happy. PDM thinks it's an invalid EVAL operation. EMPHIST contains account number. A A A A A R MCFMT MCACCT MCFNAME MCLNAME K MCACCT 6S 0 32A 32A COLHDG('Account Number') COLHDG('First Name') COLHDG('Last Name')
Figure 4: Here's a DBU view of an employee record for account 400. We will be using two simple files for our example.Figure 2: This is an example of what you'll see in PDM if you attempt SQL in an RPGLE source member. So. With IBM Rational Developer for Power Systems Software. A A A A A A R MHFMT MHACCT MHDATE MHNET K MHACCT K MHDATE 6S 0 L 9S 2 COLHDG('Account Number') COLHDG('Pay Date') COLHDG('Pay Net Amount')
. we will determine the year-to-date amount that was paid to employee 400.
ytdNet = ytdNet + MHNET. we will chain into the EMPLOYEE file to retrieve the employee name.
Straight-Up RPG Without Embedded SQL
For our RPG code without embedded SQL. ' + %trim(MCFNAME) + ' Net: ' + %trim(%editc(ytdNet: '1')).000 per week. dou %eof().
. reade currentKey EMPHIST. else. chain currentKey EMPHIST. and her net pay will be $1. displayBytes = %trim(displayBytes) + ' ' + %trim(MCLNAME) + '. the account. enddo. displayBytes = 'Acct(' + %trim(%editc(currentKey: '3')) + ')'. displayBytes = %trim(displayBytes) + ': ' + ' NOT FOUND!'. if %found(). ytdNet = *ZEROS.Figure 5: Here's the DBU view of the employee history for account 400 for the first day of the year. will have an account key of 400. FEMPLOYEE IF E K DISK FEMPHIST IF E K DISK F* D xEMPLOYEE E DS ExtName(EMPLOYEE) D xEMPHIST E DS ExtName(EMPHIST) D currentKey S 6S 0 D ytdNet S 9S 2 D displayBytes S 52A /free currentKey = 400. and then we will loop through the EMPHIST file using the account number key to accumulate the year-to-date total for the employee. Eibeamma Ausfurhundrid. For our data. chain currentKey EMPLOYEE.
// Display the Results dsply displayBytes. MCFNAME. /end-free
Fixed-Formatted RPG with Embedded SQL
Now we will write an embedded SQL program to generate the same results: D xEMPLOYEE E DS ExtName(EMPLOYEE) D xEMPHIST E DS ExtName(EMPHIST) D currentKey S 6S 0 D ytdNet S 9S 2 D displayBytes S 52A C eval currentKey = 400 C eval ytdNet = *ZEROS C eval displayBytes = 'Acct(' C + %trim(%editc(currentKey:'3')) C + ')' C*// Run the Query C/EXEC SQL C+ select MCACCT. MCFNAME. *inlr = *ON. MCLNAME. ' + %trim(MCFNAME) C + ' Net: ' C + %trim(%editc(ytdNet: '1')) C else C eval displayBytes = %trim(displayBytes) C + ': ' + ' NOT FOUND!' C endif C displayBytes dsply C eval *inlr = *ON
Free-Formatted RPG with Embedded SQL
And here is the free-formatted version of the same code: D xEMPLOYEE D xEMPHIST D currentKey E DS E DS S ExtName(EMPLOYEE) ExtName(EMPHIST) 6S 0
. MCLNAME C/END-EXEC C*// Display the Results C if sqlState = *ZEROS C eval displayBytes = %trim(displayBytes) C + ' ' + %trim(MCLNAME) C + '. sum(mhnet) C+ into :MCACCT. :MCLNAME. :ytdNet C+ from EMPLOYEE C+ join EMPHIST on MCACCT = MHACCT C+ where MCACCT = :currentKey C+ group by MCACCT. :MCFNAME.endif.
MCLNAME. This gets to be really nice when you are processing all of the accounts in the file. // Run the Query exec sql select MCACCT.
. /end-free Now let's review the differences. "exec sql" is the free-formatted alternative to /EXEC SQL and /END-EXEC. else. and we are specifying the file to use in the SQL statement.
No File Specifications
I discussed this in my previous article. /END-EXEC. You can JOIN the two files together and use them to create the results. displayBytes = %trim(displayBytes) + ' ' + %trim(MCLNAME) + '. and exec sql
/EXEC SQL indicates that some SQL code is about to begin. endif. sum(mhnet) into :MCACCT.D ytdNet S 9S 2 D displayBytes S 52A /free currentKey = 400. *inlr = *ON. :MCFNAME. and you can see that we are not using any F-specs in this program. This might seem nice here. MCFNAME. displayBytes = 'Acct(' + %trim(%editc(currentKey: '3')) + ')'. and /END-EXEC marks the end. // Display the Results if sqlState = *ZEROS.
Using Both Files at the Same Time
There is no need to CHAIN into the EMPLOYEE file and then READ through the EMPHIST file. dsply displayBytes.
/EXEC SQL. displayBytes = %trim(displayBytes) + ': ' + ' NOT FOUND!'. ' + %trim(MCFNAME) + ' Net: ' + %trim(%editc(ytdNet: '1')). This is because we are using SQL. :MCLNAME. MCLNAME. but it is a simple example and is only being used for one account. This is similar to /free and /end-free to indicate the beginning and ending of segments of code that are freeformatted RPG. MCFNAME. :ytdNet from EMPLOYEE join EMPHIST on MCACCT = MHACCT where MCACCT = :currentKey group by MCACCT. ytdNet = *ZEROS.
which are referred to as host variables in SQL. and there are no variables declared for sqlState. which contains the SQLSTATE/SQLSTT variable. These are used for both input and output in this example. This is made available automatically by the compiler. and the "sum" used on the MHNET field will sum the total for the group. If you look at your compiler spool file.
Where Did sqlState Come From?
You can see the complete code above.
Figure 6: You'll see the SQLCA data structure in the compiler spool file. :ytdNet" portion is used as output for the results to be put into when the statement is executed. :MCLNAME. The "where mcacct = :currentKey" is the input version that allows a variable value to be used to filter the data.
. SQL will automatically "group" all of the records specified to be grouped together.Colons in Front of the Variables
The colons (:) indicate variables inside of the SQL statement. The "into :MCACCT. you will see the SQLCA data structure.
You don't need to loop through the records when you are using "group by" in your SQL statement. :MCFNAME.
and I don't want to pass along my own bad habits. using the CALL command. and in the process of breaking my own bad habits. you can create *PGM. And that's all you need to do to create an RPG program with embedded SQL. or *MODULE. You can get a lot more resolution by expanding your code and looking for more codes that are available for SQLSTATE. compile the code.
Compiling the Embedded SQL Program/Module
To compile RPG programs using embedded SQL. *SRVPGM. you will get the same results.
Figure 7: This output is generated when calling both versions of the program.
There is no special way to call an SQLRPGLE program. I usually just use CRTSQLRPGI because you can do everything with it. You can choose either CRTSQLRPG or CRTSQLRPGI if you are creating a program. and run it. You can find a list of SQLSTATE values on the IBM site by clicking here.In my quest for simplistic code. You can download the code. The difference between the two is that you do not have the option to determine the compile type when using CRTSQLRPG because it creates only *PGM objects. so I updated this version of the code to use SQLSTATE instead. Whether you run the straight RPG program or the one using embedded SQL. my previous version of this program was using sqlCode. This would be a year-to-date amount into November. which is discouraged from usage for the purpose of portability. With CRTSQLRPGI. Here is the command I used to compile this program: CRTSQLRPGI OBJ(MyLib/MCP035SQL) SRCFILE(MyLib/MySrc) COMMIT(*NONE) DBGVIEW(*SOURCE) You options may vary. you'll need to use a new command.
. create the files. depending upon whether or not you are using commitment control and what your debugging preferences are. You call it just the same as you would call any other RPG program.