RE: Re: GCIC Fullscreen applications

I worked On Vollie a million years go - VSE
Roscoe no -- 
Not familiar with the fetures but if you thnk that something is missing lets put it onthe wish list
 
Roc


  _____  

From: [email protected] [mailto:[email protected]] On Behalf Of Mike Voss
Sent: Sunday, August 08, 2010 19:04 
To: [email protected]
Subject: RE: [H390-VM] Re: GCIC Fullscreen applications


  



Roc

Nice work on the FSE.

Niiiiice.

Has anybody here ever worked with ROSCOE or VOLLIE? ROSCOE was my favorite programmer's environment, and that's I imagine when I see your multiuser FLIST/FSE/CMD environment. I would love to see it develop in that direction. Just my personal opinion.
Perhaps you could use an anagram and call it ROCsoe?

Also, (Mike N,) didn't CICS run on VSE? That or perhaps VS1 might be an interesting port of KICKS (which I suppose would also imply a port of GCC. Oh well.)

Mike of NC
--- On Sun, 8/8/10, Rocky <[email protected]> wrote:




From: Rocky <[email protected]>
Subject: RE: [H390-VM] Re: GCIC Fullscreen applications
To: [email protected]
Date: Sunday, August 8, 2010, 11:49 AM


  



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: H390-VM@yahoogroups .com [mailto:H390- VM@yahoogroups. com] On Behalf Of mfnoel
Sent: Sunday, August 08, 2010 18:31 
To: H390-VM@yahoogroups .com
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 H390-VM@yahoogroups .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: H390-VM@yahoogroups .com [mailto:H390-VM@yahoogroups .com] On Behalf Of
> kerravon86
> Sent: Sunday, August 08, 2010 7:21 AM
> To: H390-VM@yahoogroups .com
> Subject: [H390-VM] Re: GCIC Fullscreen applications
> 
> --- In H390-VM@yahoogroups .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
>