Killing yourself with Virtual Storage (was ICM - Set Condition code?) 
Author Message
 Killing yourself with Virtual Storage (was ICM - Set Condition code?)

Some years ago IBM had a program called VSPC that used what methods are
avilable in MVS to do just that -- and it was a disaster, though the
reasons for this went far beyond the storage methods used by
the program.

Unfortunately, it was designed before storage isolation worked reasonably
well.  It would have been better had it just not cared, used efficent
techniques, and used MVS storage isolation to give it a fixed number of
frames.  Well, that never came about.

--Steve Myers


Quote:

[snip]
>I once raised the question wther a program that is AWARE of paging, so
>that it not just designed so as not page a lot, but also monitors its own
>paging behaviour and acts accordingly would be a good idea.
[snip]

>However, I stil think that if you want your code to be efficient but
>portable - you can not simply trust the OS. You should use tricks/tips
>that were a fact of life ages ago. It also make the programming more fun.

>--


-- Steve Myers

The E-mail addresses in this message are private property.  Any use of them
to  send  unsolicited  E-mail  messages  of  a  commerical  nature  will be
considered trespassing,  and the originator of the message will be  sued in
small claims court in Camden County,  New Jersey,  for the  maximum penalty
allowed by law.



Sun, 03 Dec 2000 03:00:00 GMT  
 Killing yourself with Virtual Storage (was ICM - Set Condition code?)

<-snip->

: You should use tricks/tips
: that were a fact of life ages ago.

Like using 2-digit fields for the year.   :-)

: It also make the programming more fun.

Especially every 100 years.  :-)

Jonesy
MainFrame IBM since 1966

No ,  I realize you did not mean *that*!

--
--
Marvin L. Jones  jonz<AT>rmi.net
Gunnison, Colorado
563 days to go until the Year 2000



Sun, 03 Dec 2000 03:00:00 GMT  
 Killing yourself with Virtual Storage (was ICM - Set Condition code?)

Quote:

>They found that every so often CICS/VS dispatched a small loop which
>actually branched around within CICS/VS nucleus etc. in 4k steps, but
>doing absolutely nothing at each location except branching to the next.
>The only reason they could imagine for this was that CICS/VS wanted
>to avoid being paged out!

There is even a SIT parameter to control how often this is done. It is indeed
to keep CICS from being paged out, the theory being that if the CICS nucleus is
paged out, when a transaction is issued there would be a lot of delay caused by
waiting for the various parts of the CICS nucleus to be paged back in.

That may be one of the explanations on why batch jobs often run better when
unnecessary CICSes are shut down, particularly on memory-constrained (i.e.,
paging) systems.

Mark A. Young



Sun, 03 Dec 2000 03:00:00 GMT  
 Killing yourself with Virtual Storage (was ICM - Set Condition code?)

:>Some years ago IBM had a program called VSPC that used what methods are
:>avilable in MVS to do just that -- and it was a disaster, though the
:>reasons for this went far beyond the storage methods used by
:>the program.

As  said - this is pretty much what I figured - WITHOUT writing down a
program. However the theoretical question is still interesting.

In suchh cases were the optimal solution isn't known - does it make sense
to write self monitoring code?

When I have some free time I may investigate this more deeply.

If anyone can tell me more on IBM's failed attempt - I'd be glad.




Mon, 04 Dec 2000 03:00:00 GMT  
 Killing yourself with Virtual Storage (was ICM - Set Condition code?)

:><-snip->

:>: You should use tricks/tips
:>: that were a fact of life ages ago.

:>Like using 2-digit fields for the year.   :-)

:>: It also make the programming more fun.

:>Especially every 100 years.  :-)

:>Jonesy
:>MainFrame IBM since 1966

:>No ,  I realize you did not mean *that*!

I enjoyed this reply!!!

However, somehow I feel that the general lesson from Y2K, which to me is
to make lengths etc. as parametric as possible wasn't learned by most.
Which will mean that Y1M or whatever is going to be hell.

And, keep in mind that not only date fields are in danger of filling up...

 --



Mon, 04 Dec 2000 03:00:00 GMT  
 Killing yourself with Virtual Storage (was ICM - Set Condition code?)

Quote:


> >As  said - this is pretty much what I figured - WITHOUT writing down a
> >program. However the theoretical question is still interesting.

> >In suchh cases were the optimal solution isn't known - does it make sense
> >to write self monitoring code?

> In the general case, self-monitoring code is "self-defeating".

> Either you have sufficient knowledge of the algorithms and facilities
> used by the system, or you don't.  If you don't, then you -can't-
> optimize program behavior effectively.  If you *do* have sufficient
> knowledge, you can 'design appropriately' from word go, and run-time
> monitoring doesn't buy you anything.

I agree that this is the normal case. However there are situations, not
all that rare, in which you do not have enough knowledge in order to
optimize your code. This is even more plain to see when you consider the
fact that the smae code may have to run in verey different cirumstances -
with varying ammount of resources like memory and I/O.

What you can do in such cases is to use rules of thumb - heuristics - in
order to perform some sort of runttime optimization.

Sometimes these techinques themselves can be proven to be optimal, but in
many cases they are still better than nothing.

A good example of self-adapting behaviour is the LRU
(least-recently-used) policy for managing paging/cache memory. The
behaviour is adaptive to different situations. LRU is is some respect
optimal.

Quote:
> This application was some of the _weirdest_ code ever seen, And, after
> it had been running for a short time, *nobody* knew where _anything_
> was, in the box. The machine, itself, knew what it was doing, but
> nobody on the 'outside' had a clue -- except that it was 'doing its
> thing'.  Made 'reading a core dump' a _real_ challenge. <grin>
> The scary part of the whole deal is that it _worked_.  Superbly.
> Exceeded original design specs by a factor of almost 4; and beat
> the manufacturer's 'theoretical maximum performance' numbers by
> about 150%.

By the way, doesn't this contradict your first remark?!

But I agree that the case you descirbe is very extreme :-).




Tue, 12 Dec 2000 03:00:00 GMT  
 Killing yourself with Virtual Storage (was ICM - Set Condition code?)


Quote:
> >A good example of self-adapting behaviour is the LRU
> >(least-recently-used) policy for managing paging/cache memory. The
> >behaviour is adaptive to different situations. LRU is is some respect
> >optimal.

> That's *NOT* adapting to different -hardware- characteristics, but to
> changes in 'data-flow'.  Which is an *entirely* different subject.

Why isn't fundumentally different?!

Quote:

> BTW, don't try to tell anybody that has 'n' storage slots, and 'n+1'
> items being accessed in circular sequence, that LRU is 'optimal'. <evil grin>

> LIFO works _far_ better in that _specific_ circumstance --  a grand total
> of 2 'faults' per cycle through the n+1 items, as opposed to 'n+1' fault.

> LRU is the 'best available', _general-purpose solution_, but it is *not*`
> 'optimal' in all circumstances.

As I said "LRU is in some respects optimal"... :-)




Fri, 15 Dec 2000 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. ICM - Set Condition Code?

2. Virtual Storage---curiosity question

3. Info requested on virtual storage support...

4. Virtual Storage

5. Virtual Storage

6. fortran77 and virtual storage problem with mvs/esa upgrade

7. Code it yourself

8. Track for last record after set filter to a condition

9. How to set initial value depending on condition

10. How to reset module storage to set value

11. Splitting 'and' conditions into multiple conditions

12. Order of evaluation of conditions in a combined condition

 

 
Powered by phpBB® Forum Software