Synon 2E - Development Standards (Performance)

Synon 2E Development Standards - Performance 

Update: 05/12/2025 - I have created a page for all standards related posts.

https://leedare-plex2e.blogspot.com/2025/12/synon-standard-posts-all-in-one-page.html

This is the first part in a complete series of articles I intend to post regarding development best practices and standards for the CA 2e (Synon) development tool. The aim of publishing the guides is to educate, collaborate and enhance the standards by receiving community feedback. After all, no one person can know everything but the wider community can contribute.

Many of these tips I have learnt over the years and quite a lot have been sent to me by interested parties around the world. A big thank you to you all.

I will publish the complete documents on the 2E wiki (soon) with full acknowledgements. (See my links section below).

In the meantime I will publish some selected extracts on this blog just to get your thought processes flowing.

Performance

There are many considerations when programming for performance in CA 2e. A few are highlighted here. This is by no means an exhaustive list. My next technical post will relate to Defensive Programming techniques......

I'd be interested to hear of others from the community in general and would be happy to include them on this blog and the final wiki document.

Some development standards to help with Synon 2e performance

Drop unused relations where possible and set others to appropriate level. i.e. OPTIONAL or USER etc. This cuts down unnecessary code and processing as well as making your action diagrams more easily navigable.

Avoid FLD for passing parameters for non command line type programs. Will use less PAGs.

Tactically use *QUIT to reduce I/O. Especially when programs have lots of nested validation logic. Very useful when validating. Use the *QUIT inside subroutines to halt further processing. Provides cleaner message feedback to end user and reduces response times.

Avoid Dynamic Selection Access Paths.

Avoid Virtuals, especially Virtuals with relations to files with Virtuals. Virtuals have their place. Query access paths or in scenarios where they are always used. Best practice in this area is to avoid virtuals and to get data as appropriate.

Ensure programs do not close down if called iteratively.e.g. in a loop or inside USER: Process Record etc for a RTVOBJ or PRTFIL etc. Typically used for externalised RTVOBJs.

Consider sharing ODPs.(Open Data Paths)

Consider usage of shared subroutines. Minimise the amount of code and reduces object size and makes debugging easier.

Consider usage of Null Update Suppression within your CHGOBJs. Very useful for batch programs.

Avoid unnecessary selector/position fields on subfile selectors.

Avoid contains (CT) selection on control panels

Ensure arrays are appropriately sized. Too large they will consume more memory.

Reduce file I/O by loading small reference files that are regularly read into arrays upon opening the program. Good examples here wsould be files like TRANSACTION TYPE or XYZ RULES.

Reduce I/O by only getting reference data only on key change. This will depend on the chosen access path of course.

When writing to an IFS write fewer larger chunks of data rather than multiple small chunks. Overhead is opening, positioning and closing the IFS file.

Pass reference data down through call stack rather than re-retrieve in the lower level function.

Consider physical file access paths for fix programs (version 7.0+) or write SQL to perform the basic updates.

Use OS/400 default values to initialise fields on a database file rather than write a program.

CHG/CRT v CRT/CHG. Use the appropriate one depending on likelihood of the records existence.

Avoid *CONCAT and *SUBSTRING native in 2e for long string manipulation. If concatenating for long strings it is possible to keep a counter of where you are to save the concatenation operation time to identify the current position in the string.

Avoid RTV message to build strings with high usage.

Consider DSPFIL instead of DSPTRN, especially true if de-normalisation is designed in the database with any total duplicated into the header record.

Do not perform a *RTVCND for blanks. Check for blank first in the action diagram.

Consider a database file field for *RTVCND if approriate.

Be aware of the affect of a scan limit for strict selection criteria as the screen will not pause load processing until the subfile if full or EOF reached. Particularly for large files.

Consider the naming conventions of your access paths to ensure that underlying indexes can be shared when key subsets are apparent and ensure that are built and implemented in the correct order to reduce indexes.

Ensure access paths have correct maintenance option i.e. *IMMED, *DLY or *REBLD.

Thanks for reading the

Synon 2E and Plex Emporium by Lee Dare (A developer blog). 

Lee.

Synon 2E - Development Standards (Defensive Programming)

Synon 2E Development Standards - Defensive Programming

Update: 05/12/2025 - I have created a page for all standards related posts.

https://leedare-plex2e.blogspot.com/2025/12/synon-standard-posts-all-in-one-page.html

Some of these are advanced tips.

Part two in the series and takes a look at defensive programming techniques and how these help you to create reliable programs.

The following a guidelines for creating robust code.

Always check for a divide by zero (runtime) error by checking the divisor field for zero value prior to performing the *DIV operation.

Never move numeric fields into a field with a smaller domain. With RPG this can cause truncation of the value and with RPG ILE Pre 8.0 will cause an RPG ILE runtime error.

Ensure that your iteration values and counters are large enough to cater for your anticipated maximum.

Ensure that your field sizes for database attributes are sized sufficiently to cater for the number of records anticipated.

Ensure that your arrays are sized to cater for the maximum number of array records anticipated. Thus avoiding array index out of bounds issues. Remember to balance this with not overly sizing the array and thus causing a performance degragetion.

Always ensure that any substring operations utilising position and length parameters are within the range of the target field. Thus avoiding substring out of bounds.

Remember to check the function options for your function to ensure appropriate behaviour, especially close down program and reclaim resources.

Never use the WRK context in new programs. Use LCL and HLL. If you choose to fix up old WRK fields, remember to check all other internals within your object and ensure that fields aren't used. This used to be used a trick in the old days to bypass the paramters passing limits. This was pre-arrays and when structure files where a pain.

Avoid HLL User Source and Programs. If you do write user source for RPG first convert program to RPG ILE and write one user source. The sign of a well managed and maintained 2E model is the percentage of HLL code versus generated code. If your models are more than 5% HLL then you have issues and a history of developers who have misunderstood the purpose and philosophies of model based development. IMHO.

Always pass parameters to user source. Do not rely on the generated field names.

Avoid use of CON context as these values are not available for impact analysis and localisation.

Avoid manual source modification. Use a program and the pre-processor directives to amend code automatically.

Source Modification – Special Notes.

Manual source modification must be avoided at all costs. If source is required to be overridden then a source modifying program should be written to automatically perform this function after generation and before compilation using the pre-processor.

In Summary:-

- Do NOT consider source modification unless absolutely necessary.

- Avoid the use of fields that use incremental counters for naming i.e. LCL Context YLnnnn.

- Avoid adding parameters above a field declared as a modified field. Therefore, always try to ensure that your fields that are parameters that are modified are at the top of the parameter declaration list.

- Try to avoid usage of fields higher than 32k. If 64k is required considered looping in 32k blocks as the 64k limit would one day be exceeded.

- Consider a naming standard to help you to easily identify a modified program and its modifying program.

- Consider centralised methods to ensure source modification programs have been successful rather then depend on a developer having to manually check the modified source.

Thanks for reading the

Synon 2E and Plex Emporium by Lee Dare (A developer blog). 

Lee.

The "Wooo! moment" Factor

Wooo! I love coding!

This is another one of my general life blogs and follows up from my recent article about what makes a good programmer where I refer to a ‘Rocky Balboa’ moment that encompasses everything about being a great computer programmer.

I would like to clarify that this post has nothing to do with the incessant number of reality talent shows and is not in anyway linked or endorsed by those in the entertainment industry.

However, I recently went to the Smackdown/ECW world tour event here in Auckland, New Zealand.

Like most of the other hardcore WWE fans I registered for the internet presale, logging in a minute or two before midday and continually pressing the refresh (F5) button in Internet Explorer until the ticket selection page popped up. A quick combo-box click later and an anxious wait ensued whilst the system allocated my tickets and then the “Woo! moment” came.

I knew it was a full on “Wooo! moment” as it did turn the heads of a few people in my office.

The reason being was that I was lucky enough to get front row tickets, seat numbers 1 and 2 which was not only the closest you can get to the ring but also the closest you can get to the entrance ramps for when the wrestlers strut their stuff as part of the pre bout entertainment. The arena held thousands and thousands of people and to get to two best tickets in the house was reason enough for me to celebrate. Actually, celebrate for my daughter, as she is the wrestling fan. I just have transient knowledge.

