Today,I went through a SORT step which has 2 SORTOUT statements.One having the output dataset and other having DD SYSOUT=*.
He was using INCLUDE statment before SORT like
Job was giving the same output when I interchange the order of SORt and INCLUDE.Is the above way the correct way.
Also, it was having 2 sortout statement but it didn't gave JCL error.How is this possible?
Both of your questions are answered in the respective manuals.
Hint1: DFSORT Application Programmer's Guide (How DFSORT Works - DFSORT Processing)
Hint2: z/OS MVS JCL Reference (DD Statement - Name Field)
Job was giving the same output when I interchange the order of SORT and INCLUDE.Is the above way the correct way.
INCLUDE statement processing is performed before SORT statement processing regardless of the order of the control statements. I always like to specify the statements in the order they will be processed, but it doesn't really matter. For complete details on DFSORT's order of processing, see:
Frank, are you saying that DFSORT knows that two datasets with the same DDNAME appear in the JCL and that DFSORT itself makes the decision to ignore the duplicate? I ask because the JCL Manual says
"If duplicate ddnames appear in a job step, processing is as follows:
– In a JES2 system: The system performs device and space allocation and disposition processing for both DD statements; however, it directs all references to the first DD statement in the step.
– In a JES3 system: If both DD statements request JES3 or jointly-managed devices, the system cancels the job during JES3 interpretation. If only one or neither DD statement requests a JES3 or jointly-managed device, the system performs device and space allocation processing for both DD statements; however, it directs all references to the first DD statement in the step."
which I interpret as meaning that the duplicate ddname is handled by JES, not by the program being executed (e.g. DFSORT).
I'm not an expert on JES2 or JES3, so I don't know what they do with duplicate ddnames, but DFSORT has the capability of handling duplicate ddnames if it's presented with them. "Handled" is rather vague. Duplicate ddnames certainly do appear in the TIOT in various cases.
Obviously, if the system does NOT present the duplicate ddnames to DFSORT, then DFSORT doesn't need to handle them. But if the system does present the duplicate ddnames to DFSORT, then DFSORT identifies them as duplicates and uses the first one (e.g. if the two data sets have different attributes, DFSORT uses the attributes it obtains from the first one).
After further research (JES2/JES3 manuals), I have come to the conclusion that the phrase "it [meaning JES2 or JES3] directs all references to the first DD statement in the step" is really only referring to JCL references ( e.g. DSN=*.ddname, DCB=*.ddname, or VOL=REF=*.ddname), and does NOT mean references to the DDNAME by programs, themselves.
FWIW, on the JES2 systems I have worked on (I've never worked on a JES3 system), duplicate DDNAMEs DO appear in the TIOT - but only in particularly sensitive utility code have I ever had the need to traverse the TIOT (for example, to retrieve the individual DSNAMEs of concatenated datasets, or in order to detect/support the concatenation of datasets with unlike attributes). Normally I just rely on the results returned by an RDJFCB macro, which I have always assumed would be the JFCB for the first matching DDNAME provided in the JCL for the current step.
It would make sense, in retrospect, for DFSORT to traverse the TIOT to insure that all inputs, concatenated or otherwise, were 'compatible' with the sort control cards provided before undertaking what could be a resource intensive process only to encounter a DCB conflict in the 4th or 5th concatenated dataset, for example.
DFSORT would ignore the second and third SORTOUT DD statements. If you got some kind of error, then it's probably for some other reason.
(Remember that DFSORT is not the only component involved in handling your DD statements - the error could have occurred before DFSORT was even invoked.)
Obviously, I'd have to see your JES messages before I could help you figure out what you did wrong, since I can't read your mind or look over your shoulder.