HDTenEightyP/NetNews huggingface dataset:
From: mats@efd.lth.se (Mats Akerberg)
Newsgroups: comp.os.vms
Subject: Re: Butthead
Date: 22 Dec 92 16:21:29 GMT
	<1992Dec22.153345.21177@zip.eecs.umich.edu>
Organization: EFD, Lund Inst. of Technology, Lund, Sweden
Originator: mats@efd.lth.se

In article <1992Dec22.153345.21177@zip.eecs.umich.edu> pampreen@emunix.emich.edu (Dave Pampreen) writes:
>   I have read a few of your last responses and you sound like your
>   are just a pompus buthead who thinks he knows everything.  I have
>   been kind of busy with a real LIFE and I can't always sit down and 
>   keep up on my comp.os.vms.  I usually end up missin a few (1000) or
>   so articles so get off my case and everybody elses.  People usually 
>   post here because the can't get the answer anywhere else.  

I think people post here becuse

 1) They can't read TFM!

 2) They are stupid!

Then perhaps there are a few out there that really need help
and they always get it witout flame!

 

--
  Mats Akerberg, System Manager (mats@efd.lth.se),(MATS@SELDC52) on Earn/Bitnet
  Lund Institute of Technology ,School of Electrical Engineering and  
  Computer Sciences. Snail: Box 118  S-221 00 Lund Sweden
  Phone: + 46 46-109847 FAX: + 46 46-104013 
-- 
  Mats Akerberg, System Manager (mats@efd.lth.se),(MATS@SELDC52) on Earn/Bitnet
  Lund Institute of Technology ,School of Electrical Engineering and  
  Computer Sciences. Snail: Box 118  S-221 00 Lund Sweden
  Phone: + 46 46-109847 FAX: + 46 46-104013 
Newsgroups: comp.os.vms
From: miller@tgv.com (Vagrant)
Subject: Re: More than 1 line of command history buffer
Reply-To: miller@tgv.com
Organization: TGV Incorporated in Santa Cruz, CA
Date: Wed, 30 Dec 1992 18:25:02 GMT


In article <PRZEMEK.92Dec29235033@rrdstrad.nist.gov>, przemek@rrdstrad.nist.gov (Przemek Klosowski) writes:

#I like to have the command line editing provided courtesy of VMS
#system read procedure, and the fact that I can retrieve the previously
#used command line using the up-arrow key; however, I am spoiled by the
#DCL 20-line command history (and the readline library I am using on
#Unix that remembers commands across login sessions).  Is there a
#simple way to increase the command history list size, so that more
#than one last command is remembered?

I usually use SMG in order to get a bigger command history.  I don't
believe you can expand the buffer that VAXCRTL uses.  Here's some
example code in C below.  See the SMG manual for more info.

-bruce



#module TERM "V1.0"
#pragma builtins

#include ssdef
#include descrip
#include rmsdef
#include smgmsg

    u_word	TT_Channel;

    /* Special events concerning the terminal. */
    u_word	TT_MBX_Chan;
    u_byte	TT_MBX_Buffer[256];
    u_long	TT_MBX_IOSB[2];

    static int	Pasteboard_Id;
    static int	Display_Id;
    static int	KeyBoard_Id;
    static int	Key_Table_Id;
    static int  preserve_screen = 1; /* Don't clear screen on startup. */


/*
 Description:
	Initialize the terminal related stuff (yeah, that's right. stuff.)
*/

int IPNCP_SMG_Init()
{
    u_long RC;
    $DESCRIPTOR(Input_Device,"SYS$COMMAND");

    RC = LIB$ASN_WTH_MBX (
	&Input_Device,
	&sizeof(TT_MBX_Buffer),
	&sizeof(TT_MBX_Buffer),
	&TT_Channel,
	&TT_MBX_Chan);
    if (ERROR(RC)) LIB$SIGNAL(RC);

#ifdef NOTDEF
    RC = SMG$CREATE_PASTEBOARD (
	&Pasteboard_Id,		/* We use this to get info about the display.*/
	0,			/* Output device.  default is 'SYS$OUTPUT' */
	0,			/* height of the screen. */
	0,			/* width of the screen. */
	&preserve_screen	/* Should we clear the screen? */
	);
    if (ERROR(RC)) LIB$SIGNAL(RC);
#endif /* NOTDEF */

    RC = SMG$CREATE_VIRTUAL_KEYBOARD(&KeyBoard_Id);
    if (ERROR(RC)) LIB$SIGNAL(RC);

    RC = SMG$CREATE_KEY_TABLE(&Key_Table_Id);
    if (ERROR(RC)) LIB$SIGNAL(RC);

    return(SS$_NORMAL);
}

