Generate a new supervisor and (re-)link system components as needed to create an operational DOS/360 system that supports multiple partitions, a reasonable number of devices, and the addition of spooling by following these steps:
Edit the supervisor assembly job if desired. Assemble the supervisor, repeating as needed to eliminate errors
Link and catalog the supervisor, and re-link CORGZ, RSERV, and SSERV
IPL the new supervisor; link additional system components and system utilities
Catalog the ZAPRELO utility
Apply a patch to ANS COBOL module ILACBL51
Link sort/merge modules
Rename PL/I modules to enable PL/I system files on disk
Create a core image library for the F2 partition
Link the assembler, ANSI COBOL, COBOL D, FORTRAN, PL/I, and RPG
Assemble and catalog the DITTO utility
Apply corrections to the ISAM logic modules (ISMODxx)
The devinit Hercules commands in the following procedure include the CRLF option. This option should be omitted if you're using Hercules on a Linux system. If you omit CRLF when using a Windows platform, you'll have to fix the resulting file for viewing with Windows notepad using the following command:
type inputfile.txt | find /v "" > outputfile.txt
The supervisor provided in sysgen01.jcl works with the provided oper.cnf Hercules operational configuration; no changes are required. If you want to change options or add devices, feel free.
Do not remove support for system files on disk (FOPT macro SYSFIL=(2314,1000,1000)) because step SYSGEN09 in this stage and the POWER startup procedure requires that support.
Do not enable DASD File Protection (FOPT macro DASDFP operand). Currently available Hercules distributions do not support selector channel operations; this includes pre-built binaries and any build you may make using current committed sources. Learn why this is an issue here here.
SEND defines the end of the supervisor and the start of memory available to application programs. If SEND changed because the supervisor increased in size due to the addition of options, every application program would have to be re-linked, and often this meant every application program had to be re-compiled--recall that DOS/360 did not have a relocating loader. Space between the actual end of the supervisor and SEND was either 1) wasted space unavailable to application programs, 2) room to allow for some future expansion of the supervisor, or 3) both.
"Going Large" was not an option for SEND because memory for 360 hardware was very expensive; increasing SEND unnecessarily meant "permanently" depriving applications of memory needed to run. This is a bad thing for large applications and applications that benefit from lots of available memory, such as the Sort utility. Of course, going large in a Hercules environment is not a problem.
Use these guidelines to set SEND consistent with practice on real hardware:
Start with the actual supervisor end address
Round this value up to the nearest 2,048-byte boundary
If actual supervisor end address is already close to a 2,048-byte boundary, add another 2,048
The maximum for SEND was 32760
SEND is set to 24,576 (12 x 2,048) in the supplied sysgen01.jcl. This leaves about 1,500 bytes available for future supervisor expansion without needing to change SEND and re-link/recompile application programs.
A relocating loader did not appear until DOS/VS.
DOS/360 supported only one supervisor on a system residence volume, named $$A$SUP1. Which means doing an assemble-link-catalog in one job can break a sysres if there are errors in the assembly. So the assemble step is split from the link-catalog step to enable review of the assembly listing. This job assembles the new supervisor and punches the object deck to tape. If the assembly is clean, a second step will link and catalog.
Review the printout to see that the supervisor assembled correctly. The following three messages are expected and do not indicate an error. The statement numbers may be different if you have changed options.
STMT ERROR CODE MESSAGE
IJY046 AT LEAST ONE RELOCATABLE Y-TYPE CONSTANT IN ASSEMBLY
5755 IJY037 MNOTE STATEMENT
5756 IJY037 MNOTE STATEMENT
If there are other error messages, you'll need to address them. This step can be re-run as many times as needed. You don't need to restart Hercules to rerun this step; just restart at the "devinit 00e prt/sysgen-1-asmsup.txt crlf " statement above.
Once assembled successfully, the supervisor needs to be cataloged. In addition, three system utilities need to be re-linked because the supervisor increased in size. Further, because the new supervisor includes job accounting, a dummy $JOBACCT module must be cataloged to prevent jobs from being canceled due to "PHASE $JOBACCT NOT FOUND". You're welcome to replace the dummy $JOBACCT with a "live" one later on. Finally, the 44K assembler will be re-linked to reflect the new BG partition start address so we can use it just after the IPL of the new supervisor.
IPL configuration for this job is the same as for SYSGEN01 (we have not IPL'd)
If successful, you'll see:
1C90D NEW SUPERVISOR CATALOGED. RESPONSE REQUIRED.
Respond "IGNORE" to continue.
This step can be re-run as many times as needed if errors are reported.
This job ipl's the new supervisor and links a collection of system components and utilities.
The IPL configuration for this and all subsequent jobs is defined by the supervisor we generated in SYSGEN01. The IPL commands card deck consists, from this point forward, of a SET DATE/CLOCK command and a LOG command. All needed devices are pre-generated in the supervisor.
You should see the following on the Telnet console.
0I20I DOS IPL COMPLETE
BG 1C00A ATTN. 0 0C.
BG
The "BG" in the console messages is your proof that the new supervisor, which supports multiple partitions, has been IPL'd. It appears when the BG partition has read all of the cards in the (virtual/Hercules) card reader. You can use this message as an indication that a SYSGEN step has completed.
Continue with:
The normal method for patching a DOS/360 program was the inclusion of REP cards in a program's object deck prior to linking the program. If a system component was to be patched, one would punch the relocatable module to cards, add the REP cards, and catalog the updated module back to the relocatable library. When the relocatable module is included in a linkedit step, the patches described in the REP cards are applied to the resulting phase. See DOS System Control and Service for the format and function of REP cards.
DOS/360 was not intended to run on a hardware configuration that did not include a reader and a punch. DOS/VS release 33 was the first to support cardless operation.
DOS/360 lacks the useful PDZAP and OBJMAINT utilities, which would have allowed the earnest systems programmer to dispense with punching a possibly large binary card deck when applying object code patches to phases or relocatable modules. But under Hercules, DOS/360 is cardless (editing an EBCDIC/binary card deck in Windows is a non-trivial task).
ZAPRELO enables the insertion and deletion of REP cards to and from relocatable module decks. It reads an 81-byte record SYSPCH file, output by an RSERV PUNCH control card. All existing REP cards are deleted, and new ones read from the card reader are added. Output is an 80-byte record file suitable for SYSIPT containing the relocatable module minus all old REP cards and with the REP cards present in the card input to ZAPRELO. (It's easy to retain the existing REP cards; just DSPLY the module using RSERV and include the existing REP cards in the ZAPRELO card input.)
This step can be re-run as many times as needed if errors are reported. You may need to condense system libraries by running job sysgen90 to reclaim space.
ANS COBOL includes an error that causes generation of incorrect code when compiling a COBOL subroutine and using the cross-reference (XREF) option. Bill Carlborg found this issue, I believe while developing sample COBOL programs, and developed a correction that can be applied to DOS/VS. This is a retrofit of the PDZAP input such that it can be permanently applied to the relocatable module containing the error.
Once applied, any future linkedit of ANS COBOL, including the one in SYSGEN07, below, and in POWER09 later on, will incorporate the correction.
This step can be re-run as many times as needed if errors are reported. You may need to condense system libraries by running job sysgen90 to reclaim space.
The original DOS distribution includes 14 different choices for sort/merge, including choice of devices supported for workfiles and record types that may be sorted. These choices allowed for the conservation of disk space and memory required for the sort program.
Because disk space and memory are, at least on 1960's mainframe scales, free, we'll link only the full-function version of the disk sort/merge and the tape sort/merge. Note that we moved the disk sort merge relocatable modules from the private relocatable library to DOSRES during the MIGRATE stage.
This step can be re-run as many times as needed if errors are reported. You may need to condense system libraries by running job sysgen90 to reclaim space.
The PL/I runtime library includes two sets of subroutines for input and output, the default set that does not support system files (SYSIPT, SYSPCH, SYSLST) on disk, and a second set that do. This job renames the default set to save them and renames the set that supports system files on disk to the names required for inclusion with PL/I programs.
If this job fails, you should review the printout to determine what failed, how much was actually done, and what must be re-renamed to enable rerun from the failing step forward.
F2 should have a private core image library because DOS/360 does not include a relocating loader. Program phases linked for execution in the BG partition will not run in the F2 partition because the F2 partition has a different address range. If one wishes to have the flexibility of running a given program in either BG or F2, one must link the program twice, once for each partition. Without a private core image library, one must use different names for the BG and F2 versions of the executable, and hence two sets of JCL to run the executable.
We'll create the library on WRK14B
You may re-run this job without a special restart procedure. If you do re-run it, you may get either of the following messages:
4444A OVERLAP ON UNEXPRD FILE IJSYSPC SYS003 WRK14B -or-
4433A EQUAL FILE ID IN VTOC IJSYSPC SYS003 WRK14B
Messages 4444A and 4433A are issued during the CORGZ utility when a file exists with the same name or in the same place as the new core image library. Respod "DELETE" to delete the old file and continue with library creation.
This step links every compiler available in the DOS 26.2 distribution. The PL/I compiler is linked to include support for system files on disk. Both COBOL compilers are linked.
This step can be re-run as many times as needed if errors are reported. You may need to condense system libraries by running job sysgen90 to reclaim space.
This step assembles and links DITTO, a multipurpose file-to-file utility developed after the release of DOS. It incorporates in one program many of the functions of the several DOS-supplied utilities, and also provides a very nice collection file-to-print. DITTO saved my bacon more than once; no DOS/360 system should be without it. Proof of the value of this utility may be found in the fact that the utility still exists, much enhanced, and has been ported to other IBM mainframe operating systems, including z/OS.
This step can be re-run as many times as needed if errors are reported. You may need to condense system libraries by running job sysgen90 to reclaim space.
There is an error in the Indexed Sequential Access Method (ISAM) modules that can result in an erroneous "No Record Found" message. The correction was provided by Bill Carlborg (wjckjc822 on the Yahoo group H390-DOS-VS), and he posted the job that is executed in this step. See https://groups.yahoo.com/neo/groups/H390-DOSVS/conversations/topics/2221 for a complete discussion of the problem and its correction. (Note: H390-DOS-VS is a closed Yahoo group; request access and you should get it.)
This step can be re-run as many times as needed if errors are reported. You may need to condense system libraries by running job sysgen90 to reclaim space.
When phases, modules, or books are deleted or replaced, the library directory is updated, but that's all. After much activity, one could have lots of unusable space embedded in libraries. There is no automatic process for removing unusable space from DOS/360 libraries. One could set an automatic condense limit, which would trigger a space reclamation when needed. But that created the possibility, when running on real hardware, that a one-minute library maintenance job could turn into a 20-minute job if the limit was reached. So setting the limit for triggered library space reclamation had its downside.
We'll condense all libraries as the last step in the system generation process. This step can be run when and as needed.
Continue to the POWER stage.