A job should have entered the queue, but did not run. Checking the browse data set, you see the message SP07-03, SATO-35 or SCNJ-15 saying the job is in LOCKED STATUS.
Issue a LLOCK,JOB=* top line command in CA 7 online. If the job is still in LOCKED status, then there will be a stated reason. If the reason is 'LOCKED IN LOAD', the job will have to have a successful load before it will schedule into the queue.
Do a LOAD,JOB=jobname command in CA 7. After the load has executed and flushed from the request queue, check the browse file (usually the name of this file can be found by looking for the DD name of BROWSE in the CA 7 procedure) for a message of LOAD SUCCESSFUL or LOAD UNSUCCESSFUL. If the load was successful, nothing else is required. If the load is unsuccessful, the message gives insight as to what in the load data was not able to be added or updated in the CA 7 database.
Occasionally it is reported that a job using a trailer step to DEMAND itself back in, gets an SP07-03 message in the browse file noting the job is locked. When a job executes the load step, at the end of the job (when it is back in the Request queue for job completion processing) the load data is processed to the CA 7 database. During this time, the job's database record is locked so there are no simultaneous updates to that job. Once the load data has been processed in the database, the job record in the database is unlocked and normal processing can occur. A job cannot schedule into the request queue when it is in locked status, thus you will get one of the above messages saying that the job could not schedule in. This is a timing issue -- as soon as the processing of the load data to the database has completed, the lock is removed, and the job can schedule.
If you have jobs that use trailer steps to DEMAND themselves, you should use RELOAD: X on the DB.1 screen so that the load step is never automatically inserted (a top line LOAD command would have to be done on the job to refresh the job's information in the CA 7 database).