I have a series of processes which consists of a master process (process 010) which calls worker processes (process 100, 110 and possibly 120). Process 010 defines various global variables so that the worker processes can populate them and pass them down the line. It is the one and only process defined in a chore which runs overnight, every night. The other processes are called (or not) by 010 via ExecuteProcess().
In summary:
- Process 100 grabs a list of all new payruns from the payroll system via ODBC, and writes their details into a Payruns cube.
- Process 110 scans through those payruns to check for any anomalies, and also compiles a list of the payruns which have been paid but not yet uploaded into the reporting cube. It stores that list in a delimited global string variable, because it's not like we have arrays or dictionaries, much less objects in TI, is it IBM??
- If that string is empty, the chore's nightly work is done, and it ends.
- Otherwise, process 120 is called. Process 120 does a pull of the payrun data (again by ODBC) for all of the payruns listed in the global string that process 110 populated. It runs a validation process to check for errors such as invalid element names, employees who don't have master data, etc. If it finds any, it will write out error logs, or, if the data is bad but there is a known workaround, it will write advisory logs. (Eg if an entry uses an invalid account number, but the process knows what the right one is, it writes a log saying "For this entry I'll use account 123456 instad of ThisIsAStuffedAccount.")
I ran that on Saturday morning.
But during the Saturday night, and the Sunday night, the payrun process kept generating the advisory warnings.
Except those payruns had been uploaded, so process 110 should not have been finding any new payruns to check, meaning that process 120 should not run, meaning that there should be no advisory logs.
Why were the logs there?
I ran the 010 process manually. It correctly stopped after process 110.
I ran the chore. It called process 120, which it should not have.
This is what the manual has to say about Global Variables:
Yup, uh-huh, I knew that...IBM wrote:Global variables can be declared within a process that is part of a given chore. Once declared, the global variables are available to all other processes that are part of the chore.
Yup, knew that too.IBM wrote:The variables persist while the chore is executing
Uh-oh.IBM wrote:and for the duration of the current server session. Global variables are destroyed upon server shutdown.
Except... this isn't entirely true. I've been using global variables for years and have never come up against this problem. The difference is that:
(a) With most global variables I've explicitly initialised them each session; with this one I didn't; and
(b) A lot of the processes in which I use globals are not scheduled constantly.
And that's the key. The information above is wrong. The values do NOT persist for the duration of the server session. They do however persist for processes which are called as part of a chore... as long as that chore remains scheduled. That's why when I ran process 010 independently, there was no value in that variable, while there WAS a value when I ran the chore before I turned the chore schedule off. HOWEVER, as soon as I turned off the chore scheduling and ran the chore again... the variable was clear, because the value was dropped.
So, remember boys and girls, when you use global variables? Explicitly declare the value of the damn things so that the value will never carry over from a previous run.
