HDTenEightyP/NetNews huggingface dataset:
From: tjs@world.std.com (Tim J Sylvester)
Subject: DECmcc EMS v1.2 on Ultrix
Summary: Too bad DECmcc EMS won't be on Ultrix
Keywords: DECmcc
Organization: The World Public Access UNIX, Brookline, MA
Date: Tue, 10 Nov 1992 02:35:03 GMT


Bill Gasman is the third DEC person who has told me that 
several components of DECmcc EMS will not be available on Ultrix.

I think this is a mistake.  The previous poster is a perfect example
of someone who would want to manage a DEC site with an Ultrix
workstation.  They probably have several DEC terminal servers
and a powerful DECstation that is a perfect platform to run
DECmcc but they can't use DECmcc EMS to manage their network
because some engineers at DEC can't image why anyone would want
to manage a Dec site with Ultrix.


Tim
Newsgroups: vmsnet.networks.management.decmcc
From: vaisanen@joyds2.joensuu.fi (Jarmo Vaisanen)
Subject: DEC MSU vs. DECmcc future?
Reply-To: vaisanen@joyds2.joensuu.fi (Jarmo Vaisanen)
Organization: University of Joensuu, Computer Center
Date: Wed, 11 Nov 1992 08:31:16 GMT


Hi!


I would like to get some comments on following.

I understand that DEC MSU is SNMP and DECnet IV manager and that it is
targeted at smaller installations. I happen to have v1.1 of MSU and the
future seems a little bit odd.  MSU requires INGRES but ULTRIX doesn't
any more include INGRES run time.  So I'm stuck with 4.2 (?)  What about
MSU 1.2 (1.x, 2.x) - is there such a thing any more in production lines?

Has DEC thought about some kind of product change from MSU to DECmcc
at lowered prices?  Or are we left on our own?


Jarmo

-----------------------------------------------------------------------
Jarmo Vaisanen          vaisanen@joyds2.Joensuu.FI      (Internet)
University of Joensuu   JVAISANEN@FINUJO                (EARN, BITNET)
Computer Center
Newsgroups: vmsnet.networks.management.decmcc
From: RBN@C3PO.RTPNC.EPA.GOV (Bob Boyd(919-541-4441))
Subject: RE: DECmcc use within Digital
Originator: server@ralph.rtpnc.epa.gov
Reply-To: <decmcc@ralph.rtpnc.epa.gov>
Organization: Environmental Protection Agency 
Date: Tue, 10 Nov 1992 19:29:28 GMT

Message created @ 10-NOV-1992 14:16:18.04

Wow!!! This is great -- I'm enjoying this posting.  I hope that
others on the list will consider posting something about how they
are using DECmcc in the near future.

Thanks Bill Gassman for posting it, and Brad Woodcock for putting
it together!


Bob Boyd	Unisys/EPA, RTP NC	919-541-4441
rbn@c3po.rtpnc.epa.gov
Newsgroups: vmsnet.networks.management.decmcc
From: JONAK%NETMAN@cebaf.gov
Subject: EMS V1.2 on Ultrix??
Originator: server@ralph.rtpnc.epa.gov
Reply-To: <decmcc@ralph.rtpnc.epa.gov>
Organization: Environmental Protection Agency 
Date: Mon, 9 Nov 1992 16:32:01 GMT

Is anybody running EMS version 1.2 on an Ultrix machine? I have the chance to
replace my VAXstation 3100 with a DECstation 5000, but our local sales rep
says that MCC is not available on Ultrix. I'm having a hard time believing it!!
Thanks in advance!


************* Keith Jonak
              Assist. Hardware Systems Manager
              Continuous Electron Beam Accelerator Facility
              Internet - jonak@cebaf.gov
              Voice - 804-249-7696
