HDTenEightyP/NetNews huggingface dataset:
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: comp.os.vms
Subject: Re: Dual monitor on VS3100: HELP!
Date: 8 Oct 92 17:57:53 GMT
Organization: St. Peter's College, US

In article <1992Oct7.185842.21784@engage.pko.dec.com>, jackson@pravda.enet.dec.com writes:
> 
> In article <1992Oct3.132146.4019@spcvxb.spc.edu>, terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes:
> |>> Some time ago, someone explained how to connect a second monitor to a...

  Careful with those attributions 8-) The referenced text is from article
<1992Oct2.224124.18064@thijssen.nl>, by lamhof@thijssen.nl (Lambert Hofstra).

  Thanks for the "wrap" program, though.

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381
From: moeller@gwdgv1.dnet.gwdg.de ("GWDGV1::MOELLER")
Newsgroups: comp.os.vms
Subject: RE: fwrite() in vaxcrtl broken?
Date: 14 Oct 92 17:45:09 GMT
Distribution: world
Organization: The Internet

John Hawkinson <panix!jhawk@NYU.EDU> writes:
> I'm experiencing this REALLY weird problem with fwrite() to stdout.
> It appears to work fine when I run the program, but if I spawn/nowait/out
> the program, it sticks a newline/cr/whatever in there!
>[...]

Most VMS disk files are structured into "records", and the newlines
you see when TYPEing a file are added implicitly (also the editors
usually show you one "record" per line). To a first approximation,
the only exception are files *created* by the VAXC library functions.
Unfortunately, the disk file used with SPAWN/OUTPUT=file is created
by the SPAWN command as a record-oriented file; btw, the same goes
for a batch .LOG file.

