Suggested recommendation:

IF YOU USE IMAGE LOGGING, ALWAYS MAKE YOUR CSLT THE SAME DAY YOU NEED TO USE IT! 
(Or make sure no CHANGELOG occurred since the CSLT was made.)

(Thanks be to SOX...which forced Image logging.)

We added so many log files identifiers for each of our production databases it reached the ULog limit in sysgen of 64 logging identifiers.  So, per recommendations of this listserv (and elsewhere,) I had to update the tables in sysgen and do a CONFIG UPDATE this weekend to bring it to the maximum HP ULog limit of 128.[1]

Not a problem.

Stop the logging identifiers with "LOG logid,STOP"

Shut down the system and BOOT ALT from tape.  System came up just fine!

UNTIL it was time to restart logging!

Every logging identifier reappeared with old log file numbers a few days old.
(We do a CHANGELOG every night and move the old log file to a different group.)

I scratched my head on this one for half of Sunday.

I did GETLOGs and they wouldn't take.  Every time I used the AUTO parameter, it insisted I start with a log file that ended in "001".[2]  I couldn't use GETLOG on old file numbers either.

D*AM*N!  That really messed up our log file continuity naming convention.  I did not relish the idea of starting all our log files over at "001" again.  That also meant I would have to purge all the previous log files "001...nnn" in the move-to group routine above so our nightly routine would continue to work, or create a new group and edit our routine.)

So I started tinkering with one log file.  One method, was to rebuild the log file ending in "001" do a GETLOG ...;AUTO and start over.  Then do a CHANGELOG a hundred sixty odd times until I got back to our previous number to fit our naming convention.  REPEAT...FORNUM I=1,n in MPEX helped there.  MPEX also helped purge all the recently created log files with nothing in them.

Then I found another trick:   

I RENAMED the log file to the older number LISTLOG report wanted.  Did a LOG logid,RESTART.  Did a CHANGELOG logid.  Then renamed the log file back.  Funny thing about the CHANGELOG, the new log file number *jumped forward* several log file numbers!

Example:
LISTLOG

MYLOGID   user.account    YES    YES    MYLOG165.group.account

RENAME MYLOG168, MYLOG165
LOG MYLOGID,RESTART   ... (logging starts successfully.)
CHANGELOG MYLOGID     ... (log file number jumps to MYLOG169!)
RENAME MYLOG165, MYLOG168

(repeat for every LOGID in LISTLOG.)

- - - - - - <Epiphany Begin> - - - - - - - -

Then it occurred to me, the Log file numbers the system wanted were from the day the CSLT was created.  I had made it before the weekend, thinking it would save me some time before the shutdown!  

- - - - - - </Epiphany End> - - - - - - - -

Therefore:

a. Logging Identifiers copy number on the CLST tape in the case of an UPDATE or UPDATE CONFIG.

b. Logging Identifiers on the system retain the NEXT log file they need to CHANGELOG to.

So if one needs to use a CLST to load and you're using Image Logging, remember to use it just after you create it, or make sure no CHANGELOGs occurred since it was made.

This may effect some sites as they may believe their CPU is a static configuration and only do a CSLT once a month or once a week.  In the case of an emergency tape load, to save some heartache rebuilding image log files, they may need to do a CSLT every day.

Notes:

[1]  What's with the cheesy LOGID limit of 128?  Perhaps one can squeeze another patch out of HP before end of support?

[2]  What's with that anyway?  Why can't one do a GETLOG with whatever file number one darn pleases?)

BT


Tracy Johnson
MSI Schaevitz Sensors 

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *