Shell Programming and Scripting

zip has a delete option, and a zip mounted to a PC is a directory!

Long shot but I would suggest you eliminate the main and init functions and place the code in these functions directly into the shell script to ensure that declared variables have global scope. Depending on the version of ksh you are using, you can run into variable scoping issues declaring variables within a function and then using that variable in another function.

Often, if variables are first loaded or exported in the ksh main flow, then references to them in functions work, unless the function ends up in a pipe chain and so in a child process, in which case it can set it for its own benefit, but that change does not make it back to the parent.

A great part of learing is learning what works and staying away from wha does not, so life is double hard as a newbie: wrong approach, coded wrong, unstable or unworkable, much longer than necessary, usually not nicely formatted, and for many experts trying to help, not like anything they would write. I have an acronym, OPC, for other people's code or children. One obstacle to reusable code is that it may be cleaner, easier, better to write from scratch and discard. I use cscope (on a web server) so I can find bits of code without looking at all that OPC!

You mention that this is an hourly job. I assume cron.
There is potential for the script to misbehave if any run takes longer than one hour because the workfile names in /tmp do not have unique names.
May be worth having a simple interlock mechanism (e.g. a "flag" file) to prevent a second instance starting.

Yes, or a simple ps test:

Code:

if [ $( ps -fu "$USER" | grep -c "${0##*/}" ) != 2 ]
then
  ... # report overrun
  exit 1
fi