|
midrange.com
Nope
michael@ryantechn
ology.com
Sent by: To
midrange-l-bounce Midrange Systems Technical
s@xxxxxxxxxxxx Discussion
<midrange-l@xxxxxxxxxxxx>
cc
11/09/2005 01:31
PM Subject
RE: Error deleting data area...
Please respond to
Midrange Systems
Technical
Discussion
<midrange-l@midra
nge.com>
Any other processes accessing that data area?
> -------- Original Message --------
> Subject: RE: Error deleting data area...
> From: todd.sabella@xxxxxxxxxxxxx
> Date: Wed, November 09, 2005 1:14 pm
> To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
>
> Nothing has changed recently and no ILE is involved
>
> Submitting program.....
> Program . . . . . . . : DAYSYSCOMP
> Program creation information:
> Program creation date/time . . . . . . . . . . . : 05/05/31 08:20:51
> Program attribute . . : CLP
> Type of program . . . . . . . . . . . . . . . . : OPM
>
> Submitted program....
> Program . . . . . . . : CIRT0200
> Program creation information:
> Program creation date/time . . . . . . . . . . . : 02/09/15
23:56:36
> Program attribute . . : CLP
> Type of program . . . . . . . . . . . . . . . . : OPM
>
>
>
>
>
>
>
> michael@ryantechn
> ology.com
> Sent by:
To
> midrange-l-bounce Midrange Systems Technical
> s@xxxxxxxxxxxx Discussion
> <midrange-l@xxxxxxxxxxxx>
>
cc
> 11/09/2005 12:38
> PM
Subject
> RE: Error deleting data area...
>
> Please respond to
> Midrange Systems
> Technical
> Discussion
> <midrange-l@midra
> nge.com>
>
>
>
>
>
>
> Have you recompiled the either the submitted or submitting program, and
> now they are in different activation groups?
>
> > -------- Original Message --------
> > Subject: Error deleting data area...
> > From: todd.sabella@xxxxxxxxxxxxx
> > Date: Wed, November 09, 2005 12:25 pm
> > To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> >
> > For the second time in a few days, we have received this error when
> trying
> > to delete a data area within a batch job.
> >
> > The data area is created in the submitting program. Then a new program
> is
> > submitted. The submitted program checks for the data area, retrieves
its
> > value, and is supposed to delete the data area. It has worked fine for
a
> > number of years.
> >
> > If the object was locked by something else, I would have expected to
see
> > CPF2114 (Cannot allocate object WHICH01 in RTAM type DTAARA. ). But
> instead
> > we're getting CPFA030 (Object already in use) which mentions threads.
> >
> > Along with a program dump, the system printed the job information.
There
> > was only one thread for the job...
> >
> > 5722SS1 V5R2M0 020719 Work with Job
> > Threads
> > Total Aux Run
> > Thread Status CPU I/O Priority
> > 00000004 RUN .066 57 50
> >
> >
> > Anyone have any ideas ??
> >
> > Thanks,
> > Todd
> >
> > A snippet of the job log....
> >
> > Message . . . . : 12800 - CHKOBJ OBJ(RTAM/WHICH01) OBJTYPE(*DTAARA)
> > 05/11/09 00:40:55.174600 QCADRV QSYS 0391
CIRT0200
> > R
> > Message . . . . : 13300 - RTVDTAARA DTAARA(RTAM/WHICH01)
> RTNVAR(&WHICH)
> > 05/11/09 00:40:55.183232 QCADRV QSYS 0391
CIRT0200
> > R
> > Message . . . . : 13400 - DLTDTAARA DTAARA(RTAM/WHICH01)
> > 05/11/09 00:40:55.206864 QP0QCHK QSYS *STMT
CIRT0200
> > R
> > From module . . . . . . . . : QP0QCHK
> > From procedure . . . . . . : qp0qchk__FP15chk_parms_block
> > Statement . . . . . . . . . : 642
> > Message . . . . : Object already in use.
> > Cause . . . . . : Cannot allocate object for reason code 1. 1 --
> Object
> > WHICH01 of type *DTAARA in library RTAM is in use by another thread.
2
> > --
> > Member WHICH01 in file , library RTAM is in use by another thread.
> > Recovery
> > . . . : Wait until the object is no longer in use and try the
> request
> > again.
> > 05/11/09 00:40:55.252880 QCLXERR QSYS 00DA QCLXERR
> > Q
> > Message . . . . : CPFA030 received by CIRT0200 at 13400. (C D I R)
> > Cause . . . . . : Control language (CL) program CIRT0200 in library
> RTAM
> > detected an error at statement number 13400. Message text for
CPFA030
> > is:
> > Object already in use. Recovery . . . : This inquiry message can
be
> > avoided by changing the program. Monitor for the error (MONMSG
> command)
> > and
> > perform error recovery within the program. To continue, choose a
reply
> > value. Possible choices for replying to message . . . . . . . . . .
.
> .
> > . .
> > . : C -- Cancel the CL program. D -- Dump the CL program variables
> and
> > cancel the CL program. I -- Ignore the failing command. R -- Try the
> > failin
> > command again.
> > 05/11/09 00:40:55.268208 QMHSNINQ QSYS 0CDD
QCLXERR
> > Q
> > Message . . . . : D
> > 0 05/11/09 00:40:55.233824 QMHUNMSG *N QCMD
> > Q
> > Message . . . . : Function check. CPFA030 unmonitored by CIRT0200 at
> > statement 13400, instruction X'006F'.
> >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
