From: Randy Jaye To: All
I have an RPG program that periodically displays a program message stating that the record being accessed is already allocated by another job. Does anyone know how to retrieve the RRN of the locked record or identify the user who has the lock? I would like to display the user's name on the screen so that the person who receives the message knows who has him locked out.
From: Doug Payton To: Randy Jaye
Try the QUSRTOOL program TAADBFFC when you encounter a record lock. Pass the program-status data structure to it. This program can inform the locked-out user which job has the lock on the record and gives him the ability to send a message to the workstation that has locked the record. It also lets the user send a message to the QSYSOPR message queue. It works like a charm for me. One problem-you can't bypass the lock. It must be released before you can continue. For more information, look at member LOCKMSG in file QATTINFO in library QUSRTOOL.
From: Matt Sargent To: Randy Jaye
The relative record number of the locked record, as well as the job information of the locking job, can be found in the program-status data structure in positions 91 to 170. 6 provides an example.
The relative record number of the locked record, as well as the job information of the locking job, can be found in the program-status data structure in positions 91 to 170. Figure 6 provides an example.
The information is contained in a message string. If you want to extract the record number or the job information, you will have to parse it out. However, in most cases, you can just display the text as is. It will look something like this: "Record 431 in use by job 542612/MATT/DSP41."
Since this is a formatted string, the position of the job information within the string will vary.
At one time, I had a problem with extraneous text appearing after the message. I fixed that by scanning for the period (.) and blanking out the remainder of the message.
Obtaining Information on a Locked Record
Figure 6 Locked Record Information
*. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+ A D@DATA R 9 0 REFFLD(REC/DATA MYFILE)
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online