search

s390guy / vm370

35 stars 10 forks source link

Align config with MVS TK4- #12

Closed g4ugm closed 3 years ago

g4ugm commented 3 years ago

MVS.DIRECT.TXT MVS.CONF.TXT

One of the first things I change with any of the older sixpack releases is to change the MVS config to support IPLing TK4- under VM/370 - it works pretty well, but I've always wondered where the default configuration in the sixpack comes from.

Here is a small diff to vm370ce.conf and USER DIRECT that configures the system to use TK4-'s dasd config out of the box. All you need to do is create a directory named "mvs" under the VM370CE home dir, and unzip the TK4- distribution into it.

I should write up some simple instructions on IPLing TK4- under VM/370 and shutting it down (the standard procedures work fine, but running it as a VM doesn't trigger TK4-'s nice automatic scripting stuff).

Joe

BobBolch commented 3 years ago

We should include information on how to generate a V=R CP Nucleus for TK4. Bob Bolch

jgeorge44 commented 3 years ago

Quick and Dirty V=R Nucleus Building for VMCE V1R1

In under to unlock VIRT=REAL support in VM/370 CE, to take advantage of the performance boost that VIRT=REAL gives to other operating systems running as clients under VM/370 (like MVS under VM, for example), you need to rebuild the CP nucleus on the system to support a VIRT=REAL memory area. The default nucleus under VMCE does not enable VIRT=REAL, because if you're not using any applications that can take advantage of it, it's just memory wasted that can be used for other users and other applications.

If you need VIRT=REAL support, enabling it is pretty easy - you do need to recompile and load a new CP nucleus, but VMCE is already pre-configured to make this simple even for the less experienced MAINT user. The procedure below will enable V=R support with no other changes to the CP nucleus:

LOGON MAINT CPCMS CP SPOOL PUN CP SPOOL PRT VMSETUP CP

This will set up the MAINT user's VM for recompiling the CP nucleus and spooling the output back to the MAINT user's virtual reader.

Execute the command below and respond to the prompts:

VRSIZE VIRTUAL=REAL OPTION REQUIRED (YES,NO): yes STORAGE SIZE OF VIRT=REAL <MINIMUM IS 32K>: 8192K 08192K STORAGE SIZE FOR VIRTUAL=REAL IS THE ABOVE ENTRY CORRECT (YES,NO): yes

Recompile the CP nucleus with the command:

VMFLOAD VRLOAD DMKHRC

VRLOAD builds the VIRT=REAL nucleus. You will get a card deck routed to your virtual reader as a result: SYSTEM LOAD DECK COMPLETE PUN FILE 0342 TO MAINT COPY 01 NOHOLD

Take the spool ID from the output above and put it at the top of your virtual reader, and IPL from it:

ORDER RDR 342 0001 FILE ORDERED

IPL C CLEAR Nucleus loaded on VM50-1 --- Starting CYL=0530, last CYL used=0548 CP ENTERED; DISABLED WAIT PSW '00020000 00000012' CP

At this point, re-IPL CMS and save the nucleus map to disk in case it's needed. When you IPL CMS, you will get a print file spooled to your virtual reader:

IPL CMS PRT FILE 0344 TO MAINT COPY 01 NOHOLD

Re-order the reader to put this file at the top of the deck, and then read it to your A disk:

ORDER RDR 344 READCARD VRNUC MAP READCARD VRNUC MAP

The first READCARD command will fail with a "READER EMPTY OR NOT READY." error. The second one will save the file VRNUC MAP to your A-disk.

Once this file is saved, re-IPL VM/370 and check the console messages for V=R support:

SHUTDOWN REIPL (system will re-IPL and MAINT will be logged off)

The operator console (in the Hercules window) will show:

DMKCPI957I Storage size = 16384 K, Nucleus = 328 K,
Dynamic Paging = 07108 K, Trace Table = 248 K,
Free Storage = 0508 K, Virtual=Real = 08192 K

If you see "Virtual=Real = 08192 K" then you have successfully enabled this support in your CP nucleus, and client OSes that take advantage of it will see upwards of a 2x performance increase.

