Setting up a terminal server based application for a client brought up an interesting issue recently. The basic outline is a windows 2003 terminal server with HP thin clients on the shop floor with dustproof keyboards as mentioned here.
The production MIS application runs off a unix system with a windows front end located on another Windows server. The application normally requires local installation of a “shim” – a small basic core of the application with some additional registry entries for various component registrations. Some windows fonts are required to be installed for operation of a reporting module and finally a windows shortcut dictates how the application launches with various switches on the command line colouring what functionality the user gets.
The issue arose – How to configure the application differently for each of the machines that were to be configured as Data Capture Units – i.e where the users input data about the current and completed jobs that the machine they are on has. Therefore this “profile” for each machine needs to have some means of indicating this.
The client had investigated the mechanism before and had been looking for either a command line switch or .ini file setting that could be used to control the behaviour. The supplier hadn’t given them any other information other than the creation of various folders as part of the standard installation – which basic meant three flavours of access – different for three types of user.
It was watching the client going through the process of creating a DCU profile – which actually amounted to an error that appears when the program is first run – followed by the entry of the appropriate details for a precreated user account and other info – which resulted in the creation of a file called p_dcuno.d which contained one line with the details just entered – that gave me a clue.
Looking at the three directories containing the “3 flavours” of user setup” – noting that none of them had any files updated whilst the changes where made – other than this one line file and checking the shortcuts that were available – I noticed that the difference between them was not the command line or the switches – rather the Working directory property of the shortcut.
To prove that this was the actual mechanism by which the program was able to read the DCU file and thus decide who was logging in – we created a fourth folder from one of the three already there – copied one of the shortcuts – and then changed its working directory to point at the fourth setup folder – and just to confirm it operated the same as the others when first run – deleted the DCU file in it.
Running the program from the shortcut – generated the error regarding the missing dcu file – allowed us to enter new details and once saved – allowed us to start the application with a new fourth set of details.
So its worth remembering that the working directory can still be beneficial as it was back in the early days of networking windows and storing data on network servers …. and thanks to Steve for the info that lead us there.