This is what I was trying to remember. It is for calling LE Cobol, but it
demonstrates the use of the CEEENTRY and CEETERM macro that are used to
establish the environment without having to use a LE C stub program. I used
to use the Cobol stub method in the past.
On Thu, Aug 30, 2018 at 11:12 AM Don V Nielsen
wrote:
> "Having successfully ported sqlite to z/OS Unix as a 32 bit app"
>
> Totally Awesome! Do I have a solution? No. But I'll bet John McKown will. I
> believe he is a guru with the mainframe.
>
I don't know about being a "guru". Personally,
"Having successfully ported sqlite to z/OS Unix as a 32 bit app"
Totally Awesome! Do I have a solution? No. But I'll bet John McKown will. I
believe he is a guru with the mainframe.
It is not SqlLite. It is that communication mechanism between the non-LE
program calling into the LE environment.
I am not familiar with the internals of z/OS ... YMMV.
My initial take would be that it would depend on whether the LE remains active
(initialized) and maintains its memory allocations/file opens, etc, between
invocations from your native z/OS assembly code. That is to say is the
sequence:
It is not clear to me why your program closes the sqlite3 database at
the end of each C function invocation. AFAIK sqlite3 should not close
any database connection unless your program invokes sqlite3_close. If
something in the "Language Environment" closes and releases internal
resources at the
5 matches
Mail list logo
