HDTenEightyP/NetNews huggingface dataset:
From: nikolaid@CC.GATECH.EDU ((Ioanis Nikolaidis))
Newsgroups: bit.listserv.hellas
Subject: onoma mhxanwn
Date: 15 Oct 92 21:01:09 GMT
Reply-To: "(Ioanis Nikolaidis)" <nikolaid@CC.GATECH.EDU>
Organization: Georgia Institute of Technology, College of Computing
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Location: Microelectronics Research Center (MiRC), H-2 (1st Floor)
Telephone: (Off.) + (404) 853 9910-1, (Fax) + (404) 853 9378
X-Mailer: ELM [version 2.3 PL11]
Comments: To: "(Kafenes 'To Ellhnikon')" <hellas@brownvm.brown.edu>

To agapimeno mou onoma gia mhxanhma einai:
"Nemesis"

Bary kai ashkwto -- kanei gia file-server ;-)

Giannhs
GaTech/Atlanta

ps. Sthn Bellcore exoun ola sxedon ta Ellhnika nhsia san
machine names. Ta ellhnika nhsia einai prosfiles thema kai sto
pan/mio patras an kai ekei eixame ksekinhsei mia paradwsh me
onomata "ekdidomenwn/elafrwn gynaikwn" (sapfo, frini, lais klp.)
Ekane pio eykolh thn epikoinwnia .. se stigmes pou thelame
na treksei to programma ("Ela moro mou, kane to kane to") kai
otan blepame ta core dumps ("Ton pairneis palipoutana, gamw tha
giagias sou to mpougadokofino") klp klp
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: bit.listserv.hellas
Date:         Tue, 6 Oct 1992 23:54:16 EDT
Reply-To:     "Nick Gavrielatos" <ucnick@SOCRATES.UMD.EDU>
From:         "Nick Gavrielatos" <ucnick@SOCRATES.UMD.EDU>
Subject:      PFK, kane mas ligaki "tsou-tsou"
Comments: To: hellas@brownvm.brown.edu

PFK - Tsoutsounoleugie olkhs:

Ekeino pou petaei sta sigoura einai oxi h omada sou(pou den exeis)
alla to aeroplano pou 0a se ferei sth Nea Yorkh tis prosexeis
meres... mhpws endiaferesai na mas anakoinwseis etaireia, pthsh,
kai wra afiksews??? Skeftomai na kalesw thn mpanta omofulofullwn
na se kalwsorisoun... Eimai sigouros pws gia sena 0a paiksoun tsampa!

Epeita pou ksereis, mporei namai kai egw ekei... panta ntumenos
sta maura mou, panta etoimos na dw posh maggia kai tsampouka
exei kaneis oxi mesa ap ta koumpakia, alla FACE TO FACE!!!


Sunexizoume... sta gene0lia mou eixe katebei o Yiannis o Koutalos,
kai eixame paei mazi me allous eksw. Entos twn allwn mou eipe
pws ton exeis apeilhsei kai mallista epaneilhmmena, pws "0a tou
spaseis ta moutra" mono kai mono epeidh se eixe kanei koskino
se kati politikosuzhthseis... Politika diafwnw mazi tou, alla
auto den exei shmasia. Auto pou exei shmasia einai auto pou
sou exw ksanapei palia, kai pou paei kapws etsi:

Thn epomenh fora pou exeis to PMS sou,
thn epomenh fora pou 0eleis na spaseis ta moutra kapoiou,
thn epomenh fora pou 0eleis na metrhseis th maggia sou
thn epomenh fora pou 0eleis na gnwriseis ton pragmatiko tsampouka sou

ELA KAI BRES EMENA MWRH PEO0HLASTRA!!!!
ELA KAI BRES EMENA!!!

Oxi pws 0elw na to paiksw prostaths tou Yiannh tou Koutalou,
alla brhkes na poulhseis tsampouka se ena prao kai hsuxo tupo,
pou den exei pote tou peiraksei kanena. Me mena omws ta pragmata
allazoun, giati opws isws ksereis(den ksereis alla 0a ma0eis)
den eimai oute enas aplos alhths tou limaniou, oute kan o mesos
aisxros nuktobios... Kai ekei na doume poses samprines bastane
ta blefarotsinora sou...


Nikos Gavrielatos
To Sixameno Plasma
ucnick@socrates.umd.edu
From: yiannis@BINKLEY.CS.MCGILL.CA (Ioannis REKLEITIS)
Newsgroups: bit.listserv.hellas
Subject: Re: I taberna tou Mparmpa Giwrgh
Date: 13 Oct 92 21:52:05 GMT
Reply-To: Ioannis REKLEITIS <yiannis@BINKLEY.CS.MCGILL.CA>
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Comments: To: tassos@art.dnet.nasa.gov
Comments: cc: HELLAS@brownvm.brown.edu

Me aformh thn eidhsoula...

...Otan tis nuxtes kruwnw kanw mia proseuxh
   Na mhn einai oi nuxtes pageres sta El Zatar
   Na mhn einai oi nuxtes pageres sta El Zatar

   Den kruwnoun ekeinoi pou pote den rwtoun
   kai gia marka 'h dollaria makelio ksekinoun
...
Alhtheia pws "distinguished" autoi oi tupoi eksoplizontas tous
prwin sunergates twn germanwn kai diwkontas osous eixan antistathei?

Yiannis
"Antistash ekane o ELAS
 kai oxi o kathe Ralhs o GermanoTsolias"
From: MG543C@GWUVM.BITNET (Stratos Safioleas)
Newsgroups: bit.listserv.hellas
Subject: e-mail guide
Date: 9 Oct 92 17:22:35 GMT
Reply-To: "Stratos Safioleas" <MG543C@GWUVM.BITNET>
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Comments: To: hellas@uga.bitnet

Xairete!

To exei pei ndn o Lewvidas, kai va to 0umisw kat' arxnv,
n teleutaia ekdosn tou "Spectrum" (Oktwbrios 92) exei eva
e3airetiko afierwma sto e-mail kai stis epidraseis tou
stnv avaptu3n tns texvologias, tnv e3eli3n tou, kai tis
duvatothtes kai pi0avotntes pou uposxetai se sxesn me
epikoivwvia, politikn, oikovomia klp.

To IEEE parexei dwreav odngo (Guide to Internet) pou mporeite va
tov zntnsete stelvovtas mail stn dieu0uvsn:

email.guide@ieee.org

Sas afnvw kai xairomai pou ta kouiz pou
gemisav tn lista ediw3av tis brisies (!)


Stratos kai Kurstratos
     Di kai Ci

        kai polu broxn

PS. Diw3te ta kouiz, kai ferte tis brisies re   :-)
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.hellas
Date:         Sat, 10 Oct 1992 21:49:15 +0100
Reply-To:     v.narinian@IC.AC.UK
From:         v.narinian@IC.AC.UK
Subject:      Anekdoto
Comments: To: hellas@auvm.american.edu

