When executing DSTRUN it creates inline.t3i. Here’s a sample of the contents:

devwf01:/home/bus/scripts>more inline.t3i
%connect
%begin
EX FEX-790732.FEX
%end
%disconnect
%stop_server

We plan to use DSTRUN for a few hundred schedules. We have a product called Control-M that will be used to launch ReportCaster schedules. Control-M provides for dependencies and give us more control in several ways.

My concern is that if we execute multiple schedules via DSTRUN, will there be contention for the inline.t3i file?
Will there be write errors when another schedule tries to create it?
Is there anyway to rename it or suppress it?

It took a bit to make the DSTRUN to t3i link. It is executing the server with EDASTART -X "ex afex" that creates the t3i, not the presence of a DSTRUN call in the fex. If you only have one process, then by the time the EDASTART -X returns, the inline.t3i is no longer needed. If you have two different processes running with the same current directory, each doing EDASTART -X "ex afex", I suppose you could have a conflict so you want to use unique t3i files. In which case you create a uniuely named t3i yourself and run it with the command EDASTART -f unique.t3i

Hm, I was always under the impressions, that with EDASTART -x an agent would be allocated to the request, but that just before starting that agent the commands to execute would be stored in the inline file within the agents own temp environment. That way no conflicts could arise from using the same file name because they were all stored in a different directory.
Guess I was wrong here.
But that raises another question. And that is how do I influence what name to allocate to this inline command file, when starting a scheduled job using DSTRUN?
I don't think you have any control over that....
Anyone knows what really happens in this case?

Here's what I do. I have a script and generic fex.

The following is yifex.sh

#!/bin/ksh
umask 000
export ORACLE_SID=KIDS
export ORACLE_BASE=/opt/ibi/10gClient
export ORACLE_HOME=/opt/ibi/10gClient
export ORAENV_ASK=NO
export EDACONF=/opt/ibi/713/ibi/srv71/wfs
export EDATEMP=/opt/ibi/apps/temp/$1
export EDAPROF=.
export EDAPATH=.
export FOCUSFEX=$1
export KIDSHOME=/home/eda
TEMPDIR=/opt/ibi/apps/temp/$1
if [ ! -d $TEMPDIR ];
  then echo '$TEMPDIR does not exist...Creating.'
       mkdir $TEMPDIR
       chmod 774 $TEMPDIR
  else echo '$TEMPDIR exists.'
fi
cd $EDATEMP
pwd
$EDACONF/bin/edastart -f $KIDSHOME/yifex.t3i
mv yifex.t3o $KIDSHOME/msgfiles/$1.t3o
cd $KIDSHOME
rm $EDATEMP/* 2>/dev/null
rmdir $EDATEMP

The following is yifex.fex in baseapp.

-SET &PGM=FGETENV(8,FOCUSFEX,8,'A8');
-SET &PGM=UPCASE(8,&PGM,'A8');
 EX &PGM

The following is an example on how to use in a fex:

-UNIX /home/eda/yifex.sh yi640

This is a "batch" job. I like getting all the FOCUS execution message. The only way I have figured out how to get them is by doing the above.

When the -UNIX command executes, yi640 which is a fex in the APP PATH, is $1 in the script and gets loaded into the FOCUSFEX environment variable. I also use the $1 to create a temp folder where the job can run. Since I don't have to worry about the job running multiple times at the same time I don't account for that but you could easily by generating a random # and adding it to the -UNIX command. In the script the random number would be $2 and you would modify the script accordingly.

When the edastart command is run, it runs the yifex.fex. It gets the contents of the environment variable FOCUSFEX and loads it into &PGM. Then the fex does an EX &PGM.

The output messages are then written to the yifex.t3o file in the temp folder. When the fex finishes, I rename/move the message file to the permanent location, then delete the temp folder.

I do this for all types of batch processes. It has been working great for over 5 years.

BobSh and I worked together to implement something similar to the solution provided by jgelona.

We created a temporary directory under our application directory (similar to jgelona's temp directory). We used the current UNIX process ID of the script to establish the new temporary directory (ie, ...\temp\123456).

Prior to running edastart -x, we changed directories to the fully qualified new tempoary directory. However, we did not create a unique .t3i file as the t3i file is now created in the pid directory because the edastart -x is initiated while in that directory.

As other scripts would create their own unique pid directory, there is no conflict with other scripts potentially running at the same time.

Using this technique, all of the temp files used in the edastart -x focexec as well as the inline.t3i file are self-contained under the unique pid directory. Once the process is done, the pid directory can be removed to keep things cleaned up.