Zend access to QS36F Files

[steven_spencer]

Hi,

Newbie here. Would like to know about Zend access to QS36F files on the iSeries. Are there differences compared to the DB2 access (where the file layouts are compiled into the file and are available to Zend at the time of access, if Zend uses that). And where does Zend make or find the file layouts ? .. on an iSeries descriptor like IDDU or F&I, or internally within the Zend Studio file layouts (however those are maintained). And does it work the same as with DB2, or are there structural or access time differences ?

Any help appreciated.
Thanks.

Steven Spencer
Bayside, NY

[aseiden]

Hi, Steven,

Are the files externally described (with DDS), or only internally described (in programs)?

--Alan Seiden

[steven_spencer]

Hi,

Program described only.

Although I could easily make up DDS specs from my main F&I that I use simply as a guidepost.

Is there an issue of data unconforming (e.g. blanks instead of zeros)?
I don't mind cleaning up data in that manner.

Steven

[aseiden]

Steven, if you create DDS, apply it to the files, and clean up the data, PHP will be able to access the files with SQL.

Alan

P.S. Are you familiar with the LISUG user group? They meet in Long Island monthly. There's quite a bit of PHP on IBM i expertise in that group. I attend every few months or so. Worth going. (lisug.org).

[steven_spencer]

Hi,

Alan, I saw you gave an interesting talk on Zend and PHP a couple of months ago. No meeting this month though. I haven't been for awhile but can come maybe next month.

When you say "apply it to the files", I'm not sure whether you mean just have it available matching the data, or actually physically compile the files. I'm not sure if that compiling will affect the normal RPG programs running on the files (assuming the data is not off-kilter).

Steven

[aseiden]

Hi, Steven,

I meant actually recompiling the files, or possibly CHGPF (specifying the DDS source) without recompiling.

A data mismatch is the biggest danger. But try a test to see.

Alan

[steven_spencer]

Hi,

Thanks.

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.

Steven