Clarification on CA 2E 8.7.4 Runtime Date/Century Handling (Y2RTJCR)

Products

• CA 2E

Issue/Introduction

In earlier versions of CA 2E, the generated source explicitly contained century determination logic similar to:

IF YY < 40   Century = 1ELSE   Century = 0ENDIF

However, after upgrading to CA 2E 8.7.4, this logic is no longer present in the generated source.

Instead, the generated program now calls the runtime program Y2RTJCR, which populates the Program Data Structure (PGMDS) and the job date is subsequently retrieved from that structure.

This KB article clarifies the CA 2E 8.7.4 Runtime Date/Century Handling (Y2RTJCR)

Environment

2E 8.7.4 and later

Resolution

1.  How does Y2RTJCR determine and populate the century value within PGMDS?

The program Y2RTJCR is a CA 2E program responsible for populating 7-digit (CYYMMDD format) job-related date fields within the Program Data Structure (PGMDS). It derives the century digit by applying a hard coded sliding-window pivot rule against the 2-digit year portion of each job date:

If the 2-digit year is less than 40, the century is set to 1, treating the date as a 20xx year (e.g., 2000–2039).
If the 2-digit year is 40 or greater, the century is set to 0, treating the date as a 19xx year (e.g., 1940–1999).

This calculation applies to both the Job Submit Date and the Job Start/Execution Date and the resulting 7-digit values are written back into the respective PGMDS fields.

2.  Does Y2RTJCR use any configurable cutoff year, IBM i environment settings or other runtime configuration to determine the century?

No. Y2RTJCR currently uses the hardcoded cutoff value of 40 for century determination. Currently, there is no other configurable cutoff year, IBM i environment setting or runtime configuration for this purpose.

3.  Is there any supported mechanism within CA 2E to configure or influence this century determination logic?

Y2RTJCR is part of the shipped sources inside CA 2E, a group of sources which the customers can modify based on their own environmental needs. The source exists in Y2SYSRC/QRPGSRC. It can be modified as needed for future cut-off dates. If and when any such changes are made to the shipped sources, please ensure that the custom changed programs work fine in development/test environments before promoting them to production environments.

4.  It is possible to modify Y2RTJCR to use a cutoff of 80 instead of the current 40?

The source is shipped to enable customers to handle this change based on their requirements. The change of the cutoff in Y2RTJCR is a safe change.  Kindly note that any change to the shipped source is not supported out-of-the-box by Broadcom Support and needs to undergo testing at the customer end. The program can be compiled with a standard CRTRPGPGM IBM compiler command, since it is an RPG/400 program. If and when the change is done, this new version of Y2RTJCR can be copied over to the existing runtime libraries and replace the older version.

5.  Would existing generated programs that call Y2RTJCR automatically use the updated logic after recompilation of Y2RTJCR or would regeneration/recompilation of individual generated programs also be required?

Yes, existing programs that call Y2RTJCR will automatically use the updated logic after recompilation of Y2RTJCR. There is no need to regenerate/recompile individual generated programs. After recompiling Y2RTJCR, ensure that it is copied into the proper generation library and/or runtime library. Need to ensure that the modified version of Y2RTJCR is the first one referenced from the library list being used in the interactive/batch sessions.

6.  Is Y2RTJCR shared across all CA 2E models/applications in the environment or does each model/application have its own runtime copy?

The model or application does not have a copy since Y2RTJCR is a runtime object. The base version exists in the 2E Product library (Y2SY) and is typically copied into the target library (a runtime library/generation library) when the YDUPAPPOBJ command is executed. 

7.  Are there any risks that future CA 2E upgrades/PTFs may overwrite the customized Y2RTJCR source or object?

The chances of modifying Y2RTJCR are very low since it caters to limited functionality and there has been no issues until now. That said, from the next 2E 8.8 release onwards, we are planning to include a list of modified runtime objects that were changed as part of the new release development/issue fixing related activities.  If Y2RTJCR is indeed one among those modified objects, then reach out to Broadcom Support to provide an additional fix that will include both your changes and the 2E changes. 

8.  Does Y2RTJCR apply only to job-related date fields in PGMDS or can it also influence other application/business date fields generated by CA 2E?

Y2RTJCR applies ONLY to the job related date fields in PGMDS. For the application/business date fields generated by CA 2E, the century determination is done in conjunction with a 2E model value called YCUTOFF. The cut-off year in this model value can be any year from within the range of 1900-1999 and its current value is retrieved at run time. The shipped default is 1940. In this case a year greater than or equal to 40 is assumed to be in the 20th century and a year less than 40 is assumed to be in the 21st century.  YCUTOFF has no overlapping responsibility in Y2RTJCR.

9.  Apart from Y2RTJCR, are there any other CA 2E runtime programs or generated routines that should be reviewed for cutoff-year logic?

Y2RTJCR is the only program which handles the cutoff year logic for job related date fields. For application/business date fields, the YCUTOFF data area is used for century determination. For job-related date fields, Y2RTJCR is used for century determination. Please note that Y2RTJCR is only invoked in the program initialization phase (ZZINIT subroutine) of the generated 2E programs.  If any changes are made to Y2RTJCR, it is recommended to mention that explicitly in your upgrade notes/internal documentation so that after any subsequent upgrades in the future it is known that the modified Y2RTJCR needs to be included in the runtime library instead of the older one.