Patch Creation

Screen management

Entry screen

Element types that can be patched

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

Important notes

Total transfer of a table data

The TABcode is used to transfer the data in a table, by reloading it in the database with its structure and its data. However, the dictionary elements related to this table are not created, so the table might be hidden. Also, this code is useful when you want to reload 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 applies to the table definition (ATB XXXXX), the second applies to 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 a table data

To partially transfer a table data, provide the table abbreviation in the type column and enter in the Namecolumn a logical condition used to extract the source folder and perform the integration to the destination folder. It is important to note that the data extracted in this way can modify the existing data with the same keys, or create new data. However, for security reasons, the data may never be deleted during the patch integration. For example, in the following situation, in the country table (TCY abbreviation):

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 script file via the EXE code (see below). For example, in order to be certain for the countries starting with an A, that only the countries with codes AD, AE or AL remained on the list, a script file would have been delivered (called MAJPATCHnnn for example), which would contain the lines described in the example below.

Running a script

One specific case must be mentioned: The EXE code, which makes it possible to give the name of a script to be run. Despite its rank number, this script 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).

The script must contain a subprogram called PATCH, with a parameter being the folder code. This is the subprogram 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 seen that it is necessary to declare the tables in this subprogram whilst considering the fact that they must be declared in a folder that is not necessarily the current folder (the syntax, Local file = FOLDNAME + '.TABLENAME', ensures this).

Generic scripts 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 script in the maintenance. The standard scripts to be started, depending on the type of patched element, are as follows:

This type of functionality can also be carried out within the framework of a specific development (simply add the PATCH subprogram 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. Supervisor.

Selection of the configuration 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 the patch, be it defined by an action, a window, a screen, a table and two scripts, 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 example, if a window is integrated before the screens included in this window, the error Nonexistent screenis triggered upon 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).

Dictionary elements that are not patched

If you are installing a patch containing dictionary elements, please note that 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.

Please refer to the detailed technical appendixfor details on the applicable 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...

On 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 placed 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 with this function :

 PRTSCR : Screen print

This can be changed using a different setup.

Batch task

This function can be run in batch mode. The standard task ZPATCHC is provided for that purpose.

Specific Buttons

Error messages

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

…. : nonexistent 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 to the abbreviation in an existing table.

... Dictionary XXX record nonexistent

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 an incorrect syntax.

Tables used

Refer to documentation Implementation