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
Dave,
I actually looked up jdbc after your post. .. and was somewhat surprised. I
had assumed that jdbc was just java database connector ... Instead it is
just for relational using sql. I personally think that this was a huge
assumption by the original authors. It should have been jrdbc.
As far as Perl and EBCDIC goes the biggest objection was the lack of any
system that the Perl guys can use to validate the code with. I had put out
a question to the list a while back... Looking to run Tomcat and Jspwiki on
a z/os system ... And offer up some system time to the Perl guys for
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
David Crayford writes:
I'm not aware of any previous requirement for a mainframe
COBOL program to access a data base running on a different
platform.
That's fairly common. To pick an example, Oracle offers a product called
Oracle Access Manager for CICS that allows COBOL (and other programming
On 28/10/2013 11:39 AM, Timothy Sipples wrote:
David Crayford writes:
I'm not aware of any previous requirement for a mainframe
COBOL program to access a data base running on a different
platform.
That's fairly common. To pick an example, Oracle offers a product called
Oracle Access Manager
Is SQL really that much better then native APIs? In the
case of your typical key/value data store surely get/set is easier than
SELECT FROM WHERE/UPDATE SET IN etc.
My short answer would be YES!
The Typical key/value data store may be better handled with get/set. But
presenting complex data
On 27/10/2013 7:44 AM, Ze'ev Atlas wrote:
Is SQL really that much better then native APIs? In the
case of your typical key/value data store surely get/set is easier than
SELECT FROM WHERE/UPDATE SET IN etc.
My short answer would be YES!
I disagree. One of the reasons for choosing a NoSQL
On 25/10/2013 1:51 PM, Rob Schramm wrote:
With a JDBC driver and a bit of JAVA code..you could use the COBOL/JAVA
procedure BCDBATCH to help tie the two together. Did a quick scan and
there appear to be at least few JDBC drivers.
I'm scratching my head as to why a JDBC driver is useful with a
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, there was
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 on
It's not much fun accessing Mongo in C let alone COBOL.
Agree
My language of choice is Perl which flaws with that stuff and I am working on
my JavaScript skills. However, what drives me is frustration. Whenever I do a
mainframe project, I see how much I miss the other side's features and then
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 to
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
With a JDBC driver and a bit of JAVA code..you could use the COBOL/JAVA
procedure BCDBATCH to help tie the two together. Did a quick scan and
there appear to be at least few JDBC drivers.
Rob
Rob Schramm
Senior Systems Consultant
Imperium Group
On Fri, Oct 25, 2013 at 1:18 AM, David Crayford
43 matches
Mail list logo
