our invoice number is sequential (i.e. new invoice number = previous invoice number + 1). A simple subprogramm (running for many years) does the job as an invoice number generator.
get counter-view #ISN
add 1 to counter-view.counter
update
The calling program has to do the end/backout transaction. And that’s the problem. Not every calling program ends the transaction immediately. Sometimes that leads to deadlocks, NAT3009 etc. To do the end transaction inside the subprogram won’t work because it influences the transaction logic of the calling program.
So the question is: How to solve the problem?
Adabas/Natural is not able to handle nested ETs or something like that.
One idea is to call the invoice number geneator as a RPC-Program (btw: is it possible to call a local Subprogram via RPC?). It has a different Adabas-Session and so we could to an ET inside the subprogram without influencing the calling program. Any other ideas?
Hi Matthias,
According to the doc, “…The Natural RPC facility enables a client Natural program to issue a CALLNAT statement to invoke a subprogram in a server Natural. The Natural client and server sessions may run on the same or on a different computer”, your idea seems to be very “productive” to me. Of course, there`s another “simple and stupid” solution: to force any calling program to issue ET (end transaction) just after after calling that generator to make sure that it (the calling program) got its own unique INVOICE NUMBER.
Like many shops we are also using the same logic (with the same drawbacks :-(; I`d be very interested in knowing about your progress in solving such a problem.
Ok, I don’t see the problem then, allocate the next invoice number independently of
the actual invoice, i.e. the subprogram does the GET - UPDATE - ET, no nested transactions.
The code I suggested for using the ISN as the invoice number is easily modified since it is a two step process:
Instead of:
STORE an invoice record
MOVE *ISN to ISN-COUNTER (field in the record)
UPDATE the invoice record.
you simply:
STORE an invoice record
MOVE *ISN to ISN-COUNTER (field in the record)
IF prefix required
compress #prefix isn-counter into isn-counter leaving no space
end-if
UPDATE the invoice record.
When the user invokes the invoice generation transaction the first thing done
is get the invoice number generated, before any transaction has been started.
If this is possible depends on the context, of course, when a transaction has
already been started when the invoice generation program is invoked then
that won’t work, of course.
Just some news:
We’ve implemented an RPC-Solution for the counter-problem. It’s just a simple subprogram in a special libary. Only the rpc-server knows this libary as a steplib.