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



Yes it waits. Call, Callb, Callp, they all are interactive single-threaded calls. Control will not return to the program until the call completes.

Sounds like CRSDnld44R isn't releasing a locked record.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Stephen Mooney
Sent: Tuesday, April 21, 2009 12:12 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Question on CALLP use

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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.