This was a VSAM file with multiple record layouts. One record for most screen information. One record per line of comment text, about 8 per screen. It would read the records and display the screen. When the user said update, it would read the record, update the information, and update, add, or delete the lines of text as needed. No lock while displayed on screen.
On Mon, Jun 16, 2014 at 6:34 PM, Paul Gilmartin <[email protected]> wrote: > On 2014-06-16 17:28, Mike Schwab wrote: >> Some co-workers had an application that kept doing this. Two people >> would browse the same record, and while talking on the phone each >> would enter their own updates. The second update screwed up the key >> to the various lines of text for the screen. I suggested, and it >> worked, that the last update time stamp be placed in the screen, and >> if it didn't match the updates where thrown away. Stopped messing up >> the keys. >> > "browse ... update"? Many people think of "browse" as a read-only > function, incapable of introducing any change, far less screwing up. > > ISPF LM services are pretty good at serializing to prevent such > problems. Were your victims using ISPF? > > Were these DSORG=PS/PO files, or something more exotic, such as VSAM? > And doesn't VSAM provide suitable locking mechanisms? > > What's a "record"? > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
