VMUTIL is since ages no longer part of the base VM system; WAKEUP is, but
the execs around it forming VMUTIL are no longer there.
As about the midnight problem: I try to explain the issue in documentation
of RxServer (RxServer can be used to create a functionrich VMUTIL server).
As to close
SAVEFD is not about speed of access to data on the CMS minidisk, it's about
saving real storage:
- without SAVEFD each user accessing a common minidisk has his own copy
of the file directory
- with SAVEFD all users accessing that common minidisk share a common copy.
Since file directory
On Fri, May 7, 2010 at 8:20 AM, Kris Buelens kris.buel...@gmail.com wrote:
As to close consoles: that is best done a bit after midnight: CP's timestamp
for spool files is the time of open, so if one'd close consoles just before
midnight at date d, console files of very active machines will
My guess: you have to force DDR to skip to the data on the tape, so
INPUT 181 TAPE (LEAVE SKIP 1
(so the first tape file is DDR and its control statements, the following
tape files are the data to be restored).
2010/5/6 Brian Nielsen bniel...@sco.idaho.gov
On Thu, 6 May 2010 15:19:00 -0500,
Eginhard has nailed it. I remember the performance boost we got back in
those days. It was truely a difference between a useable and a
non-usable system, and it was all about storage constraints.
Terry
From: The IBM z/VM Operating System
-Original Message-
From: The IBM z/VM Operating System
[mailto:ib...@listserv.uark.edu] On Behalf Of dave
Sent: Thursday, May 06, 2010 3:58 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Windows Enabler Appliance on System z Now Available
Another interesting question would be how
On Fri, 7 May 2010 08:27:45 +0200, Kris Buelens kris.buel...@gmail.com
wrote:
My guess: you have to force DDR to skip to the data on the tape, so
INPUT 181 TAPE (LEAVE SKIP 1
(so the first tape file is DDR and its control statements, the following
tape files are the data to be restored).
VMUTIL is since ages no longer part of the base VM system; WAKEUP is, but the
execs around it forming VMUTIL are no longer there.
Guess that shows how long I've been at this. I've been carefully nursing a copy
of VMUTIL since SP5. 8-)
Maybe I need my brain flushed. I suspect IBM would pay for
Me too
I have been dragging DTR$WAIT and a WAKEUP PARMS file around with me since
the 80's
This is the first shop I have been at that VMUTIL was not already in use
when I got here.
munson
201-418-7588
David Boyes dbo...@sinenomine.net
Sent by: The IBM z/VM Operating System
VM/SP3 for me. I still use the DTR$WAIT to get it started after a
change to the WAKEUP file.
/Fran Hensler at Slippery Rock University of Pennsylvania USA for 47 years
mailto:f...@zvm.sru.edu http://zvm.sru.edu/~fjh +1.724.738.2153
Yes, Virginia, there is a Slippery Rock
I should have mentioned that VMUTIL was not part of VM/Sp but was
included in an licensed add-on package called (I think) ISPF.
Since I stole it from that package I guess I'm illegally running it.
/Fran
On Fri, 7 May 2010
Wasn't it CMS Utilities Feature (CUF)?
I guess I am spoiled. KWAKEUP has been available everywhere I have worked since
my Amdahl days. I have never used WAKEUP. In addition to setting variables for
the trigger event, KWAKEUP does not have the problem crossing midnight that is
in WAKEUP.
I should have mentioned that VMUTIL was not part of VM/Sp but was
included in an licensed add-on package called (I think) ISPF.
VM/IPF, later CMS Utilities.
this is from the Wakeup Parms file
* *
* THIS IS THE DEFAULT 'WAKEUP PARMS' FILE THAT IS SUPPLIED WITH *
* THE VM/370 IPO/E SYSTEM FOR THE VIRTUAL
-Original Message-
From: The IBM z/VM Operating System
[mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes
Sent: 07 May 2010 15:39
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Windows Enabler Appliance on System z Now Available
I guess I'm more frighten by M$ lawyers than
Can I just add one caveat. One of the types of licence Microsoft
provides is
an OEM licence. In the case of a desktop OS an OEM licence is NOT
TRANSFERABLE and dies with the hardware its installed on.
Yes.
You're responsible for supplying a legitimate Windows license for the appliance
Occasionally our DASD chooses to issue service messages (SIM) to tell us
about incidents that have occurred within the DASD subsystem. On z/OS, we
get IEA480E messages. On z/VM, we'd expect to receive HCP403I, but we've
not been able to find them. We'd assume they'd be going to OPERATOR but
1) What z/VM release and maintenance level?
2) Are you running PROP or some other PRO-like program (e.g CA's
VM:Operator, or IBM's z/VM Operations manager for z/VM) to filter some or
all HCP messages?
We've received occasional HCPERP403I messages on z/VM 5.4 and z/VM 5.1
(upgraded to z/VM 5.4
We think we may have found the cause. It seems that one of our DASD
subsystems is producing the message, but the other is not. So our storage
lackey is checking with EMC as he seems to recall that there's a setting
that needs to be enabled.
Thanks much,
Leland
On Fri, May 7, 2010 at 3:54 PM,
1) z/VM 6.1 0901
2) Operations Manager, but not filtering CP messages. And we didn't
receive the HCP messages on 5.4 either (that I know of) and we weren't
running OpsMgr at the time.
In case it matters, this is EMC DASD that we're dealing with.
At least in one case, we do see an occurrence
If it helps, we use EMC DASD, too.
I think you're right about it being an EMC problem. Sic 'em! :-)
Mike Walter
Hewitt Associates
(Sent from the wee keyboard of a Blackberry.)
- Original Message -
From: Leland Lucius [llluc...@gmail.com]
Sent: 05/07/2010 03:59 PM EST
To:
On Friday, 05/07/2010 at 07:34 EST, Leland Lucius llluc...@gmail.com
wrote:
At least in one case, we do see an occurrence in EREP, but that's not as
handy
as the HCP403I message would be.
I think that means that the SIM contained a (type,severity) combination
that CP doesn't recognize.
22 matches
Mail list logo
