RE: You bet!

["Michael Franchino" <Michael.Franchino@xxxxxxxxxx>]

I have definitely seen SYNON code do that..

IFM had a program that checked to see if PO's were received (3-way
match).. It would read through the ENTIRE IMHIST file looking for
completed receipts.. It didn't even use a Key for VENDOR or anything.
It would take 20 minutes for the screen to appear and it would have
exceeded the # of reads.. I think MAPICS put a fix in to limit the
search for X number of reads, which wouldn't work since it wouldn't find
the records.. I added a key to the lookup and the program went from 20
minutes to 1 second.

I understand that tools are used to produce these programs, but there
has to come a time where you just have to say, well.. The tool is done
and we have to fix this problem by hand.

Michael Franchino
Custom Systems Corporation
http://eax.cussys.com
973-726-0202 X214 



-----Original Message-----
From: mapics-l-bounces@xxxxxxxxxxxx
[mailto:mapics-l-bounces@xxxxxxxxxxxx] On Behalf Of Konrad Underkofler
Sent: Thursday, November 06, 2003 3:37 PM
To: MAPICS ERP System Discussion
Subject: You bet!


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.


_______________________________________________
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.