code: private boolean isStoppingStoppedOrFailed() {
          BatchStatus jobBatchStatus = runtimeWorkUnitExecution.getBatchStatus();
  
          if (jobBatchStatus.equals(BatchStatus.STOPPING) || jobBatchStatus.equals(BatchStatus.STOPPED) || jobBatchStatus.equals(BatchStatus.FAILED)) {
              return true;
          }
          return false;
      }
docs: Today we know the PartitionedStepControllerImpl always runs in the JVM of the top-level job, and so
  will be notified on the top-level stop.
  
  Doing xJVM split-flow would be more complicated, since not only do we lose the single JVM for
  the top-level job, the split and the child flows........we also can't count on the top-level
  portion of the partition, the PartitionedStepControllerImpl, being in the same JVM as the
  top-level job.
  
  If we add xJVM split-flow.. not only do we have to worry about the flows themselves...we also have to recode
  some assumptions for partitions... since the partitioned step might be itself part of a split-flow.
  
  Note we also might have to worry about ensuring the STEP-level status was moved to STOPPING if we
  were only checking the job level status remotely (see defect 203063).
  
  We could just check the DB.. but I guess we don't have to for now.
  
  @return true if the job is stopping, stopped, or failed.