Patch Creation

Screen management

Entry screen

Element types that can be patched

This table is used to enter a list of object to be patched. This list is identified by an object type and a name. The definition of the various types and the meaning of the name are given here: The Rank column is used to know the order of the element types in the patch (see paragraph below). Elements with rank 100 in the grid are always at the end of the patch (in alphabetical order of element codes).

Important notes

Total transfer of data from a table

The TAB code is used to transfer the data in a table, by reloading it in the database with its structure and its data. On the other hand, the dictionary elements corresponding to this table are not created, which means that it may not be visible. Also, this code is useful when re-loading a table already created in the folders to be patched, where the structure has not changed. If this is not the case, it is necessary to place two lines in the patch definition : the first line concerns the table definition (ATB XXXXX), the second line concerns its content (TAB XXXXX). Even if they are not sorted in this entry order, the patch function will replace them in the order above. At the patch integration, the table will be created in the dictionary and in the database, if it does not already exist (if not, its structure will be updated if it has changed). Then the table will be reloaded with the data.

Partial transfer of the data in a table.

The possibility to transfer the partial contents of a table is obtained by giving the abbreviation in the Type column of the table, and by indicating in the Name column a logic condition that will be used for the extraction of the initial folder and for the integration in the target folder. It is important to note that the data extracted in this way can modify the existing data with the same keys, or to create new data. On the other hand, and for reasons of security, in no case will there be deletion of data during the integration of a patch. In this way, for example, if the following situation is considered, for the country table (abbreviation TCY) :

If in the patch the line with TCY is indicated and the condition CRY = "AL", the patch will only contain the line corresponding to Albania, and the integration of the patch in the target folder will rewrite AL, Germany and replace it with AL, Albania.

If indicated in the patch is a line with TCY and the condition pat(CRY,"A*"), the patch will contain 4 lines AD, AE, AF and AR. On integration, the record AE, United Arab Emirates and the record AR, Argentina will be created, the AL, Germany will be replaced by Albania and keep A, Afghanistan and AU, Australia, that existed already in the target folder and were not delivered in the patch.

If in the patch there is a line with TCY and the condition find(CRY,"AD","AE","AL"), the result will be the same, except for AR, Argentina, which would not have been transferred.

The only way to delete data consists in:

• Either globally replacing the contents of a complete table (TAB type patch)
• Or supplying a processing via the EXE code (see below). For example, in order to be sure for the countries starting with an A, that only the countries with codes AD, AE or AL remained on the list, a processing would have been delivered (called MAJPATCHnnn for example), which would contain the lines described in the example below.

Running a processing

One specific case must be mentioned: The EXE code, which makes it possible to give a name to a processing to be run. This processing is run at the end of the patch integration (it may exist beforehand or be delivered in the patch itself, since the execution is only carried out at the end of the integration).

This processing must contain a sub-program PATCH, with a setup that is the folder code. This is the sub-program that will be run. In this way, for the situation above, the following program is obtained :

Subprog PATCH(NOMDOS)
Value Char NOMDOS
Local File =NOMDOS+".TABCOUNTRY" [TCU]
Trbegin [TCU]
Delete [TCU] Where pat(CRY,"A*")=1 & find(CRY,"AD","AE","AL")=0
Commit
End

In this way it can be see that it is necessary to declare the tables in this sub-program while considering the fact that they must be declared in a folder that is not necessarily the current folder ( It is the syntax, Local file = FOLDNAME + ".TABLENAME", that ensures it).

Generic processings to be run

When patches are carried out on model elements of the user interface (model screens used to create transaction windows), the screens concerned need to be revalidated.

This revalidation can be performed by declaring the running of the appropriate processing in the maintenance. The standard processings to be started depending on the type of patched element can be found here below:

It should be noted that this type of functionality can also be carried out within the framework of a specific development (simply add the PATCH sub-program as specified in the previous paragraph).

Documentation patch

The structure of the data in the documentation slightly differs. In effect, the following default rules are applied on folder creation and revalidation:

• the documentation texts and files (tables ADOCBLB and ADOCCLB) are entered in the supervisor folder and are not transferred to the dependent folders (it is nevertheless possible to create local help texts for a folder that will be stored locally).
• the documentation structure (documentation links, that are nearly dictionary elements, and paragraph structures) is stored in each folder and copied to those folders located below in case of revalidation (while complying with the vertical or specific activity codes that may have been defined in a child folder).

