IBM MAINFRAME HELP & SUPPORT FORUMS

Philippe · Joined: 10 Jan 2008 Posts: 15 Location: France

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

Frank Yaeger · Joined: 15 Feb 2005 Posts: 4613 Location: San Jose, CA

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

Philippe · Joined: 10 Jan 2008 Posts: 15 Location: France

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

dick scherrer · Joined: 23 Nov 2006 Posts: 8733 Location: 221 B Baker St

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.

Frank Yaeger · Joined: 15 Feb 2005 Posts: 4613 Location: San Jose, CA

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.

Philippe · Joined: 10 Jan 2008 Posts: 15 Location: France

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