BTW, there is a very simple counterexample to your suggestion that all "old" boolean fields can be used directly:
You can use SPECIAL as a boolean/keyword (or "attribute" as the documentation says), but after FLAG2 a relational operator is expected.
Original Message:
Sent: Tue January 02, 2024 10:57 AM
From: Jeroen Tiggelman
Subject: Help understanding logic behind an EXCLUDE statement used to identify new userids with expired passwords
Hi Rob,
Yes, a basic flag field without special support. By contrast, both SPECIAL and REVOKED are exceptionally treated as keywords by the SELECT parser.
(For output, SPECIAL is understood to be as alias for the template field FLAG2, while REVOKED is an alias for the zSecure-defined field REVOKE.)
I am not convinced that your idea that all "older" boolean fields in TYPE=RACF have special treatment is correct, but I don't feel like reviewing that right now. I do agree that the differences/surprises can be annoying.
As to the documentation, SPECIAL and REVOKED explicitly appear here: https://www.ibm.com/docs/en/szs/3.1.0?topic=SS2RWS_3.1.0/com.ibm.zsecure.doc_3.1.0/admin_audit/carla_cmnd_lang_select_fld_val_usr_cls.htm .
Regards,
------------------------------
Jeroen Tiggelman
IBM - Software Development Manager IBM Security zSecure Suite
Delft
Original Message:
Sent: Fri December 29, 2023 06:06 AM
From: Rob van Hoboken
Subject: Help understanding logic behind an EXCLUDE statement used to identify new userids with expired passwords
Hm.... basic flag field.... it has been possible to use basic flag fields as booleans for a long time, like
newlist type=racf
select class=user special
or
select class=user revoked
Obviously, field names HAS_PASSWORD and HAS_PHRASE are not from the templates, but built-in, like SPECIAL and REVOKED. It is annoying that the difference between the old field names (that can be used as booleans) and the new ones cannot be gleaned from the manual. But you're right, RACF newlist is a constant source of (undocumented) surprise.
------------------------------
Rob van Hoboken
Original Message:
Sent: Thu December 28, 2023 02:40 PM
From: Jeroen Tiggelman
Subject: Help understanding logic behind an EXCLUDE statement used to identify new userids with expired passwords
Hi Michael,
I think TYPE=RACF works slightly differently from other newlist types in a number of regards (which might have to do with applying the information from the RACF templates to influence the field type... but doing so only after the basic parse). If you use a DEFINE... TRUE variable you don't need to specify a value, but for a basic flag field I believe you do.
Regards,
------------------------------
Jeroen Tiggelman
IBM - Software Development Manager IBM Security zSecure Suite
Delft
Original Message:
Sent: Thu December 28, 2023 11:07 AM
From: Michael Nielsen
Subject: Help understanding logic behind an EXCLUDE statement used to identify new userids with expired passwords
I did change line 6 to
6 | PASSWORD_EXPIRED=YES NOT(HAS_PHRASE=YES)
and it worked.
I'm just curious about the conflicting behavior on the bit fields. Could we have something configured incorrectly?
------------------------------
Michael Nielsen
Original Message:
Sent: Thu December 28, 2023 10:59 AM
From: Michael Nielsen
Subject: Help understanding logic behind an EXCLUDE statement used to identify new userids with expired passwords
I tried using the example
SELECT CLASS=USER SEGMENT=BASE CREADATE>=TODAY-4 PASSWORD_EXPIRED NOT(HAS_PHRASE)
and CARLa seems to expect relational operators on the bit fields
1 | /* # temp */
2 | alloc type=UNLOAD DD=C1UNL1
3 | alloc type=CKRCMD DD=CKRCMD01
4 | NEWLIST TYPE=RACF NOPAGE NODUP OUTLIM=0 NAME=ONWHRE
5 | SELECT C=USER SEGMENT=BASE CREADATE>=2023-12-06,
6 | PASSWORD_EXPIRED NOT(HAS_PHRASE)
CKR0128 12 Expecting relational operator or "(" instead of blanks " NOT(HAS_PHRASE)" at SYSIN line 6
CKR0987 12 Syntax error: text expected instead of blanks at " NOT(HAS_PHRASE)" on SYSIN line 6
CKR0128 12 Expecting relational operator or "(" instead of delimiter ")" at SYSIN line 6
CKR0987 12 Syntax error: text expected instead of delimiter at ")" on SYSIN line 6
Am I reading the messages incorrectly?
------------------------------
Michael Nielsen
Original Message:
Sent: Fri December 22, 2023 07:44 AM
From: Rob van Hoboken
Subject: Help understanding logic behind an EXCLUDE statement used to identify new userids with expired passwords
First of all, EXCLUDE works only on the records (profiles) that have matched the preceding SELECT command. That means, you do not have to specify C=USER S=BASE on the EXCLUDE commands.
For simple bit fields, you do not have to write =YES or <>YES, this may make it easier to read.
EXCLUDE (C=USER SEGMENT=BASE HAS_PASSWORD=YES PASSWORD_EXPIRED<>YES),
OR (C=USER SEGMENT=BASE HAS_PASSWORD<>YES HAS_PHRASE=YES)
becomes
EXCLUDE (HAS_PASSWORD NOT(PASSWORD_EXPIRED)),
OR (NOT(HAS_PASSWORD) HAS_PHRASE)
and your final report would read
SELECT CLASS=USER SEGMENT=BASE CREADATE>=TODAY-4 PASSWORD_EXPIRED NOT(HAS_PHRASE)
------------------------------
Rob van Hoboken
Original Message:
Sent: Wed December 20, 2023 01:58 PM
From: Michael Nielsen
Subject: Help understanding logic behind an EXCLUDE statement used to identify new userids with expired passwords
I tried using the following CARLa to build a list of new userids that have expired passwords and do not have a passphrase
NEWLIST TYPE=RACF PL=0
SELECT C=USER SEGMENT=BASE CREADATE>=TODAY-4
EXCLUDE (C=USER SEGMENT=BASE HAS_PASSWORD=YES PASSWORD_EXPIRED<>YES),
OR (C=USER SEGMENT=BASE HAS_PASSWORD<>YES HAS_PHRASE=YES)
SORTLIST KEY(8)
and noticed that some userids which should appear in the report were not there.
After some testing this CARLa seems to provide an accurate report
NEWLIST TYPE=RACF PL=0
SELECT CLASS=USER SEGMENT=BASE CREADATE>=TODAY-4 PASSWORD_EXPIRED=YES
EXCLUDE CLASS=USER SEGMENT=BASE HAS_PHRASE=YES
SORTLIST KEY(8)
The first carla seems to be too inclusive and is accidentally excluding some, but not all, userids which we want to find (new userids with an expired password and no passphrase). I've tried working this out but don't understand the logic that is happening here. I would appreciate it if someone can step through and explain the logic in the first example.
------------------------------
Michael Nielsen
------------------------------