sqlite on IBM z/OS Unix

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

sqlite on IBM z/OS Unix

davidkjackson
Having successfully ported sqlite to z/OS Unix as a 32 bit app, I am now
looking at a c program to make SQL calls to this.
Starting with an Assembler routine that runs within z/OS (not Unix), which
is not LE (Language Environment)enabled, we then call a c routine (numerous
times) that is LE enabled. That is all working fine and making good SQL
calls to sqlite. the c program then returns back to the upper assembler
calling program. The problem is that the c routines is opening, issuing the
SQL and closing on each invocation.

Now this may be a dumb question, so apologies up front.
Is there any way that the c program can open the sqlite db initially on the
first call and keep it open after it returns back to the calling program
until a final call at which point it will issue the sqlite3_close.

Again - sorry if this was a dumb question.

Thanks
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite on IBM z/OS Unix

Chris Brody
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 end of each C function call then this would be an
issue with your z/OS environment.

Assuming that the "Language Environment" does not automatically
release resources, I can think of a the following alternative
approaches:

1: C code opens the database and stores the handle in a static variable.
2: C code opens the database and returns the pointer to the assembly
code; assembly code would then include the returned pointer value in
subsequent calls to the C code.
3a: C code opens the database, stores it in a structure on the heap,
and returns the pointer to the structure back to the assembly code
which is then used in subsequent calls to the C code
3b: C code opens the database, stores it in a structure on the heap,
maintains some kind of hash table or other key-value map, and returns
a numerical value to the assembly program which is then used in
subsequent calls to the C code

I suspect it should be pretty straightforward (easy) to search for
documentation on each of the approaches above. I think this could be
similar to interfacing between C and higher-level languages such as
Java, Python, C++, etc.

I would compare alternatives 2 and 3a to how FILE pointers work
between stdlib and C programs, also to how sqlite3 database pointers
work between sqlite3 library and application code in C..

I hope this is helpful to you and other readers on the list. Please do
not hesitate to ask if anything does not sound right or is not clear.

Chris

https://www.linkedin.com/in/chrisbrody/

On Wed, Aug 29, 2018 at 6:26 PM David Jackson <[hidden email]> wrote:

>
> Having successfully ported sqlite to z/OS Unix as a 32 bit app, I am now
> looking at a c program to make SQL calls to this.
> Starting with an Assembler routine that runs within z/OS (not Unix), which
> is not LE (Language Environment)enabled, we then call a c routine (numerous
> times) that is LE enabled. That is all working fine and making good SQL
> calls to sqlite. the c program then returns back to the upper assembler
> calling program. The problem is that the c routines is opening, issuing the
> SQL and closing on each invocation.
>
> Now this may be a dumb question, so apologies up front.
> Is there any way that the c program can open the sqlite db initially on the
> first call and keep it open after it returns back to the calling program
> until a final call at which point it will issue the sqlite3_close.
>
> Again - sorry if this was a dumb question.
>
> Thanks
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite on IBM z/OS Unix

Keith Medcalf
In reply to this post by davidkjackson

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:

run z/OS assembly
call "C" LE
  initialize environment
  ... do stuff in environment
  tear down environment and release all its resources
carry on in z/OS assembly

or is it more like:

run z/OS assembly
call "C" LE
  initialize LE environment if it is not initialized otherwise use existing environment
  ... do stuff in environment
carry on in z/OS assembly
... eventually when process ends clean up the LE environment if it exists

If the latter then you should be able to open the database and keep a static pointer to the sqlite3 structure across "jumps" into the LE environment.  If the environment and all its resources are released (as in the former case) when you return back to native z/OS then obviously you cannot do that.  Which one it does is probably documented somewhere, however, I would suspect the latter case (initialize only once) for performance reasons, unless the LE environment is another "process" ...

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.


