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> 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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
