ca.portal.admin

Re: #VIBDS Change for release  16.0

Discussion created by ca.portal.admin on Feb 2, 2006
Hi Bill,

VIBTBXN --> TBX ( To copy DSECT use #TBXDS TBKSESI=N )
TBXTBKA --> TBK ( Use #TBK )
TBKLID is the transaction ID.

The VIBTBXN says next NEXT VIB IN TBX-VIB also in TBX there is TBXNTBX
that says -->Next TBX of transaction.

So this implies that a TBK can have may TBX'x and a TBX can have many
VB50's. This makes no sense to me as I thought that a transaction was a
VB50 and since the transaction id is in the TBK it implies one TBK one
VB50.

Never seen any different but who knows about SQL.

Hope this helps.

Pete Charles
COGITO





-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of Bill Allen
Sent: 02 February 2006 01:24
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: #VIBDS Change for release 16.0

Hello All:

In releases prior to 16 the #VIBDS Dsect contained a field called
VIBRUNID,
this used to hold the Run Unit ID, in release 16 there is no such field.

There is a comment in the release 16 #VIBDS Dsect that says it is
defunct
and to use the TBKLID, this is a field in the #TBKDS Dsect.

Has anybody written any code that deals with this new #TBKDS Dsect for
the
RUN-UNIT ID? Are you willing to share it?

Bill Allen

"
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 am being careful. The SQL type transactions are nothing new to IDMS,
when we're talking about about concurrent database work. It's always
been possible for an application, although required some work and
attention to detail. And the use of internal tasks, factotums and
helots, even adds to the flexibility. SQL was a natural fit for IDMS in
that sense, although in other contexts I find SQL far more primitive
then IDMS architecture. It's a tribute to IDMS that it can be tailored
to SQL without changing it fundamentally.

As far as the 'finish task' goes, yes it could be humorous. But lets
not forget the changes to deadlock detection/response over the years.

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
"Be very careful about your use of transaction in these 'discussions'; I am
talking specifically (like Philippe) about the 'database' SQL transaction'
and that it consists of one or more run units...and yes, the vendor
definitely has contributed to the overall confusion in terminology.

Now we could talk about how the 'finish task' dml terminates and
synchronizes a recovery unit for a 'database' transaction. That could
certainly stir the pot, agreed?

In fact, this subject would have perhaps made for a good and perhaps on the
humorous side presentation at IUA/CA World or was it already given? (then
ooops).

Regards,
Joe Perkins

Outcomes