HDTenEightyP/NetNews huggingface dataset:
From: "David Harrold, MSOE" <harrold@kirk.msoe.edu>
Newsgroups: vmsnet.internals
Subject: System Service to create users?
Date: Thu, 27 Aug 1992 16:46:00 CDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Hi all,

     Does anyone know if there is a system service available that will
     create a user in SYSUAF.DAT.  I know I could directly open the
     the file and add a record, but I prefer not to do this.

     Any help on this would be greatly appreciated.

     Thanks,

     Dave Harrold



...............................................................................

David Harrold                                             harrold@kirk.msoe.edu
Milwaukee School Of Engineering                           Phone: 414-277-7286
Academic Computing Services                               FAX:   414-277-7465
P.O. Box 644,    1025 N. Milwaukee St.,      Milwaukee,   WI       53201-0644

...............................................................................
Newsgroups: vmsnet.internals
Subject: Backup, VMB and the boot block
From: tanner@cerritos.edu
Date: 31 Aug 92 19:57:19 PST
Organization: Cerritos College, Norwalk CA

I have one of those idle questions that I can't answer and just can't forget.

In section 30.2.3.3.1 of the I&DS it says that VMB is one of the few files
that is located by an absolute LBN (in the boot block) and is not free to be
moved on our VAX 6000 system disk without running WRITEBOOT.

When a system disk is restored from backup, does BACKUP somehow preserve the
LBN of VMB.EXE or does it perform the functions of WRITEBOOT?  Obviously it
does something, or you couldn't boot from a restored system disk.

-Bruce
-- 
Bruce Tanner        (310) 860-2451 x 596    Tanner@Cerritos.EDU
Cerritos College    Norwalk, CA
From: dsroberts@beckman.com
Newsgroups: vmsnet.internals
Subject: RE: PATCH on ALPHA ?
Date: 2 Sep 92 07:16:59 PDT
Organization: Beckman Instruments

In article <9209021225.AA14429@sndsu1.sinet.slb.com>, brydon@dsny25.sinet.slb.com writes:
> You gotta be kidding!! All of the CSCPAT_nnnn kits (all of them!) are
> VMSINSTAL savesets that Patch an image.  Almost everything that is done in a

Not that this is related to the topic at hand, but this is decidedly untrue. 
Many of the CSCPAT kits nowadays have whole images that are replaced and never
do any patching.  Now, if you're saying all the images on the kits were patched
by DEC at DEC, that I can't speak to :-)

> _______________________________________________________________
> Harvey Brydon         | Internet:   brydon@dsn.SINet.slb.com
> Dowell Schlumberger   | P.O.T.S.:   (918)250-4312
>     I'm not an actor but I play one on T... Hey!
-- 
   Don Roberts                   Internet:  don@beckman.com
   Beckman Instruments, Inc.     Phone:     714/961-3029
   2500 Harbor Bl. Mailstop X-12 FAX:       714/961-3351
   Fullerton, CA  92634          Disclaimer:  Blame me, not Beckman.
   People are as happy as they decide to be - A. Lincoln
Newsgroups: vmsnet.internals
From: eric@sejnet.sunet.se (Eric Thomas)
Subject: re: PATCH on ALPHA ?
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden
Date: Wed, 2 Sep 1992 02:22:01 GMT

In article <1992Sep1.214402.16889@eco.twg.com>, reece@eco.twg.com (Reece R. Pollack) writes:
> In article <715362736.403197.MILLER@TGV.COM>, MILLER@TGV.COM writes:
> |>I doubt it.  I've already worked with miles and miles of machine listings
> |>from both the GEM C compiler and the MACRO32 compiler.  I've even found
> |>several compiler optimizer bugs.  I know what I'm doing.
> 
> And he's modest too.

I'm sure he is old enough to defend himself, but I'd just like to point out
that, to me, this didn't look like bragging - just pointing out former
experience in patching. Finding compiler optimization bugs is nothing
extraordinary if you have been exposed to enough compiler-generated
pseudo-assembler listings. Every time you mention "patching" or any other
machine code based maintenance technique, people will start jumping and saying
that this is too dangerous and unreliable, so one develops this sort of
reactions.

> |>Besides, a lot of patches are trivial, like constant changes.  And
> |>what if I want to patch some native M64 code?
> 
> I don't think I'd want to subject my customers to the headache of trying
> to manage patched images. DEC has been moving away from this as fast as
> they can, and for good reason.

