Home > IT Answers > AS/400 > SYNON vs COBOL
Rituraj
0 pts.
 SYNON vs COBOL
AS/400, RPG, Application development, CLP, RPGLE, Development, DB2 Universal Database
Hi All,
This query is related to performance. I am currently in the process of changing an application from COBOL to Synon. The application uses a lot of I/O involving files. Upon converting the application to Synon, I find that the performance has declined - COBOL takes 8 minutes whereas Synon is taking 35 minutes. I have tried using arrays for faster I/O but the time did not improve much. Does it mean that for applications involving large calculations, COBOL is better? Are there any other ways I can improve synon application's performance? Your experience and advice will definitely help me.

Thanks - Rituraj.
ASKED: Nov 7, 2006  11:27 AM GMT
UPDATED: December 25, 2009  4:20:00 AM GMT
RELATED QUESTIONS
TomLiotta
66,990 pts.
Answer Wiki:
Good morning, I'm not a SYNON expert but from COBOL there is something you must see:

COBOL creates an executable package does not need the environment for running, ?does SYNON the same?.

In COBOL all variables are predefined and allocated during the compilation time. ?Does SYNON the same?.

A COBOL program is almost 80% pure machine code, is the second fastest in execution (FORTRAN is #1) and all operations and routines are loaded "before" execution (are included in the execution package" not during execution, maybe there is the difference.

COBOL works with packed decimal not binary coded there is no need for conversion, just think on that.

=======================================================

COBOL is for writing programs. Synon is for writing entire applications.

Synon is an "application generator". Applications generated by Synon can consist of COBOL or RPG programs plus all of the files of all types that make up an application. The purpose is to design an application model and then have Synon generate the application.

Once the model exists, all future maintenance is done by altering the model and regenerating the app. All descriptive aspects of the app are automatically kept in sync with the app itself. The value is in the future maintenance.

As an application generator, it is reasonable to expect performance to be reduced out of the generated code. I don't quite get the "8 minutes vs. 35 minutes" description though. It's rare that anyone ever has any way to say how long an "application" runs. Usually the best that can be done is to say how long a specific functional component might run.

So, you must have one COBOL program that you diagrammed (in an action diagrammer) in Synon and then generated. The original and the generated copies take the two different run times to complete.

How much experience do you have? Is the entire application finished in Synon? Or is just an isolated function done? Was the function "redesigned" or did you bend Synon to accommodate existing structures? Did you know which functions to include from Synon or did you have to make a lot of guesses? Do you know yet if the Synon specs are appropriate?

Most importantly, are you intending to do the whole thing in the same way or are you going to use Synon as it's intended?

If this is going to be a program by program conversion, it's a definite waste of time and money. You'd be better off with a product such as ProGen. Although that's also referred to as an application generator, it is well suited to being a "program" generator. However, IIRC, it only generates RPG.

But if you intend to go with a generator, the language shouldn't make any difference. You shouldn't look at generated code anyway. Work with the specs instead.

Anyway, I obviously can't answer your question because there's nowhere near enough info to say why run times would be so different. I hope I said enough to help you think about the situation and to make some tentative plans.

Tom
Last Wiki Answer Submitted:  Dec 25, 2009  4:19 AM (GMT)  by  TomLiotta   66,990 pts.
Latest Answer Wiki Contributors:  inoboa   0 pts.
To see other answers submitted to the Answer Wiki View Answer History.
RSS - Discussions Help
Discuss This Question:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _



 

Rituraj,

I’m a MVS Cobol guy so I don’t know much about Synon. I do however, have some strong opinions about moving away from Cobol.

When you decide to use a language like Synon (or Linc, PacBase ….) you end up with dirty cobol generated behind the scenes. This cobol is then converted into really bad assembler and as a result you lose a lot of efficiencies. You do gain in coding time but ultimately the software is going to cost you a lot more.

Have a look at the file IO. Hopefully underneath it all Synon isn’t opening and closing your files for each IO. It may also be your definitions of numerical values involved in calculations. These need to be in hex (binary) for the calculation so if Synon is storing these as display formats instead of packed or binary then this will cause inefficiencies also. In saying all this I can’t tell you how to tune Synon.

Good luck with it.

Regards,

Jason

yarson
 0 pts.
 

The only thing I can say is that I agree with the previous answers : thing twice before changing from native Cobol or RPG to Synon. You better stay with your Cobol or/and RPG. Then You know what the code does. With synon you don’t know what is written behind the scene.
Good Luck

jadima
 0 pts.
 

I am a Synon guy. Way back. That was always our problem.
And caused our IT=VP to buy a HW-BULL (can I say that at an
IBM site?).
The Synon experts may disagree, but Synon just has too much
overhead! And the analyst above is correct too, it builds dirty Cobol or RPG dirty code.
It’s not a working man’s get it done code.

walter47
 120 pts.