Problem: An issue has become known with ED 2.3 where the Job Scheduling tools from 3rd party vendors stop communicating with ES. This issue will have an impact on our external partners who integrate with ES such as Job Schedulers who don’t use MFBSI. The issue may be seen with Job schedulers such as Zena, CA, ASG, UC4, etc if they are run outside of a COBOL environment with the path set. This issue only affects COBOL DLLs that are built/linked in a way that the COBOL RTS is dynamically selected at runtime and that are called by non-COBOL executables. When these non-COBOL executables are run outside of a COBOL environment 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. For instance, 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. Resolution: The simplest workaround is to create a registry entry via a registry 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 it’s hunted for on the system.
↧
