MVSFORUMS.com

seekaysk · Beginner Joined: 31 Aug 2007 Posts: 49 Topics: 15

Hi,

This might be pretty simple for some of you. I had done it in past but need it in a hurry now. Can somebody please help me.

File1 (FB):

Frank Yaeger · Posted: Thu Sep 27, 2007 2:56 pm Post subject:

You can use a DFSORT/ICETOOL job like this to do what you asked for. I assumed neither input file has duplicates within it. I also assumed that both files have 80 byte fixed-length records, but you can change the job appropriately for other record lengths.

seekaysk · Beginner Joined: 31 Aug 2007 Posts: 49 Topics: 15

Thanks a lot Frank. My Input file PS is 17 bytes and output file VSAM 1053 bytes. Does that mean, I need to create the input file first to 1053 bytes and then perform the above processing ?

Thanks again.
_________________
Thanks.

seekaysk · Beginner Joined: 31 Aug 2007 Posts: 49 Topics: 15

Oh, I am sorry. My first input file is 17 bytes and another input files is 1053 bytes. Sorry for the typo.
_________________
Thanks.

seekaysk · Beginner Joined: 31 Aug 2007 Posts: 49 Topics: 15

Now, I have converted both the input files to equal length of 18 bytes of which first 17 bytes are to be compared.

I am using below but am getting message : Field beyond maximum Record length.

Frank Yaeger · Posted: Fri Sep 28, 2007 10:25 am Post subject:

I tried your JCL with input files having RECFM=FB and LRECL=18 and got cc=0. If your input files have RECFM=FB and LRECL=18, then you shouldn't get that message, so there's something you're not aware of or not telling me.

Please post your complete JCL and control statements, and all of the //TOOLMSG and //DFSMSG messages.
_________________
Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort

mvs · Beginner Joined: 08 Aug 2007 Posts: 3 Topics: 0

Try "OPTION SOLRF". My guess is that your installtion default is NOSOLRF. NOSLRF causes the output record length of the first 2 sorts to be 18, not 19, and would cause the ICE027A.

Frank Yaeger · Posted: Fri Sep 28, 2007 12:05 pm Post subject:

mvs,

Excellent guess! NOSOLRF would indeed cause the ICE027A message. I always forget about NOSOLRF since SOLRF is the shipped default and highly recommended value.

seekaysk,

Look for the following in the DFSMSG messages:

mvs · Beginner Joined: 08 Aug 2007 Posts: 3 Topics: 0

Happy to help, Frank. Even for DFSORT users. (By the way, this problem will not occur with SyncSort, which always passes through the INREC/OUTREC record lengths to SORTOUT.)

Mike Rossini
SyncSort Inc.

Frank Yaeger · Posted: Fri Sep 28, 2007 12:23 pm Post subject:

This problem will not occur for DFSORT either unless the site chooses to change the shipped default which is NOT recommended. Some sites do prefer not to have INREC/OUTREC change the SORTOUT record length - not sure why but DFSORT gives them that option if they want it. Unfortunately, those sites don't always inform their users of the change and its effects.
_________________
Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort

mvs · Beginner Joined: 08 Aug 2007 Posts: 3 Topics: 0

I think I can guess why NOSLRF would be the installation default. That WAS how DFSORT determined the output LRECL until Release 14, when SOLRF was introduced and made the default, adapting the SyncSort algorithm. Some sysprogs would be fearful of this change and thus would choose NOSLRF as their default.

(By the way, DFSORT users converting to SyncSort can have their SyncSort installation customized to use the NOSLRF approach if they choose.)

seekaysk · Beginner Joined: 31 Aug 2007 Posts: 49 Topics: 15

Frank and MVS,

Kudos to you both! I truely appreciate your time and effort in solving the problems.

I have a deadine on my head and am going with a workaround now but will surely look into the sys parm suggested and update you.

Thanks a lot again to both of you.
_________________
Thanks.

Frank Yaeger · Posted: Fri Sep 28, 2007 2:31 pm Post subject:

mvs,

If you are going to represent Syncsort on this board and make comments about Syncsort vs DFSORT, then please put your affiliation in your signature line so it will show up in every one of your posts. People on this board have the right to know the affiliations of people making comments for their company. It would also be more appropriate to use your real name as your userid as Alissa and I do rather than the very generic "mvs".

SOLRF=YES became the DFSORT default in July, 2000 via an R14 PTF, so you're talking about some pretty old history here. We actually run into very few sites that change the default to SOLRF=NO. As for who's copying who, we both know that both products copy each other to make migration easier which I'm sure customers appreciate (DFSORT offered SOLRF to make migration easier - Syncsort offered NOSOLRF to make migration easier - there are numerous other examples.)

BTW, the option is "NOSOLRF" as you correctly stated in your first post, not "NOSLRF" as you incorrectly stated several times in your last post.
_________________
Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort