Skip to main content

[archive] Unkown file status error problem

  • June 11, 2009
  • 14 replies
  • 1 view
D

[Migrated content. Thread originally posted on 11 June 2009]

We are getting a weird situation with a file access every now and then and have been tearing our hair out trying to find it. Essentially we have copy libraries which we use to access files so that this is done in a consitent manner. The relevant code is as follows:-

select detd08 assign disk-d08
organization indexed
access dynamic
lock mode manual
record key d08-key
file status is d08-status.

03 disk-d08 pic x(20) value "detd08".
03 d08-status value "00".
05 d08-status-1 pic x.
05 d08-status-2 pic x.
01 access-status pic 9.
88 access-ok value zero.
88 eof value 1.
88 invalid-key value 2.
88 rectyp-error value 3.
88 record-locked value 4.
88 unknown-error value 5.

read-detd08.
move zero to access-status.
read detd08 invalid
move 2 to access-status
end-read.
if access-ok
and d08-status = 99
move 4 to access-status
if lock-retry
move d08-key to s10-key
move "detd08" to s01-error-file
perform lock-wait
go to read-detd08
end-if
end-if.
if access-ok
and d08-status-1 not = 0
move 5 to access-status
end-if.
if not access-ok
move 1 to access-type
perform d08-err
end-if.
*
d08-err.
move "detd08" to s41-file s01-error-file.
move d08-key to s41-record s10-key.
move 5 to s01-no-bytes.
move d08-status to common-status.

