RE: Dorting multiple VSAM and PS files

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:IBM-MAIN@xxxxxxxxxxxx
Behalf Of Gilbert Saint-Flour
Sent: Wednesday, January 31, 2007 11:53 AM
To: IBM-MAIN@xxxxxxxxxxx
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 listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.