HDTenEightyP/NetNews huggingface dataset:
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: The problem with $CREMBX System_Service
Date: 19 Nov 1992 03:00:09 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 <1992Nov18.171216.26136@nntpd2.cxo.dec.com>, winalski@adserv.enet.dec.com (Paul S. Winalski) writes:
=
=The DCL command interpreter uses RMS to read its input file.  RMS is a record-
=oriented I/O system.  When the input device is a terminal, the sequence of
=characters up to a carriage return (or other similar line-terminating control
=character) is considered a single record.  When the input device is a mailbox,
=RMS considers each message in the mailbox to be a separate record.  You are
=reading characters one at a time from the terminal and then writing them one
=at a time using $QIO to the mailbox.  Each character thus ends up as a separate
=message, and is seen as a separate record by DCL.

The fault is not in RMS.  MAILBOXES ARE RECORD-ORIENTED DEVICES.  You can't
read a single character from a mailbox (well, you CAN, by using $QIO[W], but
the only character you can read singly is the first character of a record, and
then you lose the rest of the record).

=The solution is to buffer characters inside your program until you read a
=CR from the terminal, then write the buffered string (not including the CR) to
=the mailbox using one $QIO.

Or have the application that's reading the mailbox buffer what it reads until
it sees a CR in the data its reading from the mailbox.  Both techniques are
equally effective, and I'd choose the one for which obtaining and modifying the
source code is easier.
--------------------------------------------------------------------------------
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
From: zapantis@uvphys.phys.uvic.ca (Nik Zapantis)
Subject: Re: Plans for mixed Alpha/VAX cluster with common system disk?
Reply-To: zapantis@uvphys.phys.UVic.CA
Organization: University of Victoria, Physics & Astronomy
Date: Mon, 16 Nov 92 18:02:34 GMT


-In article <1992Nov12.224853.23999@engage.pko.dec.com>, parris@star.enet.dec.com (Keith B. Parris) writes:

|>
|>We don't presently plan to support a common system disk shared between VAX and
|>Alpha systems.  Cluster-common files (SYSUAF, RIGHTSLIST, etc.) can be shared. 
|>

Will the Alpha support/mount a VAX/VMS system disk? In other words, will I be
able to have both an Alpha VMS disk and a VAX/VMS disk mounted on an Alpha 
system, and boot Alphas from the Alpha disk and VAXens from the VAX disk?

_________---_---_-_-_-_-_____-_----____---__-__-_-_-----_-_--_--___-_-__---__-_
|>Keith B. Parris, Digital Equipment Corporation, Alpha VMS Clusters & I/O Group
|>----_-____-_--_-__-_---_-___-_-_-_--__-_-__---__-_---_-___-_-_-_-_____--_--___-_
|>Anything blatantly opinionated or which is later found to be inaccurate was
|>mine, of course.  Digital gets the credit for any actual facts which appear.
|>-_-_--__-_-__----___---__-__-_-_-_-_____-__--_____---_-___-_-_-_--__-_--_--___-_
|>


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| Nik Zapantis                  | zapantis@uvphys     (BITNET)  |
| Dept. of Physics & Astronomy  | 45393::zapantis(HEPnet/SPAN)  |
| University of Victoria        | zapantis@uvphys.phys.UVic.CA  |
| Victoria, BC                  | Phone: (604)721-7729          |
| V8W 3P6                       | FAX:   (604)721-7715          |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: DYERFDF@hsdwl.utc.com ("Frank  Dyer x9568 ..Electrical Design", Chip)
Newsgroups: comp.os.vms
Subject: Lexical = SHO QUOTA/DISK/USER ?
Date: 16 Nov 92 12:08:23 GMT
Distribution: world
Organization: The Internet


 Is there a lexical I can use to return the same information as

     $ SHO QUOTA /DISK=diskx /USER=usery

 I want to reformat the output of the above to show a summary of quotas of
 a few project areas we have.

 Thanx, Frank

  *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
  * Frank Dyer                        INTERNET:  DYERFDF@HSDWL.UTC.COM  *
  * Hamilton Standard (UTC Division)  (203) 683-9568  FAX: 683-9500     *
  * Senior Design Engineer                                              *
  * Windsor Locks, CT  USA             Nuthin' Witty to write here Yet! *
  *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