To disable this support, follow the same directions above except run VMFASM CPLOAD DMKHRC (CPLOAD does not include V=R support), install that nucleus via the same steps above, then save off the map as CPNUC MAP instead of VRNUC MAP.

jgeorge44 commented 3 years ago

VIRTREAL.MEMO.TXT

VIRTREAL.MEMO.TXT

BobBolch commented 3 years ago

Joe, Could you put together those instructions on the TK4- install? I would like to try it out to validate the directory additions. Thanks/Bob

jgeorge44 commented 3 years ago

Working on this, sorry, been out of town last week. Trying to figure out what the best directory naming convention would be to put tk4- under the VMCE home directory, or put it parallel to the VMCE home directory. TK4- unzips to a current directory (as opposed to VMCE that unzips to it's own directory) so that complicates the process a little bit.

BobBolch commented 3 years ago

I had planned to consolidate the Community Edition 3350s on a single string of addresses from 140-14F. I see that the tk4- setup uses those addresses. It is easy to change the tk4- setup? Could we wall off a set of addresses (with some spares) to be used for a tk4- guest? Maybe I should use something else for VM disks (6A0-6BF?).

Bob

On Mon, Apr 19, 2021 at 4:37 PM Joe George @.***> wrote:

Working on this, sorry, been out of town last week. Trying to figure out what the best directory naming convention would be to put tk4- under the VMCE home directory, or put it parallel to the VMCE home directory. TK4- unzips to a current directory (as opposed to VMCE that unzips to it's own directory) so that complicates the process a little bit.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/s390guy/vm370/issues/12#issuecomment-822768422, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARUFCBMRLZE3CBZVT2FF6JTTJSH7ZANCNFSM4Z6CGAVA .

jgeorge44 commented 3 years ago

I had planned to consolidate the Community Edition 3350s on a single string of addresses...

Please! Scattering disks across controllers is good practice with real ancient iron, but performance wise I can't see how it makes much of a differences under Hercules, and claiming a string (or two even) for CE volumes simplifies a lot of DASD address juggling for other client OSes that much easier.

The addresses that MVS needs are largely irrelevant to what VM uses - all we need to do is make sure that the affected volumes are attached to VM in some non-conflicting addresses, and then just re-map them with DEDICATE statements in the directory to put them back in the right places for MVS.

For 3350 volumes, 440-44F seems "unused" (other than VM/370), as are 540-54F, and 6F0, 7F0, and 8F0 strings just off the top of my head.

CMSDOS defaults to 6A0 and 7A0, but moving them is easy enough as well (since they come with the VMCE package anyway) so those are also two nice big blocks as well.

Personally I'm fond of 440-44F but not for any technical reasons. :)

mgrossmann commented 3 years ago

Hey together,

I'm in trouble :)

/MIkeG

Recompile the CP nucleus with the command:

VMFASM VRLOAD DMKHRC

VRLOAD builds the VIRT=REAL nucleus. You will get a card deck routed to your virtual reader as a result: SYSTEM LOAD DECK COMPLETE PUN FILE 0342 TO MAINT COPY 01 NOHOLD

vmfasm vrload dmkhrc               
File 'VRLOAD ASSEMBLE *' not found.
*** VRLOAD ASSEMBLE NOT FOUND ***  
l vrload * *                
VRLOAD   EXEC     F1        
VRLOAD   EXEC     G1        
Ready; T=0.01/0.01 12:57:53
BobBolch commented 3 years ago

Hi Mike, The correct command is:

VMFLOAD VRLOAD DMKHRC

Sorry I missed that. Bob

On Tue, Apr 20, 2021 at 8:57 AM Mike Großmann @.***> wrote:

Hey together,

I'm in trouble :)

/MIkeG

Recompile the CP nucleus with the command:

VMFASM VRLOAD DMKHRC

VRLOAD builds the VIRT=REAL nucleus. You will get a card deck routed to your virtual reader as a result: SYSTEM LOAD DECK COMPLETE PUN FILE 0342 TO MAINT COPY 01 NOHOLD

vmfasm vrload dmkhrc File 'VRLOAD ASSEMBLE *' not found. VRLOAD ASSEMBLE NOT FOUND

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/s390guy/vm370/issues/12#issuecomment-823251848, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARUFCBJRO6WFG7HZSC7Z5SLTJV23ZANCNFSM4Z6CGAVA .

mgrossmann commented 3 years ago

will give it at try :)

mgrossmann commented 3 years ago

It's working great ... thank you

Now, I will IPL MVS :)

