RE: Difference bet. Primary and Full procedural file.

Doug, I agree with you on the following:
a).ability to do free format embedded SQL inside RPG.
b).ability to use qualified subfield names

The rest, I don't know if I could or not because both of us are in different
environments. Its been a long time since I had to deal with O Specs. Never
had to use the /If and /Define and other directives. Was able to use SQL
functions in a lots of places instead of the RPG BIFs. All this most
probably due to the fact that our database is designed with SQL in mind.
Data Redundancy, business rules, etc... played a role in our doing things a
particular way.

I am sure if I was working in a different type of environment I would say
the same stuff that you said.

-----Original Message-----
From: Douglas Handy [mailto:dhandy1@bellsouth.net]
Sent: Thursday, May 23, 2002 9:32 AM
To: rpg400-l@midrange.com
Subject: Re: Difference bet. Primary and Full procedural file.

Ramanujam,

>any specifics pls? Just 4 or 5 would be good enough.

Here's a partial list of things IBM asked in a survey a year ago to see how
important they were for IBM to "enhance" the precompiler to support.  IMHO,
that
is just spin for not calling the precompiler broke.  Here is a sampling:

a. Full support for properly parsing RPG subprocedures

The current version of the SQL precompiler doesn't properly parse some
source members that have subprocedures. For example, O-specs may cause an
erroneous "out of sequence" error. This enhancement would have the SQL
precompiler properly parse source members with subprocedures.

b. Support for using a local variable in a subprocedure as a host variable
in an SQL statement

RPG IV lets you declare a local variable within a subprocedure. A local
variable can have the same name as a global variable or a local variable in
a different subprocedure. The current version of the SQL precompiler doesn't
properly handle scoped variables. This enhancement would have the SQL
precompiler support the same variable scoping rules as the ILE RPG compiler.
For example, if you had a global variable X and a local variable X in the
subprocedure P, any embedded SQL statement within P that referred to :X
would be treated as referring to the local variable.

c. Full support for the V5 qualified subfield names based on the new RPG IV
D-spec QUALIFIED keyword

d. Conditional precompilation: /If, /Define, and other directives

e. Nested /Copy

These are just a sampling since you asked for 4-5.  The point is that there
is
lots of stuff which is perfectly legitimate RPG code, which must be avoided
if
you want embedded SQL to compile.  And this list ignores loads of new BIFs,
the
ability to use free format calcs, etc.

The precompiler doesn't even support everything the V3R7 compiler did!  And
that
was what, 1996 or so?  Think how much RPG has improved since then, and
consider
that you can use the features if you *don't* use SQL, and can't if you do.

And they want us to believe that SQL is the strategic direction we should
move?

Toronto is doing a terrific job;  Rochester (or whoever) needs more
resources.

Just my .02,
Doug
_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.