Newsgroups: vmsnet.networks.management.decmcc
From: Bill at MKO <gassman@skibum.enet.dec.com>
Subject: DEC MSU & DECmcc
Originator: server@ralph.rtpnc.epa.gov
Reply-To: <decmcc@ralph.rtpnc.epa.gov>
Organization: Environmental Protection Agency 
Date: Wed, 11 Nov 1992 14:41:10 GMT


	Re: Jarmo Vaisanen's note on MSU and DECmcc.

	A few weeks ago, at Interop, the next release of MSU was announced.
	As part of that announcement, it was stated that the required bits
	of INGRES will be packaged with the new release, so you will not
	be stuck with 4.2.  Version 1.3 will be shipping around February 93.
	Also, the new release is being renamed to POLYCENTER SNMP Manager as 
	part of a new naming convention.  All management products are being 
	gathered under the POLYCENTER banner, with the name reflecting "what 
	it does".  

	MSU (aka POLYCENTER SNMP Manager) is not just for small networks.
	With it's distributed polling and remote map access features, the
	product is rated for up to 10,000 devices.  At the recent Interop
	show, the new release was in the Shownet (TM) NOC and handling the 
	4000 or so device network quite well.  You will be happy with the
	new reports that are produced!

	As for lower prices - a new limited license for the next release
	will managed up to 100 devices for around $3000, and the unlimited
	license will remain at $7,070 (US country list price as of Nov 92).
	
	The DECmcc BMS (EMA based) software is $12,500 (US list 11/92).

	Please feel free to send me mail with any packaging ideas you
	may have for the DECmcc product (available on VMS and ULTRIX).
	
	regards...

	bill gassman
	digital network management
	product management/marketing
From: g_fierlbeck@decus.ch
Newsgroups: vmsnet.networks.management.decmcc
Subject: DECmcc/Expert Systems Shell
Date: 13 Nov 92 18:00:50 CET
Organization: DECUS (Switzerland)

Has anyone experimented with the implementation of a monitoring, diagnostics,
and effector system combining the features of MCC with an expert shell?
From: jlongcha@ulys.unil.ch
Newsgroups: vmsnet.networks.management.decmcc
Subject: unsubscribe jlongcha@ulys.unil.ch
Date: 12 Nov 92 07:32:07 GMT
Reply-To: <decmcc@ralph.rtpnc.epa.gov>
Organization: Environmental Protection Agency
Originator: server@ralph.rtpnc.epa.gov

unsubscribe jlongcha@ulys.unil.ch
Newsgroups: vmsnet.networks.management.decmcc
From: ccgavin@brolga.cc.uq.oz.au (Gavin Stone-Tolcher)
Subject: Font Problem with DEC MSU 1.1
Keywords: Font
Organization: Prentice Centre, University of Queensland
Date: Thu, 12 Nov 1992 00:02:13 GMT

The release notes for MSU 1.1 report a problem using 100DPI fonts on 
DECstation 5000 machines.

>When using a DECstation 5000, part of the window display may not
>be visible and some of the text-entry fields may be unreadable
>because they overlap.
>
>To eliminate overlapping, you need to reduce the font size from
>100 dpi resolution by using the 75 dpi font ULTRIX subset.

This problem can be overcome on most display devices by using a 75DPI fontset.
The DEC VXT2000 however loads 18 x 100DPI fonts in its' initial boot phase. 
These fonts are contained in the boot image for the terminal so making the
terminal use a 75 DPI fontset does not fix the problem. Starting the nms_map
application with a 75 DPi font specified ie: % nms_map -fn fontname does make 
the application use the specified font for some things but not others. Is there
any fix for this problem?


Cheers,
Gavin....

--
Internet: ccgavin@cc.uq.oz.au                         Phone: +61 7 365 3942 
  Postal: Gavin Stone-Tolcher, Network Management, The Prentice Centre
          The University of Queensland, QLD Australia 4072.
Newsgroups: vmsnet.networks.management.decmcc
Subject: Re: DEC MSU vs. DECmcc future?
From: brockie@golem.wcc.govt.nz (Roger Brockie)
Date: 13 Nov 1992 01:59:54 +1300
Organization: Wellington City Council, Wellington, NZ
NNTP-Posting-Host: golem.wcc.govt.nz

In article <1992Nov11.083116.18916@cs.joensuu.fi> vaisanen@joyds2.joensuu.fi (Jarmo Vaisanen) writes:
>...
>I understand that DEC MSU is SNMP and DECnet IV manager and that it is
>targeted at smaller installations. I happen to have v1.1 of MSU and the
>future seems a little bit odd.  MSU requires INGRES but ULTRIX doesn't
>any more include INGRES run time.  So I'm stuck with 4.2 (?)  What about
>MSU 1.2 (1.x, 2.x) - is there such a thing any more in production lines?

DECmcc has the same problem, it requires Ultrix/SQL.  After asking my sales 
being what the story was. He found out that Ultrix/sql (ingress/sql) will
be bundled with the next release of DECmcc.  But this is only for a limited
time (don't know how long) at which point DECmcc will be able to run with
the db of your choice.

DEC's arguement is they are giving us freedom by allowing us to choose the
db we want not the one they force on us.

My arguement is that at the moment I don't really care which db it uses.
I just don't want to be forced to pay for one in the future.

Roger


-- 
brockie@golem.wcc.govt.nz
From: skibum::gassman@enuf.enet.dec.com (Bill@MKO)
Newsgroups: vmsnet.networks.management.decmcc
Subject: RE: EMS V1.2 on Ultrix??
Date: 9 Nov 92 17:03:57 GMT
Reply-To: <decmcc@ralph.rtpnc.epa.gov>
Organization: Environmental Protection Agency
Originator: server@ralph.rtpnc.epa.gov


	In response to Keith Jonak's note about a DECmcc EMS package
	on ULTRIX, no, there is not one.  If you look at the EMS package
	as it exists today on VMS, it includes several legacy point 
	products that never have existed on ULTRIX, and probably never 
	will.  There is also the Terminal Server AM, which does not exist
	on ULTRIX.  The ELM (FDDI and Bridge) AM/FM package and TCP/IP
	diagnostic package ARE included in the EMS package on VMS, and
	these two options ARE available on ULTRIX.  However, for only
	two options, it was not felt appropriate to call it a "EMS" package
	in that it would create too much confusion.  As the product 
	matures, a EMS type of package will probably emerge on ULTRIX
	but for now, purchase the BMS package on ULTRIX, and add the
	ELM option if you need to manage Digital bridges/fddi equipment,
	and add the TCP/IP diagnostic assistant option if you wish to use
	it.  

	bill gassman
	network management product management
From: RON@LTUVAX.BITNET (Donley Computer Center)
Newsgroups: vmsnet.internals
Subject: DECUS gathering
Date: 9 Nov 92 10:54:38 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List


        I interrupt your regularly scheduled Macro list for the following
question - when we meet in the lobby of the Hilton at DECUS at 20:00 on
Monday, assuming that's still going on, how will members of the group be
identifiable?  (Who's wearing the white carnation?)  After all, I have no
idea how many people will be milling around the lobby at that time...

Ron
RON@LTUVAX.BITNET
From: bruce@ais.com (Bruce C. Wright)
Newsgroups: vmsnet.internals
Subject: Re: Dream extensions for MACRO-32
Date: 4 Nov 92 14:57:33 GMT
Organization: Applied Information Systems, Chapel Hill, NC

In article <1992Nov3.211427.21777@nntpd.lkg.dec.com>, critz@star.enet.dec.com (Richard Critz) writes:
> 
> In article <1992Nov3.093855.5816@ais.com>, bruce@ais.com (Bruce C. Wright) writes:
> |>I would be very skeptical about changes that, for example, hid the number
> |>of registers from the programmer, and inserted extra instructions to save
> |>and restore registers, etc -- I can forsee too many possible problems in
> |>driver-level code where you often have to use specific instruction types
> |>when you refer to device space, or where timing can be very important.
> [...] 
> 
> This has effectively already happened.  MACRO32 is a compiled language on
> OpenVMS AXP(tm)* (known in the real world as Alpha).  The compiler does all
> sorts of things behind your back including the allocation of scratch
> registers.  Some assumptions about stack layout and about where and how
> one can legally exit a routine which are valid on the VAX are not valid
> on the new architecture.

Yes, but we were talking about versions of MACRO32 for the VAX
architecture too.  And on that architecture there are some situations
where you have to be very careful about what you can do in device
space, particularly.

The same goes for the byte/word displacements, and for the I^ and S^
literals.

> |>But why bring this up now, when the VAX is almost history?  Some of us
> |>have wanted this type of thing for over 10 years, but DEC has never done
> |>anything about it.  I suspect that the problem is the typical DEC attitude
> |>of NIH (= Not Invented Here) -- a certain other competing operating system
> |>for the VAX has had this since forever.
> 
> If you read the original message again, you'll see that he brought it up
> in response to the fact that MACRO32 is a compiled language on OpenVMS AXP.
> To the original poster, it's still an assembled language on OpenVMS VAX and
> the assembler is in maintenance mode and has been for years.

This is a perfect example of exactly what I was saying -- DEC is not
interested in listening to what customers want, nor in what anyone
outside of DEC has done.

It pains me to say it since I've been working with DEC gear for over
15 years, but with an attitude like that you deserve to lose.

Bruce C. Wright
From: DEREK@U.WASHINGTON.EDU
Newsgroups: vmsnet.internals
Subject: Re: What does AXP stand for ...
Date: Thu, 5 Nov 92 08:44 PDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

>What does AXP stand for in `OpenVMS AXP (Alpha)'?
>
>        ----------------------------------------------------------------
>        Tarif Halabi, Crowntek Business Centers, Toronto, Ontario
>        xbrix.uucp!thalabi or thalabi@xbrix.uucp
>        psi%302043800069::thalabi
>        +1 416 507-5070

The story I heard from our local account manager is:

        "It doesn't stand for anything.  That's why it was used!"

Something about problems with trademarks.  Anyway, I believe he said that
that there is going to be some sort of a contest to "name the Alpha", and
come up with a meaning for AXP.

PS.
Have you heard about the Ada implementation?  Ada is not like any of the
other languages under VMS.  The command structure is similar to the
"SET something" commands.  "ACS COMPILE", "ACS LINK", etc..  (I don't
know these anymore.)  Anyway, "ACS" has some "official meaning" which
does NOT use the initials "A.C.S.".  As I heard it, ACS originally stood
for "Ada Control System", but that that name was dropped.  Kind of like
STARLET....   Anyway, this all leads me to think that AXP *DOES* have some
meaning -- at least, unofficially.


-Derek S. Haining
 University Computing Services
 University of Washington
 Seattle, Washington  98195
 (206) 543-5579

 DEREK@MAX.BITNET
 DEREK@MAX.U.WASHINGTON.EDU
From: DWING@UH01.Colorado.EDU (would rather be skiing ...)
Newsgroups: vmsnet.internals
Subject: Re: re:... idle terminals
Date: 10 Nov 92 23:44:36 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Stafford@Vax2.Winona.MSUS.EDU, writes:

>If FORCEX is not an issue, I cannot see why this is such a complex
>problem.  We have an elementary DCL procedure servering as a good
>idle process killer.  It can make execeptions based upon username,
>group, terminal, job and kill from the top down, protect system jobs, have
>on-off hour times for certain kills, most of the good stuff.

The examples on this list were how to AVOID getting terminated, not how to
write an idle process terminator.

>Elementary
>
>        create Indexed file
>        Loop:
>        wait n unless first iteration (the max idle time)
>        Get PID and process info
>        Process exemptions
>        Append padded USERNAME to F$TIME()
>        Check Indexed file - does this key exist?
>                if it does then the job has been idle for n minutes.
>                                KILL it.
>                if it does not exist, then Put this as a KEY to Indexed file
>        repeat Loop

Cute.  But, remember, this is the MACRO32 list.  And $FORCEX is very important
to ensure proper image rundown.  There are usually two reasons for idle
process killers:

  o security
  o reduce consumption of resources by idle processes

Your DCL procedure probably consumes more resources than you would save by
killing a few idle processes.

The program WATCHER, written by Matt Madison, provides all of your features
and lots more, does a $FORCEX before killing the process, and hardly consumes
any CPU time at all.  It's free.

-Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11)
 Systems Administrator, University Hospital, Denver
From: "GWDGV1::MOELLER" <moeller@gwdgv1.dnet.gwdg.de>
Newsgroups: vmsnet.internals
Subject: RE: Tape driver probs.
Date: Thu, 12 Nov 1992 12:19:17 +0100
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

<dave@chmeds.ac.nz> writes:
> We have a non DEC tape drive on our unibus vax. It used to work well (VMS 4.x)
> but has fallen into disuse.
>
> We wish to start reusing it VMS 5.4
> but it does funny things when being written to.
>
> The unit inits and mounts OK but when a file is copied to the drive it
> reads forward until it falls off the feed spool.

Does that tape drive come with a special driver?

If so, you need a driver adapted to the change of end-of-volume detection
which was introduced in VMS 5.4 .

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: vmsnet.internals
Subject: odd XQP behaviour
From: SYSMGR@IPG.PH.KCL.AC.UK
Date: Thu,  5 NOV 92 16:06:43 BST
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Some of you may have noticed my recent posting to info-vax about VMS failing
to allocate a pagefile on a slightly fragmented disk, and what to do about
it. For those who didn't, the problem was that SYSGEN CREATE was failing to
allocate an 80000 block pagefile on a disk with around 200000 blocks free
in fragments of size over 6000 blocks. What it was doing was building a
file out of about four decent-sised fragments, and then filling the header
with all sorts of mostly tiny fragments presumably out of the extent cache.

If you used sysgen ten times, creating the pagefile with size 8000, then
extending it to 16000, 24000, ... 80000, then there were no problems and
it allocated 19 extents all of a decent size. (Sys managers - REMEMBER THIS!!)

I have now found another funny: the same problem in reverse. A user ran
a FORTRAN program that generates two output files: the first stays small,
the second ends up at around 3000 blocks, both are opened 'NEW' (ie empty)
and filled with sequential writes.

Recently he noticed that the first file had been allocated with an initial
size of 6000+ blocks. This was about two-thirds of his available disk quota,
and also would have doomed the job (after a couple of days' crunching) because
the second file would have run out of quota to grow into. I gave him more
quota to avoid this, and the first file got truncated to about 20 blocks
when the job finished.  I have never seen anything like this before VMS 5.5.

Does anyone *know* whether these behaviours constitute a bug or a feature?
(please, no *opinions*, that'll just waste bandwidth). Ideally, the question
will be answerted by someone who has read the XQP listings!

In addition, are there any experts on file structures out there who can
tell me whether there is any good reason why the XQP doesn't refuse to use
extents whose size is totally wrong with respect to the size of the file
being extended? In the first instance, it knows that the file wanted is
80000 blocks. In the second, there is presumably no size indication, or
perhaps a default such as the volume default extension quantity, which is
nowhere near 6000 blocks.

        Yours,
                Nigel Arnot

                NRA%ipg.ph.kcl.ac.uk@nsfnet-relay.ac.uk   (internet)
                NRA%uk.ac.kcl.ph.ipg@ukacrl.bitnet        (bitnet)
From: xbrix!thalabi@csri.toronto.edu
Newsgroups: vmsnet.internals
Subject: What does AXP stand for ...
Date: Thu, 5 Nov 1992 10:19:56 -0500
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

What does AXP stand for in `OpenVMS AXP (Alpha)'?

        ----------------------------------------------------------------
        Tarif Halabi, Crowntek Business Centers, Toronto, Ontario
        xbrix.uucp!thalabi or thalabi@xbrix.uucp
        psi%302043800069::thalabi
        +1 416 507-5070
From: gleason@mwk.uucp
Newsgroups: vmsnet.internals
Subject: Re: Dream extensions for MACRO-32
Date: 6 Nov 92 08:53:42 CST
Organization: M. W. Kellogg, Houston TX



  Here's another extension that I think would look good in an
extension to MACRO-32 on Alphen...much larger bit fields
for the bit field operations. 

  If they were about a disk block (or even larger, a memory page,
however big that gets to be) I could dispense with a lot of
loops when using FFS and FFC. In like wise, it would be easier to
manipulate bit strings arbitrarily with INSV and EXTV.

Lee K. Gleason N5ZMR
Control-G Consultants
gleason@mwk.uucp
Newsgroups: vmsnet.internals
Subject: RE: dream extensions for MACRO-32
From: jeh@cmkrnl.com
Date: 6 Nov 92 10:31:40 PST
Organization: Kernel Mode Consulting, San Diego, CA

In article <9211041447.AA27426@sndsu1.sinet.slb.com>, brydon@dsn.sinet.slb.com writes:
> I would also like to see DEC consider addition of the concept of a DSECT, as
> implemented in other assembler languages.  This is a data structure that
> doesn't create any storage, just defines a family off offsets, like a struct
> in C.

Fixed in a previous release. :-)  See the $DEFINI, $DEF, $EQU, $DEFEND, $VIELD,
and _VIELD macros.  These use a .psect with the ABS attribute.  They're
documented in the _Device Support_ manuals but usable in any Macro code, not
just device drivers.

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
drivers, internals, networks, applications, and training for VMS and Windows-NT
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: brydon@dsn.sinet.slb.com
Newsgroups: vmsnet.internals
Subject: Assembler wishlist
Date: Wed, 4 Nov 92 23:42:25 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

From:   BRYDON@PSI%DSN@MRGATE@SNDRTR
To:     "macro32@wkuvx1.bitnet"@M_INTERNET@MRGATE@SNDRTR@SNDRTR

Derek S. Haining (DEREK@MAX.U.WASHINGTON.EDU) says:
>>        .dsect  x
>>flink:  .long
>>blink:  .long
>>data:   .blkl   n
>>bits:   .byte
>>...
>
>I have seen this already done -- with a .PSECT $$ABS$$ declaration.  Notice
>that this PSECT is based at address '00000000', and so basically generates
>offsets.  Also, you can use the "BLINK = 4" construct to accomplish this.

Yes, but if you do the first trick with the $$ABS$$ stuff, aren't you really
generating 'real' storage allocation?  Also, this restricts you to one DSECT,
unless you do assembler directives like '.=0' repeatedly.

For the second case of "BLINK = 4", of course you can do this.  But it is the
programmer's responsibility to know that a longword is 4 bytes, and to get all
the offsets correct (trivial for this example, but a bit more hairy in a large
program).  This is largely a  clerical task that can and should be taken care
of by the assembler.  Also, a data type change of one variable in the middle
of your struct/dsect causes all following offset values to change.  This
currently has to be done manually, should be done by the assembler.

A DSECT directive is trivial to implement in compiler/assembler construction
and saves an awful lot of programming effort.  I think it also makes more
appealing and maintainable code as well.
_______________________________________________________________
Harvey Brydon         | Internet:   brydon@dsn.SINet.slb.com
Dowell Schlumberger   | P.O.T.S.:   (918)250-4312
            No main(), no brain
Xref: sparky vmsnet.internals:1570 comp.os.vms:17679