It’s the wait macro the caller has to be in same key as the storage key of the ECB is this true of SELECB parm
> On Jan 10, 2019, at 12:00 AM, Tony Thigpen <t...@vse2pdf.com> wrote: > > Joseph, > > My z/OS experience is still limited. Most of my experience is with z/VSE. In > z/VSE, if in key-0, I can access any other key storage. I don't know if this > is true for z/OS. Someone else will have to speak up on that issue. > > Tony Thigpen > > Joseph Reichman wrote on 1/9/19 10:39 PM: >> This my TIMEVAL >> TIMEVAL DS 0F >> TIMESEC DC F'9' >> TIMEMICR DC F'9' >> There is another problem COMECBPT is key 0 storage and MY_ECB is key 8 WAIT >> requires the user to be in the key of the ECB would I have the that problem >> using SELECB >> Second >> -----Original Message----- >> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of >> Tony Thigpen >> Sent: Wednesday, January 9, 2019 10:21 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Concurrent Server Task Dispatch issue multitasking issue >> Looking at your code, I see several issues. I think the first is your real >> problem. >> 1) There is nothing in your select (other than a TIMEOUT condition) that >> will drop you out of the SELECT processing when a MODIFY command is issued. >> So, you can enter a bunch of MODIFY commands and none will be processed >> until something happens to the one of the sockets listed in the mask areas. >> This can be fixed with (best guess based upon limited code provided): >> L R10,CONADD GET COMMUCATION ADDRSS ECB >> EZASMI TYPE=SELECTEX, 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 >> SELECB=(R10), X >> ERROR=ERROR, Abend if Macro error X >> MF=(E,MY_PARM) >> Then remove the WAIT ECB=MY_ECB. >> Your code should drop out of the SELECTEX when either the MODIFY ECB is >> posted or a socket has activity. >> 2) You code does not handle the situation where both the MODIFY ECB was >> posted *and* a socket has activity. (And, I think the issue above would make >> this happen often.) The fix is to change the two branches to SELECT_LOOP (in >> the MODIFY logic) to branch to CK_TCPIP instead. >> 3) You did not include the TIMEOUT= value. If it is set to low-values, you >> may not get the results you expect. Based on your posts, I think there may >> be an issue here. >> There are 3 distinct actions based on how TIMEOUT= done. >> a) If TIMEOUT= is not provided, you only get posted with socket activity. >> b) If TIMEOUT= points to a low-values data-element, the ECB is posted >> right away without waiting for socket activity. >> c) If TIMEOUT= points to a non-low-values data element, the ECB will be >> posted after that time period expires *or* when socket activity occurs, >> which ever happens first. >> In other words, a TIMEOUT= pointer to low-values is not the same as not >> specifying the TIMEOUT= option. Your posts make me think that you may be >> using a low-value TIMEOUT value. >> Tony Thigpen >> Joseph Reichman wrote on 1/9/19 3:36 PM: >>> 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 >>> <mailto:IBM-MAIN@LISTSERV.UA.EDU> > On >>> Behalf Of Tony Thigpen >>> Sent: Wednesday, January 9, 2019 3:21 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU <mailto: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> >>>> <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 <mailto: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> >>>> <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> >>>> <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> >>> <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 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to 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
