One key point I forgot to mention. It's a canned programme from a vendor, with few customisation options.
>You ddin't mention the transaction rate. Is this one transaction doing batch workload? or lots of small transactions? We cannot see under the covers, very well. But, it uses browse to seek out the records needed. The key is the postal code. It's a niche product, so there are few options. It's by transaction. It's not batch! >Since the cache hit ratio is 98%, it obviously has a limited requirement for w0orking set. >I suspect it is write intensive because CICS has to force write at transaction >boundrry. 100% read! >This is one case where a database like DB2 can be cheaper because DB2 will buffer writes to the file. (only log activity is forced in DB2). Not an option with the existing package. That's why we need to know the cost (in instructions) per VSAM I/O. That is one point in the justification. Others are: The cost to re-develop/replace. Product licence. Re-training. Business/operational need. - -teD O-KAY! BLUE! JAYS! Let's PLAY! BALL! ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
