IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

RACF requesting ICH588A datashare/nodatashare at IPL


IBM Mainframe Forums -> All Other Mainframe Topics
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Alan Playford

New User


Joined: 22 Aug 2012
Posts: 48
Location: UK

PostPosted: Thu Aug 02, 2018 10:46 pm
Reply with quote

Cloned a system from (say) LP01 to a new LPAR LP02. both are LOCAL mode (i.e. non-SYSPLEXed).
This was achieved in the normal fashion by volume copies, dataset copies, the usual renames, manual editing etc.

RACF ICHRDSNT reflects correct RACF database names in each LPAR (in USER.LINKLIB).

LP01 IPL's straight through - no action message for RACF displayed.
LP02 IPL's OK but displays:
*ICH588A CONTINUED USE OF DATABASE
SYS1.LP02.RACFDS ON VOLUME Z2SCAT
CAN RESULT IN DATABASE CORRUPTION AND SYSTEM OUTAGE.
IF ANY SYSTEM IS USING THE DATABASE IN DATA SHARING MODE, AND ANY
OTHER SYSTEM CONCURRENTLY USES IT IN NON-DATA SHARING MODE,
DATABASE CORRUPTION WILL RESULT.
YOU ARE INITIALIZING INTO DATA SHARING MODE. PROFILE
IRRPLEX_ADCDPL , IN CLASS GXFACILI INDICATES NON-DATA SHARING MODE.
IF THE DATABASE IS NOT BEING USED BY SYSTEMS OUTSIDE OF THIS
SYSPLEX, AND IS NOT BEING USED BY SYSTEMS IN THIS SYSPLEX IN NON-DATA
SHARING MODE, THEN SPECIFY 'CONTINUE'. OTHERWISE SPECIFY 'NODATASHARE'
AND THE SYSTEM WILL INITIALIZE IN NON-DATA SHARING MODE.
*01 ICH600A VALID RESPONSES ARE 'CONTINUE' OR 'NODATASHARE'

Normally reply NODATASHARE but I understand CONTINUE would probably also be OK in the case of two LOCAL LPARs?

On both systems, I have the same classes defined under RACF -
resource class is GXFACILI
profile names IRRPLEX_ADCDPL and IRRPLEX_LOCAL with same characteristics.

To confirm that, command "SR CLASS(GXFACILI) shows
IRRPLEX_ADCDPL
IRRPLEX_LOCAL
on both systems

Now, I found on Google that RACF "self-protects" itself when the database(s) are copied in such a cloning situation.

But what can I do top safely stop the message appearing at IPL whilst bringing both LPAR's RACFs up in NONDATASHARING modes?
Ideally, of course, I would just like the IRRPLEX_LOCAL to be used.
Obviously the IRRPLEX_ADCDPL comes from an earlier time of ADCDs when the system was originally built some years ago.
But can I just delete IRRPLEX_ADCDPL leaving IRRPLEX_LOCAL on both systems?
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Fri Aug 03, 2018 12:45 am
Reply with quote

The manual explanation for ICH588A has a set of steps to take when this message appears. Have you tried the D XCF,SYSPLEX and D XCF,GROUP,IRRXCF00 commands mentioned in the manual?
Back to top
View user's profile Send private message
Alan Playford

New User


Joined: 22 Aug 2012
Posts: 48
Location: UK

PostPosted: Fri Aug 03, 2018 2:32 am
Reply with quote

Robert,
Thanks for replying.

Yes, tried those, and get
on LP01:
Code:
D XCF,SYSPLEX
IXC336I  21.46.33  DISPLAY XCF 732
SYSPLEX LOCAL
SYSTEM   TYPE SERIAL LPAR STATUS TIME         SYSTEM STATUS
LP01     3907 58A7   01   08/02/2018 21:46:32 MONOPLEX MODE  TM=SIMETR

SYSTEM STATUS DETECTION PARTITIONING PROTOCOL CONNECTION EXCEPTIONS:
  PROTOCOL NOT APPLICABLE IN MONOPLEX MODE

SYSPLEX INITIALIZATION TIME: 07/28/2018 19:59:44.683401               

and

Code:
D XCF,GROUP,IRRXCF00
IXC340I  21.47.50  DISPLAY XCF 734
   GROUP 'IRRXCF00' IS NOT DEFINED TO THIS SYSPLEX   


Which is maybe what you'd expect in a LOCAL/Monoplex mode?