And I don't think I'd like to subject myself to vendors who think they know
better than the customers what is good for them, or that they know why other
vendors are allocating their programming and support resources in one way or
the other. Many patches are, indeed, constant changes, and ZAP utilities have
VERIFY statements, sometimes even checksums. You can read me a zap on the phone
in 5 minutes, and I know to check everything twice and to make a backup before.
The alternative is to tell the users I have to wait for a tape, which may or
may not be acceptable. More often than not, the problem requires an immediate
solution because the dean of something is pissed off and watching the clock
tick.

A long time ago I used to be able to get patches on the phone from my vendor,
or short "updates" (basically source code patches). Now I can only get tapes
with not one but a few hundred replacement files, checksummed and
counter-checksummed and hyper-verified by a veeeeeeery slow, pseudo-AI software
service manager factory, which the vendor decided I needed. I now need hours to
do what I used to do in 5 minutes and reliability was MUCH better back then.
Boy am I glad my vendor doesn't want to subject me to the horror of patches
any longer, and for good reasons.

  Eric
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.internals
Subject: VMS tuning for a vaxcluster (LAVC)
Date: 26 Aug 92 18:11:46 GMT
Organization: Mitech Corporation, Concord MA

This talk about FPL etc has reminded me to ask a question
about VAXCLUSTER (LAVC) behavior.

The behavior of the VMS memory management with respect to the FPL
and installed images is said to reduce the amount of disk activity
required when activating commonly used images, as long
as the amount of free pages available allows pages from your favorite image
to remain in the FPL.

Correct?

Now. My question is, what good does this do in a VAXCLUSTER environment,
specifically a LAVC environment? Here a page fault consists
of both a trip over the ethernet and a trip to disk.

Obviously if a satelite has the pages of an image already in memory,
then you will winning big, avoiding a trip across the ethernet and everything.

But what about the trip to disk? Is there a way to avoid that?

The LAVC server node may have plenty of free memory, but it may have *never*
activated any of the images that people on the LAVC's are interested in.

Even if it had activated those images, would there be any optimization
available? (That is, does the vaxcluster lavc disk server -know- that
pages from a disk file may already be available in memory?)

My current situation is that I have a VAXSTATION-3200 with plenty
of free memory serving as a LAVC boot node, and I'm interested in
any hacks available to speed things up. 

In VMS 5.4-3 I was using the hack of having all images from SYS$SYSTEM
and SYS$SHARE also available on the local hard disk. That is a bit hackish,
so I didn't bother re-doing that for VMS 5.5.

-gjc
From: cd962@cleveland.Freenet.Edu (Prateek Srivastava)
Newsgroups: vmsnet.internals
Subject: Reading IBM tape on VAX
Date: 2 Sep 1992 19:34:54 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: cd962@cleveland.Freenet.Edu (Prateek Srivastava)
NNTP-Posting-Host: hela.ins.cwru.edu


I hope this is the correct news group for this problem.

My group has just bought some data that came on IBM tapes.
The only tape drives that are around are attached to a 
DEC system. The tape contain labeled file (?), and when sysop
tried to read these files in the label information also
got in, I do not have enough information to strip out the
label info. I have been given to understand that reading the
IBM tapes on main frame is a regular affair and that some
option should be used while reading/mounting the tapes.

I will appreciate if some one can help me find those option(s).
My email address is :-
     cd962@po.cwru.edu
-- 

Prateek Srivastava
cd962@po.cwru.edu
cd962@cleveland.Freenet.Edu
From: GAVRON@VESTA.SUNQUEST.COM
Newsgroups: vmsnet.internals
Subject: Technical idiots
Date: 26 Aug 92 07:45:43 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Jon Pinkley pointed out that Bill Hancock is a fool.
I'm sorry to disappoint Jon, but the "Winner of the DECUS Award
for Technical Excellence" is an idiot.  I had the displeasure once
of being in the same room and hearing his banal, content-less
amusing stories-for-idiots.

Bill Hnacock fills the halls with amusing drivel, and crowds
like him, and he doesn't know shit, but that's ok, because
he's amusing.

I may lose consulting $$$ off of this, but at least when I got
my last paycheck, I _knew_ it was because I knew what I was
talking about, not because I was a dickless technically incompetent
storytelling slob.

