0

Does anyone has experience in replacing the primary file from a RPG program, which has Level indicators defined (Level indicator used for calculation purpose)?

Instead of RPG cycle , i need to introduce new file (replacing primary file) which will defined as a fully procedural file (no more primary file)..

Thanks.

jmarkmurphy
  • 11,030
  • 31
  • 59
MAS400
  • 65
  • 1
  • 9
  • We need code, but the difference in processing would generally mean a total rewrite of the program. You would need to replace not only reading of the file, but also the break logic of the cycle. What you asking is roughly equivalent to "How do I remove the MVC framework of my web application?" – jmarkmurphy Nov 02 '17 at 18:26
  • I've done a bunch. CL Override the primary file to the new file then call the RPG. Everything will still work. The concerns are new file in same order as original file. With break processing (group by in SQL) it really makes a difference on the order of the records. – danny117 Nov 03 '17 at 13:26
  • Requirement is to add 1 more field in primary file so we decided to replace RPG cycle.... File 1 which is now primary in RPG has 30 fields , new file 2 will have 30 + 10 new fields.... At what point the RPG cycle read record from primary file, i need to replace that with Read & dow. – MAS400 Nov 03 '17 at 13:40
  • and 1 more thing to replace level break logic i need to store previously read record data and compare with current processing record data, correct? – MAS400 Nov 03 '17 at 15:26

1 Answers1

3

Why do you want to stop using a primary file? Doing your own comparisons to simulate level indicators will probably be much more work than making the changes to the primary file.

In general, to replace a primary file with a full-procedural file, put the READ + DOW not %EOF(primaryfile) at the top of the calculations, and put the second READ and ENDDO at the end of calculations.

For the calculations with the level indicators L0, L1 etc in columns 7 and 8, I would first move those calculations into subroutines, for now call them something like L0_subr, L1_subr etc.

To handle the comparisons with previous record, after the first READ, before the DOW, add statements to save off the current values of the level-indicator fields. At the end of calculations, before the second READ, add statements to compare the current values with the saved values, and if they are different, call the relevant Lx_subr(s). After all the Lx_subrs have been called, update the saved values for that particular level indicator.

Making that kind of change is error prone. I would just leave it as a primary file and add extra Level indicators to the I specs, if necessary.

2017-11-06 update starting from here:

To enable keeping track of both the previous record and the current record, use the feature where you can read into a data structure.

read rec cur_ds; 
dow not %eof;
    ... 
    if have_prv_ds; 
      compare the previous record to the current record 
    endif; 
    eval-corr prv_ds = cur_ds; 
    have_prv_ds = *on; 
    read rec cur_ds; 
enddo;

Since the READ won't be affecting the standalone fields associated with the file, a good practice to avoid accidentally referring to those standalone fields is to avoid even having the standalone fields defined. To do that, define the file with the QUALIFIED keyword. Then, you'd refer to the record format using file.fmt, and the fields associated with the file wouldn't exist.

dcl-f myfile qualified;
dcl-ds cur_ds likerec(myfile.fmt);
dcl-ds prv_ds likerec(myfile.fmt);

read myfile.fmt cur_ds; 
dow not %eof(myfile);
    ... 
    if have_prv_ds; 
      compare the previous record to the current record 
    endif; 
    eval-corr prv_ds = cur_ds; 
    have_prv_ds = *on; 
    read myfile.fmt cur_ds; 
enddo;
Barbara Morris
  • 3,195
  • 8
  • 10
  • Thanks Barbara, It's so called modernization :) that's what we are looking for to take the code at next level......I know it's risky.... We need to do second read in order to compare first time read saved value.... READ, SAVE,DOW, DETAIL, READ if change do TOTAL....but the problem if i read next record, it will wiped out all previous record from file field..... i am planning to use SQL read instead of defining at F spec... Do you guys think Group by can help me or any other suggestion to move safely, Any suggestion will be big help? – MAS400 Nov 03 '17 at 20:39
  • If you read into data structures, you can have access to both the new and old records. (Reading into data structures and writing from data structures is also considered "modern", since it gives you more control over where the record data goes.) read rec cur_ds; dow not %eof; ... if have_prv_ds; compare the previous record to the current record endif; eval-corr prv_ds = cur_ds; have_prv_ds = *on; read rec cur_ds; enddo; – Barbara Morris Nov 06 '17 at 15:24
  • See my original post for the code in the comment above, plus more information about the best way to use data structures for I/O. – Barbara Morris Nov 06 '17 at 15:36
  • I found when it's very first record read into RPG cycle it's switch on all Level Indicator is it true? Another question before reading next record, does system set off all LEVEL indicator to compare and turn on which are relevant? – MAS400 Nov 09 '17 at 20:17