Prepare for Jobnumer > 6 digits

While more complex than what I'm about to say, the original internal numbers were often stored in 2-byte values, some in 1-byte. Eventually those values grew from their limit of 99 or 9999 to 255 and 32766. But not all. The internal job number should probably be stored as an unsigned integer and left to it 2.1 billion limit. Sadly, for some silly reason, SQL doesn't seem to support unsigned integer values, so in those interfaces, a BIGINT would need to be returned or I suppose it could be mapped to Decimal instead. Anyway, point being, it is probably an easy enhancement internally in the internal structures, but not so simple when you push that out to the various interfaces. Probably should start designing how to do that so we don't have to wait for it once this sitaution becomes pervasive.

Thanks for your input. We will keep this on our radar as the system grows. Closing for now.

The base for this RFE was the following customer scenario:
- they run a background job monitoring for a need to create a PDF from a spool file
- if yes, a new job is submitted for creating the PDF into IFS and mail it
- all was done under one user and same job name
- they ran at 7.1 (i was not aware about that as they told me about 7.3) so they ran into getting big job tables
- (there was about 30.000 mails / PDFs a day)

I was working on this weekend to bring them to 7.3 and change the creation and mailing of the spools as PDF so at the moment that situation is deescalated. Also a high number of joblogs attached to the job were resulting in 400.000+ entries in the job table; hope this will decrease now.

So in my assumption we can put aside this RFE (but not forget for ever ;-) as the number of users with that specific issue really might be very low.

I first expected to see this request on large systems but most large users know how to have their system clean. You did a great work on 7.2 - the last loop test with producing jobs was on 7.1 (and then we saw multiple same jobname/number/user in WRKACTJOB. This is gone.

Thanks - i will close this for now.

The qualified job name (jobname/jobuser/jobnbr) is unique within a partition. When you start a job, the operating system will attempt to use the next sequential job number, however if that number has already been used with the same jobname and user, the operating system will skip that number and try the next one. If you submitted one million jobs with the same job name and user, then you will indeed hit this limit, but it's likely you will hit some other limit before you reach this one, such as the QMAXJOB limit that you mentioned, if not storage or a subsystem limit, etc. But is this really a valid requirement? We did a substantial amount of work to increase the QMAXJOB limit in 7.2 as well as address runaway job situations with a built in speed bump, early warning messages for QMAXJOB, storage limits, changes to how we handle MAXCPU and MAXTMPSTG, etc. We have also made extensive changes to allow decoupling of jobs from spooled output with SPLFACN(*DETACH). If users are getting close to the QMAXJOB limit, I would like to know that. But I do not agree that the job number needs to be extended beyond 6 digits, because I am not aware of a valid use case where >999,999 jobs with the same job name and user is required.

The COMMON Europe Advisory Council (CEAC) has reviewed this requirement and recommends that IBM view this as a MEDIUM priority requirement that should be addressed.

Background: The CEAC members have a broad range of experience in working with small and medium-sized IBM i customers. CEAC has a crucial role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community and has therefore reviewed your RFE.

To find out how CEAC help to shape the future of IBM i, see CEAC @ ibm.biz/BdYSYj and the article "The Five Hottest IBM i RFEs Of The Quarter" at ibm.biz/BdYSZT

Therese Eaton – CEAC Program Manager, IBM

i agree this is a keen proposal but somewhen 970000 jobs (including ended jobs with joblog) might be a limit.
Saw several situations where (for creating a print or whatever) a new job is submitted (always same user and jobname).
You might want to try a looping job submitting new jobs with same name and user.

I would agree with the commenter. Under what scenario are they not unique? One would have to be something quite unique for it to happen.

This is so deep down in the OS that I can hardly imagine it will ever be changed.