Apar IC19289 contains an update to REXECD.EXE. 
It contains the following exe:
                                
   REXECD.EXE                                                                    
                                                                                
To execute replace REXECD.EXE in the TCPIP\BIN directory.  Be sure               
to backup the original.                                                         
              
Description:

Development APAR that updates the REXEC server (REXECD) with support 
for the TME 10 Framework for OS/2 product.  This support includes:

    - Function to detect if the OS/2 installable security subsysyem is available.
      If available, REXECD will utilize the security APIs within the subsystem to
      authenticate client's attempting to issue commands.  If the security
      subsystem is not available, then REXECD will default to using it's
      traditional method of authentication.

   - Quiet mode support that will prevent any additional client input supplied to
     the server from being echoed on the server's console.  By default, quiet
     mode is off and any additional input supplied by the client IS echoed to
     the server's stdout.   To utilize quiet mode, specify '-q' as a parameter when
     starting REXECD as an isolated server (i.e. not under the control of INETD).
     Or, to utilize quiet mode when REXECD is started under INETD, set the
     QUIETMODE environment variable to 1 (or any non-null value).  The QUIETMODE
     variable only works when REXECD is started under INETD.  The purpose of 
     quiet mode is to prevent the displaying of binary input data (sent from the client) 
     which could result in undesireable beeping on the server.

   -  REXECD will now support long client commands of 256 bytes or more in length.

   -  REXECD will now route stderr information produced by a client's command back
      to the client over a secondary socket connection dedicated to receiving error
      information.  Prior to this APAR, stdout and stderr from the client's command were
      both routed over the same, primary socket connection.