From: Howard Brazee on
On Sat, 21 Jun 2008 08:00:46 GMT, Arnold Trembley
<arnold.trembley(a)worldnet.att.net> wrote:

>You might also try changing the READ statement as follows, to see if
>it has any effect on the behavior of the program:
>
>READ DSCCQNMN-FILE
> INVALID KEY CONTINUE
>END-READ
>
>Do NOT add a period after the END-READ keyword.

Why are you so adamant about not having a period here?

>The reason I suggest this is that I seem to recall there may be
>problems with omitting the INVALID KEY clause on a random read to a
>KSDS VSAM file.

What does that do?
From: Michael Mattias on
>>The reason I suggest this is that I seem to recall there may be
>>problems with omitting the INVALID KEY clause on a random read to a
>>KSDS VSAM file.

IIRC, there's a problem with not including an INVALID KEY clause on any kind
of read of an indexed file unless a USE procedure is in effect.

ie...
READ indexed_file_name
IF INVALID KEY clause present, control transferred to INVALID KEY
statements
If no INVALID KEY clause present, the USE procedure is invoked

I forgot what happens if neither is present.. maybe just FILE-STATUS is
updated? But of there is no FILE-STATUS defined, I have to believe it's a
fatal program error. (Whatever it is, it's certainly silly to have 'none of
the above').

MCM


From: Howard Brazee on
On Mon, 23 Jun 2008 10:50:00 -0500, "Michael Mattias"
<mmattias(a)talsystems.com> wrote:

>I forgot what happens if neither is present.. maybe just FILE-STATUS is
>updated? But of there is no FILE-STATUS defined, I have to believe it's a
>fatal program error. (Whatever it is, it's certainly silly to have 'none of
>the above').

I always write my programs with FILE-STATUS. But I'm the only one in
this IBM shop who does.
From: Robert on
On Sun, 22 Jun 2008 23:09:05 -0700 (PDT), vbarathee(a)gmail.com wrote:

Ws-first-read will never be set, due to missing period.

> OPEN INPUT MQFORM-FILE
>
> IF SUCCESSFUL-IO
> NEXT SENTENCE
> ELSE
> MOVE ERROR-OPENING-INPUT-FILE TO ERROR-MESSAGE
> MOVE WS-MQFORM-STATUS TO WS-RETURN-CODE
> SET WS-ERROR-FOUND TO TRUE
> PERFORM 9100-PROCESS-ERROR THRU 9100-EXIT
> GO TO 2000-EXIT
> END-IF
>
>*
>*C READS FIRST RECORD ...
>*
> SET WS-FIRST-RECORD
> TO TRUE.
>
> PERFORM 4400-READ-INPUT THRU 4400-EXIT.
>*

You don't need it. Rewrite this:

> READ MQFORM-FILE.
> IF SUCCESSFUL-IO
> MOVE WS-LIT-NO TO WS-FIRST-READ-FLAG
> ADD 1 TO WS-CNT
> ELSE
> IF END-OF-FILE
> SET WS-EOF TO TRUE
> IF WS-FIRST-RECORD
> MOVE ERROR-EMPTY-INPUT-FILE TO ERROR-MESSAGE
> MOVE WS-MQFORM-STATUS TO WS-RETURN-CODE
> PERFORM 9100-PROCESS-ERROR THRU 9100-EXIT
> END-IF
> ELSE
> SET WS-ERROR-FOUND TO TRUE
> MOVE ERROR-READING-INPUT-FILE TO ERROR-MESSAGE
> MOVE WS-MQFORM-STATUS TO WS-RETURN-CODE
> PERFORM 9100-PROCESS-ERROR THRU 9100-EXIT
> END-IF.

READ MQFORM-FILE.
IF SUCCESSFUL-IO
ADD 1 TO WS-CNT
ELSE
IF END-OF-FILE
SET WS-EOF TO TRUE
IF WS-CNT EQUAL TO ZERO
....
From: Arnold Trembley on
Howard Brazee wrote:
> On Sat, 21 Jun 2008 08:00:46 GMT, Arnold Trembley
> <arnold.trembley(a)worldnet.att.net> wrote:
>
>> You might also try changing the READ statement as follows, to see if
>> it has any effect on the behavior of the program:
>>
>> READ DSCCQNMN-FILE
>> INVALID KEY CONTINUE
>> END-READ
>>
>> Do NOT add a period after the END-READ keyword.
>
> Why are you so adamant about not having a period here?

Because I read the source example too quickly. I missed the fact that
the END-IF's were not correctly aligned with the IF's and assumed the
READ was within a larger IF. A period will not cause any problem.

>
>> The reason I suggest this is that I seem to recall there may be
>> problems with omitting the INVALID KEY clause on a random read to a
>> KSDS VSAM file.
>
> What does that do?

There may be no difference at all. Michael Matthias made the best
case for this, and it would be an easy test to do. I had a theory
that the lack of an INVALID KEY clause might result in the Operating
System intercepting a "not found" condition (file status 23) and
causing the abend. My theory is probably wrong.

I am inclined to agree with DocDwarf that there is some problem with
the ILBOWAT0. It's likely that WS-SECONDS-TO-WAIT is now above the
line, and the ILBOWAT0 actually executed is AMODE(24), RMODE(24), and
unable to deal with AMODE(31) addresses, which should certainly cause
an addressing exception like a S0C4.

If the original poster would try commenting out the CALL to ILBOWAT0
and testing again we might find out if that is the problem.

If ILBOWAT0 is the problem, then the original poster will have to find
another way to force a wait, perhaps Doc would be willing to contract
to write a 31-bit compatible WAIT subroutine.

If ILBOWAT0 is not the problem, then something must be wrong with the
KSDS VSAM file that has been added to the program.

I am very curious as to what the real problem is, and there's only so
much I can do to diagnose this remotely.

--
http://arnold.trembley.home.att.net/