RE: creating a view

From: Jeff Crosby

One example is the inventory transaction file. A lot of our inventory
transactions (receipts, adjustments, returns, transfers, etc) are handled
in
batches. When someone wants to do inventory transactions, a member is
added
to that file, the name of the member is the workstation (job) name. In
this
way, any number of users can be doing inventory transactions at the same
time without any interference with each other. I know a lot of people
don't
like multi-member files, and it may not be 'pure' from a database
perspective, but from a _business_ perspective, it works great here. (And
after all, source files are multi-member.)

Yep, very much the BPCS philosophy. Not only do people not walk on each
other, but if you lost a connection mid-batch, the user could pick up where
they left off. There are any number of reasons to use a partitioned dataset
like this.

But as Rob would probably point out, using a field in the file to identify
work data is more appropriate. We switched to that technique using a
ten-character field which could represent either the workstation or the user
ID, depending on how they wanted to segment the work. When the batch was
finally ready for posting, you would then change that field to blanks to
indicate that it was now posted. Your primary production views would only
accept records that had blanks in the work member field.

There are other ways to do this, such as having a flag that indicates the
posted status of the data. There's even a school of though in which you
have two files, one with work data and one with posted data. That way your
high availability and backup techniques can distinguish between live data
and not-quite-live data.

The bottom line, though, is that you will have to change your logic in order
to move to the DDL defined file.

Joe