...and you were in the right church, but the wrong pew.
01 WS-RECORD-COUNT PIC 9(5) COMP-3 VALUE ZERO.
01 WS-PAGE-COUNT PIC 9(4) COMP-3 VALUE ZERO.
01 WS-LINE-COUNT PIC 9(3) COMP-3 VALUE ZERO.
Using packed-decimal for these value is the optimal thing to do, but it's bad practice to have a packed-decimal defined as an EVEN number of bytes because of how it's stored, so having a four-byte packed decimal is not a good practice. You're right about them not being signed. The odd number of bytes stores the sign under the last digit in memory.
The other issue is an 01 level in COBOL uses eight bytes of storage, even if' declared as less than that. Those three items will use 24 bytes, even though their definitions would lead a less knowledgeable developer to believe only seven bytes (3 for the 9(5), 3 for the 9(4), and 2 for 9(3)) are going to be used. Not that big a deal now that storage is so cheap, but inefficient programs impact real-time processing for financial transactions, which is COBOL's great strength.
And using packed-decimal instead of binary for these counters allowed the valued to be read easily while in storage. Binary (COMP) when stored is unreadable to the average human in the same circumstance.
I'll give it credit for writing a decent structured program, but it still does things I think a good COBOL programmer shouldn't do such as have MOVES coded in with a READ process. Good structured programming says to keep your "verb" actions in separate paragraphs for the sake of easier maintenance, and difficulty analyzing and maintaining programs is what's given the language such a bad rap.