× 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: RE: BPCS support alternatives
  • From: "Stauch, Richard A" <richard.stauch@xxxxxxx>
  • Date: Mon, 18 Sep 2000 13:15:48 -0700

If I may interject, without any bias since I do not now, nor have I ever
used BPCS (I work with a number of AS/400s in different configurations and
industries, and in PC integration issues, mostly with respect to operations
and for documentation):
Genyphyr is on the right track when she talks about it "strange to debug the
generated RPG at first." Nevertheless, it seems she has glossed over the
real issue. This question whether SSA will drop AS/SET or not (a subject of
no concern to me) revealed, I think, a problem that is pervasive in the
industry, and other industries as well. It is not AS/SET's fault that people
who do not use it very much have a difficult time learning how to deal with
its product, but people often mistake their difficulty learning for a
problem of the tool's.

In Psych 101 they called it "transference." I am not calling anyone "nuts."
People (normal people) often transfer responsibility from themselves to
something else, usually an inanimate object, and AS/SET seems to be the
object of choice in this thread.

The fact is, a tool's product is only as good as the people who use it. In
wood shop, if I had used a chisel to cut wood instead of a saw, the product
would not be as good as it might have been. I've saved myself some sweat,
but at the cost of producing a poorer product. I still need a chisel, I
merely need to use it in the way it is intended. My experience tells me that
a CASE tool is good only to a certain point in the development cycle. After
that developers have to tweak the generated code (more or less) to optimize
it and to remove certain problems that will result in bugs in the compiled
code. Developers often, though, lean too hard on the tool, depending on it
for cleaner code than it is capable of generating (usually because of
deadlines).

Down here on the ground, we end up trying to second guess the developers, or
(being undermanned) spend far too much time putting out fires. Most of the
problems discussed in this List are a direct result of that dynamic. The
best answer is for those who must support (in the instant case) a BPCS
implementation, by maintenance programming or by interfacing it with other
applications, should learn AS/SET, or whatever tool was used to generate the
code, as well as the code (in this case, RPG and C). Grousing about the
tool, on the other hand, may let off steam, but it doesn't help the end user
to be more productive. That is, after all, our bottom line, isn't it?

Richard Allan Stauch
System Engineer, EDS
richard.stauch@eds.com (E-mail)

-----Original Message-----
From: Genyphyr Novak [mailto:novakg@ssax.com]
Sent: Monday, September 18, 2000 8:52 AM
To: BPCS-L@midrange.com
Subject: Re: BPCS support alternatives - we are NOT 'getting rid' of
AS/SET for next release

Hello,

I can safely say that SSA R&D, has absolutely no plans to get rid of AS/SET
in version 8.0 BPCS. In the users group, when the person spoke about
'getting rid of AS/SET' they first of all did not say  'we are going to get
rid of AS/SET in the next release'. Whomever reported that to this list was
either mis-understanding or mis-representing what the speaker said. What
they spoke of was in regards to distant future releases, and the point was
that there is a possibility in future that some other tool would replace
AS/SET. So, this was a statement about potential future
direction/investigations which at this point have not been completed. There
simply is not enough time to start using some other tool and still get the
next release out in time, so everyone can stop worrying ( or in some cases
celebrating ) about this.

BTW, actually, BPCS IS written in AS/SET (not RPG as someone mentioned). The
people who do the coding write it in AS/SET, which is a CASE tool. The
generator generates either RPG (for AS/400) or C (for Unix), which is why
you won't see us going back to native RPG - we do support more than 1
platform and this allows a common repository (the AS/SET code) to generate
code wherever we need it. BPCS runs in RPG and C on the AS/400 (the runtime
and some modules such as ECM are written in C) and runs in C on Unix. If you
are used to debugging native RPG only, and not AS/SET, likely it will seem
strange to debug the generated RPG at first, but you get used to it after
awhile.

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

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.