HDTenEightyP/NetNews huggingface dataset:
From: dean@unix1.realdec.com (Dean Banfield)
Subject: Re: Lost LAT sessions
Organization: Real Decisions Corporation
Date: Mon, 25 Jan 1993 22:20:05 GMT

In article <0NXsXB1w165w@jeslacs.wimsey.bc.ca> Peter Smode <psmode@jeslacs.wimsey.bc.ca> writes:

>   - a SHOW USERS FULL will be missing the (server/port) address for the
>   LTAxxx: terminal
>   - the process will INHALE all available CPU time, at elivated priority.
>   This effectively turns the system into a dog.
>   - it is suspected that users terminal sessions just go dead in the
>   water with no terminal response. We are not sure as users are not
>   giving us good information when these situations occur.

We have a software product which experienced a similar problem when 
installed at one particular client.  We narrowed it down to the following
criteria:
	User logged on via LAT
	Hanging out in our product at our prompt (read wait on SYS$INPUT)
	User walks away, uses other session on terminal server, etc and 
	  forgets about his read prompt in our product.
	He then logs off terminal server without actually exiting from the
	  product prompt, or logging off that session independently.
	LAT sends a HANGUP message to the process, which attempts to
	  wind down the image.  This is unsuccessful and the image is
	  left disconnected from any LAT connection and gets very high
	  priority in the attempted wind-down.
We traced the problem to a set of CTL-C, CTL-Y trapping routines which we
had implemented.  In effect, the wind-down operation sent a CTL-C (or Y)
to the image to wind it down.  Our software, assuming that this was an
interactive user, trapped the signal and tried to return the user to the
product prompt.  Having no effective terminal any more, the software got
very confused and sucked down all available resources trying to re-issue
the product prompt.  

To stop the bleeding (we never found an elegant solution) we simply advised
the client to disable the CTL-C, CTL-Y trapping, which meant that when a 
user aborted out of our product, we allowed the system to wind it down in
its own (possibly nasty to us) way.  This DID stop the problem.

My advice: Try to find out what application user/application was "turned
off" in this way.  Approach the developer of the application with these 
ideas and see what falls out.  It may be difficult to track this down, but
in our case our image was easily identifiable to the system manager as the
one trying to wind itself down.  The user was impossible to find, since the
LAT stuff got disconnected early in the wind-down.

Hope this is of some help.

-Dean
--
===============================================================
Dean Banfield                 
Real Decisions Corporation   Voice: 203.656.1500
22 Thorndal Circle             FAX: 203.656.1659
Darien, CT  USA 06820        Email: dean@rdcalr.realdec.com
-- 
===============================================================
Dean Banfield                 
Real Decisions Corporation   Voice: 203.656.1500
22 Thorndal Circle             FAX: 203.656.1659
From: Peter Smode <psmode@jeslacs.wimsey.bc.ca>
Newsgroups: vmsnet.sysmgt
Subject: Lost LAT sessions
Date: Fri, 22 Jan 93 15:27:20 PST
Organization: JES Library Automation, Coquitlam BC, CANADA

We have a bit of an oddball problem happening at a couple of our sites.
From time to time (measured in weeks or months), we will get one or
more interactive terminal sessions on LTAxxxx: terminals getting
"lost in space". The symptoms are as follows:
- a SHOW USERS FULL will be missing the (server/port) address for the
LTAxxx: terminal
- the process will INHALE all available CPU time, at elivated priority.
This effectively turns the system into a dog.
- it is suspected that users terminal sessions just go dead in the
water with no terminal response. We are not sure as users are not
giving us good information when these situations occur.
- SHOW ERROR reveals nothing
- NCP counters do no show anything out of the ordinary
- happens for both direct and dialup connections on any port, any server
- server error counters do not seem to indicate trouble.
 more
So far, DEC has sent the latest patch kits and had us install them, but
to no avail.
 
Has anybody got any ideas?
 
Both system on which this occurs are homogeneous CI-based VAXClusters.
CPUs include VAX 7xx, 8xxx and 6xxx based machines. VMS versions are
5.3-x and 5.4-x.
 
-- Peter

**************************************************************************
*   Peter Smode                 E-mail:    psmode@jeslacs.wimsey.bc.ca   *
*   JES Library Automation      Voice:     (604)939-6775                 *
*   Coquitlam, BC, CANADA       Fax:       (604)939-9970                 *
**************************************************************************
Newsgroups: vmsnet.sysmgt
From: ASM@snowyt.me.psu.edu (Aravind Melligeri)
Subject: Problems with VMS News v1.24 
Organization: Pennsylvania State Univ., Dept. of Mechanical Engineering
Date: Fri, 22 Jan 93 21:04:05 GMT
X-News-Reader: VMS NEWS 1.24

