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
Phil,
AFAIK, the whole GDG assignment only happens once.. during initial
creation. MODing will change the size of the data set.. not the GVoo
number(s). With SMS a new GDG entry gets rolled in at step end.
Most everything you need to know is in "Chapter 29. Processing Generation
Data Groups
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
Oh yea.. I guess if I paid more attention to the topic... I would have seen
that.
It is funny that everyone starts to gravitate towards problems around the
same time. Been working some on RDz.. BPX_SHAREAS and SPAWN_SCRIPT have
recently become very interesting to me. I have to admit that the who
he next meeting of the NY Metro NaSPA Chapter will be on Tuesday, 29
October, 2013, in room 1219 at the IBM Building at 590 Madison Avenue, New
York City, from 10:00 AM until 4:30 PM. Sessions for the day include:
"A Perspective on System z Capacity Delivery - Past and Future", Bob
Ro
Apologies for the naïve question, but I spent some time Googling and reading
and didn't find a clear answer to this.
We have a data set that gets fetched from the network and changes occasionally.
I'd like to untie this update from normal operation-that is, on the off-chance
that the network is
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
At 14:24 -0500 on 10/24/2013, Paul Gilmartin wrote about Re:
Allocation problem with LMCOPY:
On Thu, 24 Oct 2013 15:12:39 -0400, Robert A. Rosenberg wrote:
This will also fix the INIT issue that if a JOB Step has a DISP=OLD
with further steps as DISP=SHR, the dataset remains exclusively held
>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
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
As long as you accept a complete line at a time, like multiple SDSF
operator sessions, it should work, unless two people happen to issue
the same command and it causes problems.
On Thu, Oct 24, 2013 at 11:28 AM, John McDowell wrote:
> Mark,
>
> I understand what you are saying, the unintentional
On Thu, 24 Oct 2013 15:12:39 -0400, Robert A. Rosenberg wrote:
>
>This will also fix the INIT issue that if a JOB Step has a DISP=OLD
>with further steps as DISP=SHR, the dataset remains exclusively held
>until the last DISP=SHR step ends (since INIT can not downgrade the
>EXC ENQ to the SHR ENQ us
At 11:59 -0500 on 10/24/2013, Paul Gilmartin wrote about Re:
Allocation problem with LMCOPY:
Will 2.1 allow me to DYNALLOC a data set NEW, then immediately
downgrade the ENQ to SHR? What command? Assembler only?
I do not know but the lack of an ability to convert an EXC ENQ to a
SHR one ha
On Wed, 23 Oct 2013 21:47:34 -0700, Jon Perryman wrote:
>Sorry, I thought that the DD name was contained in the DATAID variable. It's
>value was always in a format that ISPF uses for dynamic allocation. I always
>assumed that it was the DD name.
When the dataset name is specified instead of DD
Mark,
I understand what you are saying, the unintentional interleaving of multiple
user inputs, is something you can accept/overcome. This is one possible
resolution of allowing multiple concurrent uses of the "Integrated 3270", I
personally favor a model of one writer/multiple readers such is
This would be better asked on the IDUG.ORG forum
On Thursday, October 24, 2013, R.S. wrote:
> Environment z/OS 1.11, DB2 v9.1, CICS TS 4.1
> is being migrated to
> z/OS 1.13, DB2 v10.1, CICS TS 4.2 (DB2 in Compatibility Mode)
>
> One CICS transaction expected strange behavior: much more CPU used
Environment z/OS 1.11, DB2 v9.1, CICS TS 4.1
is being migrated to
z/OS 1.13, DB2 v10.1, CICS TS 4.2 (DB2 in Compatibility Mode)
One CICS transaction expected strange behavior: much more CPU used for
"open cursor" operation. Acces path wasn't changed. It seems DB2 lost
ability to read index in b
On Wed, 23 Oct 2013 21:54:54 -0500, John McDowell wrote:
>I agree that the inability to share the "Integrated 3270" among multiple
>concurrent sessions is unfortunate and that it would be a useful enhancement
>to list that restriction. Off the top of my head I can see that the
>"ownership" of
Thanks. I am so used to being the _only_ person in our _very small_ shop
who does IPLs that it never occurred that the person doing the IPL or
shutdown would need a helper. Unfortunately, one of the other people here
who will (<1%) occasionally IPL tends to just "punch it out" if the
shutdown doesn
You are right , I was thinking of the case when you use the format
'LMINIT DATAID(LMID) DATASET('dsn') ENQ(SHR)'
Here it allocates a ISPn dd.
Best Regards
Thomas Berg
___
Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK
Thanks gentleman ..That was it . A standalone REORG needs space to hold the new
index and CA suggested us to do ASYNCH REORG . Thank you !
On Wednesday, October 23, 2013 8:07 AM, Roger Steyn
wrote:
Greetings ,
Recently , we had a problem during the REORG of SAR index file . It was
Hi Gary
Yes, There are many many calls to MQCONN, MQOPEN, etc in the PL/1 for MVS
programs.
Regards and thanks
Paul
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Gary Jacek
Sent: Wednesday, October 23, 2013 10:00 PM
To: IBM-MAIN
30 matches
Mail list logo
