HDTenEightyP/NetNews huggingface dataset:
From: dunnett@mala.bc.ca (Malcolm Dunnett)
Newsgroups: comp.os.vms
Subject: Re: LAT Printer Pausing.
Date: 23 Jan 93 10:50:59 -0700
Organization: Malaspina College

In article <930122132020.2020011d@LUDWIG.CTD.ORNL.GOV>,
    LPZ@LUDWIG.CTD.ORNL.GOV ("Lawrence MacIntyre - 615.576.0824") writes:

 [original post asked about queue on Datability server PAUSEing under
   VMS 5.5-2]

> 
> If you have a print queue in the paused state, it means that the queue received
> a ^S from the printer (assuming that you use XON/XOFF) and hasn't received the
> corresponding ^Q.

    This is not strictly true. When a printer goes offline ( XOFF or
dropping DTR for example ) the que initially goes into a STALLED state,
from which it will recover when the printer goes back online.

    I believe that if a printer stays offline for long enough ( and I'm
not sure "long enough" is a constant ) the que will change from STALLED
to PAUSED. Once the queue is PAUSED it requires operator intervention
( eg STOP/QUE/RESET ) to get it started again.

>  The possibilities are:
> 
> 1.  Your printer is toast

    If this were the case I would expect to see the que enter the STALLED
state for a while first, then change to PAUSED.

> 2.  Your terminal server is toast
> 3.  Something else ;-()
> 
    Queues can pause for many reasons other than an offline printer. I
would guess that it's either a communication problem with the server
or a bug in the LAT software. If you set the queue /RETAIN=ERROR the
print jobs which fail when the queue pauses will be retained and have
an error message associated with them. This may provide useful information
about why the pauses are occurring.

    If you have access to telephone support call and ask about the
status of CSCPAT_0511. It contains patches issued for LATmaster
which address a similar problem (among others), I'm not sure if they
are incorporated in 5.5-2 or not ( they were still required in 5.5-1 )

    You should also check with Datability to make sure you have the
latest version of their software. They released a major upgrade a year
or so ago and I wouldn't be surprised if the older version has problems
communicating with LATMaster (early LATMaster had problems talking to some
third party terminal servers )

=============================================================================
Malcolm Dunnett    Malaspina College                Email: dunnett@mala.bc.ca
Computer Services  Nanaimo, B.C. CANADA V9R 5S5       Tel: (604)755-8738
From: ISP00JW@DUCVAX.AUBURN.EDU
Newsgroups: comp.os.vms
Subject: Name removal
Date: 20 Jan 93 16:48:00 GMT
Organization: The Internet

Please remove me from list......Thanks.
From: rankin@EQL.Caltech.Edu (Pat Rankin)
Newsgroups: comp.os.vms
Subject: Re: VAXC divide problems (V3.2)
Date: 27 Jan 93 05:47:20 GMT
Organization: The Internet

>>>     subl2   #4,sp
>>>Don't ask me why it allocated space on the stack without using it,

>>I think the stack space is for the condition handler.

>       Think again. The subl2 is obviously for the variable i which is
>       allocated on the stack. [...]
>
>       It seems that the compiler didn't "notice" that it didn't use the
>       space it put asside on the stack for i. This has obviously nothing
>       to do with a condition handler.

     Nope.  As I explained in an earlier reply, the subtraction of 4
from the stack pointer is for allocation of a local variable for use
by the VAXC$ESTABLISH condition-handler setup routine.  That's not a
condition handler itself, but the address of any handler you pass it
is stored on the stack in the top four bytes, so they actually are
space for a [pointer to a] condition handler.  The value pointed to by
the frame pointer is set to a handler inside the C run-time library.
Gruesome details are available in the CRTL portion of the VMS listings.
This ugly violation of the VMS Procedure Calling Standard is for
setjmp/longjmp handling, and is inherited from the Pascal compiler
of all places!

     You can easily verify this by exploring with the debugger.  Or even
simpler for the case in question, either compile with /nooptimize or
declare `i' to be volatile and you'll discover that 8 bytes are allocated
on the stack instead of 4, and `i' uses the 2nd longword.  The compiler
didn't forget that it had moved `i' into a register.

		Pat Rankin, rankin@eql.caltech.edu
From: rbhatt@quasimodo.Inria.Fr (Rahul Bhatt)
Newsgroups: comp.os.vms
Subject: Re: Editing a large file
Date: 21 Jan 93 22:51:07 GMT
Organization: INRIA Sophia Antipolis, France

I have used emacs on VMS for this purpose and it work extremly well. 

Hope it helps

Thanks
Rahul Bhatt
From: LABELLES@ZENO.MSCD.EDU (Stephen LaBelle - MSCD)
Newsgroups: comp.os.vms
Subject: Re: RE: Operator Accounts
Date: 22 Jan 93 18:59:39 GMT
Distribution: world
Organization: The Internet

Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet, writes:

*!Stephen LaBelle, <LABELLES@ZENO.MSCD.EDU>, writes:
*!
*!>You can control priviledges and still allow your operators to do their work
*!>by setting up one or more restricted accounts. Look at the restricted flag
*!>for UAF records. I personally like using the "RESTRICTED" flag, VMS takes 
*!>care
*!>of some of the security issues as far as breaking out to the dollar sign.
*!>I challenged a couple of my operators to break it they could not.
*!
*!If you want a captive account, use CAPTIVE and not RESTRICTED.  See VMS V5.5 
*!release notes, section 2.4.3, which warns that in "a future release of VMS, 
*!system software components will be modified so they do not use the RESTRICTED 
*!flag to disable SPAWN commands. In particular, MAIL and TPU will not disable 
*!a SPAWN command ... if the account has been marked RESTRICTED.".  There's 
*!more 
*!text in the actual release notes that details this modification.
*!
*!-Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11)
*! Systems Administrator, University Hospital, Denver

Hello INFO-VAX and/or COMP.OS.VMS,

For the record, Dan Wing is a friend of mine. He also is someone whom many
times keeps me on my toes! Dan pointed out that one should use CAPTIVE and
NOT RESTRICTED. I stand corrected! In fact I have a security hole which I
will be plugging today. 

To the original party whom posted the inquiry, follow Dan's advice not
mine. Use the CAPTIVE flag!!! This assumes you set things up in a manner
such as I suggested, you may choose not to.

I also found some of the other responses about doing operator with a 
a specific account for each of them interesting. A different rationale,
with its own merits.

Dan volunteered to break my operator environment! I declined!

							Steve

##############################################################################
# Stephen LaBelle                        # Internet : labelles@zeno.mscd.edu #
# Systems Programmer                     #            labelles@clem.mscd.edu #
# Metropolitan State College of Denver   #####################################
# Denver, Colorado  USA                  # Bitnet   : LABELLES@MSCD.BITNET   #
##############################################################################
# DISCLAIMER: The opinions expressed are mine and in no way, shape or form   #
# neccessarily reflect those of Metropolitan State College of Denver.        #
##############################################################################
From: steve@dbaccess.com (Steve Suttles)
Newsgroups: comp.os.vms
Subject: Re: How can I change my Username
Date: 27 Jan 93 21:31:30 GMT
Organization: Cross Access Corp., Santa Clara, CA
X-Newsreader: Tin 1.1 PL4

finocchiaroj@merrimack.edu () writes:
: I was wondering if there is a way that I can change my username by bypassing
: the system managers protected privliages.

Actually, there is.  For about $35,000 you can buy a vax of your own,
and you can call yourself anything you want.

Somewhat less expensive options include asking the system manager.

If this is a real problem for you, you might consider getting a mail
account on another machine (there are some commercial services that do
just that) and have that machine forward the mail to the name you don't
like (presuming that the VMS host is the machine you prefer to use).

Does SYSTEM know about this?

sas
-- 
Steve Suttles                Internet:  steve@dbaccess.com      Dr. DCL is IN!
CROSS ACCESS Corporation     UUCP: {uunet,sgiblab}!troi!steve  Yo speako TECO!
2900 Gordon Ave, Suite 100   fax: (408) 735-0328              Talk data to me!
Santa Clara, CA 95051-0718   vox: (408) 735-7545   HA! It's under 4 lines NOW!
From: louis@BARRA.COM (Louis Dunne)
Newsgroups: comp.os.vms
Subject: Re: Tracking DECW$DISPLAY
Date: 26 Jan 93 21:35:53 GMT
Distribution: world
Organization: BARRA Inc., Berkeley, California.

On Jan 25,  3:02pm, Tigger wrote:
> Subject: Tracking DECW$DISPLAY
>Is there any way (such as a code to $GETDVI) to examine a _WSAn: device
>created with the SET DISPLAY command and determine what node it points
>to (ie the value of the /NODE qualifier to the SET DISPLAY)?
>
>Greg Orman
>greg@pomona.claremont.edu
>

        From DCL do the following (undocumented, of course):
                $ sh sym decw$*
                %DCL-W-UNDSYM, undefined symbol - check validity and spelling
                $ show display/symbol
 
                    Device:    WSA3:  [super]
                    Node:      HERMANN.BARRA.COM
                    Transport: TCPIP
                    Server:    0
                    Screen:    0
 
                $ sh symbol decw$*
                  DECW$DISPLAY_NODE == "HERMANN.BARRA.COM"
                  DECW$DISPLAY_SCREEN == "0"
                  DECW$DISPLAY_SERVER == "0"
                  DECW$DISPLAY_TRANSPORT == "TCPIP"

	So, rather than reading the output from a $show disp (ugh),
	you can examine the DECW$DISPLAY_NODE. 

	I think that there is something similar you can do with
	$GETDVI. I seem to remember John "Fast Eddie" McMahon
	mentioning something about this before. I'll see if I can
	find the information for doing this from an image.

Louis
       -------------------------------------------------------------------------
      / Louis Dunne                          /                                /
     /  VMS/UNIX Systems                    /  Internet:   louis@barra.com   /
    /                                      /   Phone:      +1 510 649-4229  / 
   /    BARRA, Inc.                       /    Fax:        +1 510 548-4374 /
  /     1995 University Ave., Suite 400  /                                /
 /      Berkeley, CA 94704              /                                /
-------------------------------------------------------------------------
From: mccurdy@bestsd.sdsu.edu
Newsgroups: comp.os.vms
Subject: Re: Check your temper at the door!
Date: Thu, 21 Jan 93 01:01:52 GMT
Organization: San Diego State Univ.
NNTP-Posting-Host: bestsd.sdsu.edu

>From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
>Subj: Re: Check your temper at the door!
>Date: 16 Jan 1993 14:27:06 GMT
>
>
>I, for one, consider it an act of kindness to let someone who doesn't know what
>he's doing know that, and an act of cruelty to let him go on believing he
>*DOES* know what he's doing when he doesn't.
>

Telling them in a matter of fact, civil way is of benefit and appropriate. 
Telling them rudely and embarrassing them in a public forum is really weak.
Really weak.
Newsgroups: comp.os.vms
From: tihor@acf3.NYU.EDU (Stephen Tihor)
Subject: Re: VAXen and VMS version ( was Re: Remotely rebooting vms )
Organization: New York University
Date: Fri, 22 Jan 1993 23:22:00 GMT

Systems that do not repsond to control P susually respond to BREAK.

Unfortunately I was recently reading the manuals for the 5900 
hardware and IT lists 2 ways to get to console command mode (>>>)
(a) power off the box and then power it on,
(b) run the UNIX shutdown command.

