Re: Change Datestamps -- WDSCI-L

"I hate having to close and reopen the same source member, each morning, just for the sake of a datestamp..."
Why would you want to be locking a member over night?

So if you happen to be coding on a critical change, keep the member locked open on your sessions but then you go out sick; you now cause others to wonder if you actually committed changes to the server so they can confidently end your jobs to reopen the member.

RDi opens quickly now a days and if you get a solid state PC unit its really quick (I thinks its about 10 seconds for my system from a fresh start). You can also have RDi open where it left off (Preferences -> Remote Systems, Re-open Remote Systems view to previous state).

-Matt

-----Original Message-----
From: WDSCI-L [mailto:wdsci-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Steve M via WDSCI-L
Sent: Monday, April 22, 2019 1:34 PM
To: 'Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries' <wdsci-l@xxxxxxxxxxxxxxxxxx>
Cc: Steve M <txpenguin1@xxxxxxxxxxx>; 'David Gibbs' <david@xxxxxxxxxxxx>
Subject: Re: [WDSCI-L] Change Datestamps

I guess, obviously wrong, that RDi would be smarter than it appears to be.
There's no reason it couldn't gather the "current" date from the local system and apply that value, but alas, it does not happen.

We have interactive jobs end in a much shorter time than that, however, RDi runs in QUSRWRK and not QINTER, so those rules don't apply.

I hate having to close and reopen the same source member, each morning, just for the sake of a datestamp, but that appears to be my only recourse.

Steve

-----Original Message-----
From: WDSCI-L <wdsci-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Steinmetz, Paul via WDSCI-L
Sent: Monday, April 22, 2019 14:03
To: 'Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries' <wdsci-l@xxxxxxxxxxxxxxxxxx>
Cc: Steinmetz, Paul <PSteinmetz@xxxxxxxxxx>; 'David Gibbs'
<david@xxxxxxxxxxxx>
Subject: Re: [WDSCI-L] Change Datestamps

Some of our applications have a similar issue depending on what code/process was used to obtain the date.
If the job runs past midnight, some dates could be incorrect.
We force end any interactive job after 12 hours.

This does two things.
1) End interactive sessions for users not signing off.
2) Ensures when users sign in, they have today's date.

Paul

-----Original Message-----
From: WDSCI-L [mailto:wdsci-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of David Gibbs via WDSCI-L
Sent: Monday, April 22, 2019 2:26 PM
To: Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries
Cc: David Gibbs
Subject: Re: [WDSCI-L] Change Datestamps

On Mon, Apr 22, 2019 at 1:18 PM Steve M via WDSCI-L <wdsci-l@xxxxxxxxxxxxxxxxxx> wrote:

Being a full-time remote employee I leave my RDi session running for
days on end (well, until the VPN drops me and makes me re-attach). I
started my latest session last evening, on Sunday 4/21.

Today, I was editing one of the source members I had open, did a
recompile of the object, then checked the compilation to make sure my
change was included. The source line in the compile showed 4/21 - uh,
no, today is Monday 4/22. I thought that strange, so I did a "show
data area" and sure enough, the changed lines all read 4/21. I
checked my PC date and it does properly read 4/22.