HDTenEightyP/NetNews huggingface dataset:
From: tillman@swdev.si.com ("Brian Tillman, Smiths Industries, VAX Support, x8425")
Newsgroups: comp.os.vms
Subject: RE: DECforms and the INSERT HERE key on a VT100
Date: 6 Nov 92 13:54:09 GMT
Distribution: world
Organization: The Internet

Gerard Stafleu (gerard@uwo.ca) writes:

>I am using DECinspect CM, which uses DECforms as its interface.  It
>wants me to use the function key INSERT HERE, but I have a VT100, which
>doesn't have this key.  Can I work around this?

You could always type <ESC>[2 (escape, left bracket, 2), since that's the 
sequence that INSERT HERE generates.

-----------------------------+--------------------------------
 Brian Tillman               | Internet: tillman@swdev.si.com
 Smiths Industries, Inc.     |           tillman_brian@si.com
 4141 Eastern Ave., MS129    | Hey, I said this stuff myself.
 Grand Rapids, MI 49518-8727 | My company has no part in it.
-----------------------------+--------------------------------
From: dwight@geohub.gcn.uoknor.edu (Dwight D. Moore)
Newsgroups: comp.os.vms
Subject: Re: Allocated drive problem
Date: 5 Nov 92 15:07:42 GMT
Reply-To: dwight@geohub.gcn.uoknor.edu
Organization: Geosciences Computing Network, Univ. of Oklahoma
Originator: usenet@kittyhawk.ecn.uoknor.edu

In article <01GQO9SDSO428Y6MQT@AdminA.RFERL.Org>, SMITHM@AdminA.RFERL.ORG writes:
|
|>	 
|>	I have a problem with a TA90 drive. When I do a  $SH DEV MUA10
|>	it shows the drive as :    Mounted cached
|>		                   alloc foreign
|>
|>	However, the owner process ID does not exist.
|>
|>
|>	I think the drive was alocated by a remote system (via RTF)
|>	when the remote system 'crashed', leaving the tape drive 
|>	allocated by a non-existent process.
|>
|>
|>	Is there a way to "force" deallocation of the device without 
|>	a reboot.
|>
|>
|>thanks in advance, 
|>
|>Michael.
|>
|>
|>
|>
|>			################################
|>Michael J Smith           X400     : c=US;ad=MCI;pd=RFERL;s=SMITH;g=MICHAEL
|>Systems Programmer	  INTERNET : SMITHM@RFERL.ORG
|>RFE/RL inc                Phone    : 089 210  23723
|>Munich                    Fax      : 089 2102 3752  
|>Germany
|>
|>

We had a similar problem and there is a bug in the driver software.
You might need to contact CSC for a "patch" (CSC Patch 245 is
the one we recieved).
----------------------------------------------------------------------------
Dwight D. Moore
Geosciences Computing Network
University of Oklahoma

dwight@geohub.gcn.uoknor.edu (129.15.40.10)
These opinions do not necessarily represent the opinions of OU or the GCN.
----------------------------------------------------------------------------
From: DWING@UH01.Colorado.EDU ("would rather be skiing ...")
Newsgroups: comp.os.vms
Subject: Re: How to make VMSMail run lots faster
Date: 13 Nov 92 00:33:13 GMT
Distribution: world
Organization: The Internet

Nick Abbot <70303.1354@compuserve.com> apparently wrote, and 
<verifone!jimmy_t@UUNET.UU.NET> posted (on Nick's behalf):

[...]
>    On a side note.  You might want to BAC/IM these drives, and INIT them
>with the /HEADERS=<very big>, ie. double the size of INDEXF.SYS now.  This will
>give your INDEXF.SYS the room to grow and not "fall apart" later.  Then BAC/IM
>to restore, using the /NOINIT qualifier to preserve the newly allocated size of
>INDEXF.SYS.  DIR/SIZ=ALL.

Extending the INDEXF.SYS in this manner will only work in VMS V5.5-2, or if
you've installed the backup patch to make your Backup the same as V5.5-2's
Backup.

-Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11)
 Systems Administrator, University Hospital, Denver
From: jeh@cmkrnl.com
Newsgroups: comp.os.vms
Subject: Re: sputtering FLAME ALERT>>
Date: 6 Nov 92 15:26:13 PST
Organization: Kernel Mode Consulting, San Diego, CA

In article <1992Nov6.015216.1@vxcrna.cern.ch>, zeus@vxcrna.cern.ch writes:
> [...] I suspect that by UNIX you mean an O/S with 
> something that could be called a file system [...]

Eh?  Since when has any version of Unix ever had something that could be called
a file system? 

	;-)

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
From: DEREK@U.WASHINGTON.EDU
Newsgroups: comp.os.vms
Subject: Re: FLAME ALERT>>  DECnet and OSI
Date: 9 Nov 92 18:10:00 GMT
Organization: The Internet