Two farmers are standing by the side of the road doing nothing when a
man in a mercedes comes driving in. When he sees the farmers he steps
on the brakes and stops in a cloud of dust. He opens the window and
asks:
"Schuldigen, sprechen sie Deutch?"
The farmers look at each other and look as if the didn't understand.
"Francais?", says the man in the mercedes, with the same respons.
So he tries spanish, italian and hungarian with the same effect.
When nothing helps, the man looks irritated and drives off in a new
cloud of dust.
"Maybe one should learn another language", says one of the farmers.
"What for?", says the other. "That guy spoke at least five languages,
and what good did that do?".

----
Vartan
From: J.G.Bryan@bham.ac.uk (Graham Bryan)
Newsgroups: bit.listserv.vmesa-l
Subject: Re: BEWARE, strange system restart behaviour with VM/ESA 1.1
Date: 7 Oct 92 08:57:28 GMT
Organization: The University of Birmingham, England


Had a response back from the development people about this situation
which you might be interested in (please note that the following is
my interpretation of what our support center said).

It would appear that when you hit an error in warm start processing
and see the following messages

     HCPASK9205A Invalid warm start data encountered.
     HCPASK9205A No files have been deleted yet.
     HCPASK9205A To change to a force start, enter FORCE.
     HCPASK9205A To stop processing, enter STOP.

The 'force start' refered to in the message IS NOT the same sort of
force start  that you get  when you type  FORCE in response  to the
initial 'START ((WARM|FORCE|COLD).....' message.

The main difference appears to be  that the new type of force start
DOES  NOT give  the operators  a  'spool file  summary status'  and
certainly DOES  NOT give the operator  a change to stop  the system
initialisation.