Not pleasant if you have had a problem withthe system getting
wedged.   Time to break out the power control cabling.
From: francini@narfvx.enet.dec.com (John Francini)
Newsgroups: comp.os.vms
Subject: Re: Can DCL programs execute 'other' commands ?
Date: 24 Jan 93 22:34:14 GMT
Organization: Digital Equipment Corporation, Littleton, MA


In article <01GTUMJYR28G8Y6FL7@JCSVAX1.BITNET>, HANY@JCSVAX1.BITNET writes...
>Hi ..
>        I am new to writing DCL programs. I tried to make a program
>execute commands other than those issued at the '$' prompt, but just
>couldn't figure out how to do it. For example .. What would be the code
>for a program that would read 2 mail messages, then return back to the
>'$' ? .. The following did NOT work :
> 
>$ mail
>$ read 1
>$ read 2
>$ exit
> 
>Thanks for any help.
>Hany.
>[ e-mail: hany@jcsvax1.bitnet
>      or: hany%jcsvax1.bitnet@pucc.princeton.edu ]
> 
> 

Leave off the dollar signs for every line being fed to the program, i.e.:

$ mail
read 1
read 2
exit
$ more-dcl-stuff


Be aware that DCL will not perform symbol substitution on data lines fed to
programs.  [I personally think this is most unfortunate, but I have no
input to VMS development...]

John Francini
PATHWORKS Server Engineering Group
Digital Equipment Corp.
Littleton, MA
Newsgroups: comp.os.vms
From: huber@h1cal2.desy.de
Subject: Re: command procedure calling
Organization: (DESY,Hamburg,Germany,H1 experiment)
Date: Wed, 27 Jan 1993 13:47:13 GMT

In article <ERMIMWEI.20@er.ele.tue.nl?>, ERMIMWEI@er.ele.tue.nl (Wim Beckers) writes:
> When a command procedure is called by another command procedure  their is 
> always a return to the calling command procedure.
> Is there a possibility to NOT return to the calling procedure?

Use HELP STOP EXAMPLES to learn what the DCL STOP command in DCL command file.
It returns to DCL from any nested comandfile.

Joseph "Sepp" Huber , huber@h1cal2.desy.de
Newsgroups: comp.os.vms
From: frank@tomcat.rd.ray.com (Frank Sandy)
Subject: Re: TALK command problem
Organization: Raytheon Co., Research Division, Lexington, MA
Date: Wed, 27 Jan 1993 00:34:22 GMT

In article <01GTWUKZCBNK000N1O@MSUS1.MSUS.EDU> TS117%BSU.DECNET@MSUS1.BITNET (Tandi Sunarto) writes:
>
>There is a facility in my school's computer system called TALK.
>It's a facility to call somebody anuwhere in the network system.
>I tried to call a friend of mine, but I got an error message :
>
>   $ TALK <username@address>
>
>   Can't open a connection to <address>
>   Domain service : no address found for host-name.
>
>This is strange to me, since I have no problem at all everytime
>I send a mail to him, which means I could reach him.

	It is possible to send mail between two systems even if both are not
on a common network such as the internet.   Mail frequently travels
through one or more store and forward mail gateways.  In order to use TALK both 
machines must physically be on the same network.  You can determine if
you are on the same network by trying to ping the other site.  If you
can't ping it, or telnet to it (at least as far as the login prompt)
you probably can't access it with TALK.

	From you return address, it looks like you are not on the internet
and are getting to it via a gateway from BITNET.  Your friend's site may
be on the internet or your mail may be going through a second gateway.
	
-- 
Frank Sandy,  Raytheon Research Div.,  131 Spring Street,  Lexington, MA 02173
frank@tomcat.rd.ray.com                                  phone: (617) 860-3049
Newsgroups: comp.os.vms
Subject: Re: Help with SYS$GETSYI please!
From: s01964@seb.se
Date: 27 Jan 93 13:27:41 +0100
Organization: S-E-Banken, Sweden
Nntp-Posting-User: s01964

