Can you confirm that you are in sequential mode and not non-sequential?  This is an operand to perform a normalized (Hx/Hy/Px/Py) single ray trace through a non-sequential component inside a mixed-mode system.

No, I’m working in the non-sequential mode. And the first sentences of the docu is: “Non-sequential single ray trace”. So I’m expecting this operand as a NSC operand. 

My current task is to get the path lengths of a single ray the in NSC merit function for optimizing distances. 

If you’re in non-sequential mode, then you’ll want to use NSRA with a source that has a # Analysis Rays set to 1.  The most logical choice is the  Source Ray and you use Position XYZ and XYZ Cosine values to aim the ray.  Other sources with # Analysis Rays set to 1 will work, but extended or divergent sources might give you unexpected results for the first ray traced.  

I’m using the Source Ray with a # Analysis Rays set to 1. 

Then what would be the way to optimize in the NSC the distances between my components by merit function, for which I need the optical path of the ray. 

It exercise works with the NSRA  opernand, but you have to trace and save the rays (*.zrd) in  advance. 

The NSRA does not require a saved ZRD file.  You can use the data 10 to get the physical path length of a given segment and data 14 to get the index for the optical path length.  You will simply need to know the segment that you want to analyze (you will need to count which segment you want by looking at the NSC Layout & you can choose Color Rays By Segment to help you).

To be honest, of course, this works for a minimal example with 4 Elements. But I can't start counting the elements in my setup with several 100 elements. I. e. the way about the ZRD file works better, because here then the segments are numbered accordingly. 

But to come to the original questions: why there is not this NSST operand, although in the docu this is listed as NSC operand. If not, this must be implemented here in my opinion or the docu be adapted!?

The NSST operand is designed for mixed-mode systems where you have a non-sequential component buried inside a sequential system.  If you open any sequential system, you can see the NSST is available in the MFE.  So both the software and the documentation are correct.

Even if NSST was available, it would still be very difficult to get the results you want.  You would need to 3 operands to get the XYZ for one object, 3 operands to get the XYZ for the second object, 3 DIFF operands, 1 operand to sum the squares and 1 operand to take the square root.  So you would need a total of 11 operands just to get the distance between 2 objects.

As for your specific case, if you want to optimize the distance via the MFE, the easiest option will be to do this piecemeal and to temporarily set the second object to ABSORB.  Then you can use Seg = -1 rather than needing to count the individual segments.  A more robust option would be to use either the ZPL or ZOS-API to script this process.