ca.portal.admin

sporatic dynamic alloation problems

Discussion created by ca.portal.admin on Mar 6, 2006
Hi IDMSLers,

We're having a weird problem with dynamic allocation that I'm wondering
whether anyone else is having it. Here's the thing. We've been using
dynamic allocation in all our CVs except for production for years. Last
summer, we finally converted over the production CV to include the
DSNames, and commented out all production file names in JCL INCLUDE
members so that all production jobs running in local mode are also using
dynamic allocation with the same file names. Our production CV is
cycled every night, and is down for several hours on sunday for
system-wide backups. Here's the problem.... Every once in a while,
when the production CV is brought back up, one or several files don't
get allocated due to a dynamic allocation error, and the area is flagged
as Not Available. In the log, we get message DC016922 OPENXDCB ERR=042
with the file name. If we vary the area in update, the file gets
allocated correctly, and the area is varied to update. We've determined
that it happens when there is a local mode job using the file (in
retrieval) while CV comes up. We don't seem to have any problems
when it's local mode jobs running while CV is up. I can remember a
couple of occasions where we got a dynamic allocation error, reran the
local mode job and everything was just fine.

There is an optional apar you can apply so that in local mode, if you
get the DC016922 message, it will wait and reattempt to allocate the
file. The apar is only for local mode jobs however. I've opened up a
problem with CA and have requested basically the same functionality in
the sense that if startup gets a DC016922 error, that startup continue,
but then reattempt to allocate the file. They've agreed to do
something, but I'm really curious. Am I the only one having this type
of problem with dynamic allocation????

Thanks,
Laura Rochon
Ajilon Consulting

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








Normal

Normal
Re: IDMS-STATUS and the CICS-EXEC Protocol
"Bill -

We create our own IDMS-STATUS routines for CICS.
We have several.
Instead of the displays, move your display lines to an 80 byte output area
and code something like this.
This will put the display in the MSGUSR area of the JES output for the CICS
started task
EXEC CICS WRITEQ TD QUEUE('CSMT')

FROM(CSMT-MESSAGE)

LENGTH(CSMT-MSG-LEN)

NOHANDLE

END-EXEC.

Thanks.
Jon Gocher


----- Original Message -----
From: ""Bill Allen"" <ARCHCONB@AOL.COM>
To: <IDMS-L@LISTSERV.IUASSN.COM>
Sent: Monday, March 06, 2006 6:10 PM
Subject: IDMS-STATUS and the CICS-EXEC Protocol

Hello All:

This question is for those sites that have COBOL Programs that execute in
CICS using the CICS-EXEC Protocol performing IDMS Data Base Activity.

Do you use the standard IDMS-STATUS for COBOL in these programs or do you
have a tailored version just for the CICS-EXEC Protocol?

If you have a tailored version can you share it with me?

If you use the standard IDMS-STATUS module are the results of the DISPLAY
commands in this module placed in the IDMS Log or CV JES Log?

For example:
DISPLAY 'PROGRAM NAME ------ ' PROGRAM-NAME.

DISPLAY 'ERROR STATUS ------ ' ERROR-STATUS.
DISPLAY 'ERROR RECORD ------ ' ERROR-RECORD.
DISPLAY 'ERROR SET --------- ' ERROR-SET.
DISPLAY 'ERROR AREA -------- ' ERROR-AREA.
DISPLAY 'LAST GOOD RECORD -- ' RECORD-NAME.
DISPLAY 'LAST GOOD AREA ---- ' AREA-NAME.
DISPLAY 'DML SEQUENCE ------ ' DML-SEQUENCE.


Bill Allen
ARCH Consulting Associates, Ltd.

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








Normal

Normal
Re: IDMS-STATUS and the CICS-EXEC Protocol
"The DISPLAYs were causing abends in my CICS programs so I ended up
coding my own STATUS for CICS.

IDMS-STATUS.
IF ERROR-STATUS = '0000'
NEXT SENTENCE
ELSE
PERFORM PROCESS-ERROR
THRU PROCESS-ERROR-EXIT
END-IF.
END-STATUS.
EXIT.

Where PROCESS-ERROR is generic enough that I use it with EXEC CICS
HANDLE ABEND as well. In our case, the CICS module is creating XML so
PROCESS-ERROR creates a new document that returns a flag and a nice
verbose message that the calling application can trap and display for
the user.

Any IDMS calls within PROCESS-ERROR should be coded so they won't call
IDMS-STATUS or else you might get a nifty loop.

FINISH
ON ANY-STATUS
CONTINUE
END-IF.


We are also using the calling application to log the error details.

<?xml version=""1.0"" encoding=""UTF-8""?>
<response xmlns:xsl=""http://www.w3.org/1999/XSL/Transform"">
<error-flag>W</error-flag>
<type>D</type>
<user-id>C84444</user-id>
<document-id/>
<case-no>5444444</case-no>
<user-message><![CDATA[Case 5444444, is not known to the
system.]]></user-message>
<corrective-action><![CDATA[Please ensure your case number is
correct or try another case.]]></corrective-action>
<date>20060306</date>
<time>17:22:30</time>
<error-details>
<program-name><![CDATA[SRCCDFE1]]></program-name>
<error-status>0326</error-status>
<error-record><![CDATA[CASE]]></error-record>
<error-set><![CDATA[CALC]]></error-set>
<error-area><![CDATA[VXSC0001-AREA-25]]></error-area>
<last-good-record/>
<last-good-area>VXSC0001-AREA-44</last-good-area>
<last-dml-seq>00000027</last-dml-seq>
<cobol-object><![CDATA[2000-PROCESS]]></cobol-object>
<case-no>5444444</case-no>
<task-number>0078506</task-number>
<eib-resp>00000000</eib-resp>
<eib-resp2>00000000</eib-resp2>
<debug><![CDATA[CALLED From:8200-TRANSFER-CONTROL GOING
To:SRCCDFE1]]></debug>
</error-details>
</response>


What I did on another system was to create new database records where I
could store the same elements listed above. Those records get purged
monthly.


Curt Wilson
Northrop Grumman Information Technology

Outcomes