Performance & CST900 -- BPCS-L

from Al Macintyre, mixed mode BPCS 405 CD

Do I have a question?

Well does the CST270 that runs inside of CST900 do anything other than 
wasting our time?  Is there any harm in commenting out whatever code calls 
it?  I am a bit too annoyed to rationally formulate any other questions.

I used to have to spend a significant portion of my total time futzing with 
performance tuning, and have enjoyed a vacation from that since we left the 
S/36 5360 & I had not been looking forward to having to resume delving into 
that topic.

This month we moved from AS/436 to AS/400 model 170 which was billed as 1300 
percent faster.  We plan to dramatically improve our PC & internet 
connections, but have not done that yet.  I am basically disappointed in the 
perfomance I have witnessed with the latest switch in hardware platfoms, 
compared to the story about how much better 170 is over 436 doing the same 
kinds of work ... I had specifically asked about interactive & batch & M36 & 
etc. & been assured that I would expect fantastically better performance 
across the board.

Other than the hardware switch, the only thing I am aware of that is 
different, is that we changed our SSA user license to more people, and we are 
now operating off of a temporary key even though we paid the bill a month 
ago.  The key says yes to all modules, while SYS800 only has about 1/2 of 
them turned on - I hope that discrepancies between key & SYS800 do not cause 
any problems.  We had the extra users on the 436, before switch to 170 so the 
disappointing performance is not a case of higher system load.  Also there 
are SSA BMRs going on pretty fast due to Y2K.

We did a SAVE ALL on the 436, to multi-volume tapes, then RESTORE ALL on the 
170, then latest IBM PTFs to our V4R3, and got some other additions to OS/400 
related to PC support applications not yet started up.  Basically, in 
addition to our current dumb terminal emulation we will be having a 
multi-facility LAN, and internet access across a firewall on a separate 
non-BPCS box because BPCS 405 CD is native security level 30.  We will 
continue to operate mixed mode, and a collegue is setting up PC connections, 
whose implications I do not understand as thoroughly as I would like.

Many years ago when we went from IBM file indexing to Aceler8 on S/36, ASNA 
said it would be much faster, and it was much faster - the users were ecxtatic

In the mid 90's when we went from S/36 CISC to AS/436 RISC, IBM & our 
hardware reps said it would be much faster, and it was much faster.  IBM 
literature promised 8 fold increase in performance.  Our benchmark studies 
said the increase averaged 20 fold across the board.

When we went from S/36 SSP as the only operating system on our AS/436 to 
being a guest of OS/400, IBM & our hardware reps said it would be much 
faster, although we argued that it did not make any sense, but it was much 
faster.  At the time we were running the company off of BPCS/36 & there was 
some discussion about whether we still needed Acceler8.  We tried running 
without it, and the slow down was noticeable, so we continued using that 
product on S/36 SSP.

We migrated to BPCS 405 CD in 1998 & still have an unrelated package running 
in M36 mode.

Now we were given an astronomical figure for how much faster the 170 would be 
over the 436 & I have been spoiled by all of the previous promises.  The 
backups go faster, when they run, but what is more important to me is the day 
to day operations of interactive users, and how best to schedule jobs run in 
the evening that used to fit into my nites but do not any more.

I am seeing 3 types of performance problems on the 170.

1. A tiny number of jobs do go faster, like 2-3 times faster, but the vast 
majority go noticeably slower - in other words we are not witnessing this 
purported 1300 percent increase in speed.

2. Interactive jobs have noticeable degradation when the user does a command 
option that they have not recently done, or have not done previously in that 
program, or upon arrival at a different screen in a series of screens 
connected to a program.  This seems something like an issue of CACHE or on 
the S/36 I would be looking at what screens are resident in memory.  But I 
would not expect this kind of problem to suddenly appear just by switching 
boxes & not any settings.

3. There are some evening batch jobs that we usually run at least weekly, on 
different nites of the week, whose schedule had been structured to avoid a 
heavy load on any one nite of the week, but because some of them now take 
considerably longer to execute, we now have several busy nites that were not 
a problem on the 436.