Thus the principle is as follows when integrating a doc patch (ADO type):

• the documentation structure can be integrated to all the folders listed when applying the patch, irrespective of the patch type (based on the list of folders supplied on integration)
• the texts and files are only integrated to the supervisor folder if the patch type is Supervisor (this is the case for the standard doc patches). In the event of a different patch type, the texts and files are integrated to all the folders.
• the ADF type patch (links) can be integrated to all the folders, even if the patch has the Supervisor type.

Naming of the patch files

The patch integration checks the application sequencing of the patch files, whenever they include a numerical sequencing in their name. It is recommended to name the patch files using a name defined under the form X_yyyy_zzz.dat, with the following meaning :

• X is a character (different from P, since P is used to specify standard patches) that identifies the patch type
• yyyy is a sequential number (in principle starting at 0001).
• zzz is an identifier for the version to be integrated.

If this standard is applied, during the integration of a group of patch files in a directory, the following controls will be made :

• files from different versions are not mixed during the same integration
• it is not possible to skip a sequential number if patches identified by the same character and the same version number have already been integrated. In this way for example, if the patch Z_0005_150.dat has been integrated, if an attempt to integrate patch Z_0007.140.dat is made without first having integrated the Z_0006_150.dat patch, an error message is displayed on integration.

Order of the elements in a patch file

When a patch file is created, the rule is for the elements contained in said patch file to form a consistent whole which leaves the folder consistent after it has been applied. In particular, if a new function is created by patch, be it defined by an action, a window, a screen, a table and two processings, it seems logical for all these elements to be part of the patch.

When some elements are used to constitute a patch file, the creation function sorts them in a specific order of types, so as to avoid integration errors. For instance, if a window is integrated before the screens making it up, the error Screen does not exist will occur on validation. As a consequence the data types are always integrated before the screens and tables, the screens before the windows, and so on and so forth.

The order used on generating the patch matches the rank specified in the grid below: It is also the proposal order that appears in the automatic patch.function.

Let us underline the fact that it is impossible to solve all the possible conflicts. For instance, a data type can refer to an action, that may refer to a window, that may refer to a screen, that may refer to this data type. To solve this situation of conflict (although rare), it may be necessary to break down the patch file into two files (for instance, the first file supplying all the elements with a data type that does not refer to the action, the second file supplying the data type that integrates the action).

Non patched elements in the dictionary

When installing a patch containing dictionary elements, some fields, considered as dictionary elements that can be set up, are complied with irrespective of their protections by means of activity codes. This is the case of a default destination in a report.

A detailed technical annex lists these fields.

Specific format for AAA elements

A patch of AAA type corresponds to a line coming from a setup model. It uses a specific format for the element code. This format is one of the two following:

MODELE~CODE_LEG~CODE_TRS~='FORMULE_SELECTION'

MODELE~CODE_LEG~CODE_TRS~CLE~SOUS_CLE~SOUS_SOUS_CLE...

In these lines:

• MODELE corresponds to the data model used to describe the tables to extract
• CODE_LEG corresponds to the legislation code, which can be empty (in this case, two ~ are place one after the other)
• CODE_TRS corresponds to the transaction code, which can also be empty
• FORMULE_SELECTION is a filter condition. Any text chain must be put "in double quotes" since the formula is put in 'simple quotes'.
• CLE~SOUS_CLE~SOUS_SOUS_CLE (the number of sub-keys being variable) corresponds to the specific case when it is required to select a key value corresponding to the model main table. It is only possible when calling up a model (AAA code) from the patch creation and then opening the window making it possible to select the model and enter the key by direct search.

Reports

By default, the following reports are associated to the function :

 PRTSCR : Screen print

This can be changed by a different setup.

Batch task

This function can be executed in batch mode, but no dedicated standard task is delivered to execute it.

Specific Buttons

Error messages

In addition to the generic error messages, the following messages can appear during the entry :

…. : non-existent directory

The access path for the patch file does not exist.

Object type is incorrect

The object type does not correspond either to one of the predefined objects or nor to the abbreviation in an existing table.

.....Dictionary XXX record non-existent

An attempt has been made to extract an object from a non-existent dictionary.

Incorrect value

The extraction condition associated with the data extraction from a table contains incorrect syntax.

Tables used

Refer to documentation Implementation