My main reason for asking is we still have VSAM defined with IMBED. Fortunately no KEYRANGE or REPLICATE, at least no IEC161I messages with those sub codes.
Since the statement was made that there is a performance issue, I was hoping to find some verification so that I could convince my users to reorg their files over the next year to get those removed. But if I cannot support the statement, it may be a more difficult road to travel. Zapping something is so much easier than doing a reorg of a file that may be 4GB or larger or having to have an application outage to do it. Same issue with some user catalogs. Since I know I am not the only shop, I was also wondering if anyone else was running into this situation and how they are going about trying to get their files reorg'd. This is just pure curiosity on my part. Lizette > > > I have been reading the z/OS V1.7 to V1.9 Migration guide and though > it states you do not need to remove IMBED, REPLCIATE or KEYRANGE. > It does mention that there is a performance issue by having them on > your VSAM files. > > I was wondering if anyone did an analysis to see what the buy back > for VSAM response was if these are removed? It would help me build > a case to get the VSAM data sets reorged more quickly. My VSAM > seems to be strictly IMBED at this time. I did not find any > KEYRANGE or REPLICATE definitions. > > Redefine existing VSAM data sets that contain the IMBED, REPLICATE, > and KEYRANGE attributes ---------------------------------------------------------------------- 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
