DSPRCD refresh trick and a few extra tips.

Today I was asked to fix a DSPRCD screen that wasn’t refreshing after an up-screen EDIT function (Command Key) had changed some values. Upon returning to the DSPRCD it still showed the original values.

DISCLAIMER: This is correct behaviour for a 2E function but a little bewildering for the user as they are hesitant as to whether they actually made the change in the update screen.

For a DSPFIL we would use the *reload subfile to force a reload of the screen.

For a PMTRCD we can set the function option ‘Repeat Prompt’ to get the same behaviour.

For DSPRCD etc it is a little trickier…….

Typically, I have seen people utilise a driver program and execute the screen in a loop and simply recall the screen or exit.  This is doable……    There is however, (as always)…. An alternative, a trick and as it is much simpler I will show you.

The answer is to force the transaction to continue.  You maybe be aware of the PGM.*Continue Transaction field in 2E.   It is typically used (in action diagrams) for the DSPTRN and EDTTRN function types.  The same field is used in many AD’s including the DSPRCD.

In this instance it is simply there to initiate a loop.  Typically this field only has one condition (*NO) for using the EDTTRN and DSPTRN.  See these notes in the 2E manual….

https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/it-operations-management/ca-2e/8-7/building/building-applications/modifying-action-diagrams/understanding-action-diagram-user-points.html

The trick is that the DSPRCD generates code that says if W0TRN (*Continue Transaction) = ‘R’ then keep re-showing screen. 

Our issue (default model)  is that we have no way (default way) of setting it…… We do now. 

I have simply added a new condition to the field *Continue Transaction (I’ve done it at many sites).  The condition is called ‘*Reload Trick’ and we just need to set in after we’ve called our screen.

Please note you may need to follow this with a *QUIT depending on your circumstances.

Voila…. It works 😊

Additionally, did you know.....?

1. USER:Process Command Keys has got nothing to do with command keys. Command key processing should normally be added to USER:Validate Detail Screen. 

or for DSPRCDx

1. The correct screen context DTL/2ND/3RD must be used for error message parameters to ensure that field is highlighted. Normally in any action diagram coding the screen context is not significant.
2. The validation cycle processes data from all pages together, therefore, the relation settings apply to the function as a whole, and not to individual screens.
3. It is not possible to control, which page the user sees. If there is an error the function always displays the first page, which has an error outstanding, but this may not correspond to the actual error message displayed on the message subfile line. The messages are displayed according to the sequence they were sent. Therefore, you may have to review the validation sequence.

Tip: Validate a page at a time and only start validating a subsequent page if *PGMERR is not set.

Thanks for reading. 
Lee.

Comment on commenting.

Hello,

Comments are an essential part of any coding practice whether you are using traditional languages that are quite verbose with their syntax and vocabulary i.e. Java, C# or RPG/COBOL.  Even code generation environments like 2E and Plex benefit hugely from appropriate commenting.

Modern low-code platforms like Appian, Mendix and Outsystems (to name a few) who shield you from code (as much as possible) benefit from correctly named functions and comments/annotation within them.

Without comments, what was as relatively simple coding process to the creator is now a moderate pain in the butt for the developer maintaining your code.  Multiply that with a complicated piece of technical logic and/or business logic which is now practically impossible for a maintenance developer to pick up and be successful.

Chances are you will NOT be maintaining your code. Get this into your heads.....

To avoid this, structure your comments professionally and ensure that the comment adds value.

Commenting out old code for safety reasons in the modern world is simply unacceptable.  With repositories like GitHub etc you can be brave and make changes.  Sure, comment some stuff out locally whilst trialing a few ideas....I get it.    But to commit that code to the main branch or the model if programming in Plex/2E is just unforgivable.

If you have got to the point where you have unit tested your code and are 1000% happy, remove the commented out code....NOW.

I'd also go as far to say that you should remove all legacy commented out code at the time you checkout the function...I mean where others have failed before you.  

There are no excuses for leaving commented out code in a production object/branch.

Thanks for reading.

Lee.

You have 'Function Options' you know....

PODA PODA PODA PODA PODA PODA

