Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- H390-Vm
- Messages
Search
|
Re: VMUVM
¿ªÔÆÌåÓýA VM sysprog friend of mine uses this method: he copied his VM disks from track 0 to another disk starting at track 1 using DDR. Then he defines this as a minidisk to his guest VM system starting from track 1. This way the real DASD volser can be anything, and the guest sees the original DASD track 0 as his minidisk track 0, which is actually track 1.So the minidisk has the same volser as the original DASD volume, but the volume that contains that minidisk has its original volser in real track 0. I've never done this myself, but he swears by it. Dennis Stone On 1/17/24 15:48, Mike Stramba wrote:
|
|
Re: VMUVM
Hi Bob, I was just trying to explain the concept. I was not recommending any configuration with duplicate volsers. It's too easy to confuse things.? With Hercules, you can have separate test and production test systems, that never interfere with each other. Less complex and easier to use for development. I do have a special second level VM in my setup, but it is only used to debug CP modifications code by using CP PER running on the first level system.? Best regards/Bob Bolch On Wed, Jan 17, 2024, 3:58?PM Bob Polmanter <wably@...> wrote: Fish and Bob (Bolch), |
|
Re: VMUVM
Fish and Bob (Bolch),
Nothing that you wrote was incorrect, and nothing that I wrote in the original post was incorrect either.? I didn't say that one could not use a copy of the same dasds for second level (whether actual copies or just different shadows), I said I did not recommend it.? The user that asked about this has never brought up a second level VM before.? It is just easier to not have this extra complication of duplicate volsers, making sure the second set of dasd real addresses are higher numerically than first level's dasd address, not having the duplicate volumes automatically come up 'ATTACHED TO SYSTEM', whether to use full-pack MDISK statements or dedicates in the directory, and so on.? VM/370 is not z/VM.??? It's not that it can't be done.? But I wouldn't recommend it for a first-timer. Regards, Bob |
|
Re: VMUVM
Mike Stramba
I did this exercise a couple years ago,? and I used John Yagers zzsa disk editor? utility to change the volser? on a copy of? VmR6. You can get zzssa from the CBT tape site Mike On Tue, Jan 16, 2024, 15:05 Bob Polmanter <wably@...> wrote: Hi Daniel, |
|
Re: VMUVM
Bob Bolch wrote:
When you define two disks with the same volser, in the mannerExactly! The case that gives problems occurs when two VM systems accessPrecisely! Thank you for explaining it so clearly and concisely, Bob. -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@... |
|
Re: VMUVM
When you define two disks with?the same volser, in the manner Fish describes, you are defining two different disks in effect. Neither disk sees any changes made to the?other disk. The case that gives problems occurs when two VM systems access and update the same minitidisk at the same time. Using shadow files, which CP doesn't know about, makes a disk volume appear to be two separate disks. Changes on? one disk have?no effect? on the other. Bob Bolch On Wed, Jan 17, 2024 at 12:28?PM Fish Fish <david.b.trout@...> wrote: Bob Polmanter wrote: |
|
Re: VMUVM
Bob Polmanter wrote:
[...] The hardest part of this is having a second VM system thatNot required. At least not with z/VM anyway. I of course can't speak for VM/CE, as I've never tried it with VM/CE. But z/VM certainly doesn't mind have multiple dasds with the same VOLSER (volume name). It *might* issue some type of "Duplicate volume name(s) detected!" warning, I honestly can't remember (but I think it does), but it's certainly not going to hurt anything, that much I can tell you. So you wouldn't want to try to use two copies of VM/CE, butUnnecessary. Having duplicate volume serials should *not* be a problem. At least not with z/VM anyway. I again cannot speak for VM/CE of course as I've never personally tried it, but I suspect it'll probably behave the same way: simply issue a warning but otherwise not care and keep on chugging along just fine. [...] You actually can use a copy of your existing dasd, but IWhy not. *Technically* that is *exactly* what you ultimately need to do after all. Which can easily be accomplished without doing any type of physical copying whatsoever of course, if you're using shadow files (which I *highly* recommend everyone get into the habit of always using). You need to know exactly what you are doing, what you assignI can't recall whether it forces them offline or not, but I suspect you're probably right. But it's no big deal. You can easily vary them back online again and/or attach them as needed to your second-level guest. and if you get something wrong you could clobber one orWhich is why I recommend using shadow files. As I said, I haven't tried it with VM/CE, but I *have* done it quite successfully with z/VM, and it's really not as hard (difficult) as one might think. Simply define your VM dasd volumes to Hercules with separate/unique shadow file specifications for both your primary (first-level) system and your second-level guest. Here's the way I personally have my current z/VM system defined to Hercules: # Disk Drives 0123 3390 "$(ZVM73DIR)/M01RES.cckd64" sf="$(ZVM73DIR)/M01RES_Shadow_*.cckd64" cu=$(CU) 0124 3390 "$(ZVM73DIR)/VMCOM1.cckd64" sf="$(ZVM73DIR)/VMCOM1_Shadow_*.cckd64" cu=$(CU) 0125 3390 "$(ZVM73DIR)/730RL1.cckd64" sf="$(ZVM73DIR)/730RL1_Shadow_*.cckd64" cu=$(CU) 0126 3390 "$(ZVM73DIR)/M01S01.cckd64" sf="$(ZVM73DIR)/M01S01_Shadow_*.cckd64" cu=$(CU) 0127 3390 "$(ZVM73DIR)/M01P01.cckd64" sf="$(ZVM73DIR)/M01P01_Shadow_*.cckd64" cu=$(CU) 2123 3390 "$(ZVM73DIR)/M01RES.cckd64" sf="$(ZVM73DIR)/M01RES_LEVEL2_Shadow_*.cckd64" cu=$(CU) 2124 3390 "$(ZVM73DIR)/VMCOM1.cckd64" sf="$(ZVM73DIR)/VMCOM1_LEVEL2_Shadow_*.cckd64" cu=$(CU) 2125 3390 "$(ZVM73DIR)/730RL1.cckd64" sf="$(ZVM73DIR)/730RL1_LEVEL2_Shadow_*.cckd64" cu=$(CU) 2126 3390 "$(ZVM73DIR)/M01S01.cckd64" sf="$(ZVM73DIR)/M01S01_LEVEL2_Shadow_*.cckd64" cu=$(CU) 2127 3390 "$(ZVM73DIR)/M01P01.cckd64" sf="$(ZVM73DIR)/M01P01_LEVEL2_Shadow_*.cckd64" cu=$(CU) As you can see there are two sets of dasds being defined, each specifying the exact same base image (which should always be set to read-only(*)), but each with a completely different "sf=" shadow file specification defined. In this way any changes made by your second-level system will *never* interfere with your first-level system, and vice-versa (because they each are, after all, completely separate dasd volumes unique to each other from a hardware point of view.) I will not get into whatever steps might be necessary to configure your second-level VM/CE guest itself, as that is outside the scope of this reply of mine. But I'm sure others here can help you with that. It's really no different than configuring your primary first-level VM system. You'll just be doing it to a different set of physical dasds thanks to the magic of shadow files. Just be sure to use the SECOND set of dasds in your guest's directory entry (i.e. 2123, 2124, etc.), *NOT* your first set!! I myself use a simple EXEC on my CMS guest that attaches 2123, 2124, ... etc. to my VM (and defines a console, etc) before automatically IPLing my second-level system. It's really not that tough when you think about it. <shrug> Hope that helps! (*) Whenever I setup a new Hercules system, the very FIRST step is to *always* preserve the *original* dasd by marking them as read-only. This ensures they can never become corrupted. All updates (writes) always go to the shadow file. If things go wrong, you simply delete the shadow files and try again! Refer to the "The Advantage of Shadow Files" section of Hercules's "Compressed Dasd Emulation" web page: * -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@... |
|
Re: VMUVM
On Tue, Jan 16, 2024 at 15:05 Bob Polmanter <wably@...> wrote: The hardest part of this is having a second VM system that you can use that does not have the same volume names as your first level system. Note that there are several kinds of disks in a VM system. ?"Dedicated" disks are ATTACHed to a virtual machine when it logs on, and are usually identified by their real (to CP) device address.? Other disks are usually ATTACHed to SYSTEM (meaning CP), and are used for either virtual disks or system functions.? The vdisks, page areas, SPOOL data, etc. are all bound to a disk by its volser.? You cannot have two disks with the same volser attached to CP at the same time. The disks you absolutely cannot share are those CP uses itself - paging, SPOOL, etc.? Those are all identified by volser in DMKSYS.? You can share disks that aren't on that list, but you shouldn't let both systems have them R/W.? A CMS filesystem can easily be damaged if two systems (or even two CMS users on the same system) have it online and accessed R/W. Ross Patterson? VMer emeritus? |
|
Re: VMUVM
On Tue, Jan 16, 2024 at 12:02 Daniel L. Srebnick via <dan=[email protected]> wrote: The next exercise I'd like to try is to IPL VM under VM.? I'll surmise that I may need to duplicate some DASD and that some DASD can be shared read only.? Does anyone have a guide, or even a stream of conciousness, that I can follow in the context of a VM/370 CE 1.2 or a Six Pack installation? Since those are both VM/370 systems, you might want to read what we all read and many of us followed in those days: Melinda Varian's famous "What Mother Never Told You About VM Service" ().? Within the SHARE VM Group, it (and occasionally, also Melinda) was simply referred to as "Mother". ? Ross Patterson VMer emeritus? |
|
Re: VMUVM
>?because CP won't like the duplicates and force them offline?
CP doesn't duplicates, that part is true. But, CP doesn't place them offline. If you have duplicate volsers, CP will use the one with the lowest address. "use" that means: the one it will attach to system Or to be more precise: the one that it sees oneline first, usually the lowest address.? Good(?) luck if for some reason the one think to use is offline for some reason, and your VM system? -- Kris Buelens |
|
Re: VMUVM
On Tue, Jan 16, 2024 at 04:24 PM, Daniel L. Srebnick wrote:
It looks like my first step would be to make copies of my first level DASD and then rename the VOLSERs.I think you will need to update all the entries of the directory of the 2nd level VM as well since they are defined in terms of the old VOLSERs. Or am I wrong here? It would be simpler if you had a totally different 2nd level VM/370. I can give you one, with just two packs. It is the system one gets after a simple sysgen from the tapes. It is rather primitive but good enough for the demonstration. Cheers, Rene FERLAND, Montreal |
|
Re: VMUVM
On Tue, Jan 16, 2024 at 06:24 PM, Daniel L. Srebnick wrote:
It looks like my first step would be to make copies of my first level DASD and then rename the VOLSERs.If my memory holds, this is at a really high level, and done via Hercules & the primary VM the primary VM: create empty DASD with dasdinit, attach them to MAINT, use ICKDSF to label, then DDR to copy current volumes to new, empty volumes. ?... Mark S. |
|
Re: VMUVM
My first rule for running VM under VM is that my Production System (first level) NEVER uses the same volsers as the Maintenance System (second level). This takes time to setup, but once it is done, I could always bring in a new maintenance level quickly without interfering with my production work.
toggle quoted message
Show quoted text
/Tom Kern On 1/16/2024 3:05 PM, Bob Polmanter wrote:
Hi Daniel, |
|
Re: VMUVM
Hi Daniel,
Generally, its pretty easy to do and the effort is about the same as it is to get MVS to run under VM.? Basically, you need to: 1. have a second VM system with which to ipl as a guest of the first VM system. 2. make a directory entry in first level VM that describes the second level machine layout (dasd, console, printers, memory size, etc). 3. add the second level VM's dasd entries to Hercules (in conjunction with first-level's dasd) 4. ipl first level.? make sure all of the second level dasds are online and "available" 5. logon to the second level userid,? Assign a console for second level from one of your first level terminals making sure the virtual address is what the second level VM needs.?? Make sure your second level dasd are available to the second level userid (they should show up in a CP Q V DASD command); attach them from first level if necessary.? 6. ipl second level from the second level userid with the CP IPL command. The hardest part of this is having a second VM system that you can use that does not have the same volume names as your first level system.? So you wouldnt want to try to use two copies of VM/CE, but you could use a VM/CE and a VM Sixpack for example if there are no duplicated volume serials.? I changed all of my Sixpack volume serials years ago to be unique from the distribution mainstream so I can't recall now if Sixpack names are duplicated in VM/CE. You actually can use a copy of your existing dasd, but I wouldn't recommend doing it.? You need to know exactly what you are doing, what you assign to what, and what virtual addresses belong to what real device because CP won't like the duplicates and force them offline and if? you get something wrong you could clobber one or both systems. Regards, Bob |
|
VMUVM
The next exercise I'd like to try is to IPL VM under VM.? I'll surmise that I may need to duplicate some DASD and that some DASD can be shared read only.? Does anyone have a guide, or even a stream of conciousness, that I can follow in the context of a VM/370 CE 1.2 or a Six Pack installation?
Thanks in advance. |
|
Re: Purging Class Z Printouts
Just a thought while I am at it...
toggle quoted message
Show quoted text
The "help" command in CMS currently only provides information about the Class G format commands.? While this may have made sense in a typical "real world" mainframe environment where the majority of users were only using those commands, many of us using CE and the like are both "normal" users AND operators/administrators/system programmers for the same system. While I don't expect that anyone wants to take the time to reproduce all of the documentation from the original manuals, it would be nice if for some of the more common operator types of activities there were at least hints about these things added to the help system.? In this case the fact that users with (class D if I am reading this properly?) privileges can add a userid or SYSTEM before the other arguments to purge spool files of another user would seem a small thing to add as a comment somewhere on the page and make things a bit more accessible for users who are still getting oriented to some of these tasks. It looks like you can do the same thing with the ORDER command so a similar comment on that page, for example... On 1/3/24 13:54, Frank D. Engel, Jr. wrote:
That was it! |
|
Re: Purging Class Z Printouts
That was it!
toggle quoted message
Show quoted text
Thank you! pur system p class z 0035 FILES PURGED On 1/3/24 13:18, Dennis Boone wrote:
> When I perform a "q prt" command as MAINT or from the operator |
|
Re: Purging Class Z Printouts
When I perform a "q prt" command as MAINT or from the operator> console I can see a number of spooled print files/jobs that came from > MVS running under VM; for examples: You may need to specify the owning userid (MVS) or SYSTEM on the PURGE command: PURGE SYSTEM P CLASS Z -or- PURGE MVS P CLASS Z De |
Ren¨¦ Ferland
Mark A. Stevens
Thomas Kern
to navigate to use esc to dismiss