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 [Link]. 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 '[Link]'
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 [Link].
 Automatic authorization of restored data records using OFS.
 Release I-Descriptors.
 Update [Link] with the saved definitions.
 Compile/Catalog the programs released.
The resultant package will be saved in the path given in [Link] field, along with an
Index that will be used for Release operations.
To SAVE a BCON Unit
 To RELEASE a BCON Unit

[Link]
 Note: In a TAFJ environment, the sources should not be packaged within a
[Link] 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
[Link] pack. Field descriptions are as follows:

Build Control Tool

The version “[Link], MAIN” can be used for all the actions –
SAVE/RELEASE/[Link]/[Link]/[Link]. 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, [Link]
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 [Link], 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/[Link]/[Link]/[Link]
 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
 [Link] Units will be saved
 [Link] will save the data (as in ../[Link])

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 [Link] Unit)
Programs
Use this screen to define
 [Link] where the programs/object codes ($ Files) reside,
 Selection criteria (Saved Lists should be prefixed with „SL-„ or this can be a jQL
 statement)
 [Link] 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 [Link] 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 [Link] is created under Build
Control Unit Save path and the Saved list or the Select Command is used to select the
[Link] 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 [Link] or
Catalogued using CATALOG command.

DL DEFINE Units
Use this screen to
 Define the [Link] units that need to be saved as part of this package.
 Define the company from which the records defined in [Link] need to be saved, in case
there are FIN type file records.
What Happens
 While SAVE – The [Link] units are saved by invoking [Link] and the resultant
[Link] units are copied into Build Control save path.
 While RELEASE – The [Link] Units will be copied to ../[Link]/[Link] and
[Link] and [Link] 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 [Link]. Every time the Build Control is
saved, these properties are refreshed automatically from [Link].)

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

[Link]
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 [Link])

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 [Link], the corresponding [Link] 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 [Link], $NAU file, on
IHLD status. OFS GLOBUS MANAGER is used to authorise that record.
 Instead of saving the [Link] record for new tables as part of the [Link],
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 [Link]. Since
the Authorisation of restored [Link] records happen after the activity of restoring I-Desc
definitions, there will be a run time error. However, by specifying the table here, the
[Link] 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 ../[Link]/git/[Link] will be created and a
VOC pointer will be created with ID as [Link].

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 ../[Link]/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 [Link] to review the contents of the package.
 Shown below is a screen shot of this enquiry, running on a package called TMNS000-
[Link].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
../[Link]/SAVE as shown below.

Contents of a Build Control Unit

Shown below is the Content of the Build Control Unit [Link].R12
 [Link] – 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
 [Link].R12.2 and [Link].R12.1 – The DL DEFINE pack.
 BCON_TMNS000-[Link].R12 – Index (Copy of [Link] to be used during RELEASE
Operations)

 [Link] - This is the BP defined as [Link], from which programs were selected.
  SAVEDLISTS - If a Saved list had been mentioned in [Link] 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.

 [Link].R12.2 and [Link].R12.1 -This is the [Link] to be

saved part of the package. During RELEASE Operation, this will be copied over to [Link]
restore path (typically ../[Link]/[Link]) and restored/released using
[Link] and [Link].

To Release a Build control Package

We should use the same version [Link], MAIN to release a [Link] unit.
Main Screen
 To release the pack, copy the [Link] unit to [Link]/RELEASE directory as
shown below. For Example: [Link].
 If the [Link] 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 [Link], MAIN in browser.

 Open a new record with ID as [Link] (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 [Link] Unit has been copied over.
 The system will default the path where the DL Units need to be copied (as in
../[Link]/[Link] or../[Link]) 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-[Link] stored under the release path.
 Once validated the record, system will automatically populate the remaining fields based on
the Index file BCON_TMNS000-[Link] as shown below.
 In the Release tab, in the field „OFS Source to be used for Authorising‟ enter the ID of the
[Link] 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 [Link] unit to [Link]/RELEASE
directory as shown below. For Example: [Link].
 If the [Link] 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 [Link] 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 [Link] unit based on the index file.
 Enter the [Link] as „[Link]‟ 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 [Link] record along with the
BATCH Record from the Source environment.

Screenshot of [Link] record where the BCON saved

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

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

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

[Link]
 With this action, [Link] authorises all the data records part of DL Units
specified in the multi-valued field [Link]
 Since the sample [Link] unit [Link] also contains
data records, it can be used for testing [Link] alone.
 This will enable Authorisation of Restored records. However, when Action is set to
[Link], 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 [Link], then, the Action
must first be set to [Link] and Verified (so that the programs/records are
restored). Subsequently, the Action can be set to [Link] and Verified.