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
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
testi
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. Leavin
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
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 for
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
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 it
for non-Google
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 da
>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 d
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 ..
>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 driver..
(h
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 then interface
>the Java ro
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
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
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 with U
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 to
> natively vie
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 Java <-> COBOL
comm
>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
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 port
>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 whole engine because I understan
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 already
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 i
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 o
49 matches
Mail list logo
