Roland,

        thank you VERY much for sharing your findings. Appreciated!

I think that the ability to compile SQLite on z/OS out of the box is a 
great achievement. We'll need to make sure that this will still hold 
true for future releases.

While using your dump procedure allows exchanging data-bases with other 
platforms, I think that having a fully compatible z/OS version is 
something we should aim to.

Back then I had a look at the xlc ASCII options, but I seem to remember 
there were drawbacks. Need to find my notes about it.

Regardless, it is good to see that things move on.

Thanks again for your work on this and for your will to share it.

mario

On 12/30/2015 10:43 PM, Roland Martin wrote:
> Hi Mario, I was using SQLite 3.8.6 up to this point on z/OS with a couple of
> minor code changes which are now included in version 3.9.2. With the fix
> Richard provided this morning all functionality I have tested so far is
> working out of the box with no code changes on z/OS.
>
> The databases I use are EBCDIC based (not UTF-8) so there is no moving them
> as-is to Windows or Linux. The way I work around this is to export via:
>
> sqlite3 test.db ".dump" > test.sql
>
> FTP test.sql to Windows/Linux in ascii mode and then import. The reverse can
> also be done.
>
> I have not tried using it but xlc has the ASCII option documented here:
>
> https://www-01.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13
> .cbcux01/ascii.htm
>
> You should experiment with this option, it might get you closer to your
> goal. With it SQLITE_ASCII will be defined, not SQLITE_EBCDIC since 'A'  in
> the code below (line 9576 in sqlite3.c) would be an ASCII 'A'.
>
> #if 'A' == '\301'
> # define SQLITE_EBCDIC 1
> #else
> # define SQLITE_ASCII 1
> #endif
>
>
> The origins of the build scripts below are fuzzy but I believe most of the
> options come from running configure and then copying out from the makefile.
> Some xlc specific options have been added from reading and trial and error.
> Compiling sqlite3.c:
>
> xlc \
> -DPACKAGE_NAME=\"sqlite\" \
> -DPACKAGE_TARNAME=\"sqlite\" \
> -DPACKAGE_VERSION=\"3.9.2\" \
> -DPACKAGE_STRING=\"sqlite\ 3.9.2\" \
> -DPACKAGE_BUGREPORT=\"http://www.sqlite.org\"; \
> -DPACKAGE_URL=\"\" \
> -DPACKAGE=\"sqlite\" \
> -DVERSION=\"3.9.2\" \
> -DSTDC_HEADERS=1 \
> -DHAVE_SYS_TYPES_H=1 \
> -DHAVE_SYS_STAT_H=1 \
> -DHAVE_STDLIB_H=1 \
> -DHAVE_STRING_H=1 \
> -DHAVE_MEMORY_H=1 \
> -DHAVE_STRINGS_H=1 \
> -DHAVE_INTTYPES_H=1 \
> -DHAVE_STDINT_H=1 \
> -DHAVE_UNISTD_H=1 \
> -DHAVE_DLFCN_H=1 \
> -DLT_OBJDIR=\".libs/\" \
> -DHAVE_USLEEP=1 \
> -DHAVE_LOCALTIME_R=1 \
> -DHAVE_GMTIME_R=1 \
> -DHAVE_DECL_STRERROR_R=1 \
> -DHAVE_STRERROR_R=1 \
> -D_REENTRANT=1 \
> -DSQLITE_THREADSAFE=1  \
> -DSQLITE_ENABLE_FTS3 \
> -DSQLITE_ENABLE_RTREE \
> -O3 \
> -I. -V \
> -DSQLITE_OMIT_MERGE_SORT \
> -DSQLITE_MAX_MMAPSIZE=1048576 \
> -qTARG=zOSV1R11  \
> -q64 \
> -qstrict \
> -qLANG=EXTENDED \
> -qFLOAT=IEEE \
> -qnolist \
> -qnosource  \
> -D_POSIX_C_SOURCE=200112L \
> -D_XOPEN_SOURCE=600 \
> -c \
> -o sqlite3.o sqlite3.c
>
> Compiling shell.c:
>
> xlc \
> -DPACKAGE_NAME=\"sqlite\" \
> -DPACKAGE_TARNAME=\"sqlite\" \
> -DPACKAGE_VERSION=\"3.9.2\" \
> -DPACKAGE_STRING=\"sqlite\ 3.9.2\" \
> -DPACKAGE_BUGREPORT=\"http://www.sqlite.org\"; \
> -DPACKAGE_URL=\"\" \
> -DPACKAGE=\"sqlite\" \
> -DVERSION=\"3.9.2\" \
> -DSTDC_HEADERS=1 \
> -DHAVE_SYS_TYPES_H=1 \
> -DHAVE_SYS_STAT_H=1 \
> -DHAVE_STDLIB_H=1 \
> -DHAVE_STRING_H=1 \
> -DHAVE_MEMORY_H=1 \
> -DHAVE_STRINGS_H=1 \
> -DHAVE_INTTYPES_H=1 \
> -DHAVE_STDINT_H=1 \
> -DHAVE_UNISTD_H=1 \
> -DHAVE_DLFCN_H=1 \
> -DLT_OBJDIR=\".libs/\" \
> -DHAVE_USLEEP=1 \
> -DHAVE_LOCALTIME_R=1 \
> -DHAVE_GMTIME_R=1 \
> -DHAVE_DECL_STRERROR_R=1 \
> -DHAVE_STRERROR_R=1 \
> -D_REENTRANT=1 \
> -DSQLITE_THREADSAFE=1  \
> -DSQLITE_ENABLE_FTS3 \
> -DSQLITE_ENABLE_RTREE \
> -O3 \
> -I. -V \
> -DSQLITE_OMIT_MERGE_SORT \
> -DSQLITE_MAX_MMAPSIZE=1048576 \
> -qTARG=zOSV1R11  \
> -q64 \
> -qstrict \
> -qLANG=EXTENDED \
> -qFLOAT=IEEE \
> -qnolist \
> -qnosource  \
> -D_POSIX_C_SOURCE=200112L \
> -D_XOPEN_SOURCE=600 \
> -c \
> -o shell.o shell.c
>
> Linking the two together for a sqlite3 executable:
>
> xlc -q64 -o sqlite3 shell.o sqlite3.o
>
> Hope this helps - Roland
>
> -----Original Message-----
> From: mbezzi [mailto:mbezzi at tiscali.it]
> Sent: Wednesday, December 30, 2015 11:21 AM
> To: SQLite mailing list; rolandsmartin at gmail.com
> Subject: Re: [sqlite] Function patternCompare() not EBCDIC friendly
>
> Roland,
>
>     I am pleased to see that you are successfully using SQLite on z/OS.
> Are you using the standard amalgamation? Did you need to apply special mods
> to SQLite to work on z/OS? Would you mind sharing your build procedure?
>
> Few months ago I tried compiling SQLite on z/OS: It worked but the
> data-bases generated on z/OS contains text data in EBCDIC format, including
> metadata, which makes those data-bases unusable on other platforms. The
> opposite was also true in my experience: Data-bases created on other
> platforms (I tried Linux) are not usable on z/OS for the very same reason.
>
> At that time I've spent some time trying to find where SQLite required to be
> modified to change this behavior, but this resulted a too hard assignment
> given my limited understanding of SQLite internals.
>
> Did you face the same issue? Did you find a solution? Anybody willing to
> help here giving guidance on what should be changed in SQLite to have text
> data and meta-data stored in UTF-8 format under z/OS?
>
> Thank you,
> mario
>
>
> On 12/30/2015 04:55 PM, Roland Martin wrote:
>> I have tested the code change on z/OS and it works.
>>
>> Thanks for the quick turnaround!
>>
>> Roland Martin
>>
>> -----Original Message-----
>> From: drhsqlite at gmail.com [mailto:drhsqlite at gmail.com] On Behalf Of
>> Richard Hipp
>> Sent: Wednesday, December 30, 2015 9:08 AM
>> To: SQLite mailing list
>> Cc: rolandsmartin at gmail.com
>> Subject: Re: [sqlite] Function patternCompare() not EBCDIC friendly
>>
>> On 12/30/15, Roland Martin <rolandsmartin at gmail.com> wrote:
>>> Working with version 3.9.2 on IBM z/OS case insensitive LIKE queries
>>> do not work if case does not match.
>>
>> Please test and let us know if the
>> https://www.sqlite.org/src/info/0a99a8c4facf65ec check-in fixes your
> problem.
>>
>> --
>> D. Richard Hipp
>> drh at sqlite.org
>>
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users at mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
>
>

Reply via email to