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 <[email protected]> On Behalf Of
Tony Thigpen
Sent: Wednesday, January 9, 2019 3:21 PM
To: [email protected]
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 <[email protected] <mailto:[email protected]> >
> Sent: Monday, January 7, 2019 3:45 PM
> To: 'IBM Mainframe Discussion List' <[email protected]
> <mailto:[email protected]> >
> 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 <[email protected]
> <mailto:[email protected]> > On
> Behalf Of Tony Harminc
> Sent: Monday, January 7, 2019 3:33 PM
> To: [email protected] <mailto:[email protected]>
> Subject: Re: Concurrent Server Task Dispatch issue multitasking issue
>
> On Sun, 6 Jan 2019 at 15:29, Seymour J Metz <[email protected]
> <mailto:[email protected]> > 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 [email protected] <mailto:[email protected]> with the
> message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] <mailto:[email protected]> with the
> message: INFO IBM-MAIN
>
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] <mailto:[email protected]> with the message:
INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
