Nevermind.  I was off in my calculation of the CCB address.  This is the
CCB--and, yes, the residual count looks correct.  Thanks.

0030C200  0D000000  00500320  00500328

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


On Mon, Dec 15, 2025 at 1:32 PM David Clark <[email protected]> wrote:

> >>  The first 16 bytes of the DTF is a CCB. One of the 16-bit fields in
> the CCB is the residual count.
>
> Then I am confused, because it looks like the CCB, in my case, is as
> follows after reading the first card.  The compile listing also seems to
> say that the first two bytes are the residual count.  If that is correct,
> did I read 80?  ...or did I read only 48?  This seems reversed.  However,
> the 7th half-word would be right.
>
> 00500300  00500340  00066150  00308200
>
>
>  CARDIN   DTFCD DEVADDR=SYSRDR,DEVICE=3505,IOAREA1=CARD_IA,BLKSIZE=128, X
>                 ERROPT=IGNORE,EOFADDR=DATAIN
> +* IOCS AND DEVICE INDEPENDANT I/O - DTFCD -5686-007-02-C440    @U31TUJS
> +*           5686-007 (C) COPYRIGHT IBM CORP. 1981,1989         @U31TUJS
> +*           LICENSED MATERIAL - PROGRAM PROPERTY OF IBM        @D149DBF
> +         DC    0D'0'
> +CARDIN   DC    X'000082000000'           RES. COUNT, COM. BYTES STATUJJ
> +         DC    AL1(0)                  LOGICAL UNIT CLASS
> +         DC    AL1(0)                  LOGICAL UNIT
> +         DC    A(IJCX0017)             CCW ADDRESS             @D33FDVS
> +          DC    4X'00'                 CCB-ST BYTE,CSW CCW ADDR.
>
> 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
>
>
> On Mon, Dec 15, 2025 at 12:12 PM Charles Mills <[email protected]> wrote:
>
>> 50-year-old memory so take this with a grain of salt: The first 16 bytes
>> of the DTF is a CCB. One of the 16-bit fields in the CCB is the residual
>> count. So if the DTF is expecting 128 bytes and reading 80, the field will
>> contain 48 = x'0030'.
>>
>> But I would think that scanning for binary zeroes or translating them to
>> blanks would be a perfectly acceptable approach.
>>
>> Charles
>>
>>

Reply via email to