The Program From Hell
John Smith
hell to work on at my shop.
Here are some details so you can sympathise with me:
* It's an RPG/400 program that handles my organisation's main day-to-day,
coal-face data entry and processing. Add too many lines of new code and the
compiler error CPF6316 comes back, barking about the 32k source code line
limitation. So, as you can imagine, it's a monster.
* The programming style was initially quite good, but subsequent
enhancements have been sort of stream-of-consciousness.
* Already, parts of the program have been split out into separate programs.
But, doing this with much of the rest is problematic: the compiled listing
is over 900 pages long and while I can get a handle on what's happening from
a user's perspective, making good cut-and-paste decisions within the code is
scary.
Performance is not so much of an issue because the program runs well enough
now and we have a brand new AS/400 820 to play with.
Doing nothing is not an option because we are merging with another company
and we have to build in at least some of the functionality they would
require. And, dumping it and buying something else is likewise off the
agenda.
The only option I've come up with so far is to manually insert all the bits
of QCPYSRC (did I mention there are heaps of these?) and convert the program
to RPG IV. While this will let me add more code beyond the 32k line limit, I
still have to understand and maintain the thing.
I'm searching around for other jobs pending that inevitable moment when my
boss comes and asks me how much progress I've made. In the meantime, has any
one else been in the same situation?
Craig Caulfield.
Francis Lapeyre
Software www.linomasoftware.com.
It's an excellent value. We've been using it for a couple of years now.
It will also update source that has already been converted to RPG IV. It
will copy all of the /COPY members and convert them if you want. The
trial version gives you a nag screen and won't let you convert more than
1 member at a time, but otherwise, it's fully functional. You can set
the options to convert as little or as much as you want to RPG 4 syntax
(e.g., EVAL). I used it on a similar program that had exceeded the
50-file limit, and now we have a better understanding of how it works,
simply because we're able to follow the logic flow better.
--
Regards,
Francis Lapeyre
"Facilius est camelum per foramen acus transire quam divitem intrare in
regnum Dei."
(Mk 10:25)
"John Smith" <so...@microsoft.com> wrote in message
news:3EFD4B02A6AAC6C3.86ABB496...@lp.airnews.net..
.
Jim Barnes
advice so here it comes: 1) Get a good tool that can read source and
flowchart the code (ie, AbstractProbe) 2) like all tasks this large, you
have to break it down into manageable pieces - this will enable you to
understand and start breaking this application into modular RPGIV
procedures. There is not a simple, pain-free solution to this problem. But
breaking it up into pieces and working with maybe 5-7 at a time, helps to
overcome the overwhelming feeling of inadequateness and relieves some of the
anxiety that comes from creatively distracting yourself and doing nothing
but dreading it.
ILE is your solution. In all likelyhood most of the code in this
application are business rules that are currently being used in more than
just that one application. By isolating those and pulling them off to a
separate module(s) and creating a service program, you can create binary
(rather than source) reuse. Currently, these rules are duplicated in each
process where they are used (meaning each time a change is required, you
have to go to each process and make the same change). This will eliminate
the need to do that in the future and ensure that a change in a business
rule is consistently implemented. Create discreate units (one or more
procedures) that can be atomically tested and mapped to your current
business model. If it don't match you business model - it ain't gonna work.
This mapping will also assist you in properly enhancing it later for model
changes - like acquisitions tend to initiate. In my application, I had 13
acquisitions to deal with in 1 year. If I had not followed this procedure,
I would not have been able to keep up with the changes that the acquisitions
forced.
Good luck - I feel your pain!
"John Smith" <so...@microsoft.com> wrote in message
news:3EFD4B02A6AAC6C3.86ABB496...@lp.airnews.net...
B Morris
> The only option I've come up with so far is to manually insert all the bits
> of QCPYSRC (did I mention there are heaps of these?) and convert the program
> to RPG IV. While this will let me add more code beyond the 32k line limit, I
> still have to understand and maintain the thing.
When converting to ILE RPG, you can get CVTRPGSRC to merge in all the
/copy files for you. See the EXPCPY parameter.
Barbara
John Smith wrote:
> ...
> The only option I've come up with so far is to manually insert all the bits
> of QCPYSRC (did I mention there are heaps of these?) and convert the program
> to RPG IV. While this will let me add more code beyond the 32k line limit, I
> still have to understand and maintain the thing.
> ...
Charles Wilt
<F5DC3728266B5298.E320273D...@lp.airnews.net>,
j.ba...@pentasafe.com says...
> Yes, I have been in exactly this situation. I assume you are asking for
> advice so here it comes: 1) Get a good tool that can read source and
> flowchart the code (ie, AbstractProbe) 2) like all tasks this large, you
You might also want to check out Arcad Source Code Analyzer, its free and
from my experiences to date seems to be a very nice tool. One thing, you
may find it helpful to have a larger monitor, I've only got a 17" and its
hard to see everything I want to see.
http://128.241.180.202/arcad/uk/freewareeng.html
HTH,
Charles
John Smith
I've followed all the good advice above and converted the monster to RPG IV.
But, I thought I would add some more lines of source to see if I could
recreate the compiler error. Instead, I didn't get as far as compiling and
SEU came back with:
"EDT1022 Attempt to add lines beyond 32764 ignored"
The second level help suggests that the 32k line limit may be a limitation
of SEU rather than a compiler issue. While I can't get the numbers to add up
exactly, it seems that comments are included in the count.
So, I guess you can see the quick and dirty solution I'm thinking about...
John Smith
I've followed all the good advice above and converted the monster to RPG IV.
But, I thought I would add some more lines of source to see if I could
recreate the compiler error. Instead, I didn't get as far as compiling and
SEU came back with:
"EDT1022 Attempt to add lines beyond 32764 ignored"
The second level help suggests that the 32k line limit may be a limitation
of SEU rather than a compiler issue. While I can't get the numbers to add up
exactly, it seems that comments are included in the count.
So, I guess you can see the quick and dirty solution I'm thinking about...
John Smith <so...@microsoft.com> wrote in message
news:3EFD4B02A6AAC6C3.86ABB496...@lp.airnews.net...
B Morris
/copy files and generated I, O and D specs for externally described
files and data structures.
RPG IV programs _can_ run into size limits where the RPG compiler likes
your code fine and the system gives an error, but it's much harder to
hit the limits. And it's not just a matter of bigger limits; the limits
are different because the generated code and underlying program
architecture are completely different.
Barbara
John Smith wrote:
>
> An update about the program from hell.
>
> I've followed all the good advice above and converted the monster to RPG IV.
> But, I thought I would add some more lines of source to see if I could
> recreate the compiler error. Instead, I didn't get as far as compiling and
> SEU came back with:
>
> "EDT1022 Attempt to add lines beyond 32764 ignored"
>
> The second level help suggests that the 32k line limit may be a limitation
> of SEU rather than a compiler issue. While I can't get the numbers to add up
> exactly, it seems that comments are included in the count.
>
> So, I guess you can see the quick and dirty solution I'm thinking about...
> ...
John Smith
It turns out that SEU is really the problem. I found a posting at IBM's web
site dealing with exactly the issue. While the source line limit has been
removed, SEU isn't capable of dealing with anything of this size and there
are no plans to address the issue because of SEU's "design considerations".
So, if you want to create and maintain programs beyond 32k lines, a third
party editor is needed.
I jokingly said before that the solution in my case was to strip out
'unnecessary' comments. But, this is exactly the task I've been assigned.
All good software engineers will be grinding their teeth right now...
Craig.
John Smith <so...@microsoft.com> wrote in message
news:A7E6A0EAC235975B.A49535A3...@lp.airnews.net...
Charles Wilt
regret later and which will only buy you a limited amount of time any
ways. Why don't you break the program up into seperate modules? At the
very least, assuming the program uses subroutines, you could make the
subroutines into procedures in external modules with very little effort.
Now if the program is one big long main...well that's going be more
difficult to handle, but IMHO you might as well bite the bullet now do a
complete redesign and start enjoy the benefits of a modernized ILE RPG
app. After all even the most clueless of management will understand that
as it is, you can't add any more lines of code to the program without
slitting your own throat. Besides, think of how much easier it will be
to make that next change ;-)
Charles
In article
<EE7080E6268310D2.72225D06...@lp.airnews.net>,
so...@microsoft.com says...
Karl Hanson
>
> Another update...
>
> It turns out that SEU is really the problem. I found a posting at IBM's web
> site dealing with exactly the issue. While the source line limit has been
> removed, SEU isn't capable of dealing with anything of this size and there
> are no plans to address the issue because of SEU's "design considerations".
>
> So, if you want to create and maintain programs beyond 32k lines, a third
> party editor is needed.
>
> I jokingly said before that the solution in my case was to strip out
> 'unnecessary' comments. But, this is exactly the task I've been assigned.
> All good software engineers will be grinding their teeth right now...
>
Did you try EDTF?
Also, at v4r5 the new iSeries Tools for Developers PRPQ provides Emacs
and Ez, two
graphical style editors supported via PASE and XWindows.
http://www.iseries.ibm.com/developer/factory/tools/
--
Karl Hanson
Thomas Raddatz
you may try Codestudio at http://www.rpgiv.com/codestudio/ or you may look at
Code/400. Hopefully these tools do not have a limitation. Code/400 is also
available as a trial version. The drawback is that there is a limitation of the
numbers of up and downloading source members.
E-Mail me directly if you need further information.
Thomas Raddatz.
John Smith schrieb:
--
*=====================================================*
e-mail Adresse:
Thomas....@tools400.de
Homepage:
http://www.tools400.de
*=====================================================*
Joep Beckeringh
Before stripping comments that are unnecessary until you would like to read
them, why don't you cut the member in a number of sections and reduce the
main program to an equal number of /COPY statements?
Joep Beckeringh
Databasics
>Another update...
>
>It turns out that SEU is really the problem. I found a posting at IBM's web
>site dealing with exactly the issue. While the source line limit has been
>removed, SEU isn't capable of dealing with anything of this size and there
>are no plans to address the issue because of SEU's "design considerations".
>
>So, if you want to create and maintain programs beyond 32k lines, a third
>party editor is needed.
Why not just break it up into several members and use /copy to combine
them when you submit the compile?
>
>I jokingly said before that the solution in my case was to strip out
>'unnecessary' comments. But, this is exactly the task I've been assigned.
>All good software engineers will be grinding their teeth right now...
>
Regards, Worley
B Morris
two parts and at the end of the first part, do a /COPY of the second
part. (Or three parts or four.)
(RPG IV supports nested /COPY)
Barbara
B Morris
introduced by splitting a module using /copy files: it makes it
difficult to search it while editing. You have to remember that it's in
several parts and search all the parts.
Brrr - I'd rather chew rusty nails than maintain a split file, but I'd
rather maintain a split file than maintain code without comments.
Barbara
Databasics wrote:
> ...
> Why not just break it up into several members and use /copy to combine
> them when you submit the compile?
> ...
Worley Barry
>Brrr - I'd rather chew rusty nails than maintain a split file, but I'd
>rather maintain a split file than maintain code without comments.
>
Well, RPGIV copy members are so much better than RPT copy
members that I don't find much of a problem with them. I mean
the errors in the program listing tell you the copy member name
and statement within the copy member. As long as I can view
the entire listing in the split screen and have a couple of
group jobs doing SEU for different members, I like copy members.
Regards, Worley
Ken S.
On Fri, 02 Mar 2001 22:28:41 -0600, Worley Barry
<wor...@databasics.hurst.tx.us> wrote:
>As long as I can view the entire listing in the split screen
>and have a couple of group jobs doing SEU for different members,
>I like copy members.
I don't like copy members except for standard H-specs and for
prototypes, but in the case of this huge program, that certainly
sounds like the best way to go.
Ken
http://www.ke9nr.org/
Opinions expressed are my own and do not necessarily represent the views of my employer or anyone in their right mind.
Wilbert van der Hoeven
You could use (the trial version of) Editor/400 (www.statement400.com)
to overcome the size limit and the /copy problems.
Among a lot of other benefits, Editor/400 can handle much larger
programs and can temporarily copy the copymembers into your source so
you can read and search them like ordinary sourcelines. Also Editor/400
can be a great help in analyzing and documenting your program.
Regards,
Wilbert van der Hoeven
Statement/400 Software b.v.
www.statement400.com
"Ken S." schreef: