These are all good reasons to invest in a change management tool.
Paul Nelson
Cell 708-670-6978
Office 409-267-4027
nelsonp@xxxxxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Wilson Jonathan
Sent: Sunday, April 27, 2014 8:22 AM
To: Midrange Systems Technical Discussion
Subject: Re: how to increase field size without increasing the field size
On Sun, 2014-04-27 at 08:41 -0400, Steve Richter wrote:
On Sun, Apr 27, 2014 at 8:31 AM, Wilson Jonathan
<piercing_male@xxxxxxxxxxx> wrote:
On Sun, 2014-04-27 at 07:28 -0400, Steve Richter wrote:
In defense of my colleague who is reluctant to recompile all, there is
code that is 15 years old in the system. That predates him. No one
knows for sure if the source code on the system is the actual source
that was compiled to create the program. Would be nice if source was
always stored in the program object.
I've had similar problems as sites where source was moved into user
specific "development" libraries, compiled, and then the program and
source _moved_ back to the "live" system... at which point the link
between the program and source was lost from the DSPPGM command.
Only by enforcing the rule that modded/new programs _must_ move the
source back to "live" and then re-compile was the link retained.
The other way was not to "book out" source into lots of user dev
libraries, but to have one large "dev" mirroring the "live" except for
on going changes, which would then have the source pushed back to the
live (once dev work was complete), but the compilation was always done
from "dev" with the pgm objects then pushed back to live, so again the
link was retained. The "live" source files were the backup to the real
"live/dev" source in the dev library, not totally intuitive but worked
well in practise for a small shop (circa 5 people) as un-related but
impacted development could be coordinated but probably would have been
useless in larger shops.
-Steve
midrange.com
