*DATE incorrect

Tags:
RPG
We have Visual basic applications that access the AS/400 through QSERVER. When these VB programs execute RPGLE programs, the *DATE reserved word picks up the date QSERVER was started and not the current date. This is a recent occurrance and has functioned properly for 4 or so years. Any suggestions on how or why this occurs and how do we fix it?

Answer Wiki

Thanks. We'll let you know when a new response is added.

I am not sure this is applicable, but we had the same issue with a web application that interfaced with an RPGLE program. *DATE picked up the job date (and the thread could stay active for days). We changed the RPGLE app to use %DATESTAMP instead.

Discuss This Question: 7  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Folgerscoffeeman
    What i usually do is use the Time opcode and move the Date into a Date field in *USA format. So in your D specs D Today S D DATFMT(*USA) Then at the top of your program or in your initialize routine. C Time Today The as/400 knows that dateusa is a date field, and will properly move todays date into that field. From there you can easily manipulate the date into any format you desire. With a move statement. From there you may
    0 pointsBadges:
    report
  • Folgerscoffeeman
    What i usually do is use the Time opcode and move the Date into a Date field in *USA format. So in your D specs D Today S D DATFMT(*USA) Then at the top of your program or in your initialize routine. C Time Today The as/400 knows that dateusa is a date field, and will properly move todays date into that field. From there you can easily manipulate the date into any format you desire. With a move statement. From there you may
    0 pointsBadges:
    report
  • Folgerscoffeeman
    What i usually do is use the Time opcode and move the Date into a Date field in *USA format. So in your D specs D Today S D DATFMT(*USA) Then at the top of your program or in your initialize routine. C Time Today The as/400 knows that dateusa is a date field, and will properly move todays date into that field. From there you can easily manipulate the date into any format you desire. With a move statement. From there you may
    0 pointsBadges:
    report
  • RickatEaton
    Thanks for all of your input. What we are trying to determine is what caused this anamoly. Prior to October, all of the called RPG programs used the current date in the process. During our Sarbanes-Oxley compliance work, we have summized that we modified something that caused QSERVER jobs to use the QSERVER start date as the current date.
    0 pointsBadges:
    report
  • BigKat
    From the RPGLE Refference (V5R2) For an interactive job or batch program, the user date special words are set to the value of the job date when the program starts running in the system. The value of the user date special words are not updated during program processing, even if the program runs past midnight or if the job date is changed. Use the TIME operation code to obtain the time and date while the program is running. What probably happened is that you recompiled them in a manner that allows the job to stay running. Perhaps it had been compiled with *NEW as the activation group, so that every time you called it, it started a new instance, thereby getting the "current" date.
    8,210 pointsBadges:
    report
  • Karl007
    We had the same thing happening a few times. Only our jobs ran in subsystem QSYSWRK whereas they should have been running in subsystem QUSRWRK. Actually, if I got it right that is, in subsystems QSERVER and QSYSWRK, only the so called "deamon jobs" should be running. Then if a request comes in, or if prestarted jobs need to be started, these "deamon jobs" will start jobs in subsystem QUSRWRK to threat your actual request (coming from Visual Basic in your case). But... If subsystem QUSRWRK has not been started, then those "deamon jobs" will just carry on and create those new jobs in the subsystem in which they our running themselves, being either QSERVER or QSYSWRK. And when started in QUSRWRK, these jobs will receive a jobdate from the actual system time, but when started in QSERVER or QSYSWRK, they seem to copy their jobdate from the jobdate of their "deamon job". I still wonder why that is. But the cure is simple. Issue a STRSBS QUSRWRK and the next VB job trying to connect will start in QUSRWRK, using the actual system date just as expected.
    0 pointsBadges:
    report
  • RickatEaton
    Found it. Autostart job QZDASOINIT in QSERVER was not active. I appreciate everyones input.
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following