Hello, I'm performing a syncsort joinkeys, which is failing as long as I'm using a temporary dataset. However, if I use a permanent dataset, it works just fine. Anybody have any ideas why this is happening?
Attached is the JCL. STEP001 is creating a list of key fields (policy numbers) from the INFILE that I will want to use for STEP002. STEP002 is copying the whole record (file F1) if it has the policy number from file F2. If I replace &&STEP1OUT with a permanent dataset, it works just fine :S
I'm using: SYNCSORT FOR Z/OS 1.4.0.1R
Error Messages:
Code:
AMS0000I: STEP END MXT020C2.STEP001 RC= 0000 CPU= 0.03 SEC.
+WER999A MXT020C2,STEP002 , - UNSUCCESSFUL SORT 77E W
$HASP375 MXT020C2 ESTIMATED LINES EXCEEDED
$HASP375 MXT020C2 ESTIMATE EXCEEDED BY 10,000 LINES
$HASP375 MXT020C2 ESTIMATE EXCEEDED BY 20,000 LINES
$HASP375 MXT020C2 ESTIMATE EXCEEDED BY 30,000 LINES
AMS0000I: STEP END MXT020C2.STEP002 RC= 0016 CPU= 0.50 SEC.
IEF404I MXT020C2 - ENDED - TIME=13.06.09
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Is that all the messages for the failure?
You got RC=16, but no message for that. I'm wondering if your temporary dataset was empty (as yet reason unknown), nothing comes out of the match, and your installation of Syncsort gives RC=16 for an empty joinkeys dataset.
Have you created the permanent dataset "recently", ie, has the extract program been changed since you created the permanent dataset? If the extract has been messed up so that no records are extracted, yet your "permanent" still has records on, that could account for it?
You need to confirm that the temporary is empty. Either read it with something, or make the output to a different permanent dataset. You got any counts from the key extract program?
You have a curiosity. Your main file seems to have only one record per block. The SORTOUT inherits this. Not so hot for performance.
The funny thing is, this code used to work. In fact, it ran in production last quarter end without any issues. However, we've upgraded to Syncsort version 1.4 since then. This is just a shot in the dark, but could it be the upgrade to 1.4 from 1.3?
Joined: 11 Feb 2016 Posts: 1 Location: United States
Hi,
I realise the OP may not be interested in a solution to this (probably because this issue is taken care of in SYNCSORT v2.1.1.1N), but I would still like to address this issue to help out others using the older versions of SYNCSORT.
Note that in OP's case, no conclusions were drawn from the Joinkey SNAP(s).
The same problem was reported by a programmer in my workplace with a very similar JOINKEY statement, and this particular thread was linked to.
I.
I checked the Joinkeys SNAP report (either of JNF1SNAP/JNF2SNAP depending on the parameters used to allocate each one...see below about RLSE).
and saw this:
*** DCB FORMAT ERROR. DCB DOES NOT POINT TO DEB ***
*** DCB NOT FORMATTED - COULD NOT DETERMINE THE ACCESS METHOD USED ***
II.
Searching for above error message in IBM Knowledge Center, I found this under Programmer Response:
Probable user error. Make sure that the IMGLIB CLOSE macro instruction is correctly coded.
This led me to suspect the RLSE sub-parameter in SPACE parameter specified when cataloging the temp dataset(s) used as I/P ... note that OP uses this sub-parameter in &&STEP1OUT.
III.
Subsequent searches in IBM Knowledge Center for "RLSE" and "Partial Release" indicated this:
The system ignores a request to release unused space when closing a data set if it cannot immediately obtain exclusive control of the data set. Circumstances that would preclude obtaining exclusive control include:
-- Another job is sharing the data set.
-- Another task in the same multitasking job is processing an OPEN, CLOSE, EOV, or FEOV request for any other data set.
-- Another data control block is open for the data set.,
but I was unable to find something concrete.
IV.
I still gave it a try - I removed the RLSE sub-parameter from the SPACE parameter specifications when allocating the I/P temp datasets ... and it worked!
Conclusion.
The fact that this issue is non-existent in v2.1.1.1N is definitely interesting, as it possibly points to the statement above --> The system ignores a request to release unused space when closing a data set if it cannot immediately obtain exclusive control of the data set in relation to a temp dataset.
This solution is in no way complete, as some variables are left un-addressed (which would amount to testing in various scenarios and more research), but do give it a try.
