Why Concurrent Jobs May Crash

This explains why concurrent jobs may conflict with each other, causing a crash, and what you can do to remedy the situation.

We know that concurrent jobs may conflict with each other if one or more of the jobs has to translate a binary file (for example, a Header Array file) from one form (Lahey or Fujitsu) to the other. For information about such translations and the reason for them, see the GEMPACK manual chapter Converting binary files: LF90/F77L3 to/from Intel/LF95/GFortran or look in the Online GEMPACK manual.

This translation is only needed if one of your programs is accessing a binary file of the other type -- for example, if you are running an EXE produced by LF90 and the program needs to read a Fujitsu Header Array file.

If you get a crash for these reasons, the remedy is to ensure that

•you start from the right sort of binary files -- you can convert binary files between Fujitsu and Lahey using the program ConvHAR -- see manual reference above.

•you have the right sort of utility EXEs (for example, SLTOHTA.EXE) in the directory in which your version of RunDynam is installed. If you are running GEMSIM or a TABLO-generated program which produces Fujitsu binary files, you should have versions of SLTOHT etc which produce the same sorts of files. When we supply RunDynam, we supply it in two forms -- one has associated EXEs which produce Fujitsu files and the alternative has associated EXEs which produce Lahey binary files.

Please contact GEMPACK support (support@gempack.com) if you are not sure.

URL of this topic: www.copsmodels.com/webhelp/rundynam/hc_crashcause.htm

Link to full GEMPACK Manual

Link to GEMPACK homepage