HDTenEightyP/NetNews huggingface dataset:
X-Vmsmail-To: SMTP%"hellas@uga.cc.uga.edu"
Newsgroups: bit.listserv.hellas
Date:         Sun, 22 Nov 1992 21:14:45 -0700
Reply-To:     THEODOROS <TPASCHALIDES@BPA.ARIZONA.EDU>
From:         THEODOROS <TPASCHALIDES@BPA.ARIZONA.EDU>
Subject:      Kypros podosfairo
Comments: To: hellas@uga.cc.uga.edu

Ta alla duo paignidia exoun:

POL 0 APOLLWN 1
OLYMPIAKOS 1 OMONOIA 2






                     CYPRUS SOCCER CHAMPIONSHIP  11/22/92
                     --------------------------------------



                TEAM       GAMES  PNTS      W   DR  D    GF   GA
           1   SALAMINA      8     22       7   1   0    17   4
           2   OMONOIA       8     17       5   2   1    32  12
           3   APOLLWN       8     17       5   2   1    22  11
           4   APOEL         8     15       4   3   1    17   8
           5   AXNA          8     15       5   0   3    16  10
           6   ANORTHOSIS    8     13       4   1   3    11  12
           7   ARIS          8     10       3   1   4    14  21
           8   ENWSIS        8     10       3   1   4    12  18
           9   AEL           8      9       3   0   5    15  15
          10   OLYMPIAKOS    8      9       3   0   5     7  18
          11   EPA           8      8       2   2   4     9  14
          12   EUAGORAS      8      7       2   1   5    10  17
          13   POL           8      4       0   4   4     8  13
          14   APOP          8      3       1   0   7     5  22


Theodoros
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.hellas
Date:         Mon, 16 Nov 1992 09:03:12 GMT
Reply-To:     N.P.Xenios@BNR.CO.UK
From:         N.P.Xenios@BNR.CO.UK
Subject:      SET HELLAS MAIL
Comments: To: HELLAS@BROWNVM.brown.edu

SET HELLAS MAIL
From: 105pouloukas@GW.WMICH.EDU
Newsgroups: bit.listserv.hellas
Subject: Re: Kupriako Pavepistnmio
Date: 9 Nov 92 16:28:32 GMT
Reply-To: 105pouloukas@GW.WMICH.EDU
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Comments: To: hellas@uga.cc.uga.edu

--------------------------------------------------------------------------
>Sxetika me to mail tou Michali Syrimi (kammia syggenia me ton gvwsto SYrimi
>ypourgo?):

>Pragmati dhmiourghthike problhma me ta gegwnota sthn teleth enarxhs alla
>kata th gvwmh mou to problhma dhmiourghsan politikoi kai ekklhsia (mh
>xexnate tes ekloges). Prospathoun dhladh apou bgei pio patriwths kai
>super-patriwths.

>H proedros ths dihkousas (prwsorinh) parousiastike sth epitroph paideias
>ths boulhs thn perasmenh bdomada opu shzhthsan to thema. Kai katholou
>den efyge apo thn Kypro, aplws nomizw eixe programmatismeno taxidi. H de
>boulh den apofasise oti prepei na pafthei apo thn thesh ths oute kai kan
>mporei na thn papsei. Mono o proedros mporei na thn papsei. Kai auto
>theorite anaxronistiko giati etsi h politeia tha fenetai oti
>epembenei sta akadhmaika kai to exoun pei polles fores oti to
>panepisthmio einai anexarthto.

>Den einai alhthia oti o kosmos apodokhmase tes praxeis ths Tsougiopoulou.
>Ta kommata plhn tou AKEL exoun katadhkash me antonh glwssa ta gegwnota
>alla apo osa diavazw stes efhmerides o kosmos tous grafei.
>>>                                   --------------------
>>>                                   SWSTOS O KYPRIAKOS LAOS!!

>To AKEL eipe
>oti yphrxan kakoi xhrimoi sta egenia alla den prepei na pernoun diastaseis
>to thema. Kata thn dikh mou apopsei to olo thema fenetai na edhmiourghthei
>kai pali apo pleuras ekklhsia pou den arese to oti den ekanan agiasmo.
                                   -----------------------------------
