Kbase 3078: Why Progress has 63K module (.r) limit and how to avoid it.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/10/1998 |
|
Why Progress has 63K module (.r) limit and how to avoid it.
900531-sec02
INTRODUCTION: Date Last Modified: 6/26/90
=============
This Product Services Technical Support Knowledgebase entry explains
the causes of PROGRESS error 287 "Request too large for edit buffer.
Increase -e" and how to fix it. It also explains why PROGRESS limits
the size of compiled (.r) code to 63K.
PROGRESS ERROR NUMBER: PROGRESS ERROR TEXT:
====================== ====================
287 strnal: request too large for edit buffer.
Increase -e .
POSSIBLE CAUSE OF ERROR:
========================
If your have already set the edit buffer (-e PROGRESS Startup
Parameter) to 63 and your procedure does not compile, then the
compiled (.r) code is larger than the 63K PROGRESS limit. This can
happen while you are developing your application or when you compile
your application on a cpu different from the one you developed on.
The compiled code (.r) size may also increase when you upgrade your
application to a new PROGRESS release.
For example, you can look at the size of the procedures (.ps) found in
the PROGRESS Data Dictionary directory (prodict under dlc) and you can
compare the size of these procedures to the size of the same procedures
on other cpu or PROGRESS version you plan to port to. The average
percent difference between the size(s) of the files gives you an idea
of how much larger or smaller your application will be when you port
to that new environment.
BACKGROUND:
===========
Why PROGRESS limits the size of compiled code to 63K:
For operating systems OTHER than DOS and Xenix the reason PROGRESS
enforces a 63K limit for compiled (.r) code has to do with the size of
the pointer used to address memory. Currently PROGRESS uses a 16 bit
pointer that can not address more than 64K of memory at one time (2 to
the 16th or 65536). To stay within this limit (which includes header
information) PROGRESS determined the maximum compiled (.r) code to be
63k (2 to the 16th minus 1024 resulting in 64512).
DOS and Xenix segment memory into 64K increments so the maximum
contiguous memory PROGRESS can address in any 1 segment is 64K. To
stay within this limit (which includes header information), PROGRESS
chose 63k for the maximum compiled (.r) code size.
Since portability is a major issue, by having a maximum compiled (.r)
code of 63K across all operating systems assures the developer that a
procedure that compiles on a machine that runs UNIX, for example, also
compiles on a machine that runs DOS, BTOS, or VMS.
DOES ERROR INDICATE CORRUPTION: IF SO, WHAT TYPE:
=============================== =================
No N/A
CORRECTIVE MEASURES:
====================
If the error occurs when compiling a procedure, the compiled (.r) code
exceeds the 63K limit. You must break the procedure into smaller
pieces. For example, if proc.p is too large, break it into two
procedures, proc.p and proc1.p. The last statement in proc.p should be
RUN proc1.p.
To avoid reaching the 63K compiled code limit, make it common practice
to set your edit buffer (-e PROGRESS startup parameter) to no more
than 50 when developing and compiling procedures. This allows you to
port your application across multiple environments without reaching
the limit 63K limit.
ONLINE PROCEDURES OR UTILITIES:
===============================
None
REFERENCES TO WRITTEN DOCUMENTATION:
====================================
System Administration Guide - Chapter on Startup and Shutdown
(PROGRESS Version 5)
System Administration Guide II - Chapter on Startup Options
(PROGRESS Version 6)
Progress Software Technical Support Note # 3078