I just read the latest newsletter and noted the article discussing the 6.1 QPWDCHGBLK system value and wondered what could be done for earlier releases to enforce a similar rule. The article mentions the requirement of getting at the password change date and time, and that prompted my recollection of a discovery I made some time ago: While the documentation of the Retrieve User Information (QSYRUSRI) API refers to the Password Change _Date_ as part of the USRI0100 format, the API in reality returns a system timestamp (*DTS) value that can be converted (using f.x. the QWCCVTDT API) to a timestamp with microsecond precision.
This enables you to check how many hours have passed since a password was changed, and thereby establish a check similar to the one enforced by the new QPWDCHGBLK system value. Using the user application APIs you could even store individual PWDCHGBLK values for each user profile, if you needed that granularity.