IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

DFSORT V1R5 with use of Memory Object


IBM Mainframe Forums -> DFSORT/ICETOOL
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Philippe

New User


Joined: 10 Jan 2008
Posts: 17
Location: France

PostPosted: Wed Aug 06, 2008 3:51 pm
Reply with quote

We have a problem with use of memory object.
The records on the outfiles are sorted on a different order as if we don't use memory object
Could you help us?

I think we will disable the memory object with MOSIZE=0 but I want to understand !

Regards,
Philippe
Back to top
View user's profile Send private message
Frank Yaeger

DFSORT Developer


Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA

PostPosted: Wed Aug 06, 2008 10:36 pm
Reply with quote

You haven't really given enough information, but I can take an educated guess and say that the reason you're seeing a difference is that you don't have EQUALS in effect. When EQUALS is in effect, duplicate keys are sorted in their original order. When EQUALS is not in effect, duplicate keys can be sorted in any order. So without EQUALS, there is no guarantee that records sorted with two different techniques (memory object sorting, non-memory object sorting) or even with two different runs using the same technique will have the duplicate records in the same order. With EQUALS, that is guaranteed.

Add the following to the memory object and non-memory object runs you are comparing and see if that does the trick.

Code:

//DFSPARM DD *
   OPTION EQUALS
Back to top
View user's profile Send private message
Philippe

New User


Joined: 10 Jan 2008
Posts: 17
Location: France

PostPosted: Thu Aug 07, 2008 1:51 pm
Reply with quote

You are right Franck with the EQUALS parameter but ... our lpar has EQUALS=N for long time and it's difficult for me to explain that we have to use EQUALS=Y now.
Our direction prefer that we use MOSIZE=0 instead of modify the EQUALS=N in the production lpar (not me, I prefer use this new facility)

We only see a different order with the use of Memory Object so it appear only on lpars with Dfsort R15 ... strange no !

Best Regards,
Philippe
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Thu Aug 07, 2008 8:53 pm
Reply with quote

Hello,

So, whoever made this direction is willing for the job to create an "out-of-sequence" on some run. As Frank mentioned, the way the process is currently defined, there may be a change in the order of the output records - whether "memory object" is used or not.

It has been "luck" not "skill" that has kept the file in the proper order until now. Someday, due to a change in data volume, a change in sort key distribution, availability/arrangement of sortwork dasd, or some other reason, the order of the output will change and cause problems.

Hopefully, the people who make decisions would want to make sure problems were prevented.
Back to top
View user's profile Send private message
Frank Yaeger

DFSORT Developer


Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA

PostPosted: Thu Aug 07, 2008 11:02 pm
Reply with quote

Quote:
You are right Franck with the EQUALS parameter but ... our lpar has EQUALS=N for long time and it's difficult for me to explain that we have to use EQUALS=Y now.
Our direction prefer that we use MOSIZE=0 instead of modify the EQUALS=N in the production lpar (not me, I prefer use this new facility)

We only see a different order with the use of Memory Object so it appear only on lpars with Dfsort R15 ... strange no !


Whoever is making this decision does NOT understand the ramifications of the decision they are making.

If you need EQUALS=YES, you need EQUALS=YES. Pretending that EQUALS=YES isn't needed will most likely get your site into trouble some day (possibly at 4am in the morning). Without EQUALS=YES, there is NO guarantee that the records will be in their original order. This can happen with or without Memory Objects. Suppressing the use of Memory Object Sorting when it can be used by specifying MOSIZE=0 can degrade performance. Using EQUALS=NO for a run that needs EQUALS=YES can cause problems.

The best way to handle this would be to identify the jobs that actually need EQUALS=YES (those with duplicates that must be in their original order) and use the EQUALS option just for those jobs via:

Code:

//DFSPARM DD *
  OPTION EQUALS


instead of setting EQUALS=YES or MOSIZE=0 as the installation default.
Back to top
View user's profile Send private message
Philippe

New User


Joined: 10 Jan 2008
Posts: 17
Location: France

PostPosted: Fri Aug 08, 2008 2:18 pm
Reply with quote

Thank you very much for your help.
Now, our direction is ok to modify the EQUALS parameter and to use Memory Object with max value as the installation default

Best Regards,
Philippe
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> DFSORT/ICETOOL

 


Similar Topics
Topic Forum Replies
No new posts Modifying Date Format Using DFSORT DFSORT/ICETOOL 9
No new posts Replace Multiple Field values to Othe... DFSORT/ICETOOL 12
No new posts Calling DFSORT from Cobol, using OUTF... DFSORT/ICETOOL 5
No new posts DFsort help with SUM() DFSORT/ICETOOL 12
No new posts DFSORT - VB file RDW getting overridden DFSORT/ICETOOL 3
Search our Forums:

Back to Top