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
