Consider the Document detail file, which represents a series of Document Chapters. This file is the result of a DB2 unload of a table that has a foreign key to the Document table.
FB, LRECL = 175, logical record key (document number) a packed digit in position 1, 6 bytes long (s9(11) in cobol).
Also, there exists a second logical key (chapter code) at position 21, 18 characters long.
This file may contain several records with the same document number but only one record per (document number,chapter code) pair. Also, no document number exists in this file that does not exist in file 1.
Example, not accurate in terms of positions and LRECL:
What I need to do is sort the Document Detail file so that the records are:
a) first, sorted by Document Number in the same order than the Document file and,
b)second, sort all records with the same document number ascending by Chapter code[/list]
Can anyone help me do this? I have been trying some things but I get a strange order (not present in any of the input files) :roll:
As far as I can see I do not have the JOINKEYS operator available.
If you need more info to help me, let me know.
Thanks
EDIT: Just to clear this up - I do not need any of the information present in the Document file.What I need is to sort the Document Detail file according to the order of the Document Number in the Document file AND the Chapter Code of each record in the Document Detail File.
Considering the examples above, the output should be
Joined: 06 Jan 2010 Posts: 9 Location: Lisbon, Portugal
Hi,
Yes the Document number is an S9(11) COMP-3 field on both files, but your code does not provide what I need.
I need to sort the records by Document Number in the same order that the document number appears in the Document file, not descending like in your solution. I.e., I need the Document file to provide the first level sorting of the Document Detail records...
I wasn't sure about creating temp. files in a step and then later read the same file in the same step.
Out of curiosity, Is there an advantange in terms of TAPE I/Os or CPU processing when we combine multiple steps into 1 against running them as separate steps?
I looked for an answer in all dfsort manuals but couldn't find it.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
Out of curiosity, Is there an advantange in terms of TAPE I/Os or CPU processing when we combine multiple steps into 1 against running them as separate steps?
I don't know. You could try it and see.
People usually prefer to use one step if possible on the theory that less is better.
Joined: 06 Jan 2010 Posts: 9 Location: Lisbon, Portugal
Just one more thing...
This works great for my test data but when I work on a large set of data, about 500k registers to sort in the detail file, I get an SD37 Abend.
Could this be because I'm trying to allocate more space for the temporary files than I'm allowed?
I have tried googling an explanation for this abend but nothing conclusive came up.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
At the top of the page is a link to "IBM Manuals". Down the list is the z/OS System Codes publication.
Use the manual search (the flashlight/tubelight near the top left) and find d37. From there search for the actual message (IECxxxx) in the z/OS System Messages Vol VII.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Using LookAt, I found the following explanation for the D37 ABEND in IEC031I:
A data set opened for output used all the primary space, and no secondary space was requested. Change the JCL specifying a larger primary quantity or add a secondary quantity to the space parameter on the DD statement.
What do your DD statements for the temporary files look like? Are you specifying a secondary quantity? Do you have that kind of space available on your system? I'd try something like
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
That would only work if the D37 ABEND was for one of DFSORT's dynamically allocated data sets. It would not help if the D37 ABEND is for one of the temporary data sets (T1 or T2). Of course, the OP didn't really say which data set got the D37 (well, why bother to actually supply pertinent information when you can have everyone guess instead).
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Hmmm ... you should have gotten a JES message that indicated which data set the D37 was associated with. An IECxxxI message of some kind (not an ICExxxI message). If you still have the JES log from the job that got the D37, you might want to take another look for future reference. The JES messages have important information for some types of abends.
Joined: 06 Jan 2010 Posts: 9 Location: Lisbon, Portugal
Frank Yaeger wrote:
Hmmm ... you should have gotten a JES message that indicated which data set the D37 was associated with. An IECxxxI message of some kind (not an ICExxxI message).
You're absolutely right, mea culpa. I indeed found it and it referred me to the T1 dataset.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
Of course, the OP didn't really say which data set got the D37 (well, why bother to actually supply pertinent information when you can have everyone guess instead).
I retract this snippy comment given that you didn't know the info was available.
