We have an Entire Connection-based application that has been in production for 14 years, migrated from Windows 95 to Windows XP (32-bit)/EC 4.4.1.0, and now to Windows 7 (64-bit)/EC 4.5.2.3.
Users are logged into our z/OS application via Entire Connection (EC), and they progress through several screens, the last of which downloads data to a pre-defined named file on the PC and runs a pre-defined EC Task that starts a VB6 application. The VB6 application processes the downloaded data, allows the user to interact with the data including modifying the data. When finished the user click a button in the VB6 application and a PF key is sent to the z/OS application instructing it to upload the modified data via a pre-defined named file.
I’m having problems connecting to an existing sesion using the PCC API Initialize() method in the VB6 application. First I call the GetRunningTerminalSessions() method, and then I attempt to connect to each named session returned by GetRunningTerminalSessions(). FYI We have a “Automatic logon” procedure that prevents users from starting two sessions with the same name, as that is a problem with the Initialize() method, but our “Automatic logon” procedure insulates us from having to deal with that problem.
The Initialize() method works fine in Windows XP, but not in Windows 7; in Windows 7 it always starts a new session instead of connecting to the named session as I’ve requested. The “CreateSession” parameter is set to false, it’s always been set to false for 14 years.
Just to test the problem in complete isolation of any of my code I ran some tests using a program named “Entire Connection API Test” provided by Software AG. It exhibits the same “create a new session” behavior as my application does in Windows 7, but not in Windows XP.
Any ideas what could be wrong with the Initialize() method? Is this a known bug documented somewhere? Does something need to be configured differently on Windows 7?
Remember I’m using a Software AG API testing program to connect to Software AG’s Entire Connection; at this point in the tests there is no code written by me or my staff.
Thanks in advance for your help!
This is a know problem of the version you are using. It is already fixed in version 4.5.2 PL5 of Entire Connection.
Thanks Norman, that’s great news!
I’ll work towards getting the updated Entire connection ASAP.
Do you know if 4.5.2 PL5 does anything to resolve the “4.3 API Initialization Error Code 40” issue documented in the Readme.txt file of version 4.5.2 PL3?
Yesterday, we ran into the “4.3 API Initialization Error Code 40” issue on a couple of test PCs and we’re trying to figure out how to resolve it. Although the Readme.txt file does provide some explanation using DCOMCNFG, it’s not something that most of us have any experience with, and so the explanation doesn’t seem very helpful.
We don’t see 1) our client application, 2) the “Entire Connection API Test” application, or 3) Entire Connection listed.
So if 4.5.2 PL5 does not resolve the “4.3 API Initialization Error Code 40” issue, are there any more detailed instructions on how to resolve it?
Thanks again for past help provided, and thanks in advance for any additional help you can provide!
I’ve checked with the sample programs that are part of the Entire Connection delivery. It works fine when starting the VB example program with “Run as Administrator” AND starting the Entire Connection Terminal program with “Run as Administrator”. Otherwise the calls result in an Error Code 40 caused by the UAC under Windows 7.
The hint “Initialization Error Code 40” in the readme comes from the installation under Windows XP and has a different cause.
Please try to run the programs with administrator rights to check whether it works.
Thanks Juergen! We tested the “Run as administrator” approach and found that as long we run Entire Connection once as an administrator, the Initialize method call continually works thereafter, even when logged in as a different user.
I just scanned the Readme.txt file that came with 4.5.2.3 and there is definitely is no mention of Windows XP anywhere near the documentation of the 4.3 “Initialization Error Code 40” issue. You guys might want to add some mention of the affected Oss to each issue, it would save your customers some headaches.
Yes, you are right. We will check that. As far as I can see it was first added in version 4.2.1.1 from year 2001.