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: VM Guest Printing
Dan,
?
From the first level's operator's console, you'd be closing the operator's virtual printer.? To close the VM hosting the second level machine from the operator's console, you'd have to "send" the command to it:
?
CP SEND LEVEL2VM #CP CLOSE PRT
?
I still have a some VM/SP Rel 5 manuals, so I checked, and there doesn't appear to be a Class D version of the CLOSE command, where you could specify userid and device.
?
Gosh, am I rusty.....
?
Jim |
|
Re: VM Guest Printing
OK folks, I solved it! I was doing the CP CLOSE PRT from the 1st level operator console. ?That did not work but when I tried it from the 2nd level operator console as #CP CLOSE PRT, that did it. I wonder why it won't work from the 1st level console as Bob indicated it should? And thank you for LINED character change suggestion for the 2nd level operator. ?I implemented that. To say that I generally know what I'm doing, I think it more accurate to say I'm generally learning what I forgot and what I never knew. Thanks. On Thu, 2024-10-24 at 10:13 -0400, Jeff Henry wrote:
|
|
Re: VM Guest Printing
I used to do it the other way around. I'd change the guest machine's first-level LINEND character to something other than #. That way, when I habitually typed #CP something on the 2nd level machine, I wouldn't accidentally do something to the (production) first-level system. Oh, and on a related note - don't give the guest machine anything other than class G in the first-level directory. On Thu, Oct 24, 2024 at 9:41?AM Ross Patterson via <ross.patterson=[email protected]> wrote:
-- Jeff Henry |
|
Re: VM Guest Printing
On Thu, Oct 24, 2024 at 09:08 Daniel L. Srebnick via <dan=[email protected]> wrote:
Sure, that'll work fine. You sound like you generally know what you're doing on VM, so I hesitate to ask, but have you changed the LINEND character on your second-level CP's OPERATOR user?? One of the big gotchas running CP in a VM is which CP gets the command when you type #CP at the virtual console.? Old timers like me used to put something like TERM LINEND $ in the second-level OPERATOR's PROFILE EXEC, so #CP whatever went to first-level and $CP whatever went to?second-level. Ross |
|
Re: VM Guest Printing
Hi Bob: That did not work either. ?The spooled file is there at level 2 as long as the printer is drained. ?Starting it and the output vanishes. So I tried something else. ?I attached 00F to the 2nd level VM and now printing works flawlessly with no extra steps or closes. On Thu, 2024-10-24 at 05:47 -0700, Bob Polmanter wrote:
|
|
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
|
Ren¨¦ Ferland
to navigate to use esc to dismiss