jgeorge44 commented 3 years ago

Darnit, mea culpa. I mess that up ALL the time. You'd think I'd learn it by now. :) updated instructions above and VIRTREAL MEMO above

mgrossmann commented 3 years ago

It doesn’t matter. It’s working, now. 🤓

MVS is running now inside VMCE. 👌💪

CPU rate dropped by about 15-12 percent. (Measured by rexxcps. VMCE is running on a PI3.)

That‘s ok, I think.

But the overall performance is very bad. I think the IO is to bad. Will try it on a PI4 with a USB3 SSD.

Best

/MIkeG -- Von Gmail Mobile gesendet

jgeorge44 commented 3 years ago

My biggest beef with TK* is that there are a handful of DASD volumes of every conceivable type, and that makes allocating addresses for them a major PITA because they take up so much address space. Since we can use DEDICATE in the directory to map VM370 DASD addresses to the "real" ones that TK4- needs, do you think it would be worth compressing the address space used for TK4- into as few strings as possible, then remapping them in the directory? The configuration I posted initially in this issue does that for some of the DASD (the 1A0 string for example) but I wonder if we should try to consolidate on as few addresses as we can and maybe all in a similar range, to free up address space for other OSes and other expansions? Let me work on an example and I'll post it here.

jgeorge44 commented 3 years ago

Okay, I hate this, but it's arguably... "better". Relegated all the TK4- DASD volumes to VM/370 addresses 3xx and 9F0-9F7. TK4- has DASD of almost every possible type, so it's not easy to collapse the addressing down to anything any smaller. Basically, almost all of the Tk4- DASD has been mapped to 33x, 34x, 35x, 36x, 38x, and 9Ax addresses (needed 9Ax because there are SEVENTEEN 3350 volumes in the config, grr).

FWIW DOS/VS does something similar by mapping it's DASD volumes up into 9Ax instead of 36x. We could then, if needed, allocate sequential blocks of addresses to do similar mappings for other potential "drop-in" OS clients in the future if we wanted to pre-configure client OSes to add to VMCE for people (MUSIC/SP, UTS, other VM/370 systems, and so on).

Basically this frees up most addresses in 1xx, 2xx, 4xx, 5xx, and then up for other purposes (other OSes of whatnot). You could then re-assign the VMCE DASD into the lower 140-14F addresses if you wanted, or whatever else float's your CUU powered boat. :-)

MVS.DIRECT.TXT MVS.CONF.TXT

BobBolch commented 3 years ago

Hi Joe, I agree that I hate this too :-)

Wouldn't it be easier to just relocate the 8 or 9 or 10 VM dasdi to channel 4 and higher? Rewiring with DEDICATE is just plain ugly. It's trivial for me to vacate channel 1,2, and 3 and uncomplicate the dedicates.

Can anyone enlighten me on why tk4- decided to employ such a plethora of dasdi device types? Maybe it's just like dessert - I'll have one of each!

Bob

On Tue, Apr 20, 2021 at 9:37 PM Joe George @.***> wrote:

Okay, I hate this, but it's arguably... "better". Relegated all the TK4- DASD volumes to VM/370 addresses 3xx and 9F0-9F7. TK4- has DASD of almost every possible type, so it's not easy to collapse the addressing down to anything any smaller. Basically, almost all of the Tk4- DASD has been mapped to 33x, 34x, 35x, 36x, 38x, and 9Ax addresses (needed 9Ax because there are SEVENTEEN 3350 volumes in the config, grr).

FWIW DOS/VS does something similar by mapping it's DASD volumes up into 9Ax instead of 36x. We could then, if needed, allocate sequential blocks of addresses to do similar mappings for other potential "drop-in" OS clients in the future if we wanted to pre-configure client OSes to add to VMCE for people (MUSIC/SP, UTS, other VM/370 systems, and so on).

