why not use a free local mail server for testing?
I personally use the german speaking Hamster. But there are lots of them. Google is your friend

make your formula  f = x + 20(y*y) > z
a calculated, SQLcomputed property in your TABLE
and provide it with a bitmap index and it will run distributed and be incredible fast 

docs: 

https://docs.intersystems.com/iris20192/csp/docbook/DocBook.UI.Page.cls?KEY=GOBJ_proplit#GOBJ_proplit_computed
https://docs.intersystems.com/iris20192/csp/docbook/Doc.View.cls?KEY=RSQL_C145362
 

error -400 means there is an internal error

It might be caused by using object properties as  :context.anyname inside embedded SQL

give it a try and use "simple variables"  as :%myanyname , :%myShipmentTrackingNo 
and fill the context object outside the embedded SQL
as you do with SQLCODE

I'm surprised you don't see the obvious performance difference of looking for something of distinct length at the beginning of a string
vs. scanning an eventual rather long string for some bytes somewhere eventually including also composed strings as %AB%CD%.

keep in mind: Caché is built for speed, not for the comfort of the average programmer 

%STARTSWITH relates better to Caché internal structures and is faster in larger scale

USER>w $ZDATETIME($h,3)
2020-02-08 00:59:59
USER>w $ZDATETIME($h,-2)
1581120005

docs: https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RCOS_fzdatetime

Once the query is running it is not interested in any browser activity.

BUT:
the query is stopped when you fall into the session timeout
and the related process (and any query) is terminated.
SO it not running forever!

in Caché Terminal you may

;;; see I/O device guide for more details

The name of the io table is really just UTF8 with no hyphen !

So you force translation to internal format.

It looks to me somehow like double encoded. 

Does your installation run as 8bit national (iso latin1) set or as wide char.  unicode PTUW  ?
Mgmt Portal "About" tells you  
 

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.