Previous to Priority, my company worked with an ERP program which had very strong support for spawning jobs and creating reports in the background. This was very useful as some reports used to require a long time - at least an hour - to be created. There was also a very simple but powerful method of creating macro files which would create these reports. As I recall, I would write something like
21.4
14
03
32
4
LP2:
which would mean "run report 21.4, pass it the parameters 14, 03 and 32, then send the output to printer LP2:" (the 4 meant 'run the program immediately' as opposed to 'run the program in the background'). Aligned with the job scheduler of the server, I would define such jobs to run during the dead time of the evening and early morning. Each morning I would arrive at work to find a huge pile of paper with the various reports printed; I would divide up the reports and put them in people's pigeon holes.
Time progresses: we no longer have pigeon holes, line printers and the old, single tasking, ERP program; we now have multi-tasking Priority and email. When we first started work with Priority, I adopted my habits to running reports manually in the morning then sending them by email. This takes about 15 minutes but sometimes can be a hassle as I prefer to create the reports before people have started working.
Priority does have a task scheduler although accessing and using it is harder than the old program. I use it a great deal for programs which take a long time to run (e.g. costing) and produce no output. Several times the systems manager and I have tried to define email on the server but without success ... until yesterday. Finally I can send emails automatically from the server.
At first, I thought that this was excellent, but when I started to examine the situation, I was less than thrilled. The main problem is that there is no simple way of passing parameters to the programs; even though I have found a way of overcoming this, it means that I frequently have to rewrite the programs (or more accurately, create a copy of the normal program then change the copy) to handle automatic parameters. Another, more conceptual, problem is that I like to see some of the reports and comment where necessary; sending them automatically means that I won't see them at all.
So far, I have adopted three reports for automatic distribution: two go to distribution lists and one goes to myself so that I can work on the data. Both this report and one of the distribution list reports take a comparatively long time (about 10 minutes) to run, although I used to interleave their creation with other tasks. In other words, I would start a long report then work on something else until the report displayed, thus not wasting time waiting for reports to appear. All three reports are defined in the equivalent of a large macro file whose execution is defined in the task scheduler. Thus I can add new functionality without having to change the task scheduler.
It has to be said that few reports take an excessive amount of time to run, so automating them is not much of an advantage. Creating them automatically does take responsibility off my shoulders and
also means that I don't have to log in first thing in the morning when
I'm on holiday.
Over the next week, I am going to see how using an automated task can improve the quality of my work.
After having completed writing the above (but prior to publication), someone phoned me and asked how she could send a customer a copy of all the delivery notes for that customer for the previous (or current) day - there can be at least ten such notes. It occurs to me that I could write a program to do this and I could even automate it. Saving overhead time for users is always a good idea and is my prime directive.
No comments:
Post a Comment