in reply to Giant proxy DBD for multiple databases

baku,

derby scratches his head and tries to remember all that mainframe crap he was forced to learn early in his career. We had a similar set-up (M204, VSAM, MVS, JCL, etc etc). I got damn tired of login into TSO, tweaking some JCL, submitting etc. so I wrote a perl script (4.x) that would (no DBI back then) merge a bunch of JCL, submit it to the mainframe and then wait for the data to be deposited in his *nix account.

Now I had some major differences from your set-up. First, our M204 database were backed up to VSAM files on a nightly basis and there were existing JCL snippets (what were those called exactly) that could query M204 directly if necessary (rarely was). So having to go against VSAM only (via JCL) simplified things immensely.

The second difference was we had snippets of JCL that could download data to a *nix box. That was fantastic. My perl script could just spin it's wheels waiting for the file to show up. I would then do some follow on processing in *nix.

Now for your application, you don't have to necessarily download all the data but you would need something to let you know the newly created dataset was available (which given the size of you're data, you may want to asynch that somehow). Once that temp dataset is there, you could retrieve it in chunks.

Sorry if this isn't much help. Just wanted to let you know I feel your pain. I think if you can get as much possible into a VSAM dataset and then use JCL (or perl on the mainframe) you should be able to easily develop a DBD driver for fetching.

-derby

update: I also remember being excited about EDA/SQL from ibi but it never made it out of our labs. I think that product has been rolled into a new company iwaysoftware. But I cannot comment one way or another about their products.

  • Comment on Re: Giant proxy DBD for multiple databases

Replies are listed 'Best First'.
Re: Re: Giant proxy DBD for multiple databases
by baku (Scribe) on Mar 19, 2002 at 14:53 UTC

    Our super-COBOL-expert people said we'd have to write custom COBOL to do each query, since the VSAM's are indexed only on the "primary key," like DB_File's, and we need to query against any "key" in the table.

    We did look into doing a retrieval by FTP but ran into the asynch notify "problem," which we "solved" (on paper) by passing a "job completed code" to the COBOL driver when we began the query, and have it "hit" a TCP port back on our side with this code to indicate completion.

    Unix: EBCDIC structured data JOB-ID PIC XXXXXXXXXXXXXXXX SUB-DATE-TIME 9999999999999999 SUB-DATE 99999999 SUB-DATE-YR 9999 SUB-DATE-MO 99 SUB-DATE-DY 99 SUB-TIME 99999999 SUB-TIME-H 99 SUB-TIME-M 99 SUB-TIME-S 99 SUB-TIME-CS 99 REPLY-IP 99999999999999999 REPLY-IP-H1 999 REPLY-IP-H2 999 REPLY-IP-H3 999 REPLY-IP-H4 999 REPLY-IP-PORT 99999 QUERY-1ST-COL 999 QUERY-LAST-COL 999 ... yadda, yadda ...

    Really interesting trying to express TCP streams in fixed-length fields like this. Very similar concepts to C's "union"s or "struct"s; but no binary data, because (many/most) interfaces will mangle anything outside of the basic EBCDIC printable character-set. (We had to use "special" functions just to preserve lowercase letters. God only knows what happens to Iñigo and Réné as they go through the mangler...

    Unfortunately, the contract was yanked at the last minute by the agency offering it. Apparently they thought this entire project would take 900 man-hours to complete and were a mite surprised at a 7-digit bid.

    Thanks to everyone for your contributions, though!