I am having a variable filr of LRECL = 1504. In some specific record i have a date field in the format YYYYMMDD. I need to add one day to those date fields.
IF Value from 1 to 4 column = 1000 and 16 to 3 is ATM then the date value will be present from column no 30. To that Date value we need to add one day.
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
siva102,
With z/OS DFSORT V1R5 PTF UK51706 or z/OS DFSORT V1R10 PTF UK51707 (Nov, 2009), DFSORT now supports date conversion functions(TOGREG,TOJUL) which can perform date arithmetic and give you the desired results in one pass like shown below:
But i do have some other file where i tried implementing the same logic but unable to get the output.
I have two input files and one is like below,
For FILE -1
The input file is a FB of lrcl = 320. And we need to change the date field in two places. The conditions are like below,
If
1 to 3 character = AAA then one date field starts from 40th position and the second date starts from 48th position and these dates need to be added one day.
The input file is a FB of lrcl = 190. And we need to change the date field in three places. The conditions are like below,
If
1 to 3 character = AAA then one date field starts from 20th position and the second date starts from 30th position and the third one from 40th pos and to those we need to add one day.
We have one more condition here is from these three dates sometimes we can have 00000000 instead of any date. And we dont need to change anything in that case.
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
siva102,
It would be of a great help for me if you had provided all the details at once. The manipulation of VB files is different from that of FB files. As VB files can have records with different lengths , we need to preserve them by adding the temp fields at the beginning of the record after the RDW.
For FB files we can add the temp fields at the end. so a solution for a VB file may not be applied for a FB file as is.
You need to understand the logic first and then you can customize to any format file.
The logic is quite simple. In order to add a day to existing date
1.we need to convert the Gregorian date (CCYYMMDD) into Julian date(CCYYDDD) ( ddd= day of year) . This is done by the function TOJUL
2. Add +1 to the DDD portion
3. Now you have to perform the reverse of step 1 which is converting the Julian date to Gregorian date. This is done by the function TOGREG.
However there is a loophole with this approach when the date is December 31st. adding 1 day would make it invalid day of the year. so in that case we increment the year by 1 and set the day of the year to 1 and perform step 3.
That is why you have an additional IFTHEN statements checking if the date is December 31st.
The following DFSORT JCL will give you the desired results.
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
siva102 wrote:
The input file is a FB of lrcl = 320. And we need to change the date field in two places. The conditions are like below,
If 1 to 3 character = AAA then one date field starts from 40th position and the second date starts from 48th position and these dates need to be added one day.
siva102,
With PTF UK90025 for z/OS DFSORT V1R10 and PTF UK90026 for z/OS DFSORT V1R12(Oct, 2010), DFSORT now supports date arithmetic which can add/subtract days, months or years to a given date like shown below.
The input file is a FB of lrcl = 190. And we need to change the date field in three places. The conditions are like below,
If 1 to 3 character = AAA then one date field starts from 20th position and the second date starts from 30th position and the third one from 40th pos and to those we need to add one day.
We have one more condition here is from these three dates sometimes we can have 00000000 instead of any date. And we dont need to change anything in that case.
00000000 is considered as a special date and date arithmetic functions do not add perform arithmetic on them and leave them as is.
For complete details of date arithmetic functions and other new functions see "User Guide for DFSORT PTFs UK90025 and UK90026" paper (sortugph.pdf) at:
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
Skolusu wrote:
The logic is quite simple. In order to add a day to existing date
1.we need to convert the Gregorian date (CCYYMMDD) into Julian date(CCYYDDD) ( ddd= day of year) . This is done by the function TOJUL
2. Add +1 to the DDD portion
3. Now you have to perform the reverse of step 1 which is converting the Julian date to Gregorian date. This is done by the function TOGREG.
However there is a loophole with this approach when the date is December 31st. adding 1 day would make it invalid day of the year. so in that case we increment the year by 1 and set the day of the year to 1 and perform step 3.
Are there any plans in the works to have DFSORT use Lilian day numbers rather than pseudo-Julian dates?
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
Akatsukami wrote:
Are there any plans in the works to have DFSORT use Lilian day numbers rather than pseudo-Julian dates?
NO. I wonder why you refer the Julian date as psuedo dates. The Lilian day numbers can be calculated using DFSORT functions. With PTF UK90025 for z/OS DFSORT V1R10 and PTF UK90026 for z/OS DFSORT V1R12(Oct, 2010), DFSORT now supports date arithmetic which can be used to calculate the number of days difference between two dates.The result is an 8-byte value consisting of a sign and 7 digits (sddddddd).
Lilian day number 1 started at midnight on the first day of the Gregorian calendar, that is, 15 October 1582. So if you want to convert any date to Lilian day format , all you need to do is subtract that date from 14 October 1582.
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
Skolusu wrote:
Akatsukami wrote:
Are there any plans in the works to have DFSORT use Lilian day numbers rather than pseudo-Julian dates?
NO. I wonder why you refer the Julian date as psuedo dates.
Not pseudo dates; pseudo-Julian dates. An actual Julian date would be a date in the (possibly proleptic) Julian calendar, which I am tolerably certain is not available on z/OS (although it could be calculated, of course).
As for pseudo-Julianism: I suspect, although I haven't researched the matter, that the term began when some half-educated programmers confused ordinal day number (number of days since 12/31 of last year) with Julian day number (number of days since 1/1/4713 BCE 12:00:00 UTC, the last time that the Roman indiction, Metonic cycle, and solar cycle all began together) and called a date in CCYYDDD format a "Julian date". Outside of earth science and IT, that's considered incorrect terminology...and you know how important terminology is
