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