Basically this frees up most addresses in 1xx, 2xx, 4xx, 5xx, and then up for other purposes (other OSes of whatnot). You could then re-assign the VMCE DASD into the lower 140-14F addresses if you wanted, or whatever else float's your CUU powered boat. :-)

MVS.DIRECT.TXT https://github.com/s390guy/vm370/files/6347476/MVS.DIRECT.TXT MVS.CONF.TXT https://github.com/s390guy/vm370/files/6347477/MVS.CONF.TXT

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/s390guy/vm370/issues/12#issuecomment-823711208, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARUFCBNVODWYKESNRXP7RQDTJYT4HANCNFSM4Z6CGAVA .

BobBolch commented 3 years ago

Mike,

Did you issue these suggested commands for MVS under VM: CP SET STBYPASS VR CP SET NOTRANS ON

I am interested to see if they improve performance. Bob

On Tue, Apr 20, 2021 at 12:16 PM Mike Großmann @.***> wrote:

It doesn’t matter. It’s working, now. 🤓

MVS is running now inside VMCE. 👌💪

CPU rate dropped by about 15-12 percent. (Measured by rexxcps. VMCE is running on a PI3.)

That‘s ok, I think.

But the overall performance is very bad. I think the IO is to bad. Will try it on a PI4 with a USB3 SSD.

Best

/MIkeG

Von Gmail Mobile gesendet

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/s390guy/vm370/issues/12#issuecomment-823411758, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARUFCBLLGJY6YQP47N5RFWDTJWSFRANCNFSM4Z6CGAVA .

mgrossmann commented 3 years ago

Mike,

Did you issue these suggested commands for MVS under VM: CP SET STBYPASS VR CP SET NOTRANS ON

I am interested to see if they improve performance. Bob

Oops, didn’t saw this commands. My fault. Do I have to enter this commands as MVS user?

/MIkeG

mgrossmann commented 3 years ago

Bob,

I have issued the mentioned commands on my PI3 based system. And yes, MVS is running noticeably faster / more responsive.

Still not really good, but much much better.

Will test my second installation (PI4) later today.

/MIkeG

BobBolch commented 3 years ago

Mike, Yes. I think you would issue them before the IPL of MVS. Bob

On Wed, Apr 21, 2021 at 7:09 AM Mike Großmann @.***> wrote:

Mike,

Did you issue these suggested commands for MVS under VM: CP SET STBYPASS VR CP SET NOTRANS ON

I am interested to see if they improve performance. Bob

Oops, didn’t saw this commands. My fault. Do I have to enter this commands as MVS user?

/MIkeG

-- Von Gmail Mobile gesendet

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/s390guy/vm370/issues/12#issuecomment-823978133, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARUFCBN7BAMHCW2LC2UB3YDTJ2XANANCNFSM4Z6CGAVA .

mgrossmann commented 3 years ago

Bob,

currently MVS was auto IPLed by the user directory. But as I mentioned, the performance increase is noticeably better. So it seems to work, even if I issued the commands after the IPL.

Another question. I tried to get MVS/NJE running through VMCE. I added my original hercules config line to the vm370ce.conf: 0090 tcpnje 2703 ....

And I also added a DEDICATE 090 090 to my user direct file.

But it won't work. Do I have to use an device id known by VMCE? e.g. 0041`

L MVS MVS                                              
STORAGE IS VIRTUAL=REAL                                
DMKLOG090E DEV 090 NOT DEFINED; DEV 090 NOT AVAILABLE  
FILES:  NO RDR, 014 PRT,  NO PUN                       
LOGON AT 12:00:12 GMT WEDNESDAY 04/21/21               
IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 03.8 .VS2

Best MIkeG

BobBolch commented 3 years ago

Mike,

Can you issue these commands from MAINT after MVS is logged on (but not IPLed)?

CP Q 90 CP ATTACH 90 to MVS 90

Bob

On Wed, Apr 21, 2021 at 8:08 AM Mike Großmann @.***> wrote:

Bob,

currently MVS was auto IPLed by the user directory. But as I mentioned, the performance increase is noticeably better. So it seems to work, even if I issued the commands after the IPL.

