[archive] Call Windows API fails via Thin Client

[Migrated content. Thread originally posted on 27 January 2005]

I'm using a WinAPI function call CreateFile to get a handle to a Windows file. This works fine when tested locally, but when used via the Thin Client, it fails (this means it does not return a handle to the file!).

FYI,
- The local Kernel32.dll was loaded succesfully in both environments and the Thin Client call had the "@[DISPLAY]:" prefix;
- I checked the format and the contents of the parameters twice; they are all exactly the same;
- I compiled the program with -Dl4 -Dw32 to be sure that allignment and length of parameters is not the cause;
- The program objects were not the same, the local one was running in a simplified test environment, the Thin Client was running in the full production environment;
- Acucobol-GT 6.1 was used in both cases, because the production environment is still using this.

I have no idea anymore what to do, any suggestions?

Ren

I did some additional testing and checking:

- the compilation parameters were exactly the same!

- I took my simplified testprogram and ran it from the production environment using the thin client. For this I had to add a linkage section with a communication block, comment out some fields in the working-storage because they had a meaning and field name now covered within the communication block and last, but not least, I had to add the "@[DISPLAY]:" prefix to all the API calls. Result? The CreateFile call still fails.

Has anyone suggestions what to do???

Ren

[Migrated content. Thread originally posted on 27 January 2005]

I'm using a WinAPI function call CreateFile to get a handle to a Windows file. This works fine when tested locally, but when used via the Thin Client, it fails (this means it does not return a handle to the file!).

FYI,
- The local Kernel32.dll was loaded succesfully in both environments and the Thin Client call had the "@[DISPLAY]:" prefix;
- I checked the format and the contents of the parameters twice; they are all exactly the same;
- I compiled the program with -Dl4 -Dw32 to be sure that allignment and length of parameters is not the cause;
- The program objects were not the same, the local one was running in a simplified test environment, the Thin Client was running in the full production environment;
- Acucobol-GT 6.1 was used in both cases, because the production environment is still using this.

I have no idea anymore what to do, any suggestions?

Ren

First of all. It is very difficult to suggest anything without even a line of code to suggest what you do.

Second, testing off production environment is always smart to do when you try out new things, not only because it makes it easier for yourself to see things easily overseen (I oversee things myself every day :-) ).

Now, one thing to keep in mind when using the CALL phrase, whatever goes through there is from the runtimes perspective considered to be a "program", and with programs, we need to specify if it is on the client or the server side.

Thus, it will not suffice to prefix the DLL load, but you also have to do this for the function call itself.

If it still doesn't work, please show some code.

[Migrated content. Thread originally posted on 27 January 2005]

I'm using a WinAPI function call CreateFile to get a handle to a Windows file. This works fine when tested locally, but when used via the Thin Client, it fails (this means it does not return a handle to the file!).

FYI,
- The local Kernel32.dll was loaded succesfully in both environments and the Thin Client call had the "@[DISPLAY]:" prefix;
- I checked the format and the contents of the parameters twice; they are all exactly the same;
- I compiled the program with -Dl4 -Dw32 to be sure that allignment and length of parameters is not the cause;
- The program objects were not the same, the local one was running in a simplified test environment, the Thin Client was running in the full production environment;
- Acucobol-GT 6.1 was used in both cases, because the production environment is still using this.

I have no idea anymore what to do, any suggestions?

Ren

Gisle,

Thank you for your response. Maybe it was not clear from my earlier message, but I did not forget to add "@[DISPLAY]:" before the Windows API.

This is a fragment of my code:

77 GENERIC-WRITE PIC X(04) COMP-N
VALUE 1073741824.
78 OPEN-EXISTING VALUE 3.
77 dwCreationDisposition pic S9(09) comp-5.
77 dwDesiredAccess PIC X(04) COMP-N.
77 hObject usage handle value NULL.

...

