RE: Re: SixPacks mods for GCIC users

Dave – Paolo – Gregg - ALL

 

You definitely hit on a problem.

I am well aware of the issue but I still  think 65 seconds for three
thousand lines is extremel. Probably a another problem as well.

Even with the ineffecieent getmain logic.

 

Actually that’s not a real GETMAIN –

 

Remember that GCIC is/was designed to be a Multi-user application. And as
such storgae control was a real issue for me.

Design and reality are quite different it turns out.

 

Right at the start of GCIC it does a real getmain of a large chunk of
storage – Module GSVC, and then all the other GETMAINS are just assiging and
releasing pieces of that large chunk. 

In the maclib you have a GETMAIN macro which is not the real one, but which
calls internal routines, and a GETSTRG macro which is the real getmain
macro.

 

Since there are so many getmains and freemains in the logic I decided I
could handle them more effeciently if I did it with my own routines.

And since this is only a 16M machine and  the application is designed to
support multiple users ( I have had it working with 30 simultaneously – Not
the editor, but the real application I based it on)

I was very careful about storage consumption.

 

I applied the same logic to the editor on each GET of a record  I did a
separate GETMAIN and when freeing up I did a separate FREEMAIN. (my
routines)

 

In my private storage table I have the length of each chunk of a storage
acquired and the subtask id ,

As I remember it, my freemain routine does not look at the length supplied
on the MACRO it looks at the address and the user subtask id

 

If the user issuing the freemain comes from the same subtask that acquired
the storage and the SAME ADDRESS as a previous acquire then the whole Chunk
is deleted.

If not, nothing happens. No RC.

 

There are several places in the file logic where individual records are
deleted and added.

Loading a file is obviously much faster. And deletng a file also using just
one getmain/freemain for each funtion as you are now doing.

Get enoough for the whole file in the GTABLE module.

 

But did you change the logic in the INSERT  and DELETE and COPY and PASTE
routines as well.

Here the logic gets complicated….

 

I think that if you didn't handle this, in your new logic, if you delete the
first record in the file, you might delete the entire file from memory with
your logic :-)

That’s just from my memory---

 

And On the other hand, when you exit a file, if you do not do it on a record
by record basis, you might not be deleting the storage acquired for the
records that were added individualy by COPY and INSERT and PASTE..

 

Actually when you PF3 out of the task completely all the storage acquired by
that subtask is deleted. 

Then a DIAL into the task again again should not find.and residual storage.

 

My experience on my Windows box (fast box but not special) – is that for a
file of 2000 – 3000 records they load rather quickly – not fast – but not 65
seconds either.

Loading a large dump can take a half a minute.

 

Loading a normal assembler program – a second or two.

That was my trade off for keeping the logic a little simpler.

 

But I agree with you that it can be annoying if you want to look at a
listing.

 

I like your routine and idea, but it will need a lot of refining..

We have an issue of REUSING STORAGE IN THE SAME TASK.

If you load a large file of 10000 records and then do a delete of  records 1
to  5000 how are you going to free up that storage?

For the same task I mean 

 

If you don’t free it up and then do ADD – COPY PASTE wlll need  more storage
(how do we handle that)?

A series of DELETES and ADDS or PASTES will eventually finish all the
storage while in reality you might only need the original 10000 lines.

 

I think its more complicated then just doing the one large GETMAIN in the
GTABLE module.

But I'd like to make it faster – So if you want to continue this discussion
I will be happty to get involved.

 

Anyway glad to see that someone is actually using it

 

Rocky

 

 

 

 

 

  _____  

From: [email protected] [mailto:[email protected]] On Behalf Of
paoloG
Sent: Thursday, November 04, 2010 18:09 
To: [email protected]
Subject: [H390-VM] Re: SixPacks mods for GCIC users

 

  



--- In [email protected] <mailto:H390-VM%40yahoogroups.com> , Dave
McGuire <Mcguire@...> wrote:
>
> On 11/4/10 10:54 AM, Gregg Levine wrote:
> >> Often I find fun in installing and testing Hercules on small
> >> appliances, tiny computers, NAS and so on.
> >>
> >> Recently I bought a D-LINK DNS-323 for a bargain price (about
> >> 75 Euros without HD) and I installed Hercules on it.
> >>
> >> Based on a 500 Mhz ARM processor it has a perfomance of 1-1.5 MIPS
(more or less the same as a 4341-2 of 1980); this is acceptable to me as I
like to have some wait time after issuing a command (it remembers me of good
old times;-).
> >>
> >> So I decided to test GCIC in this environment, and I
> >> was surprised by the time required to start BROWSE or
> >> EDIT function; for example starting BROWSE of GEDIT ASSEMBLE
> >> file (3742 lines) required about 65 seconds; the same for
> >> starting EDIT.
> >>
> >> Even exiting from BROWSE OR EDIT required about 12 sec.
> >>
> >> The same functions in a VM/SP environment(using BROWSE and XEDIT)
> >> give a 0.1-0.4 seconds response time.
> >>
> >> I noticed that starting BROWSE in GCIC has a path lentgh of about
> >> 60M instructions, while the BROWSE of VM/SP has a 100k instructions
> >> path length.
> >>
> >> Surprised by such a behaviour I looked into the code of GCIC,
> >> and discoveved that the file to be BROWSED or EDITED
> >> is read into memory by the same routine in GTABLE ASSEMBLE module;
> >> for each line read is issued a GETMAIN to get an area of
> >> 8 + LRECL length.
> >>
> >> I suspected that the poor performances were related to all
> >> these GETMAINs, so I tried a quick and dirty correction:
> >> I acquired an unique area of 500k at the beginning of the routine
> >> and modified the code to cope with this unique area.
> >>
> >> I got a response time of 3 sec (instead of 65) and exiting
> >> from BROWSE or EDIT is almost immediate.
> >>
> >> Hoping this may be useful to the developer to improve an already
> >> fantastic program!
> >
> > Yes this is useful. Very useful in fact. It means we have moved
> > forward in what we can use Hercules on. Now I'm not a fan of D-Link,
> > but in this case the fact that you've got it running on that family of
> > NAS devices suggests that anyone can do that.
> 
> Howdy Gregg. Hercules runs on pretty much any platform that supports 
> Linux or another UNIX-flavor OS. This means it can run on pretty much 
> anything that has an MMU and supports enough RAM and mass storage. This 
> has been the case for a long time. It's neat stuff.
> 
> That said, though, I'm pretty sure Paul was actually talking about 
> his GCIC buffer management optimization, whether THAT would be useful or 
> not.
>

Dave,

I'm pretty sure you're right:-)
I reported running Hercules and VM/370 on D-LINK NAS just to explain why I
had so low MIPS performance - which anywhow made more evident the problem in
GCIC.
On my PC with 40-50 MIPS the problem is less evident; but If I had a 4341-2
GCIC would be unusable.

Regards

Paul

> -Dave
> 
> -- 
> Dave McGuire
> Port Charlotte, FL
>