>-----Original Message-----
>From: sqlite-users [mailto:sqlite-users-
>[hidden email]] On Behalf Of David Jackson
>Sent: Wednesday, 29 August, 2018 16:26
>To: [hidden email]
>Subject: [sqlite] sqlite on IBM z/OS Unix
>
>Having successfully ported sqlite to z/OS Unix as a 32 bit app, I am
>now
>looking at a c program to make SQL calls to this.
>Starting with an Assembler routine that runs within z/OS (not Unix),
>which
>is not LE (Language Environment)enabled, we then call a c routine
>(numerous
>times) that is LE enabled. That is all working fine and making good
>SQL
>calls to sqlite. the c program then returns back to the upper
>assembler
>calling program. The problem is that the c routines is opening,
>issuing the
>SQL and closing on each invocation.
>
>Now this may be a dumb question, so apologies up front.
>Is there any way that the c program can open the sqlite db initially
>on the
>first call and keep it open after it returns back to the calling
>program
>until a final call at which point it will issue the sqlite3_close.
>
>Again - sorry if this was a dumb question.
>
>Thanks
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite on IBM z/OS Unix

Don V Nielsen
In reply to this post by davidkjackson
"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. Are you saying the LE is loading
and not unloading. I would guess that it is, and it is that which is
closing the connection. I'm sorry, but I'm 10+ years past working with
mainframes. But I recall having to do something special when calling
LE-Cobol from assembler. There was something that needed to be communicated
to say "Get up and stay up until I tell you to close", otherwise, you are
continually loading and unloaded LE with every call.

Wish I could be more helpful,
dvn

On Wed, Aug 29, 2018 at 5:26 PM David Jackson <[hidden email]>
wrote:

> Having successfully ported sqlite to z/OS Unix as a 32 bit app, I am now
> looking at a c program to make SQL calls to this.
> Starting with an Assembler routine that runs within z/OS (not Unix), which
> is not LE (Language Environment)enabled, we then call a c routine (numerous
> times) that is LE enabled. That is all working fine and making good SQL
> calls to sqlite. the c program then returns back to the upper assembler
> calling program. The problem is that the c routines is opening, issuing the
> SQL and closing on each invocation.
>
> Now this may be a dumb question, so apologies up front.
> Is there any way that the c program can open the sqlite db initially on the
> first call and keep it open after it returns back to the calling program
> until a final call at which point it will issue the sqlite3_close.
>
> Again - sorry if this was a dumb question.
>
> Thanks
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite on IBM z/OS Unix

John McKown
On Thu, Aug 30, 2018 at 11:12 AM Don V Nielsen <[hidden email]>
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, all my HLASM for UNIX
program is LE based (starts up via a CEEENTRY macro) just so that I can use
C language subroutines. This doesn't seem to have any real drawbacks, other
than some learning and recoding the startup/return stuff. The parameter
passing is the same and an HLASM LE routine can do anything that a non-LE
can do, as best as I know.

If anyone is curious about a z/OS UNIX program written in LE HLASM, here:
https://github.com/JohnArchieMckown/utilities-1/blob/master/lsenq.s

This program also shows how to get to the UNIX arguments from the shell
command line. It is not as simple as in z/OS batch. More akin to a TSO
command processor, albeit different.



>
> It is not SqlLite. It is that communication mechanism between the non-LE
> program calling into the LE environment. Are you saying the LE is loading
> and not unloading. I would guess that it is, and it is that which is
> closing the connection. I'm sorry, but I'm 10+ years past working with
> mainframes. But I recall having to do something special when calling
> LE-Cobol from assembler. There was something that needed to be communicated
> to say "Get up and stay up until I tell you to close", otherwise, you are
> continually loading and unloaded LE with every call.
>
> Wish I could be more helpful,
> dvn
>
> On Wed, Aug 29, 2018 at 5:26 PM David Jackson <[hidden email]>
> wrote:
>
> > Having successfully ported sqlite to z/OS Unix as a 32 bit app, I am now
> > looking at a c program to make SQL calls to this.
> > Starting with an Assembler routine that runs within z/OS (not Unix),
> which
> > is not LE (Language Environment)enabled, we then call a c routine
> (numerous
> > times) that is LE enabled. That is all working fine and making good SQL
> > calls to sqlite. the c program then returns back to the upper assembler
> > calling program. The problem is that the c routines is opening, issuing
> the
> > SQL and closing on each invocation.
> >
> > Now this may be a dumb question, so apologies up front.
> > Is there any way that the c program can open the sqlite db initially on
> the
> > first call and keep it open after it returns back to the calling program
> > until a final call at which point it will issue the sqlite3_close.
> >
> > Again - sorry if this was a dumb question.
> >
> > Thanks
> > _______________________________________________
> > sqlite-users mailing list
> > [hidden email]
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>


--
People who frustrate us will be around for as long as we need them.

Maranatha! <><
John McKown
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users