TC14 Install Admin Guide
TC14 Install Admin Guide
No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.
1.1 Introduction
The TCServer (java version) is a product which lets an external client program to link to the standard
TEMENOS GLOBUS module OFS (Open Financial Services). The TCServer offers different way to
connect to TEMENOS GLOBUS and T24, like MQSeries ,TCP, SSL,... Used in conjunction with the
TCClient API (Available in java and C++, and offering a COM (Component Object Modeling) layout, it
has never been easier to connect to TEMENOS GLOBUS and T24. This document will explain how to
install the TCServer (java) and will details how to configure it.
1.3 Prerequisites
The java TCServer has been developed on top of TEMENOS GLOBUS & T24 for jBASE. The java
TCServer supports TEMENOS GLOBUS 12.1 onwards and T24.
TEMENOS GLOBUS releases prior than the 13.1, need the installation of some additional subroutines
in order for the TCServer to run correctly.
These subroutines are:
- GLOBUS.INITIALISE
- GET.ENV.JBASE
- OFS.INITIALISE.SOURCE
- tSS
If you are not sure whether these subroutine are already deployed or not, type:
$ jshow <subroutine name>
If the result is a full path to a library, this means that your jBase can find this subroutine, otherwise,
contact your Temenos Representative to get the latest versions.
A java Virtual Machine (JRE) version 1.4.1 or above should be installed. To test it, type:
$ java –version. Note that some problems can occur depending the java VM and the platform.
Please refer to the Temenos HelpDesk in order to be sure that there is no known problems with some
specific VM.
The TCServer has been deployed and tested on the following platforms:
As far as your server has a java VM, the TCServer should run properly.
SOURCE.NAME....... TCS
-------------------------------------------------------
1 DESCRIPTION....... OFS ONLINE MODE
2 SOURCE.TYPE....... TELNET
3. 1 LOGIN.ID....... any
4. 1 EB.PHANT.ID....
5 MAX.CONNECTIONS... 11
6 RESTRICT.LINK.....
7 INITIAL.ROUTINE...
8 CLOSE.ROUTINE.....
9 IN.MSG.RTN........
10 OUT.MSG.RTN.......
11 MSG.PRE.RTN.......
12 MSG.POST.RTN......
13 LOG.FILE.DIR......
14 LOG.DETAIL.LEVEL.. NONE
15 OFFLINE.QUEUE.....
16 MAINT.MSG.DETS....
17 DET.PREFIX........
18 IN.QUEUE.DIR......
19 IN.QUEUE.NAME.....
20 OUT.QUEUE.DIR.....
21 OUT.QUEUE.NAME....
22 QUEUE.INIT.RTN....
23 QUEUE.CLOSE.RTN...
24 SYNTAX.TYPE....... OFS
25. 1 LOCAL.REF......
26 GENERIC.USER...... INPUTTER
27 IN.DIR.RTN........
28 VERSION...........
29 IB.USER.CHECK.....
30 EOD.VALIDATE......
31 FIELD.VAL.........
32. 1 ATTRIBUTES.....
33 RESERVED1.........
34. 1 OVERRIDE.......
35 RECORD.STATUS.....
36 CURR.NO........... 16
To have more details about setting up OFS, please refer to the Chapter 43 of the TEMENOS
GLOBUS Help. The field 2 (SOURCE.TYPE) is set to “TELNET”. However, the TCServer is not using
telnet at all ! This is to specify that we will have online (and not batch) data coming.
$ tSS TCS
An alternative way is to make sure you have an environment variable called OFS_SOURCE set up to
the value of the Record ID of the table OFS.SOURCE (in our example : “TCS”)
$ export OFS_SOURCE=TCS
then type:
$ tSS
So far, so good, you are ready to deploy the TCServer. To quit the test type: “exit”
If you received a jar File and a Setup.sh (or Setup.bat), just copy these files wherever you want, and
execute the script. You will be prompted to enter the path where you want to install the TCServer, the
Path where TEMENOS GLOBUS is (xxx.run), the Path where you version of jBASE is and the
OFS.SOURCE record ID you want to use. Note that this setup is only deploying files in the install
directory. This means that you don’t need any special privileges to install it apart from write access to
this directory. For Windows, there is NOTHING going in the registry. If you want to uninstall, just
delete the whole directory !
However, if you wish to install the NT Service (in the ./bin path), you will need to have write access to
the Registry. The removeService.bat will remove any entry.
========================================================
. Welcome to the Installation program of the .
. TEMENOS Connector Server. .
. To successfully install your program, you will need .
. to provide 3 informations : .
. - The Path where you want to install it. .
. - The Path where your GLOBUS/T24 is (xxx.run) .
. - The Path where your jBASE is. .
. - An OFS.SOURCE Record ID .
========================================================
. . .
Once installed, you will find 2 files (TCServer.bat and TCServer.sh) in your /bin directory. Just execute
it (.bat for windows, .sh for Unix/Linux) to start your server. On unix, you maybe wish to change the
right of this file.
This doesn’t mean that we don’t have to care about the environment variables anymore. The fact is
that since we can connect to multiple TEMENOS GLOBUS, each of them running on the same or
different versions of jBASE, the environment variables are listed in the format VARNAME=VALUE in a
separate file.
This file is located in the /conf Directory. The file name is environment.vars. There is 2 different
supported format for this file. The default one has the tags <unix></unix><win32></win32>.
Depending the platform you are running on, the values listed in <unix> or <win32> will be used. The
second format contains only the “name-values” pair. This means that you can, if necessary, pipe the
result of an “env” (unix) or “set” (win32) to this file. Environment variables is the biggest cause of
trouble in the deployment. A safe (but not recommended) way is to make sure OFS is running (see
previous section), and then, from the same session, “piping” all environment in the “environment.vars”
file. Thus, you ensure that the GC will start OFS sessions exactly the same way you tested it.
By default, this file contains “tags” like “<GLOBUSPATH>, <JBASEPATH>, … These tags are
substituted on the fly by the values specified in the tcserver.xml file. Even if you choose to “pipe” your
environment, you can always edit this file and add these special tags instead of having “hardcoded”
path.
<unix>
JBCRELEASEDIR=<JBASEPATH>
JBCGLOBALDIR=<JBASEPATH>
JBCOBJECTLIST=<GLOBUSPATH>/globuspatchlib:<GLOBUSPATH>/globuslib:<GLOBUSPATH>/lib
LD_LIBRARY_PATH=<JBASEPATH>/lib:/usr/ccs/lib:/usr/lib
LIBPATH=<JBASEPATH>/lib:/usr/ccs/lib:/usr/lib
SHLIB_PATH=<JBASEPATH>/lib:/usr/ccs/lib:/usr/lib
JEDIFILEPATH=<GLOBUSPATH>
JBCLISTFILE=<GLOBUSPATH>/&SAVEDLISTS&
JBCSPOOLERDIR=/usr/jspooler
JEDIFILENAME_MD=VOC
JEDIFILENAME_SYSTEM=<GLOBUSPATH>/SYSTEM
PATH=<JBASEPATH>/bin:/usr/local/bin:<GLOBUSPATH>/globuspatchbin:
<GLOBUSPATH>/globusbin:<GLOBUSPATH>/bin
JBCBASETMP=<GLOBUSPATH>/workfile/tmp_$$
JBCEMULATE=prime
JBASE_WARNLEVEL=30
JBASE_INHIBIT_ZERO_USED=1
JEDIENABLEQ2Q=1
JBASE_CODEPAGE=utf8
JBASE_I18N=1
OFS_SOURCE=<OFSSOURCE>
</unix>
<win32>
JBCRELEASEDIR=<JBASEPATH>
JBCGLOBALDIR=<JBASEPATH>
JBCOBJECTLIST=<GLOBUSPATH>\globuspatchlib;<GLOBUSPATH>\globuslib;<GLOBUSPATH>\lib
JEDIFILEPATH=<GLOBUSPATH>\
JBCLISTFILE=<GLOBUSPATH>\&SAVEDLISTS&
JBCSPOOLERDIR=<JBASEPATH>\jspooler
JEDIFILENAME_MD=VOC
JEDIFILENAME_SYSTEM=<JBASEPATH>\src\SYSTEM
PATH=<JBASEPATH>\bin;<GLOBUSPATH>\globuspatchbin;<GLOBUSPATH>\globusbin;
<GLOBUSPATH>\bin
JBCBASETMP=<GLOBUSPATH>\tmp_workfile
JBCEMULATE=prime
JBASE_WARNLEVEL=30
JBASE_INHIBIT_ZERO_USED=1
JEDIENABLEQ2Q=1
JBASE_CODEPAGE=utf8
JBASE_I18N=1
OFS_SOURCE=<OFSSOURCE>
</win32>
If you are running only one instance of T24/jBASE per TCServer, the safest way is to not use
environment.vars, but to start the TCServer AFTER having set the different environment variables
(running . ./.profile in xxx.run). The procedure is quite simple :
a) Rename (or remove the file environment.vars)
b) Go to your T24 run directory (xxx.run) and start .profile (. ./.profile)
c) Do not start Globus, and DO NOT start jShell (jsh). You maybe will need to prompt “START
JSH Y/N”
d) Cd to the bin directory of the TCServer
e) Run TCServer.sh (. TCServer.sh)
In that situation, you GARANTY that the sessions spawned by the TCServer are running exactelly as if
you where typing yourself the TSS command. (See chapter “Testing OFS”)
In this chapter, we will concentrate on one file: tcserver.xml. This file contains all the configuration
parameters of the TCServer. This is certainly the only file you will have to concentrate on. So read this
chapter carefully ! This file is located in the ./conf directory. Since the version 1.2.04, this file changed
completely to be compliant with a schema definition allowing a pre-validation and the auto-defaulting
for some specific tags.
<TCSERVER>
<MESSAGEFORMATTERS>
. . . MESSAGEFORMATTERS are used to format
</MESSAGEFORMATTERS> (change) the requests and / or the responses.
<ADAPTERS>
. . . ADAPTERS are defining how to connect to
. . . T24 / TEMENOS GLOBUS. You can specify
</ADAPTERS> the link to the message formatters here.
<LISTENERS>
. . . The LISTENERS are defining how the External
</LISTENERS> world will connect to the TCServer (W.
MQSeries, TCP, SSL, …..).
</TCSERVER>
As LISTENERS and FORMATTERS are “plug-ins” (see “Guide for writing a plugin.pdf”), we will not
give the details of these 2 blocks here. Instead, you will find documents called “PI-<plugin_name>.pdf”
in the /doc directory explaining separately how to configure the different plug-ins.
<TCSERVER>
<!-- JMXRmiPort is the port the TCServer will use to comunicate with the JMX TCManager.
Optional -->
<JMXRmiPort>1099</JMXRmiPort>
<!-- MONITOR_PORT is the port the TCServer will listen on for the TCMonitor. Optional, but
recommended. -->
<MONITOR_PORT> 9500 </MONITOR_PORT>
<!-- TELNETD_PORT is the port the TCServer will listener on for the telnet deamon. Optional --
>
<TELNETD_PORT> 9501 </TELNETD_PORT>
<!-- DEBUGGER_PORT is the port the TCServer will listener on for the remote debugger. If you
telnet on that port, and you send a request FROM THE SAME CLIENT and you basic program enter
the debugger, any debugger input / output will be redirected to your telnet session. -->
<DEBUGGER_PORT> 9502 </DEBUGGER_PORT>
<!-- SPY_PORT is the same principal than the DEBUGGER, but for ALL Input / Output. -->
<SPY_PORT> 9503 </SPY_PORT>
<!-- The STACKEXPIRATION defines how long the TCServer will keep a response in the stack
before removing it. It can happen in an asynchronous communication, if the client don’t come
to fetch the response. -->
<STACKEXPIRATION>120</STACKEXPIRATION>
<!-- SCALEDOWNSPEED defines the speed the TCServer will scale down the Sessions. For example,
if there is suddenly a lot of requests to be processed, the TCServer will scale up to a
maximum of session (See Adapter definition). Then, once there is no more request, it will
slowly remove session after session. This value defines the frequence for removing the session
(in secondes) -->
<SCALEDOWNSPEED>30</SCALEDOWNSPEED>
<!-- If a message is encrypted with the library encryption.jar (DES III), the TCServer can
detect it an decrypt / encrypt the message on the fly. This tag defines where the encryption
key is. -->
<ENCRYPTION_KEY>key</ENCRYPTION_KEY>
<!-- The HEARTBEAT block contains information for the TCServer to send a specific message to
the T24 Session on a Regular basis. The message to send can be defined, same for the expected
response. If the response received doesn’t match the expected one (following the pattern :
“does the response START with the expected answer”, an error is logged. The FREQUENCY tag
indicates (in secs) how often each adapter thread should send a Heartbeat message. Note that
this functionality has absolutally no priority on any messages. This means that if there are
messages to process, even if the periode for sending a Heartbeat message has been reached, it
wont. -->
<HEARTBEAT>
<FREQUENCY>30</FREQUENCY>
<MESSAGE>XXX</MESSAGE>
<EXPECTED_ANSWER>EB.RTN.APP.MISS.2</EXPECTED_ANSWER>
</HEARTBEAT>
<MESSAGEFORMATTER id="PrefixAppender.2">
<CLASS>com.temenos.formatter.PrefixAppender</CLASS>
<PREFIX>This is the response :</PREFIX>
</MESSAGEFORMATTER>
</MESSAGEFORMATTERS>
<!-- This session lists all the Adapter. Each adapter is a plug-in, thus described in it’s own
documents. However, all adapters have few common tags. There are described here.-->
<ADAPTERS>
<!-- Each adapter must have a unique id. This id will be defined in the listener to know how
to process the incoming message. The type must be compliant with the type of the plugin (see
specific documentation). The default value of the tape is “OFS” -->
<ADAPTER id="T24" type=”OFS”>
<!-- This tag lists all the formatters the message must go through before beeing send to the
adapter itself. Each formatter (if many) must be separated by a coma (“,”) eg : “Cp838toUTF8,
OFSML, UTF8ToCp838”. UTF( is a “build-in” formatter, and there is no need to specify it (the
TCServer will detect if the message is in OFSML) unless you want the formatting to occurs in a
specific sequence. -->
<REQUEST_FORMATTER>PrefixAppender</REQUEST_FORMATTER>
<!-- Same formatter processing for the response. -->
<RESPONSE_FORMATTER>PrefixAppender.2</RESPONSE_FORMATTER>
<!-- Maximum of session to “spawn” -->
<MAX_SESSION> 5 </MAX_SESSION>
<!-- Minimum of session to “spawn”. This is the initial value when you start your TCServer. -
->
<MIN_SESSION> 1 </MIN_SESSION>
<!-- The remaining is dependent of the adapter definition. Please refer to the specific
document (Starting with “PI-“ -->
<TIMEOUT>30</TIMEOUT>
<STARTIN>C:\globus\14000\mbdemo.run</STARTIN>
<JBASEPATH>C:\jbase4.1.3</JBASEPATH>
<PROGRAM>T24</PROGRAM>
<PARAMETER>GCS</PARAMETER>
</ADAPTER>
</ADAPTERS>
<LISTENERS>
<!-- Each listener have a unique id (can be “name”). The type must match the type of the plug-
in (see specific documentation). Active = “true or false” indicates if this listener must be
activated at startup or not. -->
<LISTENER id="Browser.1" type="tcp" active="true">
<!-- Must be an existing adapter (defined in the previous section). Note that is an adapter
has no listener associated, it will simply not start. -->
<ADAPTERID>T24</ADAPTERID>
<!-- The remaining is dependent of the listener definition. Please refer to the specific
document (Starting with “PI-“ -->
<PORT> 7001 </PORT>
</LISTENER>
</LISTENERS>
</TCSERVER>
The tcserver.xml file can also be edited with a graphical utility. With this utility, you can edit a local
tcserver.xml file or a distant one. In the case of a distant file, you must have the TC Server running on
the distant machine and the JMX-RMI enabled. All you need to provide is a host name or address and
the "JMXRmiPort" of the distant machine.
The image below, show the TCSConfig main window. With this utility you can edit, delete, copy paste
all the TC Server configuration objects without manipulating an XML tag.
1.10 HeartBeat
As described in the previous chapter, there is the possibility to set a Heartbeat facility for the
TCServer. This function will send on a regular basis a request to the adapter (only if inactive) and will
evt. Log an error if the result doesn’t match the expected one. By making a Heartbeat request which
uses the T24 Database (like a simple enquiry), it will allow the TCServer to log an exception if the
database becomes unavailable …
There is also the possibility to query the TCServer to get all the Heartbeat informations.
By sending the request “HEARTBEAT” (upper case), the TCServer will interrupt it and send the actual
result of all the heartbeat messages, grouped by adapters, like this :
<HeartBeat>
<Adapter name="T24">
<Session nb="1">
<StartTime>2004-12-07 15:08:50.818</StartTime>
<LastHitTime>2004-12-07 15:16:40.934</LastHitTime>
<NbHit>2</NbHit>
<TotalUsage>220</TotalUsage>
<LastHeartBeatHost>2004-12-07 15:16:36.137</LastHeartBeatHost>
<HeartBeatHost>OK</HeartBeatHost>
</Session>
</Adapter>
</HeartBeat>
The request “HEARTBEAT” is not compliant with OFS, so the TCServer will also recognize such a
request :
“HEARTBEAT,,./.,,” which is compliant with the OFS specifications.
If you want to ask for the Heartbeat via OFSML, the request will look like this :
<?xml version="1.0" encoding="UTF-8"?>
<Globus xmlns="http://www.temenos.com/GLOBUS/OFSML/120"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.temenos.com/GLOBUS/OFSML/120 ../../xsd/ofsml.xsd">
<ofsmlHeader>
<correlationId>001100110011</correlationId>
</ofsmlHeader>
<serviceRequest>
<securityContext>
<userName>.</userName>
<password>.</password>
</securityContext>
<ofsXMLRoutine name="HEARTBEAT">
<HEARTBEAT xmlns = "http://www.temenos.com/GLOBUS/OFSML/120/heartbeat"
xsi:schemaLocation = "http://www.temenos.com/GLOBUS/OFSML/120/heartbeat
../xsd/heartbeat.xsd"/>
</ofsXMLRoutine>
</serviceRequest>
</Globus>
If your formatter is a REQUEST formatter, response will be null. Whatever you will return back will
replace the request.
If your class is a RESPONSE formatter, both the original request and the response will be passed.
The response will be replaced by whatever you will return back.
import com.temenos.messageformatter.*;
import java.io.*;
baos.write(VM);
i++;
} else {
baos.write(request[i]);
}
In addition, you can know, from your formatter, where the request is coming from, and what adapter is
calling you. This can be done using the class Formatter (super…) like this :
You also can get any custom parameter (Tags) like this :
<MESSAGEFORMATTER id="MY_FORMATTER">
<CLASS>com.temenos.formatter.TestFormatter</CLASS>
<MYPARAM>Hello World</MYPARAM>
</MESSAGEFORMATTER>
You can retrieve the value of the tag <MYPARAM> like this :
String sParam = super.getParam(“MYPARAM”);
You also can decide to cancel this call. This means that the request will not (!) be sent to
T24/GLOBUS. In that scenario, if you defined a RESPONSE formatter, it will be invoked with a null
response …. Remember that you can override this response by just returning anything you want from
the method format().
super.setCancelCall(true);
In order that the TCServer finds your classes, they need to be deployed in the directory “ext”. For
example, our previous sample (CRLFtoVM.class) needs to be located in
<tcserver_install_path>/ext/com/temenos/formatter (“com/temenos/formatter” is the package name).
If you don’t want to deploy it in that directory, or if you made a jar file, you will need to add this jar in
the classpath.
This is possible to specify multiple formatters. In that case, you just separate them with a coma (“,”) in
the specific ADAPTER like this :
<ADAPTER id="13101">
<REQUEST_FORMATTER> CP838_TO_UTF8, OFSML, UTF8_TO_CP838 </REQUEST_FORMATTER>
<RESPONSE_FORMATTER> CP838_TO_UTF8, OFSML, UTF8_TO_CP838</RESPONSE_FORMATTER>
<MAX_SESSION> 1 </MAX_SESSION>
<MIN_SESSION> 1 </MIN_SESSION>
<OFSTIMEOUT>30</OFSTIMEOUT>
<GLOBUSPATH>c:\globus\13101\mbdemo.run</GLOBUSPATH>
<JBASEPATH>C:\jBase4.0.4.3</JBASEPATH>
<OFSENTRY>TSS</OFSENTRY>
<OFSSOURCE>GCS</OFSSOURCE>
</ADAPTER>
As you can see in the above example, we are “chaining” different formatters. The formatter “OFSML”
is a special one, and doesn’t need any definition in the <MESSAGEFORMATTERS> tag. This
formatter will convert OFSML to OFS for the request, and OFS to OFSML for the answer.
Of course, this is assuming that the class CP838TOUTF8.class and UTF8TOCP838.class are in the
directory <tcserver>/ext/com/temenos/formatter/.
This example assume that the incoming message is encoded in CP838. Because the OFSML parser
doesn’t support this charset, we say to the ADAPTER to :
1) Convert the message in UTF8
2) Parse the message (assuming this is OFSML)
3) Convert it back in Cp838 before sending it to T24.
import com.temenos.messageformatter.*;
This would be much more convenient to use the getParam() method for this situation. Here is another
sample MessageFormatter which format the message from any charset to another :
package com.temenos.formatter;
import com.temenos.messageformatter.*;
1.12 TCMonitor
You have the possibility to manage your server via telnet. To do so, just telnet your machine with the
correct port number. You can change the port the TCServer is listening on by changing the tag
<TELNETD_PORT> in the jTCServer.xml file (check the previous chapter). If you choosed to not
specify anything in the <TELNETD_PORT>, the TCServer will simply not start the telnet Deamon.
------------------------------------------------------------------------
GCServer Telnet Deamon V. 1.0
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
The TCServer uses the log4j tracing API. This API is well described on the log4j website
(http://jakarta.apache.org/log4j).
The configuration file we are using for the tracing is tcslog.properties (in the conf directory). The
tracing level should be set to “ERROR” once everything’s up and running. During the deployment
phase, the “DEBUG” or “ALL” level are the suggested one. (see the “troubleshooting chapter”).
Remarks: With the TCServer 1.4 version, Category is replaced by Logger in properties files.
In TC 1.4 distribution, you will find tlog4jappenders jars with three new Temenos log4j appender.
This appender sends the message to a registred MBean server (as a JMX notification). This appender
does not require a layout information because the structure of the message is pre-defined. The
properties for this appender are :
Remark: log.properties file must not copied to 1.4 version from 1.3. We don’t support old Category
Log4j object.
1) An OFSERROR_PROCESS.
2) An OFSERROR_TIMEOUT.
1.16.1 OFSERROR_PROCESS
This error is due to the process being spawned by the TCServer (tSS) to terminate unexpectedly. In
that situation, the TCServer will detect it and return the message “OFSERROR_PROCESS”. This error
will also being return if the process enter the debugger. However, if you have a debugger session
attached to your request, the pipes will be redirected to your debugger client. If you make a “continue”
(“C”) on the debugger, the process will continue as normal. If you make a “quit” (“Q”), then the process
will die, and the TCServer will return an “OFSERROR_PROCESS”. On platforms having a TTY (UNIX,
LINUX but not Win32, AS400), this is important to set the environment variable JBASE_DEBUG_PIPE
to “1”. Otherwise, if a process enters the debugger, the debugger will be redirected to the TTY instead
of STDOUT. In that case, the TCServer will never detect it and will timeout.
1.16.2 OFSERROR_TIMEOUT
In the settings of your adapter (tcserver.xml), you specified a timeout value. This tells to the TCServer
after how many seconds it should stop waiting for an answer, and return an “OFSERROR_TIMEOUT”
message. This error can be found in many situation. This could be a “real” timeout. This means that
everything is fine, but too slow. The TCServer will give up waiting and kill the process and restart one
“fresh”.
This also could be that the process (tSS) got a problem (dead lock, entered accidentally to an
interactive mode (waiting for a user input, …).
1.17 Troubleshooting
The only problems in the deployment of the java TC Server are due to
a) A bad configuration of OFS.
b) A bad starting Script (TCServer.sh or .bat)
This is important to verify if OFS is running correctly. Log on to your server, at the prompt Start
GLOBUS Y/N answer NO, and then just type “tSS GCS”. Note that “GCS” is the OFS.SOURCE record
ID you whish to use.
If you receive a message like :
<tSS verrsion="1.0"> <t24version>G15.0.02</t24version> <t24ofssource>GCS</t24ofssource> </tSS>
this means OFS is running. Type an enquiry in the OFS Format :
ENQUIRY.SELECT,,INPUTT7123456,CURRENCY-LIST
Another way to verify that everything’s fine is to change the tcslog.properties file (in your conf
directory) to redirect the tracing to the console (instead of a file) and to activate all tracing.
Like this :
#####################################
# Technology & Research Dep.
# Log file configuration
#
# TEMENOS (c) 2003
#
# This file contains configuration
# parameters for the log4j logger.
#
# Log Level = OFF, FATAL, ERROR, WARN, INFO, DEBUG
#
# Note :The 'File' must have only slashes '/' and never backslashes '\'
#
#####################################
log4j.rootLogger=FALSE
log4j.logger.common=ALL, file,console
log4j.logger.tcs=ALL, file,console
log4j.logger.ofs=ALL, console
log4j.logger.tcp=ALL, file,console
By doing so, restart your server, and you will have plenty of messages …
===========================================================
java GCServer version 1.1.1
First of all, don’t worry about the log4j warnings …. We should have remed-out all the line concerning
the FileAppender in the jgcslog.properties file.
Then concentrate on the highlighted lines : If you have it, you can be 100% sure your TCServer can
connect to GLOBUS and is up and running!
If you don’t have these lines, but you can make the precedent test (Typing TSS), this means that the
environment variables are wrong in the environment.vars.
If this is still not working, there is one more known cause : The version of your VM. Type java –
version. If your version is less than 1.3.1, this means that java cannot execute a binary in another
directory than the current one. In that situation you should upgrade your java VM. However, there is
the possibility to copy your entire install directory (the one where TCServer.sh is in your xxx.run
directory. Then, you duplicate (and rename) the script .profile (jProfile.bat), and add the java –jar
<currdir>\lib\TCServer.jar.
On OS390, you MUST be in the xxx.run directory when starting the tcserver. One way of doing is to
copy the TCServer.sh file in the xxx.run directory, and edit it to change the path to the tcserver.jar like
this :