From Walden H. Leverich
Say you read the item master row in RPG (and don't lock it).
Now you show the user the screen and let them play with the item.
Now you go to update that item, what if someone has changed the
row. In essence you were working on a "cached" copy of the item,
now it's out of sync w/the real copy.
Yes, records on screens may get out of sync with records in files, and you need to deal with that, but the RPG language environment GREATLY ASSISTS!
Records are a fundamental building block in native IBM i interfaces, which have been so successful in building business applications.
Read from table into record A. Copy record A to records B & C via simple assignment (B = A; C = A;). Write C to screen. Read screen to C. Read table to A. If (A <> B) then notify user about synchronization issue. Otherwise, update table from C.
Sometimes program P is responsible for maintaining certain sub-fields while program R is responsible for others in the same record. RPG supports reading & writing, to & from, data structures consisting of grouped subfields. The mapping is automatic, and may automatically avoid collisions between P & R. There's just GREAT SUPPORT in the language environment.
Many of RPG programmers would get frustrated discussing "presentation" layers, "business object" layers, and "database" layers, because they don't have to deal with "layers", per se. If certain business logic needs to be shared across multiple contexts, they put it in a service program. Service program S may export an interface to record C, so programs P and R can use it in their respective screens. But the interfaces are so simple and well integrated that they can't really be characterized as "layers".
If one is really bent on using ASP .Net, or Java, or PHP, or Net.Data, or some other interface as a "presentation" layer, then I'd suggest that they consider RPG for the "business" layer, at least.
Nathan.
midrange.com
