No, the COMM ECB is fine as is.

________________________________________
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Joseph Reichman <reichman...@gmail.com>
Sent: Wednesday, January 9, 2019 10:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Concurrent Server Task Dispatch issue multitasking issue

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

Reply via email to