Skip to content

COBOL Mappings

COBOL mappings are bindings which allow to link a data element from the UML model to a legacy data field, typically binding a COBOL field to an UML property. The bean modernization process creates these mappings and the transmodeling process consumes them to properly generate the logic of your application.

COBOL Mappings Creation

The bean modernization process is responsible for the creation of COBOL mappings for the COBOL structures you modernize. At the end of the legacy object modernization wizard (see here), your UML classes are generated in a package named generatedModel and contain information about which legacy elements have been used to produce it.

The stored property mappings are located at the Entity level using a hidden stereotype called LegacyEntityMapping, applied to the UML class. You can see these mappings by opening the specification of an UML class generated from the bean modernization process and going to the Tags entry.


The legacyItem tag stores a list of strings, each one with the following format :


Level 88 fields are not directly mapped since they don't have an UML target property. Instead, getters and setters located in the Business Object, or directly the Entity for PK_MODEL Entities (see here), allow to retrieve/set the different possible values for the CUSTLOG-AUDIT-ACTION-CODE field. In that case, mappings are generated to bind the getter/setters UML operations to these fields, with the following format :


These operation mappings are located at the Business Object level using the same mechanism as before :


NOTE : For PK_MODEL Entities, both property and operation mappings are located in the generated UML Entity.

Here is a complete example of a COBOL data structure called CUSTLOG-AUDIT-INFO (top left), the complete generated COBOL mappings (bottom left), and the generated UML structure (right) :


COBOL Mappings Scopes

Global scope

This is the default behavior for COBOL mappings. The created mappings are globally accessible across multiple cblmf files. This means that, if multiple cblmf files contains the same data structure and if you modernize this data structure in one cblmf file, the mapping will match even in the other cblmf files, re-using the same created UML elements.

Local scope

You can however compartmentalize your mappings by using local mappings, or file-scoped mappings. The format for these mappings is slightly different :

Using this scope, mappings will only be available in the scope of the cblmf file targeted in the prefix, and other cblmf files will have to create their own local mappings, even if the legacy FQN matches.

NOTE : For more information about how to generate file-scoped mappings, please refer to the COBOL Bean Modernization page.

COBOL Mappings Management

UML model

COBOL mappings can be customized after their creation by the bean modernization process. The first way to modify each value is by directly editing the legacyItem tagged value in your UML model.


In the specification page, you can access the Tags entry and clicking on the legacyItem tagged value to see the string list appear on the right. Then, you can modify (1) / add (2) / remove (3) values by using the three buttons on the bottom right corner.

Mappings wizard

Blu Age also povides a way to access all created mappings. You can access this wizard by right-clicking either anywhere in the Cobol Annotation Editor of a cblmf file, or directly on any cblmf file in your Package Explorer, and click on the Show Mappings entry.


The following page will appear :


  • The main table is separated into two columns, the left one presenting the FQN of each legacy element (1), and the right one presenting the UML element mapped to it (2). For operation mappings, the legacy element is the level 88 data field, marked with the (getter/setter) information, and the UML associated element is the couple UML getter operation / UML setter operation.
  • The UML element picker on the right (3) allows you to restrict the list of mappings by selecting a root UML element, outside which mappings are hidden from the table. The root package of the picker is the PK_BUSINESS package of your application, or the root package of your UML model if no PK_BUSINESS package exists or if your model contains service beans.


  • You can edit each mapping by clicking on the UML2 Element cell of each line and clicking on the ... button. A property picker appears to help you select the property to map. When you have modified all the mappings you want, you can click on the Apply Changes button (4) to persist the modifications (clicking on Finish also automatically apply them).


  • The Reset Views button (5) collapses the UML element picker in order to reset the table, showing all created mappings in your UML model.