Don Stokes wrote:

>DEREK@U.WASHINGTON.EDU writes:  (That's me...)
>> Don Stokes provided a short little routine which, run in kernel mode,
>> would set the PCB$M_NODELET bit in a PCB.  Just thought I would point
>> out that this bit is only being tested in "newer" versions of VMS.  It's
>> been there as far back as I can remember, but used to not work.  I think
>> it started being tested back in V5.4, but cannot say for sure.  If you
>> are running an older version of VMS, it might not prevent you from logging
>> out.
> 
>I'm fairly sure this coincided with the implementation of the audit server.
>That would have been around V5.2ish, but the NODELET bit may have been
>implemented earlier in anticipation of an "unkillable" audit server.

Well, it is listed in my "VAX/VMS Internals and Data Structures" manual
(order number AA-K785A-TE) on page 9-12, and it is noted that the bit is
unused.  By the way, this manual was published in April, 1981 for VAX/VMS V2.2.

:)

-Derek S. Haining
 University Computing Services
 University of Washington
 Seattle, Washington  98195 
 (206) 543-5579

 DEREK@MAX.BITNET
 DEREK@MAX.U.WASHINGTON.EDU
Newsgroups: comp.os.vms
Subject: Re: TUNING - QUANTUM SYSGEM parameter
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 14 Nov 92 03:23:39 GMT
Distribution: world
Organization: The Wolery

pihlab@hhcs.gov.au writes:
> 2. What are some reasonable starting QUANTUM settings for the following
>    machines:

The calculation of QUANTUM isn't really tied to the hardware speed.  Rather,
it should be based on the number of interactive computable processes that 
would use up their quantum and the acceptable response time.

Also, the calculation was a bit off for V5.2(& 5.3?), because under these
versions, a process would not preempt another unless it was 3 or more 
priority levels above the current process.  This has now been fixed, but
with those versions, knocking QUANTUM right down would have helped a lot,
effectively providing a form of preemption, although not nearly as good
as real preemption as done in current and earlier versions.  Could this
be why you got such an improvement by diddling QUANTUM before?

Basically, QUANTUM should be calculated as acceptable response divided by
the number of long term computable interactive processes, ie those that are
unlikely to let the processor go before quantum end.  I'd put "acceptable
response" at around 100ms, and you should estimate a little on the high
side for the number of computable processes.



--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: need TALK for VMS!
Date: 6 Nov 1992 23:09:50 GMT
Organization: HST Wide Field/Planetary Camera
Distribution: world
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <01GQU1OA931S91WRIW@dcu.ie>, 89500831@VAX1.DCU.IE (Ronnie Albuquerque) writes:
>I need the TALK utility for VMS...I'm running version 5.4-3 under MULTINET.
>Does anyone know where I could get a copy? FTP sites, anything....

You should be able to find a copy in the directory MULTINET:

$ DIRECTORY MULTINET:TALK*

Directory MULTINET_COMMON_ROOT:[MULTINET]

TALK.EXE;1               19/21      1991-12-28 11:21:30.98  (RED,RED,E,E)
TALK.HLP;1                3/3       1991-12-28 11:21:45.36  (RD,RD,R,R)
TALK_OLD.EXE;1           19/21      1991-12-28 11:21:32.46  (RED,RED,E,E)
TALK_OLD_SERVER.EXE;1
                         12/12      1991-12-28 11:21:33.21  (RED,RED,,)
TALK_SERVER.EXE;1        14/15      1991-12-28 11:21:31.71  (RED,RED,,)

Total of 5 files, 67/72 blocks.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
From: simons/G=Colin/I=CB/S=Sewell/O=H.A.Simons.Ltd/OU=CORP@mhs.attmail.com
Newsgroups: comp.os.vms
Subject: Re: SET TERM/INQUIRE
Date: 12 Nov 92 02:50:01 GMT
Distribution: world
Organization: The Internet

FRED W. BACH writes:

