On 31 Jan 2007 12:22:38 -0800, in bit.listserv.ibm-main you wrote: >On Wednesday 31 January 2007 14:53, Reda, John wrote: > >> This is clearly much more feasible than programming around the >> restriction. I will speak with the Development Group about this. > >Thanks, John, your help is much appreciated. > >There's a fourth solution around this problem I forgot to mention: > convert VSAM files to non-VSAM. > >In VSE, sequential files which have no need to be VSAM are often defined as >VSAM ESDS, simply because DASD management is so deficient in VSE. >Then you have VSAM-managed SAM files, which, among other things, can be >processed indifferently as VSAM or non-VSAM by application or utility >programs. Quite confusing if you ask me. > >Converting files from VSAM to non-VSAM require source-code changes, but it can >lead to many negative side-effects which make it risky business. >In other words, if you think that changing -AS- to -S- in the ASSIGN clause >of an ESDS in COBOL is a simple and easy way to make it non-VSAM, >you may be in for quite a surprise later on. Having said that, we have >converted thousands of VSAM files to non-VSAM in recent years, >and acquired much experience in the process.
Of course if IBM had ever fully understood the implications of the SHARE Guide Language Futures Task Force (or Guide SHARE depending on perspective), we wouldn't have this happy horse manure about having to differentiate in the program between an ESDS and a QSAM data set. In fact we wouldn't have to change the program if we wanted to read a KSDS with the same record description. I want to be able to concatenate an ESDS and a QSAM data set if they share a record description. It is arcanity like this that frustrates me about the z platform. ---------------------------------------------------------------------- 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
