0% found this document useful (0 votes)
49 views39 pages

PRG1.Introduction To JBC and Sessions

Introduction to jdBC and Sessions

Uploaded by

Kalkidan Abiyu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
49 views39 pages

PRG1.Introduction To JBC and Sessions

Introduction to jdBC and Sessions

Uploaded by

Kalkidan Abiyu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 39

Introduction to jBC

The way jBC works

Program

Subroutine

Compilation

Cataloguing

Environment variables – JBCDEV_BIN, JBCDEV_LIB, PATH, JBCOBJECTLIST

Variable declaration – Local and Global

Understand sessions

Variable scope.
The development environment comprises of a) A development language jBC and a
compiler which is used to develop T24, b) a Runtime TAFC / TAFJ

TAFC is the Runtime for Application Framework developed in C/ C++ language. TAFC
provides a C compiler to compile code written in jBC. Similarly there is TAFJ which is
the Runtime for Application Framework developed in java language.

As shown TAFC/TAFJ stores user data input through T24 in a multi-value database
called jBASE. TAFC/TAFJ also provides the flexibility of storing user data in external
databases like Oracle, DB2, SQL etc. through Direct Connect Drivers(DCD)

From a end user perspective both TAFC and TAFJ provides exactly the same
features, only the development environment is different.
Let us discuss each of these components in detail. To start with, jBC Language
Overview

jBC is aimed primarily at writing business applications and contains all the constructs
needed to access and modify files and their data efficiently. It also comes with in-built
libraries to access jBASE database tables.
Before you actually start writing code, you need a directory to store the source code
you write.

Traditional these directories are named with some name followed by .BP. For example
PROG.BP If it does not exist in your area, create the same using the command

CREATE.FILE PROG.BP TYPE=UD

PROG.BP thus becomes a folder to store your user-defined programs. T24 routines
are stored in the subdirectories of T24.BP.

By the way, BP stands for basic programs

 Directories are sequential files and referred to as non-hashed files in Unix,


hence type=UD where UD stands for Unix Directory

 The JED command opens a file called FIRST.PRG under the directory
PROG.BP
The <program name> MUST be the same as the <file name>, FIRST.PRG in this
case.

CRT command displays the text within quotes on the standard output, i.e., monitor.

PRINT has the same function as CRT.


 The compiler checks for errors in the source code.

 If there are no errors, the compiler generates a machine native object file,
prefixed with a “$”(eg -$FIRST.PRG) in the same directory as the source code.
The biggest difference between jBC and all the other contemporary programming
languages is that TAFC on which jBC program is executed, does not use a Virtual
Machine. It is implemented to take full advantage of the underlying Operating
System. Since TAFC does not use a Virtual Machine there is no need to produce
intermediate code to be then interpreted at run-time.

Application execution at incredible speed, programming language flexibility and simple


programming constructs, are the biggest advantage, users of jBC programming
language have over others.

TAFJ is an ingenious mechanism to convert existing jBC code to Java


Bytecode(.CLASS / .jar) and execute. The .CLASS files are executed by JVM(Java
virtual machine). Since the jBC code is made available in equivalent .CLASS files, you
may even write a JAVA program in which you can create objects of these classes and
invoke its methods. This way you can make your existing jBC code inter-operable with
JAVA without having to re-write the jBC code from scratch in Java.
The environmental variable JBCDEV_BIN is preset to the bin directory under the home
directory.

set JBCDEV_BIN=%HOME%\bin (Windows)

export JBCDEV_BIN=$HOME/bin (UNIX/ LINUX)


When T24 is installed, two directories namely “T24bin” and “bin” get installed under
the home directory of the user. The directory “T24bin” contains the core T24
executables. The directory “bin” contains the non-core/local executables. The compile
and catalog commands are consolidated into a single T24 program called
EB.COMPILE
•PATH obviously refers to the location where the CATALOG command has copied the
executable and shared libraries/DLLs.

•PATH is preset to %HOME%\bin (Windows) and $HOME/bin (UNIX/ LINUX) to


enable the application executable to be located and executed.

jSHELL is explained in detail later.


jBC is a simple programming language that facilitates easy coding. However, it does
not come with a compiler of its own.

The jBC program is compiled by either the native C compiler or the Java compiler.
The former generates a C Object code which is catalogued into an executable specific
to the underlying OS which is then executed by the TAFC runtime. The TAFJ
environment provides the mechanism for compiling T24 to Bytecode (.CLASS files /
.JAR files) that can run on any Java Virtual Machine (JVM) irrespective of computer
architecture.

