Problem:
An issue has become known with ED 2.3 which will have an impact on our external partners who integrate with ES such as Job schedulers who don’t use MFBSI. It has happened with the Zena job scheduler. It is expected to be a relatively limited impact and we do not expect it will affect a lot of customers, and looks like something only provided by ASG (Allen Systems Group) and their customers using our products.
The issue only affects COBOL DLLs that are built/linked in a way that the COBOL RTS is dynamically selected at runtime that are called by non-COBOL executables. When these non-COBOL executables are run outside of a COBOL environment then the RTS will look into the registry to find the DLL. The product build means that it will look for a version 2.2 key rather than 2.3 and therefore get a failure.
The main issue concerns the callable JCL utilities (cassub etc) and the catalog. The callable JCL utilities cassub.dll/casout.dll are built with RTS Dynamic Binding. The COBOL RTS is located via the registry.
In this issue, the callable JCL utilities cassub.dll/casout.dll should be going for:
HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Micro Focus\\Visual COBOL\\2.3
Instead, they are looking in the registry for:-
HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Micro Focus\\Visual COBOL 2012\\2.2
It appears that CAS has been linked with a 2.2 runtime 2012 runtime.
The issue may be seen with Job schedulers such as CA, ASG, UC4, etc if they are run outside of a COBOL environment with the path set.
Resolution:
The simplest workaround is to create a registry entry via a reg export file with (as in this example):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Micro Focus\\Visual COBOL 2012\\2.2\\COBOL\\Install]
"BIN"="C:\\\\Program Files (x86)\\\\Micro Focus\\\\Enterprise Developer\\\\bin\\\\"
Or amend the system path and add the path to the system path. The COBOL RTS should then be found when its hunted for on the system.
#cassub
#Zena
#Enterprise
#EnterpriseDeveloper
#MFDS
