Comments (49)
from vm370.
We should include information on how to generate a V=R CP Nucleus for TK4.
Bob Bolch
from vm370.
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.
from vm370.
from vm370.
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
from vm370.
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.
from vm370.
from vm370.
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. :)
from vm370.
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
from vm370.
from vm370.
will give it at try :)
from vm370.
It's working great ... thank you
Now, I will IPL MVS :)
from vm370.
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
from vm370.
from vm370.
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.
from vm370.
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. :-)
from vm370.
from vm370.
from vm370.
from vm370.
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
from vm370.
from vm370.
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
from vm370.
from vm370.
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
from vm370.
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
from vm370.
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
from vm370.
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
from vm370.
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.
from vm370.
from vm370.
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)
from vm370.
from vm370.
I don't think I've seen that before. If you can give me an example, I'll work that up.
from vm370.
from vm370.
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.
- Does anyone disagreee with that location.
- 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
from vm370.
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.
from vm370.
from vm370.
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.
from vm370.
from vm370.
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. :)
from vm370.
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
from vm370.
from vm370.
from vm370.
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
from vm370.
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
from vm370.
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.
from vm370.
Thanks Bob,
a great enhancement!
/MIkeG
from vm370.
Stupid question: Where is the VM370CE.V1.R1.1 directory?
from vm370.
from vm370.
Fixed in V1 R1.1
from vm370.
Related Issues (20)
- CP TERM HILIGHT ON causes first & last row screen corruption on 3270 model 4 (43 line) screen
- Document WAKEUP server
- tried snobol4 exec; no luck yet HOT 10
- OPCODES MACLIB in a future VM/370CE HOT 2
- Basic Compiler error messages missing
- EXECIO DISKW: DMSFRE160T INVALID DMSFREE CALL FROM 021240. HOT 6
- BREXX DO loop counting weirdness HOT 16
- DCSSFLAG mis-interpreted ss NUCMFLAG
- BREXX DO loop counting resets to 0 HOT 1
- error in readme-dosvs.txt
- RECEIVE refuses to read in a file that does not exist on the target disk, but that exists on a read-only extension of it.
- EXECIO DISKW treats empty VAR as EOF on input and doesn't write it. HOT 1
- NUCEXT and SUBCOM macros require NAME= on MF=L form HOT 1
- NUCEXT and SUBCOM macros do not set function name with MF=(E,...) HOT 1
- NUCEXT RENAME plist is processed incorrectly, uses wrong newname HOT 1
- ZAP command reports DMS210E on files dated 20xx. HOT 1
- NUCEXT macro with SET, ORIGIN= and MF=(E,...) builds plist incorrectly, causing random storage overlays. HOT 1
- COBOL.HELPCMD.D1 refers to wrong TXTLIB
- no help file for TAPEMAC
- No help file exists for TAPEPDS command HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vm370.