You might use $ZEOF to check for file end.

It should be enabled first:

do $system.Process.SetZEOF(1)

Then you can read file line-by-line as follows:

  do $system.Process.SetZEOF(1)
  set filename = "c:\temp\qq.txt"
  open filename:"R":2
  if '$Test {
    write "cannot open file ", filename, !
    quit
  }
  for  {
    use filename read str
    quit:$ZEOF=-1
    use $Principal write str,!
  }
  close filename

Documentation says following:

For a table containing more than 1 million records, a bitmap index is less efficient than a standard index when the number of unique values exceeds 10,000. Therefore, for a large table it is recommended that you avoid using a bitmap index for any field that is contains (or is likely to contain) more than 10,000 unique values; for a table of any size, avoid using a bitmap index for any field that is likely to contain more than 20,000 unique values. These are general approximations, not exact numbers.

To autofill password fields, Atelier (Eclipse) stores password that developer enters in different wizards. For example password for connection to Caché, password for connection to Git repository, etc. Atelier stores passwords in secure place called secure storage. Passwords are stored in encrypted form.

Access to the secure storage is protected by master password.

So, when you open some wizard with password field first time after Atelier lunch Atelier asks for master password in order to get password from secure storage and autofill corresponding field.

Let us know what exactly you don't understand and I (or maybe someone else) else will try to explain it.

$THIS is object reference (OREF) -- unique identifier of object in memory. Different objects might have the same OREF during process lifetime

And subscript of local/global can be only numeric or a string -- not an object reference.

So, while indeed $GET(a($THIS)) triggers something wrong, the construction itself is not correct.

Timothy's suggestion converts OREF to string:

if $GET(seen(""_$THIS)) quit

making command correct.

Notice, that in workaround you proposed -- you are using OID, that is unique identifier of object on disk. Different objects cannot have the same OID.