Re: SQL limited access to QS36F - how strong, how weak is the access ?

On 16-Mar-2012 13:44 , Charles Wilt wrote:

I'm not sure, but I think it's possible to replace S36 multi-format
flat files with a combination of externally described native single
format PF and multi-format logicals.

Looks like IBM even had some tools: <<SNIP>>

Many MFPF [as described with IDDU anyhow] probably could be "easily" converted to DDS described database physical and logical *FILE objects and\or SQL TABLE and VIEW *FILE objects. However the data from each format of the MFPF might best sometimes or might effectively be required, to move into separate physical files, each with their own specific external [Record Format definition] descriptions. Given a capability for the logical file [DDS or SQL] to /direct map/ the data in the underlying physical buffer, irrespective of the PF fields, plus those logical files being able to retain all I\O capabilities beyond read-only, then a direct transition from the MFPF to an equivalent MFLF would be much easier; alas, no can do.
http://archive.midrange.com/rpg400-l/201203/msg00161.html

Those <snipped> IBM LPP migration tooling had little capability to help with making the transition for the database file objects; note that there was no CVTS36F command in that list. Instead there was a "Programmer's Toolkit", a PRPQ maybe, I no longer recall, which would do things like create DDS from I-Specs, F-Specs, and ??, but also from the IDDU File Definitions [at least those] that the IDDU did\could not create as externally described due to restrictions [e.g. record ID codes, as the enablement for the MFPF]. IIRC the tooling was aware of and provided a level of /help/ to resolve conflicts for multiply defined buffer data in subfields, type conflicts, overlaps, plus any missing definitional specifications, as found across multiple program sources over which the tooling was directed.

Regards, Chuck