Re: About BPCS V6.1.01 MM -- BPCS-L


----- Original Message -----
From: <DAsmussen@aol.com>
To: <BPCS-L@midrange.com>
Sent: Thursday, October 05, 2000 1:31 AM
Subject: Re: About BPCS V6.1.01 MM


> Genyphyr,
>
>The described work file problem occurred at a
> small client with two on their technical staff running 6.1.01 full client
> with the latest BMR's as of February.  My inherit trust precludes my
> publishing of either of their names, but I would be glad to forward them
to
> you directly if you can look up BMR's with more parameters than the rest
of
> us can.
You can forward me their names off-line if you want. I can only look them up
if they have placed Helpline calls. I use the same utilities that you do to
find BMRs - our AS/400 based-BMR tracking database is uploaded to a web
database for text searching. The actual BMR system of course contains fields
which we do not externalize, but these fields do not describe the BMR and I
can't search on them either; they are internal notes, such as programmer
comments and escalation notes. It is possible that by being here so long, I
just know how to search for our own stuff faster. I almost always use the
"Search entire database" field for example.

>With the use of DBMON and the creation of a few logicals, I reduced
> the access time for the full client customer on customer orders of greater
> than 80 line items from 37 minutes to 37 seconds.  The latter was mainly
due
> to the fact that ECHW and ECLW tanked up with a horrendous volume of
records.

That's great, but did you try to clear the files first? Keeping the record
size down is much better in the long run, as these files should NOT grow
large, and no customer should be thinking this is normal. Additionally,
since no programs maintain this file (your complaint to begin with) if the
problem of records being left in the file is not resolved, eventually you
will have order entry hard-halting when the member becomes full and the file
must be incremented. And at some point, the amount of records to be paged
into memory is going to cause degraded performance even with a logical
against it.

If you are running vanilla BPCS and can prove that when an order processes
normally, it leaves behind work records, this would be a BUG and should be
reported as such via a BMR. These are after all WORK files and are not going
to have records in them when things are working as they should. Did you have
modified code running at this point that could have caused a problem?

To take care of the records that end up there after abends, as I mentioned
before I am in process of finishing a document on various work files in BPCS
that can be maintained by the user. I will post this to OGS when it is
finished. A simple CL program run after backups doing a CLRPFM can take care
of this on an ongoing basis  to clear up the occaisional user PC lockup or
abend causing records to get left in work files.  Abended jobs DO leave work
records and this is the number 1 cause of those records being in the files,
from my experience with this problem. Usually no one notices this build-up
of records until the job hard-halts because the member is full or
performance gets very bad - sometimes it is a year or more after going live
on the product.

>  The bad thing was that SQL _usually_ only degrades in performance once
the
> 200K record limit is reached -- because most packages have at least one
> useable access path.  Bad SQL, bad logical files.
 I have no idea what you are speaking of with 200K record limits and the
like. Please explain further.

> >  I also wonder why your statement "Then again, all serious BPCS work
seems
> to
> >  have ceased since Gores took over. " is based on experience with 1 BMR
not
> >  getting completed?

>  I tried to search this morning from work
> and _STILL_ never turned up BMR 55090 using keywords that we associated
with
> it.

The text of the BMR is entered by the SSA Helpline consultant, who then
forwards the BMR number (and often the text) to the customer after it has
been entered. Not sure what you mean by keywords, as we use a freeform BMR
description field, taking 2 parts - a short and long description (another
reason to search on 'All fields').

I just signed on to OGS as if I were a client. In the "Search all fields"
field, I entered 2 words. 'CEA500*' a comma and then 'parameter*'. When I
then hit 'search' (don't fill in release, platform or that other garbage),
this is the very first record which comes up.

A couple other points. BMR55090 was entered in the BMR system in April of
2000, not February of 2000 as you mentioned. In addition, it was completed
on the AS/400 platform on September 6 2000 (not last Thursday), and then on
Unix on September 28th. So, if you were running DBMON then your client was
surely an AS/400 customer and could have had the fix a month ago. If the
customer had OGS support, they could have escalated it, in which case, they
would have recieved notice when it was completed via e-mail. I did not see
any record of the BMR being escalated.

> First, as already stated, perception is 9/10ths of the law.  You can fix
10
> _billion_ BMR's, but if I have two from two different clients that
_aren't_
> fixed and don't need any of the ones that you have corrected, I perceive
that
> you're not working on them at all.  My fault again, but I would think that
> BMR's involving program failure should be worked on in the order in which
> they are received.

I certainly hope you don't _MEAN_ this Dean! Imagine that if a program
failure of small consequence on some rarely-used inquiry application was
reported on Monday, and had a good workaround. Then another problem was
reported on Tuesday in an often used function which was updating records
incorrectly, and it had no workaround. From your logic you are saying that
you would expect that our company should fix the less important and lower
end-user impact BMR just because it was reported first? This is not a 'first
come first served' system, this is a software company that must take into
consideration hundreds of customer's needs at once, not like a small
consulting firm with just a few clients.

We must weigh which BMRs will be of benefit to the most customers and fix
the most serious software issues first. We do this based upon type of error,
whether or not there is an adequate workaround, pervasiveness of the problem
(widely or rarely used module, intermittent or constant failure ) and impact
on the users if the problem is hit (ie, hard halts and database corruption
are fixed before fixing the text of an error message that is misspelled)
along with customer interest in the fix which we hear about via BMR
escalations. It would be a disservice to our install base to do otherwise.

Thanks

Genyphyr Novak
SSA Global Technologies



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