In
,
on 11/01/2013
at 02:47 PM, Timothy Sipples 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 goal:
FSVO "two" larger than the standard value. False dichotomies are not
helpful
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 EBCDI
In
,
on 10/31/2013
at 01:35 PM, Timothy Sipples said:
>It does not (if referring to ported applications),
Ported applications do not run in a vacuum.
>and repeating a falsehood
Such as the claim that z/OS does not require EBCDIC.
>EBCDIC support is required if and only if there is a requi
an indicator of what type if db was being connected. VBG
>
> Rob
> On Oct 26, 2013 12:55 AM, "David Crayford" 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.
>>> O
ther 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..
>> (how does jmdbc driver sound???
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 wrote:
>
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 wrote:
> On 1 November 2013 02:47, T
On 1 November 2013 02:47, Timothy Sipples 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...
>
> Which (other)
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 31 October 2013 01:35, Timothy Sipples 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 to operate
>
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
fa
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 applicat
In
,
on 10/30/2013
at 03:01 PM, Timothy Sipples 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 support and not particularly
>interested in it (to be charitable).
The impression
Timothy Sipples wrote:
>As mentioned previously, if you want to operate on EBCDIC data there might be
>additional steps you have to take (might),
Add 'but unneeded' between these words 'additional' and 'steps'.
David Crayford wrote:
>Any z/OS tool that doesn't support EBCDIC is a dud from t
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 b
>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), bu
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 happen
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
From: Jantje.
>To: IBM-MAIN@LISTSERV.UA.EDU
>Sent: Monday, October 28, 2013 5:20 AM
>Subject: Re: Is there currently a way to access MongoDB from z/OS LE languages?
>
>
>On Fri, 25 Oct 2013 08:30:27 -0700, Frank Swarbrick
> wrote:
>
>>Why do you say there is a need for
On Fri, 25 Oct 2013 08:30:27 -0700, Frank Swarbrick
wrote:
>Why do you say there is a need for a "C layer" here?� Even without using
>"Object COBOL" you can use JNI directly in COBOL.� (It's not great fun, but it
>is doable.)
Can you? Can you please provide a pointer to some documentation abo
!) represented in UTF-8,
determines 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 applicati
s, 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.
---
David Crayford writes:
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.
and here we have an example of rhetoric rather than substance.
On 27/10/2013 8:42 PM, John Gilmore wrote:
Until I read Mr. Crayford's post it had thus never occurred to me that
I should delegate list manipulations to either an HDB or an RDB; and I
still do not find this idea attractive. Others may, however, find it
attractive or even necessary if their pro
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
c
>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
etty 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 Data movem
cation. Anything else need some relational model, 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 ha
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 subseq
rt EBCDIC. I was very impressed.
On Thu, Oct 24, 2013 at 9:27 PM, mario@tiscali 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
&
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 imho.
I know of a MVS3.8 port once offer
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 i
>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 l
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 a
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 ext
ay, October 25, 2013 4: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
>wrote:
>
>>I'm not sure about the following. I'm up late due to ... well, it doesn't
&
ssage-
From: IBM Mainframe Discussion 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 l
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 d
On Thu, 24 Oct 2013 22:58:05 -0500, John McKown
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 to interface MongoDB (on a
>remote system such as z/Linux) with a z/OS Java routine. And
ith 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 wrote:
On 25/10/2013 12:28 PM, Tony Harminc
EBCDIC issue
>>> is a make 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 w
On 25/10/2013 12:28 PM, Tony Harminc wrote:
On 24 October 2013 23:49, Ze'ev Atlas 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
On 24 October 2013 23:49, Ze'ev Atlas 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
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 na
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
ot allow 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 iss
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
>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
--
>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
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, ther
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 main
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, there was already a full EBCDIC implementation, but there is
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
>>>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/librar
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 & sof
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
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/pub3812
, 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 have bu
onal
data bases.
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
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
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.c
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
--
Fo
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 wrote:
> Since NoSQL seems to be reigning supreme, I decided to study MongoDB which
&g
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
65 matches
Mail list logo
