In the TOPS-10 world, ANF-10 RJE stations could have card readers and printers.  The TOPS-10/20 DN200 also. But most "RJE" station software on the DEC side made the foreign mainframe look like a batch queue, and you would submit a file to that queue.  The software (typically DEC 2780/3780 emulation for {TOPS-10,TOPS-20, VMS, ...}) would send the file to the mainframe from an imaginary card reader; results similarly to an imaginary printer (ending up in a .log or other file).  I suppose "virtual" would be the modern word for "imaginary", but it comes to the same thing :-) On the KL based systems, the software was a combination of PDP-11 front end code (a dedicated DN20) and code running on the KL.  The KS used a KDP, though there was also a "DN22" remote station. I don't know exactly what UNIX did - wasn't in that world much then.  But I wouldn't be surprised if the strategy was similar - user prepares a file, software does the code conversions to/from EBCDIC, and the usual lies told (er, device emulation performed) in both directions...  That would certainly have led to the emulation work you recall - especially given the fluid definitions of character sets at the time.  I don't recall the same efforts to offload development to UNIX as to the DEC proprietary systems - IIRC, compilers for legacy languages (COBOL, RPG, PL/I) came to UNIX rather later, and with less rich/performant implementations.  In my experience, physical card equipment, as previously noted, was either a legacy/migration requirement, or simply a bureaucratic legacy "requirement".  The DEC value proposition was that cards were expensive, awkward, slow, and painful to create, modify/debug with.  Interactive TS solved those problems; the emulations were a medium of exchange between the legacy/enterprise systems and the more productive DEC systems.  Readers: quite common.  Punches, much less so. On 13-Feb-20 13:37, Clem Cole wrote: