15 WS-NUM1 PIC S9(4) USAGE COMP.
15 WS-GF-NUM PIC S9(4) USAGE COMP.
15 WS-SGA-PCT PIC S9(5)V9(4) USAGE COMP-3.
15 WS-SGA-R-PCT PIC S9(5)V9(4) USAGE COMP-3.
Fields which are COMPutational of any sort should not be in records which are transferred to other systems where the transfer involves any sort of "translation". Going to your server, or on your server, I assume the data is translated from EBCDIC to ASCII. Any content in these fields is then open to irrrecoverable scrambling.
Take the "05" in EBCDIC, This is a "control code" HT. HT in ASCII is "09". So the 05 gets translated to 09,
Now, the thing is, the 05 could be part of any of those fields above, where it would mean something, After the ASCII translation it will no longer mean the same thing, it will have been corrupted.
No files you are transferring to non-mainframes should contain non-DISPLAY fields.
The code you point to that is doing "fixes" with INSPECT is rubbish. It will also be destroying parts of those four numeric fields. the "0D" is Carriage Return and the "25" is Linefeed. They are coming from somewhere to get into your record. If you don't want them, they should be excluded before getting into the record.
With the low-values, again, if they are occuring in non-display fields, fix the source, not splodge it about at the end, Fix the source does not mean do the INSPECT earlier, it means find out why low-values are there and fix the problem (raise the paperwork to complete the task),
So no, you should just include any extra values in the block of INSPECTs, they should all be removed and the work done properly.