[H390-MVS] Free Database for H390-MVS?

[Jason Froebe [e-mail] [H390-MVS]]

Hi all,

We use DB2 for z/OS at work but I'm hoping that there is a free (to use
or opensource) database for MVS 3.8J somewhere. I'm using the current
MVS 3.8 TK4- release if that helps. I've looked via google but my
google-fu is a bit weak today (it's close to Monday).

jason

[[e-mail] [H390-MVS]]

Post by Jason Froebe ***@gmail.com [H390-MVS]
We use DB2 for z/OS at work but I'm hoping that there is a free (to use
or opensource) database for MVS 3.8J somewhere. I'm using the current
MVS 3.8 TK4- release if that helps. I've looked via google but my
google-fu is a bit weak today (it's close to Monday).

From memory, Jason Winter made
changes to SQLLITE in order for it
to work on JCC, and I think I made
a small change to his work to make
it work on GCC, and I think the
result was posted in this group, with
no real product release and testing,
but I can't remember.

BFN. Paul.

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]

Post by Jason Froebe ***@gmail.com [H390-MVS]
We use DB2 for z/OS at work but I'm hoping that there is a free (to use
or opensource) database for MVS 3.8J somewhere. I'm using the current
MVS 3.8 TK4- release if that helps. I've looked via google but my
google-fu is a bit weak today (it's close to Monday).

From memory, Jason Winter made
changes to SQLLITE in order for it

It's SQLite, not SQLLITE, and Jason
Winter's site appears to be offline, but
I seem to have downloaded it before
it went offline, so try this:

https://groups.yahoo.com/neo/groups/H390-MVS/files/SQLiteMVS.zip

Post by ***@yahoo.com.au [H390-MVS]
to work on JCC, and I think I made
a small change to his work to make
it work on GCC, and I think the
result was posted in this group, with
no real product release and testing,
but I can't remember.

I think this is the post I was talking about:

https://groups.yahoo.com/neo/groups/H390-MVS/conversations/messages/9599

But with the whitespace mangling that
Yahoo Groups would have done, it
probably won't be easy to apply that
patch. It probably needs to be done
manually.

Fortunately I found that I had actually
imported this into CVS, and have now
uploaded my patch as a file instead:

https://groups.yahoo.com/neo/groups/H390-MVS/files/sqlite-jason-v1.txt

The diff is against 3.6.12 which you
can find here:

http://www.sqlite.org/sqlite-3.6.12.tar.gz

Note that both JCC and GCC are provided
with TK4- and JCC is the one most likely
to work.

BFN. Paul.

[Joe Monk [e-mail] [H390-MVS]]

Dont mess with any of Paul's hacked crap.

You can find a straight port of SQLite for MVS in CBT files 897 and 923.

Joe

Post by ***@yahoo.com.au [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]

Post by Jason Froebe ***@gmail.com [H390-MVS]
We use DB2 for z/OS at work but I'm hoping that there is a free (to use
or opensource) database for MVS 3.8J somewhere. I'm using the current
MVS 3.8 TK4- release if that helps. I've looked via google but my
google-fu is a bit weak today (it's close to Monday).

From memory, Jason Winter made
changes to SQLLITE in order for it

It's SQLite, not SQLLITE, and Jason
Winter's site appears to be offline, but
I seem to have downloaded it before
https://groups.yahoo.com/neo/groups/H390-MVS/files/SQLiteMVS.zip

Post by ***@yahoo.com.au [H390-MVS]
to work on JCC, and I think I made
a small change to his work to make
it work on GCC, and I think the
result was posted in this group, with
no real product release and testing,
but I can't remember.

https://groups.yahoo.com/neo/groups/H390-MVS/conversations/messages/9599
But with the whitespace mangling that
Yahoo Groups would have done, it
probably won't be easy to apply that
patch. It probably needs to be done
manually.
Fortunately I found that I had actually
imported this into CVS, and have now
https://groups.yahoo.com/neo/groups/H390-MVS/files/sqlite-jason-v1.txt
The diff is against 3.6.12 which you
http://www.sqlite.org/sqlite-3.6.12.tar.gz
Note that both JCC and GCC are provided
with TK4- and JCC is the one most likely
to work.
BFN. Paul.

[[e-mail] [H390-MVS]]

CBT 897 or CBT 923 will not work for MVS. They require z/OS UNIX System Services.

[[e-mail] [H390-MVS]]

CBT 897 or CBT 923 will not work for MVS 3.8J. They require z/OS UNIX System Services.

[Mike Noel [e-mail] [H390-MVS]]

Those CBT contributions are ZOS (OE) ports, not gonna be usable in turnkey
systems...

['Theodore M Rolle, Jr.' [e-mail] [H390-MVS]]

Before I spend time on compiling PostgreSQL for Hercules, is there a reason
to?
Is DB2 so different that any substitution would be too far out?

Post by Mike Noel ***@gmail.com [H390-MVS]
Those CBT contributions are ZOS (OE) ports, not gonna be usable in turnkey
systems...

[[e-mail] [H390-MVS]]

The SQL implementation in many of the "free" Open Source DBMs is quite different from DB2 for z/OS - not just in terms os syntax but also semantics. I cannot speak specifically about PostgreSQL but I know that MySQL is very different.

Jim

['Theodore M Rolle, Jr.' [e-mail] [H390-MVS]]

Yes. MySQL is different...Oracle's hands in the pie?

I downloaded the DB2 SQL reference; I'll look through it for differences.

SQLite (and SQLCipher) don't have a server/client model. It's not
multi-threaded. (I hope this is not out on a limb.)
They're suited for databases local to a machine.

I use PostgreSQL exclusively now; it has proved to be a good choice.

Yes, MVS 3.8j. Pardon the hardware (sort of) / software mixup. ;-)


Getting a database compiled on MVS 3.8j is the easy part. Getting from a
(say) COBOL program to the database is a whole level of difference.
Assembler interface? SVC?
Any thoughts on this?

Ted

Post by ***@yahoo.com [H390-MVS]
The SQL implementation in many of the "free" Open Source DBMs is quite
different from DB2 for z/OS - not just in terms os syntax but also
semantics. I cannot speak specifically about PostgreSQL but I know that
MySQL is very different.
Jim

[[e-mail] [H390-MVS]]

Post by 'Theodore M Rolle, Jr.' ***@gmail.com [H390-MVS]
I downloaded the DB2 SQL reference;
I'll look through it for differences.

I think it would be more useful to just
confirm that both PostgreSQL and
DB2 conform to level 1 of the SQL
standard.

Post by 'Theodore M Rolle, Jr.' ***@gmail.com [H390-MVS]
SQLite (and SQLCipher) don't have a
server/client model. It's not multi-threaded.
(I hope this is not out on a limb.)

Note that if you are using GCCMVS
to compile PostgreSQL then there
is no way I know of to do
multi-threading. I don't know about
JCC.

I would suggest that, if possible, you
first get a non-multithreaded version
running.

Post by 'Theodore M Rolle, Jr.' ***@gmail.com [H390-MVS]
Getting a database compiled on MVS 3.8j
is the easy part. Getting from a (say)
COBOL program to the database is a
whole level of difference.
Assembler interface? SVC?
Any thoughts on this?

I don't know what to recommend here,
but I would point out that for whatever
reason, Jason Winter decided to use
an unused CPU instruction/opcode
in order to implement both TCP/IP
and local file access.

Another option that comes to mind is
a DIAG.

You might want to consider the
possibility of having the server
portion of PostgreSQL run on
Windows instead of MVS. If you
do that, then you will have
restored multithreading too.

BFN. Paul.

[[e-mail] [H390-MVS]]

Post by 'Theodore M Rolle, Jr.' ***@gmail.com [H390-MVS]
Before I spend time on compiling PostgreSQL
for Hercules, is there a reason to?

When you say "for Hercules", do you mean
"for MVS 3.8j or similar"? Note that someone
once proposed putting hooks in Hercules
so that it would translate database calls
from MVS into calls to a Windows database.

Note that this person had a definite opinion
that PostgreSQL is much more viable for
real applications than SQLite:

https://groups.yahoo.com/neo/groups/hercules-os380/conversations/messages/1828

I think that MVS/380 could very well be disruptive technology given a capable COBOL compiler, KICKS and let's say a port of PostGreSQL running as a STC. With tools such as these, a migration away from big iron would become feasible for a significant number of applications, IMO.


Note that if you port PostGreSQL that would
make a significant portion of the above done,
given that KICKS already exists, and an
old Cobol compiler already exists and since
we have GCC working, getting Open Cobol/
GNU Cobol working may be possible too.

Post by 'Theodore M Rolle, Jr.' ***@gmail.com [H390-MVS]
Is DB2 so different that any substitution would be too far out?

Last time I looked at the SQL standards,
they had 3 levels of compliance. I tried
to keep all my applications to the lowest
level. I suspect that all implementations
conform to the lowest level, and if people
use extensions, they should not expect
to be able to port their applications.

BFN. Paul.

[Vince Coen [e-mail] [H390-MVS]]

Is there a source version for running on IBM MVS codebase within the
sources ?

As against say Linux and Windows - if not then you have a lot of work to
do in order to convert it.

Better to just use DB/2 - a proven product under MVS and later and
should play nicely with the existing compilers supplied with MVS.

