DFSORT is the IBM sort/merge utility for z/OS. From an application programmer's perspective, you run it by specifying EXEC PGM=SORT or PGM=ICEMAN in JCL and supplying SORTIN, SORTOUT, and SYSIN. The actual installation—putting the program into load libraries and configuring the system—is done by system programmers. This page gives a high-level overview of what "installation" means for DFSORT and what you need to know as someone who uses it.
System programmers (or installers) are responsible for installing and maintaining DFSORT (or the sort product your site uses). They use product-specific procedures (e.g. SMP/E for IBM products) to load the program libraries and to place the load modules (SORT, ICEMAN, ICETOOL, and related modules) in the appropriate load libraries. They also ensure that those libraries are in the link-list or otherwise available to batch and TSO users. As an application programmer, you do not usually perform the installation; you assume DFSORT is available and invoke it via JCL.
When your JCL says EXEC PGM=SORT, the system (MVS/job entry subsystem) must find a load module named SORT. It searches the load library concatenation: typically the link-list libraries first, then any JOBLIB for the job, then any STEPLIB for the step. The first library that contains a member named SORT is used, and that program is loaded and executed. So the "installation" of DFSORT really means: the load module(s) are in one or more of those libraries. If your site uses a third-party sort (e.g. Syncsort), the same name SORT might point to that product's program if its library is earlier in the search order. The messages in SYSOUT (e.g. ICE for DFSORT) tell you which product actually ran.
A typical DFSORT installation includes:
IBM supplies DFSORT as part of z/OS or as a licensed program product. The exact packaging and naming can vary by release. Your site may also have a license for a different sort product (e.g. Syncsort); in that case, "installation" might mean that product is in the load library and possibly aliased as SORT or ICEMAN.
For day-to-day use you need to know:
You generally do not need to know where the load module lives on disk, the exact product level, or the SMP/E install history—unless you are debugging a "wrong program" or version issue.
If your site has more than one sort product or more than one level of DFSORT, JOBLIB or STEPLIB can be used to point to a specific load library. For example, you might add a STEPLIB before the EXEC so that the step uses a particular library first. That way you can force the use of a given product or level without changing the system link-list. Only system programmers or your support team would typically define which library to use; you might be given a procedure or JCL that already includes the right STEPLIB.
Installing DFSORT is like putting a big sorting machine in the building. The people who run the building (system programmers) bring in the machine and plug it in so that when anyone asks for "the SORT machine," the right one is there. You (the application programmer) don't install the machine—you just press the button (run JCL with PGM=SORT) and give it your pile of cards (SORTIN) and instructions (SYSIN). As long as the machine is installed and turned on, you can use it. If the button doesn't work (program not found), you ask the building people to fix it.
1. Who typically installs DFSORT on z/OS?
2. Where does the system find the SORT (or ICEMAN) program when you run a job?
3. Is DFSORT always included with z/OS?
4. What do application programmers need to know about DFSORT installation?
5. What might JOBLIB or STEPLIB be used for with DFSORT?