How to check for and end a function automatically

Thanks for that port Gary, I will post all the info as soon as it happens again, it may be a few days, mods can you leave this post open until I post back.

Thanks, Joe

Joe:

I wasn't aware that an index rebuild could be canceled. That is, the job can certainly be ended; but I would expect that the actual rebuild itself would cause end-of-job to be delayed until the index was finally created. I picked up the impression somewhere years back that index rebuilds (the IDX activity itself) happened within a single MI transaction. That would explain why it takes a few minutes actually to end.

If that's true, then getting DSPJOB output _might_ be difficult. The DSPJOB command, for example, _might_ delay itself until the MI boundary is reached. But that in itself would be useful info. (I'm not sure if current releases handle MI boundaries in this area differently from years past.)

Regardless, Gary is going in the right directions, given the info so far. Just be aware that you _might_ run into a frustration or two when you attempt to gather the info for him. Be prepared for possible delays in system responses when this condition arises.

Tom

I got another one this morning, I was able to get a few screenshots which I hope will help.

Thanks, Joe

Well, from the call stack, it looks like Program SYSOBJLIB/SY0010C at line 7300 is causing the problem.  

It looks like it may be making a copy of the file into QTEMP.  Not sure why that would lock the other users, though.  Really gonna need to see the source code for that program to diagnose further.

From the WRKACTJOB, it looks like this is everyone's startup program.

Let's see if we can find the source code for this program.  Use this command to display basic info about the program:

DSPPGM PGM(SYSOBJLIB/SY0010C)

(Post that output if you have trouble)

From the call stack and the job log, ,this is an OPM CL program, so the Source Library, File, and Member should be listed on the first page.

You can use STRSEU (F4 to prompt) option 5 command to view the source code if it is still in the same location as when the program was compiled.  Be aware that it could have been moved, or it is also possible that source code was not delivered or was deleted from your system.

If that is the case we may be able to use the RTVCLSRC command to retrieve the source into any handy source file (a QCLSRC exists in QGPL that is usually OK to use).

If it is just a couple of pages, you can just do screen prints.  I suspect it is longer.  If that is the case, you can download it to a text file using the Client Access File Transfer function.  (Actions - Receive File from Host).  On the DETAILS button, select ASCII Text as the format, and have the system translate to ASCII.

Post the text file here after looking through it to make sure it doesn't contain any user profile or password info that might be confidential.  CL's usually don't but you should always look before posting to a public forum.

- Gary Patterson

Check out my EE profile:  http://www.experts-exchange.com/M_4382324.html

Joe:

Two details --

1. The time on WRKACTJOB is 09:07:57.
2. Joblog shows job start time as 08:59:08.

Your earlier description indicates that some time passes while the condition exists.

Does this example mean that practically nothing was done by the user during this session? Did this condition arise during the startup of the interactive job?

The call stack shows program SY0010C from library SYOBJLIB. I'd expect that to be something maybe like some kind of "system-wide" program that might have been written to run automatically when this user (or users in the same group or even all users) sign on. Do you know what SY0010C is intended to do? Do you have a developer who is familiar with it?

Tom

Ah. Gary's here. Sorry, didn't see you before I <submitted>. Good luck.

Tom

Hi Gary, Tom,

Here is the output from RTVCLSRC PGM(SY0010C) SRCFILE(QGPL/QCLSRC)

Thanks for the help.

I should say SY0010 is a menu on the application, each user when they signon the Application starts and loads to a specfic menu.
The error seems to occur only when the users signon - at the point were the application is loading.

The source code that you posted is for the system startup program QSTRUP.  

I'm not sure how you downloaded it, but I suspect that you got the *FIRST member of the QGPL/QCLSRC file instead of  the SY0010C member.

If you used Client Access File Transfer function, you would specify:

QGPL/QCLSRC(SY0010C)

- Gary Patterson

Check out my EE profile:  http://www.experts-exchange.com/M_4382324.html

   

Yes sorry about that here is the source - I spoke to the developer and he confirms the issue is when a user signs and and interupts the application loading e.g. hitting enter or F3 etc... causes the lock.

Would be great if there was error correction to cancel the IDX-FNCSECPF as part of the startup program.

As each user signs on to the system, it looks this program makes a private copy of the FNCSECPF file into the job's QTEMP library.  The two lines of code, below, check to see if a copy of FNSECPF exists in the current job's QTEMP library, and if it does not, it copies the version in the library name contained in the FILIB$ data area into QTEMP.  

Once the data is copied, the system will automatically build any required index, this  when you see the job going into the IDX function.  That is perfectly normal.

I'm not sure why this it taking so long to complete - my best guess is that this is a big file, but that would mean that the startup process would run for several minutes for every user.  How long does it take the average user to get through this startup process?  If every user has to wait for a few minutes for the application to get started up, then I'd say this delay in the IDX build is "normal" for this system (sloppy, but normal), and that something else is going on that is causing users to have trouble logging on.

There is a suspicious little block of code (REDISP block) that resets the STKAU$ data area to "0" if user ORION signs on when the FDSCO$ data area contains "PRR" and the STKAU$ data area contains "9".  Does ORION have to sign on after you kill a IDX job in order to allow users to sign on?  If so, this issue may have nothing to do with the FINSECPF index build at all, and that is just what you notice when you look at the jobs since it takes so long to complete.

As Tom indicated before, the IDX step would likely end in the same 3/4 minutes regardless of you killing the job or not.

It would be handy to see the source code for the SY000D display file, if you can track it down.  Maybe you can ask the developer to help you locate it.

The next time this happens, do the same troubleshooting procedure on one of the jobs that is held up and post it here: I'd like to see what it is doing when it hangs (or does it hang?  What exactly happens when you say "stops anyone else from opening the application"?)  I'd like to see the job log, call stack, open files, and locks for one of these blocked jobs, too.

I have no idea why each job would need it's own private copy of a really big  file, or why the developer would structure the application so that one user's action (or lack of action) can lock all the other users out (I suspect that it is just a symptom of poorly-designed or implemented code, and that this is a defect, and not a desirable result.)).  Sounds like the developer is aware of the issue, so we might be wasting our time here if he already knows the cause.

If that is the case, then have the developer (or if he can't another, better programmer!) fix the defect.  It is  hard to diagnose defects like this at a distance, especially when the problem is intermittent and the triggering event is a mystery.  It is usually very easy for an experienced programmer to diagnose them when they can log onto the system and observe the problem in action, and even easier if he is  already familiar with the application and the problem.

Anyway, feel free to post back if you need more help, but what you really need is to get a programmer to diagnose and fix the underlying problem.

- Gary Patterson

Check out my EE profile:  http://www.experts-exchange.com/M_4382324.html

     CHKOBJ OBJ(QTEMP/FNCSECPF) OBJTYPE(*FILE) 
     MONMSG MSGID(CPF0000) EXEC(CRTDUPOBJ OBJ(FNCSECPF) FROMLIB(&FILIB) OBJTYPE(*FILE) TOLIB(QTEMP) DATA(*YES))
                                              

1:
2:

Thanks for the detailed info Gary

Here is the answer to your questions,

How long does it take the average user to get through this startup process?
Just a few seconds for each user

Does ORION have to sign on after you kill a IDX job in order to allow users to sign on?
Yes I have to signon as ORION to kill the job

I will continue to monitor and post back as much as possible.

Thanks, Joe