PDA

View Full Version : Sessions disconnect - subfile record not found



Guest.Visitor
05-09-2001, 03:04 AM
Brian, It sounds as though you have a buggy application program that's trying to access a non-existent subfile record. This is causing (probably) CPF5020 to be issued as an inquiry message. You should see it if you look further back in the job logs. The inquiry message is being replied to with a 'C' and it is this that is causing the CPF5104 followed by the termination of the interactive job. The first thing is to establish why the CPF5020 is being auto-answered with 'C'. Display one of the affected users' jobs (before they get thrown out, obviously) using option 2 of WRKJOB (Display job definition attributes) or look and see if a DSPJOB listing has been produced along with the job log and look for 'Inquiry message reply'. If it is *SYSRPYL or *DFT inquiry messages will be auto-answered. Check whether there's an entry in the system reply list (WRKRPYLE) for CPF5020, and change the reply from 'C' to 'I'. Then use WRKMSGD CPF5020 to change the IBM-supplied default reply for the message description from 'C' to 'I'. This should stop the jobs from terminating but you still have a problem with the application program - it might produce incorrect results following the subfile read error. It should be fairly easy to determine which program this is and investigate further. Hopefully your change to the message description will only need to be temporary. Dave...

Guest.Visitor
05-10-2001, 03:25 AM
Hi Dave. Thanks for the reply. The WRKRPYLE for CPF5020 is 'C' but the program is supposed to handle the error checking in this case (or so I have been told). The other thing is is that it puts out about 20 subfile not found messages before the the sessions drop if the 'C' is the issue wouldn't it drop on the first instance? Tahnk You Brian Babineau

Guest.Visitor
05-10-2001, 09:03 AM
Brian, How many CPF5104 messages are sent? This is the one that's causing the job to end and it may have been triggered by multiple instances of the previous message - I really haven't got the resources to investigate at the moment. What is clear, however, is that it is the faulty application program that is the root cause. If the error were trapped correctly you wouldn't be getting inquiry messages in the job log. Dave...

Guest.Visitor
05-16-2001, 05:34 AM
Usually I see subfile record not found error messages because the programmer has not kept track of how many were written in the first place. When reading the SFL, starting at 1, the code just keeps adding 1 to the subfile record number until record is not found. Bad coding practice. Also since a prolifically used program may spew so many low-level messages of subfile record not found, the job log gets so full the job is aborted. Maybe this is happening in your program? HTH Phil

Guest.Visitor
05-18-2001, 04:19 AM
OS V4R4 720-208C I am having a problem with sessions dropping for no apparent reason. the job logs show a CPF5104. I put a sniffer on the lines checked the TCP setup on the 400 and everything seems to be as it should. Has anyone seen this problem. A search of APARS does not show much as far as subfile and CPF5104 go. Almost all job logs show the following...... processing. Possible choices for replying to message . . . . . . . . . . . . . . . : I -- Request is ignored. Control is returned to user. C -- Request is canceled. Escape msg CPF5104 is sent. 30 05/08/01 13:03:50 QSFGET QSYS 0194 QSFGET QSYS 0194 Message . . . . : Subfile record not found. Cause . . . . . : The input operation to the subfile specified a relative record number for which no active subfile record exists. Recovery . . . : See the Application Display Programming book, SC41-5715, for subfile processing. Possible choices for replying to message . . . . . . . . . . . . . . . : I -- Request is ignored. Control is returned to user. C -- Request is canceled. Escape msg CPF5104 is sent. Thank You Brian Babineau

Guest.Visitor
05-18-2001, 04:19 AM
Hi Phil. Thanks for the info all seems to be pointing at how this application was written. One other thing that I have found is that the programs and display files etc were compiled at different levels and compiling the programs back a level seems to have resolved the issue I am now testing a few users and it seems to have worked....