Tweet
We have a lot of report programs the print-files for which use the DDS DATE keyword unadulterated, which produces the job date by default. When these programs are called from any client-server application, whether Java or VB, this date becomes unreliable. On systems that IPL every morning, it's fine. On some systems that do not IPL, it's fine. On other systems, it returns the job date from the server job handling the command call, which is frequently not the current date. This is not good.
Naturally, re-compiling the DDS with DATE(*SYS) was the first order of business, but that's a lot of print-files to move out to a lot of clients. So we whipped up a little CL program that would end and restart the *RMTCMD server. We scheduled this as a job that would run on a daily basis. Due to some poor thinking on my part, some of these jobs were set to run before midnight and others after.
This morning, I verified that the *RMTCMD server had been restarted on five client systems, and then tested the job dates on each. Three were fine, two were hosed. I should have been able to predict that the two that were hosed were those which bounced the *RMTCMD server before midnight, but that wasn't the case. In fact, two systems with the correct job date had restarted the server before 12.
So it's getting all Lloyd Bridges here ("looks like I picked a bad day to quit sniffing glue"), and if anyone has any insights, we'd be happy to hear them.
Naturally, re-compiling the DDS with DATE(*SYS) was the first order of business, but that's a lot of print-files to move out to a lot of clients. So we whipped up a little CL program that would end and restart the *RMTCMD server. We scheduled this as a job that would run on a daily basis. Due to some poor thinking on my part, some of these jobs were set to run before midnight and others after.
This morning, I verified that the *RMTCMD server had been restarted on five client systems, and then tested the job dates on each. Three were fine, two were hosed. I should have been able to predict that the two that were hosed were those which bounced the *RMTCMD server before midnight, but that wasn't the case. In fact, two systems with the correct job date had restarted the server before 12.
So it's getting all Lloyd Bridges here ("looks like I picked a bad day to quit sniffing glue"), and if anyone has any insights, we'd be happy to hear them.