ca.portal.admin

Re: Transaction vs Rununit

Discussion created by ca.portal.admin on Feb 3, 2006
I agree with Pete and somewhat with Joe. However, the multiple run-unit
per tce (task) has always been avaiable, even before 12.0. It is a
task, TCE, that terminates, not a program, and the run units for that
task, TCE, have always been rolled back on abnormal termination,
depending on the message severity. I agree that a change was made with
12.0 in regards to transaction/task terminology. If it was carried
through to all messages, literals and mechanizations of IDMS I dont know
and would kind of doubt. It spans two support areas, DC and DB, and the
intersection between the two has always been a noman's land. My memory
of the 12.0 says that they flip flopped the meaning of transaction and
task. But, a run unit was always a run unit, pre and post 12.0 days. A
run unit is symbolic for a #VB50 and gets established on a bind dmcl
call (external or internal).

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.
Aetna

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Transaction vs Rununit
"I agree with Pete and somewhat with Joe. However, the multiple run-unit
per tce (task) has always been avaiable, even before 12.0. It is a
task, TCE, that terminates, not a program, and the run units for that
task, TCE, have always been rolled back on abnormal termination,
depending on the message severity. I agree that a change was made with
12.0 in regards to transaction/task terminology. If it was carried
through to all messages, literals and mechanizations of IDMS I dont know
and would kind of doubt. It spans two support areas, DC and DB, and the
intersection between the two has always been a noman's land. My memory
of the 12.0 says that they flip flopped the meaning of transaction and
task. But, a run unit was always a run unit, pre and post 12.0 days. A
run unit is symbolic for a #VB50 and gets established on a bind dmcl
call (external or internal).

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.
Aetna


"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Transaction vs Rununit
"Sorry Pete as Philippe is correct in his definition and example of a
'DATABASE' transaction.

I don't care to get into long discussions either. The 'DATABASE' transaction
(as opposed to the other definitions of transaction) was introduced in R12
IDMS SQL Option as it is SQL terminology. The transaction can represent one
or more IDMS run units in IDMS SQL. Since more than not IDMS shops do not
employ IDMS SQL Option, the transaction consists of one run unt (they are
the same).

Recovery was the big benefit in R12 of having the transaction. If within the
same idms program, both SQL and non SQL dml calls are issued. Transaction
recovery can keep the run units db rolled out in synch. It gets a lot more
complex and perhaps more confusing to students of transaction management.

Cheers,
Joe Perkins

Outcomes