Re: Long LLE list

[Greg Price]

Bernd Oppolzer wrote:
> 
> I have the following problem:
> 
> a piece of software that I'm not allowed to change due to legal reasons
> walks through the LLE list to look for a specific module.

Any chance of purging the module from the LLE chain (via
DELETE I'd expect) and then issuing a LOAD so that it is
at the start of the LLE chain, and so would be found very
quickly in any search of the LLE chain?

Cheers,
Greg

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Long LLE list

[Chris Craddock]

On Tue, Feb 16, 2010 at 2:39 PM, Bernd Oppolzer
wrote:

> a piece of software that I'm not allowed to change due to legal reasons
> walks through the LLE list to look for a specific module. And it does this
> very often. I cannot change this behaviour. This consumes 5 percent of CPU
> of some of our production regions, because the LLE list is very long.
>
> Now I'm thinking of passing control to another TCB with a shorter LLE list
> before calling this piece of software. But the overhead of ATTACHing a
> subtask every time I call this interface is far too high. A much faster
> technique
> of switching to another TCB would be needed.
>
> Do you have any idea how I could accomplish this task? This should run in
> normal user mode, no supervisor state. There might be some overhead on the
> first call, but the subsequent calls must be fast. The existing loop
> fetches the start of the
> LLE list from the own TCB, and the address of the own TCB comes from a
> fixed storage location (X'21C', IIRC). I cannot change this coding,
> unfortunately -
> well, I could, but I'm not allowed to do it.
>
> What about POST/WAIT communication between the two tasks? I guess, this
> will probably solve our CPU problem, but the elapsed time will be much
> higher.
>
> Any other ideas?
>


When you say you "can't change it for legal reasons..." do you have the
source code, or are you just looking at the load module? How would passing
control to another TCB not constitute a modification of the software? I
can't imagine that passing control to another unit of work would save ANY
cycles at all given the number of system services and trips through the
dispatcher that you would have to make to get the answer. Running the LLE
chain is a pretty small loop. There must be a spectacular number of entries
in the list, or the code must be searching the list absurdly often.

If you can't change the source, then create yourself a little look-aside
module that does something more sensible (name/token perhaps, although that
could easily use more cpu) and then zap the load module to call your
look-aside at the appropriate point in the logic - assuming you understand
what it's really doing. Presumably the program logic was expecting to
find/not find something there, so changing it to do something else might get
you further into deep water than you wanted.

-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Long LLE list

[Chris Craddock]

On Tue, Feb 16, 2010 at 10:23 PM, Greg Price wrote:

> Bernd Oppolzer wrote:
> >
> > I have the following problem:
> >
> > a piece of software that I'm not allowed to change due to legal reasons
> > walks through the LLE list to look for a specific module.
>
> Any chance of purging the module from the LLE chain (via
> DELETE I'd expect) and then issuing a LOAD so that it is
> at the start of the LLE chain, and so would be found very
> quickly in any search of the LLE chain?
>

Wow that would be living on the edge Greg! There are so many ways that could
fail...

-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Long LLE list

[Tony Lubrano]

Bernd,

When you say it is looking for a specific module, is it looking for the same 
module every time it is called?

Tony Lubrano
Product Author
NEON Enterprise Software, LLC.
p: 281.207.4922 f: 281.207.4973

What is zPrime?  Find out at www.zprime.com or just ask us!

From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Bernd 
Oppolzer [bernd.oppol...@t-online.de]
Sent: Tuesday, February 16, 2010 2:39 PM
To: IBM-MAIN@bama.ua.edu
Subject: Long LLE list

Dear Colleagues,

I have the following problem:

a piece of software that I'm not allowed to change due to legal reasons
walks through the LLE list to look for a specific module. And it does this
very often. I cannot change this behaviour. This consumes 5 percent of CPU
of some of our production regions, because the LLE list is very long.

Now I'm thinking of passing control to another TCB with a shorter LLE list
before calling this piece of software. But the overhead of ATTACHing a
subtask every time I call this interface is far too high. A much faster
technique
of switching to another TCB would be needed.

Do you have any idea how I could accomplish this task? This should run in
normal user mode, no supervisor state. There might be some overhead on the
first call, but the subsequent calls must be fast. The existing loop
fetches the start of the
LLE list from the own TCB, and the address of the own TCB comes from a
fixed storage location (X'21C', IIRC). I cannot change this coding,
unfortunately -
well, I could, but I'm not allowed to do it.

What about POST/WAIT communication between the two tasks? I guess, this
will probably solve our CPU problem, but the elapsed time will be much
higher.

Any other ideas?

Kind regards

Bernd

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Long LLE list

[Bernd Oppolzer]

Thanks for the comments so far.

1. yes, the loop is looking for the same module every time.

2. yes, it is called VERY often. And yes, there are many modules in the
LLE list (hundreds to thousands; this is a production IMS region with
virtually all the modules we have).

3. the loop is very small. I don't have the original source;
I looked at the load module and dis-assembled part of the code manually.
I know very well what the code is doing. And I already patched the loop
at first call, stored the load module address somewhere else and simply
loaded it from the saved address instead of looking it up from the LLE 
list.

This made the problem disappear. But I'm not sure if I'm allowed to put this
patch into production, because it changes the licensed part of software,
although at run time.

4. I'm not sure if the DELETE and LOAD again approach will work, because
it appears as if the entries in the LLE list are sorted by name !!!
I could imagine that there is nowadays kind of hash logic on the LLE list,
to improve search time when looking for a specific module. Maybe there
are some newer z/OS services, and the sequential lookup of the LLE list
is no longer needed. This would make sense to me - keep the old LLE list
for compatibility reason, but implement a better mechanism in parallel
(AVL tree or hash). Maybe some of the z/OS gurus on the list could throw
some light on this. If this was the case, I could maybe give the 
manufacturer
of the software some suggestions, how to improve the search at no or low 
cost.


Kind regards

Bernd




Tony Lubrano schrieb:

Bernd,

When you say it is looking for a specific module, is it looking for the same 
module every time it is called?

Tony Lubrano
Product Author
NEON Enterprise Software, LLC.
p: 281.207.4922 f: 281.207.4973
  


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Long LLE list

[Shmuel Metz (Seymour J.)]

In , on
02/16/2010
   at 10:31 PM, Chris Craddock  said:

>If you can't change the source, then create yourself a little look-aside
>module that does something more sensible (name/token perhaps, although
>that could easily use more cpu) and then zap the load module to call your
>look-aside at the appropriate point in the logic

Wouldn't that run afoul of the legal difficulties Bern mentioned?

IMHO his best options are:

 1. Ask the vendor for assistance and/or permission.

 2. Use a semipermanent subtask with a work queue.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html