Need to write to external PF every time a D spec happens on QSYSPRT??

[edz13579]

Hi:
I need to write the detail data on a report to an external file, so it can be used in a spreadsheet. Basically, converting a report to a database file (without totals or subtotals).

Had to get involved in some old code. I'm using to seeing an EXCPT DET statement, where I could put a WRITE statement to send the same data being printed to an output file..
This program is using a D spec for detail data. There are EXCPT statements for the headings and totals, but none for the detail. Sorry for the beginner question, but how can I know where to put a WRITE statement to capture the detail being printed?
Here is a snippet of the O specs. . I'm having trouble getting a copy and paste to format properly, so sorry it looks a mess. Basically, fields CA31c, CA31CN, CA31CH, CA31CA need to be written to an external PF every time these fields are printed on the report.

I see EXCPT QHEAD and PHEAD statements in the program but cant figure out how the details are printed, so where to put my WRITE statement.

OQSYSPRT E PHEAD 03
O PROGRM 10
O TITLE1 96
O 24 'Freedom Series'

O E 78 QHEAD 1
O 8 'Customer'
O 63 'Check...................'
O 69 '......'
O 78 'Posted'
O 87 'Invoice'

O D 15 11 78 1
O 8 ' '
O D 15NLR 78 1
O CA31C 10
O CA31CN 41
O 11 CA31CH 54
O 11 CA31CA J 70

Thank you in advance for any help!
Best regards,
Ed

[MFisher]

My foggy brain thinks the program may be using an old style "primary input" file with "RPG Cycle" , which I think defaults to output at the end of each cycle, without having to specify it.

So maybe your WRITE goes at the end of the cycle before the next input record is loaded.

(I am rusty in RPG. Used it decades ago, now just tweak a few legacy programs, or write short programs mostly using SQL .)

[JonBoy]

You may be right MFisher otherwise the basic question makes no sense.

To the OP. D specs define data. That data may subsequently be output but the D spec itself is not involved.

If you could edit your post to show the formatted code it might help. To do this place a marker {code} and {/code} either side of the block. BUT _replace_ the { } by [ ]. There must be a way of typing that but I'm danged if I know how!

Also make sure to include the F-specs of the program.

[Peder Udesen]

The RPG cycle is a very unique feature that I haven't found in any other programming language.
It handles input from files, calculation and writing to files in certain steps.
You can read about it in the RPG Reference manual - search for "General RPG IV Program Cycle".
In the old days when you only had card readers, paper tapes or magnetic tapes and a printer this was
very practical.

Today it is not used -- but can be found in very, very old programs.

An easy way to change your program is to copy the lines with the detail output lines and write the fields
to a physical file. The file is created like this
CRTPF FILE(QTEMP/MYFILE) RCDLEN(132)

In the program you have the detail lines like this
OMYFILE D 15 11 78 1
O 8 ' '
O D 15NLR 78 1
O CA31C 10
O CA31CN 41
O 11 CA31CH 54
O 11 CA31CA J 70

Remember to copy the F-card for the printer and replace QSYSPRT with MYFILE and PRINTER with DISK

Thus the cycle logic is preserved and you don't have to make many changes.
I hope this will solve your problem.

[TedHolt]

The RPG cycle is a very unique feature that I haven't found in any other programming language.

Unix shell utilities have a built-in cycle. They read from standard input and write to standard output without your having to tell them to.

In some cases, you can assume some control. For example, sed (the stream editor) has a -n switch that prevents the automatic write to stdout. You have to use a p command to force the write, which is something like using EXCEPT in an RPG cycle program.

sed -n '/,/p'

[Scott Klement]

Trying to help by reformatting the code (the original post was very difficult to read.) I'm not at all sure that I got it right since a lot of the numbers in O-specs are column-dependent, and the original post lost all of the column positions -- but this is what I came up with:

.....O*ilename++DF..N01N02N03Excnam++++B++A++Sb+Sa+....................
     OQSYSPRT   E            PHEAD      03
     O                       PROGRM              10
     O                       TITLE1              96
     O                                           24 'Freedom Series'

.....O*.............N01N02N03Field+++++++++YB.End++PConstant/editword/DTformat++Comments++++++++++++
     O          E       78   QHEAD          1
     O                                            8 'Customer'
     O                                           63 'Check...................'
     O                                           69 '......'
     O                                           78 'Posted'
     O                                           87 'Invoice'

     O          D    15 11 78               1
     O                                            8 ' '
     O          D    15NLR 78               1
     O                       CA31C               10
     O                       CA31CN              41
     O               11      CA31CH              54
     O               11      CA31CA        J     7

[Scott Klement]

It's hard to tell you where to put C-specs that will run at the same (approx) time as the O-specs you've provided. To do that correctly, you need to read and understand the C-specs.

But, in general, you'd want to put them at the end of the detail calcs (i.e. the calcs that don't have total-time indicators defined), before any subroutines, etc. If you have things like other conditions or GOTOs, you'll need to puzzle those out and make sure your new code is called in the right place relative to those.

Then just condition it on the same indicators, so something like this:

        if *in15=*on and *inlr=*off and *in78=*on;
          FIELD1 = CA31C;
          FIELD2 = CA31CN;
          ...etc...
          write MYFORMAT;
        endif;

IMHO, this is the sort of question that's best asked to your mentor within your organization. Someone who can sit down and look at the code together with you, look at how the code works, and show you why the code belongs where it does.

If you don't have someone like that, try to use my advice, above... but you'll need to spend some time really understanding how the program works. Perhaps stepping through the program line-by-line with a debugger will help.

[Barbara Morris]

I second Scott's suggestion to step through the program in the debugger.