A Brief History of WCBT problems

Until V3R1 the limit for number of entries in the WCBT was 32,767.  Back in
V2R3,  V3R0M5 & V3R1 a PTF came out that would give a CPI1468 warning
message when you were running out of WCBT space.  Until then you just got a
CPF0957 when it was already too late.  That PTF was of more importance for
V3R0M5 and earlier, as the size of the WCBT was greatly increased at V3R1 -
which then caused the following problems.

During the upgrade to V3R1, the WCBT format was converted, and the table
was recreated - on a single DASD unit !

 In V3R1 there were a couple of PTFs to solve the performance problem when
the WCBT resided on a single disk unit (it allowed it to be allocated
across multiple disk units).
A tool (program QWCWCBTS) was made available by V3R1 PTF that you could run
in a restricted state to reallocate the WCBT over multiple DASD arms.
Another PTF in V3R1 addressed the poor performance of commands like WRKJOB,
WRKSBSJOB, WRKSBMJOB due to the WCBT not being compressed during an IPL
(this PTF introduced the QWCBTCMPTB data area to control compression during
IPL, which was replaced at V4R1 by a CPRJOBTBL attribute set with CHGIPLA).

Another V3R1 problem was that, if you had an FSIOP, the QWCBTCLNUP job
would occasionally still be running when the FSIOP monitor job was started,
resulting in a message like CPF1101 or CPD2638.  V3R1, V3R2 & V3R6 PTFs
were released for that.

If you ran an *M36 and, and had an incompletely created one, there was a
problem (from V3R7 on) where the M36 would fail to start after the WCBT was
compressed (because the pointer to the QM36000 job structure was
invalidated by the compression).  I believe a PTF was only released for
that in V4R4.

Another problem many people encountered, that ate up your disk space at a
rapid pace, was the SRDS (Save Restore Descriptor Space) would grow at a
rate of 20MB or more per day (under certain conditions - assuming you ran a
daily backup).  This was originally suspected as a WCBT problem, but a
compress of the WCBT in this case didn't help - you needed to run RCLSTG
frequently.  This problem occured on V3R6, V3R7, V4R1, V4R2 & V4R3.  I
believe all but V3R6 got a PTF to fix this.

Neil Palmer         DPS Data Processing Services Canada Ltd.
                                             AS/400~~~~~
Markham,  Ontario,   Canada    ___________          ___  ~
Phone: (905) 474-4890  x303   |OOOOOOOOOO| ________  o|__||=
Cell.: (416) 565-1682  x303   |__________|_|______|_|______)
Fax:   (905) 474-4898          oo      oo   oo  oo   OOOo=o\
mailto:NeilP@DPSlink.com    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.DPSlink.com        AS/400e  The Ultimate Business Machine





"Richard Jackson" <richardjackson@richardjackson.net>@midrange.com on
2000/09/29 16:49:31

Please respond to MIDRANGE-L@midrange.com

Sent by:  owner-midrange-l@midrange.com


To:   <MIDRANGE-L@midrange.com>
cc:

Subject:  RE: WRKSBMJOB, WRKUSRJOB slug-like


FYI, you don't have to have a lot of jobs hanging around.  The job tables
are also called the "work control block table" or WCBT.  Each entry is
associated with a single job and is called a "work control block table
entry" or WCBTE.  At V3R1 and before, there was no index to the active
WCBTE.  This could be true at V3R2 but I don't know.  If you wanted to
discover all the jobson the machine, you had to read the entire table.  I
think that it was at V3R1, some clever person in the lab decided that the
paging technique used to bring in the pages of the WCBT pushed out too much
non-WCBT stuff so they changed the technique to something called "exchange
bring".  This dramatically reduces the memory footprint but also eliminates
prefetching and forces lots of faulting.  I think that I remember a PTF to
fix this.   During Common in Austin Texas right after V3R1 was released, I
had lunch with one of the AS/400 performance "icons" and we chatted about
this.  I had spotted it because someone on some mailing list brought it up
so I went and did a test while running SMTRACE.  It was just pathetic.

The job commands take a long time because the machine is reading the entire
WCBT.  There is no WCBTE index like there is on RISC.  If the WCBT was EVER
very large, the system might still read it all.  Compressing or rebuilding
the table means you read less stuff so it goes faster.  Compress or rebuild
and look for PTFs.

I'm sure glad that Alexey and Eric remember this stuff, I had completely
forgotten about the compress data area.

Richard Jackson
mailto:richardjackson@richardjackson.net
http://www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---