Re: Invoice Billing Process

----- Original Message -----
From: <RickCarter@holley.com>
To: <bpcs-l@midrange.com>
Sent: Wednesday, May 01, 2002 9:21 AM
Subject: Re: Invoice Billing Process


>
> All of this sounds facinating if you've got time to anlayze every job in
> the BPCS system or if you want to hire BPCS consultants on a full time
> basis.
<snip> ........................
> Whatever happened to the days when a job ran the most efficient
> it could without worrying about all of the outside factors.  I guess those
> where the days when AS400 jobs were written in RPG or Cobol and not ASSET.
.............................<snip>
> I do remember
> when this process ran in about 20-30 minutes but frankly I can't remember
> the number of invoices that were being generated then.   My point to this
> email, is none, other than I get tired of seeing all the '  if this or
> maybe that, or this could be.... or whatever.  No one really knows how to
> make this system perform all the time, its a constant effort to keep the
> wheels on especially if you like to stay current with IBM updates, etc.


Hello,

I will assume you mean the underlying programs, rather than jobs, as regards
the programming language. AS/SET is not a programming language. It is a
development tool, rather than a programming language. BPCS application
programs on the AS/400 are mostly generated into the RPG or ILE RPG language
from the AS/SET tool. AS/SET has absolutely nothing to do with the method of
database access for BPCS, as it is fully capable of creating native RPG file
reads and updates in RPG. However, most file I/O statements in BPCS programs
on the AS/400 were replaced from the native RPG file I/O to embedded SQL
statements at V6.x.

As I mentioned, if you have OGS support you are more than welcome to call in
any specific program performance issues to the SSA GT Support Center and let
them investigate. This would be considered a valid support issue if the time
per-invoice has increased. You can also address performance changes which
you feel are due to changes in operating system levels or PTFs, to the IBM
Support Line. If you want overall system tuning, then call a consultant to
come out and do that. Then you wouldn't have to take the time out of your
schedule to read all the suggestions in response to your posting, the lack
of which you at first complained about.

The description of the problem you face is somewhat undefined, and you
mentioned that you are not even certain if you have a performance problem,
as you do not know how many invoices were processed in previous billing
runs, when your total time was on average faster. I trust that somewhere you
have stored history files where perhaps you could research this so that you
know if you even have a problem to fix, or are simply doing better business
and are processing more invoices? I often find that the desire for a 'magic
bullet' answer to a very general question is an unreasonable expectation,
and that could be why you have so many varied suggestions coming your way
which are, apparently, frustrating to you.

As regards the request for a 'base group of logicals' -- these exist
already. They are delivered with BPCS at the time our product is released.
If we are missing some commonly required logicals, we endeavor to identify
and deliver those via performance enhancement BMRs.

If the operating system changes after BPCS is released, and this causes a
change in one or more of our programs' performance, we can either fix things
via a BMR, or if we find that a bug was introduced into SQL at the new OS
release, we can work with IBM to obtain a PTF to fix it. In this case, we
ask IBM to post the PTF to the Info APAR for BPCS on the IBM web site so
that all our customers can find and download it easily. However, if no one
reports the performance (or other) problem into either the SSA GT or IBM
Support Center for investigation, then the chances of getting a fix via BMR
or a fix via PTF will become pretty slim.

I find that many people do know how to do performance tuning quite well on
the AS/400s both with and without SQL. If you lack such knowledge at your
site, there are performance tuning classes (SQL and system level) that IBM
and others offer if you do not want to have to hire someone from the outside
to assist you with this. Additionally, some intelligent suggestions were
made in response to your question that contained things to look for outside
of SQL or system tuning. I take it you also do not have the time to look
into these 'fascinating' suggestions?

Any complex software package which updates/maintains huge number of files is
going to appear at times to be a constant "battle of maintenance", as you
put it, because the system contents change daily, if not every second, and
therefore the way programs respond are going to change --- duplicate records
could cause loops or hard-halts, larger files cause performance delays,
garbage data (sometimes manually entered) in files causes bad output and in
the midst of the millions and millions of  lines of code which execute on
that system each day, there are going to be bugs here and there which no one
had designed a test to uncover and thus the problem went unnoticed until
customer X happened to have the right combination of data or sequence of
events to break that part of the code etc. etc. etc.. This is why there are,
and will be for some time to come,  jobs for programmers, analysts and
system, database and ERP administrators.

However, don't forget that even old-fashioned paper filing systems were a
"constant battle of maintenance" and required many secretaries and a team of
office administrators to run; they were only about maintaining  physically
different things - paper files would get mis-filed, filing criteria changed,
forms changed over time, file cabinets become too full, copies would go
missing, typos caused misunderstandings, math mistakes caused errors, bad
handwriting or faded ink that no one could read became an issue, archives
were lost, burnt or ruined in floods, mail delivery problems meant lost
documents or delays in contracts etc. etc. etc.. Businesses planned for this
or tried to, by making copies, inventing redundant cross-filing systems,
storing in firesafe buildings and employing people with the skills required
to get the job done in the most efficient manner. The same is true in the
modern software world - an investment must be made in your operational
systems and in the people who look after them, in order to get the most out
of what you use to help your business run.

I don't think there was any particular 'golden age' to day-dream about, and
current software systems are much much faster and more accurate than older
ones. And the amount of functionality available in today's manufacturing and
financial software is quite astounding, really, especially considering the
time scale on which this has all been developed. Software and hardware has
constantly evolved and changed (and changed very quickly) to try to meet
needs/demands from the current market place. And system administrators and
all computer professionals (including software vendors)  therefore need to
constantly stay educated to keep up with the newest technologies -- which,
in fact, they themselves have had a part in demanding or creating.

Thanks,

Genyphyr Novak
SSA GT