Cloning a model profile with CPYUSRPRF replaces the copy-her-authority ticket on IBM i

The model profile is the specification. The write-up's framing is that you never have to define what access means in the abstract; you say make user A look like user B, and the clone operation copies the model's authorities ^[5]. That moves the hard part out of the program and into the choice of model. Every authority the model picked up over five years comes with it, including the ones nobody remembers granting.

Step ordering is where I would look first. Archiving the source file is step 8, after the profile clone at step 4, the entitlement rows at step 5 and the audit event at step 6 ^[7]. A pass that overlaps the previous one can read a file that has already been provisioned, because the file is only removed at the end. The three-way branch on the two USER_INFO counts absorbs most of that: a target that now exists routes into the refresh branch instead of create ^[15].

The options string decides how strict the parse is: `doc=file case=convert countprefix=num_ allowmissing=yes allowextra=yes trim=none` ^[12]. So `allowextra=yes` lets the intake form add fields the RPG program has never heard of, and `allowmissing=yes` lets it omit them. A request with no `targetUserId` parses cleanly and arrives as blanks. Validation lands entirely on the two existence checks against QSYS2.USER_INFO ^[15]. "Declare the contract once, as a qualified data structure, and let the parser fill it," the post says ^[13].

Two adoption costs sit in the code. `%PARSER('YAJL/YAJLINTO')` means the YAJL service program has to be installed in a library of that name ^[12], and the post describes it only as the YAJL-based parser service program ^[10]. DATA-INTO itself needs IBM i 7.2 with PTFs, or 7.3 and later ^[10].

Verification is a count. After the CHGUSRPRF string runs through QSYS2.QCMDEXC, the program selects `COUNT(*)` from USER_INFO for the target name and writes the history record only once that comes back ^[17][18]. "Don't just trust that the CL call succeeded," the post says ^[18]. The count confirms a profile with that name exists. The target's authorities are never compared against the model's. The published excerpt breaks off mid-sentence at the history record write ^[18].

On a shared IFS mount, the check that stops two partitions claiming the same request is a comparison of `requestDoc.targetSystem` against `CURRENT SERVER`, skipping any file addressed elsewhere ^[14]. The write-up offers that as a tip ^[14].

The declared structure has eight fields: requestDate, targetUserId, targetUserName, targetUserEmail, modelUserId, targetSystem, siteCode and managerEmail ^[11]. None of them is an approver ^[1]. managerEmail is a notification address, used at step 7 to mail the requester and the manager ^[7]. The complaint the piece opens with is that six months later nobody can say who approved what, or when ^[2]; the flow as drawn begins when the intake system writes the JSON file ^[6], so the approval evidence lives there.