Re: 5722-QU1 Question - tools for query-style function ?

Hi,

Steven Spencer wrote:
> In each case I would be curious if there are any "gotchas" in trying to access QS36F data, after you make up some IDDU or DDS or special source representation. If the product wants the "true" DB2 database, > then I could compile and copy files over to DB2 for testing purposes.

Chuck
(snip a bunch)

To access the S/36 database file data stored in "program described" files [in QS36F or any library; i.e. not just S36EE "Files" libraries] from the SQL, the data would need to be exposed either via "externally described" physical files or by SQL [most likely only or mostly just] "external" routines such as User Defined (Table) Functions [UDTF].

Steven
Am I correct in thinking that once you do the handwork of the User Defined Table Functions (which I have never done, but sounds like some type of normal file spec thing, as long as stuff like packed data considerations do not intervene) that then you are running in a functionally equivalent mode as if you were using DB2 files with source descriptions compiled ?

Chuck

No matter what is done to migrate data to enable a query interface that uses the SQL, be sure to correct any decimal data problems which are generally pervasive for applications that originated or mimicked the behavior of the S/36 programming. Moving to SQL DDL will "force" programs to operate correctly [failing if they do not], but that may not be desirable if the applications have not already been reviewed and recompiled to prevent writing bad decimal data.

Steven
This is similar, I think, to the issues when going from QS36F to DB2. A lot of flakey forgiven QS36F data can come back to bite you, and you might have to clean up stuff, maybe blank fields, or unused fields poorly represented.

Similarly, when I ported my programs from SSP to S36EE, I ran into DDM (Disk Data Management) tightening up the doubly-defined RPG programs by giving error messages if they did not close one file-record, while it was being accessed by a second file-same-record. A funny little gotcha that was poorly documented, but of which IBM was quite awares and let me know when I called.

So if I have to tighten up some data, I don't mind. It is like preparation for DB2, and par for the course. I know the programs and data well, so it is sort of routine easy-work.

So .. do I understand sort of properly ? An SQL-oriented utility program will have a user-defined capability that it can point to that is similar to F & I, IDDU and other such files specs ?

Steven Spencer
Queens, NY