HDTenEightyP/NetNews huggingface dataset:
From: ault%alumni.cco.caltech.edu@CITIAGO.BITNET (Richard Ault)
Newsgroups: vmsnet.networks.desktop.pathworks
Subject: RE: ...DEC ethernet board and 486/50dx
Date: 28 Aug 92 13:59:04 GMT
Content-transfer-encoding: 7BIT

In bit.listserv.pcsa-l you write:
 
>   Hi,
>
>        Has anyone out there been able to get DEC's DEPCA ethernet board
>to work in a 486-50mh DX  computer.  I recently got a no-name brand PC
>(that is what you get when you work for the state and have to accept low bids)
>that has an AMI -EISA motherboard.  According to the manual it is suppose to
>support both 8 and 16 bit boards (both ISA and EISA).  The only other boards
>in the machine are the TVGA board and an SCSI -EISA disk controller.
>
>However, when I boot with the DEPCA board, all the interrupt
>settings come up as 00 other that IRQ 2 (using the NDIS drivers).
>I know the board is ok (I have tried two different boards).
>Has anyone experience this problem and were you able to fix it.
 
We have a similar problem with a 386sx/25 when we set the memory to E000, the
NDIS driver reported int=00 no matter how the board was strapped.  We ended up
disabling the ROM and putting the IO address and RAM address in the DEPCA.DOS
section of protocol.ini and NI_IRQ in the DATALINK section.  That seemed to
cure our problems.  We have VERY old DECPA's (BIOS Copyright 1987) which
could also make a difference.
 
Hope this helps
 
Richard Ault, Queens College, Charlotte, NC ault@queens.edu
From: karin@zach.fit.edu (Karin Nicholson)
Newsgroups: vmsnet.networks.management.misc
Subject: Re: Getting IP addresses (was Re: HOW to get decus uucp (last ...))
Keywords: jade.berkeley.edu 117, DNS, nettlerash
Date: 27 Aug 92 21:15:40 GMT
Organization: Florida Institute of Technology, Melbourne USA

In article <l7oh0kINNdq7@utkcs2.cs.utk.edu> shuford@cs.utk.edu (Richard Shuford) writes:
>The machine known by the name of "jade.berkeley.edu" listens on TCP
>port 117 for inbound Telnet connections to its network-information 
>server.  From a BSD Unix system, you'd normally issue the following
>command:
>
>   % telnet  jade.berkeley.edu  117
>
Make that:

    % telnet netinfo.berkeley.edu

> ....Richard S. Shuford  | "A prudent man sees danger and takes refuge,
> ....shuford@cs.utk.edu  |  but the simple keep going and suffer for it."
> ....BIX: richard        |  Proverbs 22:3 NIV


-- 

 .-.|     |    |     | |     /------------------\    Karin Nicholson
 |  |-..-.|/.-.|-..-.|*|/   < karin@zach.fit.edu >   Academic Computing Services
 `-'| |`-'|\`-'| |`-'|||\    \------------------/    Florida Tech
From: robbie@winkle.bhpese.oz.au
Newsgroups: vmsnet.internals
Subject: Re: Booting MicroVAX 3400 using non-system UIC
Date: 2 Sep 92 11:21:30 +1000
Organization: BHP Information Technology, Newcastle

In article <01GO8KCZ8CCY001SUR@VAXF.COLORADO.EDU>, DWING@UH01.Colorado.EDU (Dan Wing) writes:
> Eric J. Seeger, eseeger@ssdc.sterling.com, writes:
> 
>>Is there a way to boot up a MicroVAX 3400 running VMS V5.4 so that a
>>site specific definition can reside in a different UIC group instead of
>>the system accounts group.  More specifically, I am trying to define
>>several specific logicals that I want to have reside in a specific
>>accounts group table, and I want to define them during the startup procedure.
>>What I am finding is that even if I 'set uic' to the account I want them
>>to reside in they are still ending up under the system account during startup.
> 
> ...  Now, even if you pointed it to the correct logical name
> table, or specified the table's name with DEFINE/TABLE, it wouldn't work
> because the table doesn't exist.
>      

There is an easier way to create the group logical name table at startup.
Try the following...

    RUN /UIC=[<UIC in group>] SYS$SYSTEM:LOGINOUT.EXE

The group logical name table is created by the first run process in that
group. This does a process creation which does very little other than
create the logical name table. The UIC doesn't even have to be a valid
account, as long as it is in the correct group.

eg. JOE_SMITH has a UIC [LAZY_BUMS,JOE_SMITH] (or [3010,253]).

    To create his group logical name table, do a RUN/UIC=[LAZY_BUMS] ...
    or RUN/UIC=[3010] ...

    The group logical name table can be accessed via
    
        DEFINE/TABLE=LNM$GROUP_003010

The following is some code to determine from a NAME type UIC which group
table to use (i.e. How to get from [LAZY_BUMS] to LNM$GROUP_003010)

$!
$!***************************************************************************
$Get_Group_LNM_String:  SUBROUTINE
$!***************************************************************************
$!
$!      P1 == Specified Group
$!
$   SET NOON
$!
$   GroupString == "LNM$GROUP_000000"
$   UICIdent    =  F$IDENTIFIER("''P1'","NAME_TO_NUMBER")
$   UICString   =  F$FAO("!%U",UICIdent) - "[" - "]"
$   UICString   =  F$EXTRACT(0,F$LOCATE(",",UICString),UICString)
$   StringLen   =  F$LENGTH(GroupString) - F$LENGTH(UICString)
$   GroupString == "''F$EXTRACT(0,StringLen,GroupString)'''UICString'"
$!
$   EXIT
$   ENDSUBROUTINE

The subroutine could be called and logicals defined as follows:

$   CALL Get_Group_LNM_String "LAZY_BUMS"
$   DefLazyBums := "DEFINE/TABLE=''GroupString'"
$   DefLazyBums DECW$USER_DEFAULTS SYS$LOGIN:, LAZYBUMS_DATA:[DECW$DEFAULTS]

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rob Spencer, BHP Information Technology           |   Sorry, but my .sig
Newcastle, Australia        Voice: +61 49 40 1673 |   is on .sig leave!
Bits: robbie@winkle.bhpese.oz.au                  |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: richard@npri6.npri.com (Richard Head)
Newsgroups: vmsnet.internals
Subject: Re: MACRO32 vs. Alpha
Date: 25 Aug 92 18:29:22 GMT
Distribution: world
Organization: NPRI, Alexandria VA

MILLER@TGV.COM writes:

>SDA works fairly well.  Patch does not seem to have been ported yet.
>Both of those will understand Alpha opcodes instead of VAX.

I thought there wasn't going to be a Patch Utility, at least that wasn't
the intention.
-- 
richard@npri6.npri.com  <Richard Head>
I've fallen and I can't reach my beer!
From: gwlester@cpu.com (Gerald W. Lester)
Subject: Re: Exit handlers in VAX-C
Organization: Computerized Processes Unlimited, Metairie, LA, (504)-889-2784
Date: Mon, 31 Aug 1992 19:04:42 GMT
Reply-To: gwlester@cpu.com
Distribution: na

In article <la4fgtINNhs6@news.bbn.com>, mjensen@BBN.COM (Martin Jensen) writes:
>    Thank you O Gods of VMS for a prompt and satisfying response to my
>    earlier query!!  Now for the next question :-)
>
>    I'm trying to write an exit handler for a VMS program written in
>    VAX-C.  The various VMS manuals have left me a little confused as to
>    the calling conventions for exit handlers.
>
>    The Programming Resources Guide indicates that the exit handler
>    should be written as a subroutine - implying (in my mind anyway) that
>    the handler is called with a JSB and should return with a RSB.  Other
>    documents seem to indicate that the handler is called as a normal
>    procedure - implying (again, in my mind) that the handler is called
>    with a CALL(S,G) and should return with a RET instruction.
>

	It is invoked with CALL(S,G).  It should (must?) not return a value. 
Some writters equate subroutine with procedure vs function.  While I have never
written an exit handler in C, I have several in FORTRAN and Pascal.
From: SYSMGR@IPG.PH.KCL.AC.UK
Newsgroups: vmsnet.internals
Subject: re: PATCH on ALPHA ?
Date: Tue,  1 SEP 92 10:44:50 BST
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

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

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!

        Yours,
                Nigel Arnot

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



Newsgroups: vmsnet.internals
From: pettigrew@vertex.enet.dec.com (Mike Pettigrew)
Subject: Re: VMS Tuning
Organization: Digital Equipment Corporation
Date: 25 AUG 92 18:02:11    

> 
>One method I've used in the past is to take a new application, install it
>on the system, then set up an account with a massive WSEXTENT.  Run the app
>from this test account and see how high the page count goes.  If, like some
>s/w I've tested in this way, the app keeps eating pages up to the WSEXTENT
>value, revise the figure down and try again until you see a performance hit.
>Other s/w will peak at some figure, which can then be used as the WSEXTENT
>for users requiring that app (unless the figure is ridiculous, in which 
>case you revise it down to the performance hit mentioned above).
> 
>

Another method that works well is to use the SHOW PROCESS/CONTINUOUS command
on an active application, and observe the maximum virtual storage requirement
for the image.  This is a good approximation to what your WSEXTENT should be.
A minimal value will be one half the "typical" image virtual storage
requirement.


Most linked applications which I have studied  use 6,000 to 10,000 pages
per image.  8096 pages is a good starting range for WSEXTENT in such
accounts.


Most of the DCL commands use from 300 to 2,000 pages.  The VAX C 
compiler has a peak usage of about 25,000 pages for a 1000 line module
compilation.  A WSEXTENT of 25,000 pages is quite reasonable for such 
a development account and can cut compile times by 80%, as well as
improving overall system response.


As a fallback under heavy memory usage, WSQUOTA can be set to 
(0.8*memsize)/maxprocesscount, or or a minimum value of 512 pages.
WSDEFAULT must be set to a minimum value calculated by AUTOGEN,
usually around 300 pages.


If you have VMS 5.3 or later versions, you should consider raising the
parameter MPW_HILIMIT to one half of your total memory.  This almost
eliminates writes to the system page file, and thus improves system
response.  There is no real benefit to having more free memory than
is needed to start the next process.



>
>Your mileage may vary.
> 

Yes, it certainly will!

----------------------------------------------------------------------------
| -Mike Pettigrew        pettigrew_mi@ripple.enet.dec.com
|                        (206) 661-3032
|                        Digital Equipment Corporation 
|                        Federal Way, Washington, USA
|___________________________________________________________________________
|These opinions are mine and not necessarily my employer's
----------------------------------------------------------------------------
Newsgroups: vmsnet.internals
From: steve@hacker.UUCP (Stephen M. Youndt)
Subject: Re: Technical idiots
Reply-To: steve@hacker.UUCP (Stephen M. Youndt)
Organization: HaL Systems, Burke, VA
Date: Sat, 29 Aug 92 12:31:05 GMT

In article <1992Aug28.114155.979@beckman.com> dsroberts@beckman.com writes:
>Actually, I've been thinking about this for a few days, and while I agree that
>there is relatively little CONTENT to Hancocks presentations (I even attended
>his PSS when I was fairly new to DECUS, and came away knowing little more than
>I went into it with), I wonder if anyone could point out examples of him
>actually being consistantly WRONG.  Yes, his jokes are banal.  He displays a 
>real attitude that I would not desire in a consultant during his talks, but 
>what has he been wrong about?  What specifically makes him "technically 
>incompetent"?

I've listened to Bill a few times (when I'm looking for entertainment), and
I wouldn't say he's necessarily incompetent, but rather not as competent as
he and many others believe.

At DECUS most of his talks become extended sales pitches (without mentioning
$$$, of course :-), and the things he talks about aren't particularly
revolutionary or interesting.

At one time I was all excited about one of Network-1's projects as Mr.
Hancock was talking about a security monitor that builds profiles of
users and sets off alarms when a person acts outside his/her profile.
When I inquired about how he managed to profile the System Manager,
he replied that they hadn't, and that you should disable alarming on
accounts with system privs....  What the heck's the *point* of the
thing?!?  If you can't get any additional security for prived accounts,
it's pretty much useless.

Anyway, that's my opinion of Bill *and* his company.
 
>   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

Steve
-- 
Stephen M. Youndt  UUCP: uunet!hacker!steve  I-NET: steve%hacker@uunet.uu.net
=============================================================================
10201 Chase Commons Drive #106 * Burke, VA 22015      * Phone:  (703)978-6352
From: moeller@gwdgv1.dnet.gwdg.de (GWDGV1::MOELLER)
Newsgroups: vmsnet.internals
Subject: RE: re: PATCH on ALPHA ?
Date: 2 Sep 92 14:56:12 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

In reply to my original question about PATCH & similar things,
several people discussed this theme *only* in the view of a
software producer who might (or should not) distribute patches
instead of new images.

Is there no-one who shares my view as an end-user that the ability to
PATCH a distributed program has some value? I've come across a few
situations where I could rather easily "patch in" some feature
considered necessary at our site, but either there was no way
to convince the producer (e.g. DEC) that our problem was warranting
a change to their product, or their timescale was just *very* different
from ours (like many problems "submitted to VMS engineering").

Sure, patching data, or NOPping instructions does not absolutely
require a tool like MACRO32-level PATCH, but I'd rather not miss
*some* of its features (in particular the ability to extend
a program section).

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: GAVRON@VESTA.SUNQUEST.COM
Newsgroups: vmsnet.internals
Subject: more comments on competence...
Date: 27 Aug 92 16:22:57 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Date sent:  27-AUG-1992 09:21:12

From email [names stripped to protect the innocent]:
>
>In article <920826004543.5b3@VESTA.SUNQUEST.COM>, you write...
>>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.
>
>HAHAHAHAHAHAHAHAHAHAH!
>That's EXACTLY what me and another guy here have thought
>for years. Right-on-the-money. Bullseye! You probably WILL lose
>consulting $$$$ if this ever gets out because the gerber that dude
>doles out goes over real big with suits who sit around big shiny
>tables and pull the cash levers...

As for not reading any rags, how does one stay informed??  I'd rather
be informed by a talented journalist than a banal twit...

Ehud

--
Ehud Gavron        (EG76)
gavron@vesta.sunquest.com
"The world bores you when you're cool."
From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Subject: Re: Backup, VMB and the boot blockDIR/NEW
Organization: Curtin University of Technology
Date: Tue, 1 Sep 1992 13:17:25 GMT

In article <1992Aug31.195719.7207@cerritos.edu>, tanner@cerritos.edu writes:
> 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.
> 

It writes the LBN into the resored boot block.

> -Bruce
> -- 
> Bruce Tanner        (310) 860-2451 x 596    Tanner@Cerritos.EDU
> Cerritos College    Norwalk, CA
Newsgroups: vmsnet.internals
From: frank@rover.uchicago.edu (Frank - Hardware Hacker - Borger)
Subject: re: PATCH on ALPHA ?
News-Software: VAX/VMS VNEWS 1.41    
Reply-To: frank@rover.uchicago.edu
Organization: Joint Center for Radiation Therapy
Date: Wed, 2 Sep 1992 15:36:00 GMT

In article <1992Sep2.022201.1@sejnet.sunet.se>, ERIC@SEARN.SUNET.SE writes...
>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). ...
>I now need hours to
>do what I used to do in 5 minutes and reliability was MUCH better back then.

	Mercifully I'm not generally involved at this now, but I once was,
	in the early days of RSX on 11s. I remember one series of patches.

	Patch I		Reported to fix a problem that odd parity did not work
			right on a single line DC interface.

	Patch II	Fixed the problem that patch I fixed odd parity, but
			broke even parity.

	Patch III	Fixed the problem that patch II fixed even parity, but
			broke no parity.

	Point is, I soon developed an attitude that I had to become intimately
	involved with the workings of the operating system, so that I really
	understood what the problem was, and how the patch was going to fix it.
	(I also tended to stay a month or so behind patches, on purpose.)

	However, -sigh- due to the size and complexity, being intimate with VMS
	is much more of a job than with PDP11 systems, so perforce we must
	rely on the ability of the supplier. Caveat Emptor.

   Frank R. Borger - Physicist    __       Internet:  Frank@rover.uchicago.edu
Michael Reese - Univ. of Chicago |___      Phone : 312-791-8075 fax : 567-7455
  Center for Radiation Therapy   | |_) _   
    2929 South Ellis Avenue        | \|_)  I used to be Snow White, but I
    Chicago, Illinois 60616           |_)  drifted. Mae West
Newsgroups: vmsnet.internals,vmsnet.misc
From: reece@eco.twg.com (Reece R. Pollack)
Subject: Re: Exit handlers in VAX-C
Reply-To: reece@eco.twg.com (Reece R. Pollack)
Organization: The Wollongong Group (East Coast Operations)
Distribution: na
Date: Mon, 31 Aug 92 18:25:42 GMT


In article <la4fgtINNhs6@news.bbn.com>, mjensen@BBN.COM (Martin Jensen) writes:
|>    Thank you O Gods of VMS for a prompt and satisfying response to my
|>    earlier query!!  Now for the next question :-)
|>
|>    I'm trying to write an exit handler for a VMS program written in
|>    VAX-C.  The various VMS manuals have left me a little confused as to
|>    the calling conventions for exit handlers.
|>
|>    The Programming Resources Guide indicates that the exit handler
|>    should be written as a subroutine - implying (in my mind anyway) that
|>    the handler is called with a JSB and should return with a RSB.  Other
|>    documents seem to indicate that the handler is called as a normal
|>    procedure - implying (again, in my mind) that the handler is called
|>    with a CALL(S,G) and should return with a RET instruction.
|>
|>    As you can't write subroutines in C, this leaves me stuck with MACRO
|>    if the first case is true.  If the second case is true, I can code it
|>    in C and stick it in a shared library (which for various reasons is
|>    the preferable way to go!).
|>
|>    Any of you VMS gurus care to comment on the correct convention?

Exit handlers are called via the CALLG mechanism, specifying the 3rd
longword of the exit handler block (offset 8) as the start of the
argument list.

Make sure the argument block is not allocated on the stack or reused
before the exit handler is tripped, since it is the block you pass
to the $DCLEXH service which is used when calling the exit handler.

--
Reece R. Pollack
Senior Software Engineer
The Wollongong Group, Inc.
From: Hunter Goatley <goathunter@WKUVX1.BITNET>
Newsgroups: vmsnet.internals
Subject: RE: System Service to create users?
Date: Thu, 27 Aug 1992 17:10:59 EDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

"David Harrold, MSOE" <harrold@kirk.msoe.edu> writes:
>
>     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.
>
There's not.  The only way is to either use AUTHORIZE or do it
yourself using RMS.  We chose the latter for our home-grown account
creation software.

Hunter
------
Hunter Goatley, VMS Systems Programmer, Western Kentucky University
goathunter@WKUVX1.BITNET, 502-745-5251
From: eseeger@ssdc.UUCP (Eric Seeger)
Newsgroups: vmsnet.internals
Subject: Booting MicroVAX 3400 using non-system UIC
Date: 31 Aug 92 20:30:30 GMT
Organization: Sterling Software IMD, Vienna, Va.

I pose this question to all the VMS gurus on the net:

Is there a way to boot up a MicroVAX 3400 running VMS V5.4 so that a 
site specific definition can reside in a different UIC group instead of 
the system accounts group.  More specifically, I am trying to define 
several specific logicals that I want to have reside in a specific 
accounts group table, and I want to define them during the startup procedure.
What I am finding is that even if I 'set uic' to the account I want them 
to reside in they are still ending up under the system account during startup.

Is there some trick to doing this or is it just not possible to do this 
during startup because the system account at this point has full control.

I would welcome any helpful responses....
--

Eric J. Seeger				Phone:	(703)356-3551
8000 Towers Crescent Dr.		 UUCP:	uunet!ssdc!eseeger
Vienna, VA. 22182			 MAIL:  eseeger@ssdc.sterling.com
From: lbmoore@tchden.org (Louis B. Moore)
Newsgroups: vmsnet.internals
Subject: re: PATCH on ALPHA ?
Date: 2 Sep 92 13:30:02 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List


   Hunter writes...

> But it is true that improper use of PATCH can cause more problems than it
> solves.

Any tool in the hand of a good craftsman can work wonders.  The same tool in
the hand of a barbarian is a razor in a monkey's paw.  I leave it to the reader
to decide if they are craftsmen or barbarians.

Until a couple of years ago I was a Systems Programmer on IBM mainframes.  As
far as I can tell, IBM is slowly crushing Systems Programmers out of existance.

As the skill level of the customer's systems people goes down, (and they become
little more than glorified operators,) the more IBM can get away with.

If powerful tools like Patch are dropped, then it chips away at the customers
and third party software developers ability to modify the operating system to
their own requirements.   At the same time it strengthens (or attempts to
strengthen) the vendor's grip on their customers.

I assume that there are some technical reasons why patch is more difficult to
port, and this makes for an excuse to not port it.  Bad choice, in my opinion.


 Louis B. Moore                      Internet: lbmoore@tchden.org
 Systems Programmer                  Phone:    +1 303 837 2513
 The Children's Hospital of Denver   Denver, Colorado USA 80218

CyberGEEZER