|
View previous topic :: View next topic
|
| Author |
Message |
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
I thought I understood EXCP pretty well, but this channel program is failing and I can't figure out what's going on.
The IOB is -
| Code: |
000178 42000000000002E8 120 IOB DC 0XL40'0',AL1(X'42',0,0,0),A(ECB,0,0,CCWS,EXCP,0,0)
000198 0000000000000000 121 IOBSEEK DC XL8'0' |
The channel program is -
| Code: |
0001A0 3100019B40000005 122 CCWS CCW X'31',IOBSEEK+3,X'40',5 SEARCH ID EQUAL
0001A8 080001A000000000 123 CCW X'08',CCWS,0,0
0001B0 E90001C840000008 124 CCW X'69'+X'80',KEY,X'40',8 SEARCH KEY HIGH EQUAL ->
MULTI-TRACK
0001B8 080001B000000000 125 CCW X'08',*-8,0,0
0001C0 060001E000000100 126 CCW X'06',DIRBLOCK,0,L'DIRBLOCK READ DATA |
IOBSEEK does point to the first track of the data set. The R area is 0. IOBSEEK is filled in by using the CVTPCNVT routine with TTRN = X'00000000' rather than filling it in from DEB. This is all stuff I've done before.
The CSW in the IOB points to the TIC after the search key high-equal CCW.
The contents of KEY are CL8'ADDSTATS'
The contents of the actual key for the first record in the data set is BACKPDS.
The first byte of the ECB is X'41'.
I expect the search to end with first record and the contents of the first record to be read into storage.
As far as I can tell the CCW op codes are all correct. |
|
| Back to top |
|
 |
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
I've spent more time and I'm just as confused.
This is the IOB.
| Code: |
IOB 00000000
+0 46000000 4102DF5C 0002DE28 0C400008
0102DE10 0002DF68 00000000 00000000
+20 00000001 45000000 |
The 0C400008 the device status and the residual byte count. The 0C is channel end / device end. The 40 is wrong length! I'm thinking it's saying that R0 - the record in the search ID equal - does not have a key and that's why it's unhappy.
I'm going to start with R1. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
That did it!
I switched to a data set with a multiple track search area and it seemed to work for the highest possible key. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| Quote: |
| multiple track search area |
And what is that?
The HA and R0 are written using special CCW commands when the volume is formatted. There is not normally any reason to read or write these special records. User data begins with Record One (R1) and may be followed by additional user records. An empty track contains only the HA and R0. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
You normally do a search for R0 to format write record R1, or to do a read count for R1, or to do a read multiple count-key-data for the track. As you say, ordinary programs seldom read the home address or R0. My track dump utility has an option to read and format HA and R0, but otherwise I leave them alone. It uses read multiple count-key-data to read the rest of the track. I use read count when doing a fast summary of a data set. My program to search out gas areas in a PDS uses long chains of read count multi-track commands; other than the directory it's not interested in the data.
I thought, incorrectly, that search key high equal would skip R0. Obviously it does in multi-track mode after switching tracks. The test program ran two searches, one for the first name, and one for the last name.
A PDS directory for a data set with many members typically extends over several tracks. For my test I used the PDS directory for SYS1.LINKLIB; in my system that's 14 tracks! |
|
| Back to top |
|
|
|
|
  |
All times are GMT + 6 Hours |
|
