Bridge For Git (BFG) and element formats/file encoding
search cancel

Bridge For Git (BFG) and element formats/file encoding

book

Article ID: 417290

calendar_today

Updated On:

Products

Endevor

Issue/Introduction

We are experimenting with Endevor Bridge For Git (BFG) to establish a hybrid model environment where users can work with Endevor OR GitHub Enterprise and would like to inquire about recommended best practice in a few areas.

We have some element types that contain unprintable (hex) characters such as OBJECT types, SDF panels and Groups etc.  We also have a few element types that are tracking source in an FB80 but proprietary format where the content may contain x'00' (nulls) or packed decimal fields for lengths etc.  If we mark these as DATA FORMAT BINARY in the Endevor type definitions they are added to GIT as Binary, but this disables many of the viewing/peer review etc. What then is the best practice for editing these elements once in Git?  Can a Git user safely clone/edit/update back to GIT or do we have to use a mainframe based Git client?

We have some elements that while they are mostly text contain some characters that have different code points depending on the codepage/CCSID used.  For example the square brackets (0x'ad' and 0x'bd') - if our Endevor configuration is set up as CodePage="cp01140", CharacterSet="utf-8" then these characters appear as 'Ý' and '¨' respectively instead of '[' and ']'.  Is there a way, at the element level to select a different code page, perhaps through a .gitattributes file?  and if so how can BFG help us identify those elements/edit the .gitattributes file?

Environment

Endevor Bridge For Git.

Resolution

It is very important to make sure Endevor Web Services are configured correctly.
Follow this documentation Endevor® 19.0 > Installing > Complete Configuration Tasks > Configure REST API and SOAP API (Web Services) > Optional: Configure Web Services for Environment Using Multiple EBCDIC Code Pages to configure multiple codepages as needed (for example by type) and make sure that the output encoding is always UTF8 (what REST API client will get is in UTF8).
Subsequently make sure that BFG is running with UTF8 as well see "file.encoding" here Endevor® Bridge for Git 2.0 > Installing > Run Bridge for Git.
Note that this setup should be done before creating any mapping in BFG.
For existing mappings BFG will keep synchronizing them using the original encoding for compatibility reasons (it won't convert). When this setup is done, BFG should perform "round trip" without corrupting any character (that is not completely true because of how Endevor Web Services are handling line breaks vs. records in dataset, but for other characters you should be fine).
Next step is cloning code to the developers' workstations. That depends on the Git client used and its configuration. Git client is having conversion features that can be configured on the system, user and repository level. For example autocrlf controls conversion of line breaks. Make sure the Git clients developers are using are configured the right way and are converting characters as needed (both ways pull/push), or are not converting them. For editing of the source it depends what is the IDE/editor being used, what are its capabilities, plugins etc. Most of the editors are able to edit in hex if needed.