7 Digit Job Number Trancates Version Name in Job Details

We are running 8.11. Our job number rolled to 7 digits recently. Now, we can no longer search for some submitted jobs using the Job Details column. When the UBE name is 9 characters and the version name is 8 characters, the last character of the version name is dropped in the Job Details value. Any thoughts on a work around?

Our Job Number is 7 and I believe it has been since day one. I believe the total characters allowed for UBE & Version is 16 (not counting the job number). Anything over that will truncate. Had to instruct the developers what the naming convention was and keep enforcing it with new developers. For old reports where that has happened you will have to use a combination of values in the QBE line to find, e.g. user, date, report description w/ wildcards to find what you are looking at. Expect the unexpected, it is JDE...

Hi,

I don't know if it's working in your version like for Xe, but another option is to change the next number for job number.

In Xe, it's located in the table F986111, in data source SVM7333.

I never did it so far, but i'm thinking of it, because we get the same issue in our production environment.

Regards,

We limited the version name to two chars and two digits zzDD, where zz is used as site ID, and DD as version number.
PS Never needed more than 99 versions for one site

I see the number in F986111. So, this number is outside of Next Numbers defined in F0002? Correct?

Thanks.
I might need to push for a new naming convention. I've done my best on the UBE line. I often have a generic USER ID (from the scheduler) and our version names are bad in a lot of cases; ELGSO001, ELGSO002, ELGSO003, ELGSO004.

Thanks.
Your naming convention seems reasonable. It is just going to be a nightmare looking for PDF's generated from the long version names.

You can reset this number without issue as long as you are purging the job queue, it really doesn't like having the same job number in there twice, I haven't checked the index, but it probably violates it.

At one site the truncation of the version broke the way a third party scheduler worked and needed resetting about once every nine months.

In the end we stuck a DB level trigger on the table, so that if the number got to 999,000 (some way away) it reset to 0. The jobs increment the number by one and use the end result rather than using the table, so the first job to run will be 1. It is completely safe to do this on a running system, although you may get complaints from the end users if the WSJ is ordering on the job number.

I like this solution. Thanks for your help.