MainframeMaster

DFSORT Exits

A DFSORT exit is a user-written program that DFSORT calls at a specific point during a sort or copy step. Instead of relying only on control statements such as INCLUDE, OMIT, INREC, and OUTREC, you can plug in your own code: an input exit (such as E15) that runs as records are read, or an output exit (such as E35) that runs as records are written. Exits let you implement logic that would be impossible or very awkward with built-in statements—for example, parsing variable-length records, turning one record into many, or applying custom formatting that depends on external data. This page gives an overview of DFSORT exit types, when they are invoked, how they fit into the processing pipeline, and when to use exits instead of (or together with) standard control statements.

Other DFSORT Topics
Progress0 of 0 lessons

What Is an Exit?

In DFSORT, an exit is a routine that you write and place in a load library. You tell DFSORT to use it by coding the MODS (Modifications) control statement in SYSIN and naming your load module. During the job, DFSORT loads the module and calls your routine at a defined point: for example, once per input record (E15) or once per output record (E35). Your routine receives a pointer to the record (and related control information) and returns a code that tells DFSORT what to do next—for example, "use this record," "skip this record," or "here are multiple records." So an exit is a hook where your code runs inside the DFSORT pipeline.

Why Use Exits?

DFSORT’s built-in statements are powerful: INCLUDE and OMIT filter records, INREC and OUTREC reformat them, and OUTFIL can split and format output. But some requirements cannot be expressed that way. For example: you have variable-length records with a layout that is not fixed; you need one input record to produce several output records (e.g. one header plus many detail lines); or you need to look up data in another file or table and merge it into the record. In those cases, a user exit is the right tool. You implement the logic in a program that conforms to the DFSORT exit interface, and DFSORT calls it at the right time. So exits extend DFSORT without changing the product itself.

Exit Types and When They Run

DFSORT defines several exit types. Each type is invoked at a specific phase of processing. The most commonly used are E15 (input) and E35 (output). Others (e.g. E32) exist and are documented in the DFSORT Application Programming Guide; their exact order and purpose can vary by product level.

Main DFSORT exit types
ExitPhasePurpose
E15InputCalled as each input record is read; can pass, modify, drop, or expand (one-to-many) records before sort
E35OutputCalled as each record is written; can modify or drop the output record
E32Input (alternate)Another input exit point; exact order and use documented in the DFSORT Application Programming Guide

E15: Input Exit

The E15 exit runs during the input phase. As DFSORT reads each input record (or block of records, depending on product and options), it calls your E15 routine. The routine can:

  • Pass the record through unchanged (return a code meaning "use this record as is").
  • Modify the record and return it (e.g. change bytes, reformat, or overlay fields).
  • Drop the record (return a code meaning "do not include this record").
  • Return multiple records (one input record becomes two or more records that then go into the sort).

So E15 affects what enters the sort and how it looks. It runs before the sort (and typically before or in conjunction with other input processing, depending on product). Use E15 when you need input-side logic that INCLUDE, OMIT, and INREC cannot do—for example, complex parsing or one-to-many expansion.

E35: Output Exit

The E35 exit runs during the output phase. When DFSORT is about to write a record to SORTOUT or an OUTFIL target, it can call your E35 routine. The routine can modify the record (e.g. change bytes or format) or request that the record not be written. So E35 affects what actually gets written. Use E35 when you need output-side logic that OUTREC and OUTFIL cannot express—for example, custom formatting that depends on program logic or external data.

E32 and Other Exits

DFSORT may support additional exit points such as E32 (and in some documentation, E14, E18, etc.). The exact set and order depend on the product and release. The DFSORT Application Programming Guide lists all supported exits, the order in which they are called relative to each other and to built-in processing, and the parameter list and return codes. If you need an exit other than E15 or E35, consult that manual for the correct interface and invocation order.

Processing Order: Where Exits Fit

