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



You have conclusivly ruled out a library list problem?

I am curious: what happens if you change the record instead of deleting it? That wouild at least confirm where the problem is. (If the update works then we know we are dealing in the right place, if not, the issue is in another area.)

Dick Superneau wrote:
Yes it is.  When I looked at the journal, I can see the entries for
adding the record, the forcing of the data to auxiliary storage, some
open and closes from other procedures, the deletion and forcing of the
data again, some more open and closes.  The record is still being
"found" by one of the procedures after the deletion, causing the program
to error out.  I know I can monitor for the error, but that doesn't
explain why it is happening.  Monitoring will only mask the problem.

Help, Dick

message: 2
date: Mon, 11 Sep 2006 12:56:09 -0500
from: "Holden Tommy" <Tommy.Holden@xxxxxxxxxxxxxxxxx>
subject: RE: Deleted record still seen

Is this running under commitment control???
Thanks,
Tommy Holden


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Dick Superneau
Sent: Monday, September 11, 2006 12:54 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: Deleted record still seen

I have tried changing  the FRCRATIO value and using the FEOD opcode.
During a program run with debug, I used dsppfm on the file prior to and
after each module call.  The file did or did not show the record
correctly in comparison to the logic of the program.  The modules used
are coded to not allow more than one ODP to the file at a time.
However, the individual modules are still finding a record even when the
dsppfm at use of the open opcode on the file does not show a record.
The manual says to override the file with SEQONLY(*NO) in order to
complete processing the record being used.  That did not work even with
changing the scoping from activation group to job.  I am assuming at
this point that the internal data management buffer is still containing
that record for that file.  I do not know of any way to see the buffer
during debug.  Any suggestions?

Thanks, Dick

message: 7
date: Fri, 8 Sep 2006 09:34:18 -0500
from: "Holden Tommy" <Tommy.Holden@xxxxxxxxxxxxxxxxx>
subject: RE: Deleted record still seen

Another option to the FRCRATIO (which incidentally I prefer for this..)
is using the FEOD opcode after the write/update/delete opcode.  That way
it doesn't affect ALL programs using the file...simply the one program
in question.
Thanks,
Tommy Holden


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Bath, Martin
Sent: Friday, September 08, 2006 2:42 AM
To: 'rpg400-l@xxxxxxxxxxxx'
Subject: Re: Deleted record still seen

Hi Dick

I've seen similar behaviour on files, which for reasons I could not
deduce,
required the FRCRATIO value set to 1 on the CHGPF command. (Default is
*NONE)


Regards

Regards

Martin Bath
Global IT Group
Invensys Controls

message: 1
date: Wed, 6 Sep 2006 16:40:29 -0600
from: "Dick Superneau" <DSuperneau@xxxxxxxxxxxxxxxxxx>
subject: Deleted record still seen

I am looking for some help with two similar procedures that behave
differently.  I have a program that uses procedures to perform the file
updates that are requested by the user.  During a loop through the
program, the user can request a record to be deleted.  This deletion can
then cause a record from another file to also be deleted.  When I use
debug to walk through the program, I can stop the program at the point
right after both deletions have occurred.  At this point, I do not see
the records in the files.  The program returns to the top of the loop
and calls two similar procedures to renumber the sequence fields in the
two files.  When the first procedure is called, nothing happens as the
parameters that are passed in do not match any record in the file.  When
the second procedure is called however, a record is found on the read
statement- the one that was deleted.  Since there is no such record, the
update causes the program to crash.  The procedures are in a service
program that has *CALLER as the activation group.  Each of the
procedures has usropn specified for the file that is being used.  The
first called procedure treats the file correctly and does not see the
deleted record, but the second procedure seems to think there is a
record in the second file even though it has been deleted.

The two files are input only files in the calling program.  I have
thought that there might be a snapshot of the second file created when
the program opens and this is why the program thinks there is still a
record in the file because the view of the file has not been refreshed.
However, it doesn't explain why the similar snapshot of the first file
doesn't behave in the same manner.  I hope this makes sense.  Any help
will be appreciated.
Thanks, Dick



Regards

Martin Bath
Global IT Group
Invensys Controls Tel: +44 (0) 1752 724388
Mobile: +44 (0) 7736 017318
Fax :    +44 (0) 1752 732455
 **** PLEASE NOTE NEW EMAIL ADDRESS  ****
Email : martin.bath@xxxxxxxxxxxxxxxxxxxx
***********************************************************







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 copyright@midrange.com.

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.