Re: [sqlite] sqlite on IBM z/OS Unix
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. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea400/priasm.htm On Thu, Aug 30, 2018 at 4:13 PM David Jackson wrote: > Thanks for the various replies to this question. > I have my link working now. It starts off wit a basic 3 line c program (to > establish the LE enclave) that then calls an Asm program that passes the > SQL that then loads and branches to a c program to do the grunt work. There > is an example IBM program that does something similar. > That called c program then returns and is re-invoked any number of times > by the asm caller. I now only open and close the db on the first and final > call. > So all is good as far as that goes . > > The challenge is to now determining a means of getting the query result set > back to the calling asm program in a usable format. > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite on IBM z/OS Unix
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, 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 > 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 > > sqlite-users@mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > 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 sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite on IBM z/OS Unix
"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 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 > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite on IBM z/OS Unix
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- >boun...@mailinglists.sqlite.org] On Behalf Of David Jackson >Sent: Wednesday, 29 August, 2018 16:26 >To: sqlite-users@mailinglists.sqlite.org >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 >sqlite-users@mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite on IBM z/OS Unix
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 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 > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