To be fair to IBM the  'Systems Operation' manual does say to check
for offline SPOOL  volumes if the warm start fails,  but then again
the manual DOES NOT say anything about the different sorts of force
start,  and doesn't  even  mention the  HCPASK9205A message  should
above.
From: RMCCU@CUNYVM.BITNET (Robert Chambers)
Newsgroups: bit.listserv.vmesa-l
Subject: Re: 3211 Support in 1.1
Date: 8 Oct 92 14:44:04 GMT
Organization: CUNY/UCC VM Systems

In article <VMESA-L%92100808431341@UAFSYSB.UARK.EDU>, Fran Hensler
<FJH@SRU.BITNET> says:
>
>Also, the Conversion Notebook states that remote BSC 3274's are not
>supported thru CLUSTER and TERMINAL macros.  The terminals must now
>be defined to VM/Pass-Through.

true

>Does anyone know of an alternative to VM/Pass-Through?

VTAM.

We had a few clusters like this and converted them all to be PVM clusters
which worked pretty flawlessly.  This was a minor glitch to converting
all other things considered.

>Francis J. Hensler, CDP                     BITNET: FJH@SRU

Robert
From: dboyes@IS.RICE.EDU ((David E Boyes))
Newsgroups: bit.listserv.vmesa-l
Subject: Re: VM on RS/6000
Date: 15 Oct 92 18:25:33 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Comments: To: VMESA-L@uafsysb.uark.edu
              at Oct 15, 92 10:11 am

Sam Drake said:
> >> Nor does MACH, to my understanding, allow
> >> other operating systems (such as MACH) to run under it; it does not
> >> virtualize the CPU's supervisor state; it simply emulates the system
> >> calls that various operating systems provide to problem state
> >> programs.

I said:
> >Operation of multiple OS servers is a stated design feature of
> >the Mach 3.0 microkernel. The Unix server and the DOS server
> >already coexist on the same microkernel,...

Sam replied:
> That's true, but it's not what I claimed.  I claimed that MACH did not
> allow multiple operating SYSTEMS to run under it (as CP does).  The
> "Unix server" that runs under MACH is not bootable on the real hardware.

At one point in it's existance, AIX/370 could not boot on the
real hardware, but would run as a guest under CP.

If you measure the capability from an application standpoint -- eg, I have
application Z that requires OS Y, and I have a machine running
Mach with a OS server for OS Y, then it's transparent to me
whether the OS Y support is native or running in a emulator. Mach
permits concurrent OS server support for multiple OS's, which is certainly
analagous to the virtual machine concept. The Mach microkernel
provides services to servers that are very similar to the CP
services, and (my opinion) are somewhat more generic than the CP
services. OS servers are isolated from each other unless they
elect to be aware of other servers interacting with the
microkernel.

My point was that the ideas and capabilities are very similar.

> Sam Drake / IBM Almaden Research Center
From: R0466@VMCMS.CSUOHIO.EDU
Newsgroups: bit.listserv.vmesa-l
Subject: (no subject given)
Date: 15 Oct 92 20:52:11 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Comments: To: VMESA-L%UAFSYSB.bitnet@VMCMS.CSUOHIO.EDU

Regarding the use of cache behind a 370 VM system.  I understand the problems
with sense information returned that is not supported by the operating
system.  I have, however, seen a file on a mainframe BBS that claims to
allow us to do just that.  I haven't looked at it yet, but it is on
my to do list.

Other than that, I agree with Mr. Whitman.


-Kim Cooper
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: IBM Almaden Research Center
Newsgroups: bit.listserv.vmesa-l
Date:         Tue, 13 Oct 1992 15:14:57 -0800
From:         Sam Drake <drake@ALMADEN.IBM.COM>
Subject:      Re: VM on RS/6000
Comments: To: VMESA-L%UAFSYSB.BITNET@ucbvax.Berkeley.EDU

In article <921012185942.vmesa-l.netforum.interest@almvma.vnet.ibm.com> you wri
te:
>Does anyone know of an IBM plan to support VM on the RS/6000 architecture?

I am not an official spokesman of IBM, and cannot speak authoritatively
on this issue, but I think it is highly unlikely that you will see a VM
product on the RISC System/6000.  VM was not written with portability
to instruction sets and architectures other than S/390 in mind, and so
a port would be very expensive.

