Background queues
Sorry for the long delay, I just saw this today 5/26/06
you need to supply the name of the batch queue in a file called
/usr/symix/batch/queue. See below from the Infor web site. Or log in and search for "background queue".
Here is the solution: Batch scheduling procedures with Syteline
UNIX
CRON
The cron daemon is a command run in the background by UNIX - or, more specifically, by init, the master program. The function of cron is to provide scheduling services. You can ask cron to run a program at a specific time, periodically, at a particular time every day, or whenever the load on cron permits. The use of the cron daemon must be permitted by the system administrator.
MICROSOFT NT
The AT command is a command line scheduler that is bundled with the NT Server operating system. The AT command schedules commands and programs to run on a computer at a specified time and date. The NT schedule service must be running to use the AT command.
BACKUP SOFTWARE SCHEDULER
NT has a variety of backup software available for use. Many of the packages include a scheduling service for automating backups, command files (.bat and .cmd), and the execution of certain processes.
With the nature of the NT's operating system and its use of memory segments, it has become apparent that there are certain restrictions for addressing a Progress database on an NT server. Often, if you use a specific method for starting a Progress database (i.e.; AT), you must use the same method to continue to address the database server process. This is true for running promon, crash recovery, downing the database, etc.
SYTELINE AND SCHEDULING SERVICES
Below is a list of pointers for shutting down and starting up the server and related background processes.
This document makes the assumption that all files referenced are in the operating system path. You may find that you will need to explicitly reference the location of the desired file for your use. Additionally, it is necessary to properly path out the DB and/or parameter file options. For example:
NT & UNIX
The command: promon symix
NT
Would become: cd \dlc-srv\bin
promon c:\sym-srv\db\symix
UNIX
Would become: cd /dlc/bin
promon /usr/symix/db/symix
Use the proserve command, followed by the parameter file. The parameter file will be the name of the database plus .pf. Refer to Progress System Administration Manual for more information about the proserve command.
NT & UNIX
For example: proserve -pf symix.pf
Remember this command needs to be issued for each database that needs to be started, the main, scheduling, and global database if multi-division is being used.
SHUTTING DOWN THE SERVER
Use the proshut command, followed by the path and name of the database and the option for an unconditional shutdown (-by). Refer to Progress System Administration Manual for more proshut options.
NT & UNIX
For example: proshut -db /usr/symix/db/symix -by
Remember this command needs to be issued for each database that was started. After the server is shutdown, the before image file can be truncated. This can be done by using the proutil command, followed by the database name and truncate options. Refer to Progress Manual System Administration for more information on the proutil command.
NT & UNIX
For example: proutil dsymix -C truncate bi -biblocksize size
Note: According to Progress the proshut command was not designed to remove the background Progress processes. Therefore, make sure you follow the additional instructions for shutting down Background Report Queues, Background Job Process and Data Collection. In addition, the proshut procedure may hang if a progress process is holding a vital system resource. If a backup command is issued in the scheduling software after the servers are shutdown, it is recommended to allow a five minute time allowance prior to the backup command. In order for a backup to be successful the proshut command needs time to finish properly
STARTING DATA COLLECTION (DC) BACKGROUND PROCESS
Use the mbpro command, followed by the background data collection polling program (dc\s-dcpoll.p) and the multi-user run parameter file. The collect program periodically polls the controller and transfers data to the database.
UNIX
For example: mbpro -p dc\s-dcpoll.p -pf dsymixrun.pf > logfile
NT
For example (Progress 7): _prowin -b -p dc\s-dcpoll.p -pf dsymixrun.pf -ininame symix.ini
For example (Progress 8): prowin32 -b -basekey INI -p dc\s-dcpoll.p -pf dsymixrun.pf -ininame symix.ini
SHUTTING DOWN DATA COLLECTION (DC) BACKGROUND PROCESS
The Data Collection can be shutdown by setting the Shutdown Polling parameter in Data Collection Parameters to yes. When the Shutdown Polling parameter is set to yes, the shutdown occurs at the next polling interval.
A program to set this parameter is not available in Symix v3.0, therefore, it would be necessary to write a progress program and have Full Development Progress to compile it. For instructions on how to find the mbpro process in order to issue a kill command, refer to your Operating System manuals.
To automatically shutdown data collection background process use the mbpro command, followed by the multi-user run parameter file and the background data collection polling shutdown program (dc\n-dcpoll.p). The SyteLine program dc\n-dcpoll.p runs lib\db-alias.p and dc\stop-dc.p and then sets the "Shutdown polling" parameter to "Yes".
UNIX
For example: mbpro -pf symixrun.pf -p dc\n-dcpoll.p > logfile
NT
For example (Progress 7): _prowin -b -pf symixrun.pf -p dc\n-dcpoll.p -ininame symix.ini
For example (Progress 8): prowin32 -b -basekey INI -pf symixrun.pf -p dc\n-dcpoll.p -ininame symix.ini
You should shutdown data collection background process prior to shutting down the database server. Allow a 5 minute time frame to elapse prior to taking the database down after shutting down data collection. You may want to allow 1 ½ times your poll cycle so transactions have time to post from the previous cycle. If the poll frequency is 300 (5 minutes), you may want to allow 7 ½ minutes for the DC shutdown to occur.
STARTING BACKGROUND REPORT QUEUES
Use the mbpro command, followed by the background report queue program (batch\s-rpt.p) and the multi-user run parameter file. The SYMIX program batch\s-rpt.p runs lib\db-alias.p and batch\rpt.p which monitors the Report Queue Maintenance found off the Background Processing menu in Utilities. The program batch\rpt.p starts the background process for whichever queue is in the file batch\queue. Therefore, if more than one queue needs to be started, the mbpro command must be executed for each queue. Before the mbpro command is executed the batch\queue must contain the correct queue name for the queue to be started. After the background process has been started for a queue, the file batch\queue is removed.
For Unix, Symix has supplied a script file. It is located in the batch directory and called rptrun. Make sure $RUNDIR is on your O/S PATH for root then issue the commands:
cd $RUNDIR
batch\rptrun
from within your cron script and it will start all the background queues. The file batch/queue.lst must contain at least one queue name before this script will function. (In the above example $RUNDIR is your main Symix/SyteLine directory. Substitute the literal path to your Symix/SyteLine directory in the command.) Additionally, you may use the following information to start a queue.
UNIX
For example: mbpro -p batch/s-rpt.p -pf dsymixrun.pf >> queue.log
UNIX
Example of starting two queues:
Suppose there were two queues that needed to be started and the queue names were FIRST and SECOND. Create a file in the batch directory for each queue with its contents being the queue name.
In our example assume the following:
Filename: batch/first batch/second
Contents: first second
Example of a script that could be used to start both queues:
cp batch/first batch/queue
mbpro -p batch/s-rpt.p -pf dsymixrun.pf >> queue.log
cp batch/second batch/queue
mbpro -p batch/s-rpt.p -pf dsymixrun.pf >> queue.log
Note that you may want to set the umask to something like 000 in the script (umask 000) just prior to starting the queue so that any file output has permissions that are more open. This is especially useful if users submit reports to the queue and designate the output destination to be a file. Since that file will be owned by the account that is actually running the queue, the user may not have permissions to delete the file once they are done with it. By using the umask command you could reduce the default restrictions placed on new files created by that account. Read the "man" pages (man umask) for a more complete explanation of using this UNIX command.
