If I do not want to actually change the files to compiled "native" files, my understanding now is that there is a type of "Alias" command that can point to a dummy DDS compiled file in another library. A friend gave the syntax and when I find it I can place it here. With an Alias, the source member is the dummy file, while the physical file will be the QS36F physical.
(Perhaps, technically, the QS36F one should be called the Alias, the point is that the DDS source in an empty compiled file in another library is paired to the actual QS36F data, which is a flat file that knows nothing directly about DDS-source-compiledness .) Zend and PHP work with that pairing.
Clearly if the data is off-kilter in QS36F, unpredicatable results can occur. That can be handled step-by-step, issues like blanks and zeros. It depends on how strict is Zend on those issues. Presumably multi-record-types are handled fine by proper DDS pointing to the subset logical within the physical. I'm not sure offhand if there are any other special considerations.
If I try to actually make the files in QS36F into compiled files, (what I think is meant by applying the DSS, or recompiling the files) then there might be questions about my RPG II programs and OCL calling the files. Perhaps there needs to be some upgrade of the RPG or the screens, or changes to OCL. So, while I might do some tests, I am in no rush to go that route.