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



Neil,

FRCRATIO only alters what data management does with the records once it gets
them. If the HLL is doing the buffering then the records haven't been passed
to data management yet so the frcratio won't help, I think.

We had a related problem yesterday under commitment control. Program A
called program B, program B added some records to a file and then returned
to program A w/o closing the file. Program A then called program B again,
and program B called program C. Program C tried to delete the records
program B had written. Program C failed on a record lock! Program B hadn't
flushed it's buffers so data management couldn't help. Forcing program B to
close it's files before exiting solved the problem. Of course it hurts
performance, but not as much as record locks. I hate HLL buffering!

-Walden

-----Original Message-----
From: owner-midrange-l@midrange.com
[mailto:owner-midrange-l@midrange.com]On Behalf Of Neil Palmer
Sent: Wednesday, May 20, 1998 4:43 PM
To: 'MIDRANGE-L@midrange.com'
Subject: RE: Lag time on Index file add?


Could be.  The writes may be buffered.  Check value for FRCRATIO.
By default it's probably buffering writes.  You may not really want to
change this to FRCRATIO(1) to force all writes immediately to disk, as I
believe is required for example for C-2 security, becase it will have a
negative performance impact.
I'm a little rusty on how you immediately see these added records in
other programs.  I know one trick we used to use in the 'old' days was
to make sure any other programs that referenced the file were defined to
add records to the file on the 'F' spec.  Even if the file was only used
for input.  This would force a check for added records in the buffer
instead of just checking to see if the record was on disk.  I supposed a
shared access path would give you the same capability.



Neil Palmer                                AS/400~~~~~
NxTrend Technology - Canada   ____________          ___  ~
Thornhill, Ontario,  Canada   |OOOOOOOOOO| ________  o|__||=
Phone: (905) 731-9000  x238   |__________|_|______|_|______)
Cell.: (416) 565-1682  x238    oo      oo   oo  oo   OOOo=o\
Fax:   (905) 731-9202       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mailto:NPalmer@NxTrend.com    AS/400  The Ultimate Business Server
http://www.NxTrend.com

> -----Original Message-----
> From: Tim Truax [SMTP:truax@usaor.net]
> Sent: Wednesday, May 20, 1998 3:51 PM
> To:   'Midrange-L Group - Email'
> Subject:      Lag time on Index file add?
>
> Hello All,
> Here's a quick question.
> 1. AS400 Physical File that holds multiple comments for an order#.
> The key to this file is (order#) + (3/0 seq#).
> 2. File has 1.7 million records in it.
> 3. File has ACCESS PATH MAINTENANCE(*IMMED) when I do a DSPFD.
> 4. Records are being added to this file and they do not actually end
> up at the end of the file until 5 - 8 minutes later.
> Is this normal?
> TIA
> Tim Truax
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


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.