Ken,

Can you be more specific about the non-printing characters? If you are serializing  data to XML, you need to be clear about whether you are correctly XML-escaping the characters, or whether you are actually receiving values that are not permitted in XML. Is it clear as to which of these problems you are running into?

A rather subtle point that I haven't seen discussed here is actually about how TSTART/TCOMMIT/TROLLBACK should be handled when triggering a TROLLBACK from code that may be part of a nested transaction. Given that a lot of the code I write may be called from various contexts and those calling contexts may already have open transactions, my preferred transaction pattern is as follows:

Method SaveSomething() As %Status {
  Set tStatus = $$$OK
  Set tInitTLevel = $TLevel
  Try {
    // Validate input before opening transaction so you can exit before incurring any major overhead
    TSTART
    // Do thing 1
    // Do thing 2
    // Check status or throw exception
    TCOMMIT
  }
  // Handle exception locally due to local cleanup needs
  Catch ex {
    Set tStatus = ex.AsStatus()
  }
  While ($TLevel > tInitTLevel) {
    // Only roll back one transaction level as you make it possible for the caller to decide whether the whole transaction should be rolled back
    TRollback 1
  }
  Quit tStatus
}

(Edited for formatting.)

I prefer doing this more correctly using the right API for matching status values:

If $system.Status.Equals(sc,$$$ERRORCODE($$$GeneralError),$$$ERRORCODE($$$MoreSpecificStatusCode),...) {
  // Handle specific error(s)
}

The use of ' can result in unexpected behaviour when you are checking for a 4 digit code, but are handling a 3 digit code...

Note that it's also safer to wrap status codes in $$$ERRORCODE($$$TheErrorCode), but that may not be necessary depending on the specific context.