Re: Who Is Holding Record Lock? -SQL Perspective

Is the job name copied into some part of the SQL Communications Area [the SQLCA] for the -913? The SQLERRMC perhaps? If not...

Is receiving the message CPF5027 an option? Presumably that message was sent by the database I\O program to the procedure performing the SQL.? I suppose if that message was sent instead to the SQL I\O program, then if the SQL did not move the message to the procedure performing the SQL after its receipt, then receiving the message is not directly an option; i.e. could be obtained in other ways, but "received" only with a previously obtained message mark.

FWiW locks are /transient/ such that a conflicting lock at any one moment may not still be the same, nor may there even remain any conflicting lock. One option is to perform DSPRCDLCK OUTPUT(*PRINT) [or use the equivalent API, although I do not like nor recommend that API; I do not even recall its name] in response to the sql0913, for the file being updated.

Regards, Chuck

Taylor iSeries wrote:

In traditional RPG, it was easy to display which user is holding
a record.

I SDS
I 91 170 MSGTXT
.
.
.C KEY CHAIN FILE 9990
C *IN90 IFEQ '1'
C MOVEL MSGTXT ERRMSG
C END Then send MSGTXT to the screen informing the user which job had

the record lock.

How do you retrieve this information using SQL. For example, if
the code is:

ExecSql UPDATE Library/File
Set AgMayor = ' YES', AgMayorlcd = :Today
whereAgid# = :Agid#:
If (sqlstt <> '00000');

In a record lock, SQLSTT = 57033, but how does the
program retrieve the name of the job holding the record lock?