by default IRISLIB is always read-only mounted as it holds most of system methods, utilities, compiles, ...
all code that just executes but not changes during runtime  and that you should not try to change

differently, IRISSYS holds all dynamic system data that can change during runtime and therefore requires read-write access
As configurations, namespace tables, .....

Though with system management privileges you may change this.
But I'd recommend not to touch it unless you are an in-depth IRIS expert.

another way to explain your phenomenon:

  • assume you have a.INC
  • assume inside you have #DEFINE vaXYZ
  • next, you have b.INC with an #include a
  • now your class C with include b and using $$$vaXYZ compiles fine
  • later #DEFINE vaXYZ is  removed from a.INC
  • NOTHING HAPPENS
  • you have constructed a time bomb
  • long time later you do any change on class C
  • now your bomb crashes your compilation

I experienced such a case where the bomb was sleeping for 5 years.
Nobody remembered the change of a.INC and not the reason for the change.

It seems that you have lost the ????.inc the includes the definitions of
$$$vaExtentGbl
$$$vaSegment
$$$vaSegmentGbl
$$$vaDataSegName
$$$vaDataDocName
either you  lost the related Include statement or the whole file is lost sad

So in Studio run a "search in files" over *.inc for 

#Define vaExtentGbl
#Define  vaSegment
#Define  vaSegmentGbl
#Define  vaDataSegName
#Define  vaDataDocName
to find out which .inc you are missing.

The query you changed is totally unrelated to it, as far as it seems. 

OK.
It took some investigations to understand what's going on.

the is a Class Parameter XMLUSEEMPTYELEMENT = 1;
it switches between <Ping></Ping>  and <Ping />

BUT: if ALL Properties of your reply are empty then you just get 
an empty body  <soapenv:Body></soapenv:Body>

as soon as you set some dummy value into Property Ping you get  <Ping> </Ping>
or you add a dummy property.

Digging into %SOAP.... message classes shows, that the generated messages don't use  XMLUSEEMPTYELEMENT parameter.
 

if you add to your data class

Class NAMEHERE.myDate ClassType = datatype, ClientDataType = DATE, OdbcType = DATE, Not ProcedureBlockSqlCategory = DATE ]

these 2 methods you get a kind of self healing code.
It is accessed every time you load or save your property 

ClassMethod LogicalToStorage(in As NAMEHERE.myString ""As NAMEHERE.myDate CodeMode = expression ]
{
$s(+in'=in:$zdh(in),1:in)

}
ClassMethod StorageToLogical(in As NAMEHERE.myString ""As NAMEHERE.myDate CodeMode = expression ]
{
$s(+in'=in:$zdh(in)
,1:in)
}

Hi Alex,

 "in logical Mode the date shows normal format, in my case, for example 10/1/2019"

in logical mode you get the pure content from global which is here  NOT a $H value !!

$ZD() expects an Integer to convert    =>   it is just +"10/1/2019" => 10

then $ZD(10) = " 10/1/1841"    

So it seems that some of your Dates are not stored using DisplayToLogigal resulting in an Integer
but written directly (e.g. coming from ZEN) into your object / global.

To fix it you may run something like   if +in'=in set in=$zdh(in))

"cautionary M tales" is really ages old and outdated.

But see it from reverse side: You can run without any change code that was written 40 years ago on PDP-11
I've seen it and can confirm it.
I know of no other system that allows spanning that range of time without touching the code.

But you are not forced to write that style. Or you can even write your code in BASIC if you dislike COS.