Re: S/36 Flat file question -- MIDRANGE-L

With SQL it's essentially the same as with DDS - instead of using CRTPF and CHGPF - you simply use CREATE OR REPLACE TABLE.

As long as there are no more advanced features like referential constraints or triggers on that table, there isn't so much more to do.

In 2026 I wouldn't recommend to create another DDS based physical file. I not only recommend to create only SQL tables - I also recommend to replace each and every DDS based PF today with a SQL table, and define a DDS based LF as it's replacement, with the same record format and level id.

As for access with RPG program defined F- and I-specs - they simply do not care about record format level ids. So be really careful to do that.

My recommendation is, to first find every program that reads or writes the file. Extract the internal definitions - and compare/merge them. Then replace the program defined files with externally defined files - so that you don't have to care about that any further.

What I really wouldn't recommend is, doing the replacement and field extensions in one step. The replacement is complex enough - so better get this done, before changing field sizes or adding new columns.

HTH
Daniel

Am 07.03.2026 um 11:22 schrieb x y <xy6581@xxxxxxxxx>:

Assuming this file has one record type--and it is not unusual to find a
dog's breakfast of data formats in S/34+S/36 files--I urge you to create a
DDS (or SQL) database (physical) file that exactly matches your S/36 data.
You copy your S/36 data into the database file using FMTOPT(*NOCHK). Then
you can build your logical(s) over this file and run SQL over it. A
significant benefit of this approach is that it simplifies the task of
adding new columns and changing the attributes of existing columns. If you
use DDS to create the file, you add/change/drop columns by using the CHGPF
command with the DDS source member, and you can do multiple changes at
once. if you use SQL to create the table, the steps are a bit more
cumbersome but the process is essentially the same. I've been doing
conversions and application reengineering for 46 years and this is the
right way to go if you can.

OTOH, if other constraints don't allow moving the data into a database
file, you can create a logical over a S/36 flat file by using the SST
(substring) function like this in your LF specification:

APPID I SST(MBNAME 1 2)
APPPGM I SST(MBNAME 3 1)
APPNBR I SST(MBNAME 4 3)

You'll use SST to break the one big record--in this case, the field is
MBNAME-- into individual fields. My example shows breaking up a member
name into a group name, a member type, and a sequence. Use the derived
names--APPID, APPPGM, APPNBR--for selection and ordering (keylists). I
haven't used SST in quite some time and packed numerics might require some
imaginative processing. Note that the derived fields are read-only--you
can't change them through the logical file.

On Fri, Mar 6, 2026 at 10:39 AM DEnglander--- via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> wrote:

I have a S/36-era flat file that I am working on. It has one "field" in
it, and the file name, record format, and the one field are all the same
name. The file is created with a CRTPF statement with no DDS and using the
RCDLEN parameter.

I want to know if it is possible to somehow create a "compatibility" style
LF over this, and update the flat file to a DB2 table or a DDS PF if
needed. Fields need to be enlarged and added.

I can't get an LF to compile using the file name, field, and format all
the same name. Has anyone done this: Create an LF to mimic a flat file
over a DB2/DDS file? I have done it successfully before over an existing
DB2/DDS file, but never a flat file.

Thank you,

Doug

"CONFIDENTIALITY NOTICE: This e-mail transmission (and/or the attachments
accompanying it) contain confidential information belonging to the sender.
The information is intended only for the use of the intended recipient. If
you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution or the taking of any action in reliance
on the contents of the information is strictly prohibited. Any
unauthorized interception of this transmission is illegal under the law.
If you have received this transmission in error, please promptly notify the
sender by reply e-mail, and then destroy all copies of the transmission."
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.