Hi Danielle,

Terminology-wise I would prefer to speak of "queued commands" and "revoke/resume schedules" and "scheduled events".
Queued commands can be timed and temporary, there you would actually schedule a particular command for a particular date etc.
Here we are talking about revoke/resume schedules, with events on the schedule(s), and potentially a command or action resulting from the combination of all the schedules.

It appears you have a schedule called CANCEL. 
This might be the only schedule you have on this user, so it might determine the overall revoke/resume setting.

I think the Audit Trail here is from zSecure Command Verifier (while the schedules are from the CKGRACF component of zSecure Admin).
This reflects actual commands that were issued.

Issuing commands on the basis of revoke/resume schedules would be done by a daily CKGRACF job, I think.
https://www.ibm.com/docs/en/szs/3.2.0?topic=production-requirements-rationale-running-daily-ckgracf-job
This is on the basis of this TYPE=RACF CARLa field:
CKGREFRESH, CNGREFRESH

This field is derived from the USR field and contains the date after which a CKGRACF REFRESH command is required; undefined if the profile does not contain scheduled revoke/resume actions or queued commands.

So I guess my first question is if the daily job is in fact running.

> to essentially "hard revoke" user IDs so only we can reinstate them

The way this works is that there can be multiple schedules, and only some people are authorized to set events on a particular schedule.
So insofar CKGRACF controls who is resumed and revoked, this means it won't resume users that are 'hard revoked'.
Note this does not mean that someone else cannot be authorized to do a direct RESUME in RACF. 
But you'd expect another REVOKE to occur if the user is still hard-revoked at the next refresh.

I hope this begins to help.

Regards,

Jeroen