The SQLID parameter of the PARM statement results in the SQL interface
executing the SQL SET CURRENT SQLID command at compile time. The SQL
SET CURRENT SQLID command is executed at runtime for automatic
processing. Execution of the SQL SET CURRENT SQLID command is valid for
sites that have an external security package that supports group IDS. It sets the
qualification of unqualified tables for dynamic SQL processing. See Qualifying
DB2 for OS/390 and z/OS Tables later in this chapter for more information.
It is recommended to use SQLSYNTAX NONE with BIND STATIC-ONLY rather
than SQLID to set the qualification for tables.
Please continue on page 2-7 for further information:
Unqualified tables are implicitly qualified by the primary authorization ID of the
program. This ID is usually established by the USER parameter of your JCL JOB
card. You can modify qualification in one of three ways:
? SQLID keyword on the CA-Easytrieve PARM statement
? SQL SET CURRENT SQLID command
? OWNER or QUALIFIER parameter on the DB2 for OS/390 and z/OS BIND
Use of the SQLID and its affect on table qualification depends on whether
automatic or controlled processing is performed and if STATIC or DYNAMIC
SQL is used.
To eliminate the authorization problems encountered with the use of SQLID, use
SQLSYNTAX NONE with BIND STATIC-ONLY. This enables the use of
unqualified table names and bypasses the dynamic prepare of SQL statements.
Unqualified table names can then be qualified by the BIND process.
Then there continues in the documentation specific information for dynamic versus static SQLID with examples.
It was asked to explain how SQLID='DHSICDT', but I see the following line is commented out:
We advised that this would work with either the proper authority or by not specifying SQLID.