Why is NW0020U Userspace getting corrupted and how is it fixed?

  • 7017013
  • 20-Nov-2015
  • 05-Jun-2019

Environment

NetIQ Security Solutions for iSeries 8.1
Remote Request Management

Situation

What is NW0020U Userspace?
Why is NW0020U saying that it is getting corrupted?
How to fix NW0020U when it is corrupted.
Error messages saying that NW0020U is corrupted.

Resolution



1 & 2)  Data Corruption/Object Damage - If the error message repeats continually and does not stop repeating, then it is either corrupted or has invalid information in it.  Either way, it will need to be replaced with a good version.  The best option would be to restore it from backup (after stopping the subsystem ZPSSMON).  If that is not an option, then a copy from another system would suffice (but make sure the security is set the same as the original damaged object).  Once it is restored, run the following commands:
ADDLIBLE PSCOMMON
CALL NW0099E
CALL NW0089C

Then validate that the Secured Entries are correct.  If not, promote the What-if entries and check again.  If they are still not correct, then promote the What-if entries one more time and validate.  Be sure to also check the RRM Defaults as well and adjust them accordingly.

Once the error message is no longer happening, start the subsystem:  STRSBS PSCOMMON/ZPSSMON

3)  Object Lock - If the error message about the userspace being corrupted is only a handful of times (ie 1, or 4, or 9, etc), and does not repeat, then the object was locked at the time.  This can happen if a backup or mirroring job is using it.  Monitor to see if this happens at certain times of the day, and if so, see what is accessing the userspace.  If possible, try to limit access to the userspace by jobs other than NetIQ to times when the system is not in active use.

Cause

Checking for damage or invalid data in NW0020U was introduced in PTF 1C04041.

NW0020U is a userspace on the IBM i that contains configuration information, and it's access can be affected by 1)  Data Corruption, 2)  Object Damage, or 3)  Object Locks:

1)  Data Corruption -  Occurrs if another program writes incorrect information to the userspace.  To check for data corruption, run the following command:  DMPOBJ OBJ(PSCOMMON/NW0020U) OBJTYPE(*USRSPC)     This will create a spooled file.  Review the spooled file and find the section that starts with SPACE-  Then look at the right side of the spooled file, where it has actual data.  The first 3 bytes should be either 123, 231, or 312.  If anything else is there, then it's corrupted.

2)  Object damage - Just like any object on the IBM i, if it is in use when the system goes down ungracefully it can be corrupted.  To check the object damage, save it.  If it's damaged, a save will not work and it will mark it as damaged.

3)  Object Locks - Locks occur when some process (backups, replication, file integrity checking, etc) lock the object while RRM's exit programs are trying to access the data in the userspace.  Object locks can be trickey, since they are usually only momentary.  So if you do a WRKOBJLCK and it shows no locks, that is most likely because whatever was locking it no longer has a lock.  Checking for locks is best performed as close to the same time as the message appears about the object.  Also, unless the lock is from a user's job, the message will not persist throughout the day.  It could spawn 1 message, or a dozen (or more), depending on how long the lock is.

Additional Information

Checking for damage or invalid data in NW0020U was introduced in PTF 1C04041.