Has any one come accross problems in running VMS News V 1.24?.
It intermmitantly crashes the system. It gives out error as Fatal Bug check 
on console. I am not able to write my memory dump b'cos of shortage of disk
space. So, I am not able to analyze the memory dump at crash time. 
I was just wondering if anyone has experienced the problems with this?.
thanx
--aravind

--Aravind S. Melligeri				
-------------------------------------------------------------------------------
System Administrator		       |		      asm@mevax.psu.edu
Dept. of Mechanical Engg.	       |		      off: 814-865-2062
Pennsylvania State Univ. 	       |		      res: 814-867-5922	
-------------------------------------------------------------------------------
Newsgroups: vmsnet.sysmgt
Subject: Re: Here is a ACL question for you!
From: kaplan@bpavms.bpa.arizona.edu (Steve... friends don't let friends do DOS.)
Date: 26 Jan 1993 12:18 MST  
Distribution: world,local
Organization: University of Arizona MIS Department
News-Software: VAX/VMS VNEWS 1.41    

In article <C1Go77.LIx@micrognosis.co.uk>, nreadwin@micrognosis.co.uk (Neil Readwin) writes...
>In article <4630@mitech.com>, gjc@mitech.com (George J. Carrette) writes:
>|> Is it possible to prevent a user from being able to
>|> change the protection on a directory that he owns?
> 
>No. If you look at the Guide to VMS System Security you will find (Figure
>4-4) a flowchart. Even if an ACL explicitly denies access then it will
>branch off to BB (UIC based checks). If the requester UIC is the owner UIC
>then it checks the protection code for the object. If you read between the
>lines of section 4.2.3 then it is clear that UIC based protection always
>grants CONTROL access to the owner.
>-- 
> Phone: +44 71 815 5283  E-mail: nreadwin@micrognosis.co.uk
> Anything is a cause for sorrow that my mind or body has made

Yep.  IN addition, you should know that the capability that you want does
exist, but not in VMS.  VMS has a "big brother" called Secure VMS (SEVMS)
which can do this.  It is a so-called "trusted system", which implements a
thing called mandatory controls.  The security in a mandatory control
environment is imposed on the user by the system - they can't change it. 
This is opposed ot what we have in version vanilla VMS called descretionary
controls.  If you want more information on SEVMS - contact me or your local
DEC sales person.  More information on trused systems:

	See my column in Digital News and Review the last two issues

	Books that give the subject a nice treatment:

	Computer Security Basics
	Deborah Russell and G.T> Gangemi Sr.
	ISBN 0-937175-71-4
	Oreilly and Associates, 1991
	(800) 338-6887


	Dave Curry's UNIX System Security - A guide for users 
		and system administrators
	ISBN 0-201-56327-4
	Addison Wesley - 1992

A note of caution- the trusted systems arena is in flux.  The U.S. Govt is
issuing a new "criteria" for these systems to bring their ideas on this
more into line with those of other countries of the world.  At the moment,
each country has its own ideas about this trusted system stuff and - as you
might guess - the Americans are more "military" oriented while the rest of
the world is more concerned with the privacy and availability issues of
commercial industry.  Consider some of the security news groups as places
to hang out:  alt.security - comp.security....

Ray Kaplan
P.O. Box 42650
Tucson, AZ  85733
kaplan@bpa.arizona.edu

RayK 8)

Newsgroups: vmsnet.sysmgt
From: nreadwin@micrognosis.co.uk (Neil Readwin)
Subject: Re: Here is a ACL question for you!
Organization: Micrognosis, a division of CSK(UK) Ltd
Date: Tue, 26 Jan 1993 12:33:07 GMT

In article <4630@mitech.com>, gjc@mitech.com (George J. Carrette) writes:
|> Is it possible to prevent a user from being able to
|> change the protection on a directory that he owns?

No. If you look at the Guide to VMS System Security you will find (Figure
4-4) a flowchart. Even if an ACL explicitly denies access then it will
branch off to BB (UIC based checks). If the requester UIC is the owner UIC
then it checks the protection code for the object. If you read between the
lines of section 4.2.3 then it is clear that UIC based protection always
grants CONTROL access to the owner.
-- 
 Phone: +44 71 815 5283  E-mail: nreadwin@micrognosis.co.uk
 Anything is a cause for sorrow that my mind or body has made
