× 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.



Jerry, I don;t think there are other sources, altho I am checking on that.
Keep in mind, this program and design are literally over 20 years old.

I am putting in the change that the check # will update immediatly and not
potentially sit there on the screen un-updated.

Thanks,
Steve
It occurred to me that manually entering checks is not a normal
process.  Whether A/P or P/R checks, these check numbers are usually
generated automatically by an application (check-writer) program.


So that made me think that, perhaps, there are other sources
(check-writer?) for check numbers.  If so, do these other source(s) use
the same control mechanism that you have tried to describe here?  As
nearly everyone has pointed out, as long as the program does a CHAIN to
the updateable control table (and not a CHAIN(n)), the record is
locked.  Period.


As has, also, been pointed out, the key structure of the control table
that has been described does not match the business rules (no duplicate
check numbers within a company).  But I suspect that what is attempting
to be described (though it isn't perfectly clear) is that there are two
tables.  The Company+Batch+Check# is, probably, a transaction file (why
else the 'Batch'?).  The check number control table is (or should be) a
separate entity.


And the solution about back tracking the check number control, if the
user cancels out, is hokey.  If you could guarantee that one and only
one user / source would ever be updating the control table, it might be
possible.  But you cannot and check numbers will, inevitably, be lost,
voided, whatever.  A review of the application and its various
functions, tables, etc., is certainly merited.  At the very least it
might help you understand the application.  Then it might provide a
better perspective of the "problem" which could be conveyed here.



      * Jerry C. Adams
*IBM System i Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
      615.995.7024
fax
      615.995.1201
email
      jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>



steema@xxxxxxxxxxxxx wrote:

There is only one file. A screen present a number and date-entry. First
it
chains to the file, gets the number, adds 1, puts this on the screen.
Then
it waits for a date. there must be a date entered. Then cmd-1, updates
the
file, exits.

Hi Steve,


There is one program that generates the check number. It is a simple
RPG
that chains the file by company only, adds 1 to the existing number and
places this on the screen for the user.


Are there two files (a control file holding the last check number, and
the detail file containing the details including the newly-created check
number) or are you getting the last check number from the detail file
itself?  The point being that if it is a timing issue and the program is
failing between the moment the detail file gets its record and the
control file gets it's, then you have a duplicate situation.

Can you lay out a brief outline of the timing of the events along the
lines of:

1 co   chain control
2      add   1       check
3      update control
4      exfmt
... time passes
5 key  chain  details
6      write  details



I was told that for checks, they don't


indicate the division ever, only


company.


If the database keys are co, div, batch, check then that information is
not correct.  It may be what is _desired_ but the database does not
enforce that rule.



I still want to know what happens to


the file lock, when a term. freezes.

What does it mean when you say 'term. freezes?'
  --buck
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.








--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.