Another question. I tried to get MVS/NJE running through VMCE. I added my original hercules config line to the vm370ce.conf: 0090 tcpnje 2703 ....

And I also added a DEDICATE 090 090 to my user direct file.

But it won't work. Do I have to use an device id known by VMCE? e.g. 0041`

L MVS MVS STORAGE IS VIRTUAL=REAL DMKLOG090E DEV 090 NOT DEFINED; DEV 090 NOT AVAILABLE FILES: NO RDR, 014 PRT, NO PUN LOGON AT 12:00:12 GMT WEDNESDAY 04/21/21 IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 03.8 .VS2

Best MIkeG

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/s390guy/vm370/issues/12#issuecomment-824009563, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARUFCBIWASWJLMKV7M7GSI3TJ253XANCNFSM4Z6CGAVA .

mgrossmann commented 3 years ago

Thanks Bob :)

q n                                                                          
MVS      - DSC, OPERATOR - 009, RSCS     - DSC, CMSBATCH - DSC               
CPWATCH  - DSC, MAINT    - 0C0                                               
Ready; T=0.01/0.01 14:05:18                                                  

                                                            RUNNING   VM370CE
s390guy commented 3 years ago

Small suggestion. Where questions concerning TK4- come up, perhaps that user community should be looped in at least via the turnkey-mvs@groups.io list. They probably best know "why" things have been done as they are.

Harold

s390guy commented 3 years ago

I would encourage accommodating TK4-. The fewer changes in TK4- the better. This is particularly true for I/O devices. Any change that trickles into TK4- I/O device numbering forces a regen for TK4-. Yes, the devil is always in the details, so it might not always be possible.

Harold

BobBolch commented 3 years ago

Hi Harold, I agree about the why questions. I did ask about why it has almost every dasdi device type on the planet, but I really don't care :-).

I strongly agree with your point about not requiring TK4- changes. It's easy to have the Community Edition disks just move out of the way and leave channels 1, 2, and 3 for MVS to do what it wants. The VM directory for Community Edition V1R1.1 will have commented dasd statements in the config file for the MVS disks. The MVS under VM install will be unpacking its zip file and uncommenting the dasd in the vm370ce.conf file.

It has to be easy enough for me to do it, and I last messed with an OS system (VS1) in 1975. Bob

jgeorge44 commented 3 years ago

Wouldn't it be easier to just relocate the 8 or 9 or 10 VM dasdi to channel 4 and higher?

It would, and I'll try that next. However even this way TK4- will need SOME "mapping" in DEDICATE because TK4- defines 3375 and 3390 devices at addresses that aren't defined in DMKRIO. We have to have DEDICATE lines for each DASD anyway, and most of them will be straight-mapped but at least 5-6 of them will have to be mapped to different addresses anyway.

BobBolch commented 3 years ago

Moving the CP packs works fine.

I missed seeing any addresses that did not match RIO. Easy fix though, just update RIO to match.

Bob

On Wed, Apr 21, 2021, 2:24 PM Joe George @.***> wrote:

Wouldn't it be easier to just relocate the 8 or 9 or 10 VM dasdi to channel 4 and higher?

It would, and I'll try that next. However even this way TK4- will need SOME "mapping" in DEDICATE because TK4- defines 3375 and 3390 devices at addresses that aren't defined in DMKRIO. We have to have DEDICATE lines for each DASD anyway, and most of them will be straight-mapped but at least 5-6 of them will have to be mapped to different addresses anyway.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/s390guy/vm370/issues/12#issuecomment-824266329, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARUFCBMOCLSYWZBA3SQINOLTJ4J7DANCNFSM4Z6CGAVA .

jgeorge44 commented 3 years ago

I dont think VM/370 supports 3375 or 3390 though? Since VM never looks at the volumes, I've always configured them on 3380 addresses and then used DEDICATE to map them to the right addresses under MVS (which has a sysgen to support them)

BobBolch commented 3 years ago

Hi Joe,