|In article <9211031433.01@klnet.UUCP>, klovatt@klnet.UUCP (Keith Lovatt) writes...
|>FRED W. BACH (music@erich.triumf.ca) wrote:
|>:    We have just found out that SET TERMINAL/INQUIRE should not be followed
|>:  immediately by another SET TERM command.  Depending on system and network
|>:  overhead, there is about a 75% chance that the second command will be
|>:  totally ignored.  The effect is very reproducible.
|
|  And then he answers
|> 
|>Why not just put it all on one line? ie 
|> 
|>$ SET TERM/INQURE/NOTAB/NOFORM
|> 
|>This works just fine for us.
|>Keith Lovatt                 	|	Scarborough, Ontario, Canada
|
|    I seem to remember from a long time ago that SET TERM/INQUIRE
| *was* supposed to be used in its naked form and not combined with 
| other SET TERM statements.  I have no way of checking whether this
| restriction was ever true or not.
|
|   I don't think the SET TERM/INQUIRE/DEV=vt200/PAGE=28 is reliable in 
| our setup here.  We have separated them into two separate commands
|
|    SET TERM/INQUIRE     and         SET TERM/DEV=VT200/PAGE=28
|
| which must be separated by more than 0.5 seconds on our 3100.  We are
| running VMS 5.5-2HW and motif 1.1  .
|

    The problem is the combination of the /INQUIRE and /DEVICE_TYPE=
    qualifiers. I am not sure i see the point of using SET
    TERMINAL/INQUIRE which sets the device type of the terminal
    and then immediately following that with a SET TERM/DEV=VT200
    which negates any results of SET TERM/INQ unless the inquiry
    set the terminal to vt200_series type. Including both qualifiers
    on the same SET TERM command does not make sense and in fact
    the result of such a command would be the that the device
    type would be set to whatever the inquiry said it was, while the
    /DEVICE_TYPE value would be ignored.

    However, you can put other qualifiers with the SET TERM/INQ
    command with no problem. the inquiry sets the device type +
    any other terminal capabilities/defaults of the particular
    device type and further qualifiers override those
    capabilities/defaults.

    the fact that SET TERM/INQ flushes the typeahead buffer is
    documented under HELP SET TERM/INQUIRE. This would not affect
    command file input, just user typed input.

					colin sewell
					h.a.simons ltd.
					vancouver, bc
From: simard@vax.sonoma.edu
Newsgroups: comp.os.vms
Subject: Re: need TALK for VMS!
Date: 6 Nov 92 23:09:27 GMT
Organization: Sonoma State University

In article <01GQU1OA931S91WRIW@dcu.ie>, 89500831@VAX1.DCU.IE (Ronnie Albuquerque) writes:
> Date sent : Fri, 6 Nov 92.
> 
> Hey , fellow VAX users..
> 
> I need the TALK utility for VMS...I'm running version 5.4-3 under MULTINET.
> Does anyone know where I could get a copy? FTP sites, anything....
> 
> Thanks in advance.
> 
> Ronnie.
> --
> Ronnie Albuquerque.
>                           Internet :89500831@dcu.ie,cc445@cleveland.freenet.edu
>                           UUCP     : dcu.ie!89500831@uunet.UUCP
>                           Bitnet   : cc445%cleveland.freenet.edu@cunyvm.bitnet
> 
> "This universe is mine...I am GOD here!" - Cyberjob in 'The Lawnmower Man'.
> 

Try HELP MULTINET TALK <cr>

At least its on our version of Multinet.

_Ernie
Xref: sparky comp.os.vms:17847 vmsnet.sysmgt:336
From: Chris_F_Chiesa@cup.portal.com
Newsgroups: comp.os.vms,vmsnet.sysmgt
Subject: Re: HELP: how to stop and prevent break in?
Date: Thu, 12 Nov 92 06:33:28 PST
Organization: The Portal System (TM)

Someone who doesn't use a .signature (Portal doesn't pull in headers here,
either) writes:

>We got very strange things happened on one account where we found the owner of
 
>files are not only the owner of the account but also another one.  
>
>	OWNER=[my,WHO] 
>
>All the files and directories under that account have two owners  [...]

Forgive me if the following insults your intelligence, but the other respon-
dent I see to date, seems to have missed the point entirely.

When you say "the files... have two owners," are you saying that when you 
see

	OWNER=[my,WHO]

you believe that the file is owned by two people, named "my" and "WHO"? 
If so, I believe you are mistaken.  Files under VMS have only ONE owner, 
and I've never heard of ANY contortion anyone can go through to change that.

I believe you are merely seeing the file's ownership information expressed
as a Group and Member -- [GROUP,MEMBER] -- rather than as an Identifier --
[IDENT] .  And I further believe that this is caused by the absence of an
Identifier for the file's owner, in the system UAF.

