Re: Fullscreen application Specs

--- In [email protected], "Rocky" <rocsystems@...> wrote:
>
> Ivan
> 
> I said in the beginning - I have no arguments with "C"
> I have written a lot of "C" and I know you can do a lot with it.
> I disagree with you that "C" is efficient on the MF.

Which MF?  S/390, z/Arch?

> I worked at a shop with 30,000 MIPS.
> I was very much involved in performance tuning. C was a killer.
> This wasn't; that long ago - maybe 5 years .

A killer because ... what? Because the application
had to do a lot of calculations?

Compared to ... what?  Not doing the calculations,
or doing the same calculations in assembler?

If it's S/390, show me some C code and the
generated assembler, and I'll be very surprised
if there is some fundamental issue with C.

> The editor was just the first task and is really 
> about 10 percent of the code.
> NO - "C" is not the proper language to do what I am 
> doing in the heavy routines.

Heavy in what way?  In my experience, the usual
bottleneck in an editor is waiting for the user
to hit enter.

> Even on a PC, where I love to work in "C", for 
> this kind of programmng I would exit to assembler.

Because ... ?

> I investigated the possibility of using "C" for 
> the user interface in the
> beginning . Rejected it for several reasons.
> Among them effeciency. 

Show me lack of efficiency please.

> Of performance and coding and work place
> environement, But mostly because most of the 
> proponents of using "C" talked
> the talk but couldn't walk the walk... 

Where the "walk" is what?

> Didn't get any real offer of help besides RTFM

I certainly didn't ask you to RTFM. I offered to
guide you through getting C operational on your
system. That's what I considered to be walk.

Oh, that plus the man years of effort required
to port the C compiler to MVS in the first place.
I would hope that counts for a walk, if not a
trot.

> And I have no idea what you are trying to say about 
> writing my own routines
> in assembler for string handling.
> Are you serious. That's the solution. I am not in 
> the mood to invent "C" 

memcpy, or macros that call memcpy, are not
really inventing C. It's just using C, as
appropriate for the task at hand, and with
assembler as the competitor.

> My project was a full screen solution in  vanilla VM/370
>  
> The difference between us here is that I agree with 
> you in theory. But only in theory.

Fundamental concept - if practice doesn't match 
theory, the theory is faulty and needs to be
corrected.

> The hard facts are that I am almost finished with 
> the application and Paul
> and it appears you also are still discussing theory.

If you dispute a theory, that I know works in
practice, then yes, I will discuss theory.

> Which is fine - But please stop making suggestions 
> about what I should Have done. 

Please stop putting words into my mouth.

I made a suggestion about what I thought was
UNWRITTEN application logic, not code already
written. (I thought) You said that you needed
to write a lot of application code, and I
RENEWED my offer to assist you with setting
up C to do that ONE BIT since you didn't
appear interested in the same offer when I
gave it before.

> ITS DONE.
> Its moot at this stage -- 

Fine. So stop arguing the point, and I'll stop
correcting you.

> I would Love to add a "C" subroutine somewhere to 
> make you all happy (And me
> ALSO) but from what I understand it will be larger 
> than all the rest of the
> apllication.  

Your understanding is incorrect, and if you had
taken up my original suggestion, you would have
seen that for yourself.

> I  remember a thread of about two weeks ago about 
> needing a special loader
> because the object code doesnt fit on  the disk properly

That is a different situation - where I was
setting up a HOSTED solution (even though I
didn't really need it), because I COULD and
I thought it was COOL. That is NOT what I
was in the process of setting you up with,
because you had ALREADY stated (from memory)
that your mainline would be assembler, so I
gave you a NON-HOSTED solution and was
about to walk you through it.

But in order to have progressed on that, you
needed to at least try out the small steps
that I laid out for you which did NOT
involve reading ANY manual.

> My loop to build a map is around 60 instructions 
> in assembler - Includiing
> highlighting and  cursor positining and decision making
> I could have written that in "C" in 35. but then I 
> would have to write
> another 800 to build the maps and simulate BMS.

If you have a situation like that, then C is not
appropriate, and I wasn't suggesting otherwise.

> I already have canned tools that do that for me 
> in assembler. So it was a no brainer.
> 
> SUGGESTION
> 
> Lets forget this discussion - Not worth the effort. 
> And getting us off the point.

Suggestion - don't make inaccurate statements and
I'll have no need to correct them.

> I have a few subroutines that still need to be written 
> - If any one wants to attempt them in "C".  I will 
> give them full support and assistance and
> information etc.etc.etc.

It's your project. If you are interested in doing
parts of it in C, I will assist you in setting up
C on the mainframe, assuming you ACTUALLY KNOW C
and are WILLING TO CODE IN C.

If you don't have the knowledge, or the will, that's
fine too, just say so upfront.

> I will also participate for the learning process.

I was attempting to teach you already.

> But if its just talk - shoulda coulda woulda - 
> then its a waste of time -

Nothing I said was about that, so on the possibly
incorrect assumption that it's me you're talking
about, please don't make more false accusations.

> and lets get off the subject.
> The application (s) are almost finished and we 
> had this discussion a month ago.

We had an inconclusive conversation about something
similar, as I recall.

BFN.  Paul.