Back at least 20 years ago I wrote and published the RUNSQL command. Later I created a low-cost SQL application named "SQL Lite". IBM i (OS/400) shops have been using it for some 20 years now.

Earlier this year or late last year, IBM announced a reduced function RUNSQL command. Basicaly is provided support for the non-SELECT statements. Its introduciton caused a lot of issues for end-users who not only used my SQL Lite RUNSQL command but who had read my articles and written their own version--also naming it RUNSQL. Effectively IBM's RUNSQL was a non-starter because it only did what everybody who needed it, already could do, and it didn't do the SELECT statement.

I was playing around with the COZTOOLS' SQL Service Program and thought I could implement a new, modern SQL SELECT statement that could be run via a command. Turned out that this was easier than I had thought.

I wrote a simple test app, of about 20 lines of code, and was able to produce output from any SELECT statement. My initial tests directed the output to a text file in the IFS so that I could reveiw the results using the DSPF command or by FTP'ing the file to my PC and viewing it.

I thought this was pretty cool to be able to use my own product to produce a CL command that processes the SELECT statement and produces results. But of course "nobody needs it". So I'm wondering if something like the following would make it more useful. What do you think?

Create a CL command that contains the parameters for an SQL SELECT statement. THe parameter for the command would be:

• FROM
• SELECT
• WHERE
• ORDERBY
• HAVING
• JOIN

Similar to the Interactive SQL Prompter, this CL command would accept the components of an SQL SELECT statement as individual parameters. Then it would build the SELECT statement and run it. In addition the JOIN parmaeter would permit the entry of regular command-style qualified file names along with the "ON" parameter to more easily create a JOIN query.

Beyond that, the OUTPUT parameter would have the following options:

• * - Display the output
• *PRINT - Create a SPOOL file with the output
• *OUTFILE - Create a database file from the output
• *STMF - Create a StreamFile (IFS File) of the output

Of course the OUTFMT parameter would be used with the *STMF option to control the type of output. I'm thinking of the following options for OUTFMT:

• *TEXT
• *PDF
• *CSV

For example:

QuickSQL Stmt('SELECT * FROM CUSTMAST') OUTPUT(*STMF) OUTFMT(*CSV)

With the additional parameters:

QuickSQL Stmt(*ADVANCED) SELECT(*) FROM(CUSTMAST) OUTPUT(*STMF) OUTFMT(*CSV)

Do people still have a need for this, or should I just add it to my collection of cool things that nobody wants?

Thanks.