Re: I seek overall advice.

[Booth Martin <booth@xxxxxxxxxxxx>]

Here is my overall advice, fwiw, Grizzly.

This is a systemic issue.  You are talking of a major structural change 
in the shop.  Would it be worthwhile for you to take a few preparatory 
steps?  Define where you'd like to go, prepare your reasons for it, 
write down your goal (so that you know when you get there), and then set 
out to get your people on board?  In the process you may discover a 
bunch of stuff you really didn't wanna know, but will be glad you do. 
Once everyone is on board, write your standards and develop your 
algorithm.

You are talking about a major job ahead of you, certainly three years, 
minimum.  A few immediate changes are certainly appropriate, but a 
misfire would really be a bad thing for the new guy.

My own strategy is to pick an application at a time and do a complete 
rewrite, application at a time, including redesign and learning how 
competitors do it.  Bang-for-the buck would be how I'd choose what to do 
first; however I'd start with one of the small applications first, not 
the biggy, because your first one will be your worst one  -  better it 
not be the biggy hanging around to hound you for the next 20 years.  :)




Grizzly M wrote:
> Not sure where this should be posted. Either this list, Midrange-L, or
> the CPF000-L list. 
>
> Can anyone make a suggestion as to what would be a good way to handle
> exception errors for RPG II programs? Up until May of 2005 the previous
> programmer here wrote and maintained program in RPG II. That drives me
> nuts. Regardless of that these programs seem to crash at least once a
> day. It happens so often that the users think that answering the break
> messages is actually a programming feature the previous programmer put
> in place. I think that is unreal. Is there a way to change the default
> break handling to do something other than present the message and allow
> the user to answer? 
>
> The other problems are as follow:  
>
> There are over 400 CL programs with hardcoded libraries.
>
> There are over 400 programs that don't have the correct source members
> they were compiled from. The previous method of testing/implementation
> was to creating a new test library for each project, compile programs
> there, copy objects to the production library after testing,
> occasionally copy the source member to the production source library,
> and then delete the test library. 
>
> Finally, can anyone tell me the benefits of giving all of the users
> *ALLOBJ special authority and setting their group profile to QPGMR?
> What about the users that have *SYSOPR as their user class that aren't
> really system operators?