PRG1.Introduction To JBC and Sessions
PRG1.Introduction To JBC and Sessions
Program
Subroutine
Compilation
Cataloguing
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
PROG.BP thus becomes a folder to store your user-defined programs. T24 routines
are stored in the subdirectories of T24.BP.
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.
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.
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.
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
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
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.
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.
Memory for the variables SCOPE & STATUS is allocated on the stack
PROGRAM PROG.SHARE
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
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