New post
AllAccepted answers
Alexey Maslov · Mar 17, 2020

Just adding 2c to Kevin's reply.

Most hosts that support TCP also support TCP Keepalive  

Besides, server application should support it. 3 hours keepalive time setting is not typical; it sounds like your server app not tuned for keepalive support or doesn't support it at all.

In case of IRIS/Caché, you should explicitly set some options on connected server socket, e.g.:

start(port) // start port listener
  s io="|TCP|"_port o io:(:port:"APSTE"):20 e  quit
  while 1 {
   u io r x
   u $p // connection is accepted: fork child process
   j child:(:5:io:io)
  }
 
child
  use $p:(:/KEEPALIVE=60:/POLLDISCON)
  ...

/KEEPALIVE=60 to set keepalive time to 60 seconds
/POLLDISCON to switch on TCP probes.

Alexey Maslov · Feb 5, 2020

Dmitrii,
Your ideas sound interesting, while I have some doubts. One usually needs speed for scientific calculations. Skipping the discussion how good ObjectScript as interpretated language fits this need, if we place upon our (even small) additional interpreter, nobody would envy our calculation speed.

Your most infamous errors list can be appended with many others, such as "DO I=1.3" error which destroyed some satellite. Besides, missing The International Date Line example is merely logical error that derives from "common" inaccurate development practice.  Alas, such development errors list is sadly long, and I doubt if physical measures mismatch has the highest rate among others.

Alexey Maslov · Feb 5, 2020

The easier the better:

 if $data(^$Job(PID)) // then the process with PID is running...

But each method mentioned above has a potential problem: if the process with PID had finished far ago, the O/S PID counter could run a full cycle, and another Caché (IRIS) process could start with the same PID. The full solution may worth a separate article, while the simple one is: just to collect garbage often enough. To my experience, once a day is usually quite enough even on high loaded systems.

Alexey Maslov · Dec 11, 2019

Marat, 

Maybe it's possible to build a dictionary of wrong decoding of typical words and use it for encoding guessing. E.g., a word 

לרפא
will probably be a typical one in a medicine text. Wrong decodings can be collected using a tool like this. Using pronouns, articles or prepositions as "universal" typical words can even be a better idea.

Alexey Maslov · Dec 11, 2019

...otherwise all the gibberish lines look the same
 

While you are basically right, some euristics can help to find an answer. A line that matches a pattern: line?1(1U.L,.L,.U) is more likely encoded correctly than "camel case" one. After modifying Eduard's sample a bit: 

AutoCode
 new $namespace set $namespace="%SYS"
 Set Text = "ÍàØâàÞæØâë"
 Set Ref = ##class(Config.NLS.Locales).OpenCurrent(.Sc)
 Write "Locale name: ",Ref.Name, !!
 Do Ref.GetTables(.Tables)
 Set Key = ""
 For { Set Key = $O(Tables("XLT", Key)) Quit:Key=""  s line=$zcvt(Text, "I", Key) if line?1(1U.L,.L,.U) Write Key," ",line,!}
 q

we are getting (likely) correct answer without knowing a target language:

USER>d AutoCode^ztest
Locale name: yruw

LatinC Эритроциты 1

There are some other problems, e.g. system built-in tables such as UTF8 are not included, but they can be solved. Writing universal cyrillic decoder is not so easy task, but as there are some already exist in web, it's possible to write another one.

Alexey Maslov · Dec 9, 2019

It seems that try / catch paradigm encourages one to propagate exceptions. Otherwise it's easy to get a "style mix" that looks unpleasant, something like: 

   ...
   set sc=##Class(Config.Databases).Get(pDBname,.pProp)
   if 'sc goto gDBPropQ ; more characters to type and less expressive
  
  } catch ex {
   set sc=ex.AsStatus()
  }
gDBPropQ
  quit sc
}

or 

  ...
  set sc=##Class(Config.Databases).Get(pDBname,.pProp)
  if 'sc return sc ; many exit points from one method contradicts
                   ; with reasonable principles of modular coding
 } catch ex {
   set sc=ex.AsStatus()
 }
 return sc
}

All this stuff is just IMHO, just an attempt to be consistent. 

Alexey Maslov · Dec 9, 2019

Just a quick note: when errors are processed consistently, e.g. each %Status have been returned is processed with $$$TOE or $$$ThrowOnError  or $$$ThrowStatus macro, this approach seems to be excessive, and `set sc=ex.AsStatus()` is just enough. E.g. 

ClassMethod GetDBProp(pDBname, ByRef pProp, pDivide = 1) As %Status
{
  try {
   new $namespace set $namespace="%SYS"
   set sc=1/pDivide ;potential <DIVIDE>
   $$$TOE(sc, ##Class(Config.Databases).Get(pDBname,.pProp))
  } catch ex {
   set sc=ex.AsStatus()
  }
  quit sc
}

For me, unexpected %objlasterror is no more than a sign of inaccurate coding, when some %Status values are not processed.