Bottom line with this code the processing of modify command works consistently I now tried it 8 times in a row I'll post the code. Without the STIMER the modify command only 1 of 5
SELECT_LOOP DS 0H XC MY_ECB(104),MY_ECB CLEAR ECB AREA MVC COMMAND,=CL8'SELECT' XC MY_PARM(MY_PARM_LEN),MY_PARM CLEAR PARAMTER LIST * WTO 'ENTERING SELECT LOOP....' * STIMER WAIT,DINTVL=LTINTVLL WAIT A BIT * EZASMI TYPE=SELECT, Issue Macro X TIMEOUT=TIMEVAL, X MAXSOC=MAXSOC1, SPECIFY MAXIMUM NUMBER OF SOCKETS X RSNDMSK=RSNDMSK, READ MASK X RRETMSK=RRETMSK, RETURN FROM READ X WSNDMSK=WSNDMSK, WRITE MASK X WRETMSK=WRETMSK, RETURN FROM WRITE X ESNDMSK=ESNDMSK, X ERETMSK=ERETMSK, X ERRNO=ERRNX, (Specify ERRNO field) X RETCODE=RETCODY, (Specify RETCODE field) X ECB=MY_ECB, MAIN TASK EMB X ERROR=ERROR, Abend if Macro error X MF=(E,MY_PARM) WAIT ECB=MY_ECB L R10,CONADD GET COMMUCATION ADDRSS ECB TM 0(R10),X'40' MODIFY COMMAND POSTED BZ CK_TCPIP NO CHECK TCP IP WTO 'PROCESSING MODIFY' * USING COM,R6 L R6,COMCIBPT Point to CIB DROP R6 USING CIB,R6 CLI CIBVERB,CIBMODFY Q. IS it a Modify BNE SELECT_LOOP no; Go back CLC CIBDATA,=CL8'SHUTDOWN' Shut Down BE CLEAN_UP get out B SELECT_LOOP CK_TCPIP DS 0H CLC RETCODY,=F'0' A REAL TIME OUT OCCURED ??? BE SELECT_LOOP BH CKCONN BAL XLNK,RCCHECK B SELECT_LOOP * if value is > 0 then this a read request to be handled * * by subtask go back to main loop * *----------------------------------------------------------* CKCONN DS 0H MVC NOSELECT,RETCODY Save Number of Selected Sockets BAL XLNK,CK_SELECT Check connections B SELECT_LOOP TITLE 'CHECK SELECTION ACTIVITY.......' CK_SELECT DS 0H ST R14,SAVE14F Save link register LA R6,SOCKTBL Get Socket tbl USING SOCK_TBL,R6 SEL_LOOP DS 0H *********************************************************************** * * * check out Slected sockets * * * *********************************************************************** TPIMASK TEST, X LTINTVLL DC CL8'00000001' -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Tony Thigpen Sent: Wednesday, January 9, 2019 3:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Concurrent Server Task Dispatch issue multitasking issue What for? I think you are just making it worse. Tony Thigpen Joseph Reichman wrote on 1/9/19 1:51 PM: > Hi > > I quite don’t understand this but In my testing when I had WTO's the > modify logic would work. I now decided to put a STIMER after the > SELECT_LOOP > > I.E. > > STIMER WAIT,DINTVL=LTINTVLL WAIT A BIT > LTINTVLL DC CL8'00000001' > > > I just ran the code 6 times in a row and it worked with out the STIMER > the code would work 1 out 5 times > > thanks > -----Original Message----- > From: Joseph Reichman <reichman...@gmail.com <mailto:reichman...@gmail.com> > > Sent: Monday, January 7, 2019 3:45 PM > To: 'IBM Mainframe Discussion List' <IBM-MAIN@LISTSERV.UA.EDU > <mailto:IBM-MAIN@LISTSERV.UA.EDU> > > Subject: RE: Concurrent Server Task Dispatch issue multitasking issue > > The code bypassed the 1,000 limit size I had no choice but to chop it > up if you give me an e-mail I'll attach the program/code -----Original > Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU > <mailto:IBM-MAIN@LISTSERV.UA.EDU> > On > Behalf Of Tony Harminc > Sent: Monday, January 7, 2019 3:33 PM > To: IBM-MAIN@LISTSERV.UA.EDU <mailto:IBM-MAIN@LISTSERV.UA.EDU> > Subject: Re: Concurrent Server Task Dispatch issue multitasking issue > > On Sun, 6 Jan 2019 at 15:29, Seymour J Metz <sme...@gmu.edu > <mailto:sme...@gmu.edu> > wrote: > >> Second, MODIFY is not the only type of CIB, If the COMM ECB is posted >> then you need to process and delete the CIB, regardless of type, and >> regardless of whether you recognize the text of a MODIFY. The types I would >> expect to see are START, MODIFY and STOP. I would do a WTO for any CIB my >> code didn't recognize, but you still need to delete it. > > I agree with you, of course, but I'm not sure that that's fundamental to the > reported problem.The symptom for failing to delete the CIB would be that the > next MODIFY (or STOP or anything else) command would > get an IEE342I MODIFY REJECTED-TASK BUSY. (To say nothing of a hard > loop.) Joe hasn't told us how his MODIFYs are mostly "not working", nor if > all of them that he has issued are "valid" in that his code understands them. > > I am more suspicious of mixing async (are they really all async?) > EZASMI calls with WAITs in the same maintask flow of control. Is there > any reason for a Givesocket to be async? (For that matter is there any > reason for Takesocket or indeed any of the worker task's socket calls > to be async?) > > In the enlarged but still incomplete code snippet posted, the WAIT after the > SELECTX is commented out. SELECTX isn't going to WAIT on the Comm ECB, so who > does? > > Joe, if you want serious help with this, please post something that can > actually be assembled and run. > > Tony H. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu <mailto:lists...@listserv.ua.edu> with the > message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu <mailto:lists...@listserv.ua.edu> with the > message: INFO IBM-MAIN > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu <mailto:lists...@listserv.ua.edu> with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN