开云体育

To quote the MTS help facility: "*FAKEOS is the OS/360 environment simulation program. Its purpose is to allow object modules containing OS/360 SVCs, control blocks, and references to OS/360 I/O

Just trying to understand what *FAKEOS does. Does *COBOLU require some sort of emulator? It seems to be issuing illegal SVC's when run without *FAKEOS. ------- Forwarded Message ------- From: René

You need to run the program in the FAKEOS environment: # run *cobolu scards=hello.cbl sprint=*print* # Execution begins ? 19:11:40 *PRINT* assigned receipt number 600001 # *PRINT* 600001 released, 4

I think the issue with *CBELL is that is requires *ASMH since it generates assembler source that it needs to hand to *ASMH, which we don't have. I'm waiting for d1996 so I can see if some of the stuff

Just tried that and got the same thing. ------- Forwarded Message ------- From: John Palmer <jpalmer@...> Date: On Sunday, May 4th, 2025 at 5:42 PM Subject: Re: [H390-MTS] Any

*COBOLU compiles fine, but the runtime library is missing. I tried $run -load+*COBLIB and got: # Execution begins ? 17:27:21 Invalid SVC (010),CLS=USER. ?PSW = 071D000A 40802220

COBOLVS is licenced code, so I assume its been removed. I think *COBOLU is the only one which works. Again the BELL "C" compiler was only licenced for universities, so again I assume its been removed

When I try to run *COBOLVS, the system responds to "ETC:VSS" does not exist. Is there some trick to getting this working? Also *CBELL is also failing. *CBELL responds with: Preprocessor/Compiler

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

Tony Harminc wrote: 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

[email protected]> wrote: No - the VM we have is of roughly the same vintage as the OS/VS and DOS OSs. Are you sure you're not think

René Ferland wrote: Really? Wow. Maybe the ones we have were before VM's time? REALLY?! Again, WOW. I specifically recall the option being there when I was working with DOS/VS(E) back in the day. I

Except for MUSIC/SP, none of the vintage systems we have implement handshaking. If I am not mistaken, George Shedlock added handshaking to DOS/VS R34, and Bob Polmanter did so for MVS 3.8J. To my

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

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.

Mike Alexander wrote: 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,

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

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? Cheers, Rene FERLAND, Montreal

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

I have a Multiprise 3000 system and, now, lots of spare disk space. It struck me a few moments ago that I can now run MTS on it. The system currently runs VM/ESA 2.4, z/OS 1.5, VSE/ESA 2.4, and MVS/XA