Re: yipeee!

On Thu, 5 Feb 2004 07:52:38 -0700, "Mark A" <ma_at_switchboard.net> wrote:

>"Serge Rielau" <srielau_at_ca.eye-be-em.com> wrote in message
>news:bvtjk7$bvp$1_at_hanover.torolab.ibm.com...
>> My DB2 "offer" would be DB2 without DPF on two AIX boxes (OP wants AIX
>> it seems). The seoncd box licenced as idle standby only (1 CPU).
>> With clusterware to handle the failover.
>> This is under the assumption that a rewrite of the app to a relational
>> DBMS is intended.
>> There is not enough information to home in on which edition or box-size
>> to home in to.
>>
>> It seems Mark A. believes CICS would be less invasive. I'm not familiar
>> with either VSE or CICS so I keep my mouth shut.
>>
>> Let's presume 100% scalability for RAC (if you want to use it) for the
>> sake of math (and to not start another flame war) and similar resource
>> requirements (AIX, RAM/box, comparable disk overall).
>>
>> Your turn
>> Serge
>> --
>> Serge Rielau
>> DB2 SQL Compiler Development
>> IBM Toronto Lab
>
>I think that what they want to do is change the COBOL application data
>access from VSAM to DB2, running under CICS transaction monitor on RS6000.
>This could be done without a complete redesign of the application, although
>database access in each program would have to be changed by hand from VSAM
>to DB2 and thoroughly tested. VSAM KSDS is an inverted list database (not
>hierarchical like IMS) so there could be a one-to-one mapping of existing
>VSAM datasets to DB2 tables.

Unless, as is often the case with old COBOL systems, the records in those VSAM files are defined with a lot of REDEFINES clauses. Not an insurmountable obstacle, but one which negates a simple one-to-one mapping of data and treating a VSAM record as the equal to a rdbms row. This would require not only some restructuring of the data (not just re-hosting) but also the attendant re-work (but not a total re-write) on the application. This would go beyond simply changing the data access calls from VSAM 'read' to SQL 'select'.

(And please don't read anything into my reference to *old* COBOL systems. I still consider myself an unrepentant COBOL programmer even though I'm not currently working with it.)

>
>But again, I think their main motivation is to save money, and the
>conversion certainly would not be cheap, although much less expensive than a
>complete re-write.
>
>The hardware redundancy issues could be worked out in a number of ways, as
>already mentioned.
>
Received on Fri Feb 06 2004 - 08:14:47 CST