There is a field in the user profile called User ID number. You might be able to use it for what you need.
According to the help screen:
User ID number (UID) – Help
Specifies the user ID number (uid number) for this user profile. The uid number is used to identify the user when the user is using the directory file system. The uid number for a user cannot be changed if there are one or more active jobs for the user.
The value does not change.
Specify the uid number to be assigned to the user
profile. A value from 1 to 4294967294 can be entered.
The uid number assigned must not already be assigned
to another user profile.
Accounting code is a char(15) value. I’ve never needed more than nine characters for actual “accounting codes”, usually leaving six characters for additional info. I usually use those last six characters when calling certain functions that need special consideration — the functions update the code of the job (CHGACGCDE) at run-time to tag the usage of the function and return the characters to blanks when the function ends. Since job accounting can report by *generic accounting codes, processes can be grouped in many ways.
You could partition accounting code to have two parts if your codes could be normalized into identifiers of appropriate sizes.
Description is also available for partitioning into parts.
But those are both eliminated from consideration. Using any other attribute brings a potential for interference with any system or home-grown (or 3rd-party) function that relies on a valid value in that attribute.
The System Directory (WRKDIRE, etc.) might be useful. There are various commands and APIs that can store and retrieve user-defined attributes per user ID.
However, a user ID doesn’t necessarily equal a user profile. User IDs are limited to char(8) in length and are associated with user profiles. That brings a complication in creating any application as well as bringing a need actually to enroll users in the system directory.
One other possibility seems appropriate in releases of i5/OS and later — the User Application APIs. IIRC, info stored with these APIs gets saved/restored along with the user profiles — you need to verify that. The info isn’t exactly stored as part of the user profile; it’s likely stored in some related index object that the system knows needs to be maintained alongside of the profile.
The APIs might be wrapped in stored procs or UDFs for use with queries. It might be possible to integrate these into any application that you have in mind as long as it doesn’t need to support earliers releases.