Ehud
(no, it's not a raw nerve; Bill is a talentless Mac Weenie)

this mail message copyright 1992 ACES Inc., all rights reserved
From: GAVRON@VESTA.SUNQUEST.COM
Newsgroups: vmsnet.internals
Subject: Re: How myths are born...
Date: 26 Aug 92 22:32:11 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Date sent:  26-AUG-1992 15:28:05

Joel Snyder writes:
>In article <9208260710.AA10435@relay2.UU.NET>, "(Jon Pinkley, Westinghouse
> (216)486-8300 x1335)" writes...
>>
>>Unfortunately, it isn't limited to software.  It seems that the "free" trade
>>rags have lots of inaccurate "facts" in their columns.
>>
>
>Well, please consider this an open invitation to any and all takers to
>criticize me (privately, please, but openly if you must) for errors of
>any nature in my columns.  Some may note that I don't have one anymore
>(which is true), but I still expect to be writing in the field, and want
>to know when I say something really stupid.

        Why don't we all call Digital Review (Jack Fergreus @ 617-558-4305
        and ask that they replace the foolish and inane Bill Hancock with
        the accurate and sober Joel Snyder?  I'd rather read a Joel column
        than a Bill rag anyday.

        How about we ALL call Jack and pitch for Joel!!!

>BITNET: jms@Arizona  Internet: jms@arizona.edu  SPAN: 47541::telcom::jms

        Ehud

--
Ehud Gavron        (EG76)
gavron@vesta.sunquest.com
"The world bores you when you're cool."
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.internals
Subject: re: PATCH on ALPHA ?
Date: 3 Sep 92 13:09:40 GMT
Organization: Mitech Corporation, Concord MA

In article <715417768.652976.MILLER@TGV.COM>, MILLER@TGV.COM writes:
> Has any one else here had any problems using Patch?

Yes. I love the idea of patching things, especially patching running
systems. The good experiences comes from my LISP/LISPMACHINE days.
And I beleive that -as-a-model- patching is the correct way to do 
software support and upgrades.

So, when we are patching parts of our system written in 
imbeded/interperted language we send out stuff that is indeed a patch.
However, for stuff compiled with the C compiler, I found that I could
never seem to be able to take the time to convert a new procedure definition
changed at the source level into a convenient set of PATCH instructions.

Why, because our product is split up into about 39 different images,
with a typical size of 500 kilo-bytes. And a 500 kbyte VMS image compresses
with uucp_bin:compress into about 384 kbytes. And with a V.32 modem we
can UUCP that file in about 10 minutes.

Then, well, things like UID files (output of the MOTIF UIL compiler)
also end up making a significant portion of the size of the "binary"
stuff in a product. And that isn't even machine code.

--- WHAT THE WORLD NEEDS NOW: ---

A good "arbitrary-binary-file" diff/patch utility. Something with
good compression and error detection. Perhaps using technology
similar to what high-definition television would use to compress
differences between frame image[t] => image[t+delta(t)]

Something that could handle the addition of a few bytes in the
middle of an image, and other changes, without generating
grossly large differences.

> On those occations when I need to read someone a patch over the phone
> I have them read it back to me before they perform an update. 

Unfortunately, the only thing we can patch like that (via a human) is very
small chunks of interpreted code. But it is always risky.

> With Patch we can have a fix out to the customer within an hour
> instead of the day or two it takes to ship a new tape.

Indeed, fixes-while-U-wait is the only way to do good customer support.

We end up putting a good deal of work into getting the EMAIL connections
going. Boy is that a hassle. Usually the customer is already connected
to some internal DECNET that covers the whole company. But they don't
know that they have internet mail capability, usually through some
obscure gateway run by the research division or some non-responsive MIS
group in central administration.

For other sites, e.g. a Government lab, if we are lucky they can find
an IBM-PC someplace with a modem and kermit.

It can be a hassle, but we find that is some of the most hassle-intensive
organizations you have problems like it taking 2 days for a FEDEX-delivered
package to make it from shipping/receiving or the mail-room back into
the depths of an organization.

Anyway, to grease the administrative wheels, we actually CHARGE EXTRA
for a SUPPORT CONTRACT that doesn't include an EMAIL or DIAL-UP capability!


-gjc
From: Hunter Goatley <goathunter@WKUVX1.BITNET>
Newsgroups: vmsnet.internals
Subject: Re: DR bad, VAX PRO good
Date: Sun, 30 Aug 1992 09:16:33 EDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

don@zl2tnm.gen.nz writes:
>
>In article <6103@npri6.npri.com>, murphy@npri6.npri.com (David P. Murphy)
> writes:
>
>> i have a very high opinion of VAX Professional!  hunter goatley, bruce ellis,
>> and many others contribute valuable articles every issue, and the source is
>
>Does someone have an address for subscription requests?  I haven't seen a
>VAX Pro for _years_.
>
I've included the info below.  In case anybody missed the
announcement, I now also run the VAX-PRO@WKUVX1.BITNET file server.
Each time a new issue comes out, you'll be able to get all the source
code accompanying those articles by sending a command like SEND
AUGUST92 to VAX-PRO@WKUVX1.BITNET.   Send the command HELP in the
body of a mail message for more information.

