You can get the pid without iteration.

|nsp| is only required for access to a lock in a different namespace.

as you describe if you refer to a file outside Caché and Caché has no control over it
it's a clear case of data inconsistency

you have 4 options:
1a) create a fake file at that reference an delete it then

1b) add an "on before delete" trigger to check and fix in advance either in the record or  in file system 

2a) manipulate the file reference using the object behind your entry

2b) do the delete at object level, trap the error and ignore it. since the file is gone anyway 

when you generate Classes from XSD you require a reference. That' s where xsd is stored.  It may make sense to ich copy it first to your default repository and generate your classes after.

In fact, I see not 1 but 2 tables that share the same global.

so it might be easier to have 2 separated definitions one with and the other without the  4th subscript (some $h)

for access with SQL you than can use a UNION to assemble them. like:

or  you decide to add the missing subscript in your global to have a common structure

If this is Caché standard ID it is projected to SQL as xDBC Type INTEGER
Caché SQL Reference - Data Types says:

so 5983658923646 is definitely out of range

xDBC Type :

   represents a 64 bit integer value.

I'm not aware of any parameter to change the data type of the generated ID.
But this hack may do the trick. Just add this calculated Property to your class without affecting the storage.

Property myID As %BigInt [ Calculated, SqlComputeCode = { set {*}=%ID}, SqlComputed ];
 

I tried it now in Caché 2016.2.2 manually overwriting Storage <Type>%Storage.Persistent</Type>.

During compilation it gets automatically set back to <Type>%Library.CacheStorage</Type>
Also in class defintion.

Does this automatic change go back to repository ??? 

At first sight in Documatic, it  looks like 

 was just renamed to  

%Storage.Persistent

As a workaround, I would simply try in Caché to make a copy of  %Library.CacheStorage to a new %Storage.Persistent
(a pure rename)  Then compile a class with one and the other and compare the generated .int code.

It's a dirty hack. 
But I have no hope ISC will ever provide some backward port from IRIS to Caché.

Sorry I have no IRIS at hands and can't try it myself.

You may try WebTerminal over HTTPS as an alternate way for access.

It's really a matter of taste.

If you don't like the long list of params (especially with lousy documented methods) you can

#1) use 1 single param and pass a local array byRef .  and decode it yourself eg:

or

#2) use the traditional style you may know from Caché I/O Device Guide  having also just 1 parameter

I personally prefer #2) as it gives you an embedded doc on your intentions.

#1) all documentation on XML is here

It covers everything to output Objects to XML.

#2) to fill  this in-between object you may use the SQL Table represented by an object class.
 as simple INSERT  INTO  my.xmltable select .........

You just have to take care that the object class also extends %XML.Adapter .
That makes it ready for XML Export.  All details described in docs  

Dear Martin,

I have a rather clear vision  where your $example comes from ($zzg, $zza, ...)  
My personal suggestion is to move everything you maintain today in %ZZLANG?00 routines into clean Macro definitions (.inc)

The history of %LANG* code goes back to times when migration from other language dialects (MSM, DTM, DSM, VISOS, ..) happened
and developers were writing just in  .INT routines. That's far back in the late 80ies.  The availability of MACRO code (also ages back) made it almost obsolete. The feature was never eliminated by considerations of backward compatibility. 

I personally would never allow any developer to touch %SYS. 
And wouldn't accept any code using $zz* , zz* stuff or $zu().
There are much cleaner ways to achieve the same result without compromising the core. 

You may take my previous article The 'unlimited' UNIQUE index as a suggestion how to work around this limit.

I may misunderstand your intentions but

when I use "ResultSet.%Get("Collection")", all I get is a list of the primary keys of the objects. 

now you all you miss for each PrimaryKey is 

Set collB=##class(ICT.Experiments.B).%OpenId(primaryKey) 

or

Set collC=##class(ICT.Experiments.C).%OpenId(primaryKey)

and the object is yours.

With your class definition,  PrimaryKey is the Idkey of the Object.

the structure of $LB() is rather simply a binary string

-----------element--------------
TotalLength = 1, 3, 7 bytes depending on size    *corrected*
Type = 1 byte  (check in JSON converter for codes, or just check with ZZDUMP)
Content : size = TotalLength-1-size of length field
-----------element--------------
TotalLength = 1, 3, 7 bytes depending on size    *corrected*
Type = 1 byte  (check in JSON converter for codes, or just check with ZZDUMP)
Content : size= TotalLength-1-size of length field
-----------element--------------

...

Therefore concatenation of $lb) is so easy

I could imagine inheriting standard data types for a customized data type and then 

adding methods LogicalToStorage and StorageToLogical  similar as LogicalToObs, ....
So your manipulations happen on the way from Global to the local variable.

Additional Parameters eventually may control the generated code.

It's just a vague idea.

Ken Olson , the founder of DEC (Digital Equipment Corp.) was  famous for its statement:

• "I can't imagine any good reason for someone to have a computer at his home"

 Similar in the late 1950ies IBM estimated the worldwide market for computers of 15..30 systems in total.

So lack of phantasy what could be in the future is quite common also for very successful people and companies.

inside &SQL() only SQL compatible code is allowed
so $ZDT($H,3,1,3) is not known in SQL

you may do

mind the colon :%myts and :%tx to pass global  accessible variables to embedded SQL

At first sight, I'd say you are looking for iKnow.  Take a look