TAFC – Temenos Application Framework for C.

TAFJ – Temenos Application Framework for Java.


The C compiler, compiles the jBC code to an object code which is then catalogued to
generate an executable. The TAFC runtime executes the exe directly to generate the
output.

In Windows, CATALOG produces a .dll and a .exe file. In UNIX/ LINUX, CATALOG
produces a .so and a binary file with the same name as that of the source file.

The TAFJ environment on the other hand first generates an equivalent .JAVA file from
the jBC program, which is then compiled by the java compiler into the Bytecode. TAFJ
runtime, interprets the Java Bytecode at runtime to produce the output.

For TAFC remote.cmd for Windows, .profile for UNIX/ LINUX are files used to
configure the environment variables required during compilation and execution to
know the location of the executable

Similarly in TAFJ the TAFJ.PROPERTIES file is used to configure these details.


When a user logs into TAFC, the jSHELL program is automatically executed.

jSHELL is the TAFC shell. It acts as a command-line interpreter and provides a user-
interface for the TAFC system. It reads user-input from the command line and
executes actions based on that input.

When a jSHELL is launched, it starts a session. A session refers to all the request that
a single client makes to a server. A session is specific to the user. An unique ID is
generated for every session by the TAFC, to identify the session and the user
associated with the session.
A session is identified by its unique identifier. As shown in the figure, a user can make
multiple requests and receive responses. All such requests from the user/client is
processed by TAFC and jSHELL performs the role of the interface. The user may also
send requests through an application. One jSHELL represents one session. A session
is active till the user logs out.
When the same user logs in again or another user logs in to TAFC, another jSHELL is
launched. This starts another session. This second jSHELL exclusively processes the
requests of the user who started the session, till the user logs out or is terminated. As
you can see in the figure, another unique identification number is generated by TAFC
to identify this session and distinguish it from the first.
A session ends when the user logs out. Session termination originates with a user
request. Type Ctrl+D at the jSHELL prompt to terminate a session. This results in the
termination of the jSHELL and the session ends.

Alternatively ‘exit’ or ‘LO’ can be supplied in the jSHELL prompt to quit the session.
The two corresponding environment variables here are JBCDEV_LIB and
JBCOBJECTLIST

While cataloguing, TAFC refers to the environment variable, JBCDEV_LIB which is


preset to %HOME%\lib (Windows) or $HOME/lib (UNIX/ LINUX)

To execute a subroutine, the environment variable JBCOBJECTLIST is referred as it


contains the search path for all T24 subroutines.

To refresh your mind: JBCDEV_BIN is set to point to the path where catalog has to put
the executables. JBCDEV_LIB is set to point to the path where catalog has to put the
libraries.

The difference between the compilation of a Program and Subroutine is that, Main
program executables by default are copied in the %HOME%\bin directory. Subroutine
object files are “collated into evenly sized shared libraries” and then by default placed
in the %HOME%\lib directory.
A variable need not be declared in jBC. However, you require a name for the variable
and it’s a good practice to initialize a variable before use. jBC does not require you to
care about the data type. It’s not a strongly typed language which makes its quite
flexible to write programs.

Variables in jBC can store all types of data as well as data of any length. They are not
declared to be of a specific type.

Eg CUSTOMER.ID = “A001”, CUSTOMER.ID variable stores a character string

CUSTOMER.ID = 9278, Here the same CUSTOMER.ID variable now stores a


numeric value.

Variables MUST have a name. Variables need not have a type. Variable names can
contain characters, numbers, underscore, ‘$’ and ‘.’. The first letter for an identifier for
a variable must be a character.

The following are all valid identifiers for variables – PART_TIME, PART.TIME,
PART$TIME, TIME10, ABC_.ABC . The general practice is to use dot to separate
words in variable names eg PARTY.VENUE.

All variables by default are String or Text variables.


When you execute a jBC program, it gets a chunk of memory from the underlying OS
which is called as the process space or address space and uses it to run your jBC
code. This process space is exclusive to the program. TAFC adds a stack frame
which holds the state of the method, including which line of code is executing and the
values of all the local variables to this process space.

In the jBC program displayed on the slide

Memory for the variables SCOPE & STATUS is allocated on the stack

On execution, the program prints LOCAL IS VISIBLE


The subroutine LOCAL.SHARE on compilation generates a warning, because SCOPE
& VISIBLE are visible only in LOCAL.SCOPE and not accessible in LOCAL.SHARE. As
discussed earlier, the scope of a variable declared inside a program is limited to the program
block. It cannot be accessed even in the subroutine called from the program. The reverse is
also true. A variable used in the subroutine LOCAL.SHARE will not be accessible in
LOCAL.SCOPE.
When a program calls a subroutine, the subroutines stack frame falls on top of the call
stack. The subroutine on the top of the stack is the currently executing subroutine for
the stack. The subroutine stays on the stack until the END of the subroutine block is
reached. In the above example LOCAL.SCOPE invokes LOCAL.SHARE and the
memory representation is shown in the figure.

LOCAL.SHARE cannot access the variables declared in LOCAL.SCOPE as shown.

If instead of a subroutine, you write a program as

PROGRAM PROG.SHARE

CRT SCOPE : VISIBLE

END

The variables are still inaccessible. Another program will have its own process space
in a different memory location and hence the local variables of LOCAL.SCOPE will not
be accessible.
Once the program completes execution the process space allocated for the program,
is automatically reclaimed. So anything on the stack is destroyed and the local
variables also cease to exist.

The life and visibility of a local variable hence is within the code block in which it is
defined

Unlike local variables, Common variables retain their values even after a code block
terminates and can share its data between multiple code blocks.

This is achieved by defining the variables that you want to share as COMMON
Any variable declared as COMMON within a Program or subroutine, is not allocated
space on its stack frame in the Process Space. Common variables are created in a
common Session Space. Process Space is exclusively allocated to each program,
and is available for the programs use till it completes execution or terminates. A
session space and thereby a session variable is available even after the program
terminates, as long as the session is active.
When accessing COMMON variables from another Program or a Subroutine, a
namespace must be used to define the common variable as shown. In the example,
NS is the namespace which acts as an abstract container for holding the shared
variables. When a namespace is shared, all programs/subroutines using it should
have declared the same number of variables within it. (Note: In the above example,
you made declare the common variable without using the namespace. Then the
COMMON variables are destroyed once the main Program completes execution, and
is not available for the entire session)

SCOPE & VISIBLE are now common and shared by both LOCAL.SCOPE and
LOCAL.SHARE. SCOPE and VISIBLE are not allocated memory on the process
space, but are created in the Session space.
A Session as discussed, refers to all the requests that a single client makes. A session
is specific to the user. A session variable is hence specific to that user and is used to
store user specific “global” data for use by all programs within the application.
Common variables retain state across multiple code blocks and hence act as session
specific variables. Every user, when he initiates a session, a session space is created
which is identified by the session ID of the user and common variables are created in
this session space.
Now SCOPE and VISIBLE are COMMON, to both LOCAL.SCOPE and
LOCAL.SHARE.
As you can see, the subroutine compiles successfully. On execution, LOCAL.SCOPE
invokes LOCAL.SHARE, which prints the values in the variables assigned in
LOCAL.SCOPE.
Instead of declaring common variables in each and every program/subroutine where
they are required, you can declare them once in an INSERT file and insert this file in
all the required programs/subroutines.

In the example in the slide, an insert file called I_COMMVAR is created. SCOPE,
VISIBLE is declared as a common variable to be used throughout the session in this
file. This file is inserted in both LOCAL.SCOPE & LOCAL.SHARE using the $INSERT
statement.

$INSERT I_File - looks for the I_ file specified, in current directory, T24.BP and
bnk.run

This file should contains the declaration of the


common variables. Insert files are not compiled.
When compiling codes with insert files, the Basic command should be executed as
follows
BASIC –I <the relative or absolute path specified for the directory where your Inserts resides>
<prog directory> <file name>
SCOPE & VISIBLE are now common and shared by both LOCAL.SCOPE and
PROG.SHARE

Use EXECUTE to invoke another program from a program. EXECUTE “<PROGRAM


NAME>”.
A Session refers to all the request that a single client makes to a server. A session is
specific to the user

A session variable is hence specific to that user and is used to store user specific
“global” data for use by all programs within the application

Common variables retain state across multiple code blocks and hence act as session
specific variables
1. BASIC
2. Object code.
3. Compilation Error – because variables are not declared in jBC
4. False
5. False
6. True – common variables are available till the session ends.
1) NAME = SAM
2) 1
ONE
ONE
1) SECOND

You might also like