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


  • Subject: Re: Missing Inventory Transactions
  • From: "Robert Schmuhl" <BSchmuhl@xxxxxxxxxxxxxxxx>
  • Date: Wed, 29 Sep 1999 07:46:15 -0400

Sue:
    The User Transaction and the Inventory Transaction process thru
different queues, this means if the user transaction normally takes less
processing time,  that it will be processed before the inventory transaction
even if it was entered before it.

-----Original Message-----
From: Sue Underwood <sueu@alltel.net>
To: BPCS-L (E-mail) <BPCS-L@midrange.com>
Date: Tuesday, September 28, 1999 9:08 PM
Subject: Missing Inventory Transactions


>For those of you who may be experiencing a similar problem:
>
>Client is on BPCS version 6.02 (plf) AS/400 V4R2 and using DCServ.  We are
>using a user defined transaction to signal allocation of inventory from
>DCServ to BPCS.  When traffic is heavy between the server and the 400, we
>occasionally would have what appeared to be missing transactions filter
>through.
>
>For example, an adjustment transaction is sent through and its accompanying
>allocation transaction will follow within seconds (remember, user-defined).
> ORD720 grabs the YCI (without a lock), updates other inventory files for
>that allocation and then comes back and updates the YCI.  In the meantime,
>the adjustment transaction has processed, but the YCI's updated quantity
>fields are overlaid by ORD720.  This is proven out by using the transaction
>log on the DCServ engine.
>
>Now, I know that is a wordy explanation, but you have to understand how
>AS/Set works to see the problem.  The fields used to calculate on-hand are
>used in ORD720.  The file is read without a lock, calculations occur, and
>then the YCI is updated.  Internally, AS/Set reacquires the record and then
>compares the values in the fields from the original read with those from
>second.  If any of those are different (in this case adjustments), the
>fields from the original read are moved to record and the file is updated.
> Hence, wiping out the adjustment.
>
>This is a timing issue and we have spent a lot of time researching (and
>fixing) the errors being created.  I just wanted to save someone else the
>aggravation.  And yes, we will be reporting the issue to SSA.
>
>Sue
>
>+---
>| This is the BPCS Users Mailing List!
>| To submit a new message, send your mail to BPCS-L@midrange.com.
>| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
>| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner: dasmussen@aol.com
>+---
>

+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.