ecki/IBM-i-RPG-Free-CLP-Code
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix Readme

Browse Source
This commit is contained in:
SJLennon 2021-05-13 15:18:13 -04:00
parent 0b9cdff216
commit 76ccb67a3a
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
RcdLckDsp/Readme.md
View File

@ -1,12 +1,12 @@
# RCDLCKDSP - Displaying Locked Record Info in Interactive Programs
Older interactive programs often read a record for update, then displayed it on the screen and wait for the user to make changes. The record might remain locked for a short time while date was keyed or it might wait until after a rest break or a phone call or some other interruption.
Older interactive programs often read a record for update, then displayed it on the screen and wait for the user to make changes. The record might remain locked for a short time while data is keyed or it might wait until after a rest break or a phone call or some other interruption.
This requires less code, but is a poor technique that can increase Support/Help Desk call. It still exists in many older programs and some packaged software.
This approach requires less code, but is a poor technique that can increase Support/Help Desk calls. It still exists in many older programs and some packaged software.
When an interactive program tries to update a record that is locked by another user and the program doesn't handle it the RPG error routines kick in and give the user a confusing, and potentially dangerous, error message.
In new programs, it is much better to trap the locked record condition and handle it by calling RCDLCKDSP. It shows who has the record locked so you can ask them to finsh up what they were doing and free up the record. It allows you to retry your update or allows you to cancel what you are doing.
A better technique is to trap the locked record condition and handle it by calling RCDLCKDSP. It shows who has the record locked so you can ask them to finsh up what they were doing and free up the record. It allows you to retry your update or cancel what you are doing.
Locking information is provided in a window, like this:
@ -24,12 +24,12 @@ This is the standalone RPG program that handles the window display. It is passed
|---|---|------------|---|
|1. |Output |CL1|
||| User's reply about what to do:
|||R - Retry the IO operation that failed
|||R - Retry the IO operation that failed. Default if user just hits enter.
|||C - Cancel the program
|||D - DUmp the program and cancel
|||D - Dump the program and cancel. Hidden option for IT staff.
|2. |Input|\*
|||Pointer to the *PSDS in the calling program.
|||(A pointer is used because the *PDSD is not always the same length in the calling program.)
|||(A pointer is used because the *PDSD may not always be the same length in the calling program.)
See RCDLCKDEMO for a sample call.
@ -45,7 +45,7 @@ Call it in two separate sessions to see a RCDLCKDSP pop up a window.
## RCDLCKBAD
This program demonstates what happens if you fail to account for the record you want to update is locked by someone else. Typically the user get a message like this:
This program demonstates what happens if you fail to account for the record you want to update being locked by someone else. Typically the user get a message like this:
```Unable to allocate a record in file QCUSTCDT (R C G D F).```