PGMDU / NSCDU - is a user active or inactive

I have all kinds of places I use NSC interface modules to do maintenance and even can deactivate a user by using deactivation dates.

However, I was given a new requirement that I should call to return if a NSC user id is active or inactive. Now I am stumped.

I would think NSCDU would be the most likely routine. In fact, when testing using PGMDU and displaying the map it shows where applicable:

This security profile is currently not active.

However, there is no field that shows this:

User ID … VSTA123
Return code … 0
User type … M
Private library …
Default application … VISTA123
Last application … PRODBTCH
Last ETID …
Batch user id …
Days to change password . 0
Language or … 0
time differential (Term) 0 - 5
time zone (Term)
Logon recorded … N
NDV Unlock…
Privileged groups/members
List groups/members …
No of groups/members … 1
Mailboxes …
User ID … VSTA123
Created by … VSSCLF3
Date created … 19940111
Time created … 08:55:30
Co-signers creation …
Last modified by … VSTA146
Date last modified … 19960624
Time last modified … 12:32:58
Co-signers modification .
Owners, number of co-signers required:
Owner 1 … 0
Owner 2 … 0
Owner 3 … 0
Owner 4 … 0
Owner 5 … 0
Owner 6 … 0
Owner 7 … 0
Owner 8 … 0
Last date of pw change … 19940111
Security note 1 …
Security note 2 …
Security note 3 …
Security note 4 …
Security note 5 …
Security note 6 …
Security note 7 …
Security note 8 …

Can anyone suggest a routine I can call where the input is user id and the output contains something like ACTIVE-STATUS?

Thanks in advance!


NSCDU is the correct module. Please maintain PGMDU and redefine PPARM3 as follows:
1 PPARM3 (A250) /*
2 PLOCKTYPE (A1) /* If user ID is locked, possible values are

  •                        /* 'C' - countersign locked,
  •                        /* 'L' - logon locked.

2 PLDATE (D) /* Date of locking.
2 PLTIME (T) /* Time of locking.
2 PLAPPLID (A8) /* Library ID when user was locked.
2 PLTERMINALID (A8) /* Terminal ID when user was locked.
2 PLTPUSERID (A8) /* TP user ID when user was locked.
2 LOCKTYPE-CL (A100) /* (only output).
3 PLOBJECTID (A32) /* Object ID of object to be maintained.
3 PLOWNER (A8) /* Owner ID for which invalid password

  •                        /* was entered.

3 PLERRNR (N4/1:5) /* Error numbers received during

  •                        /* logon attempt.

3 PLERRUSER (A8/1:5) /* User IDs entered during logon attempt.
3 PLERRAPPLID (A8/1:5) /* Library IDs entered during

  •                        /* logon attempt.

2 PLOCKDATES(D/1:20) /* Activation dates (only output).
2 FILLER 34X /* Reserved for future use.

In field PLOCKDATES you will find the information.

Hi Uwe,

Thanks much for your response.

It appears you are suggesting that I use the existence of a deactivation date or not to imply active status. In some way I already make use of this in another place to deactivate users via NSCUS by moving the current date to PLOCKDATES(1,1). Is there no actual activation status field, or is it always inferred by the existence of activation and deactivation dates? If the latter, I will have to play around with this to figure out what the rules are since there are multiple pairings of such dates, so someone can be active, inactive for a time, active again, inactive again, etc.



Hi Brian,

the APIs always return the temporarily inactive times which is shown with the following example:
PRINT // ‘Temporarily inactive (Activation times):’
/ ‘From’ 12T ‘to’ 24T ‘From’ 36T ‘to’ 48T ‘From’ 60T ‘to’
If a return code is required - for example: SYSSEC6116 which is shown in the user profile maps - you may add a brainstorm request.


Thanks for your help, Uwe. I have tried your suggestion and it’s interesting how this displays.

Example: I have this one ID VSTA002 which is currently inactive.

  • Activation Dates of: VSTA002 *
    This security definition is
    Generally active
    from: __________

Temporarily inactive
from - until
__________ - __________
__________ - __________
__________ - __________
__________ - __________
__________ - __________
__________ - __________
__________ - __________
__________ - __________

Generally inactive
from: 2013-02-22

Temporarily inactive (Activation times):
From to From to From to
2013-02-22 2699-12-31

For active users, this code fails with NAT1137 Date is outside valid range, so I will have to trap for that. I cannot interrogate PLOCKDATES(1) without getting a S0C7 in such cases so it will have to be some kind of ON ERROR block instead.

I will also have to find a user that was inactive for a period and reactivated to see how the order of date ranges are presented so I can properly interpret their status.


It appears PLOCKDATES(01) contains x’00000000’ when a user is active.

If the first set of dates is populated, then PLOCKDATES(03) will contain either a date or x’0000000F’.

Hence I could redefine PLOCKDATES(D/1:20) as PLOCKDATES-A(B4/1:20) and interrogate the content and not have to worry about S0C7/NAT0954s or NAT1137 errors.

Guess I still have one more scenario to code for.

The way it is now is ok for users who either were never de-activated so they are active today, or for users who were deactivated once and the end date is the end of Natural time.

I should improve this to check the content of PLOCKDATES(02)… and if today’s date is after that date, then check the content of PLOCKDATES(03) for inactivity (if x’0000000F’ then the user is actually active, not inactive).

That is, unless the order of these PLOCKDATES pairs differs from how I am thinking.

I have no examples I can see where we have reactivated a user and left an old temporary inactive pairing on the security record. And for testing, I cannot put dates in the past in there. Best I can do is put in a pair that will expire tomorrow and see what happens.