IBM Mainframe Forum

Hi,
Does anyone knew how (or if) it can be sorted 2 different LRECL sized files ?
I want to do something like this :
SORTIN DD DSN=FILE1,DISP=SHR
DD DSN=FILE2,DISP=SHR
SORTOUT=...DCB=(LRECL=200,...)
OUTREC FIELDS=(1,200)

while FILE1 has DCB whith LRECL=250
and FILE2 has DCB whith LRECL=200

thanks,
Dan

Hello Dan and welcome to the forums,

Have you tried this on your system?

I suspect you will have a problem with a dcb mis-match when trying to read the concatenated files. You could copy the lrecl=250 file truncating the last 50 bytes and then concatenate (assuming that the first 200 bytes align in both files).

Give it a try and post back the result

Hi,
First of all, thanks for your quick response !
I tried to do as you said ( and get the LRECL error as expected ) and this is exactly my problem.
The 2 files, and sometimes even more,built dynamicly in previous steps as:
//SORTIN DD DSN=....
// DD DSN=....
// DD DSN=...
and I need to sort their 200 first bytes (the first 200 bytes align in all files) to one file.(It can be into 250 bytes or 200, it doesn't matter).
Of course I knew that i could truncating the last 50 bytes and then concatenate, but in my case i don't knew the number of the files, or their LRECL length, i just knew that each file can be 200 or 250 LRECL length.
I'm looking for a way to union the FIXED files to one truncating file.

thanks.

Hello,

First of all, thanks for your quick response !

The timing angel was smiling

but in my case i don't knew the number of the files, or their LRECL length,

How do the DD statements for file 2 thru n get into the jcl? Good news is that the lrecl does not need to be known to read a file into the sort. Whatever generates the DD concatenations could also generate a copy step for each file that would execute before the "main" step that uses all of the files.

Hi,

O.k. I'll explain the all process...
Their is a job which build dynamically a MEMBER, calling A, with all the needed files like this :

//SORTIN DD DSN=....
// DD DSN=....
// DD DSN=...

the next job knew the name of this MEMBER and use it like this :
//SORT1 EXEC PGM=SYNCSORT
//INCLUDE MEMBER=A
// SORTOUT DD *
SORT FIELDS=COPY...

This "//INCLUDE MEMBER=A" becomes to what A contains in runtime, so we get something like this :
//SORT1 EXEC PGM=SYNCSORT
//SORTIN DD DSN=....
// DD DSN=....
// DD DSN=...
// SORTOUT DD *
SORT FIELDS=COPY...

the creation of this member is not really in my hand.
Do U have something to suggest here ?

thanks.

Hello,

Read the member in some code you write (if the existing code that creates the member cannot be changed to also create the copy steps) and create a copy step for each dsn in the file. In your code you could write a JOB statement, the copy steps, and follow them with the jcl to execute the existing job and direct this to the Internal Reader (INTRDR).

I believe the better alternative would be to modify the code that creates the member to create the copy jcl in addition to the DD statements - this would make things more consistent and much easier to maintain.

Hi,
O.K. I'll try this Copy files...
I hope It will be succeed. It supposed to be a small Issue..
Thanks for now, U where very helpful.

Dan.

You're welcome - good luck and someone will be here if there are questions/problems

It supposed to be a small Issue..

Things are often easy for the person who does not have to do them. . .

d