A task sent to the system is called a Job, managed by the Job Entry Subsystem (JES).
The Job Control Language (JCL) is not a programming language, but a procedural configuration language that describes the runtime environment of a job:
what program to run
what data set to use
with what permissions
where to write the program outputs
what parameters to be sent to the program
The JCL does not execute commands like the DOS or Linux, but describes the runtime environment of a job. (Next to JCL, there is a TSO which is analogue with the command prompt/shell and its commands under DOS/Windows/UNIX, see it there.)
JCL files are stored in partitioned datasets marked as PDS or PDS(E) as members, similarly to source codes.
The Submit Job option popping up on a JCL member is a command which submits the job to the OS. The OS component which receives the submitted job is the Job Entry Subsystem (JES), which:
schedules the jobs
executes jobs
logs jobs
The job name is the identifier of the job specified in the JOB statement; it does not automatically contain the member name. A submitted job item contains the job name, the executed member name, a job ID and the completion code (CC).
A job acts as a data set, can be opened up for showing its members like the message log, the commands and the system messages.
A submitted job starts in ACTIVE status. This status is visible after the name of the job but only if the user freshes the job under the Job section. All executing or executed jobs will appear in a browser under the Jobs section if the user searches for them.
EXAMPLE FOR DEFINITION AND TRANSFER OF VSAM BETWEEN COBOL AND JCL:
When a job is started and a dataset is created within, the new dataset is registered as a physical container in the VTOC (Volume Table Of Contents) and the pointer to it is given to the job. This means the running JCL can address it and do further processes on it, external jobs can access it only when in that other JCL the volume is given as well.
When the new dataset is introduced to the ICF catalog (official volume, track, cílinder data are rendered to the dataset name), it will be visible to other jobs without knowing the volume data. This process is called catalogization.
Obviously, if the new file is temporal, so it lives only during the execution time of the job, it does not require catalogization.
When a job is finished and the new dataset must survive the termination of the job, the catalogization is obligatory.
The ZOWE explorer searches through the ICF catalog upon listing the datasets, therefore it sees only what was catalogized.
There are 2 layers in executions:
JCL level (job control)
COBOL level (program)
The JCL job always returns a code
Completion Code (CC)
Abnormal End Code (ABEND)
When the JCL and the program finishes without any errors or warnings, CC 0000 (success) code is returned by the JES.
When the JCL detects a JCL problem, a not-success CC code is returned by the JES.
When the JCL lets the program execution through but the program stops abnormally, an Abnormal End Code (ABEND) is raised which is returned again by JES.
The return code can be monitored in the ZOWE Explorer (Jobs section) or in the JCL after the actual program block (Return Code, RC). See the JCL PROGRAMMING page for more.