code: byte[] createMessageID() {
          if (TraceComponent.isAnyTracingEnabled() && tc.isEntryEnabled())
              SibTr.entry(this, tc, "createMessageID");
  
          // Note there is no need to take a lock around this update piece of
          // code because the synchronisation code guarantees we will be single
          // threaded through this method.
  
          // Increment the least significant 8 bytes by 1 to provide the counter
          // index.
          int currentOffset = currentMessageID.length;
          int counterEndPosition = currentMessageID.length - 8;
  
          do {
              // Look at the next position to the left (the first time around this brings
              // the offset inside the width of the array).
              currentOffset--;
              // Increment the current position.
              currentMessageID[currentOffset]++;
              // If the increment caused a rollover then we want to move on to the
              // next position, unless we have already reached the end of the long.
          } while ((currentMessageID[currentOffset] == 0) && (currentOffset > counterEndPosition));
  
          // The next instructions that happen on this thread will be MFP copying the byte[].
          if (TraceComponent.isAnyTracingEnabled() && tc.isEntryEnabled())
              SibTr.exit(this, tc, "createMessageID", currentMessageID);
          return currentMessageID;
      }
docs: Creates a new messageID.
  Use the stem (supplied by core) and add a session unique counter to
  the end. Return as a byte[] representing '<hex>' format. (note it
  does not include the 'ID:' part.<br>
  
  Note that as part of 188046.1 we can set the messageID onto the message
  directly as a byte array so we can avoid converting the messageID to
  a string and back again.
  
  Following 189874 we know that MFP will take a copy of the messageID byte[]
  so we would like not to have to take one here. A problem would occur if
  a second thread called this method between the time it returned the ID
  and the time MFP took a copy of it. We know this cannot arise because the
  session locking guarantees that you cannot send two messages simaltaneously.
  (the odds of it happening if this were not the case are extremely small!)
  
  @return a new messageID