Extended DDL Naming / CA 2E generators map special characters to Underscore not including "#"
search cancel

Extended DDL Naming / CA 2E generators map special characters to Underscore not including "#"

book

Article ID: 237986

calendar_today

Updated On:

Products

CA 2E

Issue/Introduction

The extended SQL naming feature assigns longer, more meaningful names for DDL columns by assigning 25-character field names from the model. 

CA 2E generators map any special characters of a field into Underscore as follows.

Special Character in Model

Mapped to in the SQL Name

~ ! ‘ % & * ( ) { } | " \ / < > = - + : ; . , ? [ ] ¢ blank

Underscore ( _ )

 

However, the special character list does not include the special character for  “#”.

 

This cause issues when we have EXCUSRSRC function with parameters called from any external functions.

The user source parameters  (#I-input, #O-output and #B-both) does not generate correctly with the long field name with # character.

Environment

Release : 8.7

Component: CA 2E

Cause

The user source parameters  (#I-input, #O-output and #B-both) does not generate correctly with the long field name with # character.

Resolution

It is a known issue that using the special character # in EXCUSRSRC in handwritten programming causes these types of scan and replace problems of real #I,#O,#B fields. Generally will not use these types of user-defined long-named fields with # in EXCUSRSRC as it will cause scan and replace problems. As it is a sensitive area of the product and there is a chance of so many other scenarios like this scan and replace problems.

That is not only with assigned statements and these types of issues may also come in the case of condition statements and iteration statements and computation statements like addition kind of statements. So the scope of analyzing, fixing, and testing is huge as we need to consider a lot of other scenarios as well. So we thought to not touch the EXCUSRSRC generator sensitive area of the product.

So, to address the reported problem we decided to include the "# " also in the special character list of the SQL naming feature. For this, we created a test PTF fix Y287A17100.SAVF which was attached to this case. Please install as per the attached readme document.
 

Additional Information

As part of this, a new Data area - YSQL#NMRFA was used to achieve backward compatibility. Please also create the same in your  model library, with the following command

CRTDTAARA DTAARA(model-library/YSQL#NMRFA) TYPE(*CHAR) LEN(4)
     VALUE(*OLD) TEXT('YSQL#NM SQL including "#" in special chars while Naming')

This data area controls whether the long and meaningful field name with # should be mapped to underscore or not same as other special characters mapping to underscore.

For backward compatibility purposes, the default value of the data area should be *OLD - which will ensure that the long and meaningful field name with #  is not mapped to underscore. Instead, if it is desired to map the long and meaningful field name with # to underscore, then we need to set the YSQL#NMRFA data area to a value of *NEW.

 

Attachments

13052022_120950950_1_Y287A17100_1659216186705.savf get_app
13052022_120950950_1_Y287A17100_1659216151840.savf get_app