Gen 8.6 Windows Oracle CSE "ORA-12557" after Oracle 19.16 patch install

Products

• Gen

Issue/Introduction

Gen 8.6 Windows Oracle CSE running on virtual machine (VM).
After installing an Oracle patch 19.16, the Start CSE always fails. 

The mderr.log file shows:

SQL Communication Area
SQLCAID:         
SQLCABC: 0
SQLCODE: -12557
SQLERRML: 45
SQLERRMC: ORA-12557: TNS:protocol adapter not loadable

Can connect to the database from a remote machine, so the Listener is working as expected.
Can also connect locally from a command prompt with SQLPlus.

Then found only some CSE process randomly fail to start and the CSE hangs.
See this message in iefmd.01 file

WARNING |   The TCP Socket is still in use.
WARNING |   If all sockets get this warning then close all Client/Server Applications then retry operation.
ERROR   |   CSEHTI29213:
ERROR   |   The Application could not be started due to a transport problem.

Environment

Gen 8.6 Windows Oracle Client Server Encyclopedia (CSE)
PTFs installed: WKS86200, CSN86202, CSN86204, CSN86205, CSN86206

Resolution

The Gen Windows CSE requires the 32-bit Oracle client software to connect to the 64-bit Oracle Database.
Web searches for error ORA-12557 indicate some potential 32-bit/64-bit software conflict.
The Oracle Database patch install may have changed the System Environment Variable PATH which impacted the use of the 32-bit Oracle client software e.g. perhaps the Oracle 64-bit database bin directory was moved in front of the Oracle 32-bit client bin directory in the PATH.
It is advised having the Oracle 32-bit client bin directory first for at least CSE configuration (Prerequisites for CSE Configuration) and so that is where it would normally stay for CSE runtime.

However for the CSE runtime with the official CSE support for Oracle 19 client software delivered in PTF CSN86204 (installed here) a hard link gets created in the Oracle 32-bit client bin directory with name orasql.dll which points to file orasql19.dll in the same directory.
That means that the CSE is then Oracle dll name independent i.e. the dll file "C:\Program Files (x86)\CA\Gen86\CSE\bin\dbcse.dll" used by all the CSE executables which connect to the database references orasql.dll and not orasql19.dll
So even though there are multiple orasql19.dll files on the server (32-bit client and 64-bit DB versions) there is only 1 orasql.dll and that is 32-bit, so in theory it should always be found irrespective of directory ordering in the PATH.
Support also could not recreate any CSE runtime problem when having the Oracle 64-bit database bin directory in front of the Oracle 32-bit client bin directory in the PATH.

After further time passed the CSE became stable without needing any changes to the PATH.
It is believed the problems were all related to VM instability.