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

Genyphyr,

In a message dated 10/4/00 5:00:37 PM Eastern Daylight Time, novakg@ssax.com 
writes:

> I have to take issue with Dean's postings of late such as:
>  
>  >>I don't mean to be ugly, but >>>
>  >> WHY DO YOUR PROGRAMS
>  > _LEAVE_ RECORDS IN THE WORK FILES IN THE FIRST PLACE???  Don't 
>  > give me that
>  > "the client crashed" excuse, either.  I haven't had enough clients crash
>  > within a week of clearing the files to generate 13K+ records.  etc.......
>  
>  Can we get some facts about these problems please?

Gladly.

>  First of all, what release and cumulative level of BPCS was this problem
>  about work files even in regards to? And what application are we speaking
>  about here? Was this 2 years ago - there was definitely a bug back then in
>  Order Entry COM which caused work files to fill as a program when into a
>  loop --- long since fixed. You posted back that you don't use this program
>  anymore. If you re-wrote the offending application, when when was this work
>  done - last week or last year or two years ago? How do you know what 
current
>  code in BPCS is doing to those work files if you aren't even running it
>  anymore?

I will admit that I was unclear here.  I have more than one client, and wrote 
based upon the subject rather than on the specific problem.  My current 
primary client re-wrote OE for their 6.1.01 mixed mode version because they 
never could get a copy of ODW.  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.  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. 
 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 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? Dennis Dompke from SSA GT asked for a BMR number so 
>  that he could research the problem. You mentioned this could not be 
determined
>  because OGS was down when you checked.
>  
>  In fact, OGS is not down today, nor yesterday. I verified with our web
>  master that the system has not been down for quite some time now (several
>  months) since we upgraded the search engine on the site (this was the cause
>  of previous downtime). The BMR search utility is up and working.  Maybe the
>  problem is with your user ID or firewall - have you checked with the
>  Helpline about why you are unable to access OGS?

May have been an AOL problem.  I'm not going to deny the fact that my own 
poor ISP could be part of the problem.  All I know is that, last night, I had 
gotten onto OGS earlier and then couldn't get _back_ on when I read Dennis' 
message.  The point is moot anyhow.  I tried to search this morning from work 
and _STILL_ never turned up BMR 55090 using keywords that we associated with 
it.  Fortunately, the person that originally reported it back in February got 
out of a meeting and was able to locate the ream of paper that he had filed 
on it, including the BMR number.  For those that didn't read my earlier post, 
it was resolved last Thursday.

>  You said the BMR which was escalated but not being worked on was about an
>  SSATCP job sending bad parameters to BIL. SSATCP jobs only run COM, CEA 
>  or OLM jobs. Some COM jobs update billing file records, but BIL programs 
are
>  run through the thin client  (NEWI) interface, so SSATCP would not pass 
them
>  any parameters directly. Pro-forma invoices in COM are generated via some
>  calls to SYS programs which then later call BIL programs in batch to do
>  printing. Can you mention what BIL program this was in regards to and a
>  basic outline of the problem? I can look up the BMR by its description for
>  you on OGS if you give more details about the problem.

Again, I admit my mistake as I did so earlier.  CEA500B was the problem.

>  If anyone doubts that serious coding work is occurring at SSA Global
>  Technologies and want to see what work __IS__ being done on BMRs, I suggest
>  checking out OGS Online.
>  
>  If you have paid for OGS support, you can see on the OGS site a listing of
>  Recently Passed BMRs which is updated on a daily basis, and shows all new
>  code fixes which have been passed for each release of BPCS in the prior 30
>  days to the inquiry date. This can be searched on by release and priority
>  code, so that customers can use this as a pro-active tool to obtain the
>  latest code fixes for products they use on their system and release level.
>  
>  Currently (as of today) it shows 33 pages of BMR objects which have been
>  completed on various releases of BPCS in the past 30 days. Additionally,
>  several people on this mailing list have mentioned hearing our 
announcements
>  to customers about a planned new release of the product. This doesn't seem
>  to bear out the accusation that serious work has stopped at SSA Global
>  Technologies since the takeover.

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 would suggest that Dean take more seriously the idea that he is the
>  (neutral) moderator of this mail listing, as recent posts seem to treat
>  facts rather like the US presidential debates have done!

Whoa ho ho ho ho!  This is, and _ALWAYS_ has been, a benevolent dictatorship 
hosted by _ME_.  I am neutral only in matters involving disputes between list 
members and violations of the list guidelines.  I have cheered SSA when they 
deserved it, and jeered them when they deserved that -- even when the jeering 
involved only my own perception.  As I stated to another SSA employee 
(offline) earlier today, I am proud that this list has finally evolved into 
what I originally intended _BUT_ it started out as a "Bitch List" during the 
dark "culpable deniability" era of Roger Covey where 5.x and 6.x users could 
exchange what little information they could with each other because SSA was 
certainly not forthcoming with it.

I'll admit that, sometimes, I intentionally take on a confrontational 
attitude over an otherwise "nit" just to see what shakes out. To date, the 
only people that have complained about my postings have "ssax.com" or a 
not-to-be-mentioned major BPCS provider tacked on to the end of their e-mail 
address.  At times, I've championed both of the latter and consider the fact 
the nobody else has "called" me on these issues to be an indication that I 
wasn't too far off the mark in my comments.  This is, after all, supposed to 
be a _discussion_, rather than a _party line_, group...

JMHO,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-mail:  DAsmussen@aol.com

"I don't know the key to success, but the key to failure is trying to please
everybody." -- Bill Cosby
+---
| 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
+---