The process described in TEC599992 will assign a GID if one does not exist for the group assignment in the logonid.
This will be for either an init_USP or getgmap callable service request.
The process for an FTP signon is slightly different because of the way that the getgmap request is issued and no GID will be assigned.
According to Security Server RACF Callable Services Version 2 Release 1 SA23-2293-00
In the description of the "getGMAP (IRRSGM00): Get GID-to-Group-Name mapping" callable service there are three request types that can be issued in the "flag" field.
The name of a word containing the lookup option:
X'00000000' search by z/OS UNIX group identifier (GID), return group name
X'00000001' search by group name, return GID
X'00000002' search by group name, return z/OS UNIX group identifier (GID),
but do not create a new GID even if BPX.UNIQUE.USER is defined.
For request 00000001 a GID will be assigned if the logonid has a GROUP value but no GID associated.
For request 00000002 the call will fail if the group in the logonid does not have a GID assigned.
FTP will issue request 00000002 when logging in to an FTP session.
The following will be seen in ACFRPTOM
getGMAP FTPD OMVSGRP 0 1 8 8 20
mm/dd/yy yy.ddd hh.mm.ss FTPDn XXXX XXXX
Failed - Group incompletely defined as OpenMVS group
GID value: nnnnnn
Map name: userid Search by groupname, Return GID, No DFT
The solution to this situation is to ensure that every user that will use FTP has a GROUP in the logonid with a GID assigned.
Note: this process by ftp is NOT restricted to z/OS 2.1 - previous z/os levels also see this functionality.
The CA ACF2 for z/OS processing is in line with the IBM RACF description of this callable service.
CA ACF2 for z/OS is responding to the getgmap callable service request issued by FTP.