|
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'. > > > > > > -- > > > > > > -- > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.
midrange.com
