BUILD.

CONTROL is a deployment tool that could be used to install Non-core T24

applications and to move packages developed locally, on-site, from one environment to
another.
The basic idea is the same as DL.DEFINE. Save the details in one environment and release
them in another. Typically, in any implementation, the developments and configurations will
be done in the Build environment and then moved to master and UAT environments and
hence the name 'BUILD.CONTROL'
It provides the user with the facility/ability to"
 Save programs, data libraries, local ref table definitions, standard selection
descriptors and release them in another T24 environment.
 Automatic restoration of data libraries using DL.DEFINE.
 Automatic authorization of restored data records using OFS.
 Release I-Descriptors.
 Update LOCAL.REF.TABLE with the saved definitions.
 Compile/Catalog the programs released.
The resultant package will be saved in the path given in SAVE.PATH field, along with an
Index that will be used for Release operations.
To SAVE a BCON Unit
 To RELEASE a BCON Unit

BUILD.CONTROL
 Note: In a TAFJ environment, the sources should not be packaged within a
BUILD.CONTROL application. The sources must be controlled only via the JAR files
and the IDE should be used for the sources. Therefore, the functionality of the fields
7 to 12 are now outdated and will no longer be supported for usage on TAFJ
platform.

This table is the gateway of Build Control Tool. This table is used to save and release the
BUILD.CONTROL pack. Field descriptions are as follows:

Build Control Tool

The version “BUILD.CONTROL, MAIN” can be used for all the actions –
SAVE/RELEASE/DL.RESTORE/AUTH.DL.RESTORE/PGM.RELEASE. Using this version we can
save and release a BCON pack.

To save a BCON pack

he Build Control system creates a package that includes Programs/Object Codes, DL.DEFINE
units, Local Ref definitions, I-Desc Definitions, Flat File details, new tables to be released etc.
Each of these components is saved in a layered approach and the priority of these layers is
as given below.
Steps to save a new Build Control Unit have been explained below.

Main Screen
 Enter BUILD.CONTROL, MAIN at the Command Prompt.
 Enter the ID that you would like to give to your Build Control Package (Having a date
component will help).
 This will open up a set of associated versions as shown below.
  Enter the Action – SAVE/RELEASE/HOLD/PGM.RELEASE/DL.RESTORE/DL.AUTH
 Give a brief description on this package/in case of patch – what is the patch for
 Mnemonic – Mnemonic code of the pack

To save a Package
Use this screen to define the path where
 BUILD.CONTROL Units will be saved
 DL.DEFINE will save the data (as in ../F.DL.DATA)

What Happens
 While SAVE – A new folder with the name same as the Record ID, is created under this path
and the build control unit is saved in this path (similar in function to DL.DEFINE Unit)
Programs
Use this screen to define
 SAVE.BP where the programs/object codes ($ Files) reside,
 Selection criteria (Saved Lists should be prefixed with „SL-„ or this can be a jQL
 statement)
 RELEASE.BP where the programs/object codes ($ Files) need to be restored in the
destination environment.
 JBCDEV_LIB & JBCDEV_BIN to be set when Compiling/Cataloguing in the destination
environment. Leaving these fields blank will result in the default JBCDEV_LIB and
JBCDEV_BIN, as defined in REMOTE.CMD or .profile, being used. If the above JBCDEV_LIB &
JBCDEV_BIN are not defined in $JBCOBJECTLIST, system will throw error.

What Happens
 While SAVE – A new folder with the name same as the PROGRAM.BP is created under Build
Control Unit Save path and the Saved list or the Select Command is used to select the
PROGRAM.BP and the records are copied to the Build Control path‟s BP folder.
 While RELEASE – The Release BP, if it doesn‟t already exist, is created in the destination
environment and the contents of the BP in Build Control unit are copied to the Release BP.
After setting JBCDEV_LIB and JBCDEV_BIN to required values, the copied files – depending
on whether they are source or object codes, are either Compiled using EB.COMPILE or
Catalogued using CATALOG command.

DL DEFINE Units
Use this screen to
 Define the DL.DEFINE units that need to be saved as part of this package.
 Define the company from which the records defined in DL.DEFINE need to be saved, in case
there are FIN type file records.
What Happens
 While SAVE – The DL.DEFINE units are saved by invoking DL.DEFINE.RUN and the resultant
DL.DEFINE units are copied into Build Control save path.
 While RELEASE – The DL.DEFINE Units will be copied to ../F.DL.DATA/DL.RESTORE and
DL.PARAMETER.RUN and DL.DEFINE.RUN will be invoked to release and restore the DL
DEFINE records.

Dict Items
Use this screen to
 Define any Dictionary items – I-Descriptor definitions that need to be saved as part of the
package. (Only enter the Standard Selection ID and the I-Desc Name. The properties will
automatically be defaulted from STANDARD.SELECTION. Every time the Build Control is
saved, these properties are refreshed automatically from STANDARD.SELECTION.)

What Happens
  SAVE – The properties – like TYPE, FIELD NO, VAL PROG and all other Standard Selection
fields are saved in their corresponding fields in R.NEW of BUILD.CONTROL.
 RELEASE – I-Descriptor name is checked in STANDARD.SELECTION and updated with the
details from R.NEW; the STANDARD.SELECTION record is locked, updated and written to
$NAU. OFS.GLOBUS.MANAGER is used to authorise this STANDARD.SELECTION record and
thereby rebuilding dictionary.

LOCAL.REF
Use this screen to define the
 Local ref definitions for all the T24 applications that need to be part of this package. (This
Local tables should be presented in LOCAL.TABLE)

What Happens
 While SAVE – Nothing. The definitions are validated.
 While RELEASE – based on the definitions and after ensuring that the Local ref fields are
available in LOCAL.TABLE, the corresponding LOCAL.REF.TABLE record is updated with this
definition. If the Local Ref is already attached to the application, then the Association is
overwritten with this definition.

New Tables to be released

Use this screen to define
 New tables that are being released as part of this package, for which Standard Selection
record needs to be rebuilt.
What Happens
 While SAVE – Nothing.
 While RELEASE – A new record is locked and created in STANDARD.SELECTION, $NAU file, on
IHLD status. OFS GLOBUS MANAGER is used to authorise that record.
 Instead of saving the STANDARD.SELECTION record for new tables as part of the DL.DEFINE,
specify the name of the table here. This proves to be helpful when a new table is being
released and an I-Descriptor also needs to be attached to that STANDARD.SELECTION. Since
the Authorisation of restored DL.DEFINE records happen after the activity of restoring I-Desc
definitions, there will be a run time error. However, by specifying the table here, the
STANDARD.SELECTION is rebuilt even before I-Desc activity is done and hence restoring I-
Desc definitions will be successful.

Flat Files
Use this screen to define
 The path of flat files (Unix/NT directories – TYPE UD Files) that need to be created when
restoring this package.

What Happens
  While SAVE – Nothing
 While RELEASE – The path, folders are created and a VOC pointer is created with ID as the
last part as the ID
 In the above case, a folder in the path ../bnk.interface/git/GIT.INWARD will be created and a
VOC pointer will be created with ID as GIT.INWARD.

Commit and Verify the BCON pack

 Once we done the above Build control definitions Commit the record and verify the same.
 After the Verify command, we can see the Data record components and Source/Object
codes which are packed up in this BCON unit. This consolidated pack will be stored under the
path ../F.BCON.DATA/SAVE with the same BCON name saved.
 Use the below enquiry and Associated version to see the data components.

View Process Info

Use this screen to see
 Once the Save operation is complete, the system will automatically display the results in the
form of a standard T24 Enquiry, as shown below.
Package Checklist
Use the enquiry BUILD.CONTROL.PACKAGE to review the contents of the package.
 Shown below is a screen shot of this enquiry, running on a package called TMNS000-
GPAC.GITI.R12.
Enquiry shows the list of Data records which are saved in the pack.
Build Control Saved Unit
Once we saved the Build Control unit, whole package will be created under the path
../F.BCON.DATA/SAVE as shown below.

Contents of a Build Control Unit

Shown below is the Content of the Build Control Unit TMNS000-GPAC.GITI.R12
 GIT.BP – Program BP
 SAVEDLISTS – If a Saved list had been used instead of a Select Command, then that Saved list
will also be saved, under a folder SAVEDLISTS
 TMNS000-GPAC.GITI.R12.2 and TMNS000-GPAC.GITI.R12.1 – The DL DEFINE pack.
 BCON_TMNS000-GPAC.GITI.R12 – Index (Copy of R.NEW to be used during RELEASE
Operations)

 GIT.BP - This is the BP defined as PROGRAM.BP, from which programs were selected.
  SAVEDLISTS - If a Saved list had been mentioned in SELECT.CMD field, then that Saved list
will be copied under this folder. During RELEASE Operation, this will be copied over to
&SAVEDLISTS& in the destination environment.

 TMNS000-GPAC.GITI.R12.2 and TMNS000-GPAC.GITI.R12.1 -This is the DL.DEFINE to be

saved part of the package. During RELEASE Operation, this will be copied over to DL.DEFINE
restore path (typically ../F.DL.DATA/DL.RESTORE) and restored/released using
DL.PARAMETER.RUN and DL.DEFINE.RUN.

To Release a Build control Package

We should use the same version BUILD.CONTROL, MAIN to release a BUILD.CONNTROL unit.
Main Screen
 To release the pack, copy the BUILD.CONTROL unit to F.BCON.DATA/RELEASE directory as
shown below. For Example: TMNS000-GPAC.SADB.
 If the BUILD.CONTROL unit contains the Object code, we should transfer the BCON unit in
Binary mode (UNIX server). If it a NT server, we do not care about the mode of transfer.

 Launch the main version BUILD.CONTROL, MAIN in browser.

 Open a new record with ID as TMNS000-GPAC.SADB (should be same as the BCON Unit
name)
 In the ACTION field enter RELEASE.

To Release a package
Use this screen to define
 Enter the BCON release path in the field „Release Package is Available under‟
 This release path should be same, where the BUILD.CONTROL Unit has been copied over.
 The system will default the path where the DL Units need to be copied (as in
../F.DL.DATA/DL.RESTORE or../DL.RESTORE) which may not be the same in both Save and
Release environments. Manually change the value if the system raises an error.
 At field input level, if the path is correct, then the system will load the remaining fields based
on the index file BCON_TMNS000-GPAC.SADB stored under the release path.
 Once validated the record, system will automatically populate the remaining fields based on
the Index file BCON_TMNS000-GPAC.SADB as shown below.
 In the Release tab, in the field „OFS Source to be used for Authorising‟ enter the ID of the
OFS.SOURCE to be used for authorising the records. At this field input, the system will
default Authorisation Priority. The user can amend this priority as applicable.
  Now commit the record.
 Open the same record and Verify it (V function).

 Now package will be installed.

Note: It is strongly recommended to use the classic screen to release the BCON unit
which holds the Object codes and Data records. Follow the below steps to release
the unit in classic mode.

Release a BCON Unit in Classic

 To release the pack, copy the BUILD.CONTROL unit to F.BCON.DATA/RELEASE
directory as shown below. For Example: TMNS000-GPAC.SADB.
 If the BUILD.CONTROL unit contains the Object code, we should transfer the BCON
unit in Binary mode (UNIX server). If it a NT server, we do not care about the mode
of transfer.

 Login to the T24 user in classic mode

 Go to the application BUILD.CONTROL in INPUT mode. Now the system will show the
below screen.

 Give the Description, Mnemonic, Action and Release path as shown below.

 Now the system will ask to reload the package. Press „Y‟ and enter. Now the system
should be reloaded the BUILD.CONTROL unit based on the index file.
 Enter the OFS.SOURCE.ID as „BUILD.CONTROL‟ and enter.

 Remaining fields will be auto populated based on the index file.

 Now commit the deal and Verify (V) the same.
 Now the system will restore the records and object codes which are packed in the
BCON unit.
 Once the Restoration processed successfully, system will ask for a sign out. Now sign
out the JBase session and re login to the new session.

 Verify the same BCON unit record in the new session as shown below.
 Now the Data records will be authorised automatically using the Build control tool.
 Then check the session, whether all the data records are authorised successfully.
  If any of the record is not authorised successfully, then authorise it manually.

Note: If any BATCH record needs to be RELEASED for multiple companies (Ex: MF1,
EU1 etc), we should “SAVE” the BATCH.NEW.COMPANY record along with the
BATCH Record from the Source environment.

Screenshot of BATCH.NEW.COMPANY record where the BCON saved

PGM.RELEASE
 With this action, BUILD.CONTROL releases all programs that are part of the DL Units
specified in the multi-valued field DL.DEFINE.
 Saving and Releasing Programs, works exactly the same way as RELEASE. To release a
program, the ACTION could be set to PGM.RELEASE or RELEASE.
 If the field RELEASE.BP is NULL, then programs will not be Compiled/Catalogued.

Note: If the user chooses to release using PGM.RELEASE, then, the Action must first
be set to DL.RESTORE and Verified first (so that the programs are restored).
Subsequently, the Action can be set to PGM.RELEASE and Verified.

DL.RESTORE
 With this action, BUILD.CONTROL restores all the data records part of the DL Units
specified in the multi-valued field DL.DEFINE.
 Since the sample BUILD.CONTROL unit TMNS000-BCON.REL.SAMPLE also contains
data records, it can be used for testing DL.RESTORE alone.
 When the ACTION is set to RELEASE, BUILD.CONTROL automatically copies the DL
Units from F.BCON.DATA/RELEASE to the DL Restore path (as in,
F.DL.DATA/DL.RESTORE), and then uses DL.PARAMETER & DL.DEFINE to release &
restore those records.
 However, when the Action is set to DL.RESTORE, the system assumes that the
required DL Units are already present in the DL Restore path (as in
F.DL.DATA/DL.RESTORE or ../DL.RESTORE). The user has to move the DL Units
manually under the DL Restore path before setting the Action to DL.RESTORE

AUTH.DL.RESTORE
 With this action, BUILD.CONTROL authorises all the data records part of DL Units
specified in the multi-valued field DL.DEFINE
 Since the sample BUILD.CONTROL unit TMNS000-BCON.REL.SAMPLE also contains
data records, it can be used for testing AUTH.DL.RESTORE alone.
 This will enable Authorisation of Restored records. However, when Action is set to
AUTH.DL.RESTORE, the system assumes that the records have already been restored
and will only attempt to authorise them.

Note: If the user chooses to authorise using AUTH.DL.RESTORE, then, the Action
must first be set to DL.RESTORE and Verified (so that the programs/records are
restored). Subsequently, the Action can be set to AUTH.DL.RESTORE and Verified.