One persistent problem of developing multi-tiered applications with the AS/400 is the need to get AS/400 job log information. One client/server Web development trick-of-the-trade is interfacing with your iSeries-AS/400 over ODBC, OLE DB, or JDBC. All client jobs run in the QSERVER subsystem as a QZDASOINIT prestart job under the user profile QUSER. Even if a Java program is running on the AS/400 using JDBC, the program will cause a QZDASOINIT job to appear in the QSERVER subsystem to satisfy any SQL requests. As a result, the QSERVER subsystem is getting more crowded as more programs begin to use it for data manipulation and to call stored procedures.

Figure 1 shows you what a typical QSERVER subsystem look like, displaying lots of QZDASOINIT jobs serving Web, Java, and Visual Basic (VB) programs.

To find the user profile that is actually connected to the AS/400, you must first use option 5 against a QZDASOINIT job, then use option 10 to look at the job log. This seems to be the only way to identify which user profile actually logged on to the AS/400, barring working with known object locks or writing a special exit program. It is further complicated by the fact that most Web-based programs use only a single user profile to connect to the AS/400. So, you could potentially have hundreds of QZDASOINIT jobs that are all using the same OS/400 user profile. This situation makes it hard to pinpoint the exact job that you want to work with or debug.

In the past, I’ve shown you an OS/400 job number search technique that involves creating a CL program on the AS/400 to execute the Retrieve Job Attributes (RTVJOBA) command and returning the job number to the caller. To perform this technique, you have to create a stored procedure definition on the AS/400 to wrap the command and describe its output. Finally, you have to invoke the stored procedure from your client application to retrieve the job number under which that client application is currently executing. This is a nice way to locate a specific job number, but sometimes it isn’t practical; particularly if
you’re a consultant who doesn’t have the authority to create a procedure, or if you just
don’t want to invest the time required to declare and run the procedure on your AS/400. In this article, I will show you how IBM finds the job number of its current Operations Navigator (OpsNav) connection and give you another way to find the current connections job number.

A Little Background

I recently discovered this information while performing ODBC traces against the OpsNav Run SQL Scripts (RSS) component. RSS has some neat features, and, since I wanted to include a few of these features in my SQLThing product, I decided to trace how they

worked. [Editor’s Note: For more information on other RSS tricks, see “I Want to Be Like Mike,” Midrange Computing (Web Edition), February 2001 at www.midrangecomputing.com/mc/monthdisplay.cfm?md=200102.]

RSS connects to the AS/400 via the Client Access ODBC driver. By setting up the ODBC control panel application to trace calls to the ODBC driver, you will receive a complete log of the RSS ODBC calls while your application is connected to the AS/400. This log is useful for observing the wizard’s hidden functions as it can reveal how IBM programmers think about implementing new features in a client/server scenario.

Digging through the heaping mounds of ODBC trace information, I found the following gem: When RSS wants to know your job number, it uses the output of the OS/400 Display Job Log (DSPJOBLOG) command by formatting a call to the QCMDEXC API function. This function allows you to call any AS/400 command via the stored procedure mechanism available in SQL. However, since you are using the API, you do not have to pre-declare the stored procedure before you call it. QCMDEXC allows any AS/400 command to be called from an SQL connection. Here is the syntax of the command:

QSYS.QCMDEXC( , )

The first argument to QCMDEXC is a command string that you want to execute. The second argument is a decimal 10,5 number that represents the length of the string that you are passing to the QCMDEXC API.

So, when RSS wants to know its QZDASOINIT job number, it first calls the DSPJOBLOG command using the QCMDEXC API and redirects the output of the command to a file in QTEMP. Here is the syntax of the call to the QCMDEXC API that will write the job log to an output file:

CALL QSYS.QCMDEXC(‘QSYS/DSPJOBLOG OUTPUT(*OUTFILE) OUTFILE(QTEMP/QAUGDBJOBN)
OUTMBR(*FIRST *REPLACE)’,0000000081.00000)

CALL is the syntax that lets the SQL transport know that you are about to call a stored procedure on the AS/400. QSYS.QCMDEXC is the name of the stored procedure (in this case, an API function) that you are about to call. The first argument to the stored procedure is the command string representing the DSPJOBLOG command. Note that the call to DSPJOBLOG causes the output of the command to be written to a file named QAUGDBJOBN in the QTEMP library. The DSPJOBLOG command also instructs the AS/400 to put the output in the first member and to replace any member or file records that already exist. The final argument to the API-stored procedure is the length of the first argument command string. In this case, the string passed in the first argument is 81 bytes in length, so the number 81 must be passed to the second argument of the QCMDEXC API as a decimal (10,5) number. Note that QCMDEXC must have the length passed as a decimal 10,5 number, and that value must match exactly the length of the passed string or the API call will fail.

Once control returns to RSS, a file exists in QTEMP that has the existing job’s joblog contents as its first member. To retrieve the job number, RSS issues the following SQL statement to read the QMHJOB field (message data field) where the QMHMID field (message ID field) is equal to ‘CPIAD02’.

SELECT QMHJOB FROM QTEMP.QAUGDBJOBN WHERE QMHMID = ‘CPIAD02’

Whenever a QZDASOINIT job connects to the AS/400, one of the first actions of the job is to send the message CPIAD02 to the job log. This message indicates which user profile is being served by the job. The data returned to RSS by the SQL statement looks like this:

QZDASOINITQUSER 467925

The first 10 characters are the job name, the second 10 characters are the user profile, and the last 6 characters are the job number. By executing the following variant of the SQL statement IBM uses, you can get the data returned as three separate fields instead of having to substring the value of the job number in your client application:

