Re: Record Lock

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.