The result of this is that sometimes (don't know when) the code that checks for the first status byte being non-zero is triggered, this performs d08-err and results in our system trying to log the error. The logging routine tells us that we have an access-status of 5, but a common-status of "00". How can this be? As an extra piece of information, the logging routine attempts to write this information to a file, which also suffers the same problem, i.e. access-status = 5 but file-status = "00". It smells like some sort of "out of resource" problem but we are completely at a loss. Has anyone any ideas PLEASE?? We have use statements in the declaratives section which should make this check on status byte 1 irrelevant, but the use code is not being triggered.:confused:

    14 replies

    D

    [Migrated content. Thread originally posted on 11 June 2009]

    We are getting a weird situation with a file access every now and then and have been tearing our hair out trying to find it. Essentially we have copy libraries which we use to access files so that this is done in a consitent manner. The relevant code is as follows:-

    select detd08 assign disk-d08
    organization indexed
    access dynamic
    lock mode manual
    record key d08-key
    file status is d08-status.

    03 disk-d08 pic x(20) value "detd08".
    03 d08-status value "00".
    05 d08-status-1 pic x.
    05 d08-status-2 pic x.
    01 access-status pic 9.
    88 access-ok value zero.
    88 eof value 1.
    88 invalid-key value 2.
    88 rectyp-error value 3.
    88 record-locked value 4.
    88 unknown-error value 5.

    read-detd08.
    move zero to access-status.
    read detd08 invalid
    move 2 to access-status
    end-read.
    if access-ok
    and d08-status = 99
    move 4 to access-status
    if lock-retry
    move d08-key to s10-key
    move "detd08" to s01-error-file
    perform lock-wait
    go to read-detd08
    end-if
    end-if.
    if access-ok
    and d08-status-1 not = 0
    move 5 to access-status
    end-if.
    if not access-ok
    move 1 to access-type
    perform d08-err
    end-if.
    *
    d08-err.
    move "detd08" to s41-file s01-error-file.
    move d08-key to s41-record s10-key.
    move 5 to s01-no-bytes.
    move d08-status to common-status.

    The result of this is that sometimes (don't know when) the code that checks for the first status byte being non-zero is triggered, this performs d08-err and results in our system trying to log the error. The logging routine tells us that we have an access-status of 5, but a common-status of "00". How can this be? As an extra piece of information, the logging routine attempts to write this information to a file, which also suffers the same problem, i.e. access-status = 5 but file-status = "00". It smells like some sort of "out of resource" problem but we are completely at a loss. Has anyone any ideas PLEASE?? We have use statements in the declaratives section which should make this check on status byte 1 irrelevant, but the use code is not being triggered.:confused:
    From the code, it does not show when or how d08-status-1 is set. Your if condition tests d08-status-1 so it is unclear when values are moved there.
    D

    [Migrated content. Thread originally posted on 11 June 2009]

    We are getting a weird situation with a file access every now and then and have been tearing our hair out trying to find it. Essentially we have copy libraries which we use to access files so that this is done in a consitent manner. The relevant code is as follows:-

    select detd08 assign disk-d08
    organization indexed
    access dynamic
    lock mode manual
    record key d08-key
    file status is d08-status.

    03 disk-d08 pic x(20) value "detd08".
    03 d08-status value "00".
    05 d08-status-1 pic x.
    05 d08-status-2 pic x.
    01 access-status pic 9.
    88 access-ok value zero.
    88 eof value 1.
    88 invalid-key value 2.
    88 rectyp-error value 3.
    88 record-locked value 4.
    88 unknown-error value 5.

    read-detd08.
    move zero to access-status.
    read detd08 invalid
    move 2 to access-status
    end-read.
    if access-ok
    and d08-status = 99
    move 4 to access-status
    if lock-retry
    move d08-key to s10-key
    move "detd08" to s01-error-file
    perform lock-wait
    go to read-detd08
    end-if
    end-if.
    if access-ok
    and d08-status-1 not = 0
    move 5 to access-status
    end-if.
    if not access-ok
    move 1 to access-type
    perform d08-err
    end-if.
    *
    d08-err.
    move "detd08" to s41-file s01-error-file.
    move d08-key to s41-record s10-key.
    move 5 to s01-no-bytes.
    move d08-status to common-status.

    The result of this is that sometimes (don't know when) the code that checks for the first status byte being non-zero is triggered, this performs d08-err and results in our system trying to log the error. The logging routine tells us that we have an access-status of 5, but a common-status of "00". How can this be? As an extra piece of information, the logging routine attempts to write this information to a file, which also suffers the same problem, i.e. access-status = 5 but file-status = "00". It smells like some sort of "out of resource" problem but we are completely at a loss. Has anyone any ideas PLEASE?? We have use statements in the declaratives section which should make this check on status byte 1 irrelevant, but the use code is not being triggered.:confused:
    From the code, it does not show when or how d08-status-1 is set. Your if condition tests d08-status-1 so it is unclear when values are moved there.
    D

    [Migrated content. Thread originally posted on 11 June 2009]

    We are getting a weird situation with a file access every now and then and have been tearing our hair out trying to find it. Essentially we have copy libraries which we use to access files so that this is done in a consitent manner. The relevant code is as follows:-

    select detd08 assign disk-d08
    organization indexed
    access dynamic
    lock mode manual
    record key d08-key
    file status is d08-status.

    03 disk-d08 pic x(20) value "detd08".
    03 d08-status value "00".
    05 d08-status-1 pic x.
    05 d08-status-2 pic x.
    01 access-status pic 9.
    88 access-ok value zero.
    88 eof value 1.
    88 invalid-key value 2.
    88 rectyp-error value 3.
    88 record-locked value 4.
    88 unknown-error value 5.

    read-detd08.
    move zero to access-status.
    read detd08 invalid
    move 2 to access-status
    end-read.
    if access-ok
    and d08-status = 99
    move 4 to access-status
    if lock-retry
    move d08-key to s10-key
    move "detd08" to s01-error-file
    perform lock-wait
    go to read-detd08
    end-if
    end-if.
    if access-ok
    and d08-status-1 not = 0
    move 5 to access-status
    end-if.
    if not access-ok
    move 1 to access-type
    perform d08-err
    end-if.
    *
    d08-err.
    move "detd08" to s41-file s01-error-file.
    move d08-key to s41-record s10-key.
    move 5 to s01-no-bytes.
    move d08-status to common-status.

    The result of this is that sometimes (don't know when) the code that checks for the first status byte being non-zero is triggered, this performs d08-err and results in our system trying to log the error. The logging routine tells us that we have an access-status of 5, but a common-status of "00". How can this be? As an extra piece of information, the logging routine attempts to write this information to a file, which also suffers the same problem, i.e. access-status = 5 but file-status = "00". It smells like some sort of "out of resource" problem but we are completely at a loss. Has anyone any ideas PLEASE?? We have use statements in the declaratives section which should make this check on status byte 1 irrelevant, but the use code is not being triggered.:confused:
    From the code, it does not show when or how d08-status-1 is set. Your if condition tests d08-status-1 so it is unclear when values are moved there.
    D

    [Migrated content. Thread originally posted on 11 June 2009]

    We are getting a weird situation with a file access every now and then and have been tearing our hair out trying to find it. Essentially we have copy libraries which we use to access files so that this is done in a consitent manner. The relevant code is as follows:-

    select detd08 assign disk-d08
    organization indexed
    access dynamic
    lock mode manual
    record key d08-key
    file status is d08-status.

    03 disk-d08 pic x(20) value "detd08".
    03 d08-status value "00".
    05 d08-status-1 pic x.
    05 d08-status-2 pic x.
    01 access-status pic 9.
    88 access-ok value zero.
    88 eof value 1.
    88 invalid-key value 2.
    88 rectyp-error value 3.
    88 record-locked value 4.
    88 unknown-error value 5.

    read-detd08.
    move zero to access-status.
    read detd08 invalid
    move 2 to access-status
    end-read.
    if access-ok
    and d08-status = 99
    move 4 to access-status
    if lock-retry
    move d08-key to s10-key
    move "detd08" to s01-error-file
    perform lock-wait
    go to read-detd08
    end-if
    end-if.
    if access-ok
    and d08-status-1 not = 0
    move 5 to access-status
    end-if.
    if not access-ok
    move 1 to access-type
    perform d08-err
    end-if.
    *
    d08-err.
    move "detd08" to s41-file s01-error-file.
    move d08-key to s41-record s10-key.
    move 5 to s01-no-bytes.
    move d08-status to common-status.

    The result of this is that sometimes (don't know when) the code that checks for the first status byte being non-zero is triggered, this performs d08-err and results in our system trying to log the error. The logging routine tells us that we have an access-status of 5, but a common-status of "00". How can this be? As an extra piece of information, the logging routine attempts to write this information to a file, which also suffers the same problem, i.e. access-status = 5 but file-status = "00". It smells like some sort of "out of resource" problem but we are completely at a loss. Has anyone any ideas PLEASE?? We have use statements in the declaratives section which should make this check on status byte 1 irrelevant, but the use code is not being triggered.:confused:
    d08-status is the status for the file and is therefore set by acucobol when the file is read. That is the point. Acucobol seems to be setting d08-status-1 (first byte) to non-zero but my reporting shows it is 0. A paradox which is what has me baffled
    D

    [Migrated content. Thread originally posted on 11 June 2009]

    We are getting a weird situation with a file access every now and then and have been tearing our hair out trying to find it. Essentially we have copy libraries which we use to access files so that this is done in a consitent manner. The relevant code is as follows:-

    select detd08 assign disk-d08
    organization indexed
    access dynamic
    lock mode manual
    record key d08-key
    file status is d08-status.

    03 disk-d08 pic x(20) value "detd08".
    03 d08-status value "00".
    05 d08-status-1 pic x.
    05 d08-status-2 pic x.
    01 access-status pic 9.
    88 access-ok value zero.
    88 eof value 1.
    88 invalid-key value 2.
    88 rectyp-error value 3.
    88 record-locked value 4.
    88 unknown-error value 5.

    read-detd08.
    move zero to access-status.
    read detd08 invalid
    move 2 to access-status
    end-read.
    if access-ok
    and d08-status = 99
    move 4 to access-status
    if lock-retry
    move d08-key to s10-key
    move "detd08" to s01-error-file
    perform lock-wait
    go to read-detd08
    end-if
    end-if.
    if access-ok
    and d08-status-1 not = 0
    move 5 to access-status
    end-if.
    if not access-ok
    move 1 to access-type
    perform d08-err
    end-if.
    *
    d08-err.
    move "detd08" to s41-file s01-error-file.
    move d08-key to s41-record s10-key.
    move 5 to s01-no-bytes.
    move d08-status to common-status.

    The result of this is that sometimes (don't know when) the code that checks for the first status byte being non-zero is triggered, this performs d08-err and results in our system trying to log the error. The logging routine tells us that we have an access-status of 5, but a common-status of "00". How can this be? As an extra piece of information, the logging routine attempts to write this information to a file, which also suffers the same problem, i.e. access-status = 5 but file-status = "00". It smells like some sort of "out of resource" problem but we are completely at a loss. Has anyone any ideas PLEASE?? We have use statements in the declaratives section which should make this check on status byte 1 irrelevant, but the use code is not being triggered.:confused:
    Is d08-status-1 initialized somewhere? Or initialized through a compiler switch?
    D

    [Migrated content. Thread originally posted on 11 June 2009]

    We are getting a weird situation with a file access every now and then and have been tearing our hair out trying to find it. Essentially we have copy libraries which we use to access files so that this is done in a consitent manner. The relevant code is as follows:-

    select detd08 assign disk-d08
    organization indexed
    access dynamic
    lock mode manual
    record key d08-key
    file status is d08-status.

    03 disk-d08 pic x(20) value "detd08".
    03 d08-status value "00".
    05 d08-status-1 pic x.
    05 d08-status-2 pic x.
    01 access-status pic 9.
    88 access-ok value zero.
    88 eof value 1.
    88 invalid-key value 2.
    88 rectyp-error value 3.
    88 record-locked value 4.
    88 unknown-error value 5.

    read-detd08.
    move zero to access-status.
    read detd08 invalid
    move 2 to access-status
    end-read.
    if access-ok
    and d08-status = 99
    move 4 to access-status
    if lock-retry
    move d08-key to s10-key
    move "detd08" to s01-error-file
    perform lock-wait
    go to read-detd08
    end-if
    end-if.
    if access-ok
    and d08-status-1 not = 0
    move 5 to access-status
    end-if.
    if not access-ok
    move 1 to access-type
    perform d08-err
    end-if.
    *
    d08-err.
    move "detd08" to s41-file s01-error-file.
    move d08-key to s41-record s10-key.
    move 5 to s01-no-bytes.
    move d08-status to common-status.

    The result of this is that sometimes (don't know when) the code that checks for the first status byte being non-zero is triggered, this performs d08-err and results in our system trying to log the error. The logging routine tells us that we have an access-status of 5, but a common-status of "00". How can this be? As an extra piece of information, the logging routine attempts to write this information to a file, which also suffers the same problem, i.e. access-status = 5 but file-status = "00". It smells like some sort of "out of resource" problem but we are completely at a loss. Has anyone any ideas PLEASE?? We have use statements in the declaratives section which should make this check on status byte 1 irrelevant, but the use code is not being triggered.:confused:
    Is d08-status-1 initialized somewhere? Or initialized through a compiler switch?
    D

    [Migrated content. Thread originally posted on 11 June 2009]

    We are getting a weird situation with a file access every now and then and have been tearing our hair out trying to find it. Essentially we have copy libraries which we use to access files so that this is done in a consitent manner. The relevant code is as follows:-

    select detd08 assign disk-d08
    organization indexed
    access dynamic
    lock mode manual
    record key d08-key
    file status is d08-status.

    03 disk-d08 pic x(20) value "detd08".
    03 d08-status value "00".
    05 d08-status-1 pic x.
    05 d08-status-2 pic x.
    01 access-status pic 9.
    88 access-ok value zero.
    88 eof value 1.
    88 invalid-key value 2.
    88 rectyp-error value 3.
    88 record-locked value 4.
    88 unknown-error value 5.

    read-detd08.
    move zero to access-status.
    read detd08 invalid
    move 2 to access-status
    end-read.
    if access-ok
    and d08-status = 99
    move 4 to access-status
    if lock-retry
    move d08-key to s10-key
    move "detd08" to s01-error-file
    perform lock-wait
    go to read-detd08
    end-if
    end-if.
    if access-ok
    and d08-status-1 not = 0
    move 5 to access-status
    end-if.
    if not access-ok
    move 1 to access-type
    perform d08-err
    end-if.
    *
    d08-err.
    move "detd08" to s41-file s01-error-file.
    move d08-key to s41-record s10-key.
    move 5 to s01-no-bytes.
    move d08-status to common-status.

    The result of this is that sometimes (don't know when) the code that checks for the first status byte being non-zero is triggered, this performs d08-err and results in our system trying to log the error. The logging routine tells us that we have an access-status of 5, but a common-status of "00". How can this be? As an extra piece of information, the logging routine attempts to write this information to a file, which also suffers the same problem, i.e. access-status = 5 but file-status = "00". It smells like some sort of "out of resource" problem but we are completely at a loss. Has anyone any ideas PLEASE?? We have use statements in the declaratives section which should make this check on status byte 1 irrelevant, but the use code is not being triggered.:confused:
    Is d08-status-1 initialized somewhere? Or initialized through a compiler switch?
    D

    [Migrated content. Thread originally posted on 11 June 2009]

    We are getting a weird situation with a file access every now and then and have been tearing our hair out trying to find it. Essentially we have copy libraries which we use to access files so that this is done in a consitent manner. The relevant code is as follows:-

    select detd08 assign disk-d08
    organization indexed
    access dynamic
    lock mode manual
    record key d08-key
    file status is d08-status.

    03 disk-d08 pic x(20) value "detd08".
    03 d08-status value "00".
    05 d08-status-1 pic x.
    05 d08-status-2 pic x.
    01 access-status pic 9.
    88 access-ok value zero.
    88 eof value 1.
    88 invalid-key value 2.
    88 rectyp-error value 3.
    88 record-locked value 4.
    88 unknown-error value 5.

    read-detd08.
    move zero to access-status.
    read detd08 invalid
    move 2 to access-status
    end-read.
    if access-ok
    and d08-status = 99
    move 4 to access-status
    if lock-retry
    move d08-key to s10-key
    move "detd08" to s01-error-file
    perform lock-wait
    go to read-detd08
    end-if
    end-if.
    if access-ok
    and d08-status-1 not = 0
    move 5 to access-status
    end-if.
    if not access-ok
    move 1 to access-type
    perform d08-err
    end-if.
    *
    d08-err.
    move "detd08" to s41-file s01-error-file.
    move d08-key to s41-record s10-key.
    move 5 to s01-no-bytes.
    move d08-status to common-status.

    The result of this is that sometimes (don't know when) the code that checks for the first status byte being non-zero is triggered, this performs d08-err and results in our system trying to log the error. The logging routine tells us that we have an access-status of 5, but a common-status of "00". How can this be? As an extra piece of information, the logging routine attempts to write this information to a file, which also suffers the same problem, i.e. access-status = 5 but file-status = "00". It smells like some sort of "out of resource" problem but we are completely at a loss. Has anyone any ideas PLEASE?? We have use statements in the declaratives section which should make this check on status byte 1 irrelevant, but the use code is not being triggered.:confused:
    d08-status is initialized by the run time system before the i-o is performed (I assume) as it is the file status item for the file detd08. It also has a value clause of "00" in its definition in working storage. Many reads of the file take place within the program before this situation occurs, which is why it smells like a resouce type of problem to me
    D

    [Migrated content. Thread originally posted on 11 June 2009]

    We are getting a weird situation with a file access every now and then and have been tearing our hair out trying to find it. Essentially we have copy libraries which we use to access files so that this is done in a consitent manner. The relevant code is as follows:-

    select detd08 assign disk-d08
    organization indexed
    access dynamic
    lock mode manual
    record key d08-key
    file status is d08-status.

    03 disk-d08 pic x(20) value "detd08".
    03 d08-status value "00".
    05 d08-status-1 pic x.
    05 d08-status-2 pic x.
    01 access-status pic 9.
    88 access-ok value zero.
    88 eof value 1.
    88 invalid-key value 2.
    88 rectyp-error value 3.
    88 record-locked value 4.
    88 unknown-error value 5.

    read-detd08.
    move zero to access-status.
    read detd08 invalid
    move 2 to access-status
    end-read.
    if access-ok
    and d08-status = 99
    move 4 to access-status
    if lock-retry
    move d08-key to s10-key
    move "detd08" to s01-error-file
    perform lock-wait
    go to read-detd08
    end-if
    end-if.
    if access-ok
    and d08-status-1 not = 0
    move 5 to access-status
    end-if.
    if not access-ok
    move 1 to access-type
    perform d08-err
    end-if.
    *
    d08-err.
    move "detd08" to s41-file s01-error-file.
    move d08-key to s41-record s10-key.
    move 5 to s01-no-bytes.
    move d08-status to common-status.

    The result of this is that sometimes (don't know when) the code that checks for the first status byte being non-zero is triggered, this performs d08-err and results in our system trying to log the error. The logging routine tells us that we have an access-status of 5, but a common-status of "00". How can this be? As an extra piece of information, the logging routine attempts to write this information to a file, which also suffers the same problem, i.e. access-status = 5 but file-status = "00". It smells like some sort of "out of resource" problem but we are completely at a loss. Has anyone any ideas PLEASE?? We have use statements in the declaratives section which should make this check on status byte 1 irrelevant, but the use code is not being triggered.:confused:
    d08-status is initialized by the run time system before the i-o is performed (I assume) as it is the file status item for the file detd08. It also has a value clause of "00" in its definition in working storage. Many reads of the file take place within the program before this situation occurs, which is why it smells like a resouce type of problem to me
    D

    [Migrated content. Thread originally posted on 11 June 2009]

    We are getting a weird situation with a file access every now and then and have been tearing our hair out trying to find it. Essentially we have copy libraries which we use to access files so that this is done in a consitent manner. The relevant code is as follows:-

    select detd08 assign disk-d08
    organization indexed
    access dynamic
    lock mode manual
    record key d08-key
    file status is d08-status.

    03 disk-d08 pic x(20) value "detd08".
    03 d08-status value "00".
    05 d08-status-1 pic x.
    05 d08-status-2 pic x.
    01 access-status pic 9.
    88 access-ok value zero.
    88 eof value 1.
    88 invalid-key value 2.
    88 rectyp-error value 3.
    88 record-locked value 4.
    88 unknown-error value 5.

    read-detd08.
    move zero to access-status.
    read detd08 invalid
    move 2 to access-status
    end-read.
    if access-ok
    and d08-status = 99
    move 4 to access-status
    if lock-retry
    move d08-key to s10-key
    move "detd08" to s01-error-file
    perform lock-wait
    go to read-detd08
    end-if
    end-if.
    if access-ok
    and d08-status-1 not = 0
    move 5 to access-status
    end-if.
    if not access-ok
    move 1 to access-type
    perform d08-err
    end-if.
    *
    d08-err.
    move "detd08" to s41-file s01-error-file.
    move d08-key to s41-record s10-key.
    move 5 to s01-no-bytes.
    move d08-status to common-status.

    The result of this is that sometimes (don't know when) the code that checks for the first status byte being non-zero is triggered, this performs d08-err and results in our system trying to log the error. The logging routine tells us that we have an access-status of 5, but a common-status of "00". How can this be? As an extra piece of information, the logging routine attempts to write this information to a file, which also suffers the same problem, i.e. access-status = 5 but file-status = "00". It smells like some sort of "out of resource" problem but we are completely at a loss. Has anyone any ideas PLEASE?? We have use statements in the declaratives section which should make this check on status byte 1 irrelevant, but the use code is not being triggered.:confused:
    d08-status is initialized by the run time system before the i-o is performed (I assume) as it is the file status item for the file detd08. It also has a value clause of "00" in its definition in working storage. Many reads of the file take place within the program before this situation occurs, which is why it smells like a resouce type of problem to me
    D

    [Migrated content. Thread originally posted on 11 June 2009]

    We are getting a weird situation with a file access every now and then and have been tearing our hair out trying to find it. Essentially we have copy libraries which we use to access files so that this is done in a consitent manner. The relevant code is as follows:-

    select detd08 assign disk-d08
    organization indexed
    access dynamic
    lock mode manual
    record key d08-key
    file status is d08-status.

    03 disk-d08 pic x(20) value "detd08".
    03 d08-status value "00".
    05 d08-status-1 pic x.
    05 d08-status-2 pic x.
    01 access-status pic 9.
    88 access-ok value zero.
    88 eof value 1.
    88 invalid-key value 2.
    88 rectyp-error value 3.
    88 record-locked value 4.
    88 unknown-error value 5.

    read-detd08.
    move zero to access-status.
    read detd08 invalid
    move 2 to access-status
    end-read.
    if access-ok
    and d08-status = 99
    move 4 to access-status
    if lock-retry
    move d08-key to s10-key
    move "detd08" to s01-error-file
    perform lock-wait
    go to read-detd08
    end-if
    end-if.
    if access-ok
    and d08-status-1 not = 0
    move 5 to access-status
    end-if.
    if not access-ok
    move 1 to access-type
    perform d08-err
    end-if.
    *
    d08-err.
    move "detd08" to s41-file s01-error-file.
    move d08-key to s41-record s10-key.
    move 5 to s01-no-bytes.
    move d08-status to common-status.

    The result of this is that sometimes (don't know when) the code that checks for the first status byte being non-zero is triggered, this performs d08-err and results in our system trying to log the error. The logging routine tells us that we have an access-status of 5, but a common-status of "00". How can this be? As an extra piece of information, the logging routine attempts to write this information to a file, which also suffers the same problem, i.e. access-status = 5 but file-status = "00". It smells like some sort of "out of resource" problem but we are completely at a loss. Has anyone any ideas PLEASE?? We have use statements in the declaratives section which should make this check on status byte 1 irrelevant, but the use code is not being triggered.:confused:
    Maybe I'm missing it, but what happens when your program gets a file status 10 (end of file) or a file status 23 (record not found) or any other file status that does not have a leading zero.
    D

    [Migrated content. Thread originally posted on 11 June 2009]

    We are getting a weird situation with a file access every now and then and have been tearing our hair out trying to find it. Essentially we have copy libraries which we use to access files so that this is done in a consitent manner. The relevant code is as follows:-

    select detd08 assign disk-d08
    organization indexed
    access dynamic
    lock mode manual
    record key d08-key
    file status is d08-status.

    03 disk-d08 pic x(20) value "detd08".
    03 d08-status value "00".
    05 d08-status-1 pic x.
    05 d08-status-2 pic x.
    01 access-status pic 9.
    88 access-ok value zero.
    88 eof value 1.
    88 invalid-key value 2.
    88 rectyp-error value 3.
    88 record-locked value 4.
    88 unknown-error value 5.

    read-detd08.
    move zero to access-status.
    read detd08 invalid
    move 2 to access-status
    end-read.
    if access-ok
    and d08-status = 99
    move 4 to access-status
    if lock-retry
    move d08-key to s10-key
    move "detd08" to s01-error-file
    perform lock-wait
    go to read-detd08
    end-if
    end-if.
    if access-ok
    and d08-status-1 not = 0
    move 5 to access-status
    end-if.
    if not access-ok
    move 1 to access-type
    perform d08-err
    end-if.
    *
    d08-err.
    move "detd08" to s41-file s01-error-file.
    move d08-key to s41-record s10-key.
    move 5 to s01-no-bytes.
    move d08-status to common-status.

    The result of this is that sometimes (don't know when) the code that checks for the first status byte being non-zero is triggered, this performs d08-err and results in our system trying to log the error. The logging routine tells us that we have an access-status of 5, but a common-status of "00". How can this be? As an extra piece of information, the logging routine attempts to write this information to a file, which also suffers the same problem, i.e. access-status = 5 but file-status = "00". It smells like some sort of "out of resource" problem but we are completely at a loss. Has anyone any ideas PLEASE?? We have use statements in the declaratives section which should make this check on status byte 1 irrelevant, but the use code is not being triggered.:confused:
    If any normal file status is returned such as 10 or 23 then the code that called the "read-detd08" routine deals with it correctly. If it is expected then the code caters for it. If it is not expected then the error logging routine works perfectly and logs the error as it should.

    I have now switched on acu_dump in the hope of being able to track down what is happening by forcing a "subscript out of range" when the condition occurs. This in itself has presented another problem in that the dump file does not finish being written and I am now investigating this. One thing just leads to another eh?
    D

    [Migrated content. Thread originally posted on 11 June 2009]

    We are getting a weird situation with a file access every now and then and have been tearing our hair out trying to find it. Essentially we have copy libraries which we use to access files so that this is done in a consitent manner. The relevant code is as follows:-

    select detd08 assign disk-d08
    organization indexed
    access dynamic
    lock mode manual
    record key d08-key
    file status is d08-status.

    03 disk-d08 pic x(20) value "detd08".
    03 d08-status value "00".
    05 d08-status-1 pic x.
    05 d08-status-2 pic x.
    01 access-status pic 9.
    88 access-ok value zero.
    88 eof value 1.
    88 invalid-key value 2.
    88 rectyp-error value 3.
    88 record-locked value 4.
    88 unknown-error value 5.

    read-detd08.
    move zero to access-status.
    read detd08 invalid
    move 2 to access-status
    end-read.
    if access-ok
    and d08-status = 99
    move 4 to access-status
    if lock-retry
    move d08-key to s10-key
    move "detd08" to s01-error-file
    perform lock-wait
    go to read-detd08
    end-if
    end-if.
    if access-ok
    and d08-status-1 not = 0
    move 5 to access-status
    end-if.
    if not access-ok
    move 1 to access-type
    perform d08-err
    end-if.
    *
    d08-err.
    move "detd08" to s41-file s01-error-file.
    move d08-key to s41-record s10-key.
    move 5 to s01-no-bytes.
    move d08-status to common-status.

    The result of this is that sometimes (don't know when) the code that checks for the first status byte being non-zero is triggered, this performs d08-err and results in our system trying to log the error. The logging routine tells us that we have an access-status of 5, but a common-status of "00". How can this be? As an extra piece of information, the logging routine attempts to write this information to a file, which also suffers the same problem, i.e. access-status = 5 but file-status = "00". It smells like some sort of "out of resource" problem but we are completely at a loss. Has anyone any ideas PLEASE?? We have use statements in the declaratives section which should make this check on status byte 1 irrelevant, but the use code is not being triggered.:confused:
    If any normal file status is returned such as 10 or 23 then the code that called the "read-detd08" routine deals with it correctly. If it is expected then the code caters for it. If it is not expected then the error logging routine works perfectly and logs the error as it should.

    I have now switched on acu_dump in the hope of being able to track down what is happening by forcing a "subscript out of range" when the condition occurs. This in itself has presented another problem in that the dump file does not finish being written and I am now investigating this. One thing just leads to another eh?
    D

    [Migrated content. Thread originally posted on 11 June 2009]

    We are getting a weird situation with a file access every now and then and have been tearing our hair out trying to find it. Essentially we have copy libraries which we use to access files so that this is done in a consitent manner. The relevant code is as follows:-

    select detd08 assign disk-d08
    organization indexed
    access dynamic
    lock mode manual
    record key d08-key
    file status is d08-status.

    03 disk-d08 pic x(20) value "detd08".
    03 d08-status value "00".
    05 d08-status-1 pic x.
    05 d08-status-2 pic x.
    01 access-status pic 9.
    88 access-ok value zero.
    88 eof value 1.
    88 invalid-key value 2.
    88 rectyp-error value 3.
    88 record-locked value 4.
    88 unknown-error value 5.

    read-detd08.
    move zero to access-status.
    read detd08 invalid
    move 2 to access-status
    end-read.
    if access-ok
    and d08-status = 99
    move 4 to access-status
    if lock-retry
    move d08-key to s10-key
    move "detd08" to s01-error-file
    perform lock-wait
    go to read-detd08
    end-if
    end-if.
    if access-ok
    and d08-status-1 not = 0
    move 5 to access-status
    end-if.
    if not access-ok
    move 1 to access-type
    perform d08-err
    end-if.
    *
    d08-err.
    move "detd08" to s41-file s01-error-file.
    move d08-key to s41-record s10-key.
    move 5 to s01-no-bytes.
    move d08-status to common-status.

    The result of this is that sometimes (don't know when) the code that checks for the first status byte being non-zero is triggered, this performs d08-err and results in our system trying to log the error. The logging routine tells us that we have an access-status of 5, but a common-status of "00". How can this be? As an extra piece of information, the logging routine attempts to write this information to a file, which also suffers the same problem, i.e. access-status = 5 but file-status = "00". It smells like some sort of "out of resource" problem but we are completely at a loss. Has anyone any ideas PLEASE?? We have use statements in the declaratives section which should make this check on status byte 1 irrelevant, but the use code is not being triggered.:confused:
    If any normal file status is returned such as 10 or 23 then the code that called the "read-detd08" routine deals with it correctly. If it is expected then the code caters for it. If it is not expected then the error logging routine works perfectly and logs the error as it should.

    I have now switched on acu_dump in the hope of being able to track down what is happening by forcing a "subscript out of range" when the condition occurs. This in itself has presented another problem in that the dump file does not finish being written and I am now investigating this. One thing just leads to another eh?

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement