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

Hi Dean,

See comments below. ..

-----Original Message-----
From: DAsmussen@aol.com <DAsmussen@aol.com>
To: BPCS-L@midrange.com <BPCS-L@midrange.com>
Date: Tuesday, February 01, 2000 12:48 AM
Subject: Re: Version of BPCS client for 6.1


>Genyphyr,
>
>In a message dated 1/27/00 6:45:14 PM Eastern Standard Time,
novakg@ssax.com
>writes:
>
><<snip>>
>>  I guess I also have to take some exception to Dean's posting which
>basically
>>  yells at software companies' support structures for asking about what
>>  version of our software you have, despite the fact that he mentioned
that I
>>  am doing a good job :-) .
>>
>>  >Probably a combination of low unemployment versus an increased call
level
>for
>>  >both, but that response should _NOT_ be what they try to pawn off on us
>for
>>  >every single question we ask.
>>  >The question from SSA is particularly onerous
>>  >regarding client questions, as they ask you if you're on the latest
.......

>OUCH ;-)!  I agree for the most part, but you left out the part of my
>original post that I felt was most pertinent -- the stuff's been working
fine
>without change on both the client and server, but _NOW_ it has failed and
>release currency on both is called into question.  For the most part, my
>clients stay current on both BPCS and OS/400, since I specialize in new
>installations.  But those same clients are often upgrading from a prior
>version of BPCS that sometimes ceases to function for no apparent reason.


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. . . :-)

It does happen, but not often, that no change is made and something breaks
that previously was working OK. I can count on 1 hand the times I worked on
problems where really nothing did change, and there was a new bug that had
to do with timing or a bug that only showed up if you didn't IPL the system
for 10 weeks. . . and some variable finally overflowed. Mostly we find that
the mystery of 'it suddenly doesn't work and nothing changed' has to do with
someone else re-configured the network, changing the DHCP, changing the DNS
(but not everywhere they should), enabling or disabling *ANYNET on the NETA
of the AS/400,  accidentally removing the *LOOPBACK address on the AS/400,
changed they way or user who submits a daemon or other varied things that
they 'didn't think would affect BPCS like that'. From an application
perspective, 9 times out of 10 you find the 'nothing changed' has to do with
bad data that mysteriously was DBU'd into the files by someone 'fixing'
something they didn't want to admit to making a mistake on; and not updating
all the files they should. Only occasionally do we find a bizarre job stream
timing issue or something of that nature that is happening intermittently
when they say 'nothing changed'. Generally, you just start out down the
process of elimination, and eventually find out what really did change. .
.and if you are lucky, you find the guy that did it so you can tell them
'don't do that again!'. :-)

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

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.

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).
This is why BMR libraries should be applied as delivered (and not picked
apart) unless you have modifications to any of the delivered code. It is
also why, on releases such as 6.0.02 a BMR explosion can practically become
a cume due to the dependency tree that grows. . . and grows. . . another
good reason to upgrade to a more current version of BPCS - smaller BMR
explosions. And a good reason to incorporate 'passed' BMRs into your BPCSPTF
library or similar library - don't leave them on your system as separate fix
libraries.

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

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

Genyphyr Novak
SSA


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