EXCP CCB Status Code Error

[Dave Clark]

I have two programs -- both of which perform 3270 I/O with a
supervisor appendage routine in order to wait on a 3270 attention
interrupt instead of just the normal channel-end + device-end CCB status
code (x'0C00').

The idea is to perform a 3270 ERASE-WRITE followed by a 3270
READ-MODIFIED. Both use EXCP. But, because (in between) you're waiting
for an end-user to make their changes and then hit either a function key
or an attention key, you can't just following the ERASE-WRITE with the
READ-MODIFIED. In between, you have to queue up a NOOP and perform a
special wait for the 3270 attention signal. Thus the reason for the
appendage routine.

The first program is supplied by somebody else (with source code)
and works just fine. The second program is one I've written and pretty
much incorporates the same techniques used by the fist program. However,
when my program goes to queue up the NOOP, I get back CCB status x'0C40'
and I can't figure out why. Anybody else have some idea?

Sincerely,

Dave Clark
--
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
(937) 294-5331



*********************************************************************************************
This email message and any attachments is for use only by the named
addressee(s) and may contain confidential, privileged and/or proprietary
information. If you have received this message in error, please
immediately notify the sender and delete and destroy the message and all
copies. All unauthorized direct or indirect use or disclosure of this
message is strictly prohibited. No right to confidentiality or privilege
is waived or lost by any error in transmission.
*********************************************************************************************

[Tony Thigpen]

Dave,

If I am reading the manual correctly, the x'40' is "A command other than
Sense was addressed to a device that the control unit has recorded as
unavailable or not ready."

Tony Thigpen

Dave Clark wrote on 9/22/23 11:38 AM:

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
09/22/2023 12:11:48 PM:

> If I am reading the manual correctly, the x'40' is "A command other than

> Sense was addressed to a device that the control unit has recorded as
> unavailable or not ready."

The web page I found says that the x'40' in byte 5 is "incorrect
length". In this case the only length I am aware of is the CCW I/O area
length. Both programs code this length as 1 for the NOOP. So, I'm not
sure what to do with that.

https://www.ibm.com/docs/en/zvse/6.2?topic=macro-format-ccb

Otherwise, since the previous EXCP for the ERASE-WRITE worked just
fine (the requisite screen does correctly appear on the device), I don't
see how the device can be unavailable. But, if your interpretation is
corerct, how would I determine if the device is not ready?

[Mark Boonie]

The x'40' is an incorrect-length indication. If you're using format-0 CCWs then the count field is required to be non-zero. As a result, a NOP, which doesn't transfer any data, will always end with the CCW count \= 0. If the ORB does not have the incorrect-length-suppression (L) bit set and the CCW does not have the SLI flag set then incorrect length will be indicated in the subchannel when CE is received. I don't know if you have control over the setting of the L bit in the ORB, but the easiest thing to do is probably set SLI (x'20' bit) in the CCW flags. If you're using format-1 CCWs then you can either set SLI in the CCW flags or set the count field to 0.

- mb

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
09/22/2023 01:36:12 PM:

> The x'40' is an incorrect-length indication. If you're using
> format-0 CCWs then the count field is required to be non-zero. As a
> result, a NOP, which doesn't transfer any data, will always end with
> the CCW count \= 0. If the ORB does not have the incorrect-length-
> suppression (L) bit set and the CCW does not have the SLI flag set
> then incorrect length will be indicated in the subchannel when CE is
> received. I don't know if you have control over the setting of the
> L bit in the ORB, but the easiest thing to do is probably set SLI
> (x'20' bit) in the CCW flags. If you're using format-1 CCWs then
> you can either set SLI in the CCW flags or set the count field to 0.

Thanks for that. I am using a format-0 CCW and I have the
following when initializing my CCW (WLR = wrong length record).

* INITIALIZE CCW
LA R0,SCRBUF GET ADDRESS OF BUFFER
L R1,BUFLEN GET MAX LENGTH OF BUFFER
STM R0,R1,MYCCW+0 PUT IN CHANNEL COMMAND WORD
MVI MYCCW+4,X'20' SUPPRESS WLR


But now the x'0C40' status has suddenly gone away after I reviewed
and rearranged my code just to "clean" things up.

However, now I see that am not getting the desired results out of
my appendage routine -- i.e., the wait is being satisifed too early and my
program is sending a message back to the user that input is required even
before they have a chance to send any input. When they finally do send
some input, it is accepted and processing continues but this keeps
happening every time it comes to the point in the process where user input
is required. It is a little difficult to debug an appendage routine when
it runs as an extension of the supervisor. Suggestions anyone?

[Farley, Peter]

Is z/XDC available to you? The authorized version might be able to help you out there, but I suspect only Dave Cole could tell you that for sure, and if so, how to do it.

Peter

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Ed Jaffe]

On 9/22/2023 2:06 PM, Farley, Peter wrote:
> Is z/XDC available to you? The authorized version might be able to help you out there, but I suspect only Dave Cole could tell you that for sure, and if so, how to do it.

CCB implies a z/VSE (or VSEn) system and AFAIK there is no z/XDC for
that platform.

(If there was, we would probably have a license for it!)


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/


--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

[Martin Trübner]

Just for the record

>> CCB implies a z/VSE (or VSEn) system and AFAIK there is no z/XDC for
that platform.

My guess, Ed, is that you are correct and it is VSE- There is TRAPPER
(and it is free) and it covers this case as well.


But

 (wild guess)

 we are looking at timing issues here and not at real debugging. So
either excellent tool is of no real help here.


Martin