For anybody that follows the WWE Wrestling you will probably know a guy called Ric Flair. He is a 16 times world champion as well as being regarded as one of the all time greats. He is also famous in WWE circles for his tag line “Wooo!”. So much so that the last three shows we have been to, Ric Flair has never been there, he has been retired since March 2008 and yet everyone was shouting “Wooo!” as the excitement began to build in the arena.

Now for me life is about experiences and the memories thereafter. We have both good and bad times that shape us all individually in some form or another. And one hopes that over the balance our lifetime that there are many more good times rather than bad and it is these good times that I affectionately refer to as the “Wooo! moments”.

Now if we spend on average a minimum of between 50 and 70 hours travelling and working each week I often ask myself why do people put up with a job or a career that doesn’t provide them with “Wooo moments”. I have been pretty lucky in this regard over the years. I am an analytical person and love computers. As a child at my local school jobs fair in 1983 I expressed that I wanted to be a computer programmer. After a few minutes searching the database (list of jobs on paper in those days). I was asked if I wanted to do commerce, a funny choice at first until you realise that it was the closest alphabetically to computing.

How times have changed.

Now everyone wants to do computing and whilst there are now more areas to become expert, I also believe that computing remains at risk of be dumbed down. I say this because many people are getting into computing because they see a higher than average salary trend, they only see the exciting parts of the job glamorised by Hollywood films or they see it as easy.

For me I got into computing because of the “Wooo! moments” and I continue to adore this line of work. But also as I get older I also find myself enjoying the fact that others around me are having their own “Wooo! moments”. I'm a little like grandparents who enjoy watching those cute little bundles known as grandchildren.

But of course it doesn’t stop there.

You may have a job that only has one or two “Woo!” moments in an entire career span. A recent example was the recent mission to detect life on Mars. Some of those guys had been working on that mission for 10 years or more. But that “Wooo! moment” when that million dollar craft landed on Mars and started to do its stuff.

Wow!!!!

The screams of joy and relief I could hear just by watching the footage on a 21” TV was there for the world to see.

The “Wooo! moments” are what drive me to get up each day and if you find yourself having less and less of these moments whilst at work.

Ask yourself why?

Work does dominate and validate many of ours lives so you might as well enjoy what you are doing. But please don't moan to me about your job. Do something about it.

Please, ensure that you do. Life is too short.

Thanks for reading the

Synon 2E and Plex Emporium by Lee Dare (A developer blog). 

Lee.

The lunchtime effect and an insane piece of Job’s Worth.

Government departments are run ineffectively!

The other day I had to visit the immigration department to renew my daughters’ residency visas.

This is a process that you have to repeat every time you renew your main passport because if you want to re-enter the country you will definitely find it useful to have this little slip indicating that you are a legal alien tucked up nicely in there somewhere.

The process is quite simple. You bring your old and new passports, fill out a form and pay the fee.

Simple!!!

A short time later (minutes or hours) you leave feeling robbed but also happy in the knowledge that you’re able to travel to and from your adopted homeland.

The key, as you all know, is to avoid the queue or at least pick the day when the most counters are open. We were going to the hospital as my wife had an appointment for one of her ailments so the time we had available in between the school runs and the appointment was basically lunchtime.

Or put it another way. Rush Hour. Usually when you have to go somewhere on a time constraint then you will always pick the bad day. Well for some reason it was empty on this occasion. We were through to the application triage officers within minutes. These guys check the forms and provide assistance before you get to a case officer.

This obviously is to avoid you waiting for a period of time to find out that you have completed the wrong form or worse still used the wrong type of pen colour.

At this stage I leant over the counter and enquired as to the lack of visitors. You see. I have been to the immigration department before and joined a queue that left the building. To give you another indication in the old building there was a portable café outside to serve food and drinks………..

Apparently it was just a slow day. I was wondering whether this was as a result of what I refer to as the lunchtime effect. I am sure I am not the only one out there but it could be due to the fact that I am an IT guy I was thinking. Why was this room empty? Was it because others had considered that it was lunchtime and therefore made the assumption that it would be busy, thus avoiding the ‘so called’ busy period when there are more people and less staff!!!!

