× 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: BPCS Upgrade Test Support Staff Challenges
  • From: MacWheel99@xxxxxxx
  • Date: Sat, 13 Feb 1999 12:26:40 EST

Posting from Al Macintyre

In Subject "ASSET Y2K Dating" there was discussion of V6 issues that were
somewhat at odds with my company's prior vision of several products so I
thought it useful to clarify some points

So, in "Subject: Clarify AS/Set?" I had asked about the merits of various
tools, since we have newly migrated to BPCS 405 CD from BPCS/36, and are
somewhat reliant on guidance from people who may have another agenda in
places, so additional opinions might be constructive, and I thank y"all for
the input

Wendy H DeCair talked about another point I would like to pursue - staffing
requirements for implementing BPCS upgrades - I am snipping out, from Wendy's
input, just what I want to comment further on

> We implemented BPCS 6.02 full c/s at 5 divisions in less than one year - 
> with three programmers and one of them was learning AS/SET.  
> We could not have done this with RPG .
> We also use Robot Scheduler, Console, Alert and Autotuner.  
> We do not have a night operator.  We have a very small MIS staff here at CFI
> The cost

(She is talking the cost of AS/Set & ROBOT)

> can be justified especially when you consider what consultants, and
> night operators, and having to rerun jobs due to data entry errors cost.

I am the only MIS staff at CIII's 4 divisions of green screen operations
actually in 3 physical locations, except for some power users who serve in a
help desk capacity, and troubleshooting PC hardware issues.  I do the
programming & I am the night operator & other stuff.  We have just some
fundamental tools that came from IBM & SSA, and some of them have operational
problems.  

We have one non-BPCS application still on Machine/36 but thankfully it does
not appear to have any Y2K implications.

I think of myself as akin to a locomotive engineer.  The AS/436 is a train
carrying the business into the future & it is my job to keep it on the tracks,
while making it go faster with more frills.  I have failed at my job if there
is serious downtime due to a derailment or other disruption, so whenever
things are running smoothly, I take credit.  I am also a computer janitor,
cleaning up whatever messes occur, for whatever reasons.

As a labor intensive globally competitive manufacturer we have a lot of
seasonal business, such as wiring harnesses for air conditioners.  Our biggest
customer is some telephone wiring that we wrested away from Singapore by
beating them on Quality.  Outside MIS & factory supervisors, there are about
20 end users who interface on-line with the AS/436, and many managers who
depend on its reports but have no other contact with the system.  Factory
supervisors do use inquiry but do not key in any data.

For Wendy & 3 programmers - what is the size of the end user community that
you service?  I understand that C/S support has a higher MIS overhead than
green screen support - by how much?

Errors leading to re-do costs are invariably found to be due to one of 3
reasons:
1. SSA problem needing another BMR - e.g. A/P discount terms date math went
south starting February 1999
2. End user turn-over with gaps in their training, leading to patterns of bad
transactional data entry
3. Baggage from our Y2K conversion e.g. we had to use some contract
programmers, some of whom unfortunately did not realize that when BPCS labels
a field as a NUMBER it often can be CHARACTER content, so we have decimal data
errors in several places & one I have not been able to fix is an intermittent
problem in shop order release where they are very heavily using SQL inside one
of the SFC52* RPG programs and I have not yet learned enough of SQL to fix
this code.

I do not see that As/Set & Robot would help with any of that.

So my new question relates to what actions are prudent when implementing SSA
upgrades PTF BMR etc. because we are on BPCS 405 CD PTF-1 & we need to go to
PTF-2 and this will be our first merger with modifications for BPCS/400.

We've done lots of BMRs/400.  Typically the first tape from SSA has problems
with the media, the internal labeling in sync with SSA standards, sending us
CISC when we asked for RISC, or some other problem resulting in asking for
another SSA try, but we get the code loaded, sometimes needing help from a
consultant dialing in via the ECS line, & I tell users they can test the fix
in our education environment by ADDLIBLE BMR whatever the number is, at the
command line.  Then when they tell me they are happy & confident the fix is A-
Ok, I move it to a conglomerate BMR library in the live environment library
list, with appropriate back-out insurance, and plan to clean up duplicate
copies months later after plenty time allotted for any problem reporting.

We learned on BPCS/36 that it was not smart to load PTFs without significant
testing, and provisions for backing out to our previous level - here are
examples of the kinds of problems we had:

I circulate to the users a copy of SSA's list of what had been upgraded & why,
to help them focus their quality assurance testing.  I also listed cases where
SSA had included upgrades that were not on their official list, and those
programs where I had had to merge lines of code - what we had modified vs.
what SSA modified.

A manufacturing executive tells me WE NEED THAT fix PDQ because we got
problems in production & inventory that it is addressing.  I ask about a test
data library & am told that there is no budget for any testing, we will just
have to take our chances & cope as best we can.  2 days later the same person
is telling GO BACK TO THE EARLIER VERSION PDQ (pretty damn quick) because we
have a horrible mess worse than we ever had, and it is because of that SSA
"fix."  Fortunately I had done my job in such a way as to be able to do so,
which does require some advance thinking about possibilities, that might never
happen.

One department tested ONLY what was on the LIST such as a bunch of 500
programs, then we went live on the release, and immediately a bunch of 600
programs, that call 500 programs, failed hard, because of bugs that the
testing failed to identify, because the department staff had not realized that
unmodified code calls modified code & it is all interdependent.

A combination of departments saying "We cannot live with all the bugs
introduced by this version" and "We positively absolutely have to have what is
in this version" meant that different application areas ended up out of
version sync, so we were frequently doing fixes on the fly for data crossing
version threshholds such as input to General Ledger.

Is this BPCS/36 "experience" typical of what to expect on BPCS/400?  I told my
staff & management that in my opinion the most cost effective way to implement
PTF-2 would be for me to work on merging it into the education environment,
then schedule Conference Room Pilots like we did for the Y2K conversion.  So
far, no concensus has been reached on this, and my marching orders have been
to continue adding to the collection of modifications.

Thanks in advance for your insight

Al Macintyre
Central Industries of Indiana
Newcomer to RPG/400 but we are often doing the same old job with new tools
+---
| 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.