ASP Support

Connection Manager ASP Support

The Connection Manager has support for ASP/VSP systems. This is done by defining each ASP system in a service within kconf.xml. The service would define its own value of SYSTEMID so that it has its own private $PSTAT area and licence file.

To ensure security, each service should define its own private valid user, valid client and admin user access control lists. This will prevent users from one ASP service from accessing data from other ASP services.

Each application <service> can also execute a specific installation of KCML from a different directory, instead of the KCML executable from the same directory as the Connection Manager. The standard kconf.xml configuration needs to be changed as follows:-

Define a <general> environment variable to store the default KCML directory, for example ASP_KCML_DIR.
Change the web services table to execute $ASP_KCML_DIR/kiodbc & $ASP_KCML_DIR/kcml for the kisam & kcml services respectively.
The application's <service> should redefine ASP_KCML_DIR environment variable to the alternative KCML directory.
Applications that do not require a different KCML installation do not need to redefine the ASP_KCML_DIR environment variable.

This is illustrated by the following kconf.xml fragments :-

<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE kconf SYSTEM "kconf.dtd" >
<kconf>
	<general>
		<environment>
			<variable>
				<!-- Default KCML directory -->
				<name>ASP_KCML_DIR</name>
				<value>$KCMLDIR</value>
			</variable>
			<!-- ... remainder of general environment block ... -->
		</environment>
	</general>
	<services>
		<service>
			<name>LiveApp</name>
			<!-- description, type, catalogue tags etc -->
			<environment>
				<variable>
					<!-- Use alternative KCML directory -->
					<name>ASP_KCML_DIR</name>
					<value>/usr/local/liveapp/kcml</value>
				</variable>
				<!-- ... remainder of service's environment block ... -->
			</environment>
		</service>
		<service>
			<name>TestApp</name>
			<!-- description, type, catalogue tags etc -->
			<environment>
				<variable>
					<!-- Use alternative KCML directory -->
					<name>ASP_KCML_DIR</name>
					<value>/usr/local/testapp/kcml</value>
				</variable>
				<!-- ... remainder of service's environment block ... -->
			</environment>
		</service>
		<!-- ... other services ... -->
	</services>
	<kweb_services>
		<kweb_service>
			<name>kisam</name>
			<program>$ASP_KCML_DIR/kiodbc</program>
		</kweb_service>
		<kweb_service>
			<name>kcml</name>
			<program>$ASP_KCML_DIR/kcml</program>
		</kweb_service>
	</kweb_services>
</kconf>

Each KCML installation should share a single kconf.xml configuration file. This can be done by using the ln -s command to symbolically link the Connection Manager's kconf.xml into the other KCML directories. Using the above kconf.xml fragments as an exmaple and assuming the Connection Manager has been installed into /usr/local/kcml

$ ls -l /usr/local/kcml/kconf.xml
-rw-r--r-- 1 root bin 19283 Feb 19 16:51 /usr/local/kcml/kconf.xml
$ ls -l /usr/local/liveapp/kcml/kconf.xml
lrwxrwxrwx 1 root bin 25 Apr  9 09:58 /usr/local/liveapp/kcml/kconf.xml -> /usr/local/kcml/kconf.xml
$ ls -l /usr/local/testapp/kcml/kconf.xml
lrwxrwxrwx 1 root bin 25 Apr  9 09:59 /usr/local/testapp/kcml/kconf.xml -> /usr/local/kcml/kconf.xml

Starting background processes

Startup and shutdown scripts, as referenced by /etc/inittab, /sbin/init.d or /etc/rc*.d, on ASP systems can be quite complex. Scripts of this type are usually used to

bkstat -x, -y

global library processes

Remote Licence deamon

These scripts may also wish to use environment variables that are set in a service's environment, which would be hard to implement using script commands.
To simplify the management of the environment the Connection Manager can be used to initialize a service.
The service needs to specify an Startup script in kconf.xml. This is the location of a shell script which contains the necessary commands for starting service-specific programs, ect. The ASP server's boot script can then call kwebserv using the -s and -i command line flags. When executed in this mode, kwebserv will load the environment from the general and service sections of kconf.xml. The Startup script is then executed with the remaining command line arguments that were passed to kwebserv.

For example, if we have a service called Accounts, which defines an Startup script of /user1/accounts/scripts/start.ksh
The server's boot script could contain a command of the form

kwebserv -s Accounts -i start

After loading the environment for the Accounts service, kwebserv would execute the command

ksh /user1/accounts/scripts/start.ksh start

The shell interpreter that is used, in this case ksh, to execute the script is determined by the value of $SHELL or $SH. If neither of these environment variables are set, then a default of /bin/sh is used. If the script produces any output, then this is displayed.
After the script has been executed, kwebserv will print a message containing the command and its return code.

kwebserv: Info: /user1/accounts/scripts/start.ksh start returned 0

These messages, along with any script output, can be redirected to a log file, ie

kwebserv -s Accounts -i start >/user1/boot.log 2>&1

Alternatively, if no -s Service flag is used, then kwebserv will enumerate over all services. In this mode kwebserv will execute a command of the form

kwebserv -s servicename -i argmuents

for each service in kconf.xml. This eliminates any need to write shell script code to enumerate all available ASP systems.

Starting background processes

See Also: