counting no. of record in a relative file

[deveshjogal]

hi

Does anybody know a way to get the total no. of records in a relative file. (One of the way could be reading the file till end; But is there any other way for the same. The environment can be IBM 3090 mainframe/Unisys A series mainframe)

Devesh

 

[MarcLodge]

Hi Devesh,
Does Thread209-435441 help?
Marc

 

[slade]

Hi Devesh,

You should tell us the circumstances under which you want
to count the recs.

Is this part of a production job stream? Do you want to find the count in a test environment (e.g. ISPF)? Do you want to write a pgm to do it, use a utility? Do you have to test the count a 100 times a day, once a year, etc?

The approaches will differ depending on your answers.

Regards, Jack.

 

[3gm]

I'd guess a binary search sort of thing would work:

Read relative record # 16777216
Read relative record # 8388608
Read relative record # 4194304 etc

until you are able to successfully read a record. You then know the EOF is between that record and the next higher multiple of two. Divide that interval in half and read a record. Continue until you read record n successfully and n+1 fails. Should require at most 25(?) READS to handle file sizes up to 16M records.

Glenn

 

[Member 310024]

Just a question prompted by the 3rd Generation Man's comment.

What if records within a relative file have been deleted?
Would an attempted read on a deleted slot, necessarily
be successful?

Does the original query ask for a record count or the
highest rel key?

 

[mrregan]

I agree with Terminate. A relative file could have just one record in the highest relative key position.

 

[Dimandja]

If a relative record had been deleted, a random READ would raise the AT END condition (while a sequential READ would skip the empty cell).

However, a START APPROXIMATE followed by a READ NEXT would accommodate Glenn's solution.

Dimandja

 

[Dimandja]

PS - my solution added to Glenn's tip should work when relative records were randomly added as in mrregan's example. The skipped lower cells simply become invalid/empty.

Dimandja

 

[kkitt]

I have used this little bit of JCL to get a record count and place it into a file that can be used in later pgms if needed. This uses ICETOOL to get the record cound and a sort to pull out just the line with the count. Hope this helps:

//SRT1 EXEC PGM=ICETOOL                                  
//TOOLMSG DD DSN=KKITT.TEMP.TEST1,DISP=(,CATLG,DELETE),  
//           SPACE=(TRK,1),UNIT=TEMP                     
//DFSMSG  DD SYSOUT=*                                    
//CONCAT DD DSN=KKITT.TEST.BDT.WALORD,DISP=SHR           
//TOOLIN DD *                                            
MODE STOP                                                
COUNT FROM(CONCAT)                                       
//*                                                      
//STEP2  EXEC  PGM=ICEMAN                                
//SORTLIB  DD  DSN=SYS1.SORTLIB,DISP=SHR                 
//SYSOUT   DD  SYSOUT=*                                  
//SORTIN   DD  DISP=SHR,DSN=KKITT.TEMP.TEST1             
//SORTOUT  DD  DSN=KKITT.TEMP.TEST2,DISP=(,CATLG,DELETE),
//         UNIT=TEMP,SPACE=(TRK,1)                       
//SYSIN    DD *                                          
  SORT FIELDS=COPY                                       
  INCLUDE COND=(2,7,CH,EQ,C'ICE628I')                    
  OUTREC FIELDS=(11,80)                       

Output from ICETOOL:

ICE600I 0 DFSORT ICETOOL UTILITY RUN STARTED 
                   
ICE632I 0 SOURCE FOR ICETOOL STATEMENTS:  TOOLIN
                  
ICE630I 0 MODE IN EFFECT:  STOP                

          MODE STOP

ICE630I 1 MODE IN EFFECT:  STOP  

ICE602I 1 OPERATION RETURN CODE: 00
               
          COUNT FROMCONCAT)

ICE627I 0 DFSORT CALL 0001 FOR COPY FROM CONCAT   TO E35 EXIT COMPLETED 

ICE628I 0 RECORD COUNT:  000000000004716

ICE602I 0 OPERATION RETURN CODE:  00

ICE601I 0 DFSORT ICETOOL UTILITY RUN ENDED - RETURN CODE:  00           


Output from ICEMAN (placed into file):

RECORD COUNT:  000000000004716

 

[deveshjogal]

Thanks a lot...

Devesh

 

[sln007]

Excellent solution from "KKITT" listed above.
I've used this method for years.