How to find number of bytes read/written in RPGLE?

625 pts.
Dear AS/400 Lovers! In a program, I need to find the number of bytes read from a file(FILE1) & written to another file(FILE2) in RPGLE. I need to maintain this in an Audit-file for Audit purposes. Has anybody done this earlier? any help would be of great value. Thanks in Advance, Svanky

Software/Hardware used:
as/400, rpg/400, rpgle, db2/400, os/400

Answer Wiki

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

It sounds like you this is noe a constant. Sometimes you may take x number of data elements from file A and update/write them to file B. And other times it might be X+n fileds. Is that correct?
Is it only within one program?
I believe if you journal the *before and *after images of file B, you should be able to analyize the journal entries to get what you need.
There is a Command EXPJRNE that you can downloiad from the FREEWARE website that would be a good place to start with the coding.

Discuss This Question: 8  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.
  • CharlieBrowne
    I should have added this. Here is a link to a freeware website that has a command EXPJRNE that will help you out.
    62,385 pointsBadges:
  • philpl1jb
    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
    54,090 pointsBadges:
  • TomLiotta
    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
    125,585 pointsBadges:
  • TomLiotta
    p.s. I love talking with auditors. Tom
    125,585 pointsBadges:
  • Splat
    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.
    12,915 pointsBadges:
  • svankipu
    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
    625 pointsBadges:
  • TomLiotta
    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
     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
    125,585 pointsBadges:
  • philpl1jb
    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
    54,090 pointsBadges:

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.

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


Share this item with your network: