create new tag
view all tags

Automating Export/Import with Unix Crontabs

"Can I run an APPX process via a Unix command (one liner) to Export and Import? I would like to setup a crontab to handle this if I can."

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

  1. The part invoked via the APPX menu system that turns an APPX file into a flat (but still machine architecture-dependent format) file
  2. The part invoked via the "appx -e=filename" which turns the machine dependent format into APPX's portable interchange format. (This is an optional step for going between machines with different byte orders, like between RS/6000 AIX and Windows boxes)
Each of these steps would be automated in different ways. The second is shorter, so we'll discuss it first.

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.

(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

    1. Set the environment variable APPX_SCRIPT_OUT equal to a filename in which you want to save the script. For example:

      export APPX_SCRIPT_OUT=/tmp/export.script

    2. 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.)

    3. Exit APPX

    4. Copy the script just created to a new name (so it doesn't get overwritten next time you enter APPX).

    5. You can look at the script in vi (or some other editor) if you want. You'll see it's a logical trace of the options you chose and input you provided.

Play Back the Script

    1. Set the environment variable APPX_SCRIPT_IN equal to the filename of the script you want to replay.

      For example:

      export APPX_SCRIPT_IN=/tmp/export.script

    2. Run "appx", take your hands off the keyboard and WATCH IT GO!
If you wanted to run a series 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.HELPM"`

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


... 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.

(See additional documentation for further discussion of Keystroke Recording and Playback.)


Read what other users have said about this page or add your own comments.

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2016-01-21 - JeanNeron
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback