× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



These threads are about the hardest to read. I'm out on this thread.

On Fri, Mar 16, 2012 at 3:13 PM, Steven Spencer
<stevenspencer@xxxxxxxxxx> wrote:
Hi,

 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
....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..... > 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.

Chuck Pence
   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.

=================================================

Steven Spencer

My main interest in special access at this time is the group of query
programs and 4GLs, native utilities, and SQL-lineage utilities.  Here
is how I see the four groupings (yes, I am omitting some SQL-oriented
development environments, feel free to add to and tweak or even
disrupt my groups).

a) 4GLs  - Lansa, Magic, WinDev, maybe EGL

b) iSeries utilities - Surveyor, NGS, MRC and more

c) DBVisualizer, Aquafold, AQT, Squirrel, JasperForge and BIRT/Actuate and more

d) iSeries SQL

What you say, I am going to guess, applies, in general, to

(c) and (d) , although I would especially like verification on (d)
and some of (c).  Remember that some of (c) are inquiry utilities
anyway, so the "barely accessible" is ok.

(a) from what I understand, generally gives a method in their
environment, although it may in some cases be a user defined table
that is not limited, in that environment. And if that is the nature
of the workaround, packed fields have to be "no problemo"

(b) is not really SQL and generally they have handled this question,
due to the iSeries lineag.

=================================================

Chuck Pence
   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.

Steven
This is a little hard to follow. I think you are saying that first we
must have SQL access.

Chuch Pence
   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.]

Steven
Understood. And this is the pattern followed by NGS, which bills
itself as a superior "Query"

Chuck Pence
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.

Steven
As long as they, or anybody, gets it done, would there be any major
problem in this alternative ?

Thanks for the backdrop.  I realize that most people don't care too
much about this, since they went to DB2 long ago, and many of the
people using QS36F are intimidated a bit by the many options and
confusions.  I'm just trying to work it through.

Steven Spencer
Queens, NY

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.