C$SYSTEM under thin client

We are using Extend 9.1.1 AcuRCL on server2008, clients running Win7. We have this installed in dozens of sites, with hundreds of work stations, working fine.
For one function, where we invoke saxon.jar to create an .fo file, and then use fop to create a PDF, everything works fine in a thick client session on the server. However, from all workstations running a thin client session on this one server, the command-line calls to C$SYSTEM fail with exit-status=2.

This works fine at all other customer sites, with the same configuration of server (2008) and workstations, and also with other combinations. Just at this one site, the thin client sessions fail when calling both saxon.jar, and when calling fop.bat. We CAN (and do) call other routines in the thin client session, including .EXEs on the server, without any problem.

I'm flummoxed - I've checked everything I can think of. The default user under AcuRCL has administrator priviledges, and because other calls to .EXE files work, that doesn't seem to be a problem. The folders are set to give full access to the domain users, to the built-in SYSTEM user, and to the default user set up in Acurcl.cfg. There are no errors generated in the trace file created with acurcl.

Would anyone have any ideas I could try?

Thanks

Tony

I just wonder if this Windows 2008 system has Powershell in addition to the typical Command prompt. I know I ran across this issue where commands through Powershell did not work like they would through the command prompt.

We are using Extend 9.1.1 AcuRCL on server2008, clients running Win7. We have this installed in dozens of sites, with hundreds of work stations, working fine.
For one function, where we invoke saxon.jar to create an .fo file, and then use fop to create a PDF, everything works fine in a thick client session on the server. However, from all workstations running a thin client session on this one server, the command-line calls to C$SYSTEM fail with exit-status=2.

This works fine at all other customer sites, with the same configuration of server (2008) and workstations, and also with other combinations. Just at this one site, the thin client sessions fail when calling both saxon.jar, and when calling fop.bat. We CAN (and do) call other routines in the thin client session, including .EXEs on the server, without any problem.

I'm flummoxed - I've checked everything I can think of. The default user under AcuRCL has administrator priviledges, and because other calls to .EXE files work, that doesn't seem to be a problem. The folders are set to give full access to the domain users, to the built-in SYSTEM user, and to the default user set up in Acurcl.cfg. There are no errors generated in the trace file created with acurcl.

Would anyone have any ideas I could try?

Thanks

Tony

Wiith the Powershell it works better when you preface your command with cmd /c, you could try this in your call to C$SYSTEM, insert a cmd /c before referencing the bat file or script.

We are using Extend 9.1.1 AcuRCL on server2008, clients running Win7. We have this installed in dozens of sites, with hundreds of work stations, working fine.
For one function, where we invoke saxon.jar to create an .fo file, and then use fop to create a PDF, everything works fine in a thick client session on the server. However, from all workstations running a thin client session on this one server, the command-line calls to C$SYSTEM fail with exit-status=2.

This works fine at all other customer sites, with the same configuration of server (2008) and workstations, and also with other combinations. Just at this one site, the thin client sessions fail when calling both saxon.jar, and when calling fop.bat. We CAN (and do) call other routines in the thin client session, including .EXEs on the server, without any problem.

I'm flummoxed - I've checked everything I can think of. The default user under AcuRCL has administrator priviledges, and because other calls to .EXE files work, that doesn't seem to be a problem. The folders are set to give full access to the domain users, to the built-in SYSTEM user, and to the default user set up in Acurcl.cfg. There are no errors generated in the trace file created with acurcl.

Would anyone have any ideas I could try?

Thanks

Tony

Good thought - if it were Powershell, I would expect to see the same problem when running a thick client session on the server itself. We don't see that - the thick client session on the server runs just fine. Only when we run the same commands as a thin client session do we see the problem, and only at this particular install.

However, I tried appending "cmd.exe /c" to the front of the java command, and the fop command, and verified that it worked here at our office, both thick client on the server, and thin client from a workstation. However - it still doesn't work at the client site, and the behaviour is exactly as before. The return code from C$SYSTEM is 2 in both calls (which doesn't really help much).

We are using Extend 9.1.1 AcuRCL on server2008, clients running Win7. We have this installed in dozens of sites, with hundreds of work stations, working fine.
For one function, where we invoke saxon.jar to create an .fo file, and then use fop to create a PDF, everything works fine in a thick client session on the server. However, from all workstations running a thin client session on this one server, the command-line calls to C$SYSTEM fail with exit-status=2.

