On 4/21/2016 3:47 PM, Ken Cornetet wrote:
In summary, "CU mode" offers a tremendous amount of power for simh users, and requires very little effort to implement.
Very little effort? Every paper tape implementation in SimH is unique. The "central library" for paper tape, insofar as there is one, is fgetc and fputc. Besides, the proposed CU mode does exactly what the reader and punch do today anyway - namely, read or write data from or to a single file. Paper tape devices that use non-ASCII character sets provide translation to and from ASCII for text.
Magtapes? On input, exactly how are records blocked? On output, how is record blocking disentangled? Most older operating systems had specific requirements for magtape formats, in terms of record sizing and blocking. While card images are a reasonable expectation for text files in some environments, it is far from universal as a format (because it was very space inefficient, among other things). And what guest OS, aside from Unix, will allow output of arbitrary character sequences to a raw device from a console command? Assuming there even is an interactive console in the simulated environment...
As I have said before, this issue needs to be addressed simulator by simulator. For example, look at Dave Pitts' solution for IBM 7094 IBSYS, which expected an auxiliary 1401 to deal with the messy details and slow processing time of character devices. He wrote utilities that turn text files into IBSYS job decks and turn IBSYS output magtapes into text files, as well as a generalized command procedure for running jobs.
If the file transfer issue is not addressed to your satisfaction in a particular simulated environment, then take it up with the developer or maintainer of that environment.
/Bob Supnik _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