On LP02 LPAR (the one with the IPL message) you get:
Code:
D XCF,SYSPLEX
IXC336I  21.51.20  DISPLAY XCF 123
SYSPLEX LOCAL
SYSTEM   TYPE SERIAL LPAR STATUS TIME         SYSTEM STATUS
LP02    3907 58A7   02   08/02/2018 21:51:20 MONOPLEX MODE  TM=SIMETR

SYSTEM STATUS DETECTION PARTITIONING PROTOCOL CONNECTION EXCEPTIONS:
  PROTOCOL NOT APPLICABLE IN MONOPLEX MODE

SYSPLEX INITIALIZATION TIME: 08/02/2018 12:08:36.669230


and

Code:
D XCF,GROUP,IRRXCF00
IXC332I  21.49.24  DISPLAY XCF 121
 GROUP IRRXCF00:    LP02

which is slightly different?
And I'm unsure what that is telling me, or how to resolve it?
Back to top
View user's profile Send private message
Alan Playford

New User


Joined: 22 Aug 2012
Posts: 48
Location: UK

PostPosted: Fri Aug 03, 2018 2:57 am
Reply with quote

further interesting (?) information:
On LP01, RVARY LIST shows:
Code:
ICH15013I RACF DATABASE STATUS:
ACTIVE USE  NUM VOLUME   DATASET
------ ---  --- ------   -------
 YES   PRIM   1 Z22CAT   SYS1.RACF
 YES   BACK   1 Z22CAT   SYS1.RACFSEC
ICH15020I RVARY COMMAND HAS FINISHED PROCESSING.

on LP02, RVARY LIST shows:
Code:
ICH15013I RACF DATABASE STATUS:
ACTIVE USE  NUM VOLUME   DATASET
------ ---  --- ------   -------
 YES   PRIM   1 Z2SCAT   SYS1.LP02.RACFDS
 YES   BACK   1 Z2SUSS   SYS1.LP02.RACFDS.BACKUP
MEMBER LP02     IS SYSPLEX COMMUNICATIONS ENABLED & IN NON-DATA SHARING MODE.
ICH15020I RVARY COMMAND HAS FINISHED PROCESSING.

Note the extra line for LP02! But why? Where should I look?!
Coded for you - do it yourself next time
Back to top
View user's profile Send private message
Alan Playford

New User


Joined: 22 Aug 2012
Posts: 48
Location: UK

PostPosted: Sat Aug 04, 2018 9:47 pm
Reply with quote

Think I’ve solved this minor problem?

All hinges on the ICHRDSNT (RACF resident tables) module that is compiled to primarily state the RACF database names?
(Unless you have zOS v2.3 in which case you can take advantage of the new IRRPRMxx PARMLIB member)

When I setup LP02, I recompiled this module as follows:
ICHRDSNT CSECT
DC AL1(1) one RACF database
DC CL44'SYS1.LP02.RACFDS' primary RACF db
DC CL44'SYS1.LP02.RACFDS.BACKUP' backup RACF db
DC AL1(255) number of resident data blocks
DC X'8C' updates duplicates on backup db
END
/*
//* Note the last flag byte!
//* Description of flag byte bits...
//* x'1... ....' - duplicate updates to backup
//* x'.1.. ....' - duplicate statistical updates to backup
//* x'..x. ....' - reserved
//* x'...x ....' - reserved
//* x'.... 1...' - enable for sysplex communications
//* x'.... .1..' - default mode
//* 0 = non data sharing
//* 1 = data sharing
//* x'.... ..x.' - reserved
//* x'.... ...x' - reserved
//*

The X’8C’ is the important bit here?
Says “allow for SYSPLEX operations (if applicable)” and also - more importantly - "set data sharing on as default”.

I’ve recompiled this to remove the sysplex ability (we are running Local/Monoplex) and data sharing facility to use X’80’ instead, so next IPL of LP02 shouldn’t ask the question!
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> All Other Mainframe Topics

 


Similar Topics
Topic Forum Replies
No new posts RACF - Rebuild SETROPTS command which... All Other Mainframe Topics 3
No new posts RACF cost vs. ACF2 cost IBM Tools 2
No new posts CICS Access to RACF CICS 2
No new posts CICS RACF & DB2CONN CICS 2
No new posts RACF as API Endpoint All Other Mainframe Topics 5
Search our Forums:

Back to Top