The User Work Area (UWA) is a set of program variables declared in the host…

Concept: An application program cannot read or write stored database records directly. The DBMS holds records in its own internal system buffers, so the host-language interface fixes an agreed transfer area: a set of ordinary program variables declared inside the application, known as the User Work Area (UWA). Every individual record is copied through that area, in one direction or the other, by the database calls the application issues.

Application: The stem already fixes one end of the transfer — the UWA is declared in the host program. The other end has to be whatever actually holds the stored records, which is the DBMS. On a retrieval the DBMS locates the record in its buffer and copies it into the UWA, where the program can then read it as ordinary variables; on a store or a modify the DBMS copies the current contents of the UWA back into its buffer and on to the database. So the UWA is the communication area for individual records between the host program and the DBMS.

Cross-check: the UWA lives in the host program’s own storage, but it is filled and consumed by DBMS calls, so exactly two parties touch it — the program and the DBMS. Reading the alternatives by value confirms this:

• the host record is the record image sitting in the program’s own variables — that is what the UWA holds, not the party at the far end of the transfer, and a transfer needs two distinct parties.

• the host language is the general-purpose programming language (COBOL, C, PL/I) the application is written in. A language is a notation for writing the program, not a runtime party that stores or moves records.

• pairing the DBMS with the host record places the database engine opposite a program-side data structure instead of opposite the program that runs and issues the database calls.

Hence the User Work Area communicates the contents of individual records between the host program and the DBMS.