>>> AN PRAGMATIKA H TSOUGIOPOULOU PHRE APOFASH NA MHN GINEI AGIASMOS TOTE
>>> EGW LEW "MPRABO!" KAI THN YPOSTHRIZW. DEN 3ERW AN EKANE ALLES KAKES
>>> ENERGEIES ALLA EDW THN PARADEXOMAI.

>Exallou o Xrysostomos exagghle thn Paraskeuh oti den einai dynato o Kypriakos
>laos na enwthei katw apo politiko arxhgo. Bgalte ta symperasmata sas||

>Andreas

>>> STAVROS.
-----------------------------------------------------------------------------
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.hellas
Date:         Fri, 20 Nov 1992 16:58:24 LCL
Reply-To:     Stelios Fragakis <FRAGAKIS@GREARN.BITNET>
Comments:     Warning -- original Sender: tag was LISTMAN@GREARN
From:         Stelios Fragakis <FRAGAKIS@GREARN.BITNET>
Subject:      I-20 plhrofories?

Geia xara,

Thelw plhrofories gia epikyrwsh ths  formas I-20 apo ellhniko proskeneio
Apanthseis sth lista h proswpiko mail

Epishs gia osous den to kseroun

An kapoios  apokthsei F-1 VISA  auto de shmainei  oti h forma  I-20 (pou
xrhsimopoihse gia na thn apokthsei)  einai egkyro, epishmo eggrafo.
Xreiazetai na epikyrwthei apo ellhniko prokseneio.
Auta apo to stratologiko grafeio. :-)

 Stelios
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.hellas
Date:         Tue, 17 Nov 1992 14:06:39 EST
Reply-To:     Thomas Varouhakis <varouhak@ICARUS.MONTCLAIR.EDU>
From:         Thomas Varouhakis <varouhak@ICARUS.MONTCLAIR.EDU>
Subject:      17 Noembrh simera...
Comments: To: ekatera@syma.sussex.ac.uk
Comments: cc: HELLAS@american.edu
              17 Nov 1992 13:42:17 WET
              <9211171411.AA23648@icarus.montclair.edu.montclair.edu>

>
>            O   D R O M O S
>

T'akordeov eivai e3'isou kalo...

0wmas-
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.hellas
Date:         Sun, 22 Nov 1992 16:24:43 EST
Reply-To:     "Georgatos, Konstantinos" <GEO@CUNYVMS1.BITNET>
From:         "Georgatos, Konstantinos" <GEO@CUNYVMS1.BITNET>
Subject:      Gouzgounoquiz: Apantiseis kai alla

Date sent:  22-NOV-1992 16:19:48

>> 4. (optional gia tous Gkousgkouni-fans) Ti epaggeletai o Gkousgkounis
>>  simera ?

>Xmm. Kala pou einai optional, giati den kserw.

