Each virtual machine has some fixed set of permanently (between operator actions) allocated system components. The most common such as a mini-disk which holds information while “the virtual machine is not logged in” which means that no “operators console” is attached and no control blocks are allocated in real storage. Real disks and even whole channels can be dedicated to a virtual machine.
Other system components are allocated as the virtual machine is activated as when someone “logs in” at some terminal by naming the virtual machine and conveying the password. At least at this point the terminal is allocated to the machine as the virtual control console.
At this point one is talking to CP and can issue a number of simple commands that cause more system resources to be allocated and attached to the VM. Temporary disk “T=DISK” can be borrowed in the form of contiguous ranges of cylinders on real disks. Mini disks appear to the program within the virtual machine as a standard IBM disk except for the exceptional number of cylinders. Software written for these machines has learned not to be surprised at such sizes.
A password system for the permanent mini disks lets one attach and perhaps share mini-disks with other virtual machines.
The virtual card readers and punches play a role that has little to do with real cards. A number of consecutively virtually punched cards constitutes a “virtual deck” and can persist even after the producing machine is gone. A variety of commands from the virtual operator consoles can list, transfer, and queue in the reader of some other virtual machine. It is the original message system for VM. Virtual decks can even be turned into real decks if the real machine has a real punch!
Traffic in these virtual card decks is under control of a rather conventional set of password controlled policies imposed on the respective operator consoles. I think that the following is true: If you assign a password to your virtual punch and don’t tell anyone that password, then