In
of6c884318.84e6f64a-on48257c16.00237d2b-48257c16.00257...@sg.ibm.com,
on 11/01/2013
at 02:47 PM, Timothy Sipples sipp...@sg.ibm.com said:
Now, I stipulate that there are many desirable capabilities.
Operating on/with EBCDIC data is often useful. There are two ways
to try to accomplish that
Hi all
While I may change my mind in the future, I've pretty much decided to abandon
the project for now, for these reasons:
1. Mongo DB data is UTF-8 and not even ASCII. An EBCDIC version is thus
irrelevant and not needed. This is different then the situation with the PCRE
library where
David Crayford writes:
Do you have any real world experience with open source and
porting to z/OS?
Yes, some.
Tony Harminc opines:
Sure, if all your application does is crunch numbers or manipulate
bytes. But if it has any interaction with the operating system such as
calling its services...
On 1 November 2013 02:47, Timothy Sipples sipp...@sg.ibm.com wrote:
Tony Harminc opines:
[with respect to the need to use EBCDIC]
Sure, if all your application does is crunch numbers or manipulate
bytes. But if it has any interaction with the operating system such as
calling its services...
As long as the program accepts the data as valid and doesn't check it
for valid ASCII characters, it should work for any character set. Let
the operating system determine if it is a valid data set name, path,
etc.
On Fri, Nov 1, 2013 at 10:51 AM, Tony Harminc t...@harminc.net wrote:
On 1
Timothy is right - as long as your program doesn't call services that
require EBCDIC names, you don't need EBCDIC.
What's the open source equivalent of IEFBR14, the Unix true command?
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Fri, Nov 1, 2013 at 11:18 AM, Mike Schwab
jdbc and mongodb.. as well as there being a
jdbc link on the mongodb page in addition to the mongodb java connectors.
Doesn't really change my intent ... Grab the mongodb java database
driver..
(how does jmdbc driver sound???) and couple it with the cobol
application
code.
I understood
if db was being connected. VBG
Rob
On Oct 26, 2013 12:55 AM, David Crayford dcrayf...@gmail.com wrote:
On 25/10/2013 11:13 PM, Rob Schramm wrote:
Not sure how to respond.. on the one hand you have an excellent point.
One the other hand.. Google jdbc and mongodb.. as well as there being
On 31 October 2013 01:35, Timothy Sipples sipp...@sg.ibm.com wrote:
Shmuel Metz writes:
...z/OS does require EBCDIC.
It does not (if referring to ported applications), and repeating a
falsehood does not make it any more true.
EBCDIC support is required if and only if there is a requirement
I've recently been writing web servers using Lua/Orbit.
From the reports I've read there doesn't seem to be any particular problem
compiling Lua on z/OS (via make posix). As mentioned previously, if you
want to operate on EBCDIC data there might be additional steps you have to
take (might), but
On 30/10/2013 3:01 PM, Timothy Sipples wrote:
I've recently been writing web servers using Lua/Orbit.
From the reports I've read there doesn't seem to be any particular problem
compiling Lua on z/OS (via make posix). As mentioned previously, if you
want to operate on EBCDIC data there might be
In
of5f4879d8.ef7c6ebe-on48257c14.0023d7b0-48257c14.00269...@sg.ibm.com,
on 10/30/2013
at 03:01 PM, Timothy Sipples sipp...@sg.ibm.com said:
If I could coach a little bit on the Perl conversation within
the open source community, Perl's maintainers seem to be
particularly hung up on EBCDIC
Shmuel Metz writes:
...z/OS does require EBCDIC.
It does not (if referring to ported applications), and repeating a
falsehood does not make it any more true.
EBCDIC support is required if and only if there is a requirement to operate
on/with EBCDIC-encoded data. z/OS does not require an
You speak with great authority about this Timothy. Do you have any
real world experience with open source and porting to z/OS?
On 31/10/2013 1:35 PM, Timothy Sipples wrote:
Shmuel Metz writes:
...z/OS does require EBCDIC.
It does not (if referring to ported applications), and repeating a
David Crayford writes:
I wonder if there is a market for mainframe legacy applications to
access NoSQL data stores?
Of course. Case in point: the IBM DB2 Analytics Accelerator. The PureData
System for Analytics which powers the IDAA is, as it happens, a NoSQL
data store. However, applications
On 29/10/2013 4:47 PM, Timothy Sipples wrote:
David Crayford writes:
I wonder if there is a market for mainframe legacy applications to
access NoSQL data stores?
Of course. Case in point: the IBM DB2 Analytics Accelerator. The PureData
System for Analytics which powers the IDAA is, as it
Who's using F1? MongoDB is currently valued at $1B and has venture
capatalists throwing money at it. Last time I looked Mongo could handle
joins and complex data and had a very rich query language.
F1 is obviously new and it is not clear how (if at all) Google would release it
for non-Google
This is a very old argument.
Hierarchical data bases (HDBs) long antedate relational ones (RDBs),
and the deficiencies of HDBs were once well understood. The chief
problem with them is that an HDB and applications that use it are not
independent. They are unhappy bedfellows. If one is changed
David Crayford writes:
begin extract
IMO, programming skills to develop applications should be kepth to the
minimal. I would rather get the job done as quickly as possible then
show off rubbing two sticks together when I could just use a match.
/end extract
and here we have an example of
/infocenter/pdthelp/v1r1/topic/com.ibm.entcobol.doc_5.1/PGandLR/ref/rputf8e.html
Thus interacting with MongoDB in UTF-8 from your COBOL applications should
be no problem whatsoever.
Timothy
their initials, and outputs the results (in EBCDIC):
http://pic.dhe.ibm.com/infocenter/pdthelp/v1r1/topic/com.ibm.entcobol.doc_5.1/PGandLR/ref/rputf8e.html
Thus interacting with MongoDB in UTF-8 from your COBOL applications should
be no problem whatsoever
:27 PM, mario@tiscali mbe...@tiscali.it wrote:
I've found the thread about porting MongoDB interesting, and I would like
to ask a question along the same lines:
Any SQLite port for z/OS (ideally non USS)? Having a self contained
database engine for small stand-alone projects would be great
John,
that's great, thank you very much for your time and effort!
I see you ported a quite recent version of SQLite, and reading your
notes in file 897 I see that The code was compiled with almost no
changes. What would be needed to compile a different SQLite source,
let's say a
, and
SQL engines are pretty refined and do the navigation for you.
My reason of thinking about interfacing MongoDB to COBOL is the fact that COBOL
is very well suited to deal with API's and the hierarchical model. And I
believe that MongoDB has its place as Warehouse engine.
Again, even in the Big
about interfacing MongoDB to COBOL is the fact that COBOL
is very well suited to deal with API's and the hierarchical model. And I
believe that MongoDB has its place as Warehouse engine.
Again, even in the Big Data movement there is now a tendency to go back to SQL,
hence Google's F1 Database
with a NoSQL
data base which has a very specific API.
Why not just use the MongoDB Java API? Does JDBC provide some kind of
value add?
Rob
Rob Schramm
Senior Systems Consultant
Imperium Group
On Fri, Oct 25, 2013 at 1:18 AM, David Crayford dcrayf...@gmail.com wrote:
On 25/10/2013 12:28 PM, Tony
Not sure how to respond.. on the one hand you have an excellent point.
One the other hand.. Google jdbc and mongodb.. as well as there being a
jdbc link on the mongodb page in addition to the mongodb java connectors.
Doesn't really change my intent ... Grab the mongodb java database driver
List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Ze'ev Atlas
Sent: Friday, October 25, 2013 12:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there currently a way to access MongoDB from z/OS LE languages?
Actually, it looks like there is support to UTF-8
:33 AM
Subject: Re: Is there currently a way to access MongoDB from z/OS LE languages?
On Thu, 24 Oct 2013 22:58:05 -0500, John McKown john.archie.mck...@gmail.com
wrote:
I'm not sure about the following. I'm up late due to ... well, it doesn't
matter. But I am wondering if it would be easier
I will look carefully at the Java option and JNI, but my inclination (as an old
timer) is to adapt the C driver rather. Working directly with C subroutines
from COBOL, without a Java layer seems to me to be more natural, but again, I
am an old timer and I do not really know Java. If I need
List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Ze'ev Atlas
Sent: Friday, October 25, 2013 12:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there currently a way to access MongoDB from z/OS LE languages?
I will look carefully at the Java option and JNI, but my inclination (as an old
The compiler limitations are for LITERALS, not for variables. Think VALUE
clause, or constant strings MOVEd to a variable.
That's good news
ZA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
On 25/10/2013 11:13 PM, Rob Schramm wrote:
Not sure how to respond.. on the one hand you have an excellent point.
One the other hand.. Google jdbc and mongodb.. as well as there being a
jdbc link on the mongodb page in addition to the mongodb java connectors.
Doesn't really change my intent
Hi all
Is there currently a way to access MongoDB from z/OS LE languages?
ZA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
On 25/10/2013 10:04 AM, Ze'ev Atlas wrote:
Hi all
Is there currently a way to access MongoDB from z/OS LE languages?
It should be simple enough to build a client. There are many
http://docs.mongodb.org/ecosystem/drivers/. Of course, that's for accessing
MongoDB running off the mainframe. I'm
On 25/10/2013 10:29 AM, Ze'ev Atlas wrote:
Assuming I use my experience in porting Open Source C libraries to the
mainframe and import the MongoDB C driver and compile it successfully, my main
issue would then be, as usual, the pesky EBCDIC. When working on the PCRE
library
It should be simple enough to build a client. There are many
http://docs.mongodb.org/ecosystem/drivers/. Of course, that's for accessing
MongoDB running off the mainframe. I'm interested to know why you would
want to do that?
I have no intention on porting the whole engine because I understand
EBCDIC may not be your only problem! What about endianess? I suggest you
study the wire protocol if you are serious
thank you for pointing me to the right direction.
I will look at the documents you've mentioned about both, EBCDIC and endianess
and see if it it worth it.
ZA
On 25/10/2013 10:58 AM, Ze'ev Atlas wrote:
It should be simple enough to build a client. There are many
http://docs.mongodb.org/ecosystem/drivers/. Of course, that's for accessing
MongoDB running off the mainframe. I'm interested to know why you would
want to do that?
I have no intention
in a simple way for hierarchies. I guess I'll have to develop
a type and the functionality to handle it.
About a previous post, the endianess should not be a big issue to deal with
once the two sides of the protocol are well defined. The EBCDIC issue is a
make or break issue. MongoDB works decidedly
I'm not sure about the following. I'm up late due to ... well, it doesn't
matter. But I am wondering if it would be easier to interface MongoDB (on a
remote system such as z/Linux) with a z/OS Java routine. And then interface
the Java routine with COBOL. I need to read up on the Java - COBOL
Actually, it looks like there is support to UTF-8:
___
You need to do two steps to convert ASCII or EBCDIC data to UTF-8:
Use the function NATIONAL-OF to convert the ASCII or EBCDIC string to a
national (UTF-16) string.
Use the function DISPLAY-OF to convert the
On 24 October 2013 23:49, Ze'ev Atlas zatl...@yahoo.com wrote:
About a previous post, the endianess should not be a big issue to deal with
once the two sides of the protocol are well defined. The EBCDIC issue is a
make or break issue. MongoDB works decidedly with UTDF-8 and I need COBOL
On 25/10/2013 12:28 PM, Tony Harminc wrote:
On 24 October 2013 23:49, Ze'ev Atlas zatl...@yahoo.com wrote:
About a previous post, the endianess should not be a big issue to deal with
once the two sides of the protocol are well defined. The EBCDIC issue is a
make or break issue. MongoDB
or break issue. MongoDB works decidedly with UTDF-8 and I need
COBOL to natively view a string as UTF-8. Does the current incarnation of
COBOL (and perhaps PL/I) have a native UTF-8 string type. If not, then I
will abandon the whole project.
I'm doubtless blowing (or something) into the wind
MongoDB stores it data in BSON or binary JSON and is schema-less.
There is a JSON Schema Internet draft underway -
http://tools.ietf.org/html/draft-zyp-json-schema-03
And, here is an IBM developerWorks article that approaches it -
http://www.ibm.com/developerworks/cloud/library/cl-json
: Wednesday, October 16, 2013 10:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Google F1 was: Re: MongoDB
The brainiacs over at google have invented a novel hybrid data base for their
Ads business http://research.google.com/pubs/pub38125.html. It supports
hierarchical schemas.
Quote With F1, we
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of David Crayford
Sent: Wednesday, October 16, 2013 10:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Google F1 was: Re: MongoDB
The brainiacs over at google have invented a novel hybrid data base for their
Ads business http://research.google.com/pubs
...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, October 17, 2013 1:10 AM
Subject: Google F1 was: Re: MongoDB
The brainiacs over at google have invented a novel hybrid data base for their
Ads business http://research.google.com/pubs/pub38125.html. It supports
hierarchical schemas.
Quote
leful...@sbcglobal.net (Lloyd Fuller) writes:
And this product is called NOMAD from Select Business Solutions. It
has only been available since 1976 or thereabouts.
And you can even MIX hierarchical and RDBMS if you want.
recent post in thread on cloud killing traditional hardware
.
You are correct, it IS not and SHOULD never be used as a transnational
database. It is however, a great (read better, more natural, more scalable,
etc.) replacement to warehoses with star schemas and the like.
Conceptually, navigating MongoDB is similar to navigating IMS and IDMS and is
totally
Since NoSQL seems to be reigning supreme, I decided to study MongoDB which was
both recommended by a friend (a PM who is managing an actual project with that
stuff) and is the most popular NoSQL engine out there according to
http://db-engines.com/en/ranking (they don't count Hadoop since
Sounds like a VSAM database. Just a key and data area, meanings are
what you assign to them, no database catalog to define the individual
fields.
On Tue, Oct 15, 2013 at 10:51 PM, Ze'ev Atlas zatl...@yahoo.com wrote:
Since NoSQL seems to be reigning supreme, I decided to study MongoDB which
Oh No, It is much more then that. You store a set of key-values, which means
that the dictionary (metadata) is part of the row. If you know Perl or Java
you actually store hashes (or objects) which they call documents
ZA
--
In Rexx, you could think about it as storing a stem
ZA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
On 16/10/2013 11:51 AM, Ze'ev Atlas wrote:
Since NoSQL seems to be reigning supreme, I decided to study MongoDB which was
both recommended by a friend (a PM who is managing an actual project with that
stuff) and is the most popular NoSQL engine out there according to
http://db-engines.com/en
schemas and the like.
Conceptually, navigating MongoDB is similar to navigating IMS and IDMS and is
totally different then using relational sets (using SQL)
ZA
--
For IBM-MAIN subscribe / signoff / archive access instructions
57 matches
Mail list logo