From: ltran@NETCOM.COM (Linh C Tran)
Newsgroups: comp.os.vms
Subject: Want to buy a used DELNI in Northern California
Date: 16 Nov 92 17:52:29 GMT
Distribution: world
Organization: The Internet



Help,

I am interested in buying a used DELNI.  Do you have one to sell or you
know of any reseller that carry them ?

Thanx in advance....


LInh Tran	ltran@netcom.com   (408) 943-9700
From: OSUDAR@cmt.anl.gov (John Osudar {708 252-7505})
Newsgroups: comp.os.vms
Subject: RE: ?Why does this backup go so slow?
Date: 18 Nov 92 17:27:29 GMT
Distribution: world
Organization: The Internet

The idea of BACKUP doing disk I/O one allocation cluster at a time is really
hilarious!  Are there still people out there who are under the impression that
disk I/O's must be done in units of the allocation cluster size?

Since nobody else has asked...
Are you running the "new" BACKUP (which began with VMS V5.2)?
If you are, check the quotas on the account you're using to run BACKUP.  Look
at DEC's recommendations and guidelines.  Setting the quotas properly is vital
to BACKUP's performance improvements.
How are the disks connected to their host(s)?  Are they on two different
cluster nodes on an Ethernet, on different controllers connected to one node,
or both on the same controller?
Was the source drive badly fragmented?  Fragmentation really killed performance
in the old BACKUP, and can do the same to the new BACKUP if quotas aren't set
right.  Even with decent quotas, bad fragmentation will affect performance.
Was the BACKUP process running when the system was very busy?
Which qualifiers did you use?  For example, did you use /RECORD and are you
including that time in the 4.5 hours?  Did you do a /LOG?

					John
					osudar@cmt.anl.gov
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Failures in system security.
Date: 16 Nov 92 17:30:59 GMT
Reply-To: carl@SOL1.GPS.CALTECH.EDU
Organization: HST Wide Field/Planetary Camera
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <1992Nov16.154413.13758@ncsa.uiuc.edu>, jsue@ncsa.uiuc.edu (Jeffrey L. Sue) writes:
>>While that's not 100% secure, it's a lot more secure than VMS mail has been in
>>the past.
>
>Tell you what.  You give me a PC on your network with Ethernet & DECnet,
>and we'll just see who your VAX thinks I am.  Remember, *I* am the system
>manager for my PC/MAC/VAXstation.  Thus I can look like anyone I want.
>And if I know that your system is down, or if I can interrupt the network
>connection between systems (place myself in the middle), I can even do
>it without anyone knowing.

As I said, it takes someone with PHY_IO or equivalent. Having your own
transceiver on the network certainly counts as equivalent to PHY_IO.  As to
what happens when you start issuing packets that are alleged to come from a
machine other than your own, it that machine is actually up, running, and on
the DECnet, both I and the manager of the machine you're impersonating are
going to see odd things happening to DECnet.  In those circumstances, you're
not going to be able to impersonate another node without leaving tracks.

>Also, I don't think it takes PHY_IO privilege to open a network object.
>If you know what VMS Mail expects as input from the network connection I
>believe it's very easy in DCL to fake it out.

It takes PHY_IO priv to spoof the NCB.  When you construct your own NCB, that
doesn't affect what the remote process sees as the NCB (well, since you can
include some user data in the NCB, that part can be affected).  DECnet
constructs the NCB that the remote process sees.  If you want the remote
process to see a phony NCB, you've got to build and dispatch your own packets.
This requires PHY_IO.

Also, as I pointed out at the beginning of my article (didn't you actually read
it?), starting with VMS v5.5-2, DEC allows the system manager the option of
setting things up so that making an outgoing connection to the MAIL object
requires SYSPRV.  Other network objects can still be opened with just NETMBX, I
think, but DEC finally made it (as I said in my article, to which you've
apparently replied without reading it) somewhat harder to counterfeit mail over
DECnet.
--------------------------------------------------------------------------------
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: murphy@npri6.npri.com (David P. Murphy)
Newsgroups: comp.os.vms
Subject: problem with DECC under ALPHA/VMS
Date: 19 Nov 92 01:34:42 GMT
Distribution: world
Organization: NPRI, Alexandria VA

The C compiler for ALPHA AXP, called DECC, does not provide the linker
with the correct information for cross-referencing purposes:  if a function
is only called by other functions within the same module as the callee,
then the linker reports _no_ modules reference that function.  ugh.
DSN acknowledges that this is not my imagination, but they are still
trying to decide if this is a "bug" or a "feature".

i'm not making any of this up, you know.

ok
dpm
-- 
murphy@npri6.npri.com 602 Cameron St. Alexandria, VA 22314 (703) 683-9090

              When every one is dead the Great Game is finished.  Not before.
                              --- Hurree Babu, "Kim"
From: FZC@CU.NIH.GOV ("Paul Robinson")
Newsgroups: comp.os.vms
Subject: "The Man From Mars"
Date: 16 Nov 92 03:23:37 GMT
Reply-To: 0005066432@mcimail.com
Distribution: world
Organization: The Internet

Before you think that in my item to Info-Vax, in which I said
'The Man From Mars, "Michael Smith"' I wanted you to know
(in case you don't) what it meant.  There was a famous book
released in the 1960s called "Stranger in a Strange Land"
where the main character is a human being brought back from
Mars, and his name was V. Michael Smith, or "Mike Smith,
The Man From Mars."  It's just sort of a reference I've
used to anyone named "Mike Smith."  It's not meant to be
offensive at all, nor does it mean that your comments are
somewhere out of this world.


Xref: sparky comp.os.vms:18294 vmsnet.sources.d:696
From: rankin@eql.caltech.edu (Pat Rankin)
Newsgroups: comp.os.vms,vmsnet.sources.d
Subject: Re: GAWK v2.14 available from FILESERV@WKUVX1.BITNET
Date: 20 Nov 1992 22:48 PST
Organization: California Institute of Technology
Distribution: world
Reply-To: gawk.rankin@eql.caltech.edu
NNTP-Posting-Host: eql10.caltech.edu
News-Software: VAX/VMS VNEWS 1.41    

In newsgroup vmsnet.sources.d, article <1992Nov20.215838.4130@wkuvx1.bitnet>,\
 goathunter@wkuvx1.bitnet writes...
[...]
> To get GAWK v2.14 via e-mail, send the following commands (without the
> comments) in the body of a mail message to FILESERV@WKUVX1.BITNET:
> SEND GAWK-2-14			!37 60-block files
> SEND FILESERV_TOOLS

     I plan to post it to vmsnet.sources so that the current version
can replace the really old one which is in the archives for that group.
This version has been successfully built and tested under VMS POSIX
and Alpha/VMS as well as "normal" VAX/VMS.

		Pat Rankin, rankin@eql.caltech.edu
From: goathunter@wkuvx1.bitnet
Newsgroups: comp.os.vms
Subject: Re: Q: .tar.Z files that won't unpack under VMS
Date: 23 Nov 92 16:23:13 CDT
Distribution: world
Organization: Western Kentucky University, Bowling Green, KY

In article <23NOV199211193139@seqvax.caltech.edu>, mathog@seqvax.caltech.edu (David Mathog) writes:
> I frequently run into .tar.Z files that were put together on Sparcs that will
> not unpack and untar correctly under VMS.  They go through lzdcmp without
> posting any error mesages, but then blow up in tar.  Either I'm throwing the
> wrong switches or there is some bug/incompatibility in my copy of lzdcmp or
> tar. 
> 
It should work if you use GNU compress and not LZDCMP.  You can get
GNU compress for VMS via e-mail by sending the following command in
the body of a mail message to FILESERV@WKUVX1.BITNET:

SEND COMPRESS

You can also get it via anonymous ftp from ftp.spc.edu; you'll need:

	[.MACRO32]LZDCMP.EXE
	[.MACRO32.SAVESETS]COMPRESS.BCK_Z

Hunter
------
Hunter Goatley, VMS Systems Programmer, Western Kentucky University
goathunter@WKUVX1.BITNET, 502-745-5251
Newsgroups: comp.os.vms
From: anos@elmrd6.ineab.ikea.se
Newsgroups: comp.os.vms
Subject: Re: Fixing SYSTEM-W-HEADERFULL error
Date: 21 Nov 92 12:05:22 +0200
Organization: IKEA Northern Europe AB

In article <2369.2b04e86c@decus.ch>, mandach@decus.ch writes:
> In article <BxoMzw.Jx9@irvine.com>, adam@irvine.com (Adam Beneschan) writes:
>> Please help us!!  We're getting this error message and we're not sure
>> what to do.  Please email replies to abeneschan@irvine.com.  
>> 
>> Our situation:  We have a Vaxstation 4000 model 60, VMS version V5.5,
>> 1 gigabyte SCSI drive.  There are 49112 files on our system, and our
>> INDEXF.SYS file is 49190 blocks.  (Each header in INDEXF.SYS is 1
>> block, so it's not surprising that these figures are close.)  If we
>> say SHOW DEVICE/FULL, it says the maximum number of files is about
>> 257000.  
> 
> Adam,
> 
> your porblem may have to do with some initialization constraints (VMS
> calculates these paramters based upon "used-to-be-values" With those
> GIGA-byte drives that emerged in the recent time some default values
> have not been adapted yet.
> 
> Our way to overcome this problem was to backup the ENTIRE disk onto
> another one which we initialized with a larger value for the para-
> meter /MAXIMUM_FILES (see the Help-text from VMS: $ HELP INIT dev/MAX)
> You could also use a tape and restore the entire disk with BACKUP but
> I'd suggest to use the switch /NOINITIALIZE and previous to restoring
> initialize the disk in  question with a alrger value of MAX.._FILES.
> 
> Hope this helps !
> 
> Regards,
> Hans
> 
> 

I would say that the problem is that your INDEXF.SYS is too fragmented and
can't be extended. I have had the same problem recently on a Vax 4000/100 in
Belgium, and the way to fix it was to do an image backup, initialize the
volume with /HEADER=n (4096 in my case) and the do the restore with the
/NOINIT qualifier. Again, the problem is that VMS *assumes* that you will
not have more that 16 files on your volume (do a DUMP/HEADER to check) and
therefore allocated 16 blocks when the volume is initialized. After this,
normal file extension is performed when needed, meaning a badly fragemented
indexfile after a short period of time.
 
+------------------------+--------------------------------------------------+
| And my name is ...     | Anders Ostling				    |
| employed by ...        | IKEA Northern Europe AB (INEAB)                  |
| located in ...         | Helsingborg, Sweden                              |
| Return mail address to | ANOS@ELMRD6.INEAB.IKEA.SE			    |
| Phone                  | +46 42 15 29 06                                  |
+------------------------+--------------------------------------------------+
Newsgroups: comp.os.vms
From: olin@vger.cheme.cornell.edu (Steve Thompson)
Subject: changing ALLOCLASS
Reply-To: olin@vger.cheme.cornell.edu
Organization: Chemical Engineering, Cornell University, NY
Date: Mon, 23 Nov 1992 23:35:15 GMT

I have a node in my cluster called DANTE which has up to today had
a non-zero allocation class (ALLOCLASS=3). This node has a single
RA81 disk attached (DUA0). All other cluster nodes have mounted
this disk as $3$DUA0. Today I shut down this system and rebooted
with ALLOCLASS set to zero. I then expected the disk to show up
as DANTE$DUA0 on the other nodes; however, it is still $3$DUA0.
Removing the node from the cluster appears not to have altered the
other nodes' knowledge of what DANTE's ALLOCLASS used to be. I
hesitate to mount the disk on the other nodes, lest something is
up and they scribble all over the disk. Is it supposed to work like
this? If so, I will have to reboot everything. Thanks,

Steve

---------------------------------------------------------------------------
Steve Thompson, System Mangler   Internet: thompson@cheme.tn.cornell.edu
School of Chemical Engineering   Bitnet:   thompson@crnlchme
Olin Hall, Cornell University    Phone:    (607) 255 5573
Ithaca NY 14853
---------------------------------------------------------------------------
From: tillman@swdev.si.com ("Brian Tillman, Smiths Industries, VAX Support, x8425")
Newsgroups: comp.os.vms
Subject: RE: RMS-F-ISI
Date: 16 Nov 92 17:23:07 GMT
Distribution: world
Organization: The Internet

Ken Connelly (connelly@uni.edu) writes:

>For the last two times this has been executed, I have gotten part way
>through the CONVERT, then received this error:
>
>%CONV-F-WRITEERR, error writing NEWS2DISK:[ANU]NEWS.ITEMS;336
>-RMS-F-ISI, invalid internal stream identifier (ISI) value

This is a known problem with CONVERT and has been in CONVERT for VMS V4.n and 
all of 5.n so far, according to DSNlink.  The work around is this (and I quote 
DEC):

WORKAROUND:

Specify the output file with a name that other processes will
never try to open.  Then RENAME it to the original filename
after the CONVERT completes.  The following commands can be
used to accomplish this:

     $ CONVERT file.dat  'F$GETJPI("","PID")'.dat
     $ RENAME 'F$GETJPI("","PID")'.dat  file.dat


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

Newsgroups: comp.os.vms
From: hamjavar@hydra.unm.edu (Farid Hamjavar)
Subject: DCL question.
Date: Thu, 19 Nov 92 01:36:09 GMT
Organization: University of New Mexico, Albuquerque




Hello :

As you can tell the following simple DCL script prints its first two
parameters/arguments :

$ DISPLAY= "WRITE SYS$OUTPUT"
$ DISPLAY  "''p1'"
$ DISPLAY  "''p2'"


Now if any of the parameters starts with   /    this script will crash :

$ @t.com /parameter1  /parameter2
%DCL-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement




   Is there any clean way to go around this?  That is, to be able to 
   print them (or use them in same script) as they are?

   The reason is that later on, those parameters will be fed to another
   application within the same script. 


Thank you.
Farid Hamjavar
You can reply publicly or e-mail me : hamjavar@carina.unm.edu







Newsgroups: comp.os.vms
From: hamjavar@fornax.unm.edu (Farid Hamjavar)
Subject: Thank you.
Date: Fri, 20 Nov 92 06:54:40 GMT
Organization: University of New Mexico, Albuquerque



Many thanks to following people who replied to my
DCL question of 'qualifier passing' to script.

carl@sol1.gps.caltech.edu
marshall@force.ssd.lmsc.lockheed.com  
reed%vax1@cbemf.att.com  
00mjstum@leo.bsuvc.bsu.edu
MULLEN@hornet.ag.uiuc.edu 
kega@nobeltech.se 
SPG@nereid.sunquest.com 
mandach@decus.ch
rsimms@hubcap.clemson.edu 


Farid Hamjavar
University of New Mexico -- CIRT
From: JHILT%DRCV06.decnet@DRCVAX.AF.MIL ("DRCV06::JHILT")
Newsgroups: comp.os.vms
Subject: Is a heterogeneous system possible under 5-5?
Date: 17 Nov 92 13:43:00 GMT
Organization: The Internet

We have just upgraded from VMS V5.4-2 to V5.5-2 and have been unable to
find a way to use two distinct UAF files within a cluster as we did under 5.4.
As things now are we are going to have to change about 120 usernames to make
them unique.  Having distinct UAF's gave us the ability to allow users to sign
onto different (but clustered) systems with the same username.
In addition there is exactly one queue manager now so depending which system
reboots first is the system which gets the queue manager and the remaining
systems cannot run batch jobs using the /USER qualifier.
Is there another solution to this problem?

Jim Hilt              | | jhilt@drcvax.af.mil  |
Systems Analyst       | | (508) 475-9090x2449  |
Dynamics Research Corp. 60 Frontage Road Andover, MA 01810
From: tihor@acf3.NYU.EDU (Stephen Tihor)
Newsgroups: comp.os.vms
Subject: Re: 2 node LAVC "problem"!
Date: 23 Nov 92 16:34:00 GMT
Organization: New York University

The traditional dirty trick in this case =--=which works nly because
the two systems share NO HARDWARE is to create a quorum disk on each
opne with different names and 1 vote.   When both systems are up the quorum
disk name difference invalidates the Qdisk and quorum is the 2 CPU votes.
When you lose connect (the axe murder takes out the ethernet either or both systems
can manage to survive, they only see tyhe CPU and 1 qdisk so thats 2 votes
and presto.   Note that there is still the issue of where you
put common queues, etc so that they survive.  Absetent a multiheaded SCSI control
you are still looking at one node losing functionality or needing to 
run a separate deamon to fail out some functions.