× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.