S/36-Style Control Files

From: Allyn Uptain To: All

Coming from a S/36 background, I find this one-record-format-per-file is taking some getting used to. In particular, how do you handle your "control" file? We've got one file that contains things like company name and address, but it also contains Federal ID number, G/L account for payables checks, G/L account for payroll checks, G/L account for petty cash, option flags, and on and on.

On the S/36, one of my favorite ways to handle this file was to key it based on the piece of information and only store one data item per each record. For instance, I might have the records listed in 4. If I do that on the AS/400, I have to use a program-described file. But if I use externally described files, then I've got one huge record or lots of small files. Any advice?

On the S/36, one of my favorite ways to handle this file was to key it based on the piece of information and only store one data item per each record. For instance, I might have the records listed in Figure 4. If I do that on the AS/400, I have to use a program-described file. But if I use externally described files, then I've got one huge record or lots of small files. Any advice?

From: Ernie Malaga To: Allyn Uptain

Data areas are probably the best solution for your problem. I wrote an article about data areas which appeared in the February issue of MC.

From: Chuck Keel To: Allyn Uptain

You can still use non-externally described files or files that can have generic data in them. Our system uses reference files as control files. These files only have three fields. The first is a category, the second is a key and the third is a large field that contains the data. The third field can be broken down as required by using either a PF format or a program-described data structure.

TechTalk: S/36-Style Control files

Figure 4 Typical Control File

 Record Key Data 01CONAME company name 01COADR1 company address 1 01PAYCHK payables checking account# 01FEDID federal id#