SELECT SUBSTRING(QMHJOB,1,10) AS JOBNAME,
SUBSTRING(QMHJOB,11,10) AS USERNAME,
SUBSTRING(QMHJOB,21,6) AS JOBNUM
FROM QTEMP.QAUGDBJOBN WHERE QMHMID = ‘CPIAD02’;

This little trick is a unique way to find an elusive job number and avoid having to create a special stored procedure on the AS/400. Since the technique relies on the use of the QCMDEXC API function and the ability to call AS/400 commands as stored procedures (even if they are not declared as such), it will work from OLE DB, ODBC, or JDBC. Figure 2 shows a VB snippet that will use ADO to perform the same actions as RSS and print the job number in a Windows message box. Figure 3 shows a simple Java program that will run on your AS/400 and return its QZDASOINIT job number. This Java program should also run on a client PC, as it is 100% Pure Java and does not use any proprietary AS/400 features other than the call to the QCMDEXC API.

Caveats, Anyone?

The only caveat is that you must ensure that you have the Translate coded character set (CCSID) 65535 option enabled if you are using ODBC as your transport. This can be set via the ODBC Control panel applet (under the Translation tab), or set dynamically via the connection properties if you are using an OLE DB provider. The QMHJOB field is data type LONG VARBINARY, and it is stored in CCSID 65535 as it holds job message data which can be binary or character information. If you do not have the translate option enabled, the data will be returned to a PC client in EBCDIC characters instead of ASCII, and you would have to translate the data to ASCII yourself.

This is a neat way to retrieve a job number, the only drawback being that it writes information to a file in QTEMP. Should your job be in debug more or have a large job log, the execution of the DSPJOBLOG command could take some time, so you might want to use the stored procedure method to retrieve the number as it is more efficient.

References and Related Materials

“AS/400 Stored Procedures to the Rescue!” Howard F. Arner, Jr., Midrange Computing (Web Edition), August 2000, www.midrangecomputing.com/mc/article. cfm?titleid=b1462&md=20008

“iSeries and AS/400 SQL at Work,” Howard F. Arner, Jr., MC Press

“I Want to Be Like Mike,” Howard F. Arner, Jr., Midrange Computing (Web Edition), February 2001, www.midrangecomputing. com/mc/monthdisplay.cfm?md=200102

“Optimizing the Optimizer,” Howard F. Arner, Jr., Midrange Computing, July 1999

“Pesky Stored Procedure Pitfalls,” Howard F. Arner, Jr., Midrange Network Expert (Web Edition), November/December 2000, www.midrangecomputing.com/ ane/article.cfm?id=1034&md=20005

“Stored Procedures 101,” Howard F. Arner, Jr., Midrange Computing (Web Edition), October 2000, www.midrangecomputing. com/mc/article.cfm?titleid=b1556&md=200010

Figure 1: This is what a typical QSERVER subsystem looks like, with lots of QZDASOINIT jobs serving Web, Java, and Visual Basic programs.

'Assumes con1 is an active ADO connection object
'connected to your AS/400
dim cmd1 as new adodb.command
dim rs as new adodb.recordset
cmd1.activeconnection = con1
cmd1.commandtext = "CALL QSYS.QCMDEXC('QSYS/DSPJOBLOG " & _

"OUTPUT(*OUTFILE) OUTFILE(QTEMP/QAUGDBJOBN) " & _
"OUTMBR(*FIRST *REPLACE)',0000000081.00000)"
cmd1.execute
cmd1.commandtext = "SELECT SUBSTRING(QMHJOB,1,10) AS JOBNAME," & _

"SUBSTRING(QMHJOB,11,10) AS USERNAME," & _
"SUBSTRING(QMHJOB,21,6) AS JOBNUM " & _
"FROM QTEMP.QAUGDBJOBN WHERE QMHMID = 'CPIAD02'"
rs.open cmd1
msgbox "Your Job Number is: " & rs.fields("JOBNUM").value
rs.close
set cmd1=nothing
set rs=nothing

Figure 2: This snippet of Visual Basic will print the job number of the QZDASOINIT job VB is using to service SQL requests.

import java.sql.*;
import java.math.*;

class AS400SP {

Connection con = null;

long c = 0;

AS400SP () {

try {

Class.forName("com.ibm.as400.access.AS400JDBCDriver");

} catch( ClassNotFoundException e) {

System.out.println("JDBC Driver not found: " + e);

System.exit(0);

}

try {

con = DriverManager.getConnection ("jdbc:as400://10.10.10.1;extended

dynamic=true;","arner","arner");

long timer1=System.currentTimeMillis();

Statement stmt = con.createStatement();

stmt.executeUpdate("CALL QSYS.QCMDEXC('QSYS/DSPJOBLOG
OUTPUT(*OUTFILE) OUTFILE(QTEMP/QAUGDBJOBN) OUTMBR(*FIRST
*REPLACE)',0000000081.00000)");

System.out.println("Procedure Executed");

ResultSet rs = stmt.executeQuery ("SELECT SUBSTRING(QMHJOB,1,10) AS
JOBNAME,SUBSTRING(QMHJOB,11,10) AS USERNAME,SUBSTRING(QMHJOB,20,6)
AS JOBNUM FROM QTEMP.QAUGDBJOBN WHERE QMHMID = 'CPIAD02'");

rs.next();
System.out.println(rs.getString("JOBNAME")) ;
System.out.println(rs.getString("USERNAME")) ;
System.out.println(rs.getString("JOBNUM")) ;

System.out.println("End Test");
} catch (SQLException e) {

System.out.println("SQL error : " + e);

return;

}

}

public static void main (String[] pList) {

new AS400SP ();

System.exit(0);

}

}

Figure 3: This simple Java program will connect and then retrieve and display the QZDASOINIT job number.