ca.portal.admin

Re:Re: Coding Allowing in ADS to check for 0966

Discussion created by ca.portal.admin on Dec 23, 2005
As far as I remember, you do not have control over the readies in ADS.

The ADS run-time environment will determine if the readies need to be
carried out at the time of the first DML statement. You can code the
ready statements anywhere in your dialog, without regard to the logic.
If you have two ready statements for the same area the last ready
statement encountered by the compiler will be the one executed.

I am not sure you can catch the error on a failure of the ready
statement, but, if you can, the check needs to be done in the first DML
statement you execute in the dialog. I am also pretty sure that if the
ready fails you will not start a run-unit.

Back in the 10.2 days you could call a utility (I think it was
documented, but unsupported) to execute DCUF and DCMT statements and you
could use that to check the status of an area. I don't know if that is
still possible.
But you should be able to code a Cobol program that does the BIND,
READY, check status and FINISH and returns the status of the ready to a
dialog as well.

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

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




Chris Wood
<Chris.Wood@GOV.A
B.CA>
To
Sent by: IDMS IDMS-L@LISTSERV.IUASSN.COM
Public Discussion
cc
Forum
<IDMS-L@LISTSERV.
Subject
IUASSN.COM> Coding Allowing in ADS to check
for
0966

12/23/2005 11:22
AM


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






Hi,



I am trying to intercept the 0966 message when accessing a database that
is offline. I want to display a friendly message rather than have the
abend screen with an 0966. I have coded ALLOWING ERROR CODES ('0326'
THRU '0966') after my first DML statement which is an OBTAIN FIRST xxxx
WITHIN yyyy AREA. I then code an IF ERROR-STATUS IS '0966'.



I still get the abend screen showing the 0966 error. Should this work?



I am on 16.0 SP1 + apars on z/OS 1.6.



Thanks



Chris Wood

Alberta Department of Energy

CANADA

This communication is intended for the use of the recipient to which it
is addressed, and may contain confidential, personal and or privileged
information. Please contact us immediately if you are not the intended
recipients of this communication, and do not copy, distribute, or take
action relying on it. Any communication received in error, or subsequent
reply, should be deleted or destroyed.
This communication is intended for the use of the recipient to which it
is addressed, and may contain confidential, personal and or privileged
information. Please contact us immediately if you are not the intended
recipients of this communication, and do not copy, distribute, or take
action relying on it. Any communication received in error, or subsequent
reply, should be deleted or destroyed.

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








Normal

Normal
Re: [IDMSVENDOR-L] OM INDEX
"At 18:03 12/28/2005, you wrote:
Actually that was a question I meant to ask. What would be wrong with
putting the index into the data area? You could use sub-ranges to separate
the data and the index so there would be no space contention issues caused
by the large ""cluster"" that the index will create - and it greatly
simplifies the ""which areas need to be readied in which usage mode"" issue.
It is something I've been meaning to suggest to our database designers here
so that we could add indexes into our network databases to improve SQL
performance - but there's been a reluctance because of the program
maintenance issues to get the area readies right. So using the sub-areas
seems to me the perfect solution. Am I missing something?

Cheers - Gary
Gary - I have been burnt many times by using sub-areas - unless/until
PRINT SPACE can report on sub-areas, I would not recommend sub areas
unless one is willing to run DBANS on sub-areas to determine utilization -

when a sub-area fills up, it the full sub-area is first in the area,
an EXTEND SPACE will do no good - and one cannot simply remove the
sub-area partition to give more space to the full sub-area - you are
changing the CALC algorythm and EVERYTHING goes south (or to you,
would it be going north?)

so while I might consider adding indexes to a data area, I would give
EXTREME caution to using subareas as they are currently defined ...

chris

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








Normal

Normal
Re: [IDMSVENDOR-L] OM INDEX
"Actually that was a question I meant to ask. What would be wrong with
putting the index into the data area? You could use sub-ranges to separate
the data and the index so there would be no space contention issues caused
by the large ""cluster"" that the index will create - and it greatly
simplifies the ""which areas need to be readied in which usage mode"" issue.
It is something I've been meaning to suggest to our database designers here
so that we could add indexes into our network databases to improve SQL
performance - but there's been a reluctance because of the program
maintenance issues to get the area readies right. So using the sub-areas
seems to me the perfect solution. Am I missing something?

Cheers - Gary

Gary Cherlet
Justice Technology Services
Telephone +61 (0)8 8226 5199
Facsimile +61 (0)8 8226 5311
Mobile +61 (0)41 333 1613
MailTo:cherlet.gary@saugov.sa.gov.au

This e-mail message and any attachments are qualified as follows:
Addressing: If you have received this e-mail in error, please advise by
reply e-mail to the sender. Please also destroy the original transmission
and its contents.
Confidentiality: This e-mail may contain confidential information which
also may be legally privileged. Only the intended recipient(s) may access,
use, distribute or copy this e-mail.
Individual Views: Unless otherwise indicated, the views expressed are those
of the sender, not Justice Technology Services.
Computer Viruses: It is the recipient's responsibility to check the e-mail
and any attached files for viruses.

Outcomes