Synon 2E It's (ELeM)entary, My Dear Watson

UPDATE: 06/12/2025 - Linked to a summary post dedicated to deep dive long form posts.

https://leedare-plex2e.blogspot.com/2025/12/synon-2e-technical-deep-dives.html

I've used this trick a few times so I thought I should share it on the blog before I get run over by a bus.

Often we (developers) are asked to produce or consume data files for integrations with 3rd party systems.  Even with the emergence of web services there are still many many times where the preferred method of interchange is file based, typically these are bulk (high volume) transactional exchanges.  Think payments between banks etc 

For the systems I've worked on we have solved this with .csv delimited inbound and outbound files.  We have also utilised fixed width files, the majority having old school multi-format layouts with a traditional header, detail and footer structure which has some advantages over .csv.

For now, I will also ignore that we could have also provided XML or JSON payloads as part of a real-time integration. 

As you can see, there are numerous ways to skin this cat. However, this is a 2E and Plex blog so for today, let us concentrate on:-

• How you might build and consume files into a 2E based application. 
• How can we create a multi-format flat file using purely Synon logic only?

Let's fire up a 5250 session and explore an unsung feature in 2E that helps remove the complexity of building these flat files.

What are we going to build? 

An extract file with a header record, 10 detailed transactional records and a footer which denotes both EOF as well as have a total  for basic validation.  In the real-word this may include hash total etc

An example of what this file data might look like is below.

Back in 2E, first define a file with one Known By (Numeric 9.0) should be suffice for most integrations and a second field (Has relation) of 'Flatfile Data' - Type TXT and length of 500 (or whatever length works for your environment). RP4 has better field limits than RPG. 

I've called my file FIXFILP.

Now we need to build the data record, usually you would start concatenating the data values together to meet the design specification of the receiving system and handle those pesky FILLER57 fields etc that always appear from somewhere.

This involves dozens (if not hundreds) of lines of code to concatenate the data.  The resulting action diagram is often difficult to understand and cumbersome to maintain.

What if there was an easier way to build up the data with the ability to easily reorder the fields and cater for changing field lengths.  Well there is, using a neat unsung feature of 2E arrays.

2E keeps track of the last record to be added, changed or read in an array, a sort of cursor I guess.  This is available in action diagram logic hidden in the ELM context. (ELeMent).

The only 'built in' function that can use the ELM context is a *CVTVAR.  

First create an array with the data fields you would like to appear in the dataset, this can be header, detail 1, detail 2, footer etc.  It doesn't really matter for a flat file process.  To keep it nice and simple I have made up some generic fields names with various data types.

I've keyed these arrays based on the Record type of HDR, DTL and FTR.  You can do how best suits your use case.  All the arrays are set with a 'Numer of Elements' of 1 record as I don't need to use the in the traditional sense.  I just need a pointer to an ELM in memory.

All we then do is call a CRTOBJ over the array to populate the data.  Once in the array, we can use the *CVTVAR to populate a flat file field.  2E handles all the different data types and spits out a well formatted string which you can write to the database/extract file etc



But we are not done.  I've ready other blogs that talk about ELM and they do a pretty good job of explaining the outbound example above.  But not many people realise that depending on whether you are using the ELM context as Input or Output, is the equivalent of constructing or deconstructing the data.  So yes, this method can be used to unpack flat files also. :-)

As long as in the receiving function you have created a shell array record.  You can use ELM to move the data into the array and then standard RTVOBJ functionality to retrieve the record in its deconstructed form.

An example below of a couple of screens that I rushed together showing the data string and the subsequent fields.

You simply point the flatfile string to the correct array and 2E will handle everything else.

Thanks for reading the

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

Lee.

Synon 2e Development Standards - Screen Functions (Part II) - SELRCD

SELRCD - Synon 2e Development Standards

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

Part 2 in the series around screen function types will concentrate on the Select Record (SELRCD) function type.

This is often overlooked as a valuable function as it always appears to be generated on your behalf by 2e when you create a file. However, it has a few useful quirks that require a little thinking and I have often seen everly complicated logic added to them due to a lack of understanding where a simple workaround works quite nicely.

Below I summarise some of the key points when using the SELRCD:-

In general there should only be one SELRCD record per file, the default. I propose you rename your default select per for to '*SLT filename'. (See posts on naming standards). However, there may be occasions when it is necessary to select by a variety of different styles, or by a different key value. For example, where the primary key is a surrogate#.

These reasons may justify having more than one selection program, probably built over different ACPs. All other selects other than the default must be name SLT name and not *SLT name. This ensures correct ordering in the file. If using a different access path I would name them 'SLT By access path'.

