Re: Question on CALLP use

Since you don't appear to be using threads, the answer is yes;
DOWNLOAD will wait until the procedure called (CRSDnld44R or
CRSDnld80R) returns before continuing.

What do you mean "update a record" "lock on the record"?

Since IFS files don't have records, I assume you mean the CRSDnldxxR
procedure update a record in a DB table and that it's a lock on the DB
record that is a problem.

Off the top of my head without seeing the procedures in question, I
could see a lock being a problem if the two procedures using
commitment control and are somehow being run in different activation
groups.

Otherwise, my guess is you're misdiagnosing the problem.

HTH,
Charles


On Tue, Apr 21, 2009 at 1:12 PM, Stephen Mooney
<Stephen_Mooney@xxxxxxxxxx> wrote:

I have an ILE program (DOWNLOAD) that performs an 'fgets' on an IFS file.

Depending upon the record type (first two positions of the above read
record), I move the entire contents of that line into a pre-defined data
structure and then callp a procedure with that line to update records.

Here is an example of the code DOWNLOAD:

We fget data into p_data and dow p_data < > *NULL

If RecType = '44';
  C44REC  = line;
  callp     CRSDnld44R(C44REC);
Endif;

If RecType  = '80';
  C80REC   = line;
  Record   = line;
  callp      CRSDnld80R(Record);
Endif;

We then fget data into p_data again followed by an enddo.

My question is, if the first condition is true, and we execute the callp
to CRSDnld44R, does the DOWNLOAD program wait until CRSDnld44R is finished
before it fgets the next IFS record, or does it continue to the point
where both CRSDnld44R and CRSDnld80R could be active at the same time?

The issue we seem to be having is that when CRSDnld80R runs, CRSDnld44R
has a lock on the record that 80 is trying to update.  Thanks for any
help.

Stephen M. Mooney
Application Development Manager
Rural/Metro Corporation
9221 E. Via de Ventura
Scottsdale, AZ 85258
480-606-3216
encryptme

-----------------------------------------
This communication may contain confidential and/or proprietary
information
and may not be disclosed to anyone other than the intended
addressee.
Any other disclosure is strictly prohibited by law.  If you are not
the
intended addressee, you have received this communication in error.
Please
notify the sender immediately and destroy the communication
including all
content and any attachments.  Thank you.
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.