In article <davids.728101271@marloo.kowari.cpsg.com.au>, davids@kowari.cpsg.com.au (David Schulz) writes:
> Hello,
> 
> I am trying to use SYS$GETSYI to retrieve the local node name.  The call is
> returning successfully, but the buffer is empty and return length is 
> zero.  Any help will be greatly appreciated.  The code fragment below
> shows what I'm trying to do.
> 
> Thanks in advance,
> 
> David
> 
> 
> -----------------------------------------------------------------------------
> 
> #include 	<syidef.h>
> 
> int
> main()
> {
> 	int		status;
> 	short	version_len, node_len;
> 	char	version[8];
> 	char	node_name[15];
> 
> 	struct item_list {
> 		short		length;
> 		short		code;
> 		int			buf_addr;
> 		int			return_length;
> 	} itmlst[] =
> 	{
> 		{	8,	SYI$_VERSION,		&version,		&version_len	},
> 		{	15,	SYI$_NODENAME,		&node_name,		&node_len	},
> 		{	0,	0,					0,				0	}
> 	};
> 
> 	status = SYS$GETSYIW(0, 0, 0, &itmlst, 0, 0, 0);
> 
> 	/* Returns version ok, but not node_name */
> 
> 	printf("version = <%8s>, length = %d\r\n", version, version_len);
> 	printf("node = <%15s>, length = %d\r\n", node_name, node_len);
> }
> 
> -----------------------------------------------------------------------------
> davids@kowari.cpsg.com.au
> -----------------------------------------------------------------------------
--
The item code SYI$_NODENAME is returning the sysgen parameter SCSNODE name.
Instead, translate the system logical name SYS$NODE. That logical name is
always defined on a node running DECnet.

On VAXcluster nodes is the sysgen parameter SCSNODE defined to be the same as
the DECnet node name, SYS$NODE. On standalon nodes should/must ?? the SCSNODE
name be defined if you run the new queue manager, in V5.5.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jonas Lindholm				Internet: jlh@seb.se
R-M3					Phone:	  +46 8 639 1000
S-106 40 Stockholm			Fax:	  +46 8 639 3762
SWEDEN
From: david@ittpub.nl (David P. Morgan)
Newsgroups: comp.os.vms
Subject: Re: Mailbox access
Date: 27 Jan 93 22:41:54 GMT
Organization: ITT Publitec R+D BV, Amsterdam

In article <20303.2b5bb282@ul.ie>, 9120092@ul.ie writes:
> Firstly thanks to all who replied to my previous posting, it was all very
> helpfull. Now just to put your minds to the test again as I'm having
> difficulty with mailboxes. My lecturer in Computer Organisiation wasn't
> able to give any solutions to the problem of writting to a mailbox
> created by another user. So far I can create mailboxes and pass data
> to a subprocess of my account but can not do the same to a mailbox in
> another account. This is primerily caused by VMS which takes a mailboxes
> name and places the pointer to that device in the PCB. So when a mailbox
> is created instead of being "My-Mailbox" and being open for group
> access it is infact "My-PID.My-Mailbox" which tends to throw a spanner
> in the works for me as I can not get around that protection.
> I think IO$Write_Attention gets involved some where but I'm not sure.
> Am I right about the mailbox protection. any suggestions on getting
> around it?

Forget this stuff about PCB's and IO$whatever. Read the help on $CREMBX.

Mailboxes can be identified by their device names or the optional logical
names created by $CREMBX. You can use $GETDVI to get the device name and
pass it to your other process OR you can have the other process pick up
the logical name of the mailbox from the job table by using:
$ def/tabl=lnm$process_directory lnm$temporary_mailbox lnm$job
before you create the mailbox. 
Or when you create a permanent mailbox the name goes into the system table.

> 
>           Thanks
> 
>              Peter.
> 
> Peter O'Brien, E-Mail  9120092@ul.ie
> 
>         The expressions expressed here are my expressions and 
>              nothing but my expressions, so help my God!
don't they say 'so help me God'