I dimly remember specifying some devices unsupported by CP which were dedicated to a guest (MVS maybe) using the unsupported device type with CLASS= to specify the device classification (DASD in this case). That way CP would not mess with it. I will experiment with that. Defining one to one DEDICATEs appeals to me, if it is possible. Bob

On Wed, Apr 21, 2021 at 3:55 PM Joe George @.***> wrote:

I dont think VM/370 supports 3375 or 3390 though? Since VM never looks at the volumes, I've always configured them on 3380 addresses and then used DEDICATE to map them to the right addresses under MVS (which has a sysgen to support them)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/s390guy/vm370/issues/12#issuecomment-824318097, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARUFCBM63IXIVZ43HQNR4ALTJ4UTTANCNFSM4Z6CGAVA .

jgeorge44 commented 3 years ago

I don't think I've seen that before. If you can give me an example, I'll work that up.

BobBolch commented 3 years ago

Hey Joe, I think that Class=DASD on device, with an unsupported device type on an Rdevice macro will producean rc=4 when you reassemble RIO. /Bob

On Wed, Apr 21, 2021, 5:58 PM Joe George @.***> wrote:

I don't think I've seen that before. If you can give me an example, I'll work that up.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/s390guy/vm370/issues/12#issuecomment-824385011, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARUFCBLMY5OHWSA5XX5TWA3TJ5C6ZANCNFSM4Z6CGAVA .

BobBolch commented 3 years ago

I downloaded the tk4 system and there are disks defined in the MVS.CONF.TXT and MVS.DIRECT.TXT files that are not in the tk4 download I have. The tk4- Idownloaded has empty files for cbt_dasd.cnf, source_dasd.cnf, etc. The sample files above look like they have disks that should be in those directories. I think we should expand the tk4- zip file into an 'mvs' subdirectory within the VM370CE.V1.R1.1 directory and base the vm370ce.conf commented mvs dasd definitions on that structure.

  1. Does anyone disagreee with that location.
  2. Do the cbt, source, etc. disks (which appear optional) belong in the ...\VM370CE\mvs\dasd directory, or somewhere else? I want the mvs subdirectory to look just like it would it it were running under Hercules, instead of under VM.

I need to wrap up this issue, because it is already delaying the VM release. Thanks/Bob

jgeorge44 commented 3 years ago

