Re: Code limitations


Re: Code limitations


Every client that does much mod'g to P4211 runs into this problem. I've hit
it several times myself. The solutions you mention are the usual ones.
Others I've heard of include: converting whole subroutines into /COPY
books, and/or, converting whole subroutines into independent callable


Alan Caswell
Alan Caswell Consulting
Cell: 206-799-8823
EM: [email protected]


Active Member
RE: Code limitations


Yes, we have run into that same limitation in that same program. My
approach was to "externalize" (read copybook) some of the bigger subroutines
so that I could insert my code. A couple of caveats to that would be you
can not put a subroutine into a copybook if it contains a copybook, i.e. you
can put S998 into a copybook but not S999. Also, I have not been able to
figure out how to debug code in a copybook so if it is new and complex you
might want to keep it inline. How you structure it depends on the standards
of your shop, the complexity of the changes, how modular the code is, etc..
An example of what I did was to put S998 into a source member Z4211S998 and
insert the statement "C/COPY JDESRC,Z4211S998".

If anyone has a better way of doing it, I for one would very much appreciate
hearing about it.

Douglas Belcher
KV Pharmaceutical Inc.
St. Louis MO
Opinions expressed are not necessarily those of my employer

Doug Belcher
St Louis MO
Opinions expressed are not necessarily those of my employer


RE: Code limitations

I ran into this with the P4211 on a couple client sites. I just created the
S998 as a copy book. I forget what I called it something like C4211 and
added the source in the JDECPY library. This will free up hopefully enough
lines of code. I also made sure that there was documentation at the
beginning of the pgm as well as where the copy was.
Hope this helps.


Active Member
RE: Code limitations

Another solution is to convert it to RPGILE which does not have the code
limitations as RPG/400.
You also have to make copies of the copybooks and convert them as well.

This is a lot of work but when it is done you can mod the P4211 to your
hearts content.


Reputable Poster
RE: Code limitations

That happened to us also.

The IBM compiler runs out of "Objects".

If you search the archive of this mailing list you will see a few options.

JDE has a SAR # 3782087 that is 47 pages worth of deletes.
I didn't trust the deletes and didn't want to "Test" it for them.

I ended up converting the program to ILE. This option seemed to be the
There is also some code changes that need to be made to the SVR programs if
you want to be able to compile ILE programs from within SVR.

I still have some Faxes from the list member who sent them to me.
We have had NO problems with the P4211 sense we converted it.

We are on 8.1 cum 2 but if I remember correctly the gentlemen who sent me
the information was on 7.3

Hope this helps.

Scott Parker
Grote Industries, LLC
mailto:[email protected]

Scott Parker
Grote Industries, LLC.
WorldSoftware Version 8.1.2 AS/400 V4R5


Active Member
RE: Code limitations

We converted P4211 and its /COPY members to RPGIV to overcome the limit of
32,767 objects in the RPGIII compiler.
The SEU limit of 32,7nn statements is a separate issue, which we overcame
with extensive use of /COPY, placing statements in external source members.

We have modified the SVR programs so we can perform SEU editing and RPGIV
compiling with SVR. This last point is a convenience issue. You can
survive by editing and compiling outside of SVR. I can share these code
mods if you like.

Eric Lehti    Certified JD Edwards Professional
Fike Corporation, mailto:[email protected] * Phone (816) 229-3405 ext.
JD Edwards A73 Cume 10, AS/400 9406-730, OS/400 V4R4

Your comment: We have run into limitations in coding lines in the P4211
Sales Order Entry


Re: Code limitations

This approach can work. But, when you get updates you will have to retrofit or
convert the program and copy books to RPGIV. An easier approach that may have been
mentioned is to convert sections of the program to copy books (still a problem with
updates but at least you would not have to wory about the copy books)


wayne_severson wrote:
Re: Code limitations

I've run into this while using a 4th GL dictionary. This is an AS/400 "feature"
allowing only 32,xxx
lines for a program. I got around it by transferring the file to my PC, doing
the editing in Notepad,
transferring the file back to the 400, and then compiling. A nuisance to be
sure but there aren't
that many programs with that volume of lines - hopefully. If the compiler will
handle it this is one
way you to go.

We have run into limitations in coding lines in the P4211 Sales Order Entry
program. To enable us to proceed with our modification we removed blank
comment lines (placed by the Case Tool) and any other superfluous comment
lines, to gain back the space for code. I am curious if others have run
into this limitation and what method you used to deal with this? Also are
there any other programs that we need to be aware of, that are already so
long we may run out of lines?
Please advise.


Lynn Pryor
Client Svcs Mgr.
A7.3 CUM 11


Active Member
RE: Code limitations

I have been watching the responses on this issue and I have to throw in my 2
cents. PHD has not encountered this problem with P4211 (yet) so we have not had
the need to implement any of these work-arounds. However, it is clear to me
that each individual company using JDE should not have to develop their own
solution to this. If the user community can figure out how to change SVR
and/or P4211 to overcome these deficiencies, certainly JDE should be able to
solve it once and give all of us a single, well-designed, integrated, thoroughly
tested solution. If not, why are we paying the annual maintenance fee?

JDE: Are you listening?

Phil Rumschlag
MIS Director
PHD, Inc
Voice: 219 479-2321
Fax: 219 479-2807
email: [email protected]

Eric_Lehti <[email protected]> on 05/24/2001 08:21:54 AM


Reputable Poster
Re: Code limitations

Our problem was not with the Number of Lines. So moving sections of code to there own copy routine was not an option.

Our problem was with the number of Object the compiler could handle.

Yes these are 2 seperate issues.

But the way I see it the ILE approach is better because you will still run out of Objects in the near future. Moving code to copy books does not help reduce the number of objects. I talked to JDE about this and the said they had thought they had fixed the issue back in 7.2. Guess not.

Speaking towards Upgrates and Retro fitting. If your problem is only with the number of lines and you move code to copy books you will still have to "Retro" fit any Changes into either the Code or into your new copybook.

I guess its still 6 of one 1/2 a dozen of the other. IMHO.

Scott Parker
Grote Industries, LLC.
WorldSoftware Version 8.1.2 AS/400 V4R5


RE: Code limitations

Which is exactly why we will be taking a real hard look at maintenance this
year. Especially with the 10% increase we were just recently notified of.
We really have to take a look at the value this maintenance is providing.
We are very happy, well content because it is working, on A7.3.11 right now
and we plan on staying there awhile. A business partner provides fixes and
necessary mods to us.
RE: Code limitations


We had the same problem with P4211. there are actually two problems. It
sounds like you have hit the first one where the SEU editor cannot handle the
number of lines. We have done the same as you and also moved some of the
subroutines into copy books. If you continue to modify the program you will
eventually his a compiler limitation. We contacted IBM regarding this and
their suggestion was to convert the program to ILE. We opted to take some of
the subroutines which did not apply to our company and convert them to program.

The only other program that we have had a problem like this is the PO receipts
program (P4312).