In one of our sysplex's we have all Top Secret LPARs except one RACF LPAR.
We can route commands to all LPARs except the one RACF LPAR. This LPAR
receives the following messages.
ro *all,d a,l
*ICH409I 283-054 ABEND DURING FRACINT PROCESSING
IE480I D
WOW!! That doc APAR is 10 years old. I would have thought that this would
no longer be an issue by now. Especially with IBM's push to large sysplex
environments for software cost reductions, but I'll take that up with our IBM
representative. All LPARs in our sysplex execute from a copy of a
Yes, but this only points out the issue. I would like to see a document that
says mixed security environments in a sysplex is not recommended or
supported.
OK, here is a recap. Commands routed to all LPARS will work if they are issued
from the RACF LPAR. The command will fail (only on the
So why can I route a command from one RACF LPAR to another RACF LPAR (in
the same sysplex with different RACF databases) when my userid is not
defined to the target RACF LPAR? RACF on the target LPAR does not contain
a userid that matches the userid on the first RACF LPAR. What kind of
After a maintenance upgrade this past weekend, a specific user is getting
allocation error messages when using Endevor. I think SMS is having issues,
but I can't find the return codes in any manual. The messages are;
C1A0010E ALLOCATION ERROR RC=9700-0402, DDNAME=
C1A0011E IKJ56894I DATA
Yes, every thing is in increments of 4 (0400, 0404, 0408, etc.). I can not
find
a 0402 code.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN
Allocation is going to DASD. There is no VIO on this system. There are 2
products that could be in play here, DFSMS and STOP-X37. I'm getting ready
to set a slip trap to see if I can narrow it down.
--
For IBM-MAIN subscribe
I found the problem. It is with a software product called Performance
Essentials. It is a VSAM optimizer. It had an issue when writing the status
record to the PAGE dataset. The vendor had a fix (PSP30420). It was applied
and now it works. I discovered this when I could create a valid
Thanks for all of the good discussions. What I am reading here is that the
only need to size the PLPA and COMMON is to save DASD space. If you have
the DASD space, then just allocate a 2GB (combined PLPA and COMMON) page
datasets and be done with it, until 64 bit addressing arrives.
One
So, the PLPA pages residing in the COMMON page dataset (from overflow
condition) will have the page protection bit on also as if they were residing
in
the PLPA page dataset?
--
For IBM-MAIN subscribe / signoff / archive access
I'm changing the paging volumes and dataset names on out tech (z/OS 1.8)
lpar. When I try to IPL, I get an IEA924D message. The text says, iea924d
volume mbgpg1 needed for page data set was not mounted; new plpa data
set may be requested; reply 'go' or 'ignore'. I can't find what is wrong.
I created a SSA on a driving system, then created the PAGE datasets. I think
I found my issue. I used IDCAMS to ALTER the cluster names, but not the
components. I will try another IPL tomorrow and report back.
--
For
I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it
overflow into the COMMON page dataset. Is there any issues with allocating
a huge COMMON page dataset? For example, if my LPAR only requires a
combined PLPA and COMMON size of 800 cylinders, can I used an entire
13 matches
Mail list logo
