RE: Embedded SQL + Closing an ODP

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

I wonder if this is a normal behavior of embedded SQL.  I've recently begun
working with the latest version of the BPCS ERP package, and have come
across a rather nasty situation.  It seems that what SSA did was to create a
fat order entry client in C, then when their fat client initiative failed,
they rewrote the C code into AS/SET code on the AS/400 and made it into a
green screen.  I'm sure you can see that there are quite a few scary things
in that statement, but let's move to the specific one.

Evidently, the C programmer was fond of using SELECT INTO, and in fact would
use this regularly to retrieve single fields from different files.  These
got translated back to the AS/400 as embedded SQL in the generated RPG code
(AS/SET, for those who haven't worked with it, is basically a CASE tool that
generates RPG code).

So now we have a 44000-line (yes, that's 44000 - as in cannot be edited by
SEU) RPG program with embedded SQL.  I ran the program recently to try and
see where a certain field was getting updated, and for the heck of it, I did
a quick check of the open files using option 14 of DSPJOB.  I almost choked
when I saw that there were FOUR HUNDRED AND FORTY THREE open data paths.
Many files had 20 or more ODPs over them.  I am assuming that this is
because of the various SELECT INTO statements.

What do you folks think?


> -----Original Message-----
> From: owner-midrange-l@midrange.com
> [mailto:owner-midrange-l@midrange.com]On Behalf Of David Keck
> Sent: Sunday, February 11, 2001 2:29 AM
> To: Midrange-L
> Subject: Embedded SQL + Closing an ODP
>
>
> I have an ILE RPG program comprised in part of an SQLRPGLE
> module, compiled
> with
>
> Commitment control  . . . . . . . . . . . . . . . . . :   *NONE
> Relational database . . . . . . . . . . . . . . . . . :   *LOCAL
> Naming convention . . . . . . . . . . . . . . . . . . :   *SYS
> Allow copy of data  . . . . . . . . . . . . . . . . . :   *OPTIMIZE
> Allow blocking  . . . . . . . . . . . . . . . . . . . :   *ALLREAD
> Delay PREPARE . . . . . . . . . . . . . . . . . . . . :   *NO
> Close SQL cursor  . . . . . . . . . . . . . . . . . . :   *ENDMOD
>
> After ...
>
> C/EXEC SQL open @Cursor
> C/END-EXEC
>
> an ODP is created as can be seen via WRKJOB 14.  Later, immediately after
> ....
>
> C/EXEC SQL close @Cursor
> C/END-EXEC
>
> the file is still open, which I find perplexing and vexing.  With the file
> open the program maintains a member lock which interferes with other
> elements of the system.
> How can I close the ODP and release related locks without ending
> the program
> containing the embedded SQL ?  A solution which works at V3R2 would be
> ideal.
>
> Thanks - Dave K.
>
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---