This works fine at all other customer sites, with the same configuration of server (2008) and workstations, and also with other combinations. Just at this one site, the thin client sessions fail when calling both saxon.jar, and when calling fop.bat. We CAN (and do) call other routines in the thin client session, including .EXEs on the server, without any problem.

I'm flummoxed - I've checked everything I can think of. The default user under AcuRCL has administrator priviledges, and because other calls to .EXE files work, that doesn't seem to be a problem. The folders are set to give full access to the domain users, to the built-in SYSTEM user, and to the default user set up in Acurcl.cfg. There are no errors generated in the trace file created with acurcl.

Would anyone have any ideas I could try?

Thanks

Tony

Not being an AcuCOBOL expert, I believe it is the case that the C$SYSTEM call is executing on the server, correct? Tony, it might be helpful to look in the Windows system logs on the server to see if you can find a clue there.

Also, you might write a small VBScript that does the same call and use it to debug (that is, take COBOL totally out of the picture) from a command line, using the same user profile that is being used for the COBOL app. If you can recreate the error situation, you might have more robust error messages.

We are using Extend 9.1.1 AcuRCL on server2008, clients running Win7. We have this installed in dozens of sites, with hundreds of work stations, working fine.
For one function, where we invoke saxon.jar to create an .fo file, and then use fop to create a PDF, everything works fine in a thick client session on the server. However, from all workstations running a thin client session on this one server, the command-line calls to C$SYSTEM fail with exit-status=2.

This works fine at all other customer sites, with the same configuration of server (2008) and workstations, and also with other combinations. Just at this one site, the thin client sessions fail when calling both saxon.jar, and when calling fop.bat. We CAN (and do) call other routines in the thin client session, including .EXEs on the server, without any problem.

I'm flummoxed - I've checked everything I can think of. The default user under AcuRCL has administrator priviledges, and because other calls to .EXE files work, that doesn't seem to be a problem. The folders are set to give full access to the domain users, to the built-in SYSTEM user, and to the default user set up in Acurcl.cfg. There are no errors generated in the trace file created with acurcl.

Would anyone have any ideas I could try?

Thanks

Tony

Revisiting this problem, as it has occurred again on a different server at a different customer site. It does not appear we ever resolved this in 2015 (the customer installed our application on a different server).

This customer is running Small Business Server 2011 with Win10 workstations. C$SYSTEM is running on the server, using flags=98. The symptoms are a little different - the call to run saxon.jar runs just fine in both thick client and thin client. However, the call to run fop.bat works on thick client, but fails on thin client with a return code 1 (from C$SYSTEM). The same user profile is used for both thick client and thin client sessions.

This server does have PowerShell installed, so I appended "C:\\windows\\system32\\cmd.exe /c" to the front of the command line that invokes FOP.BAT. It made no difference we will get the return code of 1 and the PDF is created, but with 0 bytes. If we run fop.bat from the command line to create the PDF using the FO file that was created by the thin client session it works fine. So, the FO file is fine, and fop.bat runs fine in thick client, but not in thin client. Because it is the same user profile used for both thick and thin clients, I can eliminate permission problems. There are NO messages appearing in any of the Windows logs (error, application, security or system).

Tom, I did not understand how to use a VB application to mimic thin client behaviour; since the problem only exhibits when running a thin-client session, we'd need to somehow mimic that.

There must be something different, somewhere, between a system call in thick client and a system call in thin client, using the same user profile. Any and all suggestions are welcome as this is a severe problem for this customer site.

Thanks

Tony

We are using Extend 9.1.1 AcuRCL on server2008, clients running Win7. We have this installed in dozens of sites, with hundreds of work stations, working fine.
For one function, where we invoke saxon.jar to create an .fo file, and then use fop to create a PDF, everything works fine in a thick client session on the server. However, from all workstations running a thin client session on this one server, the command-line calls to C$SYSTEM fail with exit-status=2.

This works fine at all other customer sites, with the same configuration of server (2008) and workstations, and also with other combinations. Just at this one site, the thin client sessions fail when calling both saxon.jar, and when calling fop.bat. We CAN (and do) call other routines in the thin client session, including .EXEs on the server, without any problem.

I'm flummoxed - I've checked everything I can think of. The default user under AcuRCL has administrator priviledges, and because other calls to .EXE files work, that doesn't seem to be a problem. The folders are set to give full access to the domain users, to the built-in SYSTEM user, and to the default user set up in Acurcl.cfg. There are no errors generated in the trace file created with acurcl.

Would anyone have any ideas I could try?

Thanks

Tony

