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
This group is for all folks running the original IBM VM/370 Release 6 operating system (or later (e.g. VMTCE (Community Edition)) on Hercules. Like the other early IBM operating systems this version has always been in the public domain and so can be freely distributed. The base version as supplied by IBM is lacking in many facilities. IBM solved this by providing additional extension products which were licensed and so are not available. There are however many user enhancements available which can be installed. In addition, in order to get users up and running quickly updated "releases" of VM/370 included the most popular updates are available for download, so novices can start to learn VM without having to delve into the system internals. It is intended that this wiki will provide information on the base release and these updates.
The available versions are here :-
?
?
|
Re: VM Guest Printing
Daniel,
?
You have to issue the CP CLOSE PRT from the virtual machine console (first level) userid that is hosting the 2nd level VM system.
?
At that point, if your first level system printers are stopped (e.g., device 00e or 00f) then you should see the output in a CP Q PRT ALL command, sitting in the first level spool.? If the printers are started then you will see a message on the first level operator console that the output is bring printed and it should be available in your disk file.
?
Regards,
Bob
? |
|
Re: VM Guest Printing
Daniel,
?
How is your printer defined in the directory of the first level machine hosting the second level system?? It's been a long (really long) time, but I vaguely recall that you had to define the printer (Device 00E) on the first level machine correctly, or possibly couple the printer on the hosting first level VM to another device on a first level VM (RSCS comes to mind).?? The basic gist of it is that the system printer at the second level is DEV 00E at the first level, and that you have to track it down from there.
?
I wish I had a working example to look at..... sigh..... I know I've done it once or twice.? Those were the days!
?
Jim |
|
Re: VM Guest Printing
I understand what you're saying, but...
?
The output appears on the second level CP for a moment and then is gone:
?
18:51:41 PRT ?00E OUTPUT OF DAN ? ? ?FILE ?= 0020 RECDS= 000005 COPY= 01 ?A PRT
Q PRT 18:51:56? 18:51:56 NO PRT FILES ?
If I issue a CP CLOSE PRT it does nothing because the output seems to be going into the ether...shouldn't the files show up via a
Q PRT until I issue the CLOSE? |
|
Re: VM Guest Printing
On Wed, Oct 23, 2024 at 19:03 Daniel L. Srebnick via <dan=[email protected]> wrote:
If the second-level CP is still logged on, and you haven't done a #CP CLOSE PRT from its virtual console, then the first-level SPOOL file is still open, and won't appear in the PRT queue yet. Folks that used to run second-level systems with virtual printers often had a?second-level OS mod to do a CLOSE vdev-addr via DIAG 8 after printing their SPOOL's files.? But VM/370 R6 CP doesn't do that by default. Ross |
|
Re: Let's Talk About RSCS
On Mon, Oct 21, 2024 at 11:11 AM, Daniel L. Srebnick wrote:
I'm still testing, but am posting my results here in case anyone else wants to try. Yes, I tried it and it works for me too. Thank you so much for finding this, I wanted that RJE connection to work for so long. :-)
?
Cheers,
?
Rene FERLAND, Montreal |
|
Re: VM Guest Printing
Therein lies the mystery. My first level printer IS started and nothing is in the queue, nor is it being written to the associated file. On Wed, 2024-10-23 at 19:00 -0400, Ross Patterson wrote:
|
|
Re: VM Guest Printing
On Wed, Oct 23, 2024 at 17:21 Daniel L. Srebnick via <dan=[email protected]> wrote:
Your second-level user wrote a file to its virtual printer.? The second-level CP created a second-level SPOOL file to collect and store that print data.? When the file was closed, the second-level CP wrote the SPOOL file's contents to a printer.? That printer is actually a first-level virtual printer, so the first-level CP created a?first-level?SPOOL file to collect and store the print data that the second-level CP wrote.? If your?first-level?CP doesn't have a STARTed printer accepting print files, it will just sit in the first-level SPOOL until you #CP START one. A first-level Q PRT should show this. Ross |
|
VM Guest Printing
I have a VM system and a VM under VM guest system.? My printer output from a user under the guest system is vanishing.
?
In Hercules, I have 00e output going to a file.?? The CP directory entry for the VM guest includes:
?
USER VMTEST PPPPP 8M 16M G ? ? ? ? ? ? ? ? ? ?
?OPTION ECMODE REALTIMER BMX VIRT=REAL STFIRST
?IPL 6A1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?CONSOLE 009 3215 ? ? ? ? ? ? ? ? ? ? ? ? ? ??
?SPOOL 00E 1403 A ? ? ? ? ? ? ? ? ? ? ? ? ? ??
?SPOOL 00C 2540 READ * ? ? ? ? ? ? ? ? ? ? ? ?
?SPOOL 00D 2540 PUNCH A
?
Suppose I dial my guest system and logon as a user.? I can print a file and I see it show up on the operator console of the VM guest:
?
16:13:46 PRT ?00E OUTPUT OF DAN ? ? ?FILE ?= 0027 RECDS= 000005 COPY= 01 ?A PRT
?
After seeing the message, a Q PRT by the Operator shows no files.
?
There is also no output added to my redirected listing file.? I do know that this works from the top level VM.
?
I must be missing something, but it is surely not obvious to me.? Please enlighten me.
?
Thanks.? ? ? ? ? ? ? ? ? ??
|
|
Re: Losing virt-real setup upon rebuilding the nucleus...can't it be prevented?
On Wed 23 Oct 2024 at 02:10:56 -0700, Herman Hartman wrote:
But piece by piece my recollection comes up with a second level that would be a similar nucleus/VMsystem? as it was on first level; but now updated with the latest ptf's or PUT. In order to validate the correct working the DMKRIO would be similar, so no DMKRIO2 as in William's case, and on second level the DASD that are less relevant for validation would be small unused minidisks.In some sort of "ideal case", I can imagine that you first create a new nucleus and install and run it in a VM. Then when all is ok, you re-IPL the real machine from the same already installed disk. I guess that this requires that the testing VM is configured very very similar to the real machine, otherwise it would not work. Maybe this would get conflicts of VOLSERs between virtual and real disks? I didn't think it through far enough to know if this can be avoided. -Olaf. -- ___ Olaf 'Rhialto' Seibert <rhialto/at/falu.nl> \X/ There is no AI. There is just someone else's work. --I. Rose |
|
Re: Losing virt-real setup upon rebuilding the nucleus...can't it be prevented?
Frank, you're right; to narrow it down, this was about mapping of minidisks that contained code used in the nucleus building, or at least that's what I remember. Of course we wouldn't want to interfere with production, that was the whole idea of the safe environment of a second level VM.
?
But piece by piece my recollection comes up with a second level that would be a similar nucleus/VMsystem? as it was on first level; but now updated with the latest ptf's or PUT. In order to validate the correct working the DMKRIO would be similar, so no DMKRIO2 as in William's case, and on second level the DASD that are less relevant for validation would be small unused minidisks.
?
Good to have your punctual remarks, which stir up more and hopefully more accurate memories. Although, maybe I should wait until the recollection is complete; scratch the 'maybe' ;-(
?
But a more innocent recollection is: the second level system used to be quite slow; wrt the indicator text in the 3270 right hand corner a colleague suggested we change the 'RUNNING' text into 'WALKING'.
?
KR, Herman |
|
Re: Losing virt-real setup upon rebuilding the nucleus...can't it be prevented?
¿ªÔÆÌåÓýProbably showing my own ignorance here, but couldn't the minidisks be defined at the 1st level and mapped in the 2nd level's DIRECT using DEDICATE? I'd imagine that would be problematic with a large number of users but for something like this you probably wouldn't need that many... Even if you only did this with a subset of them you could use that subset for transfer?
On 10/23/24 03:37, Herman Hartman
wrote:
|
|
Re: Losing virt-real setup upon rebuilding the nucleus...can't it be prevented?
Great to hear about this tip again, William.
In 1986 I used it in some form of exercise, and the following years as a travelling systems programmer I never went without it in my clients' installations.
The exact actions I forgot, thanks for sharing your tips.
I seem to remember there was also a trick to map the relevant 2nd level mini disks to 1st level mini disks in the respective USER DIRECT's, in order to push software down and to more conventiently go into production afterwards; would this mapping also be possible on Hercules?
KR, Herman |
|
Re: Losing virt-real setup upon rebuilding the nucleus...can't it be prevented?
One other small old timer tip regarding the CP nucleus..
?
You will definitely want to create a new Class-G user (I call mine CPCP) for running a 2nd-level CP.. Never load an untested nucleus to your main system. There are some exceptions but, for those, you will want to use some sort of "alternate nucleus" strategy so you can always just re-ipl to get back to a working nucleus.
?
You will want to create the following files:
Then make a copy CPLOAD EXEC. I call mine CPLOAD2 EXEC. You should edit this to use the 2nd-level files. (e.g. c/DMKSYS/DMKSYS2/* * same for RIO & SNT)
?
Then you create the 2nd-level nucleus load deck with:
?
SP PUN CPCP CL N
VMFLOAD CPLOAD2 DMKLCL
?
then from CPCP:
?
SP RDR CL N
SP PRT * CL M
IPL 00C CLEAR
. . .
SP PRT CLOSE NA CPCPNUC LOADMAP
?
cheers, WIlliam
?
? |
|
Re: Losing virt-real setup upon rebuilding the nucleus...can't it be prevented?
¿ªÔÆÌåÓýYou should not need to rerun VRSIZE every time you rebuild the
nucleus. On 10/21/24 11:31, Alejandro olivan
Alvarez wrote:
|
|
I also receive the same message upon ee exit. Is there a fix for this? Sorry if I missed the solution to this.
?
Mike
?
** freeMem: ignored attempt to free NULL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
Memory overwrite detected by __DMSFRT at E8DBA0. ? ? ? ? ? ? ? ? ? ? ? ??
DLMALLOC PANIC LINE 3540 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
ABNORMAL TERMINATION (NO RESOURCE CLEANUP) ERRNO 430 DLMalloc aborted. ??
Ready(00012); T=0.21/0.33 08:40:50
|
|
Re: Let's Talk About RSCS
Here's an update.? After extensive testing and numerous suggestions from others in the community, I think I have found an answer.
?
On the VM/RSCS side, you need to start the line with a buffer size of 606.
?
START NODEA PARM H02 B606
?
Using this configuration I am able to cleanly punch jobs from a VM user, via RSCS, to JES2.? Unless I route the output otherwise, it comes back to the RSCS virtual machine, which prints the output on VM's PRT1.
?
I'm still testing, but am posting my results here in case anyone else wants to try. |
|
Re: Losing virt-real setup upon rebuilding the nucleus...can't it be prevented?
Aha ... that makes sense!
?
So... Would that mean that, whenever I run VMFLOAD VRLOAD DMKLCL , there should no longer need to re-run VRSIZE, as long as I moved the resulting DMKSLC TEXT A filo onto the LoCaL modifications 594/E minidisk, isn't it?
?
Thank you very much for your reply, it was very helpful to further understand what's going on!
?
Cheers
--
Alejandro Olivan. Spain. |
|
Re: Losing virt-real setup upon rebuilding the nucleus...can't it be prevented?
So... here's the deal
?
VMFLOAD is an EXEC that creates a "nucleus load deck". It takes its input from another EXEC that is a list of files to be concatenated into a single "punch" file. .
?
The thing that makes VMFLOAD create a "nucleus load deck" is that the first file listed in its "load list" EXEC is "DMKLD00E LOADER".. This is an IPLable program that loads and links the other object files in the "load list" into memory and then transfers control to the entry point names on an LDT card at the end of the 'load list'. This same process is used to create a CP nucleus and a CMS nucleus... just different "load lists".
?
Specifically for the V=R situation, you must invoke VMFLOAD with the VRLOAD EXEC load list (or some derivative). The only difference between this load list and the standard CPLOAD EXEC load list is that VRLOAD includes an additional entry for "DMKSLC". This file (DMLSLC TEXT) contains a "SLC" loader control that moves the location counter so to create the V=R "hole" in the loadable CP nucleus.
?
The VRSIZE utility program is what creates the DMKSLC TEXT file references in the VRLOAD load list.
?
As far as the CPLOAD MAP and VRNUC MAP, those are manually created from the nucleus load process...
?
For lots more info, check out this source:
?
cheers, William
? |
|
Re: Losing virt-real setup upon rebuilding the nucleus...can't it be prevented?
Hi, thank you for your help.
?
The fun thing is that, while I got it to work by switching from what I learn from documents to do:
?
VMFLOAD VRLOAD DMKHRC
?
to
?
VMFLOAD VRLOAD DMKLCL
?
by applying the 'LCL vs HRC' logic ... after reading your point, quite a bunch of questions came to my mind! :-)
?
So... is VRLOAD a kind of 'variant' of CPLOAD but just for 'virt-real' enabled CP?
Does it require a run of VRESIZE command anytime I rebuild the nucleus, for something non-VR realated? (DMKRIO, DMKSYS, DMKBOX...) anyways??
And what about VRNUC MAP? ... does it 'replace' CPLOAD MAP? I mean, can I simply erase CPLOAD MAP and keep VRNUC MAP at minidisk E?
?
Thank you.
Cheers.
?
--
Alejandro Olivan. Spain. |
|
Re: Losing virt-real setup upon rebuilding the nucleus...can't it be prevented?
¿ªÔÆÌåÓýwhen rebuilding the nucleus replace this: ?? vmfload cpload dmklcl
with this to maintain v=r: ?? vmfload vrload dmklcl
On 10/15/24 08:19, Alejandro olivan
Alvarez wrote:
|
Ren¨¦ Ferland
to navigate to use esc to dismiss