You need not be a subscriber to receive the files, though Professional
Press certainly hopes that you'll become one.  The file server came
about after discussions in comp.os.vms about the lack of availability
of files except from ARIS and CompuServe.  VAX-PRO@WKUVX1 is a public
service provided by Western Kentucky University and Professional
Press.

Hunter
------
Hunter Goatley, VMS Systems Programmer, Western Kentucky University
goathunter@WKUVX1.BITNET, 502-745-5251

---------------------------------------------------------------------------
To request a free sample copy of _VAX Professional_, please call
215-957-4266.

Subscriptions to _VAX Professional_ are $48 per year (6 bi-monthly issues).
You can subscribe by writing to the following address:

        _VAX Professional_
        101 Witmer Road
        P.O. Box 773
        Horsham, PA 19044-9887.

You can enclose payment, credit card information (VISA, MasterCard, and
American Express---please include your account number and the expiration
date), or you can ask them to bill you.

For faster service, call 215-957-4266.

(The foreign price is $66 per year.  Prepayment is required.)
Newsgroups: vmsnet.internals,comp.os.vms
From: boardman@cancer.unm.edu (Bob Boardman)
Subject: How to move Queue files vms 5.5?
Date: Fri, 04 Sep 92 17:27:00 GMT
Organization: UNM Cancer Center
Reply-To: boardman@cancer.unm.edu


  Last night we moved our system and users from our old RA81's to our
  new RF73's, on our Vax 4000-200 under VMS v5.5.  Everything went pretty
  smoothly, except for the *#$%^$ new queue system.  For some reason, the
  queue system still insists on using the RA81 for two of the three queue
  files.  The logical QMAN$MASTER is defined as SYS$COMMON, and indeed it
  is using the QMAN$MASTER.DAT file on the new RF73 system disk, but it is
  still insists on accessing the RA81 for the other two files:

	 [SYSCOMMON.SYSEXE]SYS$QUEUE_MANAGER.QMAN$QUEUES;1
	 [SYSCOMMON.SYSEXE]SYS$QUEUE_MANAGER.QMAN$JOURNAL;1

  No one at this site has documentation on the new 5.5 queue manager (we're
  an ESL site and the ESL people are unavailable at the moment, and probably
  couldn't help anyways).  I haven't been able to find any other logicals
  that the queue manager might be using to point to these files, so I suspect
  that the location of these files must have been written into the QMAN$MASTER
  file.  We probably shot ourselves in the foot during the 5.5 upgrade by
  specifying the location of the new queue files as "dub0:" rather than
  $disk1:.  Digging through the on-line docs, I think we could maybe do it
  by stopping the queue manager, then using START/QUEUE/MANAGER/NEW_FILE=$DISK1
  to create new queue files, stopping the queue manager again, copying the old
  dub0: files to $disk1, and the restarting the queues, but since we are a
  critical production machine and really need the queues to be working, I'm
  nervous about trying this without knowing for sure that this will work.
  Has anyone else run into this problem?  If so, how do you fix it?

  -Bob


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|      Bob Boardman, University of New Mexico, Albuquerque, New Mexico        |
|         internet:boardman@cancer.unm.edu    bitnet:BOARDMAN@UNMB            |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Newsgroups: vmsnet.internals
Subject: Re: How myths are born...
From: jms@mrsvax.mis.arizona.edu (Entia non sunt multiplicanda praeter necessitatem)
Date: 26 Aug 1992 14:03 MST  
Reply-To: jms@arizona.edu
Distribution: world,local
Organization: University of Arizona MIS Department
X-Lunar-Date: 4 days, 4 hours, 27 minutes since the last quarter of the moon
News-Software: VAX/VMS VNEWS 1.41    

In article <9208260710.AA10435@relay2.UU.NET>, "(Jon Pinkley, Westinghouse (216)486-8300 x1335)" writes...
> 
>Unfortunately, it isn't limited to software.  It seems that the "free" trade
>rags have lots of inaccurate "facts" in their columns.
> 

Well, please consider this an open invitation to any and all takers to
criticize me (privately, please, but openly if you must) for errors of
any nature in my columns.  Some may note that I don't have one anymore
(which is true), but I still expect to be writing in the field, and want
to know when I say something really stupid. 

Joel M Snyder, 1103 E Spring Street, Tucson, AZ, 85719 
Phone: 602.882.4094 (voice) .4095 (FAX) .4093 (data)
BITNET: jms@Arizona  Internet: jms@arizona.edu  SPAN: 47541::telcom::jms
I can't think about that.  It doesn't go with HEDGES in the shape of
 LITTLE LULU -- or ROBOTS making BRICKS...
Newsgroups: vmsnet.internals
Subject: Re: How myths are born...
From: jeh@cmkrnl.com
Date: 27 Aug 92 01:44:44 PDT
Organization: Kernel Mode Consulting, San Diego, CA

In article <9208260710.AA10435@relay2.UU.NET>,
"(Jon Pinkley, Westinghouse (216)486-8300 x1335)" writes:
> Jamie Hanrahan, Kernel Mode Consulting, San Diego CA, writes concerning
> MMG and VMS tuning in general:
>
>>Lots of well-known "authorities" on VMS get these details wrong, repeatedly,
>>in print.  Professional courtesy prevents me from naming names.
>
> Unfortunately, it isn't limited to software.  It seems that the "free" trade
> rags have lots of inaccurate "facts" in their columns.
>
> I was really disappointed with a recent column that "explained" Modems and
> the V. specs.  It was written by a winner of the DECUS Award for Technical
> Excellence (Highest Technical Award).  (For Jamie's sake, I will state that I
> am not talking about him.  As far as I know, he doesn't write a column, but
> perhaps he should.)  [...]

Writing a column has its good and its bad points.  You gain lots of exposure
and credibility, especially among those who can't possibly know if you're right
or wrong (this is the "it must be true or they wouldn't print it" crowd).

On the other hand, writing even a few hundred words and making DAMNED sure that
they're all correct (and free from the detail-level errors of the sort that
crept into the net article of mine that Jon quoted above!  I've already posted
a correction....) isn't worth the dollars paid, not by several orders of
magnitude.  (And you'd better, because right alongside the believe-everything-
they-read crowd, are the ones who have nothing better to do but pore over
everything written trying to find mistakes.)

