RE: INFDS Sy 36 PSDStr... Issue

Kathie wrote:
>As you may remember, I am rewriting old icky stuff , still,
>I am creating transactions in a 64 character flat file.

Do you have to?  I mean, is this file under your control at all?  If it's
not, the client may be asking you to make a silk purse from a sow's ear...

>Some of the records are Batch Hdr records and some
>are detail records. I have the last 13 positions
>of the record to hold whatever I wish.

>I need to be able to retrieve the records later in the
>program for
>'REVIEW'. On one screen, I need to ROLL through the Header
>records and allow
>the user to modify them, on another screen, I need to ROLL
>through the Detail
>records for the associated Header record to allow modification
>of them. The
>records in the transaction file will be written by different
>workstations. I
>am only supposed to show the records written by the
>workstation the user is
>using. The program must run in 36 mode, and later will be
>'converted' (by a
>package) to a 400 program.
>Soooooo, I am thinking I must use my 13 positions to store
>Batch (4) Batch
>Start RRN (4) Prev Dtl Rcd RRN (4) and a 1? position WSID.

>I need to get the RRN of the record - how? the WSID of the
>record - how?

It's been a Real Long Time, but I do not think that information is available
to a S/36 RPG program.  There are other ways around the problem though...

If you need the RRN, store it in the 13 character "free" portion of the
record.  Run a batch program to re-calculate the RRN before you start.
Sure, performance will be horrible, but it will run, and in S/36 mode.
Giving this as an alternative to the client may help explain the artificial
constraints you are having to operate under.

Obviously, the best solution is to go to an indexed file.  If that's not
possible, make this a multiple program process.
1) Read all the records for the workstation
2) Write them to a scratch file - indexed
3) As you write them, tag them "in work" in the 13 column "free" area
4) Do the subfile work over that file
5) When the user hits F7 to update, pass back through the original file and
delete all the original records and write the new ones containing the
updates.  Alternately, update the original records in place.  You could use
a sequence number to identify the records - make it the same as the work
file index.  The point being that you'll have to read the flat file and
compare/chain against your work file.

How restricted are you?

  --buck