For some strange reason neither PL/I nor COBOL is able to supply the userid. DB2 makes it available through the USER special register, REXX has a function called USERID() and in CICS you can access the userid by using EXEC CICS ASSIGN USERID(variableName). When your PL/I or COBOL program is using either DB2 or CICS you can access the userid, but what if your program does not have access to neither CICS nor DB2? Well, in COBOL you can do it like this:

DATA DIVISION.
WORKING-STORAGE SECTION.
01  PSA-POINTER POINTER.
01  USERID PIC X(8).
LINKAGE SECTION.
01  PSA.
  02  FILLER PIC X(548).
  02  ASCB-POINTER POINTER.
01  ASCB.
  02  FILLER PIC X(108).
  02  ASXB-POINTER POINTER.
01  ASXB.
  02  FILLER PIC X(192).
  02  ASUSER PIC X(8).
PROCEDURE DIVISION.
...
SET PSA-POINTER TO NULL
SET ADDRESS OF PSA TO PSA-POINTER
SET ADDRESS OF ASCB TO ASCB-POINTER
SET ADDRESS OF ASXB TO ASXB-POINTER
MOVE ASUSER TO USERID
DISPLAY 'ADDRESS SPACE USERID = ' USERID
...

I PL/I you can code a function like this one:

userid: PROC RETURNS(CHAR(8));

  DCL psa_address FIXED BIN(31) INIT(0);
  DCL psa_pointer POINTER BASED(ADDR(psa_address));
  DCL 1 psa BASED(psa_pointer)
    , 2 filler CHAR(548)
    , 2 ascb_pointer POINTER
    ;
  DCL 1 ascb BASED(ascb_pointer)
    , 2 filler CHAR(108)
    , 2 asxb_pointer POINTER
    ;
  DCL 1 asxb BASED(asxb_pointer)
    , 2 filler CHAR(192)
    , 2 username CHAR(8)
    ;

  RETURN(asxb.username);

END userid;

The above pieces of code will in TSO access the userid of the TSO user. In batch they access either the userid of the submitter of the job or the userid specified on the JOB card. In CICS they access the userid used to start the CICS system which normally is NOT the userid executing the transaction. If you want to access the userid of the transaction you have to use EXEC CICS ASSIGN USERID.