Conceptually, input flows like this: read record → (E15 if present) → other input processing (e.g. INREC, INCLUDE/OMIT) → sort/merge → output processing (e.g. OUTREC, OUTFIL) → (E35 if present) → write record. The exact order can vary by product; the Application Programming Guide describes it in detail. The important idea is that E15 sits on the input side and E35 on the output side, so you can change data before it is sorted and again before it is written.

When to Use Exits vs Built-in Statements

Prefer built-in statements when they can do the job. INCLUDE and OMIT are easy to read and change; INREC and OUTREC handle most reformatting and field manipulation. Use exits when:

  • Record layout is variable or non-standard and cannot be described with fixed positions and lengths.
  • You need one input record to produce multiple output records (one-to-many).
  • You need to call another program, access a table, or perform logic that is not expressible in control statements.
  • You need state across records (e.g. running totals or conditional logic that depends on previous records) in a way that exits support and built-in statements do not.

Exits require a separate program, a load library, and MODS in SYSIN. They are more work to develop and maintain than control statements, so use them only when the built-in options are insufficient.

Specifying Exits: MODS

You tell DFSORT which load module(s) contain your exit code by coding the MODS control statement in the SYSIN data. Syntax varies by product; typical forms include a single module name (e.g. MODS=(MYEXIT)) or a list that assigns modules to exit types (e.g. MODS=(E15=MYE15,E35=MYE35)). The load module must reside in a dataset that is in the step’s library concatenation—usually STEPLIB or JOBLIB. If the module is not found, the step will fail at load time. For the exact MODS syntax and options for your DFSORT level, see the product documentation or the MODS statement reference.

Interface and Conventions

Each exit type has a defined interface: how DFSORT calls your routine (register conventions, parameter list layout) and what return codes you must set. Your program must follow this interface exactly; otherwise DFSORT may abend or behave incorrectly. The DFSORT Application Programming Guide describes the interface for each exit type, including parameter lists and return codes. Exits are typically written in Assembler or COBOL; the guide explains how to receive parameters and set return codes in each language.

Explain It Like I'm Five

Imagine a conveyor belt: cards come in on one side and go out on the other. DFSORT is the machine that sorts them. An exit is like a helper you station at the belt. The E15 helper stands at the front: when a card comes in, they can leave it as is, change it, throw it away, or make copies and put several cards on the belt. The E35 helper stands at the back: when a card is about to go out, they can fix it or throw it away. You tell the machine the helpers’ names (with MODS), and the machine calls them at the right time. The helpers are the programs you write.

Exercises

  1. In one sentence, what is the difference between what E15 and E35 can do?
  2. Give an example of a requirement that would make you use an E15 exit instead of INCLUDE and INREC.
  3. Where do you specify the name of your exit routine, and where must the load module be located for the step to find it?
  4. Why is it better to use INCLUDE/OMIT/INREC when they can achieve the same result as an exit?

Quiz

Test Your Knowledge

1. What is a DFSORT exit?

  • A type of sort key
  • A user-written routine that DFSORT calls at a specific point during processing so you can change, filter, or create records
  • A JCL DD name
  • An OPTION keyword

2. During which phase is the E15 exit called?

  • Output phase
  • During the input phase, as records are read
  • Only when using MERGE
  • At job termination

3. When would you choose an E15 exit instead of INCLUDE/OMIT and INREC?

  • Never; INCLUDE is always better
  • When you need logic that cannot be expressed with control statements—e.g. complex variable-length parsing, one-to-many record creation, or external lookups
  • Only for MERGE
  • Only when OPTION COPY is used

4. What does the E35 exit do?

  • Sorts the data
  • Runs during the output phase so you can modify or drop records before they are written
  • Reads SORTIN
  • Defines the collating sequence

5. How does DFSORT know which exit routine to call?

  • It is always E15
  • You name the load module(s) in the MODS control statement; MODS can assign different modules to E15, E35, E32, etc.
  • Only via JCL PARM
  • Exits are automatic