Re: FTP of numeric data from MVS

From: Bill Manry <BManry_at_us.oracle.com>
Date: 1996/08/29
Message-ID: <5034hu$cn5_at_inet-nntp-gw-1.us.oracle.com>#1/1


Jeffrey Alper <alperj_at_worldnet.att.net> wrote: [...]
>Bill,
>Unfortunately the company I am working for does not have this product.
>Perhaps I could convince them to buy it. But anyway, I have about 40
>processes that will run weekly and monthly. About 5 of these processes
>will have over a million records with an average of about 4 SQL
>statements per row. Would SQL*Net be able to handle this and would the
>product be expensive?

Like any performance question the answer starts with "It depends." What it depdends on are things like the amount of data involved in the SQL (versus the size of the records and the amount of number manipulation you currently are doing) and the speed of the network between the mainframe and the UNIX system. If the 4 SQL statements per record are all SELECTs that return more than a trivial amount of data (or INSERTs/UPDATEs that send a lot of data) then my proposal is less likely to help. If the SQL is not data-intensive then you might consider writing a PL/SQL (stored) procedure that does what the separate SQL statements currently do. This could reduce your per-record interaction with Oracle to a very small size in SQL*Net terms and might be very efficient with even modest network capacity.

You will have to talk to your Oracle rep to get pricing information... I'm just a developer. The MVS Client package may be a bit expensive to purchase as a "point solution" for a single application requirement. It is better to look at it as part of a broader integration strategy that considers how your mainframe systems and non-mainframe Oracle systems are going to coexist. (Of course we also sell the ultimate Oracle<->mainframe integration facility, namely Oracle7 RDBMS for MVS...but that's another story. ;-)

/b

--
Bill Manry - Mainframe & Integration Technologies - Oracle Corp. USA
The above statements and opinions are my own and do not
necessarily represent those of Oracle Corporation.
Received on Thu Aug 29 1996 - 00:00:00 CEST

Original text of this message