The original goal (Dave's comment from my post on the group) was to keep TK4- untouched. Unzipping TK4- into an mvs/ directory under VM370CE allows TK4- to run unmodified from that location as normal, with the added benefit of being able to IPL that same system under VM370 with the same disks. The missing disks (CBT and SRC) are optional for TK4- install, but if they are installed they go into the TK4- dasd/ directory in their usual places (mvs/dasd/ from our PoV, just like everything else)

We can always do this better/differently in future releases, but I think that's the least number of changes to make it all work under VMCE.

BobBolch commented 3 years ago

I modified the V1R1.1 release candidate to use these conf statements and mvs directory entry. Any final comments?

Thanks/Bob

On Thu, Apr 22, 2021 at 12:37 PM Joe George @.***> wrote:

The original goal (Dave's comment from my post on the group) was to keep TK4- untouched. Unzipping TK4- into an mvs/ directory under VM370CE allows TK4- to run unmodified from that location as normal, with the added benefit of being able to IPL that same system under VM370 with the same disks. The missing disks (CBT and SRC) are optional for TK4- install, but if they are installed they go into the TK4- dasd/ directory in their usual places (mvs/dasd/ from our PoV, just like everything else)

We can always do this better/differently in future releases, but I think that's the least number of changes to make it all work under VMCE.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/s390guy/vm370/issues/12#issuecomment-824999720, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARUFCBJKJISETPDF467BYD3TKBGDLANCNFSM4Z6CGAVA .

Dedicated MVS stuff for running TK4- MVS as a guest operating system.

Download TK4- from http://wotho.ethz.ch/tk4-/tk4-_v1.00_current.zip

Create a directory named "mvs" under the current VM370CE installation

unzip the file in the "mvs" directory

Un-comment these lines if you want to use it.

Note that the actual disk packs are not included with this distribution!

010C 3505 jcl/dummy eof ascii trunc

030c 3505 mvs/jcl/dummy eof

030e 1403 mvs/log/hardcopy.log

#

0131 2314 mvs/dasd/sort01.131

0132 2314 mvs/dasd/sort02.132

0133 2314 mvs/dasd/sort03.133

0134 2314 mvs/dasd/sort04.134

0135 2314 mvs/dasd/sort05.135

0136 2314 mvs/dasd/sort06.136

#

0140 3350 mvs/dasd/work00.140

0148 3350 mvs/dasd/mvsres.148

0149 3350 mvs/dasd/smp001.149

014a 3350 mvs/dasd/smp002.14a

014b 3350 mvs/dasd/smp003.14b

014c 3350 mvs/dasd/smp004.14c

#

0152 3330 mvs/dasd/hasp00.152

#

0160 3340 mvs/dasd/page00.160

0161 3340 mvs/dasd/page01.161

#

0170 3375 mvs/dasd/work01.170

#

0180 3380 mvs/dasd/work02.180

#

0190 3390 mvs/dasd/work03.190

0191 3390 mvs/dasd/mvscat.191

#

0240 3350 mvs/dasd/pub000.240

0241 3350 mvs/dasd/pub010.241

0248 3350 mvs/dasd/mvsdlb.248

#

0270 3375 mvs/dasd/pub001.270

0271 3375 mvs/dasd/pub011.271

#

0280 3380 mvs/dasd/pub002.280

0281 3380 mvs/dasd/pub012.281 #

0290 3390 mvs/dasd/pub003.290

0291 3390 mvs/dasd/pub013.291

#

0340 3350 mvs/dasd/cbt000.340

0341 3350 mvs/dasd/cbt001.341

0342 3350 mvs/dasd/cbt002.342

0343 3350 mvs/dasd/cbtcat.343

0348 3350 mvs/dasd/src000.348

0349 3350 mvs/dasd/src001.349

034a 3350 mvs/dasd/src002.34a

034b 3350 mvs/dasd/srccat.34b

jgeorge44 commented 3 years ago

hold up. what you posted above won't work because it defines DASD on 170,190, 270, and 290, which aren't in DMKRIO. The CONF and DIRECT posted in the first comment here are (I think) as close as we can get to direct mapping, they're all direct mapped except the 3380, 3390, and 3375 DASD are all mapped to 1A0-1AF and then reassigned with DEDICATES in the directory. I know you don't like that (I don't either) but I think thats the best we're going to be able to do without changin DMKRIO which I wouldn't want to do for this release.

We can always fix DMKRIO and re-map this stuff in a future release, since the actual DASD volumes aren't changing, just how we map them to addresses in VM, we should be able to tweak this stuff with some level of impunity in the future.

BobBolch commented 3 years ago

Hi Joe, Please explain why you don't think I should change RIO. Thanks/Bob

On Thu, Apr 22, 2021, 3:31 PM Joe George @.***> wrote:

hold up. what you posted above won't work because it defines DASD on 170,190, 270, and 290, which aren't in DMKRIO. The CONF and DIRECT posted in the first comment here are (I think) as close as we can get to direct mapping, they're all direct mapped except the 3380, 3390, and 3375 DASD are all mapped to 1A0-1AF and then reassigned with DEDICATES in the directory. I know you don't like that (I don't either) but I think thats the best we're going to be able to do without changin DMKRIO which I wouldn't want to do for this release.

We can always fix DMKRIO and re-map this stuff in a future release, since the actual DASD volumes aren't changing, just how we map them to addresses in VM, we should be able to tweak this stuff with some level of impunity in the future.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/s390guy/vm370/issues/12#issuecomment-825127993, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARUFCBMF52ULBKK34WEMAY3TKB2SDANCNFSM4Z6CGAVA .

jgeorge44 commented 3 years ago

If this MVS stuff is holding up release, I think changing DMKRIO might be a big change to throw in at the last minute, thats all. I didn't see in your comment above that you changed DMKRIO to make that work, if you already did and there's nothing else that might be affected by it, then I redact my comment. :)

BobBolch commented 3 years ago

Thanks, Joe. I think that these small RIO changes make sense. The manuals do indicate that devices supported by guests only, and not supported by CP, should specifically be identified. This is so that CP we will only pass through requests from the guest, and not initiate any requests itself (including diagnose I/O).

The suggestion to put the TK4- download into a VM370CE.V1R1.1\mvs directory and uncomment statements in vm370ce.conf to connect it will make that install very easy for experimenters.

On Thu, Apr 22, 2021, 3:57 PM Joe George @.***> wrote:

If this MVS stuff is holding up release, I think changing DMKRIO might be a big change to throw in at the last minute, thats all. I didn't see in your comment above that you changed DMKRIO to make that work, if you already did and there's nothing else that might be affected by it, then I redact my comment. :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/s390guy/vm370/issues/12#issuecomment-825143888, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARUFCBJXYF7374N2YMRQBM3TKB5SHANCNFSM4Z6CGAVA .

mgrossmann commented 3 years ago

Bob,

is DMKRIO the place to configure the BSC devices, too?

These are the device id's sysgened in TK4- for rscs.

//* ! 2703 ! 090 - 097 ! 690 - 697 ! leased BSC

Best Mike

BobBolch commented 3 years ago

Mike,

Yes. I'm swamped today, but I will look at it tomorrow. Can you send me the commands I need to start MVS correctly, start one of the lines, as a test, and terminate MVS correctly (not MVSCMCMD LOGOFF :-) /B

On Fri, Apr 23, 2021 at 7:38 AM Mike Großmann @.***> wrote:

Bob,

is DMKRIO the place to configure the BSC devices, too?

These are the device id's sysgened in TK4- for rscs.

//* ! 2703 ! 090 - 097 ! 690 - 697 ! leased BSC

Best Mike

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/s390guy/vm370/issues/12#issuecomment-825598832, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARUFCBMDTC7DC72DM55XTG3TKFL2VANCNFSM4Z6CGAVA .

BobBolch commented 3 years ago

Mike,

I looked at the tk4- Hercules config files, and I do not see any devices at address 90. I was going to copy the tk4- device definition to the vm370ce.conf file.

/B

On Fri, Apr 23, 2021 at 7:38 AM Mike Großmann @.***> wrote:

Bob,

is DMKRIO the place to configure the BSC devices, too?

These are the device id's sysgened in TK4- for rscs.

//* ! 2703 ! 090 - 097 ! 690 - 697 ! leased BSC

Best Mike

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/s390guy/vm370/issues/12#issuecomment-825598832, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARUFCBMDTC7DC72DM55XTG3TKFL2VANCNFSM4Z6CGAVA .

mgrossmann commented 3 years ago

These definitions are only in use, when you install NJE38(RSCS) package. Current TK4- version did not have this software preinstalled.

But the upcoming version will.

Best /M

mgrossmann commented 3 years ago

Mike, Yes. I'm swamped today, but I will look at it tomorrow. Can you send me the commands I need to start MVS correctly, start one of the lines, as a test, and terminate MVS correctly (not MVSCMCMD LOGOFF :-) /B …

I'm not quiet sure, what u are asking for. Please let us discuss this topic via mail.

/MIkeG

BobBolch commented 3 years ago

See the readme-vmce-1_1_1.txt file in the VM370CE.V1.R1.1 directory for details on running the lates MVS TK4- release under VM. The instructions for generating a VM370 CP Nucleus with V=R support are also in that directory.

These updates afe accepted.

mgrossmann commented 3 years ago

Thanks Bob,

a great enhancement!

/MIkeG

wrljet commented 3 years ago

Stupid question: Where is the VM370CE.V1.R1.1 directory?

BobBolch commented 3 years ago

Hey Bill, It's on the verge of being released. We are doing final testing, so it should be one day next week.

Bob Bolch

On Fri, Apr 30, 2021, 11:02 AM Bill Lewis @.***> wrote:

Stupid question: Where is the VM370CE.V1.R1.1 directory?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/s390guy/vm370/issues/12#issuecomment-830156291, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARUFCBJ5EEESAJBWA4KSMDDTLLBBTANCNFSM4Z6CGAVA .

BobBolch commented 3 years ago

Fixed in V1 R1.1