I'll answer Barbara and Chuck with the same reply, as they are both
equally incredulous of WHY. And I really can't blame them! ;-D

Barbara, what kinds of "bad things" do you foresee? I just want the
member change date (the one you can see on WRKMBRPD > F14). I can't
think of a thing that could go wrong with that, other than it won't
match the module object source change dates, but it already doesn't.
In other words, the damage is done - the source doesn't match the
object dates, so how much worse could it get changing them back?

1. No, we didn't add any lines, so debug will give the "source has
changed" error, but remain usable.
2. I hate the way we mark our code changes, but it's not my choice. I
don't much like the new way we've decided to do it, but that wasn't
mine either.
3. It won't bother me in the least that the source change dates are
all pointed to last night, but others seem to think it's the worst
thing ever.
4. I'm going to make them all happy and figure out a way to fix the
dates to where they were last updated.

some of the folks in QA/CS and one of the developers use that date a
lot (it's handy, but there are other ways) and they're pissed off it
has changed due to updating the top comments in almost all of the
programs - about 2k source members strung over 7 versions of the
software. I'm trying to make them happy.

Thanks again for the suggestions, if we do anything about it, it will
be to use AnyDate to change the system date and then change the member
type or update the first line or something. We might not do anything,
but I was hoping for an easy way to do it, of which there doesn't seem
to be.

Thanks for all the suggestions though.

On Fri, May 18, 2012 at 7:49 PM, Barbara Morris <bmorris@xxxxxxxxxx> wrote:
On 2012/5/18 4:42 PM, rick baird wrote:

We've changed the way we mark our code changes which required updating
comment lines in the source members to initialize them for the new
method.


Why not wait until the source member needs to be changed for some other
reason?

I'm assuming there's a good reason, I'm just curious to know what it is.

The only thing I can think of is that there's some utility that crawls
through the source analyzing changes - if not, ignore the rest of this.
If so, shouldn't the utility just handle both the old and new format? If
it can't, then some pre-process could do whatever transformation is
being done on the source now, but into temporary members.

I agree with Chuck - faking out the last change date on the file could
have unforeseen consequences, and if you are unlucky, you wouldn't find
out about them until long after the badness happened.

Rule to live by: There's always another way.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].