Xref: sparky vmsnet.sysmgt:451 vmsnet.networks.misc:150 comp.os.vms:22071
From: talman@netsys.com (Talman and Associates)
Newsgroups: vmsnet.employment
Subject: VAX/VMS, COBOL, SQL, Chicago Il., (Recruiter)
Summary: Develop CASE Tools in Chicago Il.
Keywords: Recruiter, VAX, VMS, SQL, COBOL,
Date: 22 Jan 93 23:19:59 GMT
Distribution: usa
Organization: Netsys Inc.

Our client is a "Big six" accounting firm looking for experienced Software
developers to provide Data base and systems expertise in support of a key
strategic initiative.   This person will perform logical and physical data
base design, and be responsible for implementation of CASE Technology. 

Our client requires a four year degree, five years of DEC experience, with at
least 2 years experience as a DBA.  Solid Cobol programming skills and 
excellent communications skills.

To respond :  Please do not E-Mail this address.

Call or write     Greg Sayles
                  Roy Talman & Assoc.
                  203 N. Wabash

                  Chicago Il. 60601

                  (312) 630-0130

or Fax  (312)630-0135
Newsgroups: vmsnet.employment
From: paulo@cix.compulink.co.uk (Paul Ockenden)
Subject: VAX Pascal programmer required
Reply-To: paulo@cix.compulink.co.uk
Date: Sat, 23 Jan 1993 15:34:00 +0000


We have an opening for a VAX/VMS Pascal programmer, to work at our
offices in Brighton, on the south coast of England (50 miles from
London).

The main requirements are (obviously) VMS and Pascal (preferably
at the same time!). Knowledge of C would also be an advantage.

We are a small company developing technical software for the oil
distribution industry.

Please send a CV to me fairly quickly if you are interested.

P.

Please DO NOT post queries here - I don't often have time to read
this newsgroup.

 +---------------------------------+--------------------------------+
 |Paul Ockenden, Managing Director,|Telephone        +44 273 621393 |
 |Industrial Might & Logic Ltd,    |Fax              +44 273 621390 |
 |58 Cobden Road, BRIGHTON,        |Email paulo@cix.compulink.co.uk |
 |East Sussex, BN2 2TJ, England.   |                                |
 +---------------------------------+--------------------------------+
Newsgroups: vmsnet.vms-posix
From: jls2@teal.csn.org (Jeff Stoner)
Subject: Alpha TCP and Posix
Organization: Colorado SuperNet, Inc.
Date: Thu, 21 Jan 1993 21:58:11 GMT

Has anyone heard any solid release dates or know who I could contact for info
on getting in a beta program for the following for the DEC Alpha computer
running OpenVMS...

	TCP/IP Services
	Posix

Thanks!

-- 
====== Jeff L. Stoner === Boulder, Colo. ============ /\ = /\ ========== |
                                                 /\  /  \ /  /\  /\    --*--
   Home: jls2 @ bearhug.boulder.co.us         /\/  \/    /  /  \/  /\    |
   News: jls2 @ csn.org                    /\/  \   \  /\  /    \    /\
From: rmcewen@ccs1.bbn.com
Newsgroups: vmsnet.networks.tcp-ip.wintcp
Subject: INETSERV: get_token(): Null token!
Date: 24 Jan 93 21:43:21 GMT
Reply-To: rmcewen@ccs1.bbn.com
Organization: Bolt Beranek and Newman, Inc., Cambridge, MA
NNTP-Posting-Host: ccs1.bbn.com

When the INETSERV process starts up, it broadcast this error:

		get_token(): Null token!

What does this error mean, and how do you correct it?


						-Regis
Newsgroups: vmsnet.networks.tcp-ip.wintcp
From: dlhanson@nap.amoco.com (David L. Hanson)
Subject: Kerberos
Organization: These are my opinions.
Date: Thu, 28 Jan 1993 00:03:14 GMT

Has Wollongong announced when Kerberos support would be added to	
their VMS product?  
=========================================================================
David L. Hanson       Internet --> dlhanson@nap.amoco.com
Amoco Corporation     X.400    --> A=attmail,P=amoco,S=Hanson,G=David,I=L
Any opinions expressed are my own!
Newsgroups: vmsnet.networks.tcp-ip.wintcp
From: larry@eco.twg.com (Lawrence B. Henry III)
Subject: Re: Disabling "rlogin -8" esc sequence for uucp-g
Reply-To: larry@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Mon, 25 Jan 93 15:23:19 GMT


In article <727688156snx@fragile.UUCP>, kramer@fragile.UUCP (Mike Andrews) writes:
|>Bottom line: how can I get uucp-g running reliably?  The problem spot
|>seems to be 'rlogin' -- I can't switch the escape sequence off.  -e^@
|>dosen't work.  (and uucp-g uses nulls)  If someone could point me to
|>the right syntax, or to a replacement rlogin program (I foolishly
|>tried to port 386BSD's rlogin over before realizing how little I
|>really knew about network programming in C :) I'd be extremely grateful..
|>Thanks much.  Sorry for the length, but after seeing a flamefest in other
|>vmsnet.* groups about "people asking questions and not giving enough
|>information"....  :-)
|>
|>            Mike
|>
|>--
|>Mike Andrews - kramer@wittenberg.edu - root@fragile.uucp - kramer@mik.uky.edu
|>
Mike,

If you would be so kind as to open a contact with our support organization we
will send you a new rlogin image that allows you to disable the escape
character...

-Larry.
From: kramer@fragile.UUCP (Mike Andrews)
Newsgroups: vmsnet.networks.tcp-ip.wintcp
Subject: Disabling "rlogin -8" esc sequence for uucp-g
Date: 22 Jan 93 07:35:56 GMT
Reply-To: kramer%fragile.UUCP@ms.uky.edu
Organization: Terminal Frost

I'm trying to run a UUCP connection over the Internet by dialing into our
VAX at school and using "rlogin -8" to get to the machine (hometown) from
which I get my feed.  It works about 99% of the time -- occasionally,
it will choke up on a particular packet, call after call after call.

My guess is since uucp's g protocol requires full 8-bit transparency,
it's coughing on sequences like "^[z" (which causes rlogin to spawn back
out to DCL, for example)...  If I add "-e^v" to the rlogin command line,
the problem goes away for that particular packet, but creates the problem
on another packet.  And obviously, it's a hassle changing it every few
calls....

For now, I'm using the uucp f protocol, which always works, but is
VERY slow, and doesn't check errors as well (one error in a file
causes the whole file to be resent!  Not that this happens much,
since I'm connected with MNP 4...)

My UUCP chat script runs the following after logging into the VAX, to
set up 8-bit transparency as best I know how (if I goofed HERE somewhere,
I'd love to know about it):

$ set broad=(none)
$ set term/nobroadcast
$ set term/dev=unknown
$ set term/pasthru
$ set term/noescape
$ set term/nohostsync
$ set term/noecho
$ set term/passall
$ set term/noreadsync
$ set term/nottsync
$ set term/nowrap
$ set term/noparity
$ set term/eightbit
$ define/user sys$input 'f$trnlmn("sys$output")'
$ mcr twg$tcp:[netdist.user]rlogin s.ms.uky.edu -8 'p1 -l Ufragil
$ logout

The 'p1 is there so that if the g protocol hangs, I can pass it a new
escape character using "-e^[" by just changing my chat script locally.

Bottom line: how can I get uucp-g running reliably?  The problem spot
seems to be 'rlogin' -- I can't switch the escape sequence off.  -e^@
dosen't work.  (and uucp-g uses nulls)  If someone could point me to
the right syntax, or to a replacement rlogin program (I foolishly
tried to port 386BSD's rlogin over before realizing how little I
really knew about network programming in C :) I'd be extremely grateful..

Hardware/software specifics: a 386/40 running UUPC 1.11v for OS/2 2.0,
(soon to become a NeXTstation, which may or may not support uucp-f),
calling a Xyplex LAT server on a VAX 4000-300 running VMS 5.5-1 and
Win/TCP 5.2.  The VAX (wittenberg.edu) does NOT have UUCP installed,
and probably never will.  The home system is s.ms.uky.edu, a 26-processor
Sequent Symmetry S81, running HDB UUCP under Dynix 3.1.2.

Email responses to fragile!kramer@ms.uky.edu or kramer@wittenberg.edu would
be much appreciated, as I've probably chewed up enough bandwidth with this
post...

Thanks much.  Sorry for the length, but after seeing a flamefest in other
vmsnet.* groups about "people asking questions and not giving enough
information"....  :-)

            Mike

--
Mike Andrews - kramer@wittenberg.edu - root@fragile.uucp - kramer@mik.uky.edu
Newsgroups: vmsnet.networks.tcp-ip.wintcp
From: larry@eco.twg.com (Lawrence B. Henry III)
Subject: Re: INETSERV: get_token(): Null token!
Reply-To: larry@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Mon, 25 Jan 93 14:40:46 GMT


In article <lm63bpINNg33@news.bbn.com>, rmcewen@ccs1.bbn.com writes:
|>
|>When the INETSERV process starts up, it broadcast this error:
|>
|>		get_token(): Null token!
|>
|>What does this error mean, and how do you correct it?
|>
|>
|>						-Regis
|>

Regis,
	This is a piece of brain-damage in the inetserver's parser... when
reading the servers.dat file if the parser encounters two or more
consective blank lines it will error out with this message. I know its
confusing and the error message sucks... this mis-feature will be removed in
a future release of PathWay...

The solution is to check the servers.dat file for blank lines and squeeze them
down to at most one blank line.

-Larry.
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: complete version of CMU-IP...
From: "Henry W. Miller" <henrym@sacto.mp.usbr.gov>
Date: Wed, 27 Jan 1993 21:32:57 EST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
CC: henrym@sacto.mp.usbr.gov
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

judson@girtab.usc.edu (Tom Judson) writes:

|In article <torppa.728078157@mits> torppa@mits.mdata.fi (Jarkko Torppa) writes:
|>I'm trying to find complete CMU-Open VMS/IP preferably by ftp. I already
|>know SACWMS.MP.USBR.GOV but the set is far from complete there.
|>
|>tcpip+@andrew.cmu.edu said that until 15 of january I could have ftp:d it
|>from one of their machines, after that I should contact decus.
|>--
|> Jarkko Torppa |        torppa@mits.mdata.fi |  Uh huh
|
|I also need a "complete" version.  Is it available from anywhere else
|besides decus?  If decus is controlling it, why don't they have an ftp
|site?
|
|I have the executable files from SACWMS.MP.USBR.GOV, could someone mail
|me the installation instructions and any documentation that they have.
|I would like to give this a try as soon as possible.
|

Tom,
	A "full kit" will be made available as soon as possible.  In the
interim, we'll probably release the individual critical pieces as smaller
kits.  The main reason is that, franking, writing and debugging a large
VMSINSTAL kit is a pain, especially when you have a complex relationship
like the CMU components, and you have limited CPU resources for testing.
One typo or bug in the kit can blow away an hours worth of testing, and
you have to restart from scratch.  I've written a comphrehensive install
kit for inside of the Bureau, and believe me it was not fun.

	I have not been informed that DECUS is "controlling" it.  To my
knowledge, they were just going to act as a repository.

-HWM
----------
Henry W. Miller
Assistant Systems and Network Manager
U.S. Bureau of Reclamation
Mid Pacific Region
2800 Cottage Way MP1100
Sacramento, CA 95825
(916) 978-5108 / FTS - Same as commercial
Inet:	"henrym@sacto.mp.usbr.gov"

"I've fallen, and I can't get up!"
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: IBM3270 emulation
From: "Henry W. Miller" <henrym@sacto.mp.usbr.gov>
Date: Tue, 26 Jan 1993 02:04:13 EST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
CC: henrym@sacto.mp.usbr.gov
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

uucm000@uxa.ecn.bgu.edu (Tingli Pan) writes:

|Is there a way to emulate IBM termina 3270 on cmu-tek? (free package)
|
	Not at present, but it's an idea whose time has come.

	CMUTEK is not free.  Cheap maybe, but not free.  And not easy,
either.  That's a joke.

-HWM
----------
Henry W. Miller
Assistant Systems and Network Manager
U.S. Bureau of Reclamation
Mid Pacific Region
2800 Cottage Way MP1100
Sacramento, CA 95825
(916) 978-5108 / FTS - Same as commercial
Inet:	"henrym@sacto.mp.usbr.gov"

"I've fallen, and I can't get up!"
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: EGADS.... How embarrassing...
From: "Henry W. Miller" <henrym@sacto.mp.usbr.gov>
Date: Wed, 27 Jan 1993 20:40:47 EST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
CC: henrym@sacto.mp.usbr.gov
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

John,
	I think both ways have merits.  With the old way, you could
respond directly with the send, and the address of the list-in-general
wasn't that bad to type into the 'CC:' line.  At least with the new
method, you can see from VMSMail when doing a 'DIRECTORY' that the message
is concerning CMU-xxx.

-HWM
----------
Henry W. Miller
Assistant Systems and Network Manager
U.S. Bureau of Reclamation
Mid Pacific Region
2800 Cottage Way MP1100
Sacramento, CA 95825
(916) 978-5108 / FTS - Same as commercial
Inet:	"henrym@sacto.mp.usbr.gov"

"I've fallen, and I can't get up!"