开云体育

This should work fine. MTS sometimes ran in production under VM back in the day although I don't think it ever did so at UM. It will be aware that it is running under VM and may change its behavior in a few ways, mostly dealing with error recovery. However, this may not be too useful since it won't have any support for TCP/IP.

Mike

On 7 Feb 2025, at 0:22, René Ferland via groups.io wrote:

Will it implement handshaking? That is, will MTS automatically close the spooled printer files so it will be printed by the real printer of VM?

No. It has no special support for VM. It treats VM like a funny sort of real machine.

Mike

Mike Alexander wrote:

René Ferland wrote:

Will it implement handshaking? That is, will MTS automatically
close the spooled printer files so it will be printed by the
real printer of VM?

No. It has no special support for VM. It treats VM like a funny
sort of real machine.

Most operating systems are largely, but not completely, unaware that they are running under a virtual machine such as VM, and rightly so. BUT... in a few specific places they, IMHO, do need to be aware of it. Closing their spooled printers between jobs is one such place. AFAIK all IBM operating systems do this, and IMHO so should MTS too, if/when it's run under VM.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

If I remember correctly you can use the STIDP store processor ID instruction and the info you get back (I think it's high values at the end X'FF' means it's running under VM.

Adding in:


QUERY

CPUID = aabbbbbbccccdddd

Where:

aabbbbbbccccdddd
is the 16-digit processor identification associated with the
virtual machine.

aa is the version code; these two digits are forced to X'FF' to
identify that the virtual machine is running under VM/370.

bbbbbb is the processor identification number; this field contains
six hexadecimal digits. This is the only part of the CPUID
that can be modified by means of the SET CPUID command or set
by the VM/370 directory's OPTION contrel statement.

cccc is the model number; this field contains a leftmost digit of 0
followed by three digits of the wodel number (0-9;. This
field defaults to the model number of the real machine.

dddd is the machine check extended logout; this field is forced to
X'OOOO' since CP does not reflect machine checks back to the
virtual machine.

René Ferland wrote:

Fish wrote:

AFAIK all IBM operating systems do this

Except for MUSIC/SP, none of the vintage systems we have
implement handshaking.

Really? Wow. Maybe the ones we have were before VM's time?

If I am not mistaken, George Shedlock added handshaking to
DOS/VS R34,

REALLY?! Again, WOW. I specifically recall the option being there when I was working with DOS/VS(E) back in the day. I guess back then it was something new that IBM had just recently added? I mean, I can understand earlier versions not having it (not even IBM operating systems are psychic after all, being able to predict the future), but I would have thought that virtually all of their later versions would have had it.

and Bob Polmanter did so for MVS 3.8J. To my knowledge,
there is no handshaking in DOS/360, MVT, OS/VS1, and MTS.
A work around for these systems (when run under VM) is
to use dedicated printers (and punches), something easy
to do when VM runs under Hercules, maybe not that much
on a real system. :-)

Quite right. It's not possible to have *every* VM guest use the real printer at the same time. :)

Cheers,

Rene FERLAND, Montreal

P.S. -- From the manual "Introduction to DOS/VS Release 34"
we learn, on page 124, that handshaking was provided by a
licensed product called "Advanced Functions", which explains
why it is not in the operating system we get after a sysgen
from the tapes we have.

Ah yes! I forgot about AF. My bad. The version of DOS/VSE we had was a not-yet-released still-under-development pre-AF version of DOS/VSE. (Our president was a former IBM'er and managed to get a copy of DOS/VSE before AF was officially released.) I guess that's why we had it.

My bad.

But I hope my point was made: once the feature became available, it *was* eventually incorporated into virtually all subsequent releases/versions of IBM's most popular operating systems. Perhaps not ALL of them, but most of them I suspect. And given how easy it was to do too, I can't see why ALL of the older vintage IBM operating systems that are run on Hercules today wouldn't have it. It's such a very simple tiny change.

Anyway, don't mind me. Sorry to bother you all. Just passing through. I'll go away now and leave you guys alone. :)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Tony Harminc wrote:

Are you sure you're not thinking of virtual memory handshaking?

No. I was talking about VM print spool handshaking. The guest (in this case MTS), when run under VM, being able to close its VM printer to cause its printouts to appear as separate VM spool files that the VM user could then do what they wish with. (i.e. print to VM's real printer, purge it, transfer it to their VM user's reader so they could read it in to their 'A' disk and look at it, etc).

That was the original topic of this thread after all, yes?

This was implemented long ago by end users for everything from
MVT to VS1 to DOS/VS, and only later by IBM. This is about
avoiding double paging, and having VM notify the guest when a
storage reference requires VM to bring in a page from disk, so
that the guest can dispatch another task instead of the entire
multi-tasking guest being forced to wait.

That's a completely different type of VM handshaking. AFAIK we weren't talking about that. We were talking about only the VM print spool handshaking. Yes?

This has nothing to do with closing SPOOL files and the like,
which is pretty trivial to implement.

I agree the two topics are completely different from one another, but AFAIK closing spool files and the like WAS what we were talking about, yes? Unless I missed something and the topic changed to something else midstream?

<me: confused by your reply>

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

On 7 Feb 2025, at 15:38, Mike Ward wrote:

aa is the version code; these two digits are forced to X'FF' to identify that the virtual machine is running under VM/370.

Not necessarily VM/370, it could be some other virtual machine. For example the MTS virtual machine also sets the first byte of the CPU ID to FF. If MTS is going to close its printers when a job is done, it will need a reliable way to determine if the VM it is running on supports that feature. We would also need to know how to actually do that. Presumably some diagnose instruction, but I have no idea which one.

Mike