On 2/23/11 9:57 AM, Harman, Roger wrote:
Rather than code directly to them, why not use embedded SQL to limit
the exposure?
Richard Thomas on Wednesday, February 23, 2011 9:45 AM wrote:
Using the API should ensure your software is future-proof; if you
do want to use the QAOK* files directly, be prepared for possible
changes to the tables (and therefore level checks) when you move
to a new release etc.
Chuck said: "I would not recommend coding directly to them" and I
second that.
<<SNIP>>
Using SQL can limit exposure to some changes in definitions to the
keys, data types, length\precision, scale, and CCSID, but not against
actual data changes [e.g. to\for meaning, like "codes"], column name
changes, or especially the replacement of those files by some other
means of implementing the Directory feature.
While the implementation of the directory entries is unlikely to
change from using the files in QUSRSYS [AFaIK the function is pretty
much solidified and unchanging], the Directory feature is merely
"implemented" using those files. Thus the reason to avoid coding to the
QAOK* database files directly if a desire exists to have an application
that can continue functioning across releases and [even possibly,
although very unlikely due to difficulty in both effecting and properly
ensuring such changes outside of the install process,] across PTF changes.
There is no reason that the data in those files could not be migrated
by the OK component of the OS, from the QAOK* files in QUSRSYS, into
user spaces, user indexes, or even into objects not available directly
by any non-system interface, such as a system-domain internal object
type rather than a user domain external object type. There is also
nothing preventing the files from being changed to "Allow Read: *NO"
from their current status of being "Allow Read: *YES"; i.e. such that
only "system" interfaces are allowed to perform a database READ, and
that can be effected easily in a PTF; nothing except upsetting anyone
who has coded directly to such implementation details ;-)
Coding to an implementation detail rather than to a documented
interface is subject to the vagaries of OS developers, for however they
might choose to change\enhance the feature with tweaks\overhauls to the
means of implementation. Any "implementation changes" against the
feature or data, upon which the application has a coded dependency, may
just stop working [or worse, start producing unpredictable or incorrect
output] as a side effect of the change. At least if\when the designed
and documented external interface to the function\data produces bad
results, that situation can be reported as a defect to IBM, and a PTF
provided. If the database files change [even if documented] or even
disappear, the application dependent on those files will need to be
changed or possibly re-written [probably to use the supported API
instead of the since-changed or removed database files; i.e. to do what
the application should have done in the first place].
Regards, Chuck
midrange.com
