RE: 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
>