IBM already sells a line of MicroChannel based S/390s that can run VM,
the 9371s.  What would you expect to get out of VM on a '6000 that you
wouldn't get from a 9371?  (I'm just curious.)

Now AIX *was* written with portability in mind, and so you can run AIX
under VM on your S/390 computers quite nicely.  But taking VM the other
way would be rather more difficult.

Sam Drake / IBM Almaden Research Center
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.vmesa-l
Date:         Tue, 13 Oct 1992 09:49:14 EDT
From:         "John A. Pershing Jr." <PERSHNG@YKTVMH.BITNET>
Subject:      VM on RS/6000
Comments: To: IBM-MAIN@RICEVM1.BITNET
Comments: cc: JEISZNER@INDYCMS.BITNET, VMESA-L@UAFSYSB.BITNET


I couldn't comment on any of IBM's future plans (or lack thereof), even
if I knew them.

However, suffice it to say that VM is *only* supported on System/370
and System/390 architectures.  What you saw at SHARE is a S/370-on-a-
card that happens to plug into a MicroChannel, and which uses the PS/2
(running special code) as an I/O processor.  So, you didn't really see
VM running on a PS/2; what you saw was VM running on a 370 which
happened to be housed inside of a PS/2.  A subtle but important
distinction.

      John Pershing                             pershng @ watson.ibm.com
      IBM Research, Yorktown Heights            PERSHNG at YKTVMH.BITNET
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.vmesa-l
Date:         Wed, 14 Oct 1992 01:27:24 +0100
From:         Eric Thomas <ERIC@SEARN.BITNET>
Subject:      Re: VM on RS/6000
              13 Oct 1992 20:05:16 EDT from VM/ESA Discussions <VMESA-L@UAFSYSB>

On Tue, 13 Oct 1992 20:05:16 EDT Leonard Boyle <LENBOYLE@CCVM.SUNYSB.EDU> said:

>I think that  many people think that the price-performance  of the 9371s
>is not good.

Very true,  and I'm afraid  I can't think of  any reason why  the RS/6000
version  would fare  any better.  Remember, the  PC or  AIX machine  only
serves as a  service and I/O processor; their CPU  power is NOT available
to the 370  machine, which runs its  own processor on its  own board. The
development costs  would be  presumably much  lower on  the PC  since IBM
already  has working  code for  that, which  would only  need adjustments
rather than a total rewrite.

