Modern mainframe computers are equipped with more and more processors (CPUs). Therefore modern software products on the mainframe utilises the processors to execute tasks in parallel. MVS has always been handling a lot of parallel tasks so therefore both software products and our own programs must handle parallel occuring events to a certain degree. Handling parallel occuring events because of parallelism is very different from utilising parallelism or just testing for parallel occuring events when you are an ordinary programmer. Just think on how difficult it may be to start two jobs at the same time and to make them execute at the same time.
When you do not have access to use OPC or other job scheduling tools you have to submit your jobs yourself. This is usually done by using the SUBMIT command in ISPF EDIT/VIEW. By the way SUBMIT also works in ISPF BROWSE. The SUBMIT command transmits the complete content of the data being edited, viewed or browsed to JES. JES will interpret the data and determine whether the data can be executed by JES or not. If not you will receive a JCL error. On the other hand JES does not mind if the data consists of more than one job. JES expects to receive a JOB card as the first record. Then JES reads through the rest of the data validating the records one by one. If JES meets a // without any other data JES interprets this record as the end of the first job. Then JES scans through the remaining records in search for a new JOB card. If a new JOB card is encountered then the following records are treated as part of the new job until another // or JOB card is received and so forth.
According to the description above the following content of a dataset or member becomes two separate jobs when submitted:
These two jobs are guaranteed to run for a very short time and they just illustrate how you submit two jobs at the same time. To make them execute in parallel it takes a little more. Firstly the jobname of the jobs must be different. If the jobnames are equal JES will garantee you that they will be executed serially. Secondly there must be at least two so-called initiators defined for the job class used by the jobs or they have to be submitted in two different job classes. In the example you need two initiators for job class 1 in order to make the two jobs run in parallel. The third and last detail is that no other jobs must be executing which may delay the execution of your jobs. If for example there are two initiators defined for class 1 and one job is executing in class 1 when the two jobs in the example are submitted they will be executed serially instead of in parallel. Now you are aware of all the difficulties involved in getting two jobs to execute in parallel even though it is quite easy to submit them at the same time.
It is a little dangerous to write a tip including job cards because the definiton of job cards and job classes varies a lot from installation to installation. I have on purpose left out the accounting parameter (the first parameter after JOB) which is required at some installations. It is not sure that CLASS=1 will work at your installation and this may also be the case for MSGCLASS=H. In return NOTIFY=&SYSUID will ensure that the NOTIFY will be sent to the user submitting the job. By the way it is not necessary to terminate a job with // on an empty line. In the example the line may be deleted as a new job card works as a terminator for the previous job.
In SDSF there is a command called INIT (it may work in SYSVIEW as well) which shows you the connection between initiators and job classes, but many installations find that this command should only be accessible for operations people and system programmers. If you have access to TASID (try TSO TASID) there is a menu item that when selected will show you the same information as the INIT command. In the newest releases of z/OS it is possible to define job classes with varying numbers of initiators depending on the workload which makes it even harder to predict the parallel execution of your jobs.