× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Steve,

It actually can and could be worse. With Synon being a brute force code
generator it replicates routines whenever a file gets touched. A lot of
the performance work they did to improve performance removed
relationships that generated code. Can you imagine every program that
references warehouse always having to check if the warehouse was still
there, even after the record was edited the first time? Some record
entry transactions were spawning 100+ ios per enter key. It was also
difficult to have Synon use key access, it really does want to read the
whole file at times. Since every program opened every file just about
they ended up doing the shared open thing which is the big hit going
into a COM program.

They used to strip off a lot of the excess code but I don't think it is
done anymore, for example, look at all the hidden fields on a display.
Synon put every field on the display and then hides the unused ones. In
an old version of client access it actually blew up the terminal
emulator because hidden fields are transmitted to the client,
overflowing the buffers. 

Some code is also due backwards compatibility to older versions of RPG.
The multiple MOVEL's are an example of that.

Not to mention that old routines still in the model but unused still
generate programs and code even if they never get executed.  

It is a major accomplishment that COM works at all! The original six
month rewrite of OEI turned into a three year slog and thousands of
fixes since that time that we all still enjoy.

Regards

Konrad

-----Original Message-----
From: sjones@xxxxxxxxxxxxxx [mailto:sjones@xxxxxxxxxxxxxx] 
Sent: Thursday, November 06, 2003 1:39 PM
To: mapics-l@xxxxxxxxxxxx
Subject: This is what our ALF's buy?!?






This is actual code from program AMBQGDFR.  Notice field WUZ0NB.

OK define the field.  Nothing unusual here.....

 * Define work field &Chr
C                   MOVEL     *BLANK        WUZ0NB            1


Now blank out the field.... Must you tell the program to move blanks 4
times? Actually if you look farther down it blanks out WUZ0NB a few more
times.  I really wish IBM would disipline the compiler so we only had to
tell it to do things one time :-)

                   MOVEL     *BLANK        WUAAGX
                   MOVEL     *BLANK        WUZ0NB
                   MOVEL     *BLANK        WUZ0NB
                   MOVEL     *BLANK        WUZ0NB
                   MOVEL     *BLANK        WUZ0NB
                   MOVEL     *BLANK        WUCOCD
                   MOVEL     *BLANK        WUDXCD
                   MOVEL     *BLANK        WUZ0NB
                   MOVEL     *BLANK        WUZ0NB
                   MOVEL     'Y2U0005'     W0RTN
                   GOTO      OGEXIT
                   ENDIF


 Now what are they trying to do?  OH wait maybe MAPICS is getting into
the hardware business & are making sure everyone has to buy a really big
computer..

 C                   MOVEL     ALCQTX        WUZ0NB
 C                   MOVEL     ALCRTX        WUZ0NB
 C                   MOVEL     ALCSTX        WUZ0NB
 C                   MOVEL     ALCDTX        WUZ0NB


The field WUZ0NB is on 205 lines of code in this program.

I have seen the execute a subroutine that only has a BEGSR and a ENDSR
statement in it, but this takes the prize!!!

This is not the only field they do this with either in this program.  I
think we now have a better understanding why COM is so resource intense.

Hope everyone gets as good of a laugh from this as we did....

Steve Jones

_______________________________________________
This is the MAPICS ERP System Discussion (MAPICS-L) mailing list To post
a message email: MAPICS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/mapics-l
or email: MAPICS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mapics-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.