/*
 Functional Description:

	This routine is used to get input for cli$dcl_parse.
	The format of the arguements must be the same as
	LIB$GET_INPUT.
*/

int IPNCP_Get_Input (Get_Str, Prompt_Str, Out_Len)
    struct dsc$descriptor_s *Get_Str, *Prompt_Str;
        int *Out_Len;
{
    u_long RC;

    RC = SMG$READ_COMPOSED_LINE (
		&KeyBoard_Id,
		&Key_Table_Id,
		Get_Str,
		Prompt_Str,
		Out_Len);
    if (RC == SMG$_EOF) return(RMS$_EOF);

    if (ERROR(RC)) LIB$SIGNAL(RC);

    return(RC);
}
From: powers@ELROS.STG.TRW.COM
Newsgroups: comp.os.vms
Subject: Gak groking (was Flames and Such)
Date: 3 Jan 93 06:56:49 GMT
Distribution: world
Organization: The Internet

A post on the subject of Flaming and Such asserts:

>	trap 's=$?; rm -f /tmp/gak.$$; exit $s' 0
>	grep \^Subject: * | tr '[A-Z]' '[a-z]' | \
>	sed -e 's/[0-9]*:subject:[      ]*//' -e 's/^re:[     ]*//' \
>		-e 's/^re:[     ]*//' | sort > /tmp/gak.$$
>	awk -f - /tmp/gak.$$ <<"Grok!This" | sort -n
>	BEGIN {f=1;c=0} {if (f) {f=0;c=1;l=$0} else {if ($0 == l) {c++;} else {
>	printf "%3d %s\n",c,l;c=1;l=$0}}} END {if (c) {printf "%3d %s\n",c,l;}}
>	Grok!This

Grok?  Grok!  With a gak too???  Groking a gak??????  In public?!?!?!?!?!?!?!?!

Ooooooooooo, when the net.decency guys hear about this.....  

       Lester
       powers@elros.stg.trw.com

PS:  There are modems with special filters on the market now that should take
care of those {{{ line noise symptoms.


Newsgroups: comp.os.vms
From: cctj001@utxvms.cc.utexas.edu
Subject: RE: TT_AccPorNam field for FTAnn: devices (was: something else)
Organization: University of Texas @ Austin
Date: 3 Jan 93 05:27:49 CST

> 
> ... Somewhat related to this, it shore would be 'cool' if DEC could include
> this same information for the FTAnn: devices for X terminals.  Ah, well, 
> maybe next version?
> 
> -Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11)
>  Systems Administrator, University Hospital, Denver
> 

Sorry, couldn't resist:

$ SHOW USERS/FULL CC

      VAX/VMS User Processes at  3-JAN-1993 15:16:02.41
    Total number of users = 5,  number of processes = 42

 Username  Node   Process Name      PID     Terminal
 CCDK001  INDIGO  CCDK001         21A00164  FTA5:    (LOCAL->INDIGO)
 CCDK001  INDIGO  DECW$MWM        21A00104  MBA120:  Disconnected
 CCDK001  INDIGO  David Barkelew  21A00102           
 CCDK001  INDIGO  _FTA6:          21A00127  FTA6:    (LOCAL->INDIGO)
 CCTJ001   BLACK  T.J.            41C000A9  FTA5:    
                                                   (TCPIP->bisque.cc.utexas.edu)
 CCTJ001    BLUE  T.J.            40400F34  FTA2:    
                                                   (TCPIP->bisque.cc.utexas.edu)
 CCTJ001    CYAN  T.J.            4D4000EB  FTA2:    
                                                   (TCPIP->bisque.cc.utexas.edu)
 CCTJ001   GREEN  T.J.            22200115  FTA1:    
                                                   (TCPIP->bisque.cc.utexas.edu)
 CCTJ001  ORANGE  CCTJ001         20200795           
 CCTJ001  ORANGE  DECW$MWM_0019   202007A3  (subprocess of 20200795)
 CCTJ001  ORANGE  T.J.            202007A5  FTA24:   
                                                   (TCPIP->BISQUE.CC.UTEXAS.EDU)
 CCTJ001  ORANGE  TJ_CALENDAR     202007A8  (subprocess of 20200795)
 CCTJ001  ORANGE  TJ_MAIL         202054BE  (subprocess of 20205C94)
 CCTJ001  ORANGE  TJ_VPA          20200B47  (subprocess of 202007A6)
 CCTJ001  ORANGE  VUE$CCTJ001_1   2020164C  MBA1949: Disconnected
 CCTJ001  ORANGE  _FTA25:         202007A6  FTA25:   
                                                   (TCPIP->BISQUE.CC.UTEXAS.EDU)
 CCTJ001  ORANGE  _FTA26:         202007A7  FTA26:   
                                                   (TCPIP->BISQUE.CC.UTEXAS.EDU)
 CCTJ001  ORANGE  _VTA2364:       20205C94  VTA2364: LTA6154: (TELESYS/90)
 CCTJ001  VIOLET  T.J.            60800136  FTA2:    
                                                   (TCPIP->bisque.cc.utexas.edu)
 CCTJ001  YELLOW  T.J.            60600158  FTA3:    
                                                   (TCPIP->bisque.cc.utexas.edu)

This is a local implementation, as far as I know, v6 does not have this feature.
(David, (when) are you going to put this out?)

--Thomas Linscomb
--Manager, VMS Service, Computation Center
--The University of Texas at Austin
From: 92ADAMS@HANNA2.NLU.EDU (Erek Adams)
Newsgroups: comp.os.vms
Subject: Possible FAQ about FAQ's.
Date: 28 Dec 92 09:32:14 GMT
Distribution: world
Organization: The Internet



  Quick and simple question for someone.  Where can I find the Info-Vax FAQs? 
To save bandwith, please reply by e-mail.   

  Thanks in advance!

+-------------------------------------+---------------------------------------+
|                                     |  Internet:  92adams@hanna2.nlu.edu    |
|  Erek Adams, Student Programmer     |  SnailMail: 5330 DeSiard, #43         |
|  Northeast Louisiana University     |             Monroe, LA  71202         |
|  Monroe, Louisiana  71202           |  Work Phone: (318)-323-7468           |
|                                     |  Home Phone: (318)-343-4729           |
+-------------------------------------+---------------------------------------+
--= Famous Last Words:  "Hmmmm...What does DELETE [*...]*.*;* really do?"   =--
From: mgrthh@rosevc.rose-hulman.edu (Thomas H. Hopson)
Newsgroups: comp.os.vms
Subject: Re: MAIL problem (NOT newmail count :)
Date: 30 Dec 1992 19:00:32 GMT
Organization: Rose-Hulman Institute of Technology
Distribution: world
Reply-To: mgrthh@rosevc.rose-hulman.edu
NNTP-Posting-Host: hydra.rose-hulman.edu


In article <1992Dec30.122948.13315@bsu-ucs>, 00mjstum@leo.bsuvc.bsu.edu (Matthew J. Stum) writes:

>Anyway, it's nothing tragic, but I've been wondering for a long time now
>why we end up with a lot of MAIL.LIS files in our [SYSLOST] directories.
>Here's my assumption based on what little detective work I've been
>motivated to do:  The MAIL.LIS files are temporary files used when PRINTing
>from MAIL... however, for some reason the MAIL.LIS file doesn't get deleted
>properly.  More like a SET FILE/REMOVE thing.
>
>The problem arises that we have quotas enabled on our user disks and it
>wreaks havoc with a user if (s)he prints a lot from MAIL.

The MAIL.LIS files are created when a user issues a PRINT command from 
within MAIL.  The MAIL utility creates a "temporary file" that it only knows
by file ID; the file is not stored in any directory.  It issues the equivalent
of a PRINT/DELETE (using, of course, the $SNDJBC system service) giving the
file ID of the file it created.

If the print job is deleted or for whatever reason doesn't complete, the file
doesn't get deleted.  Since it doesn't exist in a directory, it is really
difficult for people to even know that they own the file, much less delete it.

>Is this normal?  Or do we have something set up strangely?  Is there
>another way around it besides routinely cleaning the [SYSLOST] directories
>of MAIL.LIS files?

It is normal in the sense that it seems to happen a lot, especially if users
print a lot of mail, and especially if print jobs get deleted a lot.  There
really isn't a *nice* way of cleaning up the files, especially since you've
lost track of (never really knew) the file IDs of the files being created.

>Hmmm... now that I think of it, I don't use PRINT/DELETE a whole lot... is
>this something connected with the queueing system and not MAIL?  I don't
>see anything about PRINT in the docs that would nail it down one way or
>another.

It's not a fault of PRINT/DELETE nor of the queueing system.  It's really a
fault of MAIL for deciding to use a "temporary" file when the possibility
exists that the file may not be printed and deleted immediately.

--
Thomas H. Hopson                      work: mgrthh@rosevc.rose-hulman.edu
VMS Manager / CS geek                       mgrthh@rhit
Rose-Hulman Institute of Technology   play: hopsonth@cs.rose-hulman.edu
Terre Haute, Indiana
From: TS117%BSU.DECNET@MSUS1.BITNET (TANDI SUNARTO)
Newsgroups: comp.os.vms
Subject: Re: Apending a file at the end of mail.
Date: 21 Dec 92 06:47:00 GMT
Distribution: world
Organization: The Internet

Ehud,

Since I am a new user on VAX system, could you please elaborate your
explanation on how to append a file at the end of mail, for example :
tell me how to create an initiliazation file, and other stuff.

Thanks for any of your help.

Tandi
TS117@VAX1.BEMIDJI.MSUS.EDU

Newsgroups: comp.os.vms
From: rkoehler@author.gsfc.nasa.gov (Bob Koehler)
Subject: Re: How Open is Open VMS?
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: CSC System Sciences Division
Date: Thu, 31 Dec 1992 21:09:00 GMT

In article <1992Dec31.190236.29454@zooid.guild.org>, kovarski@zooid.guild.org (Mark Kovarski) writes...
> 
>Could someone tell me how "open" Open VMS really is. Is it so open that
>someone can obtain the source codes, or is it another proprietary operating
>system with the word "Open" attached to it? Thanks.
> 
>Mark K.
>E-Mail: kovarski@zooid.guild.org

Once upon a time VMS shipped with the source listings microfiche.  You could
get a machine-readable (edit-and-compilable) copy for a high price.  Then DEC
stopped that (they told me it made their lawers unhappy), so we had to justify
why we needed it, and pay a fee.  Now they're moving from fiche to CD rom
(Bookreader format, not ASCII flat files), but the price doesn't seem to have
gone up that much for the human-readable format.  Some of the source is
missing, most notably the DECwindows stuff.  I don't know if they still sell
a machine-readable copy, but if they do I expect its still quite expensive.

Of course you could use "open" UNIX, which as far as I know is still has source
available only as high-priced, machine readable format, unless you happen to
maybe be a university, or did they stop that?

------------------------------------------------------------------------------
Bob Koehler                     |   Any illusion to these opinions being other
rkoehler@author.gsfc.nasa.gov   |   than just mine alone is just that.

 " Life is life, and fun is fun, but it's all so quiet when the goldfish die. "
                         - Blixie
From: jsue@ncsa.uiuc.edu (Jeffrey L. Sue)
Subject: Re: HELP!!! Security problem for gurus.
Originator: jsue@mars.ncsa.uiuc.edu
Organization: The Dow Chemical Company
Date: Wed, 23 Dec 1992 19:46:07 GMT

In article <1h9e1nINN1c9@gap.caltech.edu> carl@SOL1.GPS.CALTECH.EDU writes:
>In article <1992Dec22.161918.9033@ncsa.uiuc.edu>, jsue@ncsa.uiuc.edu (Jeffrey L. Sue) writes:
>>Now that's a creative way to do it.  Just hope MAIL doesn't decide to use
>>that MAILbigfilename.MAI sometime - though it may check for this and handle
>>it correctly, I've no idea how to test this.  (besides I'm sure that the
>>possibility is quite small)
>
>Easy:  Just pick a date that's before NOW.  
Hmm....
MAIL$09A8BDA800050096.MAI doesn't like it has anything to do with a date.

>Not that hard to do if, unlike many
>recent querants, you're willing to take the time to figure out how VMS works!

Gee... some of us have *real* jobs, some of which doesn't even apply to VMS.
Actually, I know quite a bit of how VMS works, however little things like
how MAIL determines what "bignumber" to use is of little value to me.

>Of course, if you're one of the people trying to use shit for brains who 
>can't tell the difference between INFO-VAX and
>IM-TOO-LAZY-OR-STUPID-TO-MANAGE-MY-SYSTEM-SO-WILL-YOU-PLEASE-DO-IT-FOR-ME
>this strategy is meaningless.

I'm not doubting that the "bignumber" could be related to the date and time
that the file is created.  However this is not in HELP MAIL nor in MAIL> HELP.
And, seeing as how I don't need this feature, it's not worth the effort on
my part to look it up.

This information could be in the documentation somewhere, but then is it
worth the effort on my part to look it up?  However, if you're the helpful
type, you could supply this information and I'd be really happy to look
it up myself and learn something.  I'd be willing to bet that others are
willing to learn on their own as well.

Many of us do use VMS extensively, and we are also very technically versed
in the most useful aspects.  Things I don't need to use I rarely remember
years after reading it.  I may not be a MACRO or Internals guru, but what
I do know I *have* taken the time to RTFM and learn on my own in most cases.
I'd always much rather have someone point me to the documentation if they
are familiar with where to look than to spend much of my time trying to
figure out where DEC decided to document this "feature".  DEC documentation
does have a tendency to put some information in hard-to-find places.

(BTW, I just spend 5-10 minutes looking thru the MAIL Utility manual in
bookreader... if this info is there, it sure isn't obvious where.)


-- 
-----
Jeff Sue   
 - All opinions are mine -       (and you can't have any, nya nya nya)
Newsgroups: comp.os.vms
From: fairfield@slacvx.slac.stanford.edu
Subject: Re: long, long, really long DCL commands
Organization: Stanford Linear Accelerator Center
Date: Mon, 28 Dec 1992 20:59:31 GMT

In article <1992Dec28.172453.24421@ramsey.cs.laurentian.ca>, george@ramsey.cs.laurentian.ca (George Nassas) writes:
[...]
> The manual tells me that DCL will gladly accept commands of 1024
> characters although each individual line cannot go longer than 256
> characters. Can anyone fill me in on how this works? I read all over
> the FM for an example but couldn't find one.
> 
> At first I thought that I could get really long lines by going:
> 
> 		$ 256 chars -
> 		  256 chars - etc...
> 
> but no way. What gives? I've stumped all my local experts.

    DCL will accept ONLY 256 characters maximum on the command line,
whether that line is continued on multiple, shorter lines in the input
stream (terminal screen, command file) or not.

    The 1024 character limit has to do with the resulting command string
after DCL has _expanded_ the command line, i.e., replaced symbols with their 
"translations", evaluated lexical functions, etc.  For example, if you had a 
symbol

	$ DF == "DIRECTORY/FULL"

and typed "DF", the DCL command line would be 2 characters (counted against
the 256 character limit), while the expanded command would be 14 characters 
long (counted against the 1024 character limit).

    I'm sure others can give a more precise exposition (Don Stokes, are you
listening?), but this is the general idea...

	-Ken
-- 
 Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slac.Stanford.Edu
 SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
 Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
 ----------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
From: blacka@logica.co.uk
Newsgroups: comp.os.vms
Subject: Support for languages other than English
Date: 22 Dec 92 18:17:18 GMT

To what extent does VMS handle languages other than English.
If you are logged on to a VAX in (say) France which messages
come out in English and which in French.  For example, does 
  $ DIR NON-EXISTANT-FILE 
produce 
  %DIRECT-W-NOFILES, no files found
in English or French

To what degree do other DEC products handle multilingual
operation.



Andrew Black  Logica Finance
Newsgroups: comp.os.vms
From: chen@speed.uucp (Lilei Chen)
Subject: Mount verification timed out 
Organization: Aiken Computation Lab, Harvard University
Date: Tue, 29 Dec 1992 15:23:02 GMT

In our VAX/VMS-cluster a bunch of disks are cross mounted.  Somtimes when
a node goes down, its disks are marked mount verification timed out.  I
haven't found a way to get those disks remounted without rebooting the
nodes.  I am wondering if someone on the net has a solution for that problem.
Thanks.

Jim  (xue@cfaft5.harvard.edu)
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Apending a file at the end of mail.
Date: 23 Dec 1992 13:30:11 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 <1992Dec23.063743.3368@organpipe.uug.arizona.edu>, vance@lpl.arizona.edu (Vance Haemmerle x4021) writes:
>  Anyway, here's someone's question I couldn't answer after spending
>  lots of time with the DOC CD-ROM.  Is there a system service or
>  Run-Time Library routine that returns the amount of blocks allocated
>  to a file?  Something like stat() in C, but the allocated space, not
>  the used space.  I hope the answer doesn't involve reading the
>  directory file format manulally or seting up RMS control structures.

Ah, Vance.  Are you trying to involve yourself in my and Ehud's rather amiable
flamewar?  Of did you really not know about the F$FILE lexical, with the "ALQ"
item (and the equivalent field in the FAB block).

From DCL you can:
	$ WRITE SYS$OUTPUT F$FILE(file_name, "ALQ")

In a C program, you can (for LOGIN.COM in this case, but I'm sure you can
figure out how to extend things):
#
include rms

main()
{	struct FAB my_fab;

	my_fab = cc$rms_fab;
	my_fab.fab$l_fna = "LOGIN.COM";
	my_fab.fab$b_fns = strlen(my_fab.fab$l_fna);
	SYS$OPEN(&my_fab);
	SYS$CLOSE(&my_fab);
	printf("%d\n", my_fab.fab$l_alq);
}

--------------------------------------------------------------------------------
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