Enas sumaqhths mou sto frontisthrio (Kwstas Xrusospaqhs) mou
qumize se kaqe eukairia (gi' auto to qumamai allwste) oti
o Gousgounhs diathriuse fwtografeio konta sto spiti toy
(Xalandri.) Here you are
K.

#################################################################
Konstantinos Georgatos
Dept.of Math.-Grad.School-CUNY
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Subject: (no subject given)
Newsgroups: bit.listserv.vmesa-l
Date:         Thu, 19 Nov 1992 15:14:53 -0600
Comments:     <Parser> W: Invalid RFC822 field -
              "================================================================
              ". Rest of header flushed.
Comments:     <Parser> E: "From:"/"Sender:" field is missing.
From:         Undetermined origin c/o Postmaster <POSTMASTER@UAFSYSB.BITNET>

We are working on installing a VM/ESA 1.1 system. During some
of our testing we have found that our guest VSE/SP 4.1 system
will be interrupted and display a 'DEVICE RESET...' message
in CP mode. This occurs when a DIALed terminal is dropped
from the VSE guest. This is different from our VM/ESA 1.0 system
which will only display this message when the console operator
issues the RESET command from CP mode of the VSE guest machine.
With VM/ESA 1.1 the VSE console gets this message when the
user drops their line from VSE!

How can we turn this 'option' off? We have tried turning off
all of the VM messages (EMSG, IMSG...).

Currently, we log the VSE guest on and would rather stay with
this method instead of having the operator DIAL to the VSE
console. Any help would be appreciated. Thanks.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Subject: (no subject given)
Organization: Penn State University - Hershey Medical Center
Newsgroups: bit.listserv.vmesa-l
Date:         Thu, 19 Nov 1992 16:46:14 EST
From:         Joseph Ryan <JRYAN@PSUHMC.BITNET>
              19 Nov 1992 15:14:53 -0600 from <POSTMASTER@UAFSYSB>

On Thu, 19 Nov 1992 15:14:53 -0600 Undetermined origin c/o Postmaster said:
>We are working on installing a VM/ESA 1.1 system. During some
>of our testing we have found that our guest VSE/SP 4.1 system
>will be interrupted and display a 'DEVICE RESET...' message
>in CP mode. This occurs when a DIALed terminal is dropped
>from the VSE guest. This is different from our VM/ESA 1.0 system
>which will only display this message when the console operator
>issues the RESET command from CP mode of the VSE guest machine.
>With VM/ESA 1.1 the VSE console gets this message when the
>user drops their line from VSE!
>
>How can we turn this 'option' off? We have tried turning off
>all of the VM messages (EMSG, IMSG...).
>
>Currently, we log the VSE guest on and would rather stay with
>this method instead of having the operator DIAL to the VSE
>console. Any help would be appreciated. Thanks.
One way is to dedicate a terminal to vse as it's console address,
usually 01F. In the directory add DEDICATE Virtual_address Real_address;
Then make another userid the secondary console of the VSE machine.
All cp msgs will go to the secondary userid. Also, you can more easily
IPL your guest by just issuing an XAUTOLOG command.

*--------------------------------------------------------------------*
 Joe Ryan - System Programmer
 JRYAN at PSUHMC
 Penn State University  -  Milton S. Hershey Medical Center
 PO Box 850, Hershey, PA 17033
 Phone (717) 531-7569    Fax (717) 531-7259
*--------------------------------------------------------------------*
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.vmesa-l
Date:         Tue, 17 Nov 1992 08:24:02 EST
From:         "(Wayne Smith)" <WTS@MAINE.MAINE.EDU>
Subject:      Re: EREP reports

Hi Mary!

>At our site, currently our Operators run EREP weekly and print out the
>resulting reports that are then filed in a filing cabinet.  As we are
>trying to conserve paper, we've decided to spool the reports from
>EREP to tape and then have a procedure for the Operators to run
>that would allow them to print the desired report.  I was just wondering
>how other sites handle their EREP output and if anyone would be willing
>to share their execs if they are similar to what I would need.  It
>would be greatly appreciated!

I have two suggestions.  First, investigate the possibility of IBM
installing SDSS, also know as the "Service Director".  This is a PC
(that IBM provides) and PC and VM software that automates the collection
and display of EREP data.

We process EREP data daily (an EREP id gets AUTOLOGed about 5am) and the
data collected is sent to the Service Director.  With ESA2 (maybe 1.1?),
important alerts (SIMs) may be sent directly to the Service Director
without waiting for the daily report.

The Service Director organizes and prepares reports and displays on
events of interest to you.  When we installed SDSS this past summer, IBM
spent a considerable amount of money replacing HDAs because they were
"called out" by the Service Director, whereas I had not yet viewed the
events to be of great importance.  (We now have perfectly running DASD,
thank you!) :-)

My second suggestion is to place your EREP reports on DASD rather than
tape.  There are a number of products and freeware offerings that
basically have a service Virtual machine that collects console logs,
printouts etc, stores them on DASD for a time, and automatically
discards them after a prescribed time period.  We have one we call
GROVER.  An excellent product choice would be V/SEG-PLUS-ESA from VMSG
(703/506-0500 or 800/795-VMSG) (I wouldn't get V/SEG-PLUS-ESA just for
this, but it is valuable for many things, including NSS management and
open spool file browsing).

cheers,
wayne

Wayne T. Smith, CCP
Systems Group - CAPS              BITNET/CREN:  wts@maine
University of Maine System        internet:     wts@maine.maine.edu
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.vmesa-l
Date:         Fri, 20 Nov 1992 10:26:17 EST
From:         "Martin J. Doyle (215) 752-2296" <MBDMD@ROHVM1.BITNET>
Subject:      VM/ESA 1.1/1.2 on 3090-E Processor

We currently run VM/ESA 1.1 in a logical partition on an ES/9000-820.
An MVS system is run in a separate logical partition on the same 820.
According to our capacity plan, we should run out of gas on this box
late '93/early '94.  VM consumes roughly 25% of the resources on the 820.

With the falling prices of 3090s, especially 3090-E boxes, our best
bet may be to move VM off of the ES/9000, freeing the entire box up
for MVS, to a used 3090.  I know that VM/ESA 1.1 will run on a
3090-S or 3090-J class box.  Will it run on a 3090-E?  In addition,
we will probably go to VM/ESA 1.2 late '93.  Does anyone know if
VM/ESA 1.2 will run on a 3090-E processor?

We know we won't get groovy features like data spaces and XC mode
virtual machines but we really don't need those ES/9000-only features.

Thanks,

Martin J. Doyle
VM Systems Programming Contractor
Rohm and Haas Company
Philadelphia,  Pennsylvania
MBDMD@ROHVM1
(215) 592-6865 (Day)
(215) 752-2296 (Evening)
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.vmesa-l
Date:         Mon, 16 Nov 1992 12:58:51 ECT
From:         MARY MASON <SP0004@BINGVMB.BITNET>
Subject:      EREP reports

Good day everyone.

At our site, currently our Operators run EREP weekly and print out the
resulting reports that are then filed in a filing cabinet.  As we are
trying to conserve paper, we've decided to spool the reports from
EREP to tape and then have a procedure for the Operators to run
that would allow them to print the desired report.  I was just wondering
how other sites handle their EREP output and if anyone would be willing
to share their execs if they are similar to what I would need.  It
would be greatly appreciated!
Newsgroups: bit.listserv.vmesa-l
From: Graham Bryan <J.G.Bryan@bham.ac.uk>
Subject: LOGOFF/FORCE pending for user .....
Date: Mon, 16 Nov 1992 10:08:08 GMT
Organization: The University of Birmingham, England

From time to  time we get users stuck in  the dreaded "LOGOFF/FORCE
pending for user .." state. Generally these are users accessing our
system via some form a  communication software that creates logical
devices through which the user logs in.

Having finally  stopped our operators  doing a FORCE for  users who
ring up with  communications problems, we are now  finding that the
SYSTEM is forcing users because it thinks they are inactive!!

Does anyone know what or where  the time interval used by SYSTEM to
determine inactivity is called or  maintained and is it possible to
change it?

+--------------------------------------------------------------------+
| Graham Bryan                      Voice:    (UK) 021-414-3990      |
| Systems Support Group             Fax:      (UK) 021-414-3952      |
| Computing Service (Elms Road),    Janet:    J.G.Bryan @ UK.AC.BHAM |
| The University of Birmingham,     Internet: J.G.Bryan @ bham.ac.uk |
| PO Box 363, Edgbaston,                                             |
| Birmingham (B15 2TT),                                              |
| England                                                            |
+--------------------------------------------------------------------+
From: MBDMD@ROHVM1.BITNET (Martin J. Doyle (215) 752-2296)
Newsgroups: bit.listserv.vmesa-l
Subject: CP storage integrity problem
Date: 16 Nov 92 16:10:07 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

Anyone having any problems with CP storage under VM/ESA 1.1, refresh
9202?

Last week we started to get calls from users which were running
an application that runs out of a SHARED READABLE segment.  The code
in this segment has been running fine since we moved to ESA a few weeks
ago.  Last week, these users started getting operation exceptions.
A quick trace showed that they were branching to sections in the segment
that contained hex zeros.

Now the interesting part.  I used the CMS utilities DCSSBKUP program to
make a backup of this segment; next we got the handful of users who had
the segment attached to detach the segment.  After the last user had
detached the segment we fired up the application again forcing a new
image of the pages in the segment to be brought into storage from the
spooling packs.  The application started working again!

I used DCSSBKUP to backup the segment again and compared the two files.
They didn't match.  The bad copy of the segment had three pages which
were completely zeroed out!  The users were branching to a storage
location that, at one time, had code but somehow got zeroed out.
Reading in a fresh copy of the segment got the application running
again but what is CP going to zero out next?

Has anyone seen anything like this under ESA?


Thanks,

Martin J. Doyle
VM Systems Programming Contractor
Rohm and Haas Company
Philadelphia,  Pennsylvania
MBDMD@ROHVM1
(215) 592-6865 (Day)
(215) 752-2296 (Evening)
From: GEORGEH@MSU.BITNET (George_J.Haddad)
Newsgroups: bit.listserv.vmesa-l
Subject: LOGOFF/FORCE pending for user ..
Date: 17 Nov 92 15:05:00 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU


See module HCPCFM (label TIMEBOMB) for the 15 minute time-out value.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.vmesa-l
Date:         Fri, 20 Nov 1992 16:15:00 PST
From:         "(Joseph A. Faracchio {510} 642-7638 {w})" <SPGJAF@UCBCMSA.BITNET>
Subject:      VM/ESA 1.1/1.2 on 3090-E Processor

One point of attaining a -E box you should be aware of is that it
can not be upgraded to a -J anymore (by IBM at least.)  That *marketing*
option expired on Sept. 30th.   And if you want to upgrade it from -J
to -JH (9000 in 3090 clothing) that will expire dec 31st.

I only mention this because -E machines are incapable of supporting
VM , productively, in a logical partition.  the 'better' microcode for
that didn't come along until the -S or -J.
                                          .. joe.f.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.vmesa-l
Date:         Tue, 17 Nov 1992 08:36:00 PST
From:         "(Joseph A. Faracchio {510} 642-7638 {w})" <SPGJAF@UCBCMSA.BITNET>
Subject:      CP storage integrity problem

This sounds a lot like the problem we had on VM/XA SP 2.1 at 9002.
Hmm .. 9202 ... 9002    Those -02's will kill you every time! :-)

We were never able to get all users off a DCSS but by restoring
an old copy, that would immediately start being used, we could 'fix' the prob.

I don't think we ever determined the pages to be all zeros.

It finally went away when I took 2 days on IBMLINK looking at APARs that
mention OVERLAY in their descriptions and applied about 10 of them.

If you like I can try to dig them up ... but since you're on ESA
I don't know whether they would have relationships (Parent-Child apars)
etc.
     .. joe.f.
From: U52983@uicvm.uic.edu (Roger Deschner)
Newsgroups: bit.listserv.vmesa-l
Subject: Re: VM Batch Facility
Date: 16 Nov 92 23:20:16 GMT
Organization: University of Illinois at Chicago

We run it too, on ESA 1.1. We also have not actively used the Load
Leveling Scheduler feature, and I'm just a little afraid of it. It's
getting its numbers from CP IND Q, and frankly I do not have much faith
in the output of that command. The major problem is that it is just too
instantaneous - issue the command over and over and the number of users
queued for this-or-that will leap up and down all over the place, as the
human interactive users out there (remember them?) hit the enter key at
random intervals and for random reasons.

I prefer to look at paging rates. In my experience, paging rates are the
thing most strongly correlated with poor interactive performance. High
paging (to DASD) can cause I/O contention, and likewise I/O contention
can cause slow paging and a snowballing paging backlog. High paging even
to XSTORE can consume quite a few precious cycles. Therefore, paging
rate can be viewed as one measure of the health of your entire system.

I don't worry about CPU, because VM takes care of allocating cycles so
well, if you get everything else right. That is, if you have enough
cycles for all your interactive work with no BATCH running, just SET
SHARE on the batch task machines low, and the CP Scheduler itself will
take care of the possibility of processor contention very nicely. A VM
system running at 100% CPU is a happy VM system. It seems to me that
using BATCH's load leveling, based on CPU contention, could really throw
off the CP Scheduler's carefully wrought calculations of time slices,
etc. - especially since those IND Q numbers jump around so much. I
recorded those numbers for a while, using BATCH Q LLS, and the only one
of its numbers that had any statistical correlation with response time
was I/O contention. This seems pretty much useless, since in our shop at
least, BATCH jobs tend to be number-crunching memory-hogs. And I/O rate
is a trailing indicator, which may show a spike long after an actual
memory shortage caused a spike in XSTOR paging rate, which eventually
migrated out to DASD paging, and high I/O. By then the problem is
probably over.

So my strategy is to put together a server that does CP IND LOAD from
time to time, looks at paging rates, and then issues BATCH SUSPEND and
BATCH RESUME as appropriate. I haven't done this yet, but will when I
get a round tuit.

I do, though, like the discussion of suspend and resume thresholds in
the manual. This discussion is applicable in the general case to any
system you are trying to auto-regulate by any means, where there is a
danger of thrashing. The thermostat in your house does this, or else it
would be tuning your furnace on and off every few seconds.

-- Roger Deschner, U52983@UICVM.UIC.EDU, Univ of Illinois @ Chicago
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.vmesa-l
Date:         Mon, 23 Nov 1992 21:58:52 CST
From:         Rick Troth <TROTH@RICEVM1.RICE.EDU>
Subject:      Re: *SPL and pipelines

>We'd like to hook the printers up to a virtual machine and use the *SPL
>system service (to cut down on the number of mods to the system we'll
>have to make) and were wondering if anyone has written any pipelines
>filters or stages (or anything else, for that matter) that can be used
>to manage a connection to the *SPL system service?

Hi, Paul,

        Our home grown printing system counts pages  (not just lines).
Since most of the code is now mine,  I'm kindof attached to it.
We have channel-attached 3203s and a Xerox 4050.   More recently,
I added code to let any LPR (TCP) connected printer be a VM printer.
If a printer is channel-attached,  CP does most of the work,  if it's
RSCS connected then the printing system just hands it off to RSCS,
if it's an LPR printer (either plain-text or PostScript)  then we use
the READER driver to extract the file from SPOOL to an LPR pipeline.
I've been meaning to jump into the *SPL game for quite some time,
and would *love* to do so with Pipes.

        The STARMSG device driver supplied with the Pipes package will
accept the word *SPL as the name of the service to which it connects.
I doubt it works the way we'd like.   There's a strong disclaimer in
the HELP file about connecting to non-message system services.

Rick Troth <troth@ricevm1.rice.edu>, Rice University, I/S VM Systems Support
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: State University of New York at Buffalo
Newsgroups: bit.listserv.vmesa-l
Date:         Tue, 17 Nov 1992 09:16:30 EST
From:         "Steven P. Roder" <TKSSTEVE@UBVM.CC.BUFFALO.EDU>
Subject:      Re: EREP reports

On Mon, 16 Nov 1992 12:58:51 ECT MARY MASON said:
>Good day everyone.
>
>At our site, currently our Operators run EREP weekly and print out the
>resulting reports that are then filed in a filing cabinet.  As we are
>trying to conserve paper, we've decided to spool the reports from
>EREP to tape and then have a procedure for the Operators to run
>that would allow them to print the desired report.  I was just wondering
>how other sites handle their EREP output and if anyone would be willing
>to share their execs if they are similar to what I would need.  It
>would be greatly appreciated!

Our IBM SE installed a Service Director here a couple years ago.  It is
a PS/2 that logs on to our MVS system, and recieves the combined EREP data
from VM and MVS (using IND$FILE).  We never print EREP reports anymore, as
the SE can look at the data "online" at there PS/2.  I'd contact you local
branch about this option.


Steve Roder
(tkssteve@ubvm.bitnet | tkssteve@ubvm.cc.buffalo.edu | (716)645-3564
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU