Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Profile Log in to check your private messages Log in
 
RACF requesting ICH588A datashare/nodatashare at IPL

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

New User


Joined: 22 Aug 2012
Posts: 30
Location: UK

PostPosted: Thu Aug 02, 2018 10:46 pm    Post subject: RACF requesting ICH588A datashare/nodatashare at IPL
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: 8400
Location: Dubuque, Iowa, USA

PostPosted: Fri Aug 03, 2018 12:45 am    Post subject: Reply to: RACF requesting ICH588A datashare/nodatashare at IPL
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: 30
Location: UK

PostPosted: Fri Aug 03, 2018 2:32 am    Post subject:
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: 30
Location: UK

PostPosted: Fri Aug 03, 2018 2:57 am    Post subject:
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: 30
Location: UK

PostPosted: Sat Aug 04, 2018 9:47 pm    Post subject:
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    IBMMAINFRAMES.com Support Forums -> All Other Mainframe Topics All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts RACF- How to find the Last access of ... rahul shanmuganatan All Other Mainframe Topics 7 Thu Jun 21, 2018 3:19 pm
No new posts RACF - Sub groups - how they work? vasanthz JCL & VSAM 1 Wed Jan 10, 2018 6:44 am
This topic is locked: you cannot edit posts or make replies. Limit access to certain RACF group cvnlynn CLIST & REXX 5 Wed Aug 23, 2017 2:28 am
No new posts find RACF group for access to spooled... jzhardy JCL & VSAM 1 Mon May 08, 2017 11:46 am
No new posts Liberty Angel Server using RACF Keyring martin9 CICS 0 Tue May 02, 2017 5:49 pm

Facebook
Back to Top
 
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us