How do I find out how many lines of source code are on the system?

690 pts.
Tags:
CL
iSeries development
QRPGLESRC
QSYS.LIB
RPGLE
Hello. I'm trying to write a program that will tell me how many lines of source code reside on our system. I figured out the first couple of steps, but it just gets more and more confusing along the way, and I really think there's gotta be a better way to get the information i need. So far, this is what I have come up with:
  1. Get a list of all libraries in QSYS and put in an outfile.
  2. Using the above output file, create a new one holding those records where the ODCRTS, Created on system, matches the system name from RTVNETA.
  3. Read the output file from step 2 and for each library name value held in ODOBNM, Object name, do a DSPOBJD to get all *FILEs. Output to yet another file.
  4. Once all library names are processed and the 3rd file is created, do a CPYF over the new one from step 3 and select records where the source file, source lib, and source member, (ODSRCF, ODSRCL, ODSRCM), are blank.
  5. That should hold the source physical file names in all libraries.
From there, since I never was able to write the process of step 4 because of mass confusion, I thought that i'd have to read that file, and for every record, take the value in the object name which would be QRPGLESRC, and the library name, ERIC01, and copy the data into 1 main output file, and keep adding records. I could break on the library name which seems like a good idea, and call an RPGLE. There I'd read each record in that file and count the number of records, outputting the count amount, library name, and source pf name to a main output file that will eventually get reported off of. QUESTIONS ==============================================
  1. Is there an easier way to retrieve a list of all Source Physical Files held in the system?
  2. Is there any easier way to do what i need to do without creating a TON of output files, without getting confused so that i don't pull every hair out of my head?
Please help me. Eric

Answer Wiki

Thanks. We'll let you know when a new response is added.

You have the right general idea. I would use the following approach:

1. Get a list of all libraries (using either DSPOBJD as I assume you are currently doing or the List Objects API QUSLOBJ — note that both support a special value *ALLUSR to subset the list of returned libraries).

2. Get a list of all files in each library identified in step 1 (again with DSPOBJD or QUSLOBJ).

3. Use the Retrieve File Description API QDBRTVFD and format FILD0100 to determine if the file is a source file. This API can appear overwhelming but fortunately all you want is the bit field Qdbfhfsu located in the ninth byte of the returned data — so you can ignore everything else. If this bit is on then the file is a source physical file. Note that a blank source file, source file library, and member name does NOT mean you have a source physical file. It just means no source was used to define the file — a CRTPF FILE(A) RCDLEN(100) would also have no source identified.

4. If a source physical file, use the List Database File Members API QUSLMBR and format MBRL0320. This will give you a list of all members in the file along with the current number of records in each member. Alternatively you could use QUSLMBR and format MBRL0100 to get just the list of member names and then the RTVMBRD command for each member and get the NBRCURRCD value.

5. Accumulate the values found in step 4 and you’re done.

If you are not familiar with APIs you might be interested in the book APIs at Work Second Edition. In there you will find RPG examples of all the APIs I referenced above and, in the case of QDBRTVFD how to test individual bit values. Note that I am the author of this book so I am a bit biased here…

I hope this helps,
Bruce Vining

Discuss This Question: 7  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Gilly400
    Hi, There is an easier way :- DSPFD FILE(*ALLUSR/*ALL) TYP(*MBR) OUTPUT(*OUTFILE) FILEATR(*PF) OUTFILE(yourlib/yourfile) Then use Query to select records with MBDTAT (File Type) = 'S' and give a total of MBNRCD (Current number of records). Regards, Martin Gilbert.
    23,730 pointsBadges:
    report
  • Gilly400
    Hi, You can of course use query to give you level breaks with totals for each source file and/or library. Regards, Martin Gilbert.
    23,730 pointsBadges:
    report
  • Vatchy
    There is an easier starting point. File QADBXREF in library QSYS contains a list of all of the files on the system. Read through that file and look for DBXTYP = "S" - that identifies the source files on the system.
    1,410 pointsBadges:
    report
  • TomLiotta
    There is an easier starting point. Can you describe how that's an easier starting point? First, QADBXREF is an internal DB2 system file that shouldn't be directly accessed. It's unlikely that a problem would come from it, but it's always better to access system objects through supplied interfaces. You can run DSPDBR over QADBXREF to see all of the LFs that are supplied by IBM if it's necessary to read records from QADBXREF. Next, processing rows of QADBXREF may take a long time on some systems. Processing requires creating lists of members in each 'S'ource file found. Depending on locks, on authorities and on how many members are in any of the source files, it may take a significant amount of time to list a files members. If DB2 is updating QADBXREF due to file creations/deletions in other jobs, you don't want to be accessing it at the same time. Interference with DB2 can be a cause of problems that lead to a need to run RCLSTG SELECT(*DBXREF). Note that the processing of members is what DSPFD TYPE(*MBR) supplies without needing a second step for each row with DBXTYP='S'. Tom
    125,585 pointsBadges:
    report
  • Vatchy
    Can you describe how that’s an easier starting point? It's easier because you are starting with a list of the source files. You can take each file in that list and run the DSPFD command with *MBRLIST to an outfile. After doing that for each source file you can then total the number of records and you're done. Seems pretty simple to me.
    1,410 pointsBadges:
    report
  • TomLiotta
    You can take each file in that list and run the DSPFD command with *MBRLIST to an outfile. True, but the total solution only requires two statements:
    DSPFD FILE(*ALLUSR/*ALL) TYPE(*MBR) OUTPUT(*OUTFILE) FILEATR(*PF) OUTFILE(QTEMP/ALLMBR)
    SELECT sum(MBNRCD) FROM QTEMP/ALLMBR WHERE MBDTAT ='S'
    There's no need to run through the list to run DSPFD for each individual source file. All of the values already exist in the results from the single DSPFD command. Just add up the ones that matter. At least two considerations could apply. A very large number of data files could combine either with a requirement for absolute minimum space used or time consumed. If temporary space or time requirement demands it, then your direction is probably best. But if the question is "easiest", it's hard to improve on two statements. Tom
    125,585 pointsBadges:
    report
  • ToddN2000
    Also another thing to remember, the methods listed above will get you the number of line in the source file but also include the comment lines. Depending on how well documented your code is, these comment lines may greatly inflate the number of actual active lines of code.
    14,920 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following