--------------------------------------------------------------------------------
David P. Morgan                        Internet: david@ittpub.nl        |ucannot
ITT Publitec R+D BV                    UUCP:     ...!sun4nl!ittpub!david|readdis
Amsterdam                              PSI:      020412905761212::DAVID |onavt52
From: steve@dbaccess.com (Steve Suttles)
Newsgroups: comp.os.vms
Subject: Re: command procedure calling
Date: 27 Jan 93 21:41:42 GMT
Organization: Cross Access Corp., Santa Clara, CA
X-Newsreader: Tin 1.1 PL4

carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
: In article <ERMIMWEI.20@er.ele.tue.nl?>, ERMIMWEI@er.ele.tue.nl (Wim Beckers) writes:
: >When a command procedure is called by another command procedure  their is 
: >always a return to the calling command procedure.
: >Is there a possibility to NOT return to the calling procedure?
: 
: Well, you *COULD* execute the command:
: 	$ MCR DCL
: (don't do this;  it deletes your process, but it does *NOT* return to the
: calling procedure :-).

Eh?

: 
: There's no documented way to exit from the entire stack of DCL procedures in a
: single command.  The best way to deal with this is, after every invocation of a
: command procedure, have conditional code in the calling procedure.  For
: example:
: 	$!	LEVEL1.COM
: 	$ 	@LEVEL2
: 	$	IF ($STATUS .AND. 7) .NE. 1 THEN-
: 			EXIT 'F$INTEGER(%X10000000 .OR. $STATUS)'
: 	$ 	{additional commands}
: and have the called procedure return a meaningful status when it exits.

You could also $EXIT %X10000004 (a fatal status but don't print it)
and unless the calling procedure did a SET NOON, he'll quit too.

You could delete the calling command procedure's file (I've never done
this intentionally, but I can tell you from experience, that command
file will not continue to execute).

You could log out.

You could execute the STOP command (quits all command procedures.  The
job too, if you're in batch...but then, that makes sense).

You could have the procedures "talk" to each other, with logicals or
symbols or exit status values or the existence of a file or...

You could reboot...this is usually a good way to stop a command file
from executing...

You could pull the plug.  Tell them you need access to the
documentation.  Cite identical failures at campuses nationwide.  Tell
them it's not quite a virus...it's sorta like leprosy.  The library
needs first aid!

Admittedly, some of these solutions are extreme.  But then again, some
problems are extreme.  You didn't exactly say why you wanted to stop
everything... (implied smile for Stan's sake)

sas
-- 
Steve Suttles                Internet:  steve@dbaccess.com      Dr. DCL is IN!
CROSS ACCESS Corporation     UUCP: {uunet,sgiblab}!troi!steve  Yo speako TECO!
2900 Gordon Ave, Suite 100   fax: (408) 735-0328              Talk data to me!
Santa Clara, CA 95051-0718   vox: (408) 735-7545   HA! It's under 4 lines NOW!
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: command procedure calling
Date: 28 Jan 1993 01:48:29 GMT
Organization: HST Wide Field/Planetary Camera
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

>: Well, you *COULD* execute the command:
>: 	$ MCR DCL
>: (don't do this;  it deletes your process, but it does *NOT* return to the
>: calling procedure :-).
>
>Eh?

Well, it accomplishes the stated goal of not returning to the DCL procedure
that called the procedure that issues the MCR DCL command.  Of course, it does
so by deleting the entire process.

>You could execute the STOP command (quits all command procedures.  The
>job too, if you're in batch...but then, that makes sense).

Yup.  I missed that one.  The "HINTS Command_procedures" section of the on-line
help mentions the EXIT command, but not the STOP command.  It would be nice if
DEC would add a "Related_topics" item to some of their HELP entries.  The only
aspect in which I think UNIX's man pages are better than VMS's HELP utility is
in that they've frequently got a "See also: " section at the end.
--------------------------------------------------------------------------------
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.
Xref: sparky comp.os.vms:22242 vmsnet.sources.d:799