Post by 'Theodore M Rolle, Jr.' ***@gmail.com [H390-MVS]
Before I spend time on compiling PostgreSQL for Hercules, is there a
reason to?
Is DB2 so different that any substitution would be too far out?
Those CBT contributions are ZOS (OE) ports, not gonna be usable in
turnkey systems...

[[e-mail] [H390-MVS]]

I believe that even Release 1 of DB2 (no slash) required MVS/SP 1.3 (perhaps 1.1 but I would be surprised) for the Subsystem Interface (especially load to global) and the support for PC instructions (PC/AUTH address space). There may be other things but those are the most obvious missing pieces I have found so far.

Jim

[[e-mail] [H390-MVS]]

Btw, has anyone (besides me) ever looked into what it would take in terms of work to provide this functionality in MVS 3.8J? Load into global and subsystem interface don't look too bad but the functionality of PC/AUTH looks a little daunting. Or did I miss something and it has already been done?

Jim

[Laddie Hanus [e-mail] [H390-MVS]]

Essentially upgrade MVS 3.7 source code to the current running 3.8J, change all the PL/S macro expansions to use the unexpanded dsects. And then write all the code to upgrade to MVS SP 1.3. I have doing the first step off and on for 9 years.

Laddie

Sent from whatever device I am using.

Post by ***@yahoo.com [H390-MVS]
Btw, has anyone (besides me) ever looked into what it would take in terms of work to provide this functionality in MVS 3.8J? Load into global and subsystem interface don't look too bad but the functionality of PC/AUTH looks a little daunting. Or did I miss something and it has already been done?
Jim

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com [H390-MVS]
Btw, has anyone (besides me) ever looked
into what it would take in terms of work to
provide this functionality in MVS 3.8J?
Load into global and subsystem interface
don't look too bad but the functionality of
PC/AUTH looks a little daunting. Or did
I miss something and it has already been done?

I don't understand your question, and I
note that the "PC" instruction doesn't
exist in standard Hercules S/370 and
MVS 3.8j, but I would suggest you
concentrate on getting something
running at all to start with, otherwise
you may become disillusioned with
the project.

To get something working immediately,
I would suggest that you get PostgreSQL
to build an executable that expects to
receive an API list at startup, and then
just executes that API whenever a
facility like SELECT is needed.

That way you can replace the internal
implementation details anytime you
want.

So, something like:

EXEC PGM=POSTGRE,PARM='MYPROG ABC DEF'

And as above, both POSTGRE (full, server,
not just client) run in this address space,
along with your user prog MYPROG.

At a later date you can move the server
portion into a different address space,
using some sort of cross address space
communication, and potentially after
that, move the server so that it runs
under Windows instead of MVS.

BFN. Paul.

[Joe Monk [e-mail] [H390-MVS]]

"and I note that the "PC" instruction doesn't
exist in standard Hercules S/370 and
MVS 3.8j,"

You're wrong.

/*B218*/ GENx370x390x900 (program_call,S,"PC"),

https://github.com/rbowler/spinhawk/blob/master/opcode.c

Page 10-25. PC is an S/370 instruction.

http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/370/princOps/GA22-7000-10_370_Principles_of_Operation_Sep87.pdf

Joe

Post by ***@yahoo.com.au [H390-MVS]

Post by ***@yahoo.com [H390-MVS]
Btw, has anyone (besides me) ever looked
into what it would take in terms of work to
provide this functionality in MVS 3.8J?
Load into global and subsystem interface
don't look too bad but the functionality of
PC/AUTH looks a little daunting. Or did
I miss something and it has already been done?

I don't understand your question, and I
note that the "PC" instruction doesn't
exist in standard Hercules S/370 and
MVS 3.8j, but I would suggest you
concentrate on getting something
running at all to start with, otherwise
you may become disillusioned with
the project.
To get something working immediately,
I would suggest that you get PostgreSQL
to build an executable that expects to
receive an API list at startup, and then
just executes that API whenever a
facility like SELECT is needed.
That way you can replace the internal
implementation details anytime you
want.
EXEC PGM=POSTGRE,PARM='MYPROG ABC DEF'
And as above, both POSTGRE (full, server,
not just client) run in this address space,
along with your user prog MYPROG.
At a later date you can move the server
portion into a different address space,
using some sort of cross address space
communication, and potentially after
that, move the server so that it runs
under Windows instead of MVS.
BFN. Paul.

[[e-mail] [H390-MVS]]

Post by Joe Monk ***@att.net [H390-MVS]

Post by Joe Monk ***@att.net [H390-MVS]
and I note that the "PC" instruction doesn't
exist in standard Hercules S/370

You're wrong.
Page 10-25. PC is an S/370 instruction.
GA22-7000-10_370_Principles_of_Operation_Sep87.pdf

I checked the page reference and you
are right. Thanks for the correction.

BFN. Paul.