CHGOBJ and NULL UPDATE SUPRESSION - What, Why and When to use!
UPDATE: 06/12/2025 - Linked to a summary post dedicated to deep dive long form posts.
Would you do work you didn’t need to do? NO would be the obvious answer right!!! That said there are probably thousands of 2E
programs out there that are doing unnecessary updates to a database using a
CHGOBJ.
Many of these programs have been working seamlessly for
years and years, however, they are like a volcanic field. Stable for years, centuries or even millennia
but then one day……BOOM!!!!
This isn’t because they are really badly coded. After all, we should only be updating one
record at a time etc. Most CHGOBJ’s are
probably inline (i.e. a screen or a single instance business transaction).
Mass bulk updates being the lesser spotted usage for a
CHGOBJ. But it does happen!
Recently we had an issue where a long standing bulk update
processing program (EOD) went from executing in sub 1 minute (so it didn’t get
too much love in the maintenance department) to almost 30+ minutes (overnight).
Upon first inspection, the program hadn’t changed. This points to an environmental based
solution. The dataset or data volume hadn’t
significantly changed either…. The
subsystems configs hadn’t changed and there was no system resourcing issues or
spikes…..
The simple reason for the increase was that a new trigger
(2E) was added to the file being updated, this trigger had a little business
logic and this was required processing.
There was limited tuning to be done in the trigger program.
However, I did notice that the data was summary statistical style
(reporting categories for data like current
balance etc). This was being
recalculated each night and updated on an account by account basis.
On closer inspection of the rules around the categorisation
it was obvious that the vast majority of accounts stayed in their categories
for years and years and only with major events in the accounts lifecycle did
they switch. This mean that the activity
was effectively calculating the same values each night and then updating the
fields in the file every night with the same values. This in turn NOW triggered additional
functionality with a real-time trigger.
Option 1.
It was quite obvious by now that we needed to stop the
execution of the trigger. We didn’t have
the option of removing and reading the triggers after the process. The simplest method was to not perform the
database update in the first instance.
This can be done by simply comparing the newly calculated values with
the those on the database record and NOT call the CHGOBJ.
This method works and is relatively easy for a developer to
read the action diagram and ascertain what is happening and on the surface
seems like a good option. I have seen this
done in many functions.
However, the developer must (potentially) do a read to
compare to the database. This data may
itself be old (retrieved much earlier in the cycle). The developer needs to do this everywhere the
CHGOBJ is used.
Option 2.
Code could be added inside the CHGOBJ to exit if DB1 and PAR
are the same. I’ve seen this approach
too. This is a bit cleaner but for any
functions creates since 6.1 of 2E (last century) this is also the incorrect
approach.
Option 3.
The correct approach in this instance is to switch on a
function option on the CHGOBJ and utilise the built in suppression code
relating to Null Update Suppression.
(See highlighted options below).
The options are quite simple.
M - is the default model value. In this model it is ‘N’ so this implies NO
suppression will occur.
Y - means that the DB1 will be checked against
PAR twice. Once upon initial read of the
data from the file and then once the record lock is in place and that data is
about to be written.
A - (After read) only does the first part (see
above).
The generated code
The diagram below gives a visual of the code that is
generated for each of the options.
NULL Update Suppression works regardless of how you define
CHGOBJ’s
Works with:-
- Default CHGOBJ's
- Neither dropped CHGOBJ's
- KEY/RCD dropped CHGOBJ's
- Shared Subroutines.
There really isn't an excuse not to implement these options.
Benefits of the suppress option for CHGOBJ.
- Record level audit stamps won’t get corrupted
with unnecessary update.
- Performance.
- Triggers won’t get fired unnecessarily.
- Encapsulated.
Thanks for reading the
Synon 2E and Plex Emporium by Lee Dare (A developer blog). Lee.
