Problems with a logical file?

[brojoatt]

Hi.

I have a problem with a logical file.

In a program i acces to a logical file for "n" reads.

The first time i acces, the results delayed 10-15 seconds. The second time the results for the same query appairs immediatly.

If i try to do the same query for a terminal, the results delayed 10-15 secons. Then, i do in other terminal, with other user, and the results appair inmeditaly too.

I think i have a problem with the file, but i have *IMMED in the MAINT parameter of the logical file.

Some idea?

Thanks

PS: Sorry for my terrible english.

[tomholden]

Re: Problems with a logical file?

are you using SQL queries? if so then it's because the initial run is generating a temporary access path that is reused in the second run. also it's never a good idea to use the LF directly in your queries, use the PF instead.

[brojoatt]

Re: Problems with a logical file?

No, is a normal and simple logical file with 4 key fields. And i use setll and read.

[B.Hauser]

Re: Problems with a logical file?

Is DYNSLT specified within your logical file?

Birgitta

[brojoatt]

Re: Problems with a logical file?

No, there is no selection or omission fields in the file.

thks

[B.Hauser]

Re: Problems with a logical file?

I didn't talk about select/Omit it talked about the key word DYNSLT

Birgitta

[brojoatt]

Re: Problems with a logical file?

Sorry.

There is no de key word DYNSLT in the file, really ther is no one key word, only PFILE

This is the ALL source code for logical.

R RMCLIE PFILE(CLIENTS)

K CLPOS1
K CLPOS2
K CLAPEL

CLPOS1 is numeric 2,0. CLPOS2 is numeric 3,0 and CLAPEL is character 30

[MichaelCatalani]

Re: Problems with a logical file?

This sounds like the access path is set for delayed or rebuild. I would double check the file that's actually used by the job (library / file ) to ensure that specific file does not have something other than *immed in the maintenance parameter. I know you said you checked, but I would take a look at the job itself and make sure the file isnt being overridden.


You could also have a situation where a member for a file was removed, and part of the job process is to add the member back if it doesnt exist, hence the delay for the first job, and all other subsequent jobs have no delay.

Finally, his could be caused by the access pah becoming damaged, and the system has to rebuild the access path periodically. This would be a ptf issue.

When a job encounters a delay in dealing with the file, take a look at the job log to see if any errors or member additions are occurring.

[brojoatt]

Re: Problems with a logical file?

Thanks for tips.

I have test one more time the facts.

I look the library/file used in the job. This file has only 1 member (is our customer master file) and it is from 2 years ago. The MAINT parameter is *IMMED (at least 5 minuts ago )

The delay is not only in the first search in job, it is each time i do a new query. If you remember the DDS, is a logical by ZIP and NAME. WHen i search in first time 11111 - Smith, delay 10 seconds. Then, all searchs for 11111 - Smith from everybody delay 1 second. Then one user searchs 22222 - Jones, and delay 10 secons too. Then, all searchs for 22222 - Jones delay 1 second.

I know is a very strange case.

I am very grateful for all aids.

[B.Hauser]

Re: Problems with a logical file?

I'm confused: How do you access your logical file?
Native I/O, SQL, QUERY?

If you are using either SQL or QUERY NEVER specify a logical file, but use the phyiscal file (as Tom already pointed out).
If you are using either SQL or QUERY just execute a STRSQL (without any parameters) before running STRSQL or the Query/400.
After have a look at the job log. You'll see which access path was used or if an additional access path was adviced.
... and even better is to analyze the SQL with iSeries Navigator - Database --> Run an SQL Script --> Visual Explain.

SQL and Query/400 may create and open a NEW ODP (Open Data Path) for each query.

Birgitta

[brojoatt]

Re: Problems with a logical file?

Sorry, between my English and my problem, i explain like a closed book.

I access with a RPGLE program. It uses SETLL and READ. It reads thousand record (more or less). The first time takes 10-15 seconds and then, it takes less than 1 second, from other terminals and users too, for the same search.

I use "query" in my answers like "a search", no like a instruction.

[tomholden]

Re: Problems with a logical file?

does the program seton LR or close the file? if not then the additional time could be due to the opening of the files, on the second call the ODP is already established and the files are already opened.

[MichaelCatalani]

Re: Problems with a logical file?

I want to clear something up, just so we can head down the correct path:

You are saying that if you go to terminal A and key in a search, it takes 10 seconds. Then, if you perform the same search, it only takes about 1 second. And then if you go to terminal B, the same search also takes 1 second. But anytime a different search is performed, it takes 10 seconds, no matter what terminal you are working from.

Thats how I have read what you said. I'm just making sure I understood that to be correct.


Also, I'm assuming that the program is dealing directly with a file local to the system, and also that a file override is not in place.

[brojoatt]

Re: Problems with a logical file?

YES, Michael.

And the search is with an RPGLE program, using SETLL and READ. There is not OVRDBF, it's a file locate in the same system.

Finally someone can explain better than me

[Mercury]

Re: Problems with a logical file?

Please paste the relevant part of the program using this file along with the DDS of the implied LF.