As far as I know, that job will run until you close the list or until the job that requested the list ends. It may take time for it to end if your job ends and hasn’t closed the list.

Ending your program shouldn’t affect the QGYSERVER job if the job that called your program is still running. Other programs in the job might use the list after your program finishes, so the list server job won’t go away.

Are you submitting your program to batch? If you are, the QGYSERVER job should end fairly soon, though it might continue until it finishes building the entire list.

If you look at the QGYSERVER job on the WRKACTJOB display, what shows in the ‘Function’ column?

You tagged the question with V5R4, and I’ve seen QGYSERVER get hung in V5R4. It was always after ending a job without closing the list. I had to use ENDJOBABN to end the QGYSERVER job. I don’t know if that’s related though nor do I know if it specific to V5R4. The only times that I know of when the list wasn’t closed was during test runs.

Tom

Tom

char *  getNextElements (char * handler , Qgy_Gtle_ListInfo_t * getListInfo,
 int next , char * receiver , errorCode_t * errorCode )
{


    QGYGTLE(receiver, TAM , handler, getListInfo, RECORSREQ,
            next, errorCode);

    if (errorCode ... 
        return 0 ;
    }

    return receiver ;

}

This job QGYSERVER will be end at the final of the execution ? because still remains

…or when you’re finished with it and don’t want any more entries from it.

Can you show how getNextElements() calls QGYGTLE?

Tom

Tom

 do {
	ptr = getNextElements(handler, &getListInfo, recordsRtd, receiver, &errorCode);

	if (getListInfo.Info_Complete == 'C' || getListInfo.Info_Complete == 'P') {
		for (int i = 0; i < getListInfo.Records_Returned; i++) {
			
			strncpy ( qualifObj.objLib , ((Qgy_Olobj_RecVar_t *) ptr)->Obj_Lib , 10) ;
			strncpy ( qualifObj.objName , ((Qgy_Olobj_RecVar_t *) ptr)->Obj_Name , 10) ;

			module3.method2(&qualifObj);

			if (strcmp(module3.method1(), "*YES") == 0) {
				module2.method1(&qualifObj);
			}
			ptr = ptr + getListInfo.Record_Length;                            
		}
	}
	handler = getListInfo.Request_Handle;
	recordsRtd = getListInfo.First_Buffer_Record + getListInfo.Records_Returned;

	printf(" %d + %d - 1 < %d  &&  [%x] n ", getListInfo.First_Buffer_Record, getListInfo.Records_Returned, getListInfo.First_Buffer_Record + getListInfo.Records_Returned - 1, getListInfo.Total_Records, listInfo.List_Status );


} while (getListInfo.First_Buffer_Record + getListInfo.Records_Returned - 1 < getListInfo.Total_Records && listInfo.List_Status != '2');

the printf … : 1 + 70 – 1 < 70 && [46] // this is strange 1 + 70 – 1 < 70 … but with the single *PGM , which works correctly, it has the same output, nevertheless still do the remain cycles until get all the elements :S

Yes, it’s possible; but I can’t think of a reason it would make a difference. Without seeing the code, there’s no way to know what would be happening.

Assuming everything is coded okay, calling a procedure in a different *MODULE in the same program shouldn’t make a difference for an ‘Open List…’.

Tom

As you might know, that number is the binary value of a 4-byte sequence of blanks, x’40404040′. It would likely indicate that nothing was returned and that the errorCode values probably ought to be checked. Of course, that’s a reverse of the way things should be…

Check errorCode first, then…

But you’re getting it working. Post back if more problems appear.

Tom