Re: WRKJOBSCDE Woes -- MIDRANGE-L

× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.

On Thu, 27 Sep 2018, Rob Berendt wrote:

There's some major misunderstanding here.
CHGJOBSCDE does NOT use the job number from the last submission of the job
as ENTRYNBR. ENTRYNBR is to be considered as a primary key, perhaps an
automatically generated Identity Column assigned at ADDJOBSCDE time. It
will have a value before the first time it submits the job. JOB is just
an index. If there is only one ENTRYNBR for one JOB then CHGJOBSCDE
allows you to omit it. If there are multiple ENTRYNBR values for one JOB
then you have to add the ENTRYNBR. If you want to be able to use
CHGJOBSCDE JOB(ARGH) ENTRYNBR(*ALL) then you will have to submit an RFE on
that.

Rob, thank you. Now things are making more sense. I had visualized that the entries that were shown when running the WRKJOBSCDE were "sort of" instances of records held in some table somewhere in the bowls of DB2. Your explanation is much appreciated.

--Buzz

________________________________

This electronic mail transmission may contain confidential or privileged information. If you believe that you have received this message in error, please notify the sender by reply transmission and delete the message without copying or disclosing it.

This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.