You need to determine which user is "user 'WHO' in group 'my'," and if he
is legitimate and entitled to ownership of the files, simply add the proper
identifier for him -- often, this has the same appearance as his username --
to the UAF using AUTHORIZE ADD/IDENT /USER=username .

You should also try to determine how the person's identifier either failed
to get created when his account was added to the system, OR was subsequently
deleted from the UAF.  You could still have a breakin I suppose, but this
seems like an odd form of attack if so.

Chris Chiesa
  Chris_F_Chiesa@cup.portal.com
Newsgroups: comp.os.vms
From: parris@star.enet.dec.com (Keith B. Parris)
Subject: Re: VMS 5.5-1 / MIVc, satellite prevents the boot host to reboot
Organization: Digital Equipment Corporation
Date: Thu, 5 Nov 1992 14:07:49 GMT


In article <1992Nov4.164802.14651@dxcern.cern.ch>,
clusmgr@vxcern.decnet.cern.ch () writes... 
> 
>We recently upgraded one of our VAX clusters from VMS 5.4-1A to VMS 5.5-1.
>This cluster was already an MIVc but without any satellite.
>Just after the upgrade, we introduced one satellite in the cluster.
> 
>Since this date, if the satellite is UP, we are unable to reboot the boot host.
>Each time the reboot is hung, very early in the startup procedure (see below).
>We need to kill the satellite to complete the reboot.
...
>Is this a known problem with MIVc and VMS 5.5-1 or did we make something wrong?

This should work.  Most probable cause is a resource shortage on one of the
nodes, most likely the satellite.  I'd check first for a shortage of non-paged
pool.  Only way to know for sure is to get into the hung condition and then
initiate a crash dump (see the SDA manual) and have someone take a look at it.
You may have to do this on all 3 systems to find which one is having a problem.

>Cluster-related SYSGEN parameters
>=================================
>Parameter Name            VXCRNZ      VXCRNA       VSOPS      
>--------------            -------     -------      -------   
...
>EXPECTED_VOTES                  3           3            3       
>VOTES                           1           2            0       

This is fine.  Using expected votes of 1 and giving 1 vote only to VXCRNA would
have the same effect.

>ALLOCLASS                      22          22           22       
>MSCP_LOAD                       0           1            0       
>MSCP_SERVE_ALL                  0           1            0       

No need to have ALLOCLASS set to a non-zero value on the satellite VSOPS, or on
the non-serving node VXCRNZ.
____________________-_-----_-_---__-__-_-----_____----_-____-_----____------_-__
         Keith B. Parris           Digital Equipment Corporation
                                   Alpha VMS Engineering, Clusters & I/O Group
Any information here which is later found to be inaccurate was mine, of course.
Digital gets the credit for any actual facts which happen to appear in this.
-__---__-_---__-__-_-_-_-_____-__--_____---_-___-_-_-_--__-_--_--___-_-__--_____
From: bruce@ais.com (Bruce C. Wright)
Newsgroups: comp.os.vms
Subject: Re: QIO failing with ACCVIO (WIN-TCP)
Date: 5 Nov 92 00:21:53 GMT
Article-I.D.: ais.1992Nov5.002153.5819
Distribution: world
Organization: Applied Information Systems, Chapel Hill, NC

In article <9211042022.AA20329@relay2.UU.NET>, ddj@gradient.UUCP writes:
> I have a network application that runs under VMS, and can use CMU,
> Fusion, UCX, and DECnet transports.  After a "quick and easy" port
> to TWG's WIN-TCP package, I started to get errors from the
> SYS$QIO(... IO$_READVBLK...) call.
> 
> The call comes back immediately with a status of ACCVIO.  This does
> not happen right away -- the program succeeds in opening and exchanging
> packets over two or three network ports to various servers, but when
> it reaches the third (or fourth) port it fails.
> 
> The worst part is that the problem does not occur when the program
> is run from VMS DEBUG.  There is only one place in the program where
> this call is made, and the arguments all look valid (and in fact the
> call works properly for a couple dozen packets before the fourth
> socket is opened).
> 
> The program uses UDP packets (except for the decnet transport),
> and is run as a detached process, with a bytlim of about 32k and
> a file limit of about 30.  It is normally started at boot time,
> with system privs.  However it still fails when I run it from
> a terminal.
> 
> 1) What could be different between run/nodebug (or not compiled
> for debugging), and running under the debugger?

The main thing would be that you might get somewhat different routine
and static data addresses, and different stack frame addresses.  There
would likely be different stuff on the stack, etc.

Usually this type of behavior is caused either by an uninitialized
variable, or a wild pointer reference (which may be an uninitialized
pointer, or a pointer which has a stale pointer value -- into a stack
frame that is no longer active, or to dynamic storage that has already
been freed).  In either of these cases, the different addresses for
various objects mean that different junk gets picked up from the
uninitialized variable.

> 2) Is there any way to print the failed address, etc, when the
> access violation is passed in the system call return value (as
> opposed to getting the fault directly)?

In general no.  Some drivers may provide this information, but it's
not a standard return value.

> 3) Has anyone else run into anything like this problem before?
> What can be done to avoid it?  Is there a limit in the TWG network
> ACP that would prevent a process from creating more than two or
> three sockets and starting receives on them all?

I haven't heard of a problem like this.  I would doubt that it's
a limitation in TWG but I don't know for sure.

Bruce C. Wright
Newsgroups: comp.os.vms
From: theune@aplcenmp.apl.jhu.edu (Peter Theune)
Subject: Re: User limit in VS4000
Organization: Johns Hopkins Continuing Professional Programs
Date: Thu, 12 Nov 1992 12:56:00 GMT

system@NIUHEP.PHYS.NIU.EDU writes:

>>I've got a VaxStation 4000 VLC, with an interactive user limit of 2.
>>I asked for a more extensive limit, and people from local's Digital
>>told me that even they install another VMS license, hardware prevents
>>that the number of interactive users gets over 2.

>Bullfinches! I just logged into a VLC under three usernames (the last one
>to log in was unprivledged, only one had extra privs).
>There was rumors of a policy not to allow more than 2 logins (which was
>{damn, I'm not in edit mode} because of the extra power of the 4000s and
>the low price, DEC didn't want people using the 4000 in place of microvaxes.
>(dumb idea in my opinion given what they are competing against.)  In fact
>I believe we ran into that policy, but we have the CSLG :) which allows us
>,as an educational institution to have infinite logins.
>Robert Morphis
>system%niu.hepnet@lbl          BITNET
>system@phys.niu.edu            INTERNET
>NIU::SYSTEM                    HEPNET

Robert,

I suspect that you logged in as an X term session, for some reason the
license fac doesn't check for them. You can have as many x sessions as
you can stand.

The VLC uses a class D workstation license, which normally allows two
sessions. You cannot even "set host 0" after the second session is
started. You can however have many users connected via Xterm.

There _IS_ a special 8 user license available, but you must speak the
magic words to get it, and depending on the regional office, it can be
either very cheap or very expensive. Ours cost us 23 dollars (US) a
couple of years ago for a similar situation with a vaxserver 3600. The
situation with the servers is even more severe than with the VS, the
server allows only one user, not counting the console. If a user is
logged on at opa0, then no one else can get on. (servers use a class C
license I think).

Anyway, the bottom line is; use X. 

Also, I think that UCX (the dec tcp/ip package) does not check users,
but this might have been changed.

Peter.
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Kermit packet size
Date: 8 Nov 1992 09:13:04 GMT
Organization: HST Wide Field/Planetary Camera
Distribution: world
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <1992Nov7.155642.1192@galaxy.gov.bc.ca>, ewilts@galaxy.gov.bc.ca (Ed Wilts) writes:
>In article <01GQVM6KPFZ48WW1MS@scorva>, CAPTANSKI33@SNYCORVA.BITNET (CHRIS TANSKI) writes:
>> Anyone know how to change the pakcet size kermit sends from 84 to
>> 9000? My comm. program receives that fast so it would be nice if this
>> kermit server would send it that fast. Please reply directly.
>
>It depends on the version of Kermit you are using.  There are 2 different VMS
>flavours, each of which has production and test versions.
>
>Kermit-32
>	The latest *production* version available from Columbia is 3.3.126. 
>This does not support long packets.  You can pull off a test version that does. 
>I believe the latest test is T3.4.018.

Are you sure 3.3.128 isn't "production"?

$ mcr kermit
VMS Kermit-32 version 3.3.128

Default terminal for transfers is: 
_RTA1:

Kermit-32>help set send packet

SET

  SEND

    PACKET_LENGTH




       This will set the SEND packet length.  The value for  this  parameter

       must  be  between  10 and 1000.  Packet lengths outside of this range

       are illegal.  The default value is 80.



                 Kermit-32>SET SEND PACKET_LENGTH n



       Where 'n' is the send packet length to use.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
Newsgroups: comp.os.vms