MOVE GENERIC-WRITE TO dwDesiredAccess
MOVE OPEN-EXISTING TO dwCreationDisposition
* * Get handle to file object *
CALL "@[DISPLAY]:CreateFileA" USING
BY REFERENCE lpFileName,
BY VALUE dwDesiredAccess,
BY VALUE NULL, |dwShareMode
BY VALUE NULL, |lpSecurityAttributes
BY VALUE dwCreationDisposition,
BY VALUE NULL |dwFlagsAndAttributes
BY VALUE NULL |hTemplateFile
GIVING hObject

The lpFileName is a pic x(80) field with a path string terminated with x"00".
The call always returns -1 (which gives in Acu that very large number). Running this without the function prefix on a local machines returns the requested handle.

I hope this makes sense?

Ren

[Migrated content. Thread originally posted on 27 January 2005]

I'm using a WinAPI function call CreateFile to get a handle to a Windows file. This works fine when tested locally, but when used via the Thin Client, it fails (this means it does not return a handle to the file!).

FYI,
- The local Kernel32.dll was loaded succesfully in both environments and the Thin Client call had the "@[DISPLAY]:" prefix;
- I checked the format and the contents of the parameters twice; they are all exactly the same;
- I compiled the program with -Dl4 -Dw32 to be sure that allignment and length of parameters is not the cause;
- The program objects were not the same, the local one was running in a simplified test environment, the Thin Client was running in the full production environment;
- Acucobol-GT 6.1 was used in both cases, because the production environment is still using this.

I have no idea anymore what to do, any suggestions?

Ren

Gisle (and possible other interested),

Today I got a message from Tech Support that explains why it does not work:

---

Hello Ren?,

I have spoken to one of our developers last night about the problem that you are having getting your program to call DLL's correctly when running with Thin Client.

It appears that there is a fault when calling DLL's via Thin Client with the "BY VALUE NULL" phrase. The data is not being passed over correctly.

It is possible to get around the problem by adding a new variable to the WORKING-STORAGE:

77 ws-dummy pic x(04) comp-n value 0.

and changing all the CALLs that use "BY VALUE NULL" to "BY VALUE ws-dummy".

I have tested this by making some changes to the program that you provided and it does work. I have attached my modified version of the program to this email.

I will keep this ID open as there is a fault when running with Thin Client and will mark this as a reproduced issue and send it to development.

Regards
Martin

---

I will check this out today or tomorrow, but it looks they are familair with the problem!

Ren

[Migrated content. Thread originally posted on 27 January 2005]

I'm using a WinAPI function call CreateFile to get a handle to a Windows file. This works fine when tested locally, but when used via the Thin Client, it fails (this means it does not return a handle to the file!).

FYI,
- The local Kernel32.dll was loaded succesfully in both environments and the Thin Client call had the "@[DISPLAY]:" prefix;
- I checked the format and the contents of the parameters twice; they are all exactly the same;
- I compiled the program with -Dl4 -Dw32 to be sure that allignment and length of parameters is not the cause;
- The program objects were not the same, the local one was running in a simplified test environment, the Thin Client was running in the full production environment;
- Acucobol-GT 6.1 was used in both cases, because the production environment is still using this.

I have no idea anymore what to do, any suggestions?

Ren

Very good, very good.

As a matter of fact, it was me that provided Tech support the solution yesterday evening european time. I am currently in SD, thus the late responses.

[Migrated content. Thread originally posted on 27 January 2005]

I'm using a WinAPI function call CreateFile to get a handle to a Windows file. This works fine when tested locally, but when used via the Thin Client, it fails (this means it does not return a handle to the file!).

FYI,
- The local Kernel32.dll was loaded succesfully in both environments and the Thin Client call had the "@[DISPLAY]:" prefix;
- I checked the format and the contents of the parameters twice; they are all exactly the same;
- I compiled the program with -Dl4 -Dw32 to be sure that allignment and length of parameters is not the cause;
- The program objects were not the same, the local one was running in a simplified test environment, the Thin Client was running in the full production environment;
- Acucobol-GT 6.1 was used in both cases, because the production environment is still using this.

I have no idea anymore what to do, any suggestions?

Ren

Hello Gisle,

Thank you for your help! I can confirm that this work-around works fine!

Ren