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 testing... Doesn't seem to be a way to do it. Although.. I have stumbled across a couple systems that folks have made freely available. Just not sure how they are doing it legally.
Rob On Nov 1, 2013 7:04 PM, "Rob Schramm" <[email protected]> wrote: > 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. Leaving > the 2nd char as an indicator of what type if db was being connected. VBG > > Rob > On Oct 26, 2013 12:55 AM, "David Crayford" <[email protected]> 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 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 your original intent Rob. I was just sounding off about JDBC >> drivers for non-relational data bases. >> >> I've never quite grasped why there are so many SQL adapters for >> non-relational data bases. Even IMS has a Java SQL interface with ODBC and >> I just >> don't get it. 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. >> >> >> Rob >>> >>> >>> On Oct 25, 2013 3:03 AM, "David Crayford" <[email protected]> wrote: >>> >>> 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 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 <[email protected]> >>>>> wrote: >>>>> >>>>> On 25/10/2013 12:28 PM, Tony Harminc wrote: >>>>> >>>>>> On 24 October 2013 23:49, Ze'ev Atlas <[email protected]> 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 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 again, but this >>>>>>>> >>>>>>> sounds like a place for UTF-EBCDIC. Which is easily translated to and >>>>>>> from UTF-8 if that's what goes on the wire. (I'm assuming your UTDF-8 >>>>>>> was just a typo.) Presumably it would be a good start if COBOL could >>>>>>> see and manipulate the subset of UTF-EBCDIC that is EBCDIC strings >>>>>>> that would live as UTF-8 in the database. Then when COBOL learns to >>>>>>> handle UTF-EBCDIC, it could handle the complete UNICODE set. >>>>>>> >>>>>>> The wire protocol is binary. The UTF-8 requirement for strings in >>>>>>> the >>>>>>> >>>>>> BSON >>>>>> spec >>>>>> http://bsonspec.org/#/******specification<http://bsonspec.org/#/****specification> >>>>>> <http://bsonspec.**org/#/**specification<http://bsonspec.org/#/**specification> >>>>>> > >>>>>> <http://bsonspec.**org/#/**specification<http://bsonspec.** >>>>>> org/#/specification <http://bsonspec.org/#/specification>> >>>>>> . >>>>>> I really like the look of BSON. It's like google protocol buffers but >>>>>> more >>>>>> flexible. XML is the pleated khakis of the document markup world. >>>>>> >>>>>> >>>>>> >>>>>> http://www.unicode.org/******reports/tr16/<http://www.unicode.org/****reports/tr16/> >>>>>> <http://www.**unicode.org/**reports/tr16/<http://www.unicode.org/**reports/tr16/> >>>>>> > >>>>>> <http://www.**unicode.org/**reports/tr16/<http://unicode.org/reports/tr16/> >>>>>> <http://www.**unicode.org/reports/tr16/<http://www.unicode.org/reports/tr16/> >>>>>> > >>>>>> >>>>>>> Tony H. >>>>>>> >>>>>>> ------------------------------******--------------------------** >>>>>>> --**--** >>>>>>> ---------- >>>>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>>>> send email to [email protected] with the message: INFO >>>>>>> IBM-MAIN >>>>>>> >>>>>>> ------------------------------******--------------------------** >>>>>>> --** >>>>>>> >>>>>> --**---------- >>>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>>> send email to [email protected] with the message: INFO >>>>>> IBM-MAIN >>>>>> >>>>>> ------------------------------****----------------------------** >>>>>> --** >>>>>> >>>>> ---------- >>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>> send email to [email protected] with the message: INFO IBM-MAIN >>>>> >>>>> ------------------------------****----------------------------** >>>> --**---------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email to [email protected] with the message: INFO IBM-MAIN >>>> >>>> ------------------------------**------------------------------** >>> ---------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to [email protected] with the message: INFO IBM-MAIN >>> >> >> ------------------------------**------------------------------** >> ---------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
