Century date calculation errors
Hi team, a program of ours is failing stating that the cycle number is greater than the number existing in the history file. We saw that the input file had the date in the yymmdd format which would mean that the century date is being calculated. The error we faced is that the cycle number is getting generated as a century as 00.
Cycle number: 00190909
This happened post 9.1 upgrade. Need to know if there are any acr defaults which are set to generate these values. Or any way to rectify.
-
Is this a Program Interface job or File Interface? I believe there is a UNICNUM member in the SRCELIB that you can modify to add the century to the cycle.
* THE USER MAY ADD CODE HERE TO MODIFY THE CYCLE NUMBER -
* FOR ACR PROCESSING. THE CNUM AREA IN LINKAGE IS PROVIDED -
* FOR THAT PURPOSE. -
* -
* RELEASE 2.0 -
* REMARKS. UNCOMMENT THE CODE BELOW TO INSERT -
* THE CENTURY INTO ALL CYCLES. -
*---------------------------------------------------------------
* IF CNUM-CYC-DT IS GREATER THAN ZERO
* AND CNUM-CC IS EQUAL TO ZERO
* IF CNUM-YY IS LESS THAN 80
* MOVE '20' TO CNUM-CC
* ELSE
* MOVE '19' TO CNUM-CC.
GOBACK.If it is file interface, it could be the way the format when the cycle is being picked up.
-
Hr Srinivasan: what release are you upgrading from?
Even though you are using file interface, can you check to see if the UNICNUM or UNICNUM1 module is being called? These take a higher priority and will be applied even if pulling the cycle from the file. Check out the information in the ACR/Summary User Guide: do a search on UNICNUM (its going to take you a few places) and then check to see what you have. Check for both UNICNUM and UNICNUM1. We also encountered this issue when we upgraded in early 4n releases but it's been awhile. We'll keep looking to see if we have more specifics from that time but that was the program that was replacing our century with the 0's.
Mary
Please sign in to leave a comment.
Comments
4 comments