I have coded it for you - this time (and stripped off the editor line numbers).

Nothing extreme here. A basic understanding of JCL (see the JCL Reference Manual), sort (see the DFSORT manual) and IEBEGENER (see the utilities manual) is all you need. Links to manuals can be found at the top (the VERY top) of each page of the forum.

As you were told elsewhere, if you do the above you will see your data in the member where you expect to see it.

Your copy step, using ICEGENER, which will use a SORT COPY operation when there are no IEBGENER control cards (which there are'nt) is copying an entirely different dataset to where you want the SORTed output.

I do suggest you subscribe to the forum suggested by Rohit in his link above. It is a forum for Mainframe Beginners and Students. Even there you are unlikely to get a line-by-line description. If you consult your SORT manual, your Utilities manual and the JCL Reference you can discover all you need to know. If you still have problems, detail what you understand and what you specifically have a problem with.

If you use the manuals and discover for yourself, it will "stick" better, rather than taking someone's explanation.

You are also probably not learning in isolation, so have a tutor/colleague who should assist you with problems of understanding. It will help them greatly if they know what it is you don't know, so they can target advice and suggestions to cover the things you don't understand.

First step is to copy the data from member AREACODE to SYSOUT.
And, the Second step is to copy PUBLIC.DATA($005) to P2.OUTPUT($005)

So, the data from First Step is Not going to the Second step.

Now, Second step runs only when we get RC=0 in the First step. The first step will get a RC of 0 only if the data is copied successfully to Sysout. We have to keep in mind that there is a Sort Work file in the first step. So, the workspace for SORT is specified at CYL(1,1).

I believe, this is make sure that AREACODE doesn't have a lot of data. If member AREACODE has an amount of data which can't be handled by Sort Work file of CYL(1,1) then Don't copy data in member $005.

I think Sort work file has an important role to play in this Job.

Bill, please correct me If I am wrong about the role of the Sort work file.

A sort product like IBM's DFSORT or Syncsort is designed to process data containing millions of records, far too many to load into storage. To do this, though in fact it's far more complicated than this simple description, it copies the data to temporary storage specified by DD statements that have DD names that start with SORTWK. With the availability of dynamic allocation, the sort products can estimate the storage requirement for the work data sets and allocate them so the programmer does not need to specify SORTWKxx data sets. After all the input has been loaded into the SORTWKxx data sets it completes the sort and writes the sorted output.

Limiting SORTWK space would be an inaccurate way to limit data processed. How much SORTWK is actuallyused can depend on factors which change from run-to-run. For a record-based limit things like STOPAFT, ACCEPT and their cousins would be accurate.

Dynamic allocation of workspace is generally much more effective at avoiding underallocation/overallocation of workspace (which can impact the current step or other jobs).

If attempting to limit output DDs by space allocation, only give primary and no secondary. That is still a moveable feast generally and even more so with SORT.