IBM Mainframe Forum

I have a little experience with jcl/mainframe/cobol but not a lot. I am suppose to do a syncsort of a file then compare (to find NONmatches I believe) using cobol. This is what I have so far for my sync sort.



Now from what I understand is that I have to write a cobol program that takes the sorted "fileb" and compare it with another file that I have not received yet so it is not shown in the code above. I'll call it filec. Then whenever there is a file that doesn't match it outputs it into another file. I am generally having a hard time just with the syntax of how to do this. And understanding if I can write the cobol underneath the syncsort in another step. As you can tell I am pretty new to this lol. Any help will be appreciated

see here
ibm-cobol/file-match-merge-sample-code-t881.html

and/or here
http://ibmmainframes.com/about22649.html

You can, probably, also do the compare in Syncsort. The experts will need to know your dataset characteristics (RECFM and LRECL) and the key characteristics (start position, length, data type (CH, ZD etc)) for each dataset. They will also need sample input from each file and expected outputs. If you look through the sort posts you will see what I mean.

Also, to make things easier to read you should use the code tags for stuff you see on the screen. When I have finished this post I will code your original post. Note that using the quick reply button you do not get to see anything about code tags but if you use the postreply button or the full editor button you will see the code button. Search the forum for details on how to use (basically highlight the stuff to code and click the code button).

they want me to do it using Cobol as practice

the txt file attached above seems helpful. I'm trying to figure out how to execute a program properly in the jcl now

tony1131 wrote:the txt file attached above seems helpful. I'm trying to figure out how to execute a program properly in the jcl now

Not at all difficult. Some or all of this may already be known to you; I'm trying to be all-inclusive here.

When you compiled your COBOL source code, the compiler generated a object module, unsurprisingly placed in an object library. This object module, together with others that represent statically-linked subroutines, and a host of machine-language routine are linked into a load module by a program called the linkage editor or binder (do not confuse this last with the process of binding a DB2 package). Again unsurprisingly, the load module is placed in a load library.

Your JCL will then look like this:

The JOB card establishes this as a job (often miscalled a "JCL" by the ill-educated), a batch unit of work. The "other parameters" can vary greatly from
site to site; it is best to acquire a job card from a working job at your site, to ensure compliance with local standards.

The EXEC card establishes a job step, the execution of a program. I've named this step STEPN; you don't have to give a step a name, but you may well want or need to refer to it late in the job.

The DD cards are "data definition" cards (although seldom referred to by that name), each defining a data resource to be used by the step. The names are significant:

• STEPLIB defines the load library to be searched first for the program. System utilities and, often, production programs are in libraries or memory areas know to the operating system; steps running them may therefore not use a STEPLIB.
• SYSPRINT defines a data set to which messages are written and is usually allocated to the system spool (SYSOUT=*). Most system programs write to SYSPRINT, so its use is pretty standard.
• FOO and BAR are data sets used by your program (you will of course have established your own names when writing the program). Again, "other parameters" vary greatly depending on what you're trying to do).
• CEEDUMP. It's a sad fact of life that abends -- unrecoverable errors -- are likely to occur when testing a program (one of my professors at university said that any program that worked properly the first time it was run was too trivial to have been worth writing). When this happens, CEEDUMP provides a formatted dump -- printing of selected memory locations -- that can aid you in diagnosing and correcting the error.

There is of course a great deal more to JCL than this, but this may get you started.

thanks for taking the time to write such a detailed explanation, this helps a great deal. I'm going to be working on this for a lot of day. I'm sure I will have other questions lol.

Hello and welcome to the forum,

Someone will be here when there are questions/problems.

Further JCL: System utilities do not need a steplib - the OS 'knows' where they 'hang out.' Application programs, i.e. wot you write, do not need a STEPLIB if a JOBLIB is in the JCL. This comes before the first EXEC. However, you may need to point an individual step to a different load library so a steplib or steplib override will be required. An override does what it sounds like - it overrides some/all of the characteristics of a particular DD statement. It is coded in the format . Hence the need, usually, for a stepname. If the DDname does not exist then your override does not override but ADDS a new DDname.

Note that job steps ran be rolled into one piece of JCL called a PROCEDURE so instead of having loads of JCL in your run deck you have one line along the lines of

I think I found the correct load libraries to use here, Don't believe I will need to use override as you mentioned.

However after I do the syncsort I need to have my header record to stay at the top, and trailer record to stay at the bottom. Know of any way to do this?