I'm not even certain if the publicity (which would amount to free advertising
for my consulting business) is worth the work involved.

> Which brings me to my point.   Jamie, can you please post the notes from
> your excellent talk at DECUS:  "The VMS Scheduler: Myth vs. Reality"

Maybe.  I'll give that talk again at DECUS in Las Vegas, after which it may
become an article somewhere.  I have a feeling, though, that as a regular
columnist, I might be a source of frustration for an editor.

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
From: reece@eco.twg.com (Reece R. Pollack)
Subject: re: PATCH on ALPHA ?
Reply-To: reece@eco.twg.com (Reece R. Pollack)
Organization: The Wollongong Group (East Coast Operations)
Date: Tue, 1 Sep 92 21:44:02 GMT


In article <715362736.403197.MILLER@TGV.COM>, MILLER@TGV.COM writes:
|>>> Oh bugger.  So I have to cut a tape whenever I want to send someone a fix?
|>>> With Patch I can fix things immediately over the phone.  I think it's a
|>>> foolish decision to leave Patch out.  It's going to make my job a lot
|>>> harder.
|>>
|>>I doubt it. Given all the work that a RISC compiler does on your source
|>>(even, I suspect, if the source is MACRO32), I think that trying to
|>>implemement a nontrivial patch to the code that doesn't have unexpected
|>>side-effects is probably a lot more work than recompiling!
|>
|>I doubt it.  I've already worked with miles and miles of machine listings
|>from both the GEM C compiler and the MACRO32 compiler.  I've even found
|>several compiler optimizer bugs.  I know what I'm doing.

And he's modest too.

|>Besides, a lot of patches are trivial, like constant changes.  And
|>what if I want to patch some native M64 code?

I don't think I'd want to subject my customers to the headache of trying
to manage patched images. DEC has been moving away from this as fast as
they can, and for good reason. It's much too easy for a customer to mis-
type a patch and really screw things up, and if you provide them with a
file to do it for them, why not provide them with an updated image?

|>>The only exception I can think of is patching the DATA sections in the
|>>image. But the current patch utility could do that, and I can't remember
|>>when I last wanted to use PATCH on data sections anyway!
|>
|>So when is Digital going to fix Patch so that it works on already
|>loaded images?

If you get killed playing the PDP-11 version of Dungeon, it asks you if you
want to be reincarnated. If you say no, it indignantly protests, "What? Don't
you trust me? I once patched a running RSX system and it stayed up for 30
seconds!!"

--
Reece R. Pollack
Senior Software Engineer
The Wollongong Group, Inc.