Factotums and Helots

Discussion created by ca.portal.admin on Jul 30, 2005
Factotums are to DC what helots are to the database engine. They
perform DC's work, like writing enter next task code, etc. IDMS runs in
tasks. All work is done under the thread of a task. This is so that
wait states do not impede IDMS processing. Even internal work is under
the TCE. So for work that doesn't have a user, or is system wide
utility work, like writing enter next task code when a user's task is
done, a factotum is attached. It also allows asynchronous processing on
a tasks behalf. For a view of the many types of factotums there are,
look at the dsect refenrence, I think (but am not 100% at the moment)
the TCE control block has a bit that says what kind of factotum is
processing. Same goes for Helots who do utility work for the load
modules whose name starts with IDMS. Factotums are attached out of
modules with the prefix RHDC.
A stuck factotum, or helot, however is not a beautiful thing, and could
impede IDMS performance. So when you see a Factotum or Helot hung up
through the eyes of the Performance Monitor, then indeed there is a
problem that needs attention. A common one is a hung dcmt vary area
command, or any database related dcmt command.

Lutz Petzold

This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by reply e-mail and then delete this e-mail immediately. Thank you.

IDMS Public Discussion Forum


Re: PMAM reports

I am running the reports two logs at a time. This one blows up after
reading about 1240 records from a particular tape so it is not a
concatenation problem. I thought I had found the problem because I saw a
sequence with only PMHSEQ# of 1 followed by 2 rather than what seems to
be the correct 1,2,3 sequence but that failed to when I had deleted
those entries.

It seems that what came off the log is wrong but how?