Re: GCIC Fullscreen applications

Cool - do you have something like RET=USE to provide a return without the enqueue if it can't be obtained (instead of waiting until it is)?

--- In [email protected], "Rocky" <rocsystems@...> wrote:
>
> Mike
>  
> GENQ  kuku
> GDEQ  kuku
>  
> Which are actually SVC calls to my kernel
>  
> will enque and deque the  logical resource KUKU
>  
> Will put any other task that does an enq on that resource into a wait state
> until the deque is issued by the enquing task
>  
> all other tasks will continue to work
>  
>  
> Roc
> 
> 
>   _____  
> 
> From: [email protected] [mailto:[email protected]] On Behalf Of
> mfnoel
> Sent: Sunday, August 08, 2010 18:31 
> To: [email protected]
> Subject: [H390-VM] Re: GCIC Fullscreen applications
> 
> 
>   
> 
> KICKS is written almost entirely in GCCMVS, and many of it's routines are
> used recursively (meaning they call themselves, either directly or in some
> chain of calls). And it uses PCPCLIB all over the place (carefully!)
> including in the recursively called routines.
> 
> One of the reasons it's written almost entirely in GCCMVS is that the
> compiler provides pretty good inline assembler capability, meaning you don't
> have to resort to another standalone assembler routine everytime you turn
> around. Here's quick example, doing an enqueue within a C routine...
> 
> if (csa->enqscope[6] == 'S') {
> __asm__ (
> "L 2,%1\n\t"
> "L 3,%2\n\t"
> "ENQ ((2),(3),E,44,SYSTEMS),RET=USE\n\t"
> "ST 15,%0"
> : "=m"(rtn)
> : "m"(qname),"m"(rname)
> : "0","1","2","3","15"
> );
> }
> 
> I think with some understanding of reuseable/reentrant/recursive coding you
> can use GCCMVS almost anywhere you could use assembler. I'd be amazed if the
> CMS version broke such functionality -- but of course I'm amazed by stuff
> everyday...
> 
> --- In [email protected] <mailto:H390-VM%40yahoogroups.com> , "Joe
> Monk" <joe.monk@> wrote:
> >
> > Paul -
> > 
> > How is the sort function supposed to work in a multi tasking envrionment,
> if
> > it cant be *arbitrarily* reentrant?
> > 
> > Joe
> > -----Original Message-----
> > From: [email protected] <mailto:H390-VM%40yahoogroups.com>
> [mailto:[email protected] <mailto:H390-VM%40yahoogroups.com> ] On
> Behalf Of
> > kerravon86
> > Sent: Sunday, August 08, 2010 7:21 AM
> > To: [email protected] <mailto:H390-VM%40yahoogroups.com> 
> > Subject: [H390-VM] Re: GCIC Fullscreen applications
> > 
> > --- In [email protected] <mailto:H390-VM%40yahoogroups.com> , "Joe
> Monk" <joe.monk@> wrote:
> > >
> > > Just give up. He's already admitted that its not doable.
> > 
> > I admitted that *what* is not doable?
> > 
> > > >> There would be a lot of extra baggage required to force an 
> > > >> arbitrary C program to be reentrant, baggage that is not yet 
> > > >> available.
> > 
> > Forcing an arbitrary C program to be reentrant?
> > 
> > Yes, quibbling aside, that isn't possible.
> > 
> > But in the environment he is thinking of using it in, he doesn't need it
> to
> > be an arbitrary C program. He can write his C code so that it's naturally
> > reentrant, and doesn't use library functions, except perhaps the ones that
> > are able to be made available in a non-hosted environment.
> > 
> > BFN. Paul.
> > 
> > 
> > 
> > 
> > ------------------------------------
> > 
> > Yahoo! Groups Links
> >
>