Re: Interactive SQL -- Query/400 is [one of] its report writer

[CRPence <crp@xxxxxxxxxxxxxxxxxxxx>]

  The Query/400 product, much like most of the languages, is delivered 
in two parts.  There is the interactive definitional portion delivered 
as the Licensed Program Product [LPP] 57xx-QU1 in QQRYLIB accessed via 
WRKQRY, and the runtime portion delivered as part of i5/OS.  The runtime 
is accessed by OV/400 merge, some IBM PC based text merge, TXT38 merge, 
S/36 query & merge object migrations, interactive SQL, and most notably 
RUNQRY.  This split is somewhat a side-effect of the system design and 
architecture, whereby an /object/ created on one system should be able 
to be used on another system; not to imply shipping a runtime is unique 
to object-based.  When using the interactive WRKQRY feature a *QRYDFN 
object is created, and that query definition object should be able to be 
saved [to a target release that supports the level of function included 
in the definition] and then able to be restored to any system running 
i5/OS at or above the saved-to target release.  The run-time being an 
integrated part of the i5/OS enables that.
  Disclaimer on the target /release/: The definition of the Query/400 
product was such that very few functions should ever prevent previous 
release saves, and that the ability to get the definition to the 
previous release trumped preventing unsupported features.  The trump due 
to the feature not being a source-based compiler, that instead it is an 
interactive menu-based compile, so saving the object irrespective of its 
functional limitations enables an effective /source/ save -- the object 
details are available.
  Since the Open Data Path [ODP] is an object, and since the Query/400 
report writer builds a report from a query ODP, it makes sense that the 
already existing report writer should be reused rather than one written 
just for the interactive SQL SELECT processing.
  Because non-local access via STRSQL is SQL over DRDA, that same 
report writer was not the best fit.  But another report writer arrived 
for SQL based Query Management feature which has *QMQRY and *QMFORM. 
Thus for SQL CONNECT queries, the report writer used by STRSQL is the QM 
runtime with what is an effective /default form/ like is used on a 
STRQMQRY of a SELECT QM query which specifies QMFORM(*SYSDFT).
  So since the runtime features include the report writer, and that 
runtime is part of the i5/OS, the LPP is not required.  Of course since 
QM Query is part of 57xx-ST1, the point is somewhat lost -- except to 
say that the STRQM interactive utility could be /easily/ separated.

Regards, Chuck