ca.portal.admin

Non V 1 DC-COBOL calling Non V 1 DC-COBOL

Discussion created by ca.portal.admin on Jul 30, 2008
Latest reply on Jul 31, 2008 by ca.portal.admin
Hi,

=20

I thought that this was fixed many years ago but here goes.

=20

We have a unique situation where a production user can put our CV into a
very tight loop that can only be fixed by cancelling the CV. We have an
ADS dialog that makes a call to a DC-COBOL program that then calls at
least one other DC-COBOL program. Our investigation involves making a
version 2 of the ADS dialog and version 2's of the DC-COBOL programs. I
have created the V0002 entry that points to the load library that the
version 2 loads exist in and run DCMT VDP statements to define them to
the CV. When we run a test the first DC-COBOL program V 2 gets loaded
and executed but then when it calls the next DC-COBOL program it
disables the V 2 load and puts it out of service so it runs the V 1
load. Same happens with the other DC-COBOL program that gets called
afterwards.

=20

We are on z/OS 1.8 running 16 SP1 (0408) with many apars using the 3.4
COBOL compiler.

=20

Other than using V 2 programs the only thing that is different from V 1
of the first DC-COBOL program is the number of SNAP TITLE xxxx from AAAA
to BBBB. Would these snaps cause the problem?

=20

Thanks

=20

Chris Wood

Alberta Department of Energy

CANADA
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Non V 1 DC-COBOL calling Non V 1 DC-COBOL
"Steve,

I was able to cancel once when I was in the CV and did a DCMT V TASK
TERM but the other times if we are not in the CV we have not been able
to get in and stop it. At this time my concern is more about debugging
by using V 2 of the DC-COBOL to add the snaps etc. When I was able to
cancel the task our end of day stats showed that the dialog had been
called many times and so had the first DC-COBOL program. We believe that
this is a unique situation where something is happening in one of the
DC-COBOL programs that makes the dialog believe that all is fine but it
isn't and so it keeps making the call to the DC-COBOL.

I have one question that someone can answer/confirm my beliefs.

DC-COBOL should be able to handle bad error-status codes by having the
DML statement end with ON ANY-STATUS CONTINUE. This should be followed
by explicitly testing the error-status for known codes, zero and then
all else. One of the DC-COBOL programs is doing a GET QUEUE. If this
returns a certain error-status it will abend I believe, because the
checking might not catch it without the ON ANY-STATUS CONTINUE followed
by the explicit testing of error-status. Am I right in making this
assumption with a PROTOCOL of MODE IS IDMS-DC DEBUG?

Thanks

Chris

Note. I work much more with MS SQL than I do with IDMS nowadays so the
rust is showing!

Outcomes