One of the first things that are discussed when you did (if you did) the Action Diagramming course for 2E is PODA.

PODA is an approach to effective function design.

• P is for parameters and the interface.
• O is for options (Function Options)
• D is for device design (Screen/Print)
• A is for action diagram.

The concept being that these all influence the function and getting them correct will mean you’ll write less code and won’t be wrestling with the template (prototypes/patterns).

Bare this in mind for the rest of the blog post.

I was at work the other day and was maintaining some code where once again I could be heard saying, “Whoever wrote this should be shot!".  It’s my preferred (go to) phrase when I see badly written/designed/architect-ed code.

Anyhow in this instance the code was quite simple and generic so I can share it here.

The reason for my comment above was why is this code inside a subroutine called Subroutine?  The actual function ‘Perform Substitution’ was itself and EIF (Execute Internal Function).

I thought to myself, it is okay someone probably wanted to be able to *QUIT from one of the case blocks below…..  NO!!!

Hmmmm.......Perhaps someone was being a dunce!

Anyhow, depending on you model default and EIF can be generated as either inline code or as a subroutine.  I am thinking that this code might be quite old or that someone simply doesn’t understand how the code is generated in 2E. (Probably the later).

Most of you know that you can share subroutines and reduce code bloat using the ‘Share subroutine’ option.  And EIF also has an additional option called ‘Generate as subroutine’.

In the instance above we could have achieved the same result with omitting the sequence block and simply setting the value.

Let’s explore the generated code for a much simpler example.  I have an EEF (Execute External Function) calling and EIF.  The EEF is setting the local context for LCL.*JOB DATE to JOB.*Job Date and then calls the EIF which in turn set the WRK.*Job Date to JOB.*Job Date.

With ‘Generate as subroutine’ set to No we get inline code. (See below).

Taking the original example (see top), if I put the internal code inside a Sequence block I’d get a subroutine. 

See code mock up below.

So although this code looks a little neater, it still isn’t perfect.

Setting the option Generate as subroutine’ to Yes generates slightly difference code.

Overall, in this instance it didn’t matter too much as there were NO *QUIT’s to worry about and the routines weren’t (or couldn’t) be shared etc.  But it does highlight that following PODA can make your programmer life easier, not to mention mine..... as I mop up after you....

Thanks for reading. 
Lee.

2E Code Review - pet hates - part III

7. Bad field names.

I've banged on about this many times but fields called 'Current Balance' or 'Count' simply do not cut it.

Call it as it is and don't be afraid for adding more fields.  Especially, as we can now search much easier than before.....

8. Copies of functions (just in case).

RTV All (Copy).

WHY! WHY! WHY! would you do this.  Just take a version or install version control system.  It is even worse when these are external functions that eventually get generated and promoted (but never used).

This is a very amateur mistake and you'll be shocked at how prevalent this is.

9.WIP

Happy to take ideas but be quick as this blog is likely to be closing soon.....

Thanks for reading.
Lee.

2E Code Review - pet hates - part II

Back again...

My intention was that the first post would cover my major pet hates...  Being the perfectionist (that I am when it comes to coding) I quickly realised that I see many more coding mistakes/habits/bad practices that irritate me.

So here are another 3 things (there are still others on the list) that "get on my goat".  I laugh inwardly because I can see each and every developers face who I associate with some of these bad habits.  I also frustratingly recall the countless times I've explained why 'xyz' is bad without achieving a behavioral change.  Stubbornness is a very special human trait.

I go back to a previous post, way way back in 2008/2009 in fact.  I state that without a declared mandate/role to reject bad code, things never change, performing code reviews by democracy simply doesn't work.  This is why I am such a fan of 'automated development standards' review technology as it takes away the conflict.

Back to the list of bad habits that are consuming me today :-)

4. Externalising a single function to get over file limits.

Ever hit the RPG 50+ file limit?  Often you will see people externalising a single RTVOBJ (for example) in order to get back to 50 files or less.  This is the most shortsighted piece of coding I ever see and will only damage your code base.  In this instance RPGLE wasn't an option but as you can tell the option for structuring wasn't taken.

Here is a rather extreme example of a (now deprecated) function from my model at work.  I have altered some of the images for privacy reasons.

