Jerry,
First thing to point out is the OT_MAX_MEMORY is an (optional) variable
which allows you to specify the maximum amount of memory that the
translator (otrans) can use before swapping to disk. What it means is that
OT_MAX_MEMORY doesn't impose any size limit (actually the memory size limit
is 325 MB, which is OT_MAX_MEMORY+amount written to swap file) on the
transactions. I have used AI 3.0 (also in v1.41) for file sizes as long as
50-100 MB. Also I think in AI 3.1 they have OT_MAX_MEMORY's max value to be
32 (Just confirm with the GXS, 32 may be a valid value for AI 3.0 too)
Now about the performance issue, there are lot of ways to design u'r source
code to improve that. Those may or may not be suitable for you. I am
mentioning some of them to you:
1) if you have well defined spec. and you can figure out that some of the
segments never occur, then take those unused segments out. This is a
standard for outbound maps but if you are sure that your trading partner
will never gonna send some particular segments then cut those segment even
from the inbound Source models (But you must take into consideration the
risk of failure of maps in case u'r TP decides to surprise you with some
non-negotiated segments)
2) if you are using lot of mutually exclusive conditions, use CONTINUE at
the end of every mutual exclusive condition. Also keep the condition most
likely (or more frequently) to fulfill at the very top
e.g.
let's assume that the Condition A, B & C are mutually exclusive, and
frequency of C occurring is 10 times more than of B or A. In that situation
the most efficient code will be
[ CONDITION C]
ABC = xyz
---
--
CONTINUE
[ CONDITION B]
ABC = XYZ1
---
--
CONTINUE
[ CONDITION A]
ABC = XYZ2
---
---
CONTINUE
This set of rule is somewhat like CASE statement of C.
3) Use minimum number of constant assignment. For example you are assigning
"STOP" to as many as 30 instances of variable (may be at different point of
time), then instead of doing that assign VAR->STOP = "STOP" and use
VAR->STOP for those assignments.
4) Write target after a certain loops are read, and clear the arrays (I
think you are already doing that)
5) Minimize any customary INCLUDE function u might have created. Also use
less of user exit functions, if you are using them at all.
6) Remove any dead code, which actually is not useful but you left it over
there for some not very good reason.
Also don't forget to check kernel parameters for maximum size data (ask your
sys. administrator to do that)
I think if you implement some of these suggestions you may be able to
improve the performance. I hope it might be of some help to you.
Regards,
Sanjeev Gupta
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 08, 2001 3:48 PM
Subject: GEIS AI - 867 Outbound Mapping Question
> I am mapping an outbound 867 version 4010 transaction using GE-GXS (aka
> GEIS) Application Integrator 3.0 on a UNIX (Sun) platform. I have
> encountered a problem where one of the transactions within the outbound
> application file exceeds 16MB, which is the max memory size for a
> transaction (transaction in this case: Starting with the segment after ST
> to the last segment prior to SE) within Application Integrator. To
resolve
> this problem I have changed OT_MAX_MEMORY to 16MB within ".profile". I
> have also coded an ATTACH within the detail loop of the application file
> that writes out to the target model for each loop through the detail
> record. This appears to work, but has caused some serious problems with
> processing time. Does anyone have recommendations on how to improve
> performance, or a better way to resolve the max memory problem?
>
> Respectfully,
>
> Jerry
>
> =======================================================================
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
