Depending on what you're doing, either one might be a 1-step or a 2-step process. For example, Export may consist of:

The part invoked via the APPX menu system that turns an APPX file into a flat (but still machine architecture-dependent format) file

--------------------------------------------------------------------------------

2. Converting files from ASCII to 'brf', and back

You can put the commands:

appx -e=filename (for Export) and
appx -i=filename (for Import)

... into batch scripts or crontab entries in the same way that you'd put an entry in to run an APPX process.

You'd specify -i={filename} and -e={filename} arguments, instead of the -a={application}, -d={database}, and such.

To see this argument list, run appx -u from the Unix command line, or appxutil -u from a DOS popup box.

(See Moving Files Between Platforms for further discussion of 'Endian' byte order conversion.)

--------------------------------------------------------------------------------

1. Exporting and Importing via APPX menu system

This requires recording an APPX action script (which you do interactively at the keyboard). You then set up a batch script to replay that script in unattended mode:

--------------------------------------------------------------------------------
Record a Script
Set the environment variable APPX_SCRIPT_OUT equal to a filename in which you want to save the script. For example, in UNIX, you might want to type at the command line:

export APPX_SCRIPT_OUT=/tmp/export.script

Start APPX and perform the sequence of events that you want to run via cron later.

(This part's totally up to you, so no example is provided. Think of this like recording and saving a macro in Word, for playback AND EVEN EDITING IF YOU WANT TO TWEAK IT A BIT later, except that the feature is turned on before you get into APPX and you can't turn it on and off during your APPX session.)

Exit APPX

--------------------------------------------------------------------------------
Play Back the Script

Set the environment variable APPX_SCRIPT_IN equal to the filename of the script you want to replay.
For example, if you want to replay the script above, you might want to type at the command line:

export APPX_SCRIPT_IN=/tmp/export.script

Run "appx", take your hands off the keyboard and WATCH IT GO!
If you wanted to run a bunch of these in sequence via cron in background, you are probably best off setting up an external batch file that looks like the following, and calling this batch file from cron:

# Run first APPX script
export APPX_SCRIPT_IN=/appx/scripts/export.script
appx 2>&1 >/dev/null

# Run second APPX script
export APPX_SCRIPT_IN=/appx/scripts/verify.script
appx 2>&1 >/dev/null
... etc.

You may be wondering what that "appx" line is doing. OK, here's the scoop.

"2>&1" says to redirect stderr into stdout. ">/dev/null" says to throw that stdout stream away. I think that's what most people do.

However, occasionally errors get reported on that stream, so IMHO it's useful to keep it, either for a few days (in case you don't notice a problem until later) or at least until the next time the script is run.

For example, to save the stdout/stderr stream until the next run of the same script, you could use a line like:

appx 2>&1 >/tmp/export.script

If you wanted to be fancy and save these by date, so that you could store a week (or more's worth at a time), you could do something like:

appx 2>&1 >/tmp/export.script.`date +"%y%m%d.%H%M"`

That mishmash, when executed, will resolve to a filename like

/tmp/export.script.990527.0322

... which embeds the date and time of the APPX script's START of execution, into the filename.

Of course, if you do this, you'll be creating a new file in /tmp each time you run the cron entry, so be warned that you'll have to create some sort of UNIX shellscript to remove these when you no longer want them around, or remember to delete them periodically, so that /tmp doesn't fill up.