Some additional information - it turns out the problem is multiple versions of Java on the server, but the problem is still related to thin client. When we run our application in thick client on the server, the version of Java that is run is 1.8.0, which is correct. When we run with thin client, even launching from the server, using the same account, the version of java that is invoked is version 1.5 from 2004, and it doesn't support the features necessary to render the PDF.

So, the question now is why the environment is different for thin client versus thick client, and more importantly, how do we change the environment so that the default java folder for a thin client session is the version 1.8 folder?

Thanks

Tony

We are using Extend 9.1.1 AcuRCL on server2008, clients running Win7. We have this installed in dozens of sites, with hundreds of work stations, working fine.
For one function, where we invoke saxon.jar to create an .fo file, and then use fop to create a PDF, everything works fine in a thick client session on the server. However, from all workstations running a thin client session on this one server, the command-line calls to C$SYSTEM fail with exit-status=2.

This works fine at all other customer sites, with the same configuration of server (2008) and workstations, and also with other combinations. Just at this one site, the thin client sessions fail when calling both saxon.jar, and when calling fop.bat. We CAN (and do) call other routines in the thin client session, including .EXEs on the server, without any problem.

I'm flummoxed - I've checked everything I can think of. The default user under AcuRCL has administrator priviledges, and because other calls to .EXE files work, that doesn't seem to be a problem. The folders are set to give full access to the domain users, to the built-in SYSTEM user, and to the default user set up in Acurcl.cfg. There are no errors generated in the trace file created with acurcl.

Would anyone have any ideas I could try?

Thanks

Tony

Tony, the first thing I would do is temporarily replace FOP.BAT with a script containing a single line:
SET >somefile.txt

Then run your application in both thick and thin clients, saving off somefile.txt between those runs. Then use a text editor with a difference engine (I use notepad with the Compare plugin) to look at the differences. One might hope that will expose what is happening.

We are using Extend 9.1.1 AcuRCL on server2008, clients running Win7. We have this installed in dozens of sites, with hundreds of work stations, working fine.
For one function, where we invoke saxon.jar to create an .fo file, and then use fop to create a PDF, everything works fine in a thick client session on the server. However, from all workstations running a thin client session on this one server, the command-line calls to C$SYSTEM fail with exit-status=2.

This works fine at all other customer sites, with the same configuration of server (2008) and workstations, and also with other combinations. Just at this one site, the thin client sessions fail when calling both saxon.jar, and when calling fop.bat. We CAN (and do) call other routines in the thin client session, including .EXEs on the server, without any problem.

I'm flummoxed - I've checked everything I can think of. The default user under AcuRCL has administrator priviledges, and because other calls to .EXE files work, that doesn't seem to be a problem. The folders are set to give full access to the domain users, to the built-in SYSTEM user, and to the default user set up in Acurcl.cfg. There are no errors generated in the trace file created with acurcl.

Would anyone have any ideas I could try?

Thanks

Tony

Hi, Tom;
Yes, I had done that and it revealed interesting information. What I neglected to explain in my earlier post was that the PATH displays differently for the same user when running thin client versus thick client. When running thick client, the path to the 1.8 version of Java (c:\\ProgramData\\Oracle\\Java\\Javapath) is at the BEGINNING of the PATH, whereas when running thin client, the path of the java is at the END of the PATH. I tried adding JAVA_HOME as an environment variable for that user, but that made no difference.

What I've done (temporarily) is hard-code the path to the java.exe in the fop.bat file, but obviously that's not my preferred solution. I'm hoping someone from MF can explain the different renderings of PATH (probably something simple I'm missing).

Tony

We are using Extend 9.1.1 AcuRCL on server2008, clients running Win7. We have this installed in dozens of sites, with hundreds of work stations, working fine.
For one function, where we invoke saxon.jar to create an .fo file, and then use fop to create a PDF, everything works fine in a thick client session on the server. However, from all workstations running a thin client session on this one server, the command-line calls to C$SYSTEM fail with exit-status=2.

This works fine at all other customer sites, with the same configuration of server (2008) and workstations, and also with other combinations. Just at this one site, the thin client sessions fail when calling both saxon.jar, and when calling fop.bat. We CAN (and do) call other routines in the thin client session, including .EXEs on the server, without any problem.

I'm flummoxed - I've checked everything I can think of. The default user under AcuRCL has administrator priviledges, and because other calls to .EXE files work, that doesn't seem to be a problem. The folders are set to give full access to the domain users, to the built-in SYSTEM user, and to the default user set up in Acurcl.cfg. There are no errors generated in the trace file created with acurcl.

