topic Re: DCOB$ACC_DATE in Operating System - OpenVMS

DCOB$ACC_DATE

James Bard — Wed, 28 Mar 2007 14:28:39 GMT

We have a large number of COBOL programs in use which obtain the system time by doing something like

ACCEPT FROM DATE.

I've traced this to call to DCOB$ACC_DATE from DEC$COBRTL.EXE and am trying to write my own version of the routine to be used instead.

The goal is that I be able to control the value a program receives from a call like the one above without changing the system date/time. I'm having issues with passing the dummy data back to the calling program, though.

Could you please either tell me how to return the data to the calling program or suggest a workable alternative?

Thanks,
James

Re: DCOB$ACC_DATE

Robert Gezelter — Wed, 28 Mar 2007 15:07:05 GMT

James,

I suspect that to reliably achieve what your post seems to envision is somewhat different.

The COBOL runtime should be requesting the system time, at the end using the appropriate system service. It is possible to fake this, and it has been done in the past, most commonly around the plethora of testing that was done before January 1, 2000.

Replacing the COBOL call would possibly produce strange results, because there may be other software getting things through different paths. This would lead to an inconsistency, which could have serious repercussions.

If I have been unclear, or can of futher assistance, please let me know.

- Bob Gezelter, http://www.rlgsc.com

Re: DCOB$ACC_DATE

Hein van den Heuvel — Wed, 28 Mar 2007 15:22:23 GMT

The code below works for me.
It assumes and verifies presence of a logical name with the selected 6 byte date value.

Of course the default link will cause a 'multiple defined symbol'. A serious implemenation would take care of that and provide of all of:

cob_acc_date DDMMYY
cob_acc_time HHMMSSNN
cob_acc_day YYDDD
cob_acc_day_week day of week 1-7
cob_acc_date_yyyy DDMMYYYY
cob_acc_day_yyyy YYYYDDD

But that would be like work!
(Which I'll gladly undertake for a fee. Send Email!).

Regards
Hein van den Heuvel
HvdH Performance Consulting

$ type date.cob

IDENTIFICATION DIVISION.
PROGRAM-ID. my-test.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 X PIC X(6).
PROCEDURE DIVISION.
MY_MAIN SECTION.
MAIN.
ACCEPT x FROM DATE.
DISPLAY "Date : ", X.
STOP RUN.

$ type my_date.c

#define MY_DATE_YYMMDD_LOGICAL_NAME "MY_DATE_YYMMDD"
#define MY_DATE_YYMMDD_LENGTH 6

#include
#include
#include

void dcob$acc_date( char *p ) // Return date as YYMMDD
{
char *my_date_pointer;
my_date_pointer = getenv (MY_DATE_YYMMDD_LOGICAL_NAME);
if (!my_date_pointer || strlen(my_date_pointer) != MY_DATE_YYMMDD_LENGTH) {
fprintf (stderr, "Logical name %s not defined as %d char string!\n",
MY_DATE_YYMMDD_LOGICAL_NAME, MY_DATE_YYMMDD_LENGTH);
} else {
strcpy ( p, my_date_pointer);
}
return;
}

Re: DCOB$ACC_DATE

John Gillings — Wed, 28 Mar 2007 19:28:59 GMT

James,

Have a look at the OpenVMS Technical Journal V7

http://h71000.www7.hp.com/openvms/journal/v7/index.html

My article "Faking it with OpenVMS Shareable Images" can solve this problem fairly easily (indeed it was exactly this problem - messing with COBOL dates for which I wrote my first fake shareable image in about 1988).

Using a fake RTL you can change the behaviour of any routine you choose, and apply it to an existing program without having to recompile or relink the originals. With a few logical name assignments you can change what date ACCEPT FROM DATE returns for any or all COBOL programs running on your system

Use the FAKE_RTL procedure to clone DEC$COBRTL. You can then edit the MACRO code for the fake RTL to "hijack" DCOB$ACC_DATE, you can also use the default fake rtl code to trace the arguments in and out of the routine to help you work out how to return values (ie: mechanism, data type & format).

My version used a logical name to define a time offset as a signed delta time. First call translated the logical name to find the offset, it then added the offset to the current time to determine the value to be returned to the caller.

The easiest approach is to write the hijack code in MACRO32 as it's mostly calls to system services and LIBRTL routines.