× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.





Thanks for the information.  I can not find either of those two
possibilities occuring but still get the record lock.  Here is the job
log.

        5700    -       CALL PGM(GP5903CP)
        1700    -       ALCOBJ OBJ((GPPTRPM *FILE *EXCL)) WAIT(600)
        2300    -       DLTF FILE(QTEMP/GPPTRPMBK)
Object GPPTRPMBK in QTEMP type *FILE not found.
        2600    -       CPYF FROMFILE(GPPTRPM) TOFILE(QTEMP/GPPTRPMBK)
   MBROPT(*REPLACE) CRTFILE(*YES) INCREL((*IF PMSTAT *EQ 'A'))
Physical file GPPTRPMBK created in library QTEMP.
Member GPPTRPM added to file GPPTRMPBK in QTEMP.
No records copied from file GPPTRPM in GP#FILE.
        3000    -       CLRPFM FILE(GPPTRPM)
Member GPPTRMP already in use.
Function check. CPF3130 unmonitored by GP5903CP at statement 3000,
   instruction X'0025'.
CPF3130 received by GP5903CP at 3000.  (C D I R)

How is it possible for this to happen??????

Brad

"Dave Schnee"
<DSchnee-3XH/qhBBVT5t0JrxVvvTAUEOCMrvLtNR@xxxxxxxxxxxxxxxx> wrote in
message
news:<OFA1A8BC60.52C7F297-ON852570D6.0083996E-852570D7.0000E5BF@barsacon
sulting.com>...
> Brad:
> 
> I had this kind of problem several times over the last few months.
There 
> were 2 separate reasons, neither of them due to any out-and-out logic 
> problem.
> 
> First, if you are using high-availability software, there can be a 
> condition where you clear a member (or add one) and then write to it
where 
> your HA software grabs enough of a lock on the member and/or file to 
> prevent you from doing what you want.  This one bit me when populating
a 
> source file member that I had just added (probably not your specific 
> problem).  Your *EXCL lock on the *FILE may not give you enough
control 
> over both the MEMBER and the data space in it.
> 
> Second (and more insidious) is the use of Save-While-Active.  If you
have 
> some kind of SAVOBJ or SAVLIB going, there are internal seize-like
locks 
> obtained on some objects that have nothing to do with your lock but
CAN 
> prevent you from updating something.  In my case, it was updating a 
> *DTAARA on which I had an *EXCLRD lock that failed.  The workaround
here 
> was to monitor for the failure, delay a short interval and retry.
> 
> The system is getting more and more interesting.
> 
> Dave Schnee,
> Barsa Consulting Group, LLC
> 
> ---------------     Brad Porter wrote:     ---------------
> 
> date: Tue, 13 Dec 2005 14:15:24 -0700
> from: "Brad Porter" <bradp-mmonjyu0J3ZWk0Htik3J/w@xxxxxxxxxxxxxxxx>
> subject: Intermittent allocation issue
> 
> I am having a problem with a file allocation but it is very
intermittent.
> I allocate a file, copy records from the file, clear the file and then

> copy
> back.  Some times the clear operation fails with a cannot allocate
error.
> Here is a copy of the code and the error message.
> 
> 0016.00
> 0017.00              ALCOBJ     OBJ((GPPTRPM *FILE *EXCL)) WAIT(600)
> 0018.00              MONMSG     MSGID(CPF1002) EXEC(DO)
> 0019.00              SNDPGMMSG  MSG('Can not Allocate object GPPTRPM 
> File.')
> 0020.00              GOTO END
> 0021.00              ENDDO
> 0022.00
> 0023.00              DLTF       FILE(QTEMP/GPPTRPMBK)
> 0024.00              MONMSG     MSGID(CPF0000)
> 0025.00
> 0026.00              CPYF       FROMFILE(GPPTRPM)
TOFILE(QTEMP/GPPTRPMBK) 
> +
> 0027.00                           MBROPT(*REPLACE) CRTFILE(*YES) +
> 0028.00                           INCREL((*IF PMSTAT *EQ 'A'))
> 0029.00
> 0030.00              CLRPFM     FILE(GPPTRPM)
> 0031.00
> 0031.00
> 0032.00              CPYF       FROMFILE(QTEMP/GPPTRPMBK)
TOFILE(GPPTRPM) 
> +
> 0033.00                           MBROPT(*ADD)
> 0034.00
> 0035.00              DLCOBJ     OBJ((GPPTRPM *FILE *EXCL))
> 0036.00 END:
> 0037.00              ENDPGM
> 
> Message . . . . :   CPF3130 received by GP5903CP at 3000. (C D I R)
>  Cause . . . . . :   Control language (CL) program GP5903CP in library
> GP#LIBR
>    detected an error at statement number 3000. Message text for
CPF3130 
> is:
>    Member GPPTRPM already in use. 
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email:
MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/w@xxxxxxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/w@xxxxxxxxxxxxxxxx
> 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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.