Would anyone have any ideas I could try?

Thanks

Tony

One thing to remember is that, unless you use the SECURITY-METHOD of LOGON, the user account that is being used on the server is the SYSTEM account, not the DEFAULT-USER account. This probably has quite different settings than you expect. DEFAULT-USER is just used to decide whether a connection is allowed, and is NOT used (necessarily) as the account being run under.

We are using Extend 9.1.1 AcuRCL on server2008, clients running Win7. We have this installed in dozens of sites, with hundreds of work stations, working fine.
For one function, where we invoke saxon.jar to create an .fo file, and then use fop to create a PDF, everything works fine in a thick client session on the server. However, from all workstations running a thin client session on this one server, the command-line calls to C$SYSTEM fail with exit-status=2.

This works fine at all other customer sites, with the same configuration of server (2008) and workstations, and also with other combinations. Just at this one site, the thin client sessions fail when calling both saxon.jar, and when calling fop.bat. We CAN (and do) call other routines in the thin client session, including .EXEs on the server, without any problem.

I'm flummoxed - I've checked everything I can think of. The default user under AcuRCL has administrator priviledges, and because other calls to .EXE files work, that doesn't seem to be a problem. The folders are set to give full access to the domain users, to the built-in SYSTEM user, and to the default user set up in Acurcl.cfg. There are no errors generated in the trace file created with acurcl.

Would anyone have any ideas I could try?

Thanks

Tony

I ran into a somewhat similar issue recently. We don't use Thin Client, but our programs run on a number of Windows 2012 servers - sometimes via Citrix (which does load balancing across the servers) and sometimes via batch jobs or run manually from an RDP-connected desktop. What I needed to do was call a 3rd-party .bat file using C$System. This .bat file, in turn calls one or two other .bat files and ultimately an .exe, all provided by the 3rd-party package (it's ps2pdf.bat, part of the Artifex Ghostscript package). Because of these downstream calls, it needs two separate entries in the PATH. But when I called it, it would silently fail, with no error message, error code, syslog entries, etc. I had set my needed PATH entries in both the User and System environments on my test server, to no avail. I tried something similar to what Tom suggested, and the resulting PATH values looked correct - but I still didn't have a working solution or any clue why it was failing.

Another wrinkle for me was that some of the servers had different versions of the Ghostscript software, so the required PATH would differ (the version number was part of the actual installation location).

Here's what I ended up doing, and it's been working well for several months:

Query the Windows Registry to see what version of Ghostscript is installed, and get the path to the installed location (use the runtime's REG_xxx routines for this).
Use STRING to create the needed PATH entries based on the above:
- String GS-Install-Dir, "/bin" ... into GS-Bin-Path
- String GS-Install-Dir "/lib" ... into GS-Lib-Path
Define a temporary bat file (Line Sequential, with a SELECT and FD - I think I used a 300-char record size just to be safe)
Generate a unique name for it, then do an OPEN OUTPUT (in my case, each session is already running in a well-defined temporary session directory, so that's where the file goes)
String together SET statements using the path values generated above, and write them to the temporary bat file:
- Move spaces to Temp-Bat-Record
- String "SET PATH=", GS-Bin-Path, ";%PATH%" ... into Temp-Bat-Record
- Write Temp-Bat-Record
- Move spaces to Temp-Bat-Record
- String "SET PATH=", GS-Lib-Path, ";%PATH%" ... into Temp-Bat-Record
- Write Temp-Bat-Record
String together the actual call to ps2pdf.bat (Literal-Quote is a standard level-78 in a common copybook):
- Move spaces to Temp-Bat-Record
- String Literal-Quote, GS-Lib-Path, "/ps2pdf.bat", Literal-Quote ... into Temp-Bat-Record
- Write Temp-Bat-Record
- Close Temp-Bat-File
Call the temporary bat file using C$System:
- String Literal-Quote, Temp-Bat-filename, Literal-Quote ... into Sys-Cmd-Line
- Compute Sys-Cmd-Flags = Csys-Hidden Csys-Shell
- Call "C$System" using Sys-Cmd-Line, Sys-Cmd-Flags giving Sys-Cmd-Status
Delete the temporary bat file using C$Delete

You can probably adapt the above steps to your situation. You may need to add a line in the temp bat file to SET JAVA_HOME=(path to Java install dir).

Sign up

Please log in or register:

Welcome to the Rocket Forum!

Please log in or register:

Scanning file for viruses.

This file cannot be downloaded