RE: JDE RUNUBE Makes SQL not work?

First, let me state I don't even know what JDE's RUNUBE even does..
but maybe someone here does and can explain why it seems to make all SQL statements (in RPG programs mainly, that's all we've tested) not work?

Even simple ones. They just don't work and return sql error codes or no data. But only if they follow JDE RUNUBE.

UBE is E1 speak for a batch program. Every program in JDE E1 runs in an interpreted, proprietary language. The underlying E1 toolset gets called with a RUNUBE command, the libraries get set for the appropriate environment, and the interpreted language program launches.

When E1 tools run the program, it's important to know that it does not run in a single thread. Enterpriseone has a multitude of JDENET_K kernel jobs that pass this batch program between themselves. More to the point, SQL calls get handed to external QSQSRVR jobs. This is done by setting SQL server mode. Look through the job log, and you should find a message SQL7908:

Message . . . . : Job 246062/QUSER/QSQSRVR used for SQL server mode
processing.
Cause . . . . . : A Structured Query Language (SQL) statement was executed
while running in SQL server mode. SQL statements for this connection or
thread will be processed in job 246062/QUSER/QSQSRVR. Technical description
. . . . . . . . : SQL server mode was requested by either setting the SQL
server mode job attribute, or by setting the server mode environment
attribute via the SQL Call Level Interface. When running in this mode, SQL
statements are processed by a separate job, which runs under the user
profile specified for the connection. The thread identifier is -1 and the
connection is to Relational Database E1ENT. If the Relational Database name
is *N, this means that all connections for the thread will use the same job.

In essence, SQL now assumes that SQL statements are to be passed on to an QSQSRVR job and the results returned back to a monitoring job. I've never learned how to change the SQL Call Level Interface back, I just run with the following workaround.

The easiest fix is to make the RUNUBE command run in its own external program with SBMJOB. Monitor for completion, then resume back in the original job when the submitted job ends. This should isolate the SQL state change to the called program.



_____________________________________________________________________
Spirax-Sarco Engineering Plc. This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk