ca.portal.admin

Clarification on CMMT, for those interested

Discussion created by ca.portal.admin on Apr 21, 2008
CMMT (Cross Memory Master Terminal) was 'freeware' given out by InnerAccess Technologies, who were bought out by NEON in 2004, who were bought out by DataDirect. This was a nice simple monitor that was external to IDMS. Thus if the CV locked up, in most cases find out who or what was causing the issue, and you could cancel via CMMT the task or programs that was causing SOS or Storage lockups, even though you could not get to the CV directly via CICS or TSO.

My problem, on installing ZOS 1.9 and setting a Keystate of 4 for IDMS, CMMT no longer will work. I followed the instructions that came with CMMT but alias it still abends.

With ""CMMT"" you could externally look at:
AREAS, BUFFERS, DBNAMES, Destination, Files, Lines, Terminal, Memory (and update of memory), Dis Multitasking(Subtask), your Nucleus load addresses, Program PPT entries, Programs called, Printer, Pterminals, Pterminals, Resources (actively running ""and enable canceling), and display Storage pools, RUN-UNIT, System Stats, and Tasks

Edward A. Timm
Sallie Mae, Senior Database Analyst
ETIMM@salliemae.com
(317) 596-1182
Fax (317) 595-1494
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Database Procedures
"Thanks to Pete Charles and Charles Hardee for the good information.
I'll take what you've said as gospel since it came from you two.

To solve Scott's original problem:
He can't open a separate run-unit to CONNECT the index since he will
deadlock with the run-unit that did the STORE.
He can write queue records since we all agree that can be done.

However, maybe don't even use an index.
Write the queue records and set a high threshold so the queue isn't
processed by a trigger task.
Have a DC-BATCH program read the queue records and then you will know which
records had the flag set and now need to be reset.

You may want to test COMMIT and FINISH logic in regards to queue records to
be sure this works.
I seem to recall (maybe incorrectly) that queue records were committed
according to the COMMIT and FINISH logic in the application program even
without the TASK parameter (IE COMMIT TASK and FINISH TASK).

Thanks.
Jon Gocher


----- Original Message -----
From: ""Charles Hardee"" <kilrathi@FRONTIERNET.NET>
To: <IDMS-L@LISTSERV.IUASSN.COM>
Sent: Monday, April 21, 2008 8:55 AM
Subject: Re: Database Procedures

Hi Kay,
Yes, that would work since queue rununits have their own vib and so you
won't be ""corrupting"" the application rununit's vib. However, keep in mind
that queue is recoverable across an abend. So, if you put a DBKey into the
queue and then, before the queue triggered task processes it CV crashes,
when CV is restarted the queue record would most likely still be there but
the target record could have had who knows what happen to it, including
being deleted and even a new record stored in it's place. You may want to
consider logical keys rather than physical ones and allow for the fact
that
someone could have updated the record and even deleted it.
Chuck



-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM] On
Behalf Of Rozeboom, Kay [DAS]
Sent: Monday, April 21, 2008 7:30 AM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: Database Procedures

Chuck,
Would it be OK to write a queue record containing the dbkey of the
stored/modified record, which would then trigger a separate task to
connect
record to the index? Of course this would only work in CV mode.


-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM] On
Behalf Of Charles Hardee
Sent: Sunday, April 20, 2008 10:51 AM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: Database Procedures

NO! NO! NO! NO!

A procedure CANNOT, FOR ANY REASON, issue a DML verb when it is executing.
The reason is that the VIB is SERIALLY reusable, not asynchronous. If you
issue a DML verb from within the procedure you will corrupt the VIB and no
telling what will happen to the rununit that is executing at the
application
level.

The reason you can issue a queue related command is because queue
processing
takes place in a different rununit, a SYSTEM rununit, and therefore a
different VIB.

Chuck


-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM] On
Behalf Of Jon Gocher
Sent: Sunday, April 20, 2008 9:45 AM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: Database Procedures

Scott -

The reasons Tom described are the reasons you don't want to put DML in a
database procedure.
However, I think in this case, you can get away with it.
If you call using the same SUBSCHEMA-CTRL and you call on only STORE or
MODIFY, I think you will be OK.

I've written database procedures that write QUEUE records and have not had
any problems.
Of course. with QUEUE, it uses a pre-defined run-unit which is different
than the application program's run-unit.

Thanks.
Jon Gocher




----- Original Message -----
From: ""Tom&Susan Schoenborn"" <schoents@COMCAST.NET>
To: <IDMS-L@LISTSERV.IUASSN.COM>
Sent: Friday, April 18, 2008 3:06 PM
Subject: Re: Database Procedures

Hi Scott:

Any program that calls a subprogram is merely a technical convenience,
as the 'subprogram' essentially operates as an extension of the caller
(unless you do an ATTACH). Thus, as far as a database procedure is
concerned, there would be no difference if the DML was physically in
the procedure or the called subroutine.

There are numerous reasons for NOT doing DML in a database procedure
(including but not limited to):

1. You could issue DML that would recursively trigger the procedure.
2. You could issue DML that would cause a deadlock.
3. You could issue DML that would cause a wait.

Any of the above are particularly undesireable, so you definitely want
to avoid DML (especially 'update' DML) in a database procedure. Since
your procedure is called for a STORE/MODIFY, doing a
CONNECT/DISCONNECT would not cause recursion (#1), but you can't avoid
#2 or #3, or other potential ""issues"".

I think the OM set is probably a good idea, but you'll either have to
add the logic to your programs or add a call to a subroutine from
those programs.

Regards,

Tom Schoenborn
TASchoenborn@msn.com

----- Original Message -----
From: ""VanDerHeyden, Scott"" <svander@DHS.STATE.IA.US>
To: <IDMS-L@LISTSERV.IUASSN.COM>
Sent: Friday, April 18, 2008 12:08 PM
Subject: Database Procedures


All,

I know that you are not supposed to put DML statements in a database
procedure (though I don't know the reason). What I am wondering is....
would the same restriction apply if you placed a call in the procedure
and had the DML performed in the called module be allowed.

The situation is this:

We currently have a database procedure that sets a field to 'y'
before store and modify of our person record.

There are two batch programs that walk all the person records
to find the ones with the 'y' in field. (one retrieval one to reset
the field to spaces). At present we have approximately 1.13 million
person records
and on a daily basis between 2,000 - 6,000 have been updated with the
'y'.

We would like to only have to read/update the records marked with
the 'y' and are thinking of using an Optional Manual index to do
this
(connecting the record when the 'y' is added and disconnecting it when
the
batch program removes the 'y'). However, the no DML rule is hindering
this idea. We of course realize we could add the connect to every
program that stores/modifies the record. But we are big enough and have
enough
turnover in staff that I do not feel comfortable with the idea of
leaving
the connection to the memories of the programming staff.

So, if anyone can enlighten me as to why no DML in a database
procedure and/or if the called module would be an alternative it would
be greatly appreciated. Of course if you have any other ideas as to
how to identify these records I am open to that as well.

Thanks
Scott Van Der Heyden
State of Iowa Dept. of Human Services

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








Normal

Normal
Re: Database Procedures
"Scott,

My suggestion would be to avoid the database procedure, instead create a
new unlinked sorted index (mandatory automatic) on the field that you use
for signaling that a change has taken place. The program that sweeps the
records only need to read those records with a ""Y"" via the index. This
should be just about as efficient as using an OM set, although I would
recommend periodic index rebuilds.

As for using DML calls in a Database Procedure - don't. Although IDMS may
not prevent you from doing it, it will change currencies and IDMS control
blocks and may lead to unpredictable results for the unsuspecting
programmer.

Anyway, how do you handle it now? Since you use the database procedure to
set the field to a ""Y"" in the update, how do you ever change it to
something else? Do you have the one program name hardcoded in the Database
Procedure, or do you use a special schema, if you have a special schema,
you can define the set as optional in that one, and disconnect the records
as you go along.
I assume you have down-time on your database as no updates can be allowed
between the two programs.

Tommy Petersen
110 Cokesbury Rd
Room 542H
Lebanon, NJ 08833

Phone:
Internal 200 - 3699
External (908) 236-3699
Fax: (908) 236-3692




""VanDerHeyden,
Scott""
<svander@DHS.STAT To
E.IA.US> IDMS-L@LISTSERV.IUASSN.COM
Sent by: IDMS cc
Public Discussion
Forum Subject
<IDMS-L@LISTSERV. Database Procedures
IUASSN.COM>


04/18/2008 02:08
PM


Please respond to
IDMS Public
Discussion Forum
<IDMS-L@LISTSERV.
IUASSN.COM>







All,

I know that you are not supposed to put DML statements in a database
procedure (though I don't know the reason). What I am wondering is....
would the same restriction apply if you placed a call in the procedure and
had the DML performed in the called module be allowed.

The situation is this:

We currently have a database procedure that sets a field to 'y'
before store and modify of our person record.

There are two batch programs that walk all the person records to
find the ones with the 'y' in field. (one retrieval one to reset the field
to spaces). At present we have approximately 1.13 million person records
and on a daily basis between 2,000 - 6,000 have been updated with the
'y'.

We would like to only have to read/update the records marked with
the 'y' and are thinking of using an Optional Manual index to do
this (connecting the record when the 'y' is added and disconnecting it when
the batch program removes the 'y'). However, the no DML rule is
hindering this idea. We of course realize we could add the connect to
every program that stores/modifies the record. But we are big enough and
have enough turnover in staff that I do not feel comfortable with the
idea of leaving the connection to the memories of the programming staff.

So, if anyone can enlighten me as to why no DML in a database procedure
and/or if the called module would be an alternative it would be greatly
appreciated. Of course if you have any other ideas as to how to identify
these records I am open to that as well.

Thanks
Scott Van Der Heyden
State of Iowa Dept. of Human Services
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Database Procedures
"Jon,

Right on with the QUEUE and testing. There was something about COMMIT and
ROLLBACK and it's relationship to the task, as you mention and I just don't
remember what it was.

Scott will also need to decide how to handle errors from the QUEUE
processing with respect to his parent rununit. For instance, what happens if
he gets an I/O error, QUEUE area full, etc. He will have to decide how to
report this and what action the STORE is to take if an error occurs.

Good luck,
Chuck

Outcomes