SCO Unix date settings

I have SCO Unix 3.2,system date settings and clock is fine but when I execute COBOL program,it display next date.pkease help me to resolve .

Another issue ,How can I resize my existing mount point.

What does "next date" mean exactly? Do you mean "the next day" ? If so, what is the different (error) exactly?

Please open a different topic when asking a different question.

Thanks and welcome to our site.

Next date means next day exactly.

Example: If system date is 13-OCT-2020 , COBOL program is displaying it t as 14-OCT-2020.

System time and hardware clock are in sync.

So, the hardware and system clock are in sync and they are correct, per your post; and your COBOL program is ahead (in error) by one day.

The next logical question is:

What is the exact version of COBOL are you running on your SCO Unix 3.2 OS?

COBOL version is : COBOL V3.1.41-Be

Just to be sure, this is Micro Focus COBOL?

Reference: https://www.microfocus.com/en-us/products/cobol-development/overview

See also:

https://www.microfocus.com/documentation/enterprise-developer/ed50/ED-VS2017/index.html?t=GUID-D84DDFBC-3D1E-47B1-8DEF-26B322C321F6.html

See also:

https://supportline.microfocus.com/productreleaselevels/liant.asp

A shift of exact 24 hours => this is likely a timezone problem.
The timezone gives a different presentation of the realtime clock.
Yes, consult your application.
In the Unix world the timezone is often set by a TZ environment variable.

Not really sure how a 24 hour exact shift would be a TZ issue.

For the date display to be 24 hours ahead, it would have to be 24 timezones away, which is the exact location it it in!

This does not make sense to me, to be honest.

However, it could be a TZ issue only if the TZ is set ahead of the current location and time is different, for example, 6 hours ahead, or 12 hours ahead, but not 24 hours ahead (this does not really exist, frankly).

Still, it would be good to get all the relevant TZ information (locale and TZ settings) when troubleshooting this, for sure.

I have timezone settings with 'EST5EDT'.
The same timezone is set in another machine where every thing is working fine.

But only in new machine we are having issue.

Thanks. As mentioned, I do not think it is a TZ issue.

Could we get back to my question, which is important (the actual COBOL you are running, including the name of the product)!

Agreed, 24 hours is much for a TZ issue.
But I once met such a thing on Linux where /etc/timezone was corrupted (fix: rebuilt with tic).
I don't know SCO well enough, but please carefully check files like /etc/TIMEZONE or /etc/default/init for correct spelling and no special characters (no WinDOS ^M at the end!).

COBOL v3.1.41-Be
PRN=AXUGG/ZZI:6a:1a:10.04
PTI=NLS

No micro focus cobol

So please find this version on the Internet!.

I can find zero references to it when I do a Google search !!

Are you copying this Cobol application from another system onto SCO?

Cobol has a multitude of compiler date options to make it compatible with the system it is running on, and being able to read the system clock and what format dates are stored in.

You say this is not Microfocus Cobol but as an example:

https://www.microfocus.com/documentation/extend-acucobol/925/BKUSUSFILES037.html

Do you have the source code of this thing?

AFTERTHOUGHT EDIT: I wonder if this is a Leap Year handling problem. Hmmmm. What do you think guys? Answers on a postcard please......... Is the product so old that it doesn't manage year 2020?

Anything is possible, especially since we do not know the details of which exact version of COBOL is running.

I also had the thought that the version running may be so old, it is not even "findable" when doing a Google search; and so naturally, the first thing to do is to upgrade COBOL to a supported version.

I think what needs to happen next is to ascertain the exact details of the version of COBOL, including the "flavor / maker / distributor" and the year of release.

Otherwise, we are just taking WAGs.

We have a image copy of a system,by which we have created new machine

So is this date problem now occurring on the original system too?

Of what system exactly?

What machine exactly?

Details really matter in technology

Actually we had taken image copy of old running machine and created a new machine with the help of old image copy.

So yes, you have taken an image of a SCO system (x86) and put it on new hardware.

I ask again, does the old system also have this date problem? If so, these old product(s) have a date issue. If not, it's something to do with the new hardware.