Align config with MVS TK4-

[g4ugm]

Align config with MVS TK4-

[BobBolch]

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 <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARUFCBJXYF7374N2YMRQBM3TKB5SHANCNFSM4Z6CGAVA> .

[BobBolch]

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

[jgeorge44]

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]

VIRTREAL.MEMO.TXT

VIRTREAL.MEMO.TXT

[BobBolch]

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]

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]

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 <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARUFCBMRLZE3CBZVT2FF6JTTJSH7ZANCNFSM4Z6CGAVA> .

[jgeorge44]

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]

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]

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 <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARUFCBJRO6WFG7HZSC7Z5SLTJV23ZANCNFSM4Z6CGAVA> .

[mgrossmann]

will give it at try :)

[mgrossmann]

It's working great ... thank you

Now, I will IPL MVS :)

[jgeorge44]

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]

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]

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]

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]

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 <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARUFCBNVODWYKESNRXP7RQDTJYT4HANCNFSM4Z6CGAVA> .

[BobBolch]

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 <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARUFCBLLGJY6YQP47N5RFWDTJWSFRANCNFSM4Z6CGAVA> .

[mgrossmann]

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]

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]

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 <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARUFCBN7BAMHCW2LC2UB3YDTJ2XANANCNFSM4Z6CGAVA> .

[mgrossmann]

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]

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 <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARUFCBIWASWJLMKV7M7GSI3TJ253XANCNFSM4Z6CGAVA> .

[mgrossmann]

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]

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

Harold

[s390guy]

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]

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]

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]

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 <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARUFCBMOCLSYWZBA3SQINOLTJ4J7DANCNFSM4Z6CGAVA> .

[jgeorge44]

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]

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 <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARUFCBM63IXIVZ43HQNR4ALTJ4UTTANCNFSM4Z6CGAVA> .

[jgeorge44]

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

[BobBolch]

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 <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARUFCBLMY5OHWSA5XX5TWA3TJ5C6ZANCNFSM4Z6CGAVA> .

[BobBolch]

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]

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]

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 <#12 (comment)>, 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 *********************************************************************** * MVS is a guest operating system and has only dedicated DASD. * * A dedicated 0C1 device is no longer needed as a console! * * LOGON MVS and the logon terminal becomes the MVS console. * *********************************************************************** USER MVS MVS 8M 16M G OPTION ECMODE VIRT=REAL STFIRST IPL 148 CONSOLE 009 3215 SPOOL 00D 2540 PUNCH A SPOOL 00E 1403 A SPOOL 00F 1403 A SPOOL 30E 1403 A * Dedicated Unit Record Devices (MVS READER1 = 10c) * DEDICATE 00C 10C * Dedicated Tape Devices DEDICATE 480 480 * Dedicated DASD DEDICATE 131 131 DEDICATE 132 132 DEDICATE 133 133 DEDICATE 134 134 DEDICATE 135 135 DEDICATE 136 136 DEDICATE 140 140 DEDICATE 148 148 DEDICATE 149 149 DEDICATE 14A 14A DEDICATE 14B 14B DEDICATE 14C 14C DEDICATE 152 152 DEDICATE 160 160 DEDICATE 161 161 DEDICATE 170 170 DEDICATE 180 180 DEDICATE 190 190 DEDICATE 191 191 DEDICATE 240 240 DEDICATE 241 241 DEDICATE 248 248 DEDICATE 270 270 DEDICATE 271 271 DEDICATE 271 271 DEDICATE 280 280 DEDICATE 281 281 DEDICATE 290 290 DEDICATE 291 291 DEDICATE 340 340 DEDICATE 341 341 DEDICATE 342 342 DEDICATE 343 343 DEDICATE 348 348 DEDICATE 349 349 DEDICATE 34A 34A DEDICATE 34B 34B SPECIAL 0C0 3270 SPECIAL 0C1 3270 SPECIAL 0C2 3270 SPECIAL 0C3 3270 SPECIAL 0C4 3270 SPECIAL 0C5 3270 SPECIAL 0C6 3270 SPECIAL 0C7 3270

[jgeorge44]

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]

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 <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARUFCBMF52ULBKK34WEMAY3TKB2SDANCNFSM4Z6CGAVA> .

[jgeorge44]

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. :)

[mgrossmann]

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]

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 <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARUFCBMDTC7DC72DM55XTG3TKFL2VANCNFSM4Z6CGAVA> .

[BobBolch]

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 <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARUFCBMDTC7DC72DM55XTG3TKFL2VANCNFSM4Z6CGAVA> .

[mgrossmann]

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]

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]

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]

Thanks Bob,

a great enhancement!

/MIkeG

[wrljet]

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

[BobBolch]

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 <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARUFCBJ5EEESAJBWA4KSMDDTLLBBTANCNFSM4Z6CGAVA> .

[BobBolch]

Fixed in V1 R1.1