The *SLT function is named this way as it will be used by the generator when building implicit field prompting code. The routine is also used to validate a record existence in relation checking. (The check restirction within functionaity). As such a default select must be first on the file and also never have its parameter interface changed unless the keys to the file changes.

CA:2E always regards the first SELRCD it finds on the model file as the default. If an alternative SELRCD should always be called for certain relation checks then that should be assigned via the Access Path relation settings. This situation might arise when a file refers to itself. E.g. Horse Refers to Horse for Mare and Horse Refers to Horse for Sire. At the relation level for the access path it is possible to set a default select record for each relation. Therefore the ordering considerations for the generator to substitute a select record are Function Level – Access Path Level – File Level (First on alphabetically on file).

The standard SELRCD should only perform a selection facility. That is, X=Select. However, a display option may be necessary in some cases as is F9 to Add a record.

Selection logic is usually performed one entity level at a time. Therefore if the SELRCD is for a lower level entity, e.g. 'Owned by', then the high order part of the key(s) will normally be RST.

The standard SELRCD should not pass back values other than the selected key. Validation and passing back of attributes is best left to standard RTVOBJ functions since the user may bypass a selection prompt and enter key values directly.

The SELRCD should not be modified to do anything unusual. If a user exits with *Exit key the default SELRCD will always exit program with return code Y2U0016='no value selected' and also send the same completion message. This processing should not be altered.

The parameter key values passed back should have NOERROR set. This is because CA:2E does not treat a 'no value selected' exit (Y2U0016) as an error when called implicitly. But it would be an error if called explicitly in an action diagram.

Closedown option should be set in the context that the program would be called.

If a SELRCD is not sufficient because of action diagramming restrictions then a DSPFIL may be used instead. But it should have a naming convention of 'SLT By or filename'. It should follow the same logic that a SELRCD would do, i.e. Same parameter definition and same action diagram style. This is often used if additional processing like F9 = Add is required.

The advantages of the DSPFIL method is it allows increased flexibility. But if you do choose this approach then this function will never implicitly be used and developers need to handle the output parameters. That said you could template this kind of function.

Tip

Using a Neither MAP input parameter does allow you to set CTL values for additional filtering.

Thanks for reading the

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

Lee.

Synon 2e Development Standards - Screen Functions (Part III) - DSPFIL

Synon 2E DSPFIL development standards

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

Today we shall take a quick look at the Display File function (DSPFIL).

This is a very commonly used function type in 2e and if my notes are correct there may be a thing or two of interest in this post. However, I guess that this depends on whether you are an ageing old developer like myself or one of the new kids on the block in Bangalore.

But back to the action. Like many other function types the DSPFIL can be used to display data and interact with it in multiple manners. i.e. It can act like an intelligent Select Record and also allow multiple selects. It can also be used to show the contents of an array.

Hold on I hear you say.

"It's a display file and arrays are not files......"

That's true but there are methods to complete this. Nudge me with some comments and I might write up a few examples of code to show you how to achieve this.

Also as the DSPFIL has the CTL (header region) it can be used to provide an interface with a tab look 'n' feel.

Anyhow. Major tip. Take a look at the function options for this function type. In particular, the function option called Re-Process Subfile. Set this on and off and take a look at the action diagram. There will be additional user points and logic added if this is set to Yes. This is just another example of the PODA principle that is taught when you attend training.

PODA stands for Parameters, Options, Design and Action Diagram. The philosophy behind this is simple. The more correct decisions you make at the preceding level i.e. Parameters first, then options (function options) etc the less coding (action diagramming) you will need to do.

2e is quite a neat tool. You should be judging your developers based on the least amount of code required rather than rewarding on a LOC principal (Lines of Code). I think it is fair to say that anyone can write a bad program.

Below are two sections that provide some insight into the function.

General Considerations

The default scan limit is 500. This may not be appropriate for large files. If necessary set the scan limit in USER:Initialise Program to a higher value or even to Maximum. Note: That the scan limit is a model value. If you require a higher number by default (across your model) then I recommend you change the model value YSCNLMT.

Best Practice

Any subfile control selector fields not used should be dropped rather than hidden. This is for performance reasons and avoids the problem of unintentionally deselecting subfile records. To do this simply place enter ‘-‘ against the field from within the EDIT SCREEN FORMAT DETAILS screen.

Multi-part ACP key fields acting as positioners will automatically become selectors if low order fields have data and high order fields are blank. Ensure that you understand the type of data likely to be used for the screen.

