HDTenEightyP/NetNews huggingface dataset:
From: moeller@gwdgv1.gwdg.de
Subject: Re: re^2: extending INDEXF.SYS (new idea!)
Reply-To: moeller@gwdgv1.gwdg.de
Organization: GWDG Goettingen, F.R.Germany
Date: Sat, 21 Nov 1992 00:45:32 GMT

In article <9211170506.AA25540@ucbvax.Berkeley.EDU>, I wrote:
>Some time ago, there was some discussion re: pre-extending INDEXF.SYS,
>and the consensus was, that one has to be very careful,
>so that INDEXF.SYS won't become a multi-header file by any chance.
>
>It occurred to me that there is a VMS utility for extending files,
>which *has* that important check built-in:
>
>  $ MCR SYSGEN CREATE disk:[000000]INDEXF.SYS/size=<newsize>
>[...]

Sorry, it wasn't a good idea - please forget it!

Basically SYSGEN CREATE does the right thing by extending a file with
FIB$M_NOEXTHDR, which avoids getting a multi-header file.

But there several problems:

A minor one was noted by D.Jones, in that any extend operation 
probably won't update the alternate index file header
(which allows recovery from a damaged primary header);
ANALYZE/DISK/REPAIR should fix that - often that's a good idea anyway.

Unfortunately, SYSGEN does two more things:

(a) the equivalent of SET FILE/NOBACKUP (noted by simons/G=Colin/...)
    I doubt that this would be a problem, because BACKUP saves INDEXF.SYS
    "file header only" anyway (look at your BACKUP Journal!).

(b) the equivalent of SET FILE/END_OF_FILE, i.e. it explicitly sets
    the logical end-of-file mark to the highest block allocated 
    This isn't desirable anyway (makes INDEXF scans slow);
    unless the disk is being used for the first time, 
    there's also a good chance for some of the blocks 
    formerly beyond e-o-f in fact to look like valid file headers
    (from a previous copy of INDEXF.SYS, which usually occupies
    the same disk blocks after a re-INITialization).
    Run ANALYZE/DISK/REPAIR, and you suddenly have lots of 
    "multiply allocated blocks" (due to re-appearing "lost" files)!

Just yesterday I received VMS 5.5-2; if BACKUP/NOINIT now finally does
the Right Thing, exteding INDEXF.SYS may become a topic of the past.

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.
Newsgroups: comp.os.vms
From: francini@narfvx.enet.dec.com (John Francini)
Subject: Re: BACKUP performance - can I expect any better?
Organization: Digital Equipment Corporation, Littleton, MA
Date: Sun, 22 Nov 1992 08:00:00 GMT


In article <1992Nov18.195835.8983@ac.dal.ca>, ae@ac.dal.ca writes...
[...]

> 
>	BACKUP /IGNORE=INTERLOCK disk tape_file /BLOCK_SIZE=32256
> 

For maximal tape usage, set /BLOCK_SIZE to the maximum allowed, 65535.

You also may want to experiment with various values of /GROUP=n. This sets
the size of redundancy groups on the tape.   Redundancy groups allow for
more bulletproof data recovery in the event of bad media, but at a cost in
excess data being written onto the tape (thus lowering your effective
throughput).

>WSMAX on this system is 65500.  The quotas for the username that runs BACKUP
>are 
> 
>	Maxjobs:        20  Fillm:       128  Bytlm:        65536
>	Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
>	Maxdetach:       4  BIOlm:       128  JTquota:       1024
>	Prclm:           5  DIOlm:      4096  WSdef:          200
>	Prio:            4  ASTlm:      4096  WSquo:        16384
>	Queprio:         0  TQElm:        10  WSextent:     24000
>	CPU:        (none)  Enqlm:       256  Pgflquo:      32768
> 

BACKUP will never grow to the account's WSEXTENT size, only its WSQUO size.
You may want to increase the WSQUO so that BACKUP will pre-read more
files.  Also turn up FILLM.  BACKUP will only process ahead up to FILLM (or
CHANNELCNT if that is lower) files in a gulp, no matter how much memory it
has.  [The idea here is to let BACKUP slurp up vast amounts of disk data in
big chews, so it can drool it onto the tape at full tape speed with no
stops.  This requires a really wide-open account, in terms of process
limits.

Process priority is another factor.  If BACKUP and interactive users are
fighting it out at priority 4, you can be sure your saves will take a
while, and tapes will not stream effectively.  There's two choices here:
jack up BACKUP's base priority to 5 (so it can be favored just a bit more
than interactive users), or run backups in 3rd shift.

Just some thoughts....

John Francini
PATHWORKS for VMS development
Digital Equipment Corporation
francini@narfvx.enet.dec.com
From: mzraly@ra.cs.umb.edu (Michael S Zraly)
Newsgroups: comp.os.vms
Subject: Is it possible to DEFINE KEY in edit/edt AS EXIT?
Date: 20 Nov 92 09:38:22 GMT
Organization: UMass/Boston
Originator: mzraly@ra.cs.umb.edu

I am writing a *very* simple data-entry program for use by a few people
with no experience whatsoever with editing on VMS systems.  I find it
easiest to use EDIT/EDT for the data entry part, but I would like to
avoid having to remind the users to type CONTROL-ZexitRETURN: I'd
much rather be able to have them type, for instance, CONTROL-X or F10
and have EDT interpret this as CONTROL-ZexitRETURN somehow.

The "obvious" DEFINE KEY CONTROL X AS 'EX.' does not work, since the
nokeypad command EX just leaves nokeypad mode for line mode.

For various reasons, I'd rather *not* use edit/tpu, although obviously
that would solve the problem.

On another note, I would like to have the numeric keypad kept in
numeric mode rather than application mode: I cannot seem to do this in
any way in EDT.  My current solution is to SPAWN/NOWAIT a subprocess
that SET TERM/NUMERIC <terminal-name> after waiting a fraction of a
second, but this is a pretty ugly solution.  Can anyone tell me any
better solution?

Thanks,
  Mike

-- 
Mike Zraly		The first duty of a revolutionary is to get away
mzraly@cs.umb.edu	with it.	-- Abbie Hoffman
Newsgroups: comp.os.vms
From: dirico@tropix.enet.dec.com ()
Subject: Digital's Alpha AXP Information FAX Service
Keywords: Alpha AXP
Reply-To: dirico@tropix.enet.dec.com ()
Organization: Digital Equipment Corporation
Date: Thu, 19 Nov 1992 19:02:23 GMT


Looking for immediate information on Digital's Alpha AXP products and services?

Announcing the Alpha AXP Fast FAX Service!
------------------------------------------
Accessible worldwide, the "Alpha AXP Fast FAX" service is available for 
obtaining information on Digital's Alpha AXP products and services.  
The service is extremely user-friendly -- just dial the number, follow 
the voice prompts, and choose any Alpha AXP related subject you would 
like information on. And then, within seconds, you will receive product 
literature right on your fax machine!  Literature available will contain 
detailed product information, product specifications, investment 
protection programs, application and operating system software 
information, and an Alpha AXP family overview. 

U.S. and Canada                 800-842-7027 (from any touchtone phone)
Outside U.S. and Canada         415-694-3916 (from any fax machine)


Feedback welcome to:  dirico@tropix.enet.dec.com

Watch for announcements on availability of information through an automatic
response system via electronic mail!
From: RWU@MATTEC.intel.com ("Ron Wu, SC2-24, 5-2368.")
Newsgroups: comp.os.vms
Subject: Re: ?Why does this backup go so slow?
Date: 16 Nov 92 22:04:47 GMT
Organization: The Internet

>It took us 4.5 hours to do an image backup of an RA90 (80% full of user
>data) onto an RA92?  Why does it not go faster?   [I had prepared a much 
>longer version of the question, with so many particulars, that my boss 
>said to just ask the simple question.]
>-- 
>Brendan Welch, UMass/Lowell, W1LPG,  welchb@woods.ulowell.edu


	Maybe your RA90 disk is badly fragmented (it happened to me
2 weeks ago, same thing), or was your system busy at that time, assuming 
you are not running the standalone backup ?

Ron
From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: RE: what the heck is it?
Date: 14 Nov 92 21:18:51 GMT
Distribution: world
Organization: The Internet


	Can anyone tell me what the TEK4125 graphics window is for?  How is it
	used?  What are its capabilities? Where can a manual be obtained?  No
	one around here seems to know anything about it.

The TEK in TEK4125 stands for Tektronix, known for their electronic measuring
instruments.  They also make graphics terminals - in fact, they were among
the first manufacturers of the things, and their protocols became something of
a standard.  Years ago - around 20 - they made a terminal called a 4014; the
"TEK4014" interface, a very simple one, since it had to be implementable using
the hardwired SSI (small scale integration) of that era - was probably the
most widely accepted graphics output protocol for a very long time.  Every
major graphics package produced TEK4014-style output, at least as an option.
(The other major option was usually Calcomp pen-plotter compatible.)

When DEC produced the VT240 graphics terminal (early 1980's), it included
TEK4014 emulation as one option.  (The other option was ReGIS, a very
different and much more sophisticated protocol that DEC invented.  It has
never caught on outside the DEC world.)  VWS, the original DEC windowing
package for VAXstations, also included a TEK4014 emulator.

TEK4014 mode has two main advantages:  It is VERY simple to emulate; and it
is used by many software packages.

The TEK4125 was a much later Tektronix graphics terminal.  Hardware had
gotten much more sophisticated over the years, as had users' graphics
requirements.  The TEK4125, like many other Tektronix terminals over the
years, had more sophisticated graphics interfaces that 4014 emulation, though
they continued to support it.  The 4125 was at the high end of Tektronix's
range in the mid to late 80's, and its particular version of Tektronix's
graphics protocols came to be accepted as a new standard, and a follow-on to
TEK 4014, by then very long in the tooth.  However, the TEK4125 protocols came
too late in the game to win anything like the universal acceptance of TEK4014.
Graphics terminals are close to a dead issue now, replaced by workstations and
X terminals.  Still, there's a fair amount of code out there that speaks
TEK4125, and since TEK4125 includes TEK4014, all the really old code continues
to work.  So, the protocols live on.

A TEK4125 window is simply a terminal emulator that uses the TEK4125 protocols
rather than the ANSI protocols you are more familiar with.  The 4125 was a
VERY sophisticated terminal - essentially, it was a special-purpose work-
station; as I recall, you could attach a local floppy disk to it! - and had
a great deal of local intelligence.  It provided its own user interface,
which you see emulated when you bring up a TEK4125 window.

I'm not sure where you can find documentation on the TEK4125 protocol.  The
last time I saw a Textronix document for a 4125 terminal, it must have run
between 100 and 200 fairly dense pages.

General interest query:  Is Tektronix still making terminals?  Anyone know?

							-- Jerry
From: kalisiak@acsu.buffalo.edu (Christophe M. Kalisiak)
Newsgroups: comp.os.vms
Subject: LAVc questions again...
Date: 16 Nov 92 21:24:30 GMT
Article-I.D.: acsu.BxtvGv.FEy
Organization: UB


I posted a message about a month ago asking about a VS4000/VLC and 
an MVII, LAVc'ed together. After thinking about it, I believe that
I would probably want to have a local disk on the VS4000, but I don't want 
to spend the money to buy 500meg+ of SCSI disk(s) (which is what the MVII 
has in SMD form). So, if I can find a disk about the size of an RZ23L, I 
could put VMS on it but not much else. With this in mind, I was 
wondering about setting up searchlist logicals so that I could access
the files on the MVII. So, basically, what I want to do is put VMS 
(including Motif) on the VS4000's local disk, and run the programs which
reside on the MVII's disks. I don't want to run the applications on the
MVII; I just want them to reside on the MVII's disks. 

Theoretically, I guess one could just set up the searchlist logicals
on the VS4000 to point to the disks on the MVII and execute the startup
files from there, but I would like some comments on that.


Thanks,
Chris

-- 
Chris Kalisiak		     | "Pound for pound, lame puns are your best
kalisiak@acsu.buffalo.edu    |   entertainment value." -- Gogo Dodo, Tiny Toons
V076N3W7@ubvms.cc.buffalo.edu| "Stimpy, your wealth of ignorance astounds me."
V076N3W7@ubvms.bitnet	     |   -- Ren Hoek, Ren and Stimpy
From: mathog@seqvax.caltech.edu (David Mathog)
Newsgroups: comp.os.vms
Subject: Q: .tar.Z files that won't unpack under VMS
Date: 23 Nov 1992 11:19 PST
Organization: Division of Biolgy, CALTECH
Distribution: world
NNTP-Posting-Host: seqvax.bio.caltech.edu
News-Software: VAX/VMS VNEWS 1.41    

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. 

If you can get the following test file unpacked and untarred on your system
please let me know how you did it! 

The test file:

   FTP site:  cs.arizona.edu
   directory: agrep
   file:      agrep-2.04.tar.Z   (only 62kbytes)

Transfer this to your system (binary) and do:

  $ lzdcmp -x 2 agrep.tarz agrep.tar
  $ tar extract/archive=agrep.tar

On my system tar belches out the following before going belly up:

  Created directory $DATA1:[USERS.MATHOG.AGREP-2_04]
  Records in file $DATA1:[USERS.MATHOG.AGREP-2_04]ASEARCH.C;1 longer than 8192
     bytes have been wrapped
  Created $DATA1:[USERS.MATHOG.AGREP-2_04]ASEARCH.C;1 (2 records)
  Bad header record, dumped in file SYS$SCRATCH:HEADER.TAR

Thanks in advance,

David Mathog
mathog@seqvax.caltech.edu
Manager, sequence analysis facility, biology division, Caltech
Newsgroups: comp.os.vms
Subject: What is a RD33?
From: lucas@fallout.lonestar.org
Date: 18 Nov 92 14:18:09 CST
Organization: DECUS DFWLUG BBS *Dallas*TX*



Does anybody know what a RD33 really is?  I have seen references to that model
but have not actually seen one.  Also, does anyone know who really manufactured
it or what the head/cylinder combination is?

thanks

Marty Lucas
Allied Electronics, Inc.
Fort Worth, TX

lucas@fallout.lonestar.org
Newsgroups: comp.os.vms
Subject: Re: Plans for mixed Alpha/VAX cluster... WARNING!
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 18 Nov 92 07:56:45 GMT
Distribution: world
Organization: The Wolery

DEREK@U.WASHINGTON.EDU writes:
> My guess is that Don did not perform an IMAGE restore of his system disk,
> but that doesn't really matter for my point.  However, it COULD produce
> the problem that both we and Andy experienced.

Don was being bloody stupid and performing hardware surgery without taking
a backup first, and in a bonehead manouevre managed to put two RD drives
onto a single RQDX3 with the same unit select setting.  The controller got
totally confused and promptly *wrote* to the bits of the disk it was
supposed to be reading from when I tried to boot.  This trashed the home
block, master directory, boot block and one or two other minor things that
got underfoot. 

Recovery was by loading a proto-VMS onto an RD52 and booting that,
ANALYZE/DISK and some creative renaming and SET FILE/ENTERing to put the
system disk back together.  Because the MFD had been trashed, the entry
for VMS$COMMON.DIR had been lost, although SYSCOMMON.DIR was intact.  Thus
no [VMS$COMMON].  

More recently, the disk died (possibly due to trashed format?  The lost 
blocks were marked as bad, not just overwritten), and I restored from backup.
It's interesting to see what BACKUP does with a trashed bootblock:

| Dump of device DUA0: on 18-NOV-1992 20:52:32.81
| 
| Logical block number 0 (00000001), 512 (0200) bytes
| 
| 03039401 001E65C0 11C00200 15C600A0 .........e...... 000000
| 8BDFFF76 905F0000 000501FB 000609F7 .........._.v... 000010
| 20202020 4D455453 59530087 80FDFF74 t....SYSTEM     000020
| 73206120 746F6E20 73692020 20202020       is not a s 000030
| 0000000A 0A0D6B73 6964206D 65747379 ystem disk...... 000040
| 00000000 00000000 00000000 00000000 ................ 000050
[etc]

'course the disk boots just fine.... 8-)

--
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
Xref: sparky comp.os.vms:18189 comp.org.decus:990 alt.security:4835
From: sgoldberg@davidsys.com
Newsgroups: comp.os.vms,comp.org.decus,alt.security
Subject: DECUS LUG meeting on security Nov 24 in Sunnyvale
Date: 18 Nov 92 16:49:37 PST
Summary: BAYVAX (DECUS LUG) audio teleconference on security Nov 24 Sunnyvale
Followup-To: comp.org.decus
Distribution: ba
Organization: DAVID Systems Inc, Sunnyvale CA

BAYVAX, the San Francisco Bay Area DECUS (Digital Equipment
Corporation User Society) Local User Group, will be holding its next
meeting on Tuesday, November 24, at 9 am at Avnet Computer, 1175
Bordeaux Dr, Sunnyvale (near 101 and Mathilda).  The meeting is
free and open to the public.

Included in this meeting will be a 90 minute Ray Kaplan audio
teleconference entitled "System and Network Security - How You Will be
Attacked and What to do About it, Part II" moderated by Ray Kaplan and
Joe Kovara. One hour will be an interview with the major players in a
central story in Katie Hafner and John Markoff's book Cyberpunk
(Kevin Mitnick, Lenny DiCicco, and Roscoe).  30 minutes will allow for
Q/A from our audience and in many other locations around the US.  The
conference will cover telecommunications, system, and network
compromise techniques, philosophical underpinnings of attack
techniques, and the flow and availability of vulnerability and
incident handling information.  The idea is to talk to actual crackers
and discover how they attack systems, their philosophy, and how they
protect their own systems and networks. 

For more information, you can contact either
Seth Goldberg (408)720-6834 (goldberg@davidsys.com) or
Rich Taylor (408)776-4978 (rich@csd.com).

-- 
Seth Goldberg
Manager, Computer Resources
David Systems
Internet:  sgoldberg@davidsys.com  
    UUCP:  ...!uunet!sam!sgoldberg
Newsgroups: comp.os.vms
From: critz@star.enet.dec.com (Richard Critz)
Subject: Re: DECWindows CD player -- how?
Reply-To: critz@star.enet.dec.com (Richard Critz)
Organization: Digital Equipment Corporation, Nashua, NH
Date: Sat, 21 Nov 1992 01:52:51 GMT


You must prevent the CD player from being configured as a normal disk.
The comments in the first 50 lines of DECW$EXAMPLES:DECW$CDPLAYER.C
tell you how to do that (on OpenVMS VAX) using the SYSGEN parameter
SCSI_NOAUTO.  You cannot have both GKA0 and DKA0 because both try to
reference the same SCSI ID on the same SCSI bus.
--
-----------------------------------------------------------------------------
Richard Critz					      critz@star.enet.dec.com
      -- I speak only for myself; I make no commitments for Digital. --
-----------------------------------------------------------------------------
Newsgroups: comp.windows.x.openlook,comp.os.vms
Subject: DECwindow applications  under Openwindows
From: cctr127@csc.canterbury.ac.nz (Jason Haar)
Date: Mon, 23 Nov 1992 20:18:16 GMT
Reply-To: Jason Haar <j.haar@csc.canterbury.ac.nz>
X-Newsreader: TIN [version 1.1 PL6]

Hi,

This should be an easy question, but I can't fathom out the method to do
this myself :-{

Has anyone moved DECwindow fonts over into the Openwin 3.0 environment so
that the likes of DECterms can be used? If so, would they be willing to
share their secret with me? I did it for X11 - but Openwindows is beyond
me (at the moment).

Cheers

Jason Haar
From: simons/G=Colin/I=CB/S=Sewell/O=H.A.Simons.Ltd/OU=CORP@mhs.attmail.com
Newsgroups: comp.os.vms
Subject: Re: HELP: how to stop and prevent break in?
Date: 17 Nov 92 17:37:56 GMT
Distribution: world
Organization: The Internet

|Thanks for the explanation of the ownerships in the posts, but the
|problem we encountered is that the first name S892999 shown below is
|essentially a user's name.
|
|~~~~~~~~~~~~~~
|	$ dir login.com;3 /security
|
|	Directory $DUA0:[STUD.S882000]
|
|	LOGIN.COM;3          [S892999,S882000]     (RWED,RWED,,)
|                                 ^       ^
|	Total of 1 file.         |       |
|                                 |       |
|             Another user's name--       --- owner of the account
|
|~~~~~~~~~~~~~~~
|
|I'm just wondering if there is a possiblity that the name of a group
|can be the same as the name of a user. Or is there any way to check
|the group name in VMS? like "ypcat group" in UNIX running NIS.  

	yes, it's possible. if you look up the identifier S892999
	in AUTHORIZE using SHOW/ID S892999 you'll find that it's
	defined as [group-no-of-S882000,177777]. You may add identifiers
	of that type that translate to ANY alpha string, including the
	name of another user. the alpha strings don't mean anything to VMS;
	they are only there to make the output more readable. VMS
	deals with the numeric values only.

	since AUTHORIZE won't let you create a user with a uic of
	[ooo,177777], the only thing i can think of is a user was
	added with an account field of S892999. or maybe somebody
	changed the identifier with the MODIFY/IDENT command of AUTHORIZE.
	Or maybe used COPY or RENAME in AUTHORIZE.

	

Newsgroups: comp.os.vms
From: sca@gese.ge14.mdadv.gv.at (Petzi Schweda)
Subject: !!! HELP for bookreader-docs needed !!!!
Originator: sca@gese0n.ge14.mdadv.gv.at
Organization: MD-ADV, Vienna, Austria
Date: Wed, 18 Nov 1992 09:18:03 GMT


Wether my first article wasn't posted in this group or nobody knows something about - here I am again:

HOW CAN I CREATE BOOKREADER-DOCS FROM A C-PROGRAM ?????

without VAX-DOCUMENT,
and without DECWRITE !

thanks ahead, Petzi 

-- 
Petzi Schweda (sca@gese.ge14.mdadv.gv.at)
MD-ADV, Municipality of the City of Vienna, Austria
-- 
Petzi Schweda (sca@gese.ge14.mdadv.gv.at)
MD-ADV, Municipality of the City of Vienna, Austria
From: JOVAIS@rad.hup.upenn.edu
Newsgroups: comp.os.vms
Subject: f$getqui item - completion_time
Date: 18 Nov 92 23:02:00 GMT
Distribution: world
Organization: The Internet

Hello all,

	Under VMS 5.5 I can't seem to find an item for the lexical f$getqui 
Christopher Jovais			Internet: Jovais@rad.hup.upenn.edu
The Hospital of the University of PA	   Voice: (215) 662-3125
Department of Radiology
Philadelphia, Pennsylvania USA 19104Christopher Jovais			Internet: Jovais@rad.hup.upenn.edu
The Hospital of the University of PA	   Voice: (215) 662-3125
Department of Radiology
Philadelphia, Pennsylvania USA 19104
Will summarize if any interest of significance.

Christopher Jovais			Internet: Jovais@rad.hup.upenn.edu
The Hospital of the University of PA	   Voice: (215) 662-3125
Department of Radiology
Philadelphia, Pennsylvania USA 19104
From: SYSMGR@IPG.PH.KCL.AC.UK
Newsgroups: comp.os.vms
Subject: re: TUNING - QUANTUM SYSGEM parameter
Date: 18 Nov 92 12:05:43 GMT
Distribution: world
Organization: The Internet

Slightly provocative reply:

If QUANTUM=20 is OK on a microVAX-II (less than 1 VUP) (and it is!), then
logically QUANTUM=1 on anything rated at more than 20VUP should be OK,
maybe even optimal.

:-) :-) :-)

	Yours,
		Nigel Arnot

		NRA%ipg.ph.kcl.ac.uk@nsfnet-relay.ac.uk   (internet)
		NRA%uk.ac.kcl.ph.ipg@ukacrl.bitnet        (bitnet)