Associated hates: Not only will the multiple external functions increase the call stack, reduce performance, introduce errors as people forget about passing the *Return Code back (common issue when externalising) it is only ever a short term option as applications expand significantly overtime.

There are numerous other options which I have covered before like RPG to RPGLE conversion, externalising a major block of associated logic i.e. Load, Validate or Update processing or full function refactoring etc.

Tip: My preference is to aim for a mixture of RPGLE migration and also some refactoring options for better function isolation.  This depends on how much user source you have etc.


5. BOTH parameters that are initialised from within.

Often a developer will need to total up some values across multiple records.  In 2E we would typically use a RTVOBJ to work through a set of records and increment a value.

A quick and dirty way to do this is to declare a value that you want to sum up as a both parameter.  Then within the AD (Action Diagram) the code to increment the value is PAR = PAR + DB1 and an average developer would argue that the passing of the value to the output variable via the PAR is automatic.

Their logic is sound if you are trying to keep your action diagram code to the minimum.  Look at the two example below.

The lazy way

The correct way

On the surface it looks like the lazy way is okay.  It ticks the boxes for.

• Clear function naming
• Minimal AD code (x lines vs y lines)

Then it fails miserably. 

Interface

The BOTH method's parameter interface is not as easy to decipher as the correct method.  You wouldn't know from the function interface that the field(s) being totaled are being initialised back to Zero from within.

What should happen if a value is passed in.  You would expect that the value passed in, say 100.00 would be included in the total.  Here is the confusion.  The function name and interface should clearly depict what is going in inside. 

6. Leaving the MAP on.

MAP parameters are designed to pass a value passed into a function (via parameters) and place it on a device design and automatically populate the data.  i.e. MAP the parameter value to the screen or report.  There is NO other use of the MAP role within 2E.

Leaving the MAP on internal functions like a CRTOBJ or RTVOBJ. 

Whilst not impacting code, it is a sign that the developer doesn't truly understand the role of MAP and if they do, then by leaving it on they are implying that it is satisfactory to be tardy.  To me it is like not dotting an i or crossing a t.

I am going to give the developer a little out here.  CA could make it easier by NOT setting MAP by default and making it a 'opt in' option rather than something we have to constantly switch off.


Thanks for reading.
Lee.

2E Code Review - pet hates - part I

Today I thought I'd get a few things off my chest. 

Whenever I review code, look at old code or have the job of maintaining code (not my favourite part of the job by a long shot) I am often left dumbfounded.  I see the same old mistakes being made regardless of where I have worked. You will often hear me saying,"Whoever wrote this should be shot!!".

The most annoying part is that in many places the developers agree about the best way to code but quickly use the excuse of "I don't have enough time", or "Well it's done now, so don't worry" to not code properly.  My experience tells me it is often the most experienced developer(s) who are the hardest to convince of solid development standards with the terms "Old dog" and "new tricks" preeminent in my mind....