Check that the operators used by subfile selectors are appropriate for the function design. Ensure you want EQ, LE, GT or CT for example. Don't assume the default role of these fields.

If a positioner or selector field has mod 10/11 check digit then it may be appropriate to replace with a function field without the check digit. The user does have to enter a valid number to position within a list.

Tip

There is no standard feature to stop the function loading records into the subfile under programmer control. The program continues until subfile page full, scan limit reached or hits end of file. However, you may trick the function to thinking its hit end of file by using a RTVOBJ over the same ACP using a very high key value. This positions the file cursor at end of file.

USER:Process Command Keys has got nothing to do with command keys. Command key processing should normally be added to USER:Process Subfile Control.

Subfile select status field is automatically set to blanks if subfile record processing completes without error.

Gotchas

If F4=Prompt is used on any subfile control selector STS type field then there is no automatic subfile reload and CALC:Subfile Control Function Fields is not executed. User then has to press enter to invoke appropriate selection logic. Function works OK if '?' is used. There is no known workaround for this bug. I would suggest that this is not actually a bug and it is harsh to judge it that way. It is simply because the enter key was pressed for the ? and not the F4 prompt.

CALC:Subfile Record Function Fields is executed before USER:Initialise Subfile Record and therefore you may process a record subsequently deselected. i.e. PGM.*Record Selected.

If any RST input parameter key is also input on device design, and its a file to file relation, then that file validation is deferred until the main validation cycle rather than take place during the load cycle. Any automatic virtuals from the 'Owned by' file will be blank when function is loaded.

An input function field added to RCD format will not automatically check for required value. Even if you set the value to Allow Blank ‘ ‘. This is because the DSPFIL template isn’t designed to have input fields and doesn’t generate the validation routine regardless of how the flag is set or any check conditions. Need to add the code procedurally via the action diagram to force input.

An input function field added to CTL format will not automatically check for required Value. Need to add the check procedurally.

Thanks for reading the

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

Lee.

Synon 2e Development Standards - Screen Functions (Part I) - PMTRCD

Synon 2E Development Standards - PMTRCD

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

I guess the last couple of months have been a bit quite on the site. This was due to some holidays on my part and the visit of relative from overseas for 5 weeks. As you may know I live in New Zealand and the Christmas and New Year period is a time of relaxation and recouperation as well as a period of mass and I mean mass national holiday. Many businesses shut down for a compulsory two weeks.

I am now refreshed and ready to finish off those blog posts that I promised at the back end of last year.

Today I want to continue the 2e (Synon) development standards theme. I really want this site to be an extension to your technical libraries. So without further procrastination, I will get on with development standards, tips and gotcha's for 2E screen functions.

Today will shall concentrate on the single record function type PMTRCD. Future posts will cover the remaining single record function types as well as multiple record function types like DSPFIL etc.

If used as designed and thats a big 'IF', then this function should have fields on the screen that are prompts for the user to input some values which are then passed to another function for action. These would typically be a report or a processing program of some description.

But, like everything in 2e, the original design intention and actual use is only limited to the users creativeness. I have used these screen types for edit and display screens, prompts, information windows and even restricted subfiles. They are powerful for a number of reasons but for me the ability to DROP the relations and code a screen from a blank canvas is very satisfactory indeed.

General Pointers

A PMTRCD will typically be used in situations where an EDTRCD or DSPRCD is not applicable or too complex, or will have too much of a processing overhead or the traditional methods highlighted above.

For performance reasons any fields or file-to-file relations not needed should be DROPPED from the device design.

After USER:User Defined Action there is no check for any outstanding errors during the User Defined Action processing. If the function option Repeat=No then function may just exit and any errors will not be reported back to the user. Therefore it is a good idea to do a *Quit if PGM.*Return Code is not *Normal, or *Quit if *PGMERR.

Tip

If the function requires a complex set of fields or file to file relations which is not present on any existing file then consider creating an array with fields set to MAP for the PMTRCD. This is often easier and simpler than basing the function on an existing model file, then using lots of function fields and adding procedural based action diagram checking.

Gotcha's

If the function option Repeat=Yes is set then the PMTRCD just loops back to redisplay the detail screen. It does not execute USER:Load Screen. To make the function execute this user point again call user source 2E Force PMTRCD Reload






A PMTRCD behaves slightly different to an EDTRCD. During the validation cycle there is a *Quit if *PGMERR after USER:Validate Fields.

If the primary key relation check has not been turned off then an automatic prompt is generated to a SELRCD over the based upon file. But unlike other file to file relations there is no opportunity to choose which SELRCD is to be called. This I need to validate as I was unable to replicate at the time of writing.

