I'd like to propose solutions to two problems I've experienced with file record locks and data area locks. The first problem involves how users typically respond to file record locks.
After the record wait time has expired on a file record lock, the user must answer a message. IBM has set the default reply to "C" or Cancel. If the user has not already keyed ahead (through buffering), just pressing Enter (the typical user idea) cancels the job. Instead of changing the maximum record wait time on all files, why not change the default reply from Cancel to Retry?
CHGMSGD MSGID(RPG1218) + MSGF(QRPGMSGE) DFT('R') On data area locks, the wait time comes from the default wait time for the job. Since data areas give you no retry option, try the following solution:
CHGJOB DFTWAIT(*NOMAX)
Preferably, this statement would be a part of the initial program specified in the user profile. Only users with *JOBCTL authority may run this command.
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