If your mainframe experience is limited to OS/360 and/or its successors, you'll need some additional preparation before starting this adventure. Drugs and alcohol are a good start.
OS/360 includes several useful functions that DOS/360 lacked. First and foremost is a dataset catalog. OS/360 keeps track of all of the information needed to locate a dataset (volume, file characteristics, device type) in a dataset catalog, and DOS/360 does not. Disk volumes do contain location information about files stored on the volume but no more, and there's no tool to find a file given only its name. The DOS/360 JCL author must locate free space on disk volumes and make sure that file placement does not overlap other files. The programmer must deal with record formats, blocking factors, and other device-specific characteristics.
Disk space management in DOS/360 is a paper and pencil exercise that would really have been simplified if spreadsheet programs were available.
Aftermarket products for DOS/360, including DYNAM/D and DYNAM/T, added some of these capabilities to DOS.
OS/360 Job Control Language (JCL) has conditional execution, stored procedures, parameter substitution, and the ability to symbolically reference datasets created in prior steps. In a real sense, OS/360 JCL is a programming language developed to manipulate datasets.
DOS/360 has Job Control Language too. But DOS/360 JCL is a relatively simple tool for telling the mainframe which programs to run and where they can find their data, or where to put it. Everything else is up to the programmer. Many of the things OS/360 users are accustomed to coding in JCL need to be coded in the program when running under DOS/360.
OS/360 JCL expects a job card and one or more steps in which programs are executed; sometimes the programs to be executed are part of a stored procedure. For each step, the files being used or created by the program are defined in JCL statements that follow the statement naming the program to be executed. Very simple: JOB, EXEC, and DD statements. In that order.
DOS/360 JCL that identifies the files being used or created precede the EXEC statement, except for card input used by the program, which immediately follows the EXEC statement. Very simple for a DOS/360-trained person: JOB, then ASSGN, TLBL, and/or DLBL/EXTENT, then EXEC, and finally card input if any. Not so simple if you have an OS/360 background and expect things the other way round.
And in DOS/360, if two steps use the same files and control statements for those files, there is no need to repeat them prior to the EXEC statement for the second step. JOB, DLBL/EXTENT, ASSIGN, EXEC, following immediately by the EXEC for the second step.
Keep this in mind as you review the jobs in the installation stages.
OS/360 programs do not need to concern themselves with device characteristics, while DOS/360 programs have to be tailored to the characteristics of the devices they used. An OS/360 sequential file is just that, whether written to disk, tape, punched cards, or printed. OS/360 JCL provides the particulars, and OS/360 takes care of any device-specific I/O handling.
DOS/360 programs--whether Assembly or high-level language such as COBOL--must be altered, sometimes significantly, to deal with migration of an input or output file from, say, tape to disk. Or vice versa. And of course JCL needs to be changed too. Even ISAM data sets, which only exist on disk, require DOS/360 programs to deal with specifics of the disk device type.
These functional limitations made DOS/360 much simpler to develop, and IBM had a releasable product for its mainframe computers well before OS/360 became available (mid-1966 versus late 1967).
So if you've an OS/360 background, you're going to be asking "Doesn't DOS/360 take care of that?" at many points in this process. The short answer is no.
Unlike the OS/360 system generation process, which seems to start with source for the entire operating system, DOS/360 only uses source code to assemble the supervisor and a single POWER II phase. The DOS/360 distribution provided everything else in relocatable or object form. Source code was available for all DOS/360 components--and most of it has been posted to the H390-DOSVS Yahoo group--but it wasn't required to generate or use DOS/360 or its successor systems.
As a result:
IBM's transition to Object-Code-Only distributions had relatively little impact on users of successors to DOS/360.
There were relatively few modifications developed for DOS/360. This was due in part to DOS/360 installations having smaller staffs, but the fact that source code was not an integral part of the system generation played a role too.
A DOS/360 system did not require much disk space for online distribution libraries, much less than OS/360.
My contact with OS/360 is limited to that available to Hercules users, such as Jay Moseley's MVS generation web site and Jay Maynard's MVT generation web site, so I may be wrong about the above. Corrections welcomed; post to H390-DOSVS@groups.io .
Continue with a review of DOS/360 Terminology.