Re: the RPG problem - adrift in the PC-web wind

On 14-Mar-2012 07:34 , Steven Spencer wrote:

DDS source is easy to create, for flat QS36F data. If the situation
where the utilities read only the operating system compiled DDS ...
that is more involved (although I could fake it out with dummy
files, as long as the data is pointed to in QS36F). Anyway, my
experience so far is that most utilities are savvy.

If they are iSeries utilities (Lansa, NGS, etc) they addressed this
years ago, and they really do not care if it is QS36F or DB2. Lansa
I think has you enter their data dictionary, a bit of hand-work,
while NGS reads the DDS or some other source member.

If they are ported stuff, SQL-based, then you have to check
utility-by-utility. There can be problems. They may read the OS
that only defines the file as one big field, (based on BLDFILE or
File-name,Disp-new, and the key field as a divider. They would have
had to develop an alternative, and may never have bothered.

If the HTML reporting only reads a DDS source member, sitting in
QDDSSRC, then I would simply put one there.

The SQL can _access_ data from /flat files/ directly, but the capability is very limited; difficult and unpleasant at best. There was [and I believe still is] no support to CREATE VIEW over a flat file. The SQL will recognize only the /program described/ definition; i.e. the BLDFILE version as presented by DSPFFD, and will not redirect to the File\Format\Field definitions of a linked IDDU definition nor to any other separate dictionary\dictionary-like to dynamically describe the data. The data would be accessible to the SQL when the access is defined by and to the SQL, as described data [columns], such as with a User Defined Table Function. But that UDTF definition alone would only directly enable SELECT FOR READ ONLY access, so the file\data are still barely accessible via the SQL.

So while Nathan had suggested that "Before you can use tooling to generate mobile applications, your first step must be to externally define your physical files, and learn how to create SQL views" is a stretch [hyperbole?], to enable the SQL access generally and most easily effectively requires the alluded conversion. Surely that was the intended point of that comment.

FWiW, CQE-based utilities that would presumably perform SQL-like query functions [Query/400 being one example] can access the IDDU definition of a program-described file linked to an IDDU dictionary. The integrated DB2 for i[/5 etc.] SQL was not enabled to do so, even when implemented via CQE. So while some "iSeries utilities" could process SQL SELECT statements to perform query activity against a "QS36F file", the application may be implemented via the QQQQRY API using the CQE rather than using the actual DB2 for i SQL.

Regards, Chuck