Mr. Sample is correct.
However, though it is very rare these days, many sites had a procedure like this -
//SUBMIT PROC JOB='?'
//SUBMIT EXEC PGM=IEBGENER
//SYSPRINT DD DUMMY
//SYSUT1 DD DISP=SHR,DSN=SYSTEM.JOBS(&JOB)
//SYSUT2 DD SYSOUT=(A,INTRDR),DCB=(RECFM=F,LRECL=80,BLKSIZE=80)
//SYSIN DD DUMMY
There are many variations on this, but this was typical. The operator would enter -
S SUBMIT,JOB=XXX
where XXX was a member in SYSTEM.JOBS.
There were problems with this scheme. The biggest problem was the userid assigned to the submitted job. There were obvious workarounds to this problem, so it wasn't fatal. It just required care on the part of the system administrators that prepared the jobs in SYSTEM.JOBS.
It kind of disappeared in the 1990s I think it was, when two capabilities were added to the system.
- The STARTED RACF profile group allowed a userid to be assigned to a started task based on the task name.
- Started tasks could have multiple steps.
A multiple step started task is a “job,” isn't it?
As Mr. Sample says, this sort of foolishness is relegated to production scheduler systems these days.