On Thu, Aug 30, 2018 at 11:12 AM Don V Nielsen <donvniel...@gmail.com> 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 <davidkjackso...@gmail.com> > 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
