Guru: Prompting Stored Procedures
February 22, 2021 Paul Tuohy
In this tip I would like to touch on two items, in relation to stored procedures, that may have escaped your notice: prompting stored procedures and/or parameters (in Run SQL Scripts) and passing parameters by name.
I must admit that, as I have gotten older, my ability to remember the names and parameters for stored procedures has, shall we say, decreased. At this stage, I am lucky if I can remember which library/schema one of my stored procedures is in!
A case in point. I recently received an e-mail about a stored procedure I had written about (back in 2015) which performed a PIVOT on a table. The email did not mention the article (An SQL Pivot Procedure). or more importantly, the name of the stored procedure. Now, I could have gone to the IT Jungle website and used the wonderful search feature to find my article but I must admit to a dislike of reading my own articles and Run SQL Scripts happened to be open in front of me.
I did have an idea of which library (schema) the procedure was in, so I started by setting my path to that schema. I then typed in CALL and pressed F4. I was presented with a list of all the procedures in my path:
I guessed that DO_PIVOT was the one I was looking for (as opposed to DO_PIVVOT), so I selected it in the list and pressed enter. DO_PIVOT was duly placed after my call.
But I had no idea of the parameters or their sequence, so I typed in open and close parentheses after the procedure name, placed the cursor between the parentheses and pressed F4 again. I was duly presented with a list of the parameters. If you move the cursor down the list you will see the definition of each parameter.
I selected all parameters (I held down the Shift key and clicked on the first and last parameters in the list) and pressed Enter.
Unfortunately, the parameters were all placed on one line, so I performed a quick tidy up and placed a parameter on each line. Then I assigned values to each parameter and ran the statement.
And that brings us to the second part of the tip. When you call a stored procedure, you have the choice of defining parameters by position or by name. The procedure could have been called using positional parameters:
call DO_PIVOT('SQLSTAND',
'SALES',
'SALES_PERSON',
'SALES',
DEFAULT,
'REGION');
But one of the advantages of naming the parameters (apart from the obvious legibility) is that you do not need to be concerned about the sequence of the parameters — the name defines the parameter. The call could just as easily have been written as:
call DO_PIVOT(GROUP_COLUMN => 'REGION',
AGG_FUNCTION => DEFAULT,
VALUE_COLUMN => 'SALES',
PIVOT_COLUMN => 'SALES_PERSON',
FOR_TABLE => 'SALES',
FOR_SCHEMA => 'SQLSTAND');
Or you could use a combination of positional and named parameters but once you use a named parameter then all following parameters must be named as well.
call DO_PIVOT('SQLSTAND',
'SALES',
PIVOT_COLUMN => 'SALES_PERSON',
VALUE_COLUMN => 'SALES',
AGG_FUNCTION => DEFAULT,
GROUP_COLUMN => 'REGION');
I also find the ability to prompt parameters invaluable when it comes to using some of the myriad of IBM i Services and Db2 for i Services.
I am truly thankful to the ACS team in Rochester for developing features that keep me productive as I totter toward old age.
Paul Tuohy, IBM Champion and author of Re-engineering RPG Legacy Applications, is a prominent consultant and trainer for application modernization and development technologies on the IBM Midrange. He is currently CEO of ComCon, a consultancy firm in Dublin, Ireland, and partner at System i Developer. He hosts the RPG & DB2 Summit twice per year with partners Susan Gantner and Jon Paris.
