In this particular case, there was a security rule that was preventing the userid that issued the !OI command from executing the OPSSSMTBL function.
Regarding the different behavior in OPS 14.0 comparing to OPS 13.0: In OPS 14.0 a security loophole was closed regarding the security of commands issued using the OSFCHAR command prefix. In the past, if you issue a command using the OSFCHAR (default is "!") the userid checked would be the one set in the parameter OSFCONSOLE. Now, it is the actual userid that issued the command or the userid assigned to the console where it was issued. From OPS 14.0 Migration Information section:
Security Updates for Use of OSFCHAR Command Prefix (Base)
To close security vulnerabilities, the processing of OSF commands issued using the z/OS command prefix specified by the OSFCHAR parameter has been altered. When parameter OSFALLOW is set to YES, such commands that originate from any source other than an MCS console are secured using the credentials of the userid of that issuing unit of work. In prior releases of OPS/MVS, those commands are secured using the credentials of the userid specified by the OSFCONSOLE parameter.
Suppose that parameter OSFCHAR is set to '!' (the default) and a TSO user issues the command TSO OPSCMD COMMAND(!OI somerexx somearg). In OPS/MVS® Event Management and Automation Version 14.0, the crendentials of the TSO user are used to authorize their use of the OSF. In prior releases of OPS/MVS, the credentials of the userid specified by the OSFCONSOLE parameter are used.
The information above can be found in the link below: