Re: Issue in DLTF command after RCVF.

CLRPFM requires the same lock as DLTF..
I would try this:
Call a clp that calls your clp with the rcvf, pass a parm back to
the 1st clp if ok to delete the file. This way the 2nd clp is no longer
executing and has released the file lock.
jim
----- Original Message ----- 
From: "Booth Martin" <booth@xxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Friday, March 04, 2005 7:38 AM
Subject: Re: Issue in DLTF command after RCVF.


Have you tried the CLOF command?  As an aside: do you really want to delete
it?  or just clear it.

---------------------------------
Booth Martin
http://www.martinvt.com
---------------------------------
-------Original Message-------

From: Midrange Systems Technical Discussion
Date: 03/04/05 06:15:07
To: MIDRANGE-L@xxxxxxxxxxxx
Subject: Issue in DLTF command after RCVF.

In a CL program, i am using the RCVF command  to read the first record of a
PF which is having tons of records.
After this,  DLTF command is issued to delete the file but the system is not
allowing to do so because the system will make an exclusive lock on the file
when RCVF command is executed.
An error message specifying that the file is still in use is displayed. Is
it possible to unlock this file before DLTF command so that it could be
deleted?

It is found that if all the records of the file is read, then DLTF command
will be executed normally (i.e., the file will be deleted). but tehr
euirement is not to read the tons of record before deleting teh file,

Is there any solution to delete the file than by reading all the records in
the file in one shot.

Share your thoughts...



Regards

Siva.


-- 
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.