The writers of the VAXC library decided to take literally the description
of fwrite() which says "writes `n' records of `size' bytes", and therefore
with record-oriented files you just get `size' (in your case, 1) byte(s)
per record. This decision is somewhat justified by the fact that fwrite()
is the only standard C library function suitable for writing binary (non-text)
data, and with those one needs some control over record structure (if present)
without recourse to newlines. This idea is *not* specific to VMS; I've seen
a similar behaviour of C programs on another (IBM) operating system
which also has record-oriented files.

The questionable design decision is to make fwrite() behave
in record-oriented fashion even when writing to "text" files,
instead of taking serious the difference of fopen() modes "w" and "wb".

Anyway, using fwrite() for output to "text" files currently isn't portable -
use [f]putc(), [f]puts() or [f]printf() instead!

Wolfgang J. Moeller, GWDG, D-3400 Goettingen, F.R.Germany | Disclaimer ...
PSI%(0262)45050352008::MOELLER      Phone: +49 551 201516 | No claim intended!
Internet: moeller@gwdgv1.dnet.gwdg.de   | This space intentionally left blank.
From: moeller@gwdgv1.dnet.gwdg.de ("GWDGV1::MOELLER")
Newsgroups: comp.os.vms
Subject: re: Checking for MOUNT/VERIFY status
Date: 14 Oct 92 10:35:44 GMT
Distribution: world
Organization: The Internet

<kratom@hhcs.gov.au> asks:
> Is there anyone who knows how to test to see if a disk device is in a
> MOUNT/VERIFY status ? (Especially across a cluster)
>[...]
> When the disk device is in this state, and a command like F$SEARCH is entered,
> then it will hang (the process has to be stopped to get out of this state).
>
> It would be great if there was an F$GETDVI item which returned this status. Is
> there a way of determining this ?

Such "hang" conditions mean that the disk volume is mounted,
but currently not considered "VALID".

The latter can currently be tested by looking at the bit UCB$M_VALID
in the longword returned by the item code DVI$_STS, i.e. f$getd(disk,"STS").
This method, and the bit position may depend upon the VMS version.
As of VMS V5.4-3, UCB$M_VALID is 2048(decimal), i.e. bit 11.

Wolfgang J. Moeller, GWDG, D-3400 Goettingen, F.R.Germany | Disclaimer ...
PSI%(0262)45050352008::MOELLER      Phone: +49 551 201516 | No claim intended!
Internet: moeller@gwdgv1.dnet.gwdg.de   | This space intentionally left blank.
From: RGS@UVMVAX.BITNET ("Randy G. Spooner")
Newsgroups: comp.os.vms
Subject: Unsubscribe info-vax
Date: 9 Oct 92 20:24:00 GMT
Distribution: world
Organization: The Internet


        unsubscribe info-vax

Xref: sparky comp.os.vms:16656 vmsnet.sources.d:648
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms,vmsnet.sources.d
Subject: Re: Where is UUDECODE, TAR, and UNCOMPRESS for VMS ?
Date: 17 Oct 1992 01:45:44 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 <1992Oct16.161120.3258@wkuvx1.bitnet>, goathunter@wkuvx1.bitnet writes:
>In article <81775@ut-emx.uucp>, tai@utpapa.ph.utexas.edu (Tai Morris) writes:
>> I know UUDECODE, TAR, and UNCOMPRESS originated with UNIX, but I
>> work with uuencode, compressed tar files on a vms machine. I know
>> these utilities exist for the vax, but where ???
>> 
>> p.s. What ftp sites have lots of VAX stuff ??
>> 
>ftp.spc.edu ([192.107.46.27]) has a lot of stuff, as does my FILESERV.
>
>All of the above are available from both. 

Don't forget the DECUS tapes, available via anonymous FTP from
wuarchive.wustl.edu [128.252.135.4].
--------------------------------------------------------------------------------
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:16498 vmsnet.misc:929
From: hdmiller@kodak.com
Newsgroups: comp.os.vms,vmsnet.misc
Subject: RAM Disk for VMS?
Keywords: RAM disk RAMdisk
Date: 14 Oct 92 12:06:41 GMT
Reply-To: hdmiller@kodak.com
Organization: Eastman Chemical Company

Good morning!  We have an pair of applications running here in our group that
communicate with each other via a file on disk.  Up until now, the processes
have been CPU bound, but with faster and faster machines the processes are now
disk bound.  The question is: is software available (either through
configuration in VMS or an add-on product) that allows configuration of a
section of memory as a RAM disk?  This disk space does not need to be large 
(1-2 megabyte OK).  RAM is available on the machine without swapping.  We have
20 VAXstations in this situation, so a hardware solution is probably not
feasible (we would rewrite the code first).  Thanks in advance for any clue you
might provide!

 ***   ******
 **  ********                 H. David Miller     (hdmiller@kodak.com)
 * ** Kodak *                 Process Engineering
 **  ********                 Eastman Chemical Company
 ***   ******

Newsgroups: comp.os.vms
From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Subject: Re: General POSIX information
Organization: Curtin University of Technology
Date: Wed, 14 Oct 1992 19:07:52 GMT

In article <01GPTJFQH2MI0009ET@XRT.UPENN.EDU>, BUHLE@XRT.UPENN.EDU ("E. Loren Buhle, Jr. [-662-3084]", 215) writes:
...
> On machine readable:
> 
> Machine readable copies of the standards, in any form are currently
> not available.  Period.
> 
>    Reasons:
>    a) Document integrity.  There is a real risk (in that apparently
>       it has happened) that slightly modified documents are passed off
>       as the "real" standard.  (Although not impossible, it's harder
>       with paper, and more blatantly illegal.)
> 

Some one should send them this years calender, just to remind(?) them it's
the 20th century...
Showing them how to use a current editing photo-copier would also be fun.

>       Secondarily, when you obtain a copy how do you know, for sure,
>       that it hasn't been tapered with?  You'd have to have some 
>       trusted source.  (Particularly critical for purchasing litigation.)
> 

Does 'digital signiture' ring a bell?

>    b) Loss of income to ISO or IEEE (although an important reason, 
>       cynicism aside, it is less important than the first.)  Without
>       that income, IEEE would be able to progress the standards process
>       forward.  

Ah, the $$$ rules OK. Your freudian slip is showing, BTW :-)

~Paul
From: ray@astro.ocis.temple.edu (Ray Lauff)
Newsgroups: comp.os.vms
Subject: Bookreader format reader?
Keywords: InfoServer 150, CD-ROMs
Date: 13 Oct 92 12:25:58 GMT
Organization: Temple University
X-Newsreader: Tin 1.1 PL5


Hello World!

We recently installed an InfoServer 150 with the 
online documentation disks now available to all of our
VAX systems.  Unfortunately, most of our systems are set
up without the benifit of DECwindows.  We have ASCII 
terminals that are used by our students.

Has anyone written a BOOKREADER interface for ASCII
terminals which would make the documentation on the 
InfoServer 150 CD-ROMs available to our students?
I'm not looking for much here, just a plain display
of the text, although some searching and sorting
ability would no doubt be helpful.

Any comments appreciated.  Thanks in advance.

Ray.

Ray@astro.temple.edu
Newsgroups: comp.os.vms
From: larry@vishnu.eco.twg.com (Lawrence B. Henry III)
Subject: Re: Remote tape backups, RMT, etc.
Reply-To: larry@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Mon, 12 Oct 92 04:40:27 GMT


In article <1b4aq8INNncc@gap.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
|>Path: eco.twg.com!uunet!think.com!sdd.hp.com!elroy.jpl.nasa.gov!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
|>From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
|>Newsgroups: comp.os.vms
|>Subject: Re: Remote tape backups, RMT, etc.
|>Date: 9 Oct 1992 16:08:40 GMT
|>Organization: HST Wide Field/Planetary Camera
|>Lines: 18
|>Message-ID: <1b4aq8INNncc@gap.caltech.edu>
|>References: <9210081344.AA17185@relay1.UU.NET>,<9OCT199210543169@jhuvms.hcf.jhu.edu>
|>Reply-To: carl@SOL1.GPS.CALTECH.EDU
|>NNTP-Posting-Host: sol1.gps.caltech.edu
|>
|>In article <9OCT199210543169@jhuvms.hcf.jhu.edu>, ecf_stbo@jhuvms.hcf.jhu.edu (Blabst from the Pabst...) writes:
|>>In article <9210081344.AA17185@relay1.UU.NET>, gleeve@galaxy.dnet writes...
|>>>The remote tape driver (ztdriver) that Wolfgang Moeller did for VMS
|>>
|>>Dec has done it again. The driver for the dsw31/41 synchronous interface
|>>that goes on Microvax 3100 systems is called ztdriver. Ztdriver comes with
|>>the WAN drivers package. This device is also autoconfigured by sysgen. 
|>
|>No, a programmer has done it again.  If you don't want your driver name to
|>conflict with DEC driver names, start your driver name with a Q.
|>--------------------------------------------------------------------------------
|>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.
|>

I am not sure why DECUS doesn't try registering some of the more popular 
freeware driver names with DEC.. I am sure they would be willing to talk on
the subject.

-Larry.
The Wollongong Group.
From: CXNHJP@manadon-engineering-college.ac.uk
Newsgroups: comp.os.vms
Subject: WATCHER
Date: 7 Oct 92 10:40:00 GMT
Organization: The Internet

Does any body out there use the idle process killer WATCHER, if so, have they
had any problems with it eating up 70% of CPU time constantly !!!

Are there any other good idle process killers you can recommend ?


cxnhjp@uk.ac.manadon
From: gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546)
Newsgroups: comp.os.vms
Subject: Re: Decimal prefixes
Date: 10 Oct 92 16:55:00 GMT
Reply-To: gavron@ACES.COM
Organization: ACES Consulting Inc.
News-Software: VAX/VMS VNEWS 1.4-b1

In article <9210092125.AA22402@ucbvax.Berkeley.EDU>,
MOOREMJ@UV6.EGLIN.AF.MIL ("MARTIN J MOORE") writes...
# 
#Having said that, the decimal prefixes I know of are:
# 
#a	atto	10^-18

Does that mean that a whole lot of atto'boys isn't worth one pat
on the back?

:-)

#					Cheers,
#					Marty Moore
#					mooremj@uv6.eglin.af.mil

Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com
I invented skydiving in 1989!
Newsgroups: comp.os.vms
From: lionel@quark.enet.dec.com (Steve Lionel)
Subject: Re: Shareable image max count
Organization: Digital Equipment Corporation
Date:  8 OCT 92 09:47:41    


In article <1992Oct7.141626.5@elmrd6.ineab.ikea.se>, 
anos@elmrd6.ineab.ikea.se (Anders Ostling) writes...
> 
>We are currently trying to find out if there are any practical limit on
>the number of sharables than an executable may consist of. Are there anybody
>else out there that have tried this before, please let us know on your
>findings. I am thinking of system and process parameters and quotas, image
>activation and fault performance and so on.
> 

The limits you'll bump up against (and which can be raised if needed) are:

	FILLM - process open file limit; installing image /OPEN helps
	CHANNELCNT - SYSGEN parameter limiting open channels per process;
	      installing image /OPEN helps
	PROCSECTCNT - SYSGEN parameter limiting number of process sections;
		cheap to raise, installing image /SHARED helps

	The more image sections in your shareable images, the faster a
	user of those images will reach the linker limit above which it
	stops creating demand-zero image sections (I'm at home right now
	and I forget the name of the linker option which controls this.)

Other things you can do to help:

	Reduce number of image sections in each shareable image; ideally,
	you'll have only one of each distinct type.  Judicious use of
	COLLECT linker options can help.

	Maximize number of shareable pages

	Install images /OPEN/SHARED/HEADER_RESIDENT

	Consider using LIB$FIND_IMAGE_SYMBOL to activate infrequently
	used images

I don't know of any hard limits, but as a general rule it's best to keep
the number of images and image sections down so as to reduce activation
time.  Use shareables where it makes sense, but don't overdo it.

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
From: austin@cs.widener.edu (Jeff Austin)
Newsgroups: comp.os.vms
Subject: Re: Silly little DECnet question
Date: 16 Oct 1992 14:54:37 -0400
Organization: Widener University CS Department, Chester PA
Distribution: world
NNTP-Posting-Host: shirley.cs.widener.edu

In article <9210161842.AA25187@ucbvax.Berkeley.EDU> MORRIS@PATRICK-PIMS.AF.MIL ("Jay Morris") writes:
>Hopefully the answer to this question is going to help me prove a point to
>someone.  If you have a system that is not on a network, does not have DECnet
>running, and you do a SHOW NET, what would be the result?  Our's here have
>DECnet running so I can't test it here.

	Hmmm, for a minute there, I thought this was a loaded flame-trap.
	However, under closer inspection, it seems pretty harmless.  Anyway,
	here's what you should see:

		$ SHOW NETWORK
		%SHOW-I-NONET, network unavailable

	Pretty self-explanatory, eh?

				Jeff

-- 
|----------------------------------------------------------------------------|
| Jeff Austin - Widener University, Chester PA | The Computer Rule of Thumb: |
|         austin@tattoo.cs.widener.edu         |  "When in doubt, reboot!"   |
|----------------------------------------------------------------------------|
Newsgroups: comp.os.vms
From: schall@swtech06.cfsat.honeywell.com (Loren Schall)
Subject: How do you determine   DECterm != vt300  ?
Organization: Honeywell Air Transport Systems Division
Date: Mon, 12 Oct 92 16:28:40 GMT

I'm having a problem distiguishing between a DECterm and a vt340.

I use the folowing code, in my LOGIN.COM, to determine what kind of
terminal I'm logging in at.

    $term = F$GETJPI(0,"TERMINAL")
    $class = F$GETDVI(term,"DEVCLASS")
    $type = F$GETDVI(term,"DEVTYPE")
    $IF class .EQ. %X42
    $THEN                           ! is a terminal
    $    IF (type .EQ. %X6E) .OR. (type .EQ. %X71)
    $    THEN                       ! is VT200 or VT400

   { sixel graphics stuff }

    $    ENDIF 
    $    IF type .EQ. %X70
    $    THEN                       ! is VT300

   { DECterm stuff }

    $    ENDIF
    $ENDIF

GETDVI reports a DECterm as a vt300.  The problem is, now, sometimes
I'm using a vt340.  What's the right way to distinguish between a
vt300 and a DECterm?

On an almost related note, what is the correct way to tell DECwindows
LSE to open a 132x48 window at startup without interfering with
nonDECwindows LSE startup?

Loren
schall@swtech.cfsat.honeywell.com (Loren Schall)
From: gleeve@galaxy.dnet
Newsgroups: comp.os.vms
Subject: re: How to prevent changing file protection
Date: 15 Oct 92 13:59:49 GMT
Organization: The Internet

While in general VMS does not support preventing a user from changing
protection of files he owns, there are some situations in which the
results might be achievable.
   If the problem is that a user attempts to deny system access to
the files, a pass with BYPASS turned on to reset the system access to
allow backup will take care of the problem. It's a bit rude 'n' crude
but will work.
   If the problem is a user deleting files he shouldn't and these are
limited in number, the files can be set to be owned by someone else
and the user given access for RWE via an ACL. (One uses SET FILE/OWN.)
   If the problem is that a user tends to reset his file protections to
allow world access and this causes files to be exposed to loss, leaking
out of the system, etc., then a device ACL might be the thing to use.
   To use a device ACL, you just define it (in 5.4 VMS at systartup; in
VMS 6.x it's carried on the device...5.5 still needs the systartup
to do it, I believe) so that either access is denied to all but holders
of some identifier, or that access is denied to holders of some
identifier. We used this for DECnet default access, with the default
and FAL etc. accounts disabled from access to most disks on the system.
   The beauty of device ACLs used in this way is that anyone denied
access to the disk due to the ACL never sees the file protections (or
lack thereof). The security works, from the point of view of the suer
oops, user, who wants to allow the world to copy his file, like
mandatory security. Yet it's built into every VMS system.
   The DECnet identifier propagator I put into the S90 VAX tapes
was designed to let this be used for classes of users.
   Where you need to protect lots of users from each other, this sort
of control can become tedious, but you can organize your system with
virtual disks using vddriver and accomplish it, having users
segregated into different disk "volumes" each of which may have
separate ACLs to control access the way you as system manager see
fit. It takes a driver and space for a UCB; the system performance
hit is small, though running a system with hundreds of virtual disks
might get to be a headache. It's easier if your population of "problem"
users is limited or if you just need to protect against certain
accounts.
   One warning: when assembling vddriver, be sure the vd_units parameter
is big enough for the number of units you will use. The driver
won't let you define more, but that's what determines the limit.
If you use someone else's driver than mine, you will probably have
some similar thing to set up.
Glenn Everhart
Everhart@Raxco.com

Newsgroups: comp.os.vms,comp.unix.ultrix
From: larry@vishnu.eco.twg.com ()
Subject: Re: remote backup of vms on ultix host
Reply-To: larry@vishnu.eco.twg.com ()
Organization: The Wollongong Group (East Coast Operations)
Distribution: na
Date: Wed, 7 Oct 92 14:48:55 GMT


In article <1992Oct4.141853.29099@decuac.dec.com>,
mjr@hussar.dco.dec.com (Marcus J. "Buddy can you spare a clue?" Ranum)
writes:
|>>I'm looking for a utility to do remote backups of vms systems on
|>ultrix
|>>hosts analogous to rdump/rrestore.  Anyone know of such a product?
|>
|>	I don't know enough about how to make something look like a
|>device for VMS, but implementing a client side daemon that talks
|>to rmt(8) shouldn't be too hard. After all, I managed to do it. ;)
|>The ugly problems will probably arise where VMS doubtless expects
|>some mass of complex state with the tape drive, which UNIX will
|>doubtless have no idea about. Dumping to disk and then hammering
|>stuff over the network to tape will probably work easier. You
|>might want to look over my code for rmtwrite (client side rmt)
|>on decuac.dec.com, pub/sources/rmtwrite.shar.Z which is UNIX
|>specific code that at least does the protocol.
|>
|>mjr.
|>

Unless you write a client that makes it look just like a tape device you
don't have much.. We have written an RMT client for VMS.. looks just like a 
tape device. You can perform all of the tape functions that you have
grown to know and love with VMS.. ie, BACKUP etc.. The real gotchas to 
RMT client are which kinds of tape devices you are going to support.. 
The RMT protocol is so anemic that supporting a wide variety of tape devices 
is tough.. I believe that TGV has also written an RMT client.. but I don't 
believe I have ever heard of any others out there.. I think that somebody
once mentioned that their is a DECNET based REMOTE TAPE device (on DECUS
distribution) but this is tied to VMS and certainly doesn't support the
RMT protocol.

Cheers,
-Larry.
The Wollongong Group
Newsgroups: comp.os.vms
From: themos@umbc5.umbc.edu (Mr. Themos Pentakalos; ADMIN-COMP)
Subject: Pathworks for DOS related.
Organization: Univ. of MD, Baltimore County
Date: Tue, 13 Oct 1992 15:09:10 GMT

Hi everyone.
I posted this here because I know there are a lot of Pathworks managers
on this list. If you are not one of them, simply skip it. Thanks!

I have been trying to get some info from DEC, 3com, or ANYONE out there
about which new ethernet cards are compatible with Pathworks for DOS.
I am interested in 32 bit EISAs as well as other 16 bit, etc card.

DEC's responce, all 4 times, has been:

	"well, we recommend these DEPCA cards, or the 3com 3C503"

	Sounds like they are all reading documents from version 3.0

	Thanks and please reply to:   themos@umbc5.umbc.edu

	Themos

Newsgroups: comp.os.vms
From: johnn@eskimo.celestial.com (John Navitsky)
Subject: Questions on tapes.  (TARed Sun, Copying VAX BACKUPs)
Organization: =>ESKIMO NORTH (206) 367-3837 SEATTLE, WA.<=
Date: Fri, 16 Oct 1992 19:02:59 GMT

Hi all,

Preliminary:  

  We have a Vax with three tape drives, a TK70, TU81 and a 3rd party 8mm by
  Contemporary Cybernetics Group (exabyte 8500) w/ a compression board.  That
  tape is hooked into the system with a Qbus SCSI card.

Question 1:

  We automatically back up about 1.5GB of data to the 8mm nightly.  We do not
  have disk space to copy these files to disk.  We would like to be able
  to copy an 8mm tape to a set of TK70s.  Is this possible?  If so, how?

Question 2:

  We have some tapes from a 8mm (same type) drive on a Sun server in TAR 
  format.  Is it possible to restore this info on the VAX?  The TAR block-
  size was specified at 1024.
 
Thanks for your assistance!


-- 
   ---------------------------------------------------------------------------
    ||   John Navitsky   `,`,`,`,   e-mail >>  johnn@eskimo.celestial.com  || 
   ---------------------------------------------------------------------------