|
> The following was used: > RtvSysVal SysVal(QDATE) RtnVar(&Date) > ChgJob Date(&Date) > > Would this ensure that the job date matches the system date? That might be the case, but that wasn't the code that was posted :) If you do want to set the job date to the system date (something that I personally wouldn't recommend) make sure you convert the date format, in case they happen to be different. For example: RTVSYSVAL SYSVAL(QDATE) RTNVAR(&SYSDATE) CVTDAT DATE(&SYSDATE) TOVAR(&JOBDATE) FROMFMT(*SYSVAL) + TOFMT(*JOB) TOSEP(*NONE) CHGJOB DATE(&JOBDATE) But I think that this is a very poor way of doing it. What if this program was run at 11:59:59? It would set the job date to the current date, then the date would click over to midnight and still may be wrong in the RPG program that you called. If the RPG program is running for a long period of time, it's entirely possible that you'd want some of the records that it writes to show one date, and some to show another. Not to mention that when the next RPG programmer goes to look a the RPG source, he'll see that UDATE is used and assume that it's yesterday's date since he'll know from experience that UDATE is the job date! It would sure be a lot simpler and more elegant to just retrieve the system date in the RPG program if that's what's desired!!
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.