Assuming that cdate has  a rather narrow selectivity

#1) looking for a distinct value (1)  gives a rather moderate result set. So the index global might not consume too much buffer blocks.

#2) looking for >1  (combined with a  significant EXTENTSIZE may create a huge resultset.
So it is wise to scan the index global first {typically less blocks than data global] and keep the hits sorted by ID.
Then you run with this hit list along  the master map through your data global. Assuming that data require 
significantly more block reads than the index global.

With a reasonable amount of Global buffers, your temp Global even might not see the Disk storage at all. 

You see it's a bunch of assumptions hidden in this query plan.
The main goal, in any case, is to have as less "disk" access as possible.
I quoted "disk" as storage has so many kinds of variations that it just stands as a synonym.
 

I see !
And can confirm that this is by design (and ANSI definition) built like a routine call by value.
And you have no chance for a pass by reference.  [ somehow   for i=1:1:.x ]

Funny enough I remember a related discussion when I implemented that piece of  M_interpreter  almost 40 yrs ago (pre Caché in MACRO32)
And the result was: If someone wants a dynamic ended loop he should use the unlimited variant and QUIT it when done.
(WHILE was unknown in the standard definition of '78) 

And for reason of backward compatibility, no one ever tried to change it.

Hi Dmitriy,

$ZF(-1) has no chance for a timeout it is strictly synchronous

So $ZF(-2) and Looping for a result might be a workaround
$ZF(-100,"/ASYNC", ...) may do the same. See details

Both need to run the external routine in a script that documents its completion in some file and you check it.

A different approach could be a Command Pipe (CPIPE) where you read the result with a timed READ.
It's basically the same

Hi Scott!

Happy new year! 
You are right ZEN is out but CSP is not.
With ZEN you might have implemented inline editing.
But is rather simpler to achieve an acceptable result  (except coloring) if you separate editing from table view.

The generated page has a SEARCH page that should be easy to configure. <CSP:SEARCH>
And if you force the generated page to start with the search page with maxrows=25 you might cover the needs I understood.

This were my changes:
<head>
<title>Cache Server Page - Sample.Person (SAMPLES)</title>
</head>
<!-- start with search page -->
<body onload='form_search()'>
<h1 align='center'>

and at end:
</form>
</body>

This is the extended CSP:SEARCH tag:

<!-- use csp:search tag to create a javascript function to invoke a search page -->
<csp:search name='form_search' 
 classname='Sample.Person' 
 where='ID,Name,DOB,Home.City,Home.State' options='clearbtn,sortbox' 
 PREDICATES="%startswith,=,contains" MAXROWS=25
 SELECT = 'ID,Name,DOB,Home.City,Home.State,Home.Street,Home.Zip' 
 >

I did the example in namespace SAMPLES

Hi Jeff,

After some playing around it was clear that any error in a procedures ends up with <-149>:<SQL Function encountered an error>
as you found out yourself.

To have <-400> the error must happen at the top level of your SQL statement .
Using your initial SqlProc
If you add an argument to your SELECT ....., 1/HL7.Message.Get(pid) as found ....

you get a useless 1/tMsg.Read(tMsg.Size) value

but you get 

[SQLCODE: <-400>:<Fatal error occurred>]
[%msg: <Unexpected error occurred: <DIVIDE>%0AmBuncommitted+4^%sqlcq.USER.cls34.1>]

enforced by a 0 return value.

That's just half of the request and I see no way  to influence %msg variable
So you can enforce a STOP of your query. 

I think it's both

#1 missing a lot of important countries

#2 wrong (or very aged)  since FRANCE: 20  would mean to have 1 employee by customer . This simply can't match.
I think a look at the WRC registry might give some feeling on the dimensions.  (without disclosing details)  

For my case 5 yrs back picking out 1 of my partners which had >30 installations at 30 companies.
Could be they count "Intersystems Only"  -  but that's not stated nor does it make sense.

walking through their web pages you see fast who is their preferred product supplier. no need to mention

Attention!

The list of companies from enlyft.com is totally wrong.
Even if you just look at Electronic Health Record  you miss important countries like whole Scandinavia, Italy, Germany, China, ...
and beyond that whole middle and eastern Europe and especially Russia. Where is Japan ?

Just as a signal how massively wrong these figures are:
My small Austria has more companies using Intersystems products than this 26 counting for India.

I'd suggest you contact Intesystems Marketing for REAL figures.
Your source is just faked information.