Re: Record Lock on Read from IFS file?

Hi Scott,

Nice name, by the way :-)


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.

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?

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

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.

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?

Permissions? *PUBLIC has full authority.

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

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

Not sure how actgrp relates to your question?