Re: Retrieving System Distribution Directory details...

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