IMHO the difference between a run of the mill programmer (I've worked with plenty of these) and a good one (fewer but they are out there) is adherence to the little details that make long term maintainability of your code as easy as it should.  This is especially true considering the inevitable change and enhancement that is required during an applications growth and evolution.  I have espoused the standard development quote that 90% of an applications life cycle is maintenance numerous times before.

Anyhow, my post today is a list of pet hates that I see when people are "unprofessional", "selfish","crude", "Lazy" with their 2E coding.

1. Legacy commented out code.

I recently worked on some maintenance and had to work through some action diagram code.  Using the Find Services option within 2E I started to quickly get frustrated that the majority of the usages that were commented out.

What was worse still is that there were developer comments (from 2002) stating that the code was commented out and I know that this area has been enhanced many times since.  There is simply no reason to keep such old code.  The developer concerned is normally quite good but has a couple of really bad habits like this one.

Here is a snippet of code from an old function (screen print kindly shown with permission).  Note, I have redacted any client or developer or brand comments (hence some empty white space).

 

I am all for commenting out code as part of debugging, rapid prototyping, unit testing and quick wins (hot fixes) where you are not quite sure of the change you are making, but please annotate when and why.  However, I am aware that some of this code was moved to their own program(s) so IMHO should just have been removed.

Associated hates:

• Having to weed through the chaff to get to the code to change.
• Any old code will not have been maintained so will not (often) be fit for purpose (if you decided to uncomment it) so why leave it there.
• Extra impact analysis (especially for internal functions). 
• Confusion with the impact analysis usage.  A future post is planned for this.
• Better to take a version.
• Commenting out code doesn't change the timestamp for the AD line so we don't know when it was commented out.

Tip: Comment out code sparingly and preferably not at all.  Be confident with your code and solution.  After you have completed the work (and tested it), if you are 100% happy with the results revisit the action diagram and remove commented out code.  Commented out code is a maintenance burden and others will not understand why.

Here is the same code with the bad commented out code and legacy comments removed.

Still not perfectly structured but a whole lot more readable.  Perhaps CA can add a hide/show commented out code option for the action diagrammer.

2. "GET All fields" RTVOBJ not doing as described.

Every 2E developer has written the standard RTVOBJ that returns the full record. Yes, we all have forgotten the *MOVE ALL, but my biggest annoyance is when people don't visit these functions when the underlying file structure changes.

Imagine the "*GET", "GET Record", "Get All", "RTV All Fields" function without the new fields as parameter.

The next developer comes along and low and behold, there are a few fields missing.  Then they create a new one called Get All (New) and probably flag the other one with some kind of encoding system like DNU for Do Not Use etc.

Associated hates:

Numerous versions of the same type of function.  Too many choices.
Description vs reality can be misleading and frustrating.

Tip: If you have to change the file, you may as well change the "Full Record" type function as you have to regenerate up everything anyhow.

3. Using all 9 parameter definition lines for functions parameters.

In the old days when we only had *FIELD, Access Path(s) or Structure files for defining parameters it could sometimes get a little busy and we'd fill the 9 lines leaving limited options for the next developer.  We shouldn't create structure files just for the sake of it, after all, their primary purposes was for consistency of repeating data groups like audit stamps etc not for easier passing of parameters.

Since version 4.0 (over 20 years) we've been able to define parameter arrays.  There really is no excuse now for taking up the last line of a functions parameter block unless "I don't have time" or "I'll do it when we get to 10" is a valid reason.

Tip: When maintaining a function and say 6 or more parameter block lines are used consider refactoring with a parameter array.

I still think that even using parameter arrays as being a bastardised solution for this problem and that 2E should just have had more that 9 lines....but it is the lesser or two evils.

This is the tip of the iceberg.  Plenty more to follow I am sure.

Thanks for reading.
Lee.

Don’t forget the *return code

When we are developing in 2E we often reach the 50 file limit if we are generating for RPG.  RPG ILE (RP4) is more resilient as it allows more files to be opened.  I’ve preached before regarding proper function construction. 

Do you really need 50 or more files open for any given process? 

Can your function be better constructed or to be accurate………deconstructed?

What are the options?

1.       The easiest method to get over these limits is to change to RP4.

2.       The best is probably to re-architect your function properly and switch to RP4.

3.       The next best approach is to probably hive off a chunk of the processing into a new function to reduce the open files.

4.       The worst thing to do, is to externalise a single RTV in order to get under the limit.  As this can cause all sort of issues.

o   The 50 file limit will be breached on the next maintenance (most likely) leaving the potential for a string of EXT/RTV type functions.

o   If called in a loop or RTVOBJ then an external (if not set to Close Down ‘No’) may impact performance.

Another item to add the list of don’ts (above) is the preservation of the *Return Code.  An Execute External Function does not automatically return a *Return Code.  By default, standard processing is to pass back *Normal or an empty *Return Code.

If you are relying on a *Return Code for your now externalised RTVOBJ it will always come back as empty (*Normal)

unless you explicitly pass the return code back with the *EXIT PROGRAM built in function.

 

Another trap for young players but something that catches even seasoned developers out.  Had the RP4, re-architect or block of code to EEF option been taken the issue was likely to not have manifested.  

Good programming practice is to always be conscious of the *return code and more importantly (where required) test for it.

 
Thanks for reading.
Lee.