AFAIK, a PSW key of 0 in MVS will allow waiting on an ECB of any key, but I can think of reasons to disallow it. I wouldn't even try to guess for z/VSE.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Tony Thigpen <t...@vse2pdf.com> Sent: Thursday, January 10, 2019 1:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Concurrent Server Task Dispatch issue multitasking issue Seymour, Can a z/OS program, running in key-0, wait on an ECB that is in key-8? Tony Thigpen Seymour J Metz wrote on 1/10/19 1:36 PM: > 1. It is part of the architecture that with a PSW key of 0 you can access > any storage not protected by some other mechanism, e.g., low storage > protection. > > 2. There are software requirements for particular OS services, and I don't > know what they are in z/VSE > > 3. In MVS all ECBs are equal but some are more equal than others. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of > Tony Thigpen <t...@vse2pdf.com> > Sent: Thursday, January 10, 2019 12:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Concurrent Server Task Dispatch issue multitasking issue > > 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 > > ---------------------------------------------------------------------- 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
