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 
version
>  >in one breath, yet cannot support IE5 on OGS in the next -- the last 
time_I_
>  >checked, 5 _was_ the latest version of Internet Explorer and has been out
>  >longer than some of the latest client versions of BPCS.
>  
>  It is a standard question to ask when trying to resolve a problem, and you
>  would not believe the number of times it DOES apply to a problem (speaking
>  as an ex-Helpline employee), so I hardly think it is a bad or lazy question
>  to be asking a user. In fact it is the _FIRST_ question which should
>  _ALWAYS_ be asked, so that proper testing can occur or so that proper
>  searching of call archives can be done to research the error.

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.

>  In addition, we (SSA R&D) won't fix the program at your BMR level (if you
>  are not current), we fix the current BMR level (on that version of the
>  software). So logically, the first step is to test the reported problem at
>  current levels of software to see if it fails. If it works OK, and you test
>  on one cume back and it is broken as described, then it is natural to
>  imagine that a BMR in between must fix it. So, you may be requested to get
>  current on BMRs for the suspected program which is erroring. To me this is
>  just plain logic. If the problem can not be duplicated in current code, 
then
>  getting the customer to current code is a valid first step and resolves 
most
>  calls more quickly. If that doesn't fix it, then more research is required.
>  Sometimes the lack of duplication of complex issues in ERP software can 
have
>  to do with very exacting set up that can vary at hundreds of levels - and
>  yes, people (both clients and Helpliners) may not think of every possible
>  thing that might affect the program at first blush, and that is the cause 
of
>  failure to duplicate the issue - customer doesn't mention everything they
>  should or Helpline doesn't ask every question they could. I don't think it
>  is by any concerted effort of the giant software conglomerates that this
>  happens - it happens because every time you add a new function to a product
>  or make it more configurable - you are adding layers of complexity, and it
>  is harder to keep all that in your limited brain RAM at any one moment.

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?

>  In addition, if you are reporting a error such as an RPG or CPF message and
>  it shows at a particular line of code, we can't match that to any code on
>  our system to see which line is failing unless you are at the same code
>  level (we can not possibly keep a copy of code for every BMR ever done on
>  every program in BPCS). So version and levels of code may be key to
>  resolving your issue if an error message is involved, whether at IBM or 
SSA.

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.

>  As to the supposed problems cause by the combination of OGS and IE5...more
>  to rant on there. . . .
>  
>  First of all, OGS (a web site) works just fine and dandy when viewed with
>  IE5. However the FTP site (which is a link off the OGS site) where BMR 
fixes
>  can be retrieved from, and which is a Unix server, is where the problem
>  starts. Netscape 4.7 will also cause it.
>  
>  The problem occurs because your password is not carried over by the Web
>  Browser when you change directories at each click onto a new directory
>  level. If you type the entire path in your browser to begin with, you will
>  get there OK. Use this as a workaround (rather than clicking on each
>  directory from the beginning). I am told that there is NOTHING we (SSA) can
>  do about this, as it has nothing to do with our software on the site or our
>  firewall (this has been tested).
>  
>  They believe it may have to do with the 'security enhancements' made on
>  those new browser versions - but it is the browser which is dropping your
>  login name and password. I was told by the people who manage the FTP and
>  other internal systems, that they have seen this happen if you go to OTHER
>  Unix FTP servers, not just the one at SSA. If you get one of those free FTP
>  clients available on the internet and you will have no problems at all 
using
>  the FTP site. If anyone thinks they know a way for SSA to fix this, let me
>  know off line by directly replying to my e-mail address. We are open to
>  suggestions, but at the moment from our research, we do not believe the
>  problem is in any software that we are using on our FTP site server.

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?

Regards,

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

"Winners never quit, and quitters never win." -- Vince Lombardi
+---
| 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
+---