I have a problem. I am writing a Cobol program that does direct calls to Adabas files.
One of the fields I am retrieving is the date field, in Adabas it’s format in the DDM is D with length of 6, it is actually stored in a packed decimal format.
When I retrieve the date in my Cobol program I can see that it actually holds a numeric value e.g. 07388942F equates to 28th February 2023. I need to convert this value to a PIC X(10) field in Cobol in YYYY-MM-DD. Is there a way I can do this simply ?
My understanding is that the date returned is the number of days since 01 Jan 0. I have a workaround that is to use the Cobol date Function INTEGER-OF-DATE but this converts gregorian date to the format I require, which starts from Jan 1st 1600. My workaround has been to subtract the no of days from 01 Jan 0 to Jan 1st 1600 from the Adabas date and then on then use the INTEGER-OF-DATE function.
It is not ideal as it is not to ‘standard’ so was wondering if there is a way of doing this differently and cleanly that you may know about ?
Start date is actual 1582 (When we switched from Julian calendar to Gregorian). To verify write a NATURAL program that defines a user field as (D). Redefine it as P6 and move 1 to P6 field then display date field. Low and behold you will have the beginning of time (as defined by Software AG)…
Eugene (Gene) Miklovich
ADABAS/NATURAL Systems Support and DBA
Cell: 916-202-7047
Normal Hours: 8am-4pm E.T.
Please call or text if assistance needed outside these hours.
yes that is what I did and I was happy with the results as it worked but for some reason the guys in my shop don’t like it. I think this is the only way to do this using Cobol, also I don’t think there is an edit mask that will take the packed date and out it as a YYYYMMDD date in the Buffer either e.g E(DATE) etc.
To be more specific this is a NATURAL Date format (in ADABAS he just thinks it is a packed field) and COBOL doesn’t understand NATURAL D format so no COBOL edit mask will solve the issue….
Adabas allows date to be returned in your preferred format:
the field must be defined in the FDT with an edit mask such as E(NATDATE) if it is a 4 byte packed field containing a Natural date field. The FDT can be updated with the ADADBS utility without impacting existing programs. I updated my sample file with "ADADBS CHANGE FILE=101,FNDEF=‘01,AH,4,P,NC,DT=E(NATDATE)’ " (field had compression option “NC” on it already)
in your direct call, specify the date format you want the date returned in, such as E(DATE) (which returns YYYYMMDD): FORMAT-BUFFER = ‘AH,8,U,E(DATE).’, where “AH” is a 4,P field in the FDT with an edit mask of E(NATDATE) on it. Returned value is 8 unpacked numbers in YYYYMMDD format. I’m sure you can add the “-” characters without offending your shop standards
Hi Eugene,
that sounds like a good solution, however
a) I know zero NATURAL and had not even heard of it before a month ago and
b) this needs to happen in a Cobol program using Direct calls to Adabas.
The only way I could do it is using this Cobol Date function :
The DATE-OF-INTEGER function converts a date in the Gregorian calendar from integer date form to standard date form (YYYYMMDD).
The function type is integer.
The function result is an eight-digit integer.
FUNCTION DATE-OF-INTEGER(argument-1)
argument-1
A positive integer that represents a number of days succeeding December 31, 1600, in the Gregorian calendar. The valid range is 1 to 3,067,671, which corresponds to dates ranging from January 1, 1601 thru December 31, 9999.
Thanks guys,
Douglas many thanks your method was spot on and resolved my issue. The result was as you mentioned 8 unpacked numbers that I was able to move to my PIC X field after doing a redefines on the returned format-buffer value.
Great result, thanks for your help, will have to get you a beer sometime