Actually, who cares? I got the visas sorted in record time, but, I am grateful for all those who were considerate to enough to think of the lunchtime effect.

But the jobs worth moment is certainly worth writing about. For one reason alone, I am adamant that the person who came up with this rule was not an IT guy as there is no binary representation of what I witnessed. No IT guy in the world could have come up with an answer other than 0 or 1 (On or Off). And this to me is 5.66645645- and fifteen sixtenths.

As we were applying for three visas the costs were $100.00 per application. This makes sense I guess. Until you hear the triage officer ask “Are either of you two (Wife and I) applying for the visa also?”.

Our answer this time around was “No” because our passports are 10 years and the kids are 5 years in renewal intervals. “Shame” was the response, she then continued, “Because if one of you i.e. principal applicants are applying as well we can do this as one application with 3 dependents and therefore you will only be charged one off fee of S100.00.”

So the logic is that we will do the extra two applications and produce 5 instead of 3 visas. Key in details for 5 people and not 3, print, remove and secure 5 visas in the passports and not 3 and we will do that for one price.

But as a principal applicant isn’t applying then we need to treat it as 3 separate applications!!!!!!!!!!

If someone can shed any light on this I would be grateful. Until then I am proud to call myself a Software Development Professional. I certainly wouldn’t want to explain the aforementioned rule for my living or associate my name with inventing this process.

Thanks for reading the

Synon 2E and Plex Emporium by Lee Dare (A developer blog). 

Lee.

What makes a good software developer?

I have decided to move on from my current role after over four years working at my present company. My reasons are varied and plentiful but as always the lure of a fresh new challenge often commands the majority of my thoughts.

I have started once more on the interview merry go round, first with agents and then in the coming weeks with potential employers. This is an interesting time in my career and certainly a change I am looking forward to albeit a little nervously as I have only ever had three IT related job interviews in my life.

During my early stages of interview with one particular agent I was asked a really good open question. The question was “What makes a good software developer?”. I waited no more than 2 seconds before I began rattling off my opinion. Normally in these situations you take the time to consider what you want to say and then lead up to the answer.

This felt different.

I guess this is because although I have never answered this question before (personally or via my blog), I have hired enough developers and non-developers over the years to understand what I believe a good developer to be. After all, one of my own interview questions to potential new hires is “Why software development for a career?”

I ask this question as I want to know what motivated them to get into software development and what maintains that desire to be a software developer. At my last firm a new project manager joined and we got talking about stuff. You know, the technical stuff. It was quite obvious to me that this guy didn’t want to be a project manager and that he still harboured that technical development desire. I knew this because as a project manager he would say stuff like “Worst case I can write that program.” or “Couldn’t we do this in x language or y language.” It was pretty obvious to me that this guy couldn’t let go, and this is what I look for.

For me the number one thing is the passion. I want to see this in the eyes of the candidate as they express to me their achievements and technical prowess. I look for the body language that backs up these passionate views.

I have been part of and built software development teams. I have written in other posts that you do need a mixture of people at varying stages in their careers with a good balance of personal motivating factors. Passion is certainly the one I look for when I am considering the lead roles within a team. The reason being that I believe as a lead developer you must bring others on by example.

Other factors to look for, especially for a permanent employee are:-

* Longevity in the industry and loyalty to an employer or two.
* Proof of learning multiple languages and having the desire to adapt to development trends.
* Good understanding of general development concepts and practices.

These are pretty generic but with passion, loyalty, desire, adaptability and a good all round understanding of development I believe I can teach any developer the technology of the month.

Without these attributes I guess you could be selling your business short. If I had to choose one then passion is the one I would go for.

If you see a developer struggling with some code all day but eventually they let out an enormous scream of relief as they finally solve their issue, jump up and then start punching the air in delight in the style of Rocky Balboa.

I’ll have that person in my team any day.

Thanks for reading the

Synon 2E and Plex Emporium by Lee Dare (A developer blog). 

Lee.