RE: Record Lock on Read from IFS file?

If this is all residing on the same system why not just use the IFS APIs
to read through the directory & process vs using FTP?





From: "Scott Sanders" <scott@xxxxxxxxxxxxxxxxxx>
To: "'RPG programming on the IBM i / System i'"
<rpg400-l@xxxxxxxxxxxx>,
Date: 05/15/2012 01:19 PM
Subject: RE: Record Lock on Read from IFS file?
Sent by: rpg400-l-bounces@xxxxxxxxxxxx



Thank you, Scott. I will try to clarify...

On 5/14/2012 5:30 PM, Scott Sanders wrote:

The list of files is read into a user space, then each is opened and
read individually.

User space? I've never heard of listing files to a user space before.

This is from a service program library that I inherited. The same logic
is
in use elsewhere on this system and works OK. I have also used the
concept
of creating a native file, reading the directory contents and populating
this file, which is then read using native IO logic. In any case, all I
am
after is the list of file names.

If I call the second program separately, (after retrieving the files,
or copying them into the IFS directory manually), everything works

fine.

Records are read, the business logic is applied, the file is closed
and archived, then the next file is opened and processed.

When you say "call 2nd pgm separately", what do you mean by separately?
In other words, what is the state of the first program? Did it still
get run? If so, was it within the same job?

The second program is a stand-alone bound RPGLE program. It accepts a
parm
with the directory name, and will process whatever files are there. The
first program executes the FTP functions (FTP_LIST into an array, then
loop
through the array to retrieve the files with FTP_GET). The FTP session is
closed (FTP_QUIT), and then calls the second program. So, the first
program
is still in the stack when the issue occurs.

This has happened most often when the process is running in batch. In
that
case, I manually kill the program, then call the second program directly.
In that case, obviously, different jobs. But I have also had this happen
when running interactive. Again, I kill the job (SYS REQ, opt. 2), then I
can immediately call the second program and it runs fine.

When called from the first program, however, the process hangs on the
read of the first record. This is using the readf proc in QC2LE
binding directory. No error is logged.

readf?! I guess you could mean fread()...? Though, normally, RPGers
use the fopen, type APIs in order to gain the services of fgets().
It's
unusual to see RPGers calling fread(), since they'd usually use read()
if they didn't need it line-oriented. (That said... there's no reason
why you couldn't use fread... it's just not what I'm used to seeing.)

Sorry. It is using read() readf is the procedure referenced in the
service
program, but it is actually calling ExtProc('read')

It is similar to the condition I have seen when trying to read a
locked record, but without the ensuing "Unable to allocate a record"

error

that native IO would issue. Job status sits at TIMW, for as long as

I am

willing to wait.

Very strange. I've never encountered this issue.

I am somewhat gratified that I am not presenting an issue with an obvious
or
commonly known resolution. And, I must say, again, that I appreciate the
efforts to respond and assist.

When you open an IFS file with O_SHARE_NONE (or similar), and another
process tries to open it, it doesn't just "hang", but rather it
immediately returns an EBUSY error.

Stream files aren't organized into "records", so there's no concept of
a
record lock, but it's possible (though, extremely unusual) to lock a
range of bytes in a stream file. But, what would be locking them?
FTPAPI certainly doesn't do anything like that.

The symptom you describe sounds more like the symptom you'd get if it
were "blocking", as if waiting for a network connection. Seems strange
to get that if you're working with a local file system -- though, it
has
just occurred to me that you didn't actually say that you were using a
local file system. You just said "IFS". Can you give us details on
the
file system, et al, you're using in the IFS?

This is the local Integrated File System on this machine. Not sure what
other details I can describe.

Permissions? *PUBLIC has full authority.

Permissions wouldn't cause the process to 'hang'. They'd result in an
EACCESS error.

Agreed. Just thinking out loud, trying to eliminate possibilities.

Activation Group? First program is ActGrp(*New), the second one is
ActGrp(*Caller)

Not sure how actgrp relates to your question?

Again, just thinking out loud. And wondering if streamfile access is
affected by activation groups, at all.



I am going to try changing the call from program 1 (FTP) to program 2 (IFS
read and process) to be a separate submitted job. Should have an
opportunity to test that this afternoon.

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