• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • Guru: When Playing With SQL

    March 18, 2019 Paul Tuohy

    One of the questions I have been asked a lot at conferences is “How do you figure out x in SQL?” In this article, I will discuss four things I use a lot when playing with SQL in Run SQL Scripts: VALUES, SYSIBM.SYSDUMMY1, global variables, and the system catalog.

    VALUES

    When I am trying to figure out how an SQL function works, my first port of call is the VALUES statement. VALUES derives a result directly from an expression. For example, the following statement:

    values upper('paul');
    

    Would generate the following result set:

    You can specify more than one value in the expression. Enclosing all of the expressions in parentheses results in a single row. This statement:

    values  (upper('paul'), lower('PAUL'), trim('   Tuohy  '));
    

    Would generate the result set:

    If you omit the parentheses, you will get one row per expression. This statement:

    values  upper('paul'), lower('PAUL'), trim('   Tuohy  ');
    

    Would generate the result set:

    You must be careful when you omit the parentheses and ensure that each of the expressions returns the same data type. You are performing a type of UNION. If you get it wrong, for instance a statement such as:

    values upper('paul'), int(123.45);
    

    Would return a result set of:

    This is not what we want!

    One of the issues with VALUES, when looking at multiple expressions in the result set, is the column headings. We cannot assign an AS name as we would in a SELECT clause. Which brings us to SYSIBM.SYSDUMMY1.

    SYSIBM.SYSDUMMY1

    As the name implies, SYSIBM.SYSDUMMY1 is a dummy table. It contains one row and one column, which is named IBMREQD and contains a value of ‘Y’. SYSIBM.SYSDUMMY1 is used extensively in SQL examples on the web and in the Knowledge Center. We are not interested in its content. We just need a table we can use in a SELECT statement:

    select upper('paul') upper_, 
           lower('PAUL') lower_, 
           trim('   Tuohy  ') trim_ 
    from sysibm.sysdummy1;
    

    This statement would result in:

    Global Variables

    Most of the time it is just fine to use simple literals (as in the previous examples), but sometimes you will be dealing with a large literal value (XML or JSON) or values that need to be of a certain data type (XML or parameters for a call to a stored procedure, where a literal might have to be cast to a date type).

    Global variables provide a means of having a variable whose value is unique to our job. The global variable can be used anywhere than a column name or literal would be used. This is an example of creating a global variable:

    CREATE VARIABLE PTARTICLES.MY_LONG_NAME_VAR 
      FOR SYSTEM NAME MYVAR 
      VARCHAR(1000) 
      DEFAULT 'Some default text';
    

    We can now reference the global variable anywhere we would reference a literal or a column:

    values MY_LONG_NAME_VAR; 
    values MYVAR;
    select MYVAR from sysibm.sysdummy1;
    set MYVAR = 'Different Text';
    

    There are a few points worth noting about global variables:

    • The value of a global variable is unique to the job. Changing the value of a global variable does not affect any other job that may also be using the global variable.
    • If you Reconnect (in Run SQL Scripts), you will be dealing with a new version of the global variable – you have just started a new job.
    • If you want to refer to the global variable without using a qualified name, then the schema (containing the global variable) must be included in the PATH directive. SET SCHEMA will not do it.
    • Creating a global variable results in the creation of a service program, so the system name is important if you want a meaningful system name.

    System Catalog

    When using Run SQL scripts with a database that you are not familiar with, one of the challenges is know what all the columns are in table or view. This is where a decent prompt facility would be of benefit. (They are working on it as I type.) But all of the information we require is available in the system catalog.

    The system catalog is a database which cross references all of the database definitions on the system. To get a list of columns in a table you could try something along the lines of:

    select column_name, system_column_name,
           column_text, data_type, 
           length, numeric_scale 
    from qsys2.syscolumns
    where table_schema = 'SIDDBV2'
    and table_name = 'ALUMNI'
    order by ordinal_position;
    

    If you take the option to Display Results in Separate Window you will now have a record layout you can reference as required and you can copy column names from the result window, shown here:

    Play tools

    These are my standard play tools with SQL – do you have any?

    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.

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags: Tags: 400guru, FHG, Four Hundred Guru, IBM i, JSON, SQL, XML

    Sponsored by
    Maxava

    Migrate IBM i with Confidence

    Tired of costly and risky migrations? Maxava Migrate Live minimizes disruption with seamless transitions. Upgrading to Power10 or cloud hosted system, Maxava has you covered!

    Learn More

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    As I See It: The Useless Class Wanted: Exciting New Publicist For Boring Old Server

    2 thoughts on “Guru: When Playing With SQL”

    • Greg Wilburn says:
      March 18, 2019 at 9:44 am

      select * from qsys2.user_info;
      (don’t fault me for using select *)… very useful information about the users in your system.

      Reply
    • Roger Harman says:
      March 18, 2019 at 5:50 pm

      I use an extract similar to your SYSCOLUMNS example all the time.

      I also like to use the LISTAGG() function with SYSCOLUMNS to build a CSV or Tab delimited list of column text when doing extracts to a flat file. That string goes as the first record in the flat file.

      Reply

    Leave a Reply Cancel reply

TFH Volume: 29 Issue: 17

This Issue Sponsored By

  • Fresche Solutions
  • New Generation Software
  • iTech Solutions
  • Computer Keyes
  • WorksRight Software

Table of Contents

  • Entry Power S812 Gets A New – But Still Short – Lease On Life
  • Wanted: Exciting New Publicist For Boring Old Server
  • Guru: When Playing With SQL
  • As I See It: The Useless Class
  • Are You Experienced? IBM i Users Weigh In

Content archive

  • The Four Hundred
  • Four Hundred Stuff
  • Four Hundred Guru

Recent Posts

  • Meet The Next Gen Of IBMers Helping To Build IBM i
  • Looks Like IBM Is Building A Linux-Like PASE For IBM i After All
  • Will Independent IBM i Clouds Survive PowerVS?
  • Now, IBM Is Jacking Up Hardware Maintenance Prices
  • IBM i PTF Guide, Volume 27, Number 24
  • Big Blue Raises IBM i License Transfer Fees, Other Prices
  • Keep The IBM i Youth Movement Going With More Training, Better Tools
  • Remain Begins Migrating DevOps Tools To VS Code
  • IBM Readies LTO-10 Tape Drives And Libraries
  • IBM i PTF Guide, Volume 27, Number 23

Subscribe

To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

Pages

  • About Us
  • Contact
  • Contributors
  • Four Hundred Monitor
  • IBM i PTF Guide
  • Media Kit
  • Subscribe

Search

Copyright © 2025 IT Jungle