This content has been marked as final. Show 4 replies
I'm not sure you can do what you describe in the manner that you appear to be wanting to do it. I know of no APIs that are provided. There are ways to get the job done, though.<br /><br />The job management data base is an ascii text file that can easily be changed programatically. Parts of our application use it for building a drop-down list of printers for the user to select from. Changing it doesn't automatically cause Central to use the new file. Central must be told to reload it before it will be using the modified file. This can be done by placing a certain "command" file in Central's control folder, but it would not run until after the current job completes - if the current job is the one that just changed the file and further steps of the same job are for the processing of the data, then that would be too late. Once a job starts, all the parameters and tasks from the job management database and on the original ^job statement is what will be used. This goes for changing anything about the job, whether it be adding/deleting steps, changing the printer, or any other parameters.<br /><br />We accomplish pretty much what you want by doing several things. <br /><br />*First, we define all of the various configurations of jobs that we need. For example, our main printing job has four tasks; it is not uncommon to need to restart a job someplace besides the first task. Therefore, we have four different jobs defined, each one starting further down the list of tasks. We do the same thing when the processing of the data has to vary in some manner - we have jobs pre-defined for each specific set of tasks and the source of the data sets the ^job name as required for the specific tasks that have to be done.<br /><br />*For modifying the printer, we use the -z<printer> and -asp<driver> parameters on the ^job statement and the source of the file sets the values as necessary. The source of the file will also set the job name so that the desired job is ran. <br /><br />*We also have built into our custom agents the capability to recognize when a "soft" failure is occurring (such as can't reach our database) and it will put the job back in for processing after changing the job name to run the correct job for restarting at the proper step. <br /><br />*One of our steps is to check a control file to see if there is a redirection for the specified printer to a substitute printer (say, the original printer is down for maintenance). This agent will put the job back in for processing, changing not only the job name but the printer parameters. It has to be put back in, instead of just changing the parameters and passing the file on to JFMERGE, because Central uses the parameters on the original ^job line, it doesn't use the parameters that might be on the ^job line when JFMERGE starts.<br /><br />*We have also created our own agent for running as the JFERROR task. This task runs when one of the agents supplied with Central encounter a failure. Our agent analyzes the failure and determines if it was "hard" or "soft". If it was a "soft" failure, this agent requeues the job, changing the name and parameters as necessary.<br /><br />So far we have been unable to determine how to get our VB6 agents to set the ErrorLevel to notify Central that the agent failed (we came up with a workaround instead of spending a lot of time trying to get the ErrorLevel to work). This is necessary to prevent Central's agents from processing when a predicessor custom agent fails. Since we couldn't set the ErrorLevel, we just set up all of our agents to always create an output file for input to the next task. When one of our agents fail, it only outputs a modified ^job line with no following data. This modified ^job line is recognized by our custom agents as an indication that a failure is in process so it skips any processing except to pass the file to the next task. Since there is no data or form commands in the file, once it gets to JFMERGE, it just terminates without producing any output or error condition.<br /><br />Previewing is accomplished by running the JFPVMRG agent to create a PDF and then JFPVSEND to send it to the originating IP# for receipt by the View Manager which will then load it into Adobe Reader. At this point, the job running on Central will be finished - it could have produced hard-copy output or not depending on its design. Once the user receives the PDF, they can do whatever they want with it (save, print, etc).<br /><br />We use the above capability for our users to view an "archive" image of forms, after it has been processed normally. I know of others that use it to create the PDF as part of the normal processing, allowing the user to then print from Adobe Reader it if they wish.<br /><br />What we do is to drop a DAT file into Central's input folder that runs the above two agents. Our application that is running on the user's PC then watches for Adobe Reader to load and when it does it forces it to be the top-most task (we do this because we have a problem that it will often open behind other windows).
Thanks a lot for your reply. It does answer a lot of questions. As yourself, what we are trying to do is to control the behavior of Central process from outside of the controls provided by Central Control.
If you have any documentation on the various types command files that can be placed in the control directory to alter the behavior of control, kindly pass them across. Small example could be reloading of the Job Management Database after the changes have been done.
Appreciate your efforts!
Using Central Control to do such things as reloadig the Job Management Database results in a file being placed in the "control" folder. Essentially, when the Central service is between processing jobs, it checks this folder. IIRC, if this folder contains any *.msg or *.dat files it will process them and then it returns to processing files in the "data" folder (assuming the control file didn't cause the service to stop).
The following text is the content of the various files that Central Control places in the control folder as a result of using the commands on the "Control" menu. Each of these commands, except for the Start & Shut Down commands, results in a file (we haven't yet figured out how to fully stop & then start Central after it has been stopped). We use these files to pause, reload the JMD & resume when distributing updates to our servers. The documentation indicates otherwise, but in testing we've discovered that the file names must be JFCTRL##.MSG; the two digit numeric part doesn't seem to matter, but the JFCTRL part does. The date & time within the file don't seem to matter (I use the file as captured without updating the date & time). I don't know if the job name or any of the other parameters matter, the important part is the value of the "command" field.
File "JFCTRL00.MSG" to control the Central service:
Replace the line of Xs with the following, depending on what you want to occur:
Job Table Reload
(this requires the printer & formfile parameters)
You can capture your own files by issuing the command from Central Control and then going to the backup folder and copying the JFCTRL00.MSG file. (Assuming you have Central configured to save backup files.)
Keep in mind that a job that runs a program that places this file in the control folder will finish processing all tasks before Central processes the control file. Once the job finishes, then Central will process the control file and any changes, such as to the JMD, will be effective for future jobs.
Thanks mate!! You are a life saver.
Really appreciate your time and support!