BEC job queue number system

[stephenwales]

We run 4 different production instances of Ellipse here (5.2.1.6)

We're having a problem with BEC job numbering in 2 of the 4 with users with very similar usernames.

In one instance, whenever user WARNEM runs a job we see this:

This is from programs_12666.log

-----------------------------------------------------------------------------
Started bec_process.pl on rtsisd1 Args: -task RSR65D -user WARNEM -request
        RSR65D__200605300000002006053010462901 -sequence 12665
-----------------------------------------------------------------------------
Could not update RSR65D failed to update MSF080 to have a status of P for key:
        RSR65D 20060530 000000 20060530104629 01 WARNEM REJEC, sequence: 12665

REPORT1  RSR65D   RSR65B   WARN   20060530 105753 No Request for RSR65B
REPORT1  RSR65D   RSR65C   WARN   20060530 105753 No Request for RSR65C
REPORT1  RSR65D   RSR65D   WARN   20060530 105753 Could not update RSR65D
                                                  failed to update MSF080 to
                                                  have a status of S for
                                                  12666

REPORT1  RSR65D   RSR65D   WARN   20060530 105755 Could not update RSR65D
                                                  failed to update MSF080
                                                  tohave a status of F for
                                                    12666

REPORT1  RSR65D   RSR65D   ERROR  20060530 105755 Execution Failure
REPORT1  RSR65D   RSR65D   FATAL  20060530 105755 Task Aborted

Notice that the command line is invoking -sequence 12665 but the job number is 12666 according to the error messages and the file name.

In another instance, similar things are happening for userid WARNERJ, from file programs_89484.log:

-----------------------------------------------------------------------------
Started bec_process.pl on rtsisd1 Args: -task MSB8PA -user WARNERJ -request
        MSB8PA__200605310000002006053107270201 -sequence 89482
-----------------------------------------------------------------------------
Could not update MSB8PA failed to update MSF080 to have a status of P for key:
        MSB8PA 20060531 000000 20060531072702 01 WARNERJ REJEC, sequence:
        89482

UPDATE   MSB8PA   MSB8PA   WARN   20060531 072707 Could not update MSB8PA
                                                  failed to update MSF080 to
                                                  have a status of S for
                                                  MSB8PA 20060531 000000
                                                  20060531072702 01 WARNERJ
                                                  89484

Note this one is calling bec_process.pl with a sequence of 89482, where the error number and file name are 89484.

The only obvious similarity here are the usernames both starting with WARNE.

Anyone ever seen anything like that before?

Help appreciated.

Steve

 

[Drw]

The error ‘Could not update MSBXXX failed to update MSF080 to have a status of...’ is caused because there is no request record exists on msf080 for the program MSBXXX. This error commonly occurs when you have the switch ‘-Norequest’ following a task in the batch.tbl to allow the execution of a report/batch without a request.

As far the problem with the BEC_JOBNUM – It is worth checking how the requests are created... there are several ways:
A Mims Cobol batch (EXEC SUBMIT-BATCH); The Substitute request (SR) table code or a perl/unix script, etc. It is also possible that when doing this a new BEC_JOBNUM is assigned – could be a bug with BEC??? Possibly also with the way BEC handles the batch.tbl switch ‘–TaskTrigger’??

Hope this helps... Drew

 

[dbnetsi]

There was some problems in the way jobs where being created, I cant remember if it was a BEC problem or in the cobol and as such although they should have run under a single job to pick up job data from a previous job they didn't.

have a look at the logs from the failing jobs and see what it is looking for, you may need to watch for whether the job has already run as a seperate task.
Also it may be that something the user does removes the request entry while the job is running

Cheers

Technology Consultant, Australia
"So much of what we call management consists of making it difficult for
people to work" --- Peter Drucker