tickHF: not supported usage of -11!(-2;logFile) in case of invalid log file

[joannajarmulska]

Function -11!(-2;logFile) in case of invalid log file returns two numbers:

• number of valid chunks
• length of valid part

Function to replay data expects only number of chunks, which is returned when log file is not corrupted.

[joannajarmulska]

To handle corrupted log file additional field cfg.handleBadJournal will be added to configuration tickHF.qsd with three options:

• ABORT - process will be stopped and journal needs to be handled manually (it can be moved or truncated).
• ARCHIVE_BAD_JRN - invalid journal is archived and new one is created. Note that messages from the invalid journal will be dropped. Afterwards it can be manually injected to the running system.
• TRUNCATE_BAD_TAIL - invalid journal is truncated to the size that contains only valid chunks (assigned as occurence of the first corrupted message). New messages will be appened to the existing journal.
  Note that for Windows truncate is not implemented. The code for that can be injected by the user. Therefore please overwrite .os.p.W.truncate function in os.q.

[sevastos]

Hi Joanna,
Does TRUNCATE_BAD_TAIL archive the invalid chunks for later inspection/use.
Thanks

[isaac-love]

I set timestampMode = LOCAL eodDelay = 14:31:00.000, why I can't get hdb file at 14:31:00.000?

[pawelhudak]

I set timestampMode = LOCAL eodDelay = 14:31:00.000, why I can't get hdb file at 14:31:00.000?

Please note that eodDelay configuration field is designed to delay the eod by reasonable small amount of time only (say minutes), see late ticks handling documentation for more details. Implementation of this mechamism includes caching of the incomming data in the memory of tickHF process, which imply limitation on the eodDelay duration.

Cheers,
Pawel