Hi,
We are running VMSERVE, the application server/scheduler on a z/VM CP/CMS
system. Recently, it started giving this error every time we make a progr
am
run through VMSERVE. I am not very experienced in z/VM so any help is
appreciated!
System :
z/VM Version 5 Release 2.0, Service Level
Mike,
Yes, I checked out the message. The thing is, the job runs nightly, and
only fails intermittently. There is no reason to believe that the
authority to access the directory is changing during that time period;
there are only 2 people who regularly grant permissions to that user's
Alan,
The submitter does have NEWRITE permissions. And nothing in that job
erases the file. The job runs only once per day, and the File Type is
the date, such as 20110419.
However, I didn't know that authority to write the file disappeared with
the file if NEWRITE wasn't granted, so I
Kris,
The submitter is ABC, the directory owner is XYZ. The submitter has
WRITE/NEWRITE authority to the directory and files.
Nora Graves
nora.e.gra...@irs.gov
Main IRS, Room 6531
(202) 622-6735
Fax (202) 622-3123
SE:W:CAR:MP:D:KS:BRSI
From: The IBM z/VM
Jim,
I didn't think to look there, I will.
Our regular backups are VMBACKUP, which is scheduled to run 90 minutes
after this job runs. This job runs only 2 minutes maximum, so I know
that isn't the problem. But the SFS console may have some good
indications. I'll see what I can find there.
Jim,
There are basically no messages at all in the console for the SFS
service machine. One of the failures was on April 13. This is the
console for that day--no editing at all of the contents.
HCPMID6001I TIME IS 00:00:00 EDT WEDNESDAY 04/13/11
Amar, we just had this happen on a totally different program. What was
happening was the user had created an EXEC on there A disk that was
identical to the name on another disk. When they run their EXEC, it
basically kept calling itself causing recursion and exceeding available
SVC's
So, look
Look at it's log file and console spool file to see what it
was doing when the error occurred. The message is typical
for an exec that executes something that executes the exec,
as Stephen pointed out.
If you've configured VMSERVE properly it is fairly unusual
for it to suddenly change it's
Nora,
Batch jobs normally run with the privileges of the owner of the job, using
the SECUSER facility in z/VM. With SFS, this can lead to unexpected results
when a prior batch job leaves the worker with a connection to the filepool
under a different user's id. If the job ordering/selection of
Amar,
Could you logon to the service machine running VMSERVE, stop VMSERVE, and
then run the command that was running when you experienced the failure?
If it still fails the same way, you will evidence that VMSERVE is not
causing the problem, and can look elsewhere.
An alternative if you
Isn't that DIAG 88, instead of SECUSER?
Regards,
Richard Schuh
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf
Of John Hall
Sent: Tuesday, April 19, 2011 6:41 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: SFS problem
Nora,
Just to exhaust the possibilities in this line, we have had occasions when a
job would fail for another reason, then be re-submitted by another userid
without the required authority.
On Tue, Apr 19, 2011 at 7:47 AM, Graves Nora E nora.e.gra...@irs.govwrote:
Kris,
The submitter is ABC, the
Hello all ,
I have noticed kernel message Apr 19 12:35:07 hostname kernel: sclp_config:
cpu capability changed on all of our Linux guest on multiple LPARs. Does this
indicate a hardware issue with the IFL processor? I have asked our hardware
support to check for any error on the machine.
It could very well mean a hardware issue. We received this message when
the refrigeration unit in our z10 failed. The microcode scales back the
processor speed. For our healthy z10:
adczlnxsahqa1:/ # cat /sys/devices/system/cpu/cpu0/capability
1760
Well, our hardware support said that IBM was replacing some other failed
component (not IFL) around the time I noticed those errors. The cpu capability
on our z10 match what you reported on your z10.
cat /sys/devices/system/cpu/cpu0/capability
1760
I have asked hardware team to check to see if
What model of CEC? If it's a z10 or a z196, it might be some of the
power-saving features kicking in. That message can also occur if
capacity-on-demand has modified the system capability (although it's usually
rare to see it on a IFL).
From: The IBM z/VM Operating System
It is a 2097-503 z10.
Regards,
Ashwin
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf
Of David Boyes
Sent: Tuesday, April 19, 2011 2:33 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: sclp_config: cpu capability changed.
What model of
The Planning and Administration Guide for z/VM 6.1 mentions dasd that is not
eligible for minidisk cache. Is the 3390 mod 54 minidisk cache eligible?
Thanks in advance.
Brent Litster
Brent Litster
Zions Management Services Company
2185 South 3270 West
West Valley City 84119
(801) 844-5545
I executed this exec :
/**/
VMLINK 5VMDIR40 0491
VMLINK 5VMDIR40 0492
VMLINK 5VMDIR40 011F
VMLINK 5VMDIR40 041F
VMLINK DIRMAINT 01AA
VMLINK DIRMAINT 01FA
VMLINK DIRMAINT 02AA
VMLINK DIRMAINT 0155
VMLINK DIRMAINT 01DF
DMSACC048E Invalid filemode S
Ready(02024); T=0.01/0.01 16:05:35
I received
Does VMLINK with the NONAMES option cause the same behavior? VMLINK user
disk (NON
I'm not sure about in this case, but NAMES files can sometimes create
problems when using VMLINK - so I tend to use NONames
Scott Rohling
On Tue, Apr 19, 2011 at 2:08 PM, Alain Benveniste
Alain,
This looks like the problem described in APAR VM64870. Is VM64870 installed?
-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf
Of Alain Benveniste
Sent: Tuesday, April 19, 2011 2:09 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: EXTERNAL:
Scott
I will test this tomorrow... And back to tell you...
Le 19/04/11 22:16, « Scott Rohling » scott.rohl...@gmail.com a écrit :
Does VMLINK with the NONAMES option cause the same behavior? VMLINK user
disk (NON
I'm not sure about in this case, but NAMES files can sometimes create
I replayed all the process. Just before the racfconv, a verify with racut
200
validated the database integrity. After racfconv, the database is damaged
...
Alain Benveniste
Robert,
I can't confirm this right now, but if this ptf was in the last RSU from
April 2011 for vm540, so... Yes it is applied...
Alain
Le 19/04/11 22:27, « Hodge, Robert L » robert.l.ho...@lmco.com a écrit :
VM64870
VMLINK shouldn't try to access a disk at filemode S, since the access
command doesn't allow you to access anything at filemode S. You may
have found a bug. What level and service level of z/VM are you
running? Maybe you need APAR VM64870 VMLINK INCORRECTLY DETACHES THE
SYSTEM DISK? The
I'd say a call to the support center is in order... RACFCONV should
not damage your database.
On Tue, Apr 19, 2011 at 4:32 PM, Alain Benveniste a.benveni...@free.fr wrote:
I replayed all the process. Just before the racfconv, a verify with racut200
validated the database integrity. After
Hello Listers,
What is the best way/practice to backout a ptf or ptfs that has been
applied and PUT2PROD?
I am about to apply some service (2 ptfs) to CP and can't seem to find
what is best way to restore my environment prior to applying the ptfs. I
would prefer not to restore dasd. It
VM64870 is not on a RSU.
-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf
Of Alain Benvéniste
Sent: Tuesday, April 19, 2011 2:39 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: EXTERNAL: VMLINK behavior
Robert,
I can't confirm this right
Bruce,
I'm near sure I have reconducted the last vmlink provided - this ptf
included - by the IBM support from my VM530 to my VM540 RSU 1003... now I am
with the rsu 1101 applied.
Alain
Le 19/04/11 22:40, « Bruce Hayden » bjhay...@gmail.com a écrit :
VMLINK shouldn't try to access a disk at
Bruce
This ptf was for the case where the 190 was detached by vmlink... In my case
i still have it...
Alain
Le 19/04/11 22:40, « Bruce Hayden » bjhay...@gmail.com a écrit :
VMLINK shouldn't try to access a disk at filemode S, since the access
command doesn't allow you to access anything at
Hi Alain,
Please XEDIT the VMLINK SEXEC S that you have and change:
minidisklist = ''
to
minidisklist = 'S'
and then file it on your A-disk as VMLINK EXEC. Then repeat the failing
scenario. This might patch the problem for you. This is not an official fix
from IBM. I am just trying to help
Thanks, Bill.
However, I don't think my question(s) were answered in that RED alert unless it
describes to me how best to backout ptfs applied. And from reviewing the
alert, I was not able to find that answer. And no, I do not have the PTF
applied that the RED alert indicated.
Thanks for
However, I don't think my question(s) were answered in that RED alert
unless it describes to me how best to backout ptfs applied.
Call the support center is the best answer. Those folks actually understand SES
well enough to tell you how to do it without screwing things up. If you don't
Steve,
CP does not use the 0190 and 0490 disks... those are the CMS system
residence volumes.
When you apply service to CP that goes in the CP nucleus (i.e. into the
CPLOAD MODULE on the MAINT CF1 disk), then you only need to be sure that
you have a backup copy of the CPLOAD MODULE on the CF1
Which begs the question: If you're responsible for
monitoring and resolving such events, why didn't you know
about the schedule for the hardware maintenance?
Les
David Boyes wrote:
Based on your later message about simultaneous hardware maintenance happening around the
same time as the
It probably doesn't make a whole lot of difference here, but
VMLINK is an EXEC and you aren't following the Good
Practices for ordinary Rexx execs:
1-Always code Address Command
2-Specify EXEC or CP as appropriate
3-You got this one right: Quote and uppercase commands to
the underlying system
36 matches
Mail list logo
