Re: Questions about S/36 files

James,

If you are using the S/36 commands (BLDFILE and BLDINDEX), you will be somewhat limited. For example, the key on the PF must be contiguous. The key on an alternate index (aka LF) is limited to 3 keys. The field(s) will be generated by the system: F00001. If there is a key, that field will be named K00001. If there is more data after the key it will get named F00002, etc. (I think I have the correct number of zeros.)

There is no need for that, though. You can externally define the file and access internally, just as you would for a flat file.

You can certainly emulate the 36EE's logic when creating a file in DDS that would look like a 36EE file. But convenient? Not really.

By externally describing it, you can use SQL for native operations and internally define it in an RPG program.

-mark

At 11/5/2013 12:08 PM, you wrote:

A couple of questions about S/36 files, prompted by a potential new
customer whose whole native system is apparently set up around them:

First, while I've occasionally futzed around with totally flat,
non-keyed files, and while I've used program-described mode to
circumvent level-check problems on externally-described files that
change regularly, but in a manner that's under our control, I don't have
a lot of experience with actual S-36 files. Am I correct in my
understanding that an S-36 file can be both flat and keyed at the same
time? Is there a convenient way to create a file indistinguishable from
an S-36 file on a V4 or V6 box that doesn't have any S-36 emulation
installed?

Second, can SQL access an S-36 file? Is it difficult?

--
JHHL