Back around the z9 (circa 2005), IBM pushed the TRT instruction into the hardware coprocessor (aka CoP). This produced fabulous performance scanning the first operand if the nonzero function byte occurred deep into the first operand (e.g., hundreds of bytes deep). Unfortunately, empirical evidence showed that when parsing stuff like languages (assembler, C, HTML, Java, JCL, Python, & such), the nonzero function byte showed up within 9 characters on average. The start-up costs of using the CoP (e.g., transferring over the function-code table) made using it for short scans less than optimal.
IBM acknowledged this gaffe in subsequent processors, throwing more hardware at TRT, and on recent processors, TRT performs exceedingly well. The advantage of TRT is that it can scan for multiple nonzero function bytes (e.g., in this case, tab, space, or any other delimiting character) simultaneously. This is one case where 54-year-old technology still kicks ass. Furthermore, if you happen to be scanning multi-byte character sets (such as UTF-16), TRANSLATE AND TEST EXTENDED (TRTE, available beginning with the z10) provides a means of parsing 2-byte operands, with the option of using either 1-byte or 2-byte function codes (i.e., translate table). For those parsing languages that are rendered right to left (e.g., various oriental or Semitic-based languages), there are also "reversed" flavors: TRTR and TRTRE that scan right to left. Although I also advocate the use of the vector instructions, these are only available beginning with the z13 (first available on the z13 in 2012). Thus, if your customer is still running zOS on a used z900 — or if they're still running MVS 3.8 on a used 3033 — you're S.O.L.
