Background Processing
Started by Chian Yuh Choo, Mar 19 2001 01:36 AM
28 replies to this topic
#16
Posted 20 March 2001 - 12:01 AM
You check how you did - SLBQUES.
As for '&' this is a UNIX command to 'fork' the process into the background.
As for '&' this is a UNIX command to 'fork' the process into the background.
#17
Posted 20 March 2001 - 01:09 AM
The Background Processing should be executed automatically, you should not have to issue a 'pro QUE1' from UNIX.
When a Queue is executed for the first time, a record with a key of the Queue Number is left in batchque.pro. In a later post, you say that iskeys shows you have one record in batchque.pro with a key of 1. If SLBQUES shows no entries then this probably means that the Update function that you queued was executed.
How are you checking whether the function has been executed ? Does it write to a file that can be checked ? If the Update function that you are trying to place in the queue is a small one, then I suspect that it is being executed before you have a chance to use SLBQUES to view the entry. Changing Transparent Logon ? value to No for Operator ID QUE should effectively stop Background Processing. When you run the Update function that you wish to run in background, you should be able to view that entry via SLBQUES. Try that, if that works then we know that the function is being queued correctly.
Set Transparent Logon ? back to Yes, and clear any entries that may be left in the Background Processing queues. Execute the update function. Do NOT run pro QUE1 from UNIX. Check the queue. If no entry exists, then has the update function done anything (i.e. has it written to any files) ?
When a Queue is executed for the first time, a record with a key of the Queue Number is left in batchque.pro. In a later post, you say that iskeys shows you have one record in batchque.pro with a key of 1. If SLBQUES shows no entries then this probably means that the Update function that you queued was executed.
How are you checking whether the function has been executed ? Does it write to a file that can be checked ? If the Update function that you are trying to place in the queue is a small one, then I suspect that it is being executed before you have a chance to use SLBQUES to view the entry. Changing Transparent Logon ? value to No for Operator ID QUE should effectively stop Background Processing. When you run the Update function that you wish to run in background, you should be able to view that entry via SLBQUES. Try that, if that works then we know that the function is being queued correctly.
Set Transparent Logon ? back to Yes, and clear any entries that may be left in the Background Processing queues. Execute the update function. Do NOT run pro QUE1 from UNIX. Check the queue. If no entry exists, then has the update function done anything (i.e. has it written to any files) ?
PRO-IV free for 385 Days
#18
Posted 20 March 2001 - 02:04 AM
My objective is execute a number of PRO-IV update function outside PRO-IV. Thus I wish to create a queue to group all of my update function. I need execute this queue that using command 'pro QUE1'. It is correct way?
I tried to set transparent to 'N' but nothing happens. My files still not update. And SLBQUES is empty.
May I know any queue setting I am missing?
I tried to set transparent to 'N' but nothing happens. My files still not update. And SLBQUES is empty.
May I know any queue setting I am missing?
#19
Posted 20 March 2001 - 02:17 AM
Have you executed the Update function that you wish to process in Background ? When you call the function you should see a WRITEQUE function executing not the name of the update function that you are calling. This means that the function will not be executed now, but via Queue 1.
PRO-IV free for 385 Days
#23
Posted 21 March 2001 - 05:44 AM
thankyou for helping
Shaun Rudland was solved my problem.
thankyou Shaun Rudland!!
But I still not understand why I can not update details for BATCHQUE.pro.... I am only can add QUEUE ID and priority(I saw it by using 'iskeys'. Do you know why? Or I need to cut all related screen for you?
Shaun Rudland was solved my problem.
thankyou Shaun Rudland!!
But I still not understand why I can not update details for BATCHQUE.pro.... I am only can add QUEUE ID and priority(I saw it by using 'iskeys'. Do you know why? Or I need to cut all related screen for you?
#25
Posted 27 March 2001 - 03:04 PM
I get the same thing you did. It says ReadQue:
Update in Progress - Please wait. But it never finishes
I see you later fixed your problem. Can you help me.
my script is: $CHESS_PRO QUE1 QUE
You can email me at heflueckiger@auburngear.com so we do not junk up this board I really thank you.
Update in Progress - Please wait. But it never finishes
I see you later fixed your problem. Can you help me.
my script is: $CHESS_PRO QUE1 QUE
You can email me at heflueckiger@auburngear.com so we do not junk up this board I really thank you.
#26
Posted 27 March 2001 - 03:35 PM
Mr. Rudland;
I am having the same problem as Mr. Choo.
I know the function works, but once I try to run it from the Que1 it says Read Que:
UPDATE IN PROGRESS - PLEASE WAIT
But it never updates my file.
my command line in unix (hp-ux) is:
$chess_pro Que1 Que
How do I know if my function is the one in the que. I did the iskeys and it says it has one.
Please email me at heflueckiger@auburngear.com if I can give you better information and attachments.
Thank You
I am having the same problem as Mr. Choo.
I know the function works, but once I try to run it from the Que1 it says Read Que:
UPDATE IN PROGRESS - PLEASE WAIT
But it never updates my file.
my command line in unix (hp-ux) is:
$chess_pro Que1 Que
How do I know if my function is the one in the que. I did the iskeys and it says it has one.
Please email me at heflueckiger@auburngear.com if I can give you better information and attachments.
Thank You
#27
Posted 27 March 2001 - 06:29 PM
G'Day Flip,
First of all, Shaun will be fine. Only bank managers and police officers call me Mister.
The first question is, 'Is Background Processing what you want to use ?'.
Are they maintenance functions that run daily that clean data, move data or prepare data ? We will call these utility functions; functions that require no user input. If they are, then 'standard' Background Processing is not what you want. Background Processing is really useful when you have on-line users that are running large updates or reports. The user does not want to sit and wait for the update to finish; the user wants to continue entering data on the screen. The update is queued in Background Processing and control is returned to the user so that they can continue with their work while another PRO-IV process actually executes the update.
Which type of functions are you trying to set-up to run in background ? If they are utility functions then we need to take a different approach.
If they are not utility functions then .......
One of the main points about Background Processing is that it is 'self-processing', therefore you do not need to issue a command string from UNIX in order to initiate queue processing. If a function has been designated to run in background (i.e. Queue ID and Priority set via $SPOOL), then when an attempt to execute the background designated function (BDF) is made, the BDF is placed in the appropriate queue via bootstrap function WRITEQUE, and control is returned to the function that attempted to execute the BDF. If the BDF is the first entry in any given queue, then an attempt will be made to process the BDF immediately. This means that you will probably not have time to see the entry in the queue before an attempt to execute the BDF is made.
However, when queues are being processed output is directed to batch(q).out, where (q) is the Queue ID (1-9 or A-Z). These ascii files are created in the PRODATA directory. Any output that is generated by the BDF that is normally output to the screen is directed to the batch(q).out file, including error messages and user messages.
I have created a very (VERY) simple function that creates a record in a PRO-ISAM file, which I've attached in an out file. The attachment is BACKPROC.OUT, which is an ISOUT of a Native PRO-IV Export File. ISIN will create a file called BACKPROC.PRX. Using the Native PRO-IV Import ($XFR), import the function SJRU1 including Development Specs and File Definitions. The function contains one file, which is called SJRFILE. After Import you will probably need to alter the Security Category for both Function and File. Physically create the PRO-ISAM file SJRFILE.PRO.
Modify SJRU1 and remove the Batch Queue ID and Priority. Regen and execute the function. Perform an ISKEYS on SJRFILE.PRO, and you should have one record which was the time that the function ran. This will check that the function works fine in foreground processing.
Modify SJRU1 and set Batch Queue ID to 1 and Priority to 1. Regen and execute the function. You should see the WRITEQUE function name appear in the top right hand corner of the screen, and a 'REPORT HAS BEEN QUEUED' message at the bottom left of the screen. If this happens, then the function has not been executed in foreground, but has been added to the Background Processing Queue. If Background Processing is working, then the function will automatically be picked-up from the queue and executed using Background Processing. Use ISKEYS to check SJRFILE.PRO. If you have another record in the file SJRFILE.PRO, then Background Processing is working fine. Check that batch1.out has been created, and view the contents, which should look something like this:-
READQUE:
UPDATE IN PROGRESS - PLEASE WAIT
SJRU1:
UPDATE IN PROGRESS - PLEASE WAIT
If this works, then delete batch1.out and try attempting the same thing with your function.
Good Luck
Shaun
First of all, Shaun will be fine. Only bank managers and police officers call me Mister.
The first question is, 'Is Background Processing what you want to use ?'.
Are they maintenance functions that run daily that clean data, move data or prepare data ? We will call these utility functions; functions that require no user input. If they are, then 'standard' Background Processing is not what you want. Background Processing is really useful when you have on-line users that are running large updates or reports. The user does not want to sit and wait for the update to finish; the user wants to continue entering data on the screen. The update is queued in Background Processing and control is returned to the user so that they can continue with their work while another PRO-IV process actually executes the update.
Which type of functions are you trying to set-up to run in background ? If they are utility functions then we need to take a different approach.
If they are not utility functions then .......
One of the main points about Background Processing is that it is 'self-processing', therefore you do not need to issue a command string from UNIX in order to initiate queue processing. If a function has been designated to run in background (i.e. Queue ID and Priority set via $SPOOL), then when an attempt to execute the background designated function (BDF) is made, the BDF is placed in the appropriate queue via bootstrap function WRITEQUE, and control is returned to the function that attempted to execute the BDF. If the BDF is the first entry in any given queue, then an attempt will be made to process the BDF immediately. This means that you will probably not have time to see the entry in the queue before an attempt to execute the BDF is made.
However, when queues are being processed output is directed to batch(q).out, where (q) is the Queue ID (1-9 or A-Z). These ascii files are created in the PRODATA directory. Any output that is generated by the BDF that is normally output to the screen is directed to the batch(q).out file, including error messages and user messages.
I have created a very (VERY) simple function that creates a record in a PRO-ISAM file, which I've attached in an out file. The attachment is BACKPROC.OUT, which is an ISOUT of a Native PRO-IV Export File. ISIN will create a file called BACKPROC.PRX. Using the Native PRO-IV Import ($XFR), import the function SJRU1 including Development Specs and File Definitions. The function contains one file, which is called SJRFILE. After Import you will probably need to alter the Security Category for both Function and File. Physically create the PRO-ISAM file SJRFILE.PRO.
Modify SJRU1 and remove the Batch Queue ID and Priority. Regen and execute the function. Perform an ISKEYS on SJRFILE.PRO, and you should have one record which was the time that the function ran. This will check that the function works fine in foreground processing.
Modify SJRU1 and set Batch Queue ID to 1 and Priority to 1. Regen and execute the function. You should see the WRITEQUE function name appear in the top right hand corner of the screen, and a 'REPORT HAS BEEN QUEUED' message at the bottom left of the screen. If this happens, then the function has not been executed in foreground, but has been added to the Background Processing Queue. If Background Processing is working, then the function will automatically be picked-up from the queue and executed using Background Processing. Use ISKEYS to check SJRFILE.PRO. If you have another record in the file SJRFILE.PRO, then Background Processing is working fine. Check that batch1.out has been created, and view the contents, which should look something like this:-
READQUE:
UPDATE IN PROGRESS - PLEASE WAIT
SJRU1:
UPDATE IN PROGRESS - PLEASE WAIT
If this works, then delete batch1.out and try attempting the same thing with your function.
Good Luck
Shaun
Attached Files
PRO-IV free for 385 Days
#28
Posted 28 March 2001 - 10:15 AM
Shaun,
Thanks alot I did what you said and both yours and my fucntions perfromed perfect. My fucntion is an update and it updated the file as required.
Have one problem now. When I create a script file to run to do the same thing I only get:
Readque:
UPDATE IN PROGRESS - PLEASE WAIT
Well no matter how long I want it does not run.
My script file is as follows:
.ch320c.env (this is the standard chess env)
PROPATH=/chess300/bstraps
PRODATA=/chess300/userdata
export PRODATA PROPATH
cd /chess300/userdata
$CHESS_PRO QUE1 QUE
QUE1 is the que my function is in (the system would not let me create a 2.
QUE is my user with transparent login and admin rights.
One person all so told me to put off in EXIT AND ERROR LINKS, superlayer will not let me do this and proiv will let me but when I run it from within Chess to get the que the out file says it is an unknow or illegal entry, but it ran the function.
Sorry to bother you so much, but I think I am close.
I appreciate any help you can give me. I called Glovia and they said I would have to contact field service. Well they usually do not know and would want to charge for me to find out what they should tell me for the money I already pay.
Again thank you.
Thanks alot I did what you said and both yours and my fucntions perfromed perfect. My fucntion is an update and it updated the file as required.
Have one problem now. When I create a script file to run to do the same thing I only get:
Readque:
UPDATE IN PROGRESS - PLEASE WAIT
Well no matter how long I want it does not run.
My script file is as follows:
.ch320c.env (this is the standard chess env)
PROPATH=/chess300/bstraps
PRODATA=/chess300/userdata
export PRODATA PROPATH
cd /chess300/userdata
$CHESS_PRO QUE1 QUE
QUE1 is the que my function is in (the system would not let me create a 2.
QUE is my user with transparent login and admin rights.
One person all so told me to put off in EXIT AND ERROR LINKS, superlayer will not let me do this and proiv will let me but when I run it from within Chess to get the que the out file says it is an unknow or illegal entry, but it ran the function.
Sorry to bother you so much, but I think I am close.
I appreciate any help you can give me. I called Glovia and they said I would have to contact field service. Well they usually do not know and would want to charge for me to find out what they should tell me for the money I already pay.
Again thank you.
#29
Posted 30 March 2001 - 03:59 PM
You cannot add lines to batchque.pro manually. The WRITEQUE function does this when you run a function with a number/letter entered in $SPOOL under QUEUE NO. To run something from an operating system prompt you must use the transparent logon with the logon function linked to your function in $OPR. This will run your function. So you must then have 'OFF' in the exit link or use @LFUNCT='off' or the process will sit there waiting for input from the PROIV command line.
If you have want to run your function in the background (using $SPOOL entries), you can have a standard function as the link that uses the EXTERN command to get the function or read a system exported variable to branch to the function you want to run. Make sure your link function is linked to off as I explained above.
What is happening when you run your function from the operating system (with spool entries on) it adds your function to the QUE (and tries to run immediately if nothing else is currently in the queue), but since the return is passed to the calling function, which happens to be the transparent logon, it hangs and doesn't know where to go.
We actually run 'batch' processing using the AIX cron to kick off a job. We 'purchased' the code for READQUE (function that manages all background processing) and modified it to read a file to run multiple steps/functions.
But that's anther story.
Hope this has helped.
Don
If you have want to run your function in the background (using $SPOOL entries), you can have a standard function as the link that uses the EXTERN command to get the function or read a system exported variable to branch to the function you want to run. Make sure your link function is linked to off as I explained above.
What is happening when you run your function from the operating system (with spool entries on) it adds your function to the QUE (and tries to run immediately if nothing else is currently in the queue), but since the return is passed to the calling function, which happens to be the transparent logon, it hangs and doesn't know where to go.
We actually run 'batch' processing using the AIX cron to kick off a job. We 'purchased' the code for READQUE (function that manages all background processing) and modified it to read a file to run multiple steps/functions.
But that's anther story.
Hope this has helped.
Don
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users