John, The problem is the restriction imposed by the access-method (EOV, mostly) that a VSAM data set can't be part of a concatenation. As a result, if a program (SORT or otherwise) wants to read more than one data set and at least one is VSAM, then it must use several DD statements and different DD names.
What I would like is that SORT utility programs be enhanced with an option to read SORTIN data sets using several DD names, such as SORTIN01-SORTIN99. This is already what they do when the command is MERGE, but when the command is SORT, the only thing they do is read the SORTIN concatenation . Here's an example of what I would like: //STEP100 EXEC PGM=SORT //SORTIN01 DD DSN=VSAM.DATA.SET,DISP=OLD //SORTIN02 DD DSN=NON-VSAM.DATA.SET,DISP=OLD //SORTOUT DD DSN=.... SORT FIELDS=(1,8,CH,A) /* -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ On Wednesday 31 January 2007 13:46, Reda, John wrote: > I think the problem that you are encountering is an operating system > restriction. If you OPEN a file with a VSAM ACB, when the end of data > condition is encountered VSAM code is not prepared to close the VSAM > data set, clean up the VSAM control blocks, convert the ACB to a DCB > (not sure how this would be done) and reopen the file using the > converted DCB. The reverse is also true for physical sequential to VSAM > concatenation. About the only way this would be possible is for the > program to break down the concatenation using dynamic allocation, > rebuild multiple files without the sequential to VSAM conversions, and > then programmatically work through the newly dynamically allocated > files. This would be an extremely messy situation. > > We understand that this situation can lead to confusion. If a > programmer codes a concatenated file and the step ends with a RC=0, most > people would assume that all of the data had been read. To avoid this > confusion SyncSort will post an error message and end with a RC=16. > > Sincerely, > John Reda > Software Services Manager > Syncsort Inc. > 201-930-8260 > >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] >> Behalf Of Gilbert Saint-Flour >> Sent: Wednesday, January 31, 2007 11:53 AM >> To: [email protected] >> Subject: Re: Dorting multiple VSAM and PS files >> >> On Wednesday 31 January 2007 11:17, Carl Edwards wrote: >> >> > I have recently migrated a small VSE system to Z/os. >> > evrything went well with one exception. >> > The VSE Sort program was able to sort a variety of files, mixed SAM >> > and VSAM in one pass. This is not supported in Z/OS (DFSORT). >> > I can write an E15 exit to handle this, but I am somewhat amazed >> > that this cabability does not exist in Z/os. >> > Has anyone else encounterd this issue? >> >> I certainly have, way too many times! Just last year, I had a customer >> which had that particular problem in over 700 SORT steps. >> Note that this isn't just a DFSORT problem: it also exists with SYNCSORT >> and CA-SORT. >> >> Over the years, I have used three approaches to solve this problem: >> >> 1. a generic E15/E35 exit called VSAMSORT which I first wrote in 1985 >> >> 2. An ICETOOL step with COPY/COPY/SORT (an obviously more recent > solution) >> >> 3. a request to the DFSORT developers to add support for multiple VSAM >> input files - that never worked :-( >> >> -- >> Gilbert Saint-Flour >> GSF Software >> http://gsf-soft.com/ ---------------------------------------------------------------------- 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