One of these is CST900.  The volume of shop orders has not increased, in fact 
it is down by about 30% due to some reccommendations from one of our 
consultants.  On the 436, CST900 took about 50 minutes to do a purge against 
6,000 open shop orders in which about 10% would go away.  About 5 minutes 
before the job gets finished, we have to do the NOMAX response to the message 
about the spool file filling up at 10,000 pages of CST270.  On the 170, 
CST900 takes about 200 minutes to do a purge against 4,000 open shop orders 
in which about 10% go away.  The NOMAX response is about 30 minutes before 
the job ends.

The last week or so I have been rereading articles in News/400 about 
perfomance issues (this has led me to muck around with RUN priority in nitely 
batch jobs) & tonite I was studying CST900.  It seems to me that a large 
chunk of the processing time is in CST270 which prints a report so monstrous 
that it is of no use to anyone so we delete it without even looking at it.  
My first impressions of looking at the CST270 source code is that it was 
programmed by some real talented human beings, as opposed to AS/Set, who made 
a serious effort at organization & documentation.  I am impressed with their 
performance.  There's just a few important things I do not like about the 
programmer style.

There's a programmer no-no called "READ RECORDS SEQUENTIALLY AND TAKE ALL DAY 
ABOUT IT." (or in our case, take all nite.) When RPG uses a positioning 
indicator like SETLL then READ until hit record outside relevant range, the 
CL that calls the program can OVRDBF access as SEQ ONLY (*YES) for speedy 
access of each chunk of READs, but when the same logical file is accessed by 
a mixture of SETLL SETGT READ CHAIN etc. then it is my understanding that 
this technique is not available.  CST270 uses this no-no on a lot of files, 
and to be honest, lazy programmer me also does this sometimes because it is 
easier to program in RPG using the no-no.

There's another programming no-no which can be stated "RANDOM DISK ACCESS AS 
INEFFICIENTLY AS YOU CAN."  This has to do with when it makes sense to do a 
lot of READE.  If the program is an interactive user transaction & all the 
data that's needed can be obtained by a couple dozen READE then this is an 
efficient way to fly, but it can contribute to excessively long run times 
when found in batch operations.  The articles I saw suggested that READE be 
replaced by READ then test for change of key's value like SSA used to do all 
the time on BPCS/36. 

I did not dig through the logic heavily enough to see precise circumstances 
of needing READE to make sure they were one time uses, as opposed to some 
kind of loop, due to my annoyance with the naming of many key fields and 
subroutines by people who learned their trade prior to high level languages. 

I found nine files accessed by READE - there might have been more.

One of the input files is ITHL29 = Inventory History by Order / Item.
I think I know why it has to go after inactive or deleted records, if any not 
active, but I do not know why it cannot limit itself to history of shop 
orders.  This is one of the files that is being accessed by READE, which 
makes absolutely no sense to me.

If ITH is being accessed to get at reporting on individual shop orders, then 
READ with SEQ ONLY (*YES) makes enormous sense to me & I wonder if the same 
programmer style was used on the rest of the CST900 job stream.

Overall, I think CST270 is one of the better written SSA programs I have had 
the privilege of analysing, in which there are just a few things I found that 
I don't like about it, and my visitation was still somewhat cursory given its 
large size & one partial evening of study while waiting on other stuff to get 
done like the backup. 

I still do not understand why CST900 should
take just over 3 hours to process 4,000 shop orders on 170,
but just under 1 hour to process 6,000 shop orders on 436,
when the 170 was sold to us as being a superior box to the 436.

Something don't compute.

The big topic for me now is whether we even need CST270, within the CST900 
job stream, and what code to tweak to get past it.  

I am sure BPCS_L archives would have relevant threads that I did not pay 
sufficient attention to when I was oblivious to this performance glutton, 
because it is only when something takes longer to run that we do an analysis 
seeking problems, except I probably contributed to the archives overflowing 
their home.

Al Macintyre

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