Re: EXCP CCB Status Code Error
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
Re: EXCP CCB Status Code Error
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.
Re: EXCP CCB Status Code Error
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 From: IBM Mainframe Assembler List On Behalf Of Dave Clark Sent: Friday, September 22, 2023 1:55 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: EXCP CCB Status Code Error "IBM Mainframe Assembler List" 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 LAR0,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? Sincerely, Dave Clark -- 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.
Re: EXCP CCB Status Code Error
"IBM Mainframe Assembler List" 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 LAR0,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? 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. *
Re: EXCP CCB Status Code Error
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 > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of Tony Thigpen > Sent: Friday, September 22, 2023 12:12 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: [EXTERNAL] Re: EXCP CCB Status Code Error > > 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: > > 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. > > ** > > ***
Re: EXCP CCB Status Code Error
"IBM Mainframe Assembler List" 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? 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. *
Re: EXCP CCB Status Code Error
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: 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. *
EXCP CCB Status Code Error
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. *