Hope this helps?

Thanks for reading the

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

Lee.

Synon 2e Development Standards - (Hints and Tips RTVOBJ)

Synon 2E Development Standards - RTVOBJ

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

I thought I'd have a break from the 2e naming conventions thread that has occupied most of the last month and launch into a series of smaller posts that talk about some of the hints and tips associated with the 2e function types.

Today's topic is the RTVOBJ. One of the most useful function types in 2e. One which is often misused or understood.

The following are some hints and tips I have learnt, taught, embellished and/or stolen over the years.

RTVOBJ Tips

Naming. Most RTVOBJ functions can be divided into one of two types. Single record GETs to bring back attributes for a given key value. Multiple reads to perform some sort of process logic or test. Different naming conventions, 'GET By ...' or 'RTV Last four transactions' will identify these two types. See previous post re:naming standards.

Getting Records. A GET will be based upon an ACP with a unique key, usually the RTV and pass in a fully RST key value. The function will only return database attributes + the xxx Record Found Y/N flag (optional for your site). The return code will not typically be explicitly modified. If the record is not found then output parameters must be cleared. Parameters, both INPUT key fields and OUPUT attributes should be defined using the same access path (ACP) that the function is based upon. Avoid using the individual field definitions unless they are not scoped by an access path.

On certain files with fixed key values the RST key may be set to NEITHER and primed inside the RTVOBJ at initialisation. Examples here are system tables that have one record.

GET's will return ALL attributes including spare fields. (A future post will talk about the benefits or otherwise of using spare fields). If the standard *GET will do, then use it!!!. There may be other ‘Get xxxxxxxx’ functions currently in your models which may have a subset of the fields. You can replace with a single *GET if preferred.

Other types of RTVOBJs will perform various processing requirements over multiple records these could be prefixed as RTV.

General Hints. When testing for certain conditions you should *QUIT the RTVOBJ for performance reasons once the condition has been found thus minimising I/O and decreasing function runtime. There are exceptions here for *Arrays. (future post).

In general try to avoid changing the default PGM.*Return Code setting, although there may be circumstances where this is justified. If you do need to identify a specific condition other than normal the user CND.*User Quit Requested appears to be a standard I have seen at many companies.

If the RTVOBJ is built over a RSQ ACP and uses RST/POS key fields then explicitly define the key fields using a KEY structure. This will allow the developer to zoom into the key structure and understand what the key fields are.

Do not leave the fields as MAP. There is no relevance for a RTVOBJ and it only confuses new developers. CA please change this. I know it doesn't generate anything!!!!!!

Default RTVOBJ's i.e. *GET should have parameters passed as RCD. Get By and RTV's over alternative access paths should use the KEY/RCD method.

If using a RTVOBJ to retrieve reference data. It is best to not do the call if the value is optional. Saves an unnecessary I/O.

Gotcha's

Best Practice

There is a well-known bug (feature) in a 2E generated RTVOBJ in that USER:Exit Processing is executed if no records are found and there is no coding inside USER:Record Not Found. Therefore if any action diagram coding is added to USER:Exit Processing then you must also code something (comment or *QUIT) inside USER:Record Not Found. This ensures that the function always behaves in a predictable manner.

If the data passed in as RST or POS parameter is of a different domain and is alphabetic for a shorter length then unpredictable results may occur. This is because the generated code is failing to clear fields when building the RPG key list. – I could not replicate in the latest release.

Best Practice

If you change the ACP that the RTVOBJ is based upon then also remember to change parameter definition. It is best to keep these consistent for developer readability.

Version 7.0 of 2E allows RTVOBJ's to be written over physical files. This reads the file in relative record number order. This is quicker than using a logical. This technique is useful when you need to read an entire file. A fix program would be a good example.

I will cover CRTOBJ in the next blog posting.

Thanks for reading the

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

Lee.

Synon 2E - Development Standards (AD & Contexts)

Synon 2E Development Standards - Action Diagram

Synon 2E Development Standards - Contexts

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

Continuing the series of development standards for 2E (Synon). Today's topic is Action diagramming and contexts.

Once again in no particular order.

Beware of a negative list. Do not use a 'negative' LST on a STS field. E.g. If STS field has Val's A,B,C,D then do not create a LST 'Not B' which contains A,C,D. If a new VAL is added to the STS field then the negative LST immediately becomes out of date and also needs amending.

Note: As with Access Paths and File changes, status conditions should be considered a DBA level change and appropriate care and attention taken.

When not to call the *RTVCND. Do not use *RTVCND to get a condition name if the STS field is blank. This is not required as the result should be blank on the screen. Can use a derived field, although these should be discouraged if you are considering thin screen clients and business services for easy migration.

Do not use a *RTVCND in programs that may be converted to other platforms. Feature not supported on other platforms. Not sure on the impact the ADCMS though.

Know how to quit. Never use *QUIT unless you understand explicitly where you are jumping to. Only a few recognised action diagram user points should ever contain a *QUIT. Note, you can quit out of a user defined subroutine. This is a useful technique if you wish to cut down on conditional code.

Pro's
Allows you to strategically exit a subroutine for efficiency i.e. RTVOBJ.
Allows you to suppress PRTOBJ.
Allows you to exit a user defined subroutine. Especially useful for functions with lots of validation logic.

Con's
If used in wrong subroutine can seriously impact the flow of a function.
Care should be taken if code is being copied into other subroutine as the desired affect of the *QUIT may not be the same.
Not directly supported in CA Plex if you are considering a migration.

Do not use *Exit Program in internal functions.

When trying to determine the success or otherwise of a called function you should always check PGM.*Return Code.

Be extra wary of arithmatic operations that might overflow. In particular DO NOT use any tricks to truncate numeric data such as multiplying a 7-digit date by 1 into a 2 byte result field in order to extract the day number. This causes a numeric overflow and may give rise to invalid data. This is especially true (Pre 8.1) for RPGIV generate programs that will also abend with a runtime error that is not a good look to the end user.

Keeping it all in Context.

The following section is about the usage of contexts in 2e.

NLL Context.

NLL context can be used to discard any unwanted output parameters on both internal and external functions.

It will be used predominately on GETs to avoid having to define numerous RTVOBJ functions, each with different parameters. But be aware that a NLL context parameter still creates a usage for that field within the model. Thus you may create lots of spurious field usages. In earlier versions of 2e pre 8.1 the NLL also created NLL fields in the source. This has been resolved and NLL fields are no longer generated.

Pro’s
Cleaner looking action diagram.
In 8.1+ the NLL fields are no longer generated so program are smaller
Easier and quick to default whilst action diagramming.

Con’s
Dumper fields are easier to determine usage for impact analysis as NLL fields are still shown as used.

WRK/LCL context.

Try to use LCL context in preference to WRK context. Unlike WRK context the LCL context is only scoped to the function it's used in. WRK context being scoped to the whole external that the function is generated into.

WRK context should never be used to pass data between function calls, bypassing any parameter declaration.

Be careful about introducing LCL context into existing functions that use WRK context. Mixing the two contexts could be dangerous.

Be EXTRA careful about replacing WRK context. You need to follow through all usages of internal functions that use it to ensure its integrity.

Be aware that LCL context fields are not the same as NEITHER parameters. NEITHER parameters are automatically initialised upon each entry to the function. LCL context fields are only initialised upon program entry and can be used to carry over data between call invocations of the internal function. That is, LCL context can be used to cache function level data.

When reading/writing or processing lots of fields from a given record or model file then PAR context arising from NEITHER parameter access path definitions are preferable to LCL context. PAR context requires a specific parameter declaration that can be queried, and can participate in action diagramming logical parameter defaulting mechanism.

Do not use WRK or LCL context as target of a *MOVE ALL. It doesn't work. You can enter these in the action diagram and 2E will generate a comment but no code will be created.

JOB Context

Care should be taken with the use of the JOB *System Timestamp field. It is only refreshed if moved into a field. Therefore a subsequent query of the JOB context of the field will only be of the last set value. This can equate to Zero.

CON/CND Context

Best Practice - Always use conditions (CND) rather than constants (CON) for non-trivial values. That is, values other than blank or zero. This allows the exact usage of special values to be obtained from the model, and allows translation of condition names. Exceptions are simple values – see below.

CON *BLANK and CON *ZERO are fine for input parameters.

CON is also acceptable for trivial arithmetic operations such as incrementing by 1, sign reversal by multiplying by -1, percentages by dividing by 100, special characters used in *CONCAT such as periods or commas, character position numbers used in *SUBST. National language impact should be considered. i.e. When to use a comma or not. This is especially true for German as they use a comma as the decimal character.

CON.xxxxxxxxxx can also be used to initialise descriptions and text fields in one off initialisation programs.

Note the CON context is not supported in CA Plex and must be converted before any migration can occur.

CON values do no appear in impact analysis.

CON values cannot be exposed for use via the NLS product.

If you have any questions or enquiries about anything published on this blog, please do not hesitate to contact me. I welcome all comments and opinions.

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.