That is a peculiar way to arrange for email alerting on errors!
(normally the script or procedure that invokes Runstats or Reorg would test the exit-code (return-code) for success or failure and react accordingly).
If either the runstats or reorg commands fail then you will not see a DB20000I token in the first non-blank line following the RUNSTATS command (or REORG command). So you could parse for "the absence of a success message" after each command.
i.e You could parse the first non-blank line that follows each RUNSTATS line and if its first token is different from DB20000I then you have a potential problem (i.e. some kind of error or warning) that you might want to email.
Simiarly you could use the same logic for the non-blank line following each REORG line.
DB2 commands can fail (or give warnings) for many reasons, there is not a "general" error message.
You can distinguish between a warning and an error (the first token on a warning line might end with a W, while the first token on an error message line might end with N).
You might need to be able to deal with a situation that a command was still in progress (i.e. there is no line following the command), if that can arise in your setup.