Loudwater
Systems
Management


Overflow in COLLECT

You have some investigation to do and then some choices to make:
    1. What column in what table? How is the column defined?
    2. What has the level of activity been lately on this measure?
       - Is this a one-off? Who/what caused it? (Defective SMF record is
         possibility -- but a remote one).
       - Were you nudging the max value previously? If so, that may be
         a situation worth correcting. Who/what is causing it?
       - Is the column too small, and it's just that you are a big site?
         (You might want to report this as a bug)
    3. If you have to increase the capacity of the column...
       - Report to Tivoli so it gets fixed 
       - Add a column to the table in the DB
       - Add comments to DB
       - Copy/recalc old data into new column, changing units (K-->M,
         SECS-->HOURS etc)
       - Redirect all references (UPDATEs, QUERIES, etc) to the column
       - Change the table/update/comment defs etc
       - Alter QMF FORMs, GDDM FORMATs to show new units
*** (Later) The field overflowing was LINES_TO_SPOOL. After much effort (5-6 man days) we discovered that EPDM (unlike SLR) reads and applies every SMF26 record. Example: If you run a job on one cpu, and ROUTE PRINT the output to another, two SMF26s get created, and EPDM shows double the true LINES_TO_SPOOL. NB There are many ways to create this effect; sometimes the multiplier can be much larger than 2 (would you believe 31?).

*** PTF available and applied to [Client] *** Fixed permanently in R2