If I had to implement this sort of  things I'd get an Alpha chip from DEC
(300 MIPS, sure these are do-little  RISC instructions but the chip costs
1500 bucks and  does run 150Mflops after all) and  write a well-optimized
370 interpreter, using VMS for the  physical I/O. I'd have the full power
of VMS available during  development, including their excellent debugging
environment. VMS  is a reliable operating  system (banks use it)  and the
VM+VMS combination would  be very interesting to have  (you don't believe
me? Just take a look at DEC's software catalog and COUNT/SNA/*).

  Eric
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Slippery Rock University - Computer Center
Newsgroups: bit.listserv.vmesa-l
Date:         Thu, 8 Oct 1992 09:22:24 EDT
From:         Fran Hensler <FJH@SRU.BITNET>
Subject:      3211 Support in 1.1

The VM/ESA 1.1 Conversion Notebook (P. SP-26) indicates that the 3211
printer is no longer supported.  However, the CP Planning and Adminis-
tration manual (p.391) says that it is supported.

Can someone tell me which is correct?

Also, the Conversion Notebook states that remote BSC 3274's are not
supported thru CLUSTER and TERMINAL macros.  The terminals must now
be defined to VM/Pass-Through.

Does anyone know of an alternative to VM/Pass-Through?

Francis J. Hensler, CDP                     BITNET: FJH@SRU
Software Support Specialist                 Phone: (412) 738-2033
Slippery Rock University Computer Center    PANET:     8-654-2033
Slippery Rock, PA  16057-1326  USA   "Yes, Virginia, there is a Slippery Rock"
From: CAMPBELL@KENTVM.BITNET (Randy Campbell)
Newsgroups: bit.listserv.vmesa-l
Subject: VM/ESA (370 feature) and Cache Controllers
Date: 13 Oct 92 17:53:53 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

Greetings,

We are getting the ground rules down for a migration from VM/HPO Rel. 5
to VM/ESA Rel. 1.0 - 370 Feature, we are running on a 4381 platform with
a 3990-3 storage cache controller.
According to all IBM documentation, VM/ESA 370-Feature does not support
cache controller and lists only the 3990-1 and -2 storage controllers as
being supported.
My question: is there any sites out there running the 370-Feature with the
3990-3 storage controller (cache on or off)?

Thanks in advance.

Randy Campbell
Software Analyst
Kent State University
From: drake@ALMADEN.IBM.COM ((Sam Drake))
Newsgroups: bit.listserv.vmesa-l
Subject: Re: VM on RS/6000
Date: 15 Oct 92 17:11:42 GMT
Organization: IBM Almaden Research Center
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Comments: To: VMESA-L%UAFSYSB.BITNET@ucbvax.Berkeley.EDU

In article <921015053320.vmesa-l.netforum.interest@almvma.vnet.ibm.com> you
 write:
>Actually, there's nothing preventing a Mach server task from
>emulating a completely different processor architecture

Certainly not ... you can do this in any operating system.  (Performance
is often an issue, of course.)

>> Nor does MACH, to my understanding, allow
>> other operating systems (such as MACH) to run under it; it does not
>> virtualize the CPU's supervisor state; it simply emulates the system
>> calls that various operating systems provide to problem state
>> programs.
>
>Operation of multiple OS servers is a stated design feature of
>the Mach 3.0 microkernel. The Unix server and the DOS server
>already coexist on the same microkernel, to the point of being
>able to play Wing Commander in the DOS server while watching GNU
>Emacs compile on the Unix side.

That's true, but it's not what I claimed.  I claimed that MACH did not
allow multiple operating SYSTEMS to run under it (as CP does).  The
"Unix server" that runs under MACH is not bootable on the real hardware.

--
Sam Drake / IBM Almaden Research Center
From: WTS@MAINE.MAINE.EDU ((Wayne Smith))
Newsgroups: bit.listserv.vmesa-l
Subject: Re: Performance Questions
Date: 14 Oct 92 16:54:41 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

Oops, I forgot in my previous append ...

You might want to investigate APAR VM51228 High paging rate for vm/esa1.1
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
From: BARTON@MSU.BITNET
Newsgroups: bit.listserv.vmesa-l
Subject: (no subject given)
Date: 13 Oct 92 22:20:50 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

Subject: 3990-3 with vm/sp or vm/esa (370)

IBM's lack of support for this environement doesn't mean
it doesn't work - it works very well.  It's just not
controllable or measureable.  (If you carry the button
that claims "If you can't measure it, I'm not interested"
then yer in trouble....)  The devices are all
cached by default - without any way to turn caching
off.  Some people have hooked up their MVS system
to perform the control functions for them.
There are some small number of hardware errors
that may occur on the cache controller that will
be recoverable in a supported environement but won't
be in a unsupported environement.  Tho, when I've tried
to get IBM to tell me more on this subject, nobody
can give me an example of something that doesn't
recover.  There certainly is no chance of losing
data, and the box is reliable enough that hardware
failures are unlikely.
If IBM gives you a lot of FUD on this, you always
have the option of using a Symetrix from EMC, or
one of Amdahls cache controllers that will be
fully supported by IBM's code in a VM/ESA (370 feature)
environement.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Office of University Computing
Newsgroups: bit.listserv.vmesa-l
Date:         Tue, 13 Oct 1992 08:51:03 EST
From:         Nick Laflamme <NLAFLAMM@IRISHVMA.BITNET>
Subject:      Re: VM on RS/6000

I'm not sure why IBM would bother to produce a 370 or ESA card for the
RS/6000 series.  I mean, the 370 card for PS/2s is a real minor effort;
it almost exists despite IBM, not because of them.  I'm not aware of any
strengths in the RS/6000 as a chassis for a 370 card over what the PS/2
offers.  I'm not saying that it can't happen, but I wouldn't hold my
breath or let it figure into any decisions about whether to buy an
RS/6000 or not.

Just a thought,
Nick

* NLAFLAMM@IRISHVMA.BITNET
* Dominique.P.Laflamme.1@nd.edu
From: TKSSTEVE@UBVM.CC.BUFFALO.EDU (Steven P. Roder)
Newsgroups: bit.listserv.vmesa-l
Subject: ESA vs. XA mode on a 3090-200J under ESA 1.1.1/CMS 8
Date: 15 Oct 92 13:29:14 GMT
Organization: State University of New York at Buffalo
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

I have heard opposing viewpoints about the difference/similarity of XA
and ESA mode under VM/ESA 1.1.1, CMS 8.  Some say SET MACH ESA and
SET MACH XA are identical, and others have said there are differences.
How 'bout it?  Anyone out there know for sure?  Can anyone point me to a
reference on this?  IBM, are you listening?  What is your position on this?
We are planning to make ESA-mode the default for users in January.  Should
it be XA-mode instead?

Enough questions for now.


Steve Roder
(tkssteve@ubvm.bitnet | tkssteve@ubvm.cc.buffalo.edu | (716)645-3564
From: DS000@CALPOLY.BITNET (Wayne McCaughan)
Newsgroups: bit.listserv.vmesa-l
Subject: Re: Performance Questions
Date: 14 Oct 92 16:47:18 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Comments:     Resent-From: Wayne McCaughan <DS000@CALPOLY>
Comments:     Originally-From: Wayne McCaughan <DS000@CALPOLY>

----------------------------Original message----------------------------
On Tue, 13 Oct 92 11:04:12 PDT I said:
>We have just upgraded from VM/XA SP 2.1 to VM/ESA 1.1 this last weekend and
>have experienced a noticable increase in paging rates (from 100 to >300 pages
>per second) with a corresponding degradation in response time.  Our ESA system
>provides minimal CMS services as most of our work is done in an AIX/370 guest,
>a VM/XA SP 2.1 guest, and a VM/SP 5.0 guest.  We had thought that this change
>would have been essentially transparent since our users don't interact with
>ESA directly.  Any thoughts?

Some questions I received back and my responses:
>did your trace table size change?
No.

>did your V=R area (if any) change?
No, and the recovery area was kept the same size too.

>(Were you really running a VM/XA 2.1 guest under your VM/XA 2.1 system?)
Yes.  Unfortunately, the VM systems staff here has little to say about how to
optimally run VM.  The VM/XA SP 2.1 guest comes from security fears of mixing
academic and administrative users on the same machine.  We still run the same
VM/XA SP 2.1 guest under VM/ESA.

>Have your users played a trick on you by increasing their working sets
>on AIX, VM/SP or your VM/XA 2.1 guest?
AIX's memory was increased right before the XA to ESA change over, and we are
testing putting its memory size and share back to the old levels.

>VM/ESA ESA needs a greater amount of paging space to work.
>You might want to look at the percent of paging space that you are using.
>The block paging needs large blocks of empty space to work correctly.
>Are you *sure* you have enough page space?
As for ESA's block paging, we have 5 packs with paging areas and all but 1 are
300+ contiguous cylinders.  The one exception is the IPL volume which has only
a small 60 cylinder area.  Each pack has only a single page area.  A QUERY
ALLOC reports only 50% of each area in use and the QALLOC EXEC reports only
14% in use.  All DASDs are dual pathed and non-cached.

>The changes in CMS can cause an increase in paging. The vmlib  gets
>loaded in each CMS session in the SYSPROF exec and takes up about
>.5 meg each. If you have a number of dsc service machine you might want
>to  store it into a shared segement.
The host ESA system has only a few (<10) CMS users which are idle 99% of the
time.

>Are you using similar QUICKDSP and RESERVE settings?
QUICKDSP is set on for the same users.  We do not use SET RESERVE.  Our SRM
STORBUF and LDUBUF are set at 200% 200% 200% as they were under the old XA.
    Re: Performance Questions                                              R
From: BARTON@MSU.BITNET
Newsgroups: bit.listserv.vmesa-l
Subject: (no subject given)
Date: 13 Oct 92 18:45:46 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

Subject: performance questions

Page rates are expected to go up when converting from
VM/XA to VM/ESA on CMS intensive systems because CMS
is reorganized - but this should not impact a system
providing 'minimal CMS services'.  The 1st questions I'd ask
are:  did your trace table size change? did your V=R area
(if any) change?  (Were you really running a VM/XA 2.1
guest under your VM/XA 2.1 system?)  Have your users
played a trick on you by increasing their working sets
on AIX, VM/SP or your VM/XA 2.1 guest?
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU