Guest O/S Spool File Handshake Feature

[bdenton]

This PR enhances the printer and card punch device support to allow the guest O/S to tell Hercules when to open and close individual spool output files. The guest O/S can also specify the filename of each spool output file.

This update adds the handshake option to the attach and devinit commands for printer and card punch devices. This option is not allowed with either the sockdev or ``append` options.

When the handshake option adds support for two new CCWs to printer and card punch devices:

• X'F7' - Spool file open.. (can specify the name of the new file)
• X'FF' - Spool file close

The handshake option also adds the following:

• The physical output file is not opened until the guest O/S actually sends data to the printer or card punch
• The file path and extension for the resulting output file are taken from the attach or devinit command. The file name is taken from the x'F7' CCW or defaulted to the attach or devinit command
• If the output file exists, it is renamed with "_1", "_2", '_3", etc suffix similar to many popular logging facilities.

[bdenton]

responding to previous comment:

`I am also curious. Which OS supports these new ccw's? Are you proposing to modify JES2, for example, to use them?

I have included a sample update for VM370CE that implements the guest OS side of the handshake. Its behavour is totally benign if either the Hercules side is not installed or the handshake option is not configured.

I presume the JES implementation would also be possible but I don't have any expertise with that area.

As far as any consideration if some real device vendor were to build a device that implemented the F7 or FF CCW opcodes... aren't we really talking about legacy operating systems running on imaginary hardware and just satisfying fantasy dreams of us old codgers past glories?

cheers,
William

[agadsby]

@bdenton okay that makes sense. I've not looked in detail at the code yet but does it handle the case where the printer file is a pipe "| command" ?

I'm currently looking at adding a "connect" option to printers to allow it to make an outbound connection to a print server, rather than the sockdev listen approach. This allows for an elegant print server implementation for eating Hercules output, as one port could handle all the printers on the system (even from multiple Hercules').

[bdenton]

Wrt pipped printer output... The current code does not allow that with the handshake option... I should probably update the docs to show that. I suppose it could be made to work but it would be tricky for a couple of reasons...

• The current pipe management logic in printer.c is is quite different for Windows and Unix
• We would need to decide how to inform the pipe receiver of the file name passed on the x'F7' File Open CCW
• Handshake currently makes sure the full directory path on the attach or devinit command and attempts to create it if needed. This is way more complicated in the ispiped situation.

As an aside, I hadn't thought of a "print server" for Hercules before. Seems like a pretty ambitious and grand plan for antique systems running on a phone or a Pi..

cheers, William

[agadsby]

@bdenton I was only querying to check that the functionality of the pipe wasn't compromised. I'd leave it as you've described.

Actually the print splitter is fairly straightforward as the headers and trailers are generally easy to parse. On VM370CE there's no trailer page so it's necessary to use timeouts but it works well doing that.

[bdenton]

@agadsby Incorporating the guest OS handshake with a print/punch server seems interesting. It would require that the pipe receiver be able to delineate stream file boundaries and change the target names appropriately.

Seems like it might also require some sort of attach or devinit option to indicate that his is an "advanced" pipe receiver that can deal with the handshake interaction. Then the new CCW handlers introduced in this PR would need to be adjusted to pass the handshake info along to the pipe receiver.

Seems doable... but how to maintain compatibility with existing behaviour??

cheers, William

[agadsby]

@bdenton I'd probably not worry about the PIPE driver. It has an inherent design issue that you cannot overcome in Hercules nor any driven program - the pipe itself is a buffer of, typically, between 4 and 8K and unless the pipe is closed the driver cannot control the flushing of the data in the pipe. Ages ago I tried to use pipes to create a print splitter but it was doomed to fail as the end banner, or final page, often got stuck until the next job appeared, sometimes a few hours later. That's why a socket is used for this capability.

As an aside I have a modified printer.c that supports a new "connect" keyword that creates an outbound socket connection - this allows a normal print spooler to receive the files and split them as necessary. My test harness, with a Python splitter, is working well but it may be a few weeks before I've done enough testing to raise a formal PR.

Andy