On 28-Jul-2016 23:37 -0500, Booth Martin wrote:
On 28-Jul-2016 23:20 -0500, mlazarus wrote:
On 28-Jul-2016 22:33 -0500, Booth Martin wrote:
On 28-Jul-2016 21:35 -0500, Booth Martin wrote:
I am thinking that if you remove the LR on the O line you will
get the results you want.
Just to touch on [and thanks for] those replies; probably little
value on any followup with any questions I might have asked inline
below, given I likely will have gained sufficient understanding already,
or I probably will not really pursue much further given I have multiple
means of achieving the part "1) insert-a-record" of my inquiry.
No. The result was the same: First a blank record and second the
desired record of data that was previously read from the input file
S36INP, both records being output\written in that order, to the output
file S36OUT.
What I found is corrective, is *adding* an LR to the record-level
O-spec instead of having the LR being only on the field-level O-spec.
That stops the blank line from being written. For lack of any field
indicated from which the data to be written is derived, apparently the
run-time cares not.
-Maybe you need another conditioning indicator, depending on
what you wish to do (I am adding *IN71 as an example).
That seems to be the consensus; for input and output -- and as the
same indicator betwixt, thus ensuring no detail write unless there was a
corresponding [detail] read.?
-I am also thinking that you might omit RCDOUT and the
associated MOVE line; then you can just output RCDINP into
S36OUT.
I can see that is better. But the movement of data in this specific
case was explicit, purely for visibility of activity within trace data.
-It also occurs to me that you might want to overlay ARRY,3 in
say, columns 18-25 of S36OUT, which is easily done.
Noteworthy to see [how that would be done]. But I just wanted all 55
bytes from a\the row of S36INP placed as an identical row in S36OUT.
Anyhow, the ARRY references were just remnants from the QPROOF [compiler
validation\verification source] that was used as a basis for my source;
again, they remained in the source purely for assignment activity being
visible within trace data, knowing they were copied from a fully
functional RPG36 source member.
-If you insert an E on the Input Primary file line you do not
need the LR indicator.
I am not sure I ever recall noticing that End of File (EOF) directive
on the F-spec; the only cycle programs with Input-Primary (IP) that I
recall working with [and RPGIII+], likely never did set on LR nor add
the E (thus IPE). I just figured, given I had only one row in S36INP,
and that I wanted to copy just [the] one row, LR would forcibly stop the
cycle; thus that directive of E="process all rows before program end"
would have seemed counter to my goal of ensuring just one record processed.
-Finally, you could change the XX to, say, 01, and use 01 as
the detail time output add conditioning indicator instead of
the 71 that I added in the example.
The XX is a Sequence (SEQ) directive [pos 15-16] suggesting the
program need\should not check for any particular "special sequence" of
the data records; when I had ever code that, I would have specified NS
for NoSequence, so not sure why I typed XX this time.
An indicator such as 01 would be the Record ID (RcdId) [pos 19-20]; I
had ignored that setting, because I was thinking that was something to
do with Record ID Codes, of which my input file had none defined.
So I infer this RcdId indicator serves as nothing more than an
indication that a detail record was read from the input file?
You might write this whole section as:
FS36INP IPE F 55 DISK
FS36OUT O F 55 DISK A
E ARRY 1 3 8
I* .1....+....2....+....3....+....4....+....5....+....6....+.
IS36INP XX
I 1 55 RCDINP
C MOVE ARRY,2 ARRY,3
C SETON 71
C* .1....+....2....+....3....+....4....+....5....+....6
OS36OUT DADD 71
O RCDINP 55
O ARRY,3 25
Thanks. That also functions quite well; copying all records from the
input-file to the output-file. And commenting-out the lines with ARRY
both pares the code and gets what I really want -- as noted, the AARY
stuff was baggage [that I probably should have removed before posting].
oops. Forgot one thing.
Putting the output indicator on the field line means that a
record gets written every detail time, but actual data is written
only when the indicator is on. That explains the blank record you
got. (It's a guess, but are there two records in S36INP? That
would explain two Detail cycles.)
The OCL ensured, as setup, that there would be just one row. The
first record appears, quite conclusively per updates by Buck and Mark,
to be the effect of a phase of the cycle that outputs what would
normally be a heading.
So, you want to put the indicator on the record format line.
That way a record only gets written at detail time AND when the
indicator is on.
That seems to have been resolved generally by the use of *IN71; i.e.
what is shown above, gives success in writing just the one record. But
as noted, using the LR on the record-format-line of the O-spec [in
addition to the LR on the field-line of the O-spec] was similarly
satisfactory.
Actually, there's a detail output at the beginning of the cycle.
This allows for headings to be output. Since Chuck's code did not
condition the output record, he got a "pre-first record" output and
then the one after the record was read.
Seems so. I was trying to avoid all indicators but LR, in an attempt
to output only detail records; but I ended up writing a blank heading
and a detail record when LR was on [¿not a total record as previously
alluded?], best I can infer, according to what Buck posted:
[
http://archive.midrange.com/rpg400-l/201607/msg00196.html]
[http://www.jaymoseley.com/hercules/images/rpgflow.jpg]
I believe this is a valid flowchart. I do not see what you describe.
I do not see how one can get two detail out records from one input
record. That doesn't mean it doesn't happen; I am wrong way too many
times to believe I am always right.
However I am having trouble figuring out a way to get two output
records with one input record, one output format, and one cycle.
As Buck's reply suggests, and as I alluded above about RPG run-time
seeming uncaring about there being no fields indicated for the output
format, that heading record was output; output, irrespective of what
appears on that jpg as flowchart.
midrange.com
