I should have added this.
Here is a link to a freeware website that has a command EXPJRNE that will help you out.
http://www.help400.de/Eng/Freeware.htm

Generally RPG isn’t reading/writting bytes but records but if you are processing bytes then you should count them.

You could multiply the reads/writes by the number of bytes in a record or you could add the lengths of the character strings using %len(%trim( myfield)) for each field.
Phil

the number of bytes read from a file(FILE1) & written to another file(FILE2)

That’s a pretty specific request. What does it mean?

Do you want to know how many bytes are transferred between your program fields and the ODP buffers? Do you count a full record length even if you only update a couple %FIELDS()? If you only define and reference a couple fields, the compiler will only make the values of those fields available to your program. Do you count the bytes of the other fields in the same record? If you read a record from FILE1 but an error stops the update to FILE2, do you still count the bytes from FILE1?

Does the count of bytes have to be “by program”? Is it a specific program or all RPGLE programs? What if the program has ten modules and only one is RPGLE? What if the RPGLE module isn’t the one that does the I/O?

Do you have a clear definition from an auditor of exactly what is to be counted and when?

Tom

p.s. I love talking with auditors.

Tom

Taking the length of the record(s) read and the length of the record(s) written and adding them up should provide your answer.

It’s a worthless answer, utterly ignoring what actually happens to the data in between being read and being written, but it’s an answer.

Hi CharlieBrowne, Philpl1jb, TomLiotta, Splat.
Thank You Guys, all for your replies.

Charlie!
Ya you are right. the no. of bytes is not constant, it keeps changing. one time may be x-bytes may be read; another time x+n bytes may be read.
I don’t think any journalling is required. It’s a simple RPG program.

Let me put it this way:-
It’s a simple RPG program.which counts the no. of bytes while reading a record of FILE1 & counts the no. of bytes while writing into FILE2.

Finally the no. of bytes READ should be equal to no. of bytes WRITTEN, ensuring everything is proper, which is required for Audit-purposes.

Let me know if anybody has done this earlier?

Thanks very much,
Svanky

Let me know if anybody has done this earlier?

I haven’t done it before. It doesn’t make sense to me yet. It seems like the only thing that is being audited is the value that the program says that the value should be. Nothing says whether that value is correct nor does anything outside of the provide confirmation.

Let me give an example.

I created a simple table with three columns — one INTEGER column and two TIMESTAMP columns. Then I started INSERTing rows into the table.

Here’s the basic file/field descriptions:

Record Format Information
  Record format . . . . . . . . . . . . . . . :  CHKBYTES
  Format level identifier . . . . . . . . . . :  3700D94C3E66D
  Number of fields  . . . . . . . . . . . . . :      3
  Record length . . . . . . . . . . . . . . . :     56
Field Level Information
             Data        Field  Buffer    Buffer        Field    Column
  Field      Type       Length  Length  Position        Usage    Heading
  C1         BINARY       9  0       4         1        Both     C1
  C2         TIMESTAMP      26      26         5        Both     C2
    Coded Character Set Identifier  . . . . . :     37
  C3         TIMESTAMP      26      26        31        Both     C3
    Coded Character Set Identifier  . . . . . :     37

After some 48 opens and closes of the file where a total of 20740 rows were INSERTed, what should the byte-count be for the number of bytes written?

If I go outside of the program to confirm my value, I can look at the file description to see how many bytes are in the member. The basic size statistics are:

Record Format List
                       Record  Format Level
 Format       Fields   Length  Identifier
 CHKBYTES          3       56  3700D94C3E66D
   Text . . . . . . . . . . . . . . . . . . . :
 Total number of formats  . . . . . . . . . . :           1
 Total number of fields . . . . . . . . . . . :           3
 Total record length  . . . . . . . . . . . . :          56
Member List
                             Source Creation    Last Change                  Deleted
 Member           Size        Type  Date       Date     Time      Records    Records
 CHKBYTES             536576        11/09/10 11/09/10 16:42:55      20740          0
   Text:
 Total number of members  . . . . . . . . . :                 1
 Total number of members not available  . . :                 0
 Total records  . . . . . . . . . . . . . . :             20740
 Total deleted records  . . . . . . . . . . :                 0
 Total of member sizes  . . . . . . . . . . :            536576

So, I have three fields that add up to 56 bytes for a record buffer, and I wrote 20740 records. Let’s see — 20740 * 56 = 1161440

Over a million bytes.

But the actual size is only half of that.

How can you ever prove in an audit that the number counted by the program actually means anything?

(BTW, all of the numbers here are correct. You can verify them yourself on any recent AS/400.)

You can use the %SIZE() builtin function against each field or against a DS that holds a collection of fields. You can add them up while the program runs and log the values when the program finishes. But how will you know what the numbers are supposed to be? All you can do is add up the sizes of variables in the program, and those sizes won’t necessarily match with the sizes that are read or written.

Unless you can prove the numbers, they have no meaning to an audit. You can’t use the program that generates the numbers to prove the numbers.

Well, I suppose you could; but it shouldn’t be accepted by any auditor.

Tom

Of course Tom is correct.
To the extent that you can do anything
everytime you read a record
Eval totalBytesR = totalBytesR + recordLenIn
and when you write
Eval totalBytesW = totalBytesW + recordLenOut

where recordLenIn is the length of the record you read
and recodLenOut is the length of the record you write.

But of course, we’ve been saying that all along, so what did we missunderstand?
Phil