The mainframe emulated by Hercules 390 is quite a bit bigger and faster than the original System/360.
A laptop might have 500-1000GB of disk space; a 6.9MB file is unremarkable. Data transfer on a slow system is 3gb/sec (SATA-2), a three order of magnitude improvement. And there's only one drive. A system generation that took at least ten minutes to print and might take 15-30 minutes total on real hardware takes about 4 seconds under Hercules on my six year old laptop. My laptop does have a solid state disk, so that helps. But not that much.
And my smartphone--much newer than the laptop--is happy to download at 25mb/sec over a wireless connection, beating by many miles 2.5mb over fat bus and tag cables.
As a result, it makes sense to ignore much of the minutia of DOS/360 tuning and file placement: for anyone doing this on a laptop or desktop, all data transfers ultimately end up on a single drive with a single set of heads. And just as ultimately things run a whole bunch faster on a laptop than they ever did on a real 360.
Make it easy; you're not going to get performance benefits on modern systems using 50 year old optimization advice.
Two Hercules issues need to be addressed. Hercules does not emulate selector channel operations, and the current Windows builds of Hercules-390 have issues processing compressed tape (.HET) files. Workarounds exist for both, and these workarounds are included in this site's procedures and supplied configuration and control files.
Hercules does not emulate selector channel operations.
While channel and device numbering matches what would be expected by a DOS systems programmer, each device on Hercules is emulated as if it is attached to own control unit on a separate block multiplexer channel. DOS/360 DASD file protection assumes that only one device can be active on a selector channel at a time and uses the Test Channel (TCH) instruction to see if the channel is busy. On real hardware, channels return busy to TCH when another device is active on a selector channel. Hercules does not.
The result is disk data integrity problems when DASD File Protection is generated in the supervisor. See here for details, and the discussion on this subject in the Yahoo Hercules-390 group may be of interest.
Data integrity problems have been seen when using Hercules-390 V4, either the pre-built distributions dated October of 2015 or the most recent available source dated 22-Feb-2016. Problems have not been seen in Hercules 3.12, but the coding for Test Channel is the same.
As a result, you should not generate DASD File Protection in the DOS/360 supervisor. The supervisor generated by this procedure does not include DASD File Protection support.
Compressed Standard-Label Tapes Cannot Be Used
HET-formatted tapes cannot be used for standard-label tape operations under DOS/360--or DOS/VS for that matter. Hercules does not appear to support Backspace File commands when the tape is positioned before the first tape mark. A correction has been developed for Hercules-390 4.0 (Hyperion) and my preliminary testing shows that it works, although you'll have to build Hercules-390 4.0 from source to get the fix).
See the brief discussion on the Hercules-390 Yahoo group for more information.
AWS formatted tapes work fine, and the instructions and scripts in this procedure use AWS format tapes exclusively.
You'll want to review the Hercules configuration option CRLF for printer and punch devices. Including it makes it much easier to read print and punched output in Notepad in Windows.
This procedure defines a Hercules-390 variable ${line-end-type} in the Hercules configuration file dos360.cnf that is used in all scripts and Hercules-390 configuration statements. The variable ensures that line endings are specified appropriately for the host system. It's set to "CRLF" because this procedure is initially built for Windows. Change it to "" to omit the CRLF option for other host systems. While you could include ${line-end-type} in hand-typed devinit statements, it's easier to type CRLF--or leave it off if that's appropriate for your host system.
If you forget CRLF on a devinit command, you can use the following one-line Windows command to replace Hercules' default newlines with the carriage return-linefeed combination that Windows expects:
type inputfile.txt | find /v "" > outputfile.txt
This site's installation process does not route object decks to the punch, nor does it read them from the reader. So the EBCDIC<>ASCII translations provided by Hercules help us rather than interfering with the installation.
But should you try sending object decks to the punch, or read them back in, keep the following in mind:
Specify EBCDIC on the Hercules punch device to eliminate the translation to ASCII. This also keeps non-printable EBCDIC characters from being translated to blanks.
Do not attempt to edit EBCDIC punched decks. You won't be able to read them, and any change you make will break the deck.
Specify EBCDIC on the Hercules reader when you read them back in. As an alternative to punched card object decks, assign SYSPCH to tape and later SYSIN or SYSIPT to the same tape to process object decks. This avoids the translation issues. There are plenty of examples of punching decks to tape in the installation JCL, in particular look at MIGRATE01.JCL & MIGRATE03.JCL and SYSGEN01.JCL & SYSGEN02.JCL for working examples of the technique. The generated system supports system files on disk; see SYSGEN09.JCL for an example.
The smallest Hercules virtual machine memory size is 2MB. Foreground partitions should be generated for 510KB, the maximum. And the case can be made for setting the supervisor end address pretty high. (I didn't, but you're welcome to as an exercise.) And don't waste time trimming tables to save a few bytes. Systems Programmers did this for a living--and a good living at that--but there's no payoff in the activity today. For example, the only reason to limit Logical Unit Blocks (LUBs) is to keep LISTIO output from taking too many pages.
Keep in mind that all mainframe disks under Hercules have the same seek time and the same data transfer rate. There is no performance difference between 2311 DASD and 2314/19 DASD. Both operate under Hercules at the speed of the hard drive that contains the emulated disks and the connection of that hard drive to your (personal) computer. This is true for IBM's later DASD, supported only by DOS/VS and successors, too, such as the 3330 and the 3350.
There is a difference in maximum disk volume size, but that's a discussion for another section of this web site.
Use straightforward file allocations. Don't bother with split extents. Spread files across volumes only to organize your thought process about the disks. Because all of a virtual system's disks map back to the same hard drive, you're only complicating things if you get fancy with split extents.
Use Hercules compression on your disks, -0 at a minimum. -0 implements the compression on-disk structure without compressing data and eliminates PC disk space being allocated for free space on the emulated volume. The -z option, which does compress data, worked fine for me. It depends on the speed of your workstation's processor and disk. Hercules utilities exist to change emulated disk compression characteristics.
DOS/360 is equally functional with the Hercules 390 integrated console (Hercules device type 1052-C or 3215-C) or a standard telnet client.
Hercules 3.x does not work with PuTTY, a popular no-cost Telnet application. The Telnet included with Windows NT works, as does the Telnet included with Windows 10. This is a Hercules issue, not a DOS/360 issue.
Hercules V4 works with common telnet clients including PuTTY.
Find out About POWER II, the spooling system IBM developed for DOS/360.