Cobol - SQL and precompilers (was: In answer to RW

Author

SQL and precompilers (was: In answer to RW - again (was: Sorts (revised)

William M. Klein

2004-07-19, 8:55 pm

"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40fb3bbd.18924056@news.optonline.net...
> "William M. Klein" <wmklein@nospam.netcom.com> wrote:
Snip>
>
> I don't think BASED would make any difference. The problem occurs in PL/SQL
> programs shipped to the server. Precompiler generated code must replace
> references to Cobol host variables with the value of those variables. If they
> don't exist, it should replace the value with a null string. The Oracle
> precompiler doesn't do that now, so I doubt it would act differently under
> BASED.
>

I don't understand a precompiler that

"must replace references to Cobol host variables with the value of those
variables"

I have only worked with a few precompilers, but I haven't EVER seen it do that.
(I have lost the origin of this part of the current thread, so I don't know the
exact code or if you were running on supported software to whose vendor you
reported the problem).

The precompilers that I know of do not look at the VALUE of host-variables, but
rather to their "location". In the case of ANY *LINKAGE SECTION* item, the
exact "virtual address" canNOT be determined at precompile time. In fact, if
this were true, a subprogram referencing host-variables could ONLY be called by
a single program. This has nothing to do with whether the Linkage Section
host-variable has its address "set" by referencing data in the calling program
(BY CONTENT or BY REFERENCE) or by an explicit SET ADDRESS OF statement within
the Procedure Division of the called subprogram.

Robert,
Did the "environment" where you had this problem support OTHER types of
Linkage Section items as Host Variables? If so, I really do not understand the
problem (and would certainly communicate with both the compiler and precompiler
vendors to determine if this is an "acknowledged bug" or not.)

Again, as I wasn't able to find the specifications of the original program, I
may be misunderstanding exactly what the problem was, but from this part of the
thread something seems odd to me.

--
Bill Klein
wmklein <at> ix.netcom.com

Robert Wagner

2004-07-20, 3:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote:

>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40fb3bbd.18924056@news.optonline.net...
>Snip>
it[color=darkred]
>
>I don't understand a precompiler that
>"must replace references to Cobol host variables with the value of those
>variables"
>
>I have only worked with a few precompilers, but I haven't EVER seen it do that.
>(I have lost the origin of this part of the current thread, so I don't know the
>exact code or if you were running on supported software to whose vendor you
>reported the problem).

The PL/SQL statement said:

if :COBOL-INDICATOR = 'N' then
PLSQL_VARIABLE := ANOTHER_PLSQL_VARIABLE;
else
PLSQL_VARIABLE := :OPTIONAL-COBOL-VARIABLE;
end if;

The indicator contained 'N' and the pointer to OPTIONAL-COBOL-VARIABLE was null.

In the preprocessor output, the inline PL/SQL program had been moved to a big
literal in working-storage. References to Cobol host variables had been replaced
by generated names such as ":b1", which did not exist in the intermediate file.

This implies the generated code is doing an EXECUTE IMMEDIATE on the big
literal. Before that execution, it is getting the addresses of the Cobol
variables (with SQLADDR) and storing them in a generated structure. Their
position in the structure must somehow relate them to the undefined "b1".

Here is the problem: the target of EXECUTE IMMEDIATE (as with PREPARE) is not
permitted to refer to variables outside the block of code. One must replace the
placekeeper :b1 with a value before issuing the EXECUTE IMMEDIATE. Oracle must
have a client-side 'editor' function doing that. The program is abending during
that editing, even though the optional variable would not be referenced at
execution time.

If the pointer were changed from a parameter pointer to a BASED data-pointer, it
would fail the same way .. because in both cases the structure would contain a
null pointer. The editor doesn't know nor care where the pointer came from.

The fix is simple. In the editor, if a pointer is null, put a null string into
the source code. Don't cause an abend by trying to use it. The error is not in
the precompiler, it's in the editor.

>The precompilers that I know of do not look at the VALUE of host-variables, but
>rather to their "location". In the case of ANY *LINKAGE SECTION* item, the
>exact "virtual address" canNOT be determined at precompile time. In fact, if
>this were true, a subprogram referencing host-variables could ONLY be called by
>a single program. This has nothing to do with whether the Linkage Section
>host-variable has its address "set" by referencing data in the calling program
>(BY CONTENT or BY REFERENCE) or by an explicit SET ADDRESS OF statement within
>the Procedure Division of the called subprogram.

As I said, host variables are not permitted in a block that will be PREPAREd or
EXECUTEd IMMEDIATE. Why? Because in the old days, they were compiled and
executed on the server, which did not have access to the client's memory.

You may have seen shops where the in-house standard said _every_ SQL statement
must be PREPAREd. It is a real PITA having SQL in working-storage and the
corresponding host variables in procedure division FROM and INTO clauses. It
makes maintenance error-prone. The reason behind this is servers used to be much
faster than desktop machines, which made execution on the server faster than
execution on the client. Someone discovered that by running a timing test, then
created a shop standard that's being followed today, long after the technical
reason for it became obsolete .. and everyone forgot WHY the standard was
created.

It's not the first or last instance of shop standards that no longer make sense.

>Robert,
> Did the "environment" where you had this problem support OTHER types of
>Linkage Section items as Host Variables?

Yes, they are used routinely.

>If so, I really do not understand the
>problem (and would certainly communicate with both the compiler and precompiler
>vendors to determine if this is an "acknowledged bug" or not.)

I hope you understand the problem now. I doubt Oracle support people would.

The broken code had been promoted to QA and was causing previously 'certified'
programs to abend. I had one hour to fix it .. not enough time to communicate
with notoriously slow Oracle support. I fixed it by changing
:OPTIONAL-COBOL-VARIABLE to a working-storage item that has a valid address,
even though it would not be used at execution time.

Sponsored Links