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



from Al Macintyre

We are BPCS 405 CD recently from BPCS/36, in which instead of EC*W 405 CD uses
members named after the user's display station, but the principle is the same.

1. ORD500 is really a bunch of programs that communicate with each other with
the aid of work files, whose data goes into ECH & ECL & etc. - ECS ESN &
others, when you accept the order, so if you do not have some kind of crash
situation in which you need to get into the content of those files to help
resolution, those work files should be habitually cleaned up, if they tend to
grow to infinity.  Similar type scenarios abound throughout all of BPCS &
there was a SYS999 to do exactly that on BPCS/36 but I have not yet located
the BPCS/400 equivalent.

2. There is other processing that accesses customer orders in such a manner
that it can be counter-productive for concurrent processing of one bunch of
people updating customer orders & other people shipping against those orders &
others billing what has been shipped so far.  We do our billing for all
facilities at close of day after all shipments for that day, and use IBM user
message queues to inform people who update customer orders what the status is
of this - many of whom ignore the info.

We habitually have people updating customer orders & their connection to the
AS/436 goes down, leaving the order they were working on in an intermediate
state.  This happens more often with the people who are updating a whole bunch
of orders, such as in shipping, than with people updating one order at a time.

This is easily fixed via the Reorg Menu, if they promptly report what they
were doing (which 500 job) from which display station (job-id), but usually
neglect to do so, complicating trouble-shooting when some other user needs
into that order & is locked out by some error message.

We taught some power users how to fix broken situations, which may have been a
mistake, because sometimes when user-A can't get into an order because user-B
is busy there, user-C "fixes" the flags so user-A can in fact get in, without
anyone checking to see if user-B is not a phantom of a failed connection.

Aside from the training issue of end users communicating clues that would help
us avoid getting in so many messes in the first place, I could use a report
based on the data that the Reorg uses when it is fixing things = list for me
all situations where BPCS work files say someone is in the middle of an update
of precisely what but WRKACTJOB F14 info says that display station is not even
signed on right now, even via a discontinued job.

Wish list for future improvements - have a field that says "Who was the last
user to update this record?" so that when another access has a lock-condition,
it could display the NAME of the person you are in conflict with.  Trying to
teach end users how to use the IBM display lock clues is a lost cause for us.

>  From:        gsagen@primesourcetech.com (George Sagen)
>  
>  Larry,
>  
>  They are work files for Sales Order Creation and Maintenance. Whenever you
>  create an order you are actually creating it ECHW & ECLW instead of ECH &
>  ECL. When you accept the order, the ECLW and ECHW records are copied to the
>  ECH and ECL and the ECHW/ECLW records are deleted.
>  
>  Sometimes you will get an in-use error message on a sales order during
order
>  picking yet when you check the HINUSE column in the ECH table it's not set
>  to 'Y'. In that case check for ECHW/ECLW records with the same order #. If
>  they exist and truly nobody is actually editing the order, then blow them
>  away using the SQL statement:
>  
>  DELETE FROM eclw
>     WHERE lord = <insert order #>;
>  DELETE FROM echw
>     WHERE hord = <insert order #>;
>  
>  The record locks error messages should go away.
>  
>  The presence of these tables is another persuasive reason to use ORD300 for
>  viewing sales orders rather than going into order entry. Since opening an
>  order in order entry creates the work table records, by just opening the
>  order in ORD700 or COM you are inviting the opportunity for a crashed PC or
>  network failure to leave the order in an unusable state.
>  
>  George Sagen
>  gsagen@primesourcetech.com
>  
>  |-----Original Message-----
>  |From:  Larry Fry
>  |
>  |Can anyone tell me what function ECHW and ECLW serve?  We are full C/S at
>  |6.0.02plf.  If they are work files should they be cleared when the
>  |daemons are started?

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