Re: Version of BPCS client for 6.1 -- BPCS-L

Genyphyr,

In a message dated 2/1/00 5:32:20 PM Eastern Standard Time, novakg@ssax.com 
writes:

<<snip>>
> Oh...if I had a dollar for every time someone said. . . "I didn't change
>  ANYTHING and it is just broke!" but it turned out in the end that they (or
>  someone else at the site)  _did_ change something (perhaps without 
realizing
>  it would have that affect) - I would be a rich girl now. . . :-)

ROFL!  OK, me too!

<<snip>>  

>  >Indeed.  I do not envy your position supporting multiple clients and OS
>  >versions across multiple platforms on both the client and server side. 
Given
>  >the "configurability" of BPCS, that job merely becomes more difficult.  I
>  >hate to think what your HP support is like, given the multiple database
>  >versions thrown "into the mix" there!  Again, I applaud your efforts and
>  >wonder whether or not supporting so many versions of BPCS against so many
>  >platforms is wise for a company struggling for profitability.  Perhaps at
>  >least 6.0.02, if not 6.0.04, should receive a "Sunset Announcement"?  
BPCS is
>  >not the simple application that it once was through version 3.x, and a
>  >"reality check" might be in order.  How many PC packages actively support 
as
>  >many levels as does SSA?
>  
>  Believe me, you are not the first with this thought. :-) I have heard
>  considerations in this regard are being discussed currently, but no final
>  decisions have been made.
>  
>  >Errrr.  I disagree here.  If you support it, you should have a "frozen" 
copy.
>  > Otherwise, you should go to the "CUM" strategy of IBM.  SSA did this at 
one
>  >point, and I believe that it was an arrogant "no more CUM's" statement (in
>  >the face of patch level F, March CUM) from former SSA management that
>  >eliminated it.
>  
>  I guess we will just have to agree to disagree on this point. The idea you
>  mention here seems contrary to your previous comments about sunsetting old
>  releases so that we don't have to support so many versions of the product.
>  It is unrealistic to keep frozen copies of each BMR fix done to any program
>  plus it's dependencies. SSA supports our code at current levels only - if 
we
>  do a fix, it is to today's level, not your level if you are 15 BMRs behind
>  on the same release. We support the release of BPCS, not individual BMR
>  cuts. Customers de facto stay current on BMRs if they order a new BMR for a
>  program (because it contains all changes made since the last cume the
>  customer has applied) or they choose to retrofit a fix into their level of
>  the code and keep the code as a modification to BPCS.

Perhaps disagreement, but my position is not contrary at all.  I _WANT_ to 
get rid of the old releases so that support will be more consistent for _ALL_ 
releases still supported.  On the other hand, if you're going to _SUPPORT_ 
old releases, then by darn you (well, SSA, not you personally) had better 
have a frozen copy of every single variation of that release that you still 
support.  Back when I sold software, we nearly went broke buying tapes so 
that we had isolated copies of release "3.1", "3.1a", "3.1b", "3.1c", "3.1 
electrical wholesaler", "3.1 business forms distributor", "3.1 business forms 
manufacturer", "3.2" etc. because we had clients _RUNNING_ these packages -- 
regardless if it was only a difference of a couple of screen changes and 
lines of code between them because they were paying maintenance and still 
supported.

No vendor can reasonably expect a client that has modified software to be on 
"the latest CUM".  What percentage of _LARGE_ BPCS customers have _ZERO_ 
modified code?  At one site, we finally went live with the November CUM of 
6.0.02 because we had already delayed implementation seven times and INV500 
BMR's were _STILL_ coming in at the rate of more than one per week through 
February!  We finally fixed what was important to _US_ and moved on because 
there wasn't _another_ million+ dollars in the budget.  Has anyone tried to 
retrofit BMR's to a heavily modified INV500, many of which modifications were 
put in place by poorly documenting programmers to repair what that BMR was 
supposed to correct?  No picnic, I'll tell you.

>  Cumulatives are still put out for BPCS, so I am not sure what you mean when
>  you say that is not done anymore or that this is a stated policy across the
>  board. As you see, cumes have come out of R&D recently. The more current
>  releases have had cumes done (similar to IBM, the newer the release, the
>  more likely a cume will be done - when was the last time you saw a cume for
>  V3R2 :-) ??). Version 6.0.04 had a July 1999 cumulative, and rumor has it
>  that one will be done for 6.1.00 this year.

That would be nice, especially as I was feverously patching "Y2K" BMR's onto 
both 6.0.02 and 6.1.00 at the end of last year :).  Still "March CUM" as the 
latest for 6.0.02, though.  Still "No CUM" for 6.1.00, although most major 
programs were impacted by the Y2K issue.  Cumulative releases _used_ to come 
out nearly once a quarter for BPCS.  Even a _CASUAL_ glimpse at OGS online 
based upon date will indicate that most people _NEED_ a new CUM.  Helpline 
will verify that when you call about a problem...

>  The release naming conventions have changed over the years, and we allow 
BMR
>  explosions back to any previous cume levels for some releases (that may
>  change) -- but that doesn't mean you are getting old BMRs. You still only
>  get today's code - it is merely the BMR tree pulled in that grows larger --
>  see the OGS document on BMR Change Management for a full description of how
>  this works. If you order a BMR1234, but 10 BMRs have been done since then 
on
>  that program - those BMRs are by default in the build that we give you 
(even
>  though it may be named BMR1234 - that ain't all it contains) because we 
pull
>  today's version of that program and its dependencies. You may think of it 
as
>  being BMR1234, but that is a false impression, as the 'explosion' build
>  library will contain EVERYTHING done since BMR1234 and the day the BMR is
>  built, along with code which depends upon those changes (co-dependent 
code).
<<snip>>

True, but those explosions also contain programs that _aren't_ required, and 
exclude those that _are_.  Program A calls program B calls program C.  You 
want a change to B, but get A and C in the bargain -- fine.  On the 
contrapositive, we wanted a Y2K change to program B, and received all 
programs that B touched -- fine.  Unfortunately, a prior BMR to program A 
changed the number of parameters with which program B was called by program A 
-- we _DID NOT_ receive a new copy of program A under the Y2K BMR.  March 
CUM, still supported, but the B Y2K BMR did not mention the change in 
parameter list from program A as a prerequisite -- definitely _NOT_ fine.  
Since this particular program was running _PURE_ March CUM without 
modification, we hadn't loaded any BMR's (as SSA suggests if you don't need 
them), a "frozen" copy of the pure March CUM would have pointed out this 
problem with the Y2K fix.  We ended up taking temporary (until 6.1 is 
installed) "ownership" of program A to add the tenth parameter to keep 
program B from falling over.  See what I mean?

>  >Again, I must disagree.  While I haven't quantified it, the OGS site 
"flows"
>  >much better from my 4.0 browser at work than it does from client sites 
with
>  >5.0.  I can get links at work that do not appear at client sites.  Why 
would
>  >the FTP site fail due to passwords, when you must include your user id and
>  >password as part of the link?
>  >
>  
>  There is an e-mail address at the bottom of many pages on the web site to
>  send OGS comments to, and it is monitored by the team that programs the
>  site. So please send them specific details and comments if you have a 
chance
>  and notice something wierd happening with IE5 and the site. At this point,
>  from speaking to people currently on Helplines in the US and Australia,
>  there are no complaints about IE5 breaking the OGS web site that we are
>  aware of, so this is the first I have heard of it. Please let the team that
>  manages the site know specifically what is wrong, so that they can fix it.
>  The OGS site is managed and programmed by a separate team within SSA.

Will do.

>  At any rate, why the FTP site fails due to passwords is the question of the
>  day, but it does, and that is the complaint we have heard time and again
>  from users. If you look in your browser at the address line containing the
>  password and user profile name, and enter the site at one directory, and
>  then you click on another directory, you will see that as your directory
>  path changes, the password drops off the browser's address line, then a
>  failure comes up for entering that directory, because the password is
>  missing.  This is why it works OK when the entire path is typed in but does
>  not work when you get to a directory and try to go into others from there.

Thanks!  Keep up the good work, and realize that I hope this to be 
"constructive" criticism.  My opinion is that SSA will, as Thoreau said, 
"simplify".  I think that SSA management has now realized that it cannot be 
all things to all people.  Reducing the supported versions of BPCS would 
hopefully have the added benefit of preventing the relegation of _NEEDED_ 
enhancements/fixes to "E" status.

Regards!

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

"The brain is a wonderful organ.  It starts the moment you get up, and 
doesn't stop until you get to the office." -- Robert Frost
+---
| 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
+---