Re: Difference bet. Primary and Full procedural file.

[Douglas Handy <dhandy1@xxxxxxxxxxxxx>]

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