TUniverse Tech Company

Training Note
 JBS1
The architecture.
First, we introduce T24 architecture to you. There are 4 different levels in
T24 architecture.
(1) Operating system – no matter it is Unix or Windows.
(2) jBase run time environment – I would like to call this as jBase platform
rather than jBase run time. It provides several facilities to T24.
Including jBase utilities & jBase drivers & jBase database. So please
don’t treat jBase as database only.
(3) T24(Application) – to implement T24 utilities and business logics.
(4) User – this is so called the client (including GLOBUS desktop &
browser)
Logging onto jBase.
This is different from logging onto T24. Basically the logging procedure is
that.
Step1. To log onto jBase.
Step2. To log onto T24.(for desktop or classic)
For browser, the web server will log automatically for clients. – It is
transparent for browser user.
jBase logging workshop.
Please try to log onto our training server by classic mode (AnzioWin).
Step1: input the user id and password same as the ones on the white
board.
Step2: You may see a line to ask you whether you want to start T24 or
not – please choose N.
Step3: Now you are going to jShell. – only log onto jBase runtime.
Step4: type EBS.TERM to set up terminal mode as Ansi-colour.
Step5: type ‘EX’ to log onto T24.
Now you already know the difference between jBase runtime and T24
application.
jBase Directory Structure.
There are 5 major directories for jBase run time.
First is bin.Second is config.Third is lib.Forth is tmp.The last one is dev.
Jspooler is the directory related to printer. We will introduce the jspooler in
the printer set up session.
Lib – in Unix we use shared object instead of dynamic link library. That is
similar concept. The shared object and dynamic link library only are loaded
TUniverse Tech Company http://www.tuniversetech.com
Room 9, 8F., No.42, Songjiang Rd., Jhongshan District, Taipei City 104, Taiwan
(R.O.C.)
Page 1 of 3
 TUniverse Tech Company
Training Note
into memory at runtime.
jRLA jBase record lock arbiter.
There are two kinds of locking mechanism in jBase. One is the OS locking
and the other one is jRLA. If jRLA is not running, and then the jBase will
use OS locking. Since this, before starting jRLA phantom, please make
sure that there is no other user already use the jBase. Otherwise, jBase
will use OS locking for the ones who already logged on, and us jRLA for
the users who logging after. This will damage the data consistence.
Locking mechanism for multi application server.
For multi application server environments and stateless connection, the
original locking mechanism is not suitable. Hence, there is another way to
handle such scenario. We both know that jRLA use the shared memory to
determine whether the record is locked or not. But the shared memory
can not be used between multi application servers or stateless connection
– http connection. Let me explain the detail on the white board for you.
Assume that there are two application server and one jBase database
server. Both of application server mount the physical files in database
server by NFS – network file system. When the first user asks for locking
the customer record 100001 and then application server 1 send the
locking request to database server. At the meanwhile, the database server
raisees an OS locking and also register it in stub file. After that, T24
application server 1 search F.RECORD.LOCK to make sure whether the
record is locked by another process or not. If no, store the locking
information into F.RECORD.LOCK table, also request database server to
release the OS locking.
After few second, the second user asks for locking the same record from
application server 1. Once application server 1 gets the request and then it
sends a request to database server to lock the record. Database server
lock the record by OS locking and register the key into stub file.
Afterward, the application server 1 perform an search in F.RECORD.LOCK
table. It finds there is already a lock made by user 1. Since this,
application server 1 request database to release the lock and reply to user
2 by the information “The record is locked by another user”. So, this is the
way T24 handles the multi server locking mechanism.
jBase environmental variables.
jBase environmental variables are similar with the OS variables – like
PATH which to define the directories to search executables files.
TUniverse Tech Company http://www.tuniversetech.com
Room 9, 8F., No.42, Songjiang Rd., Jhongshan District, Taipei City 104, Taiwan
(R.O.C.)
Page 2 of 3
 TUniverse Tech Company
Training Note
We just introduce important ones.
JBCRELEASEDIR = this is the root directory for jBase installation.
For maintenance purpose, we usually use /usr/jbc for this variable. And
built a symbolic link between actual installed directory and /usr/jbc.
JBCGLOBALDIR = this contains the path of config directory, normally it is
same as JBCRELEASEDIR
PATH = Please remember to add /usr/jbc into PATH variables to make
sure OS system knows where to look up the executable files. Keep in
mind, don’t destroy the original PATH setting, just append /usr/jbc into it.
LIBPATH = contains the path for shared object or dynamic link libraries.
JBCSPOOLER = contains the path for spooler use.
JBCBASETMP = directory for jBase temporary usage.
JEDIFILENAME_MD = MD is the master dictionary for jBase. This
variable contain the path which point to master dictionary. ($HOME/VOC)
Let us take a look at VOC file.
Please type the command in the jShell prompt.
‘LIST VOC’
You will find there are many records stored int the VOC files.
The first field is an indicator to specific the type of vocabulary.
JBCLISTFILE = $HOME/&SAVEDLISTS&
JBCEMULATE = PRIME
.profile or remote.cmd sample explanation.

 GEN7

TUniverse Tech Company http://www.tuniversetech.com