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

And you were already active in 2008 .....

Hi WinDev Friends,

Nice forum .

We (food importer, about 15 users) went to the SSP running on the

AS/400 (ISeries) to the true AS/400 op-sys recently, although the

application programs and data files remain Sys 36 (Library-QSF36).

We have an element of our programs that run on Filemaker (duplicate

data, a bit clunky) that we would surely like to replace and we would

in general like to move more into a modern PC/GUI world accessing our

solid AS/400 data. Inquiries and reports first, updates as an extra

long-term nicety. We do see that some or all of our programs and data

should best move to the AS/400 conversion. However, having multiple

record types here and there, and limited resources, such decisions

must be made carefully .. lest we bite off more than we can chew.

(This concern is especially significant if we go to the heftier $$

Magic alternative below, and then find we cannot do very much with

it without weeks or months of program transformation .. in fact we

will also be looking into the RPG program transformation tools,

since we have no desire to rewrite everything top-to-bottom, accounting,

inventory, etc. in WinDev or Magic. Tis a one-man shop, and the daily

programs are very specialty custom-tailored.)

A few ways of moving from A to Z are being considered, with two

having demo'd nicely and seeming to be excellent fits. On the higher

end of cost, Magic Software. On a much more moderate level, WinDev.

This is the type of small business need where cost is secondary

to robustness, support, power, flexibility, comfort, etc. and both

products seem quite promising. Both products also seem to have

specialized in AS/400 integration. Of course the advantage of WinDev

as portable without additional runtime licenses is always nice, although

in this particular environment other considerations are primary.

Those who have worked on both WinDev and Magic may be especially

able to note some distinctions that I do not know about. Or simply

comment about learning curve, robustness, speed, etc.

A couple of issues are of special interest. Magic asserts they have

proprietary drivers from the PC to the AS/400 that are superior to an

ODBC connection. I simply do not know how significant that is (it could

lead to better and tighter integration on the program level, and better

speed and reliability)and do not know whether WinDev has anything similar.

Comments and background would be helpful.

From checking it seems that Magic can do very, very little with my

QS36F files, other than reading them as alpha fields (presumably they

could be converted to numeric on the Magic side). Can WinDev do a bit

more ? If someone can explain WinDev's capabilities to work with ye

olde 36 files, it will be appreciated.

Note: the free trial from WinDev does not touch this area, so I

largely have to go by discussions and helps of others that have blazed

away. Even if it means refreshing my high-school parley-vous français

or getting some language assistance. e.g. WinDev does have a specialty

AS/400 forum .. in French. On this trial level, Magic is superior, as

it gives a dongle-less full-blown evaluation copy, so I can play

more directly.

I'll stop here, there is a lot above. I have no interest in bashing

either product, they both seem to be leaders, with WinDev a bit of a

'sleeper' in the USA, just now coming to the fore. I even remember when

Magic used to win the database RAD competitions in NC against Ultimade,

Clarion, FoxPro and a couple of dozen products that came out down through

the pack. And they seem to have, more or less, kept pace with the changing

puter world. While WinDev has been coming forth with a fresher approach

at the same time.

And I could even see both products being a part of my retinue, and

possibly even a part of the food importer, over time. Especially with

WinDev being a rather inexpensive (shhhh..) product for this type of
application.

Your thoughts, feedback, etc. appreciated. On forum, or send me

an email, or we can talk on phone.

Thanks.

Steven Spencer

Programmer

Queens, NY

On Fri, Mar 16, 2012 at 8:28 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Remarkable comments for a person in flat file QS36F


On Fri, Mar 16, 2012 at 8:16 PM, Michael Ryan <michaelrtr@xxxxxxxxx>wrote:

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.

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

--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>