HDTenEightyP/NetNews huggingface dataset:
From: tate@faxcsl.dcrt.nih.gov
Subject: Re: C++ compiler for VMS
Organization: National Institutes of Health
Date: Fri, 10 Apr 1992 14:25:23 GMT

In article <ku94heINN5lf@news.bbn.com> brosen@BBN.COM (Bruce L. Rosen) writes:
>We'd like to get hold of a reliable and supported C++ compiler for
>use under VMS.  I'd appreciate any suggestions/recommendations.
>
>Bruce Rosen (brosen@bbn.com)
>BBN Software Products
>
So would we, Bruce, but not for lack of trying! We have used both the OASYS/
Glockenspiel and the Oregon Software/TauMetrics compilers (versions 1.2 and
2.0/2.1.2.1.2.1beta) with widely varying results. The OASYS "compiler" is
(or was when we stopped using it last year) actually a pre-compiler, emitting
C code which is then compiled via the VAX C compiler, etc. Version 1.2 did
work, but the performance in our application was abysmal, especially I/O. We
switched to the "Oregon Software" compiler (a true one) and found that what
had once compiled no longer did. In fact, TauMetrics, the actual source of
the product, has now taken it over from Oregon. We are currently (as of
yesterday!) attempting to use V2.1.2.1 beta, but still having problems, the
nature of which are too complicated to reiterate here. The bottom line is
that (a) there doesn't seem to be a fully functional AT&T compatible product
out there yet, and (b) it is/will be a moving target until there is a true
standard established. I'll be glad to keep this group apprized of progress.

NOTE: these are strictly my opinions, and do not reflect in any way the
      views of my employer (should he/she/it have any...)
========================================================================
Ramon L. Tate                                   tate@faxcsl.dcrt.nih.gov
Computer Systems Laboratory, DCRT
National Institutes of Health, Bethesda, MD 20892
"When you are in it up to your ears, keep your mouth shut."
From: quodling@ltnup.enet.dec.com
Newsgroups: comp.os.vms
Subject: Re: Using non-Decwindows Debugger on Decwindows/Motif Terminal Window
Date: 8 Apr 92 23:08:19 GMT
Organization: PC/PCI Appl Group

In article <8APR199209263207@wctdpv.gd.com>, yates@wctdpv.gd.com (Jeff Yates (619)547-4726) writes:
> Does anyone know how to force VMS to use the Non-Decwindows/Motif Debugger 
> while being started from a such a terminal window?  I use a VT-1200 which 

Include

$ define dbg$decw$display " " 

in your login.com

-- 
Peter Quodling		         Internet:     quodling@creatv.enet.dec.com
System Management Group          UUCP: ...!decwrl!creatv.enet!quodling
PC/PCI Applications              Phone: (508) 486 6177          _--_|\
Digital Equipment Corporation                                  /Aussie\
LTN2-1/109                                                     \_.--._/
                                 I Said it, not them                 v
Newsgroups: comp.os.vms
Subject: Re: Backup problem with TTI 8mm tape drive
From: Mariusz@fbits.ttank.com (Mariusz Stanczak)
Date: 7 Apr 92 08:03:36 GMT
Distribution: usa
Organization: Forth Bits, Los Angeles, USA
Keywords: 8mm,backup

In article <5266@npri6.npri.com> richard@npri6.npri.com (Richard Head) writes:
>For the past 3 years, we have experienced the following problem with
>our 8mm tape:  If an error occurs (usually because the disk is no
>longer available), that backup command will fail, but subsequent backup
>commands to the same tape will also fail with a "Fatal Controller Error,
>error positioning...".   An example is included.
[...]
>Also, has anyone experienced this problem with their 8mm drives?  The drive
>we have is a TTI (Transitional Technology) CTS-8, on a MicroVAX 3400 with
Yes, but this is not limited to drives from TTI (I've used theirs and Sumus)
but seems to be with the Exabyte SCSI I/F.  As our experince with using the
8mm drives increased, the problems disappeared.  The main thing is not to
put the hardware in odd states (incomplete sequence of commands as in initia-
ting a BACKUP and aborting it would do it).  If it so should happen, cycling
the power on the drive sometimes lets you recover, otherwise booting (to re-
init the controller) the system is the only thing to do.  TTI has been very
good in working with us (we (OSM/EOTA) were one of the first users of their
drives) on ironing out wrinkles, and at one time there was a mention of a
dynamically loadable driver (which would help to init the controller without
booting the system... an unacceptable "solution" in many environments), but
before that happened we worked out all our problems and haven't seen any for
years.

-Mariusz
-- 
INET: Mariusz@fbits.ttank.com
UUCP: ..!uunet!longbow!ttank!fbits!Mariusz
From: j_manning@csc32.enet.dec.com (John Manning)
Newsgroups: comp.os.vms
Subject: Re: VMS 5.5 SERVE_ERR on bootup
Date: 10 Apr 92 20:25:48 GMT
Organization: Digital Equipment Corporation


In article <1992Apr9.204343.14999@ncar.ucar.edu>, pack@acd.acd.ucar.edu (Daniel Packman) writes...
>After updating from VMS 5.4-3 to 5.5 I see a new error message on
>bootup ... SERVE_ERR error serving device MUA0: R0 status=84
>I get two such complaints, one for each of the two tape drives
>on an attached unibus.  After bootup, these two tape drives are
>operational and all seems well.  The Grey Wall says "A newly discovered
>device that fits all the serving parameters could not be served....
>the device was not served because the server is not loaded"
> 
>It seems that the criteria for determining whether a device is served
>or not has changed.  These are not served devices.  Any suggestions?
> 
>--
>Dan Packman     NCAR                             INTERNET: pack@ncar.UCAR.EDU
>(303) 497-1427  P.O. Box 3000
>                Boulder, CO  80307-3000      DECNET  SPAN: 9583::PACK




VMS 5.5 added the ability to serve certain types of tape drives clusterwide.  
A new sysgen parameter, TMSCP_LOAD, controls this new function.  The 5.5 kits
shipped with TMSCP_LOAD set to 1.  If you are not in a cluster environment or
you have tape drives that are not serveable, then you will get this error at 
boot time.  Set TMSCP_LOAD to 0 to prevent VMS from loading the tape server
software or just ignore the errors.




--------------------------------------------------------------------------------
|                                       |  Rudy's on a train to nowhere,       |
|    John Manning                       |  halfway down the line.              |
|    j_manning@csc32.enet.dec.com       |                                      |
|                                       | "Rudy", Crime of the Century         |
|                                       |         Supertramp                   |
--------------------------------------------------------------------------------
From: ZINSER@DDAGSI5.BITNET
Newsgroups: comp.os.vms
Subject: Re: two decwindows questions
Date: 3 Apr 92 08:00:00 GMT
Organization: The Internet

> <EDU%"mtxinu!sybase!jym@UCBVAX.BERKELEY.EDU"      "Jym Dyer"> writes:
>=o= I generally predicate my checks on the presence of a
>DECW$DISPLAY logical name.  This isn't bulletproof either,
>since a malicious user could define such a logical name by
>hand.  The ideal solution would be a lexical function that
>retrieves the info one gets from the SHOW DISPLAY command.
>I imagine this would be added to f$environment(), but maybe
>it should be added to sys$getdvi() (and thus f$getdvi()).
>    <_Jym_>

I posted a similar question a while ago here and several people pointed
me to the undocumented DCL command SHOW DISPLAY/SYMBOL, which gives you the
Information you want in handy symbols. Below an example how you can use this:
$!
$ OUT = F$trnlnm("SYS$OUTPUT")
$ DEFINE/USER SYS$OUTPUT NL:
$ SHOW DISPLAY/SYMBOL
$ DEFINE/USER SYS$OUTPUT 'OUT'
$ IF $STATUS
$ THEN
$   HOST = DECW$DISPLAY_NODE
$ ELSE
$   WRITE SYS$OUTPUT "SHOW DISP ERROR GETTING DISPLAY NODE"
$   GOTO END
$ ENDIF
Hope this helps.

                                Regards, Martin

* Martin P.J. Zinser                       Email: ddagsi5 (Bitnet)
* KP II                                           vipmzs.physik.uni-mainz.de
* Gesellschaft f. Schwerionenforschung GSI        vzdmze.zdv.uni-mainz.de
* Postfach 11 05 52
* D-6100 Darmstadt 11                      Voice: 06151/359789


Newsgroups: comp.os.vms
From: tihor@acf3.NYU.EDU (Stephen Tihor)
Subject: Re: vms scripts?
Organization: New York University
Date: Sat, 11 Apr 1992 21:56:00 GMT

The various photo packages (original PHOTO, JOBLOG, the Supervisor Series, etc)
all address that need as do their commercial versions.
From: JLW@PSULIAS.BITNET ("J.Lance Wilkinson,  865-1818", 814)
Newsgroups: comp.os.vms
Subject: Jeff Diewald's comments Re: Debugger problem....
Date: 6 Apr 92 18:05:00 GMT
Distribution: world
Organization: The Internet

>PSULCS::INFO_VAX "Jeff M. Diewald <pa.dec.com!nntpd" 34 lines   6-APR-1992 12:0
   2
>         -< Re: Debugger problem, VMS 5.5, VWS4.3 & DECwindows/Motif >-
>-------------------------------------------------------------------------------
   -
>>
>> Does anyone out there know if there is/was any substance to the rumor that
>> the debugger was going back to a single window (instead of three) ??
>>
>
>   We've completely rewritten the Debugger user interface in light of all
>the feedback we got about the problems.
>
        ... [ Various Enticing and Exciting Items Omitted ] ...
>
>  In short - if you've turned off the DECwindows interface in the past because
>it was unusable, check out the new and improved debugger when it's available
>in your area.  I think you'll like the changes.
>
>                                                Jeff Diewald
>                                                Debug developer
>
Gee, thanks for getting us all excited, Jeff.  Unfortunately it seems
(according to a Digital *internal debugger notes conference* that my local
DEC rep just checked for me) this new, improved interface is scheduled for
`some future release *after* VMS v5.5-2.' so it sounds like it'll be a while
before it's available in anybody's area.  Guess I'll need more newspaper for
the floor here; got all excited about this and now I've got to wait longer.

+---------------------------------------------------------------------------+
| J.Lance Wilkinson ("Lance")            BitNet:    JLW@PSULIAS.BITNET      |
| Systems Design Specialist - Lead       InterNet:  <not yet>               |
| Library Computing Services             AT&T:      (814) 865-1818          |
| E8 Pattee Library                      "I'd rather be dancing..."         |
| Penn State University         A host is a host from coast to coast,       |
| University Park, PA 16802     And no one will talk to a host that's close |
| <POSTMAST@PSULIAS.BITNET>     Unless the host that isn't close            |
| <POSTMAST@PSUCES.BITNET>      Is busy, hung or dead.                      |
+-"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+

Newsgroups: comp.os.vms
From: mako@uihepa.hep.uiuc.edu ("Makoto Shimojima, Univ of Tsukuba/CDF")
Subject: Re: Setting ICON and window titles on VT1200's
Reply-To: mako@uihepa.hep.uiuc.edu
Organization: High Energy Physics, University of Illinois, Urbana-Champaign
Date: Wed, 15 Apr 1992 22:49:43 GMT

> If I set host or telnet to another VMS node, my icon updates itself to the new
> nodename. But when I logout and return to the originating node the icon, of
> course, doesn't change.

SET_HOST :== @SYS$LOGIN:SET_HOST	! for example

where SYS$LOGIN:SET_HOST.COM is something like the following:

$! SYS$LOGIN:SET_HOST.COM
$ IF P1 .EQS. "" THEN $ GOTO Exit	! or do whatever you like
$ SET HOST 'P1'
$ @ICON.COM
$ Exit:
					mako
--
Makoto Shimojima

 Location    DECnet/ESnet  Bitnet         Internet
 UoTsukuba:  UTKBP::MAKO   -N/A-          mako%utkbp.dnet@kekux.kek.jp
 KEK:        KEKVAX::MAKO  MAKO@JPNKEKVX  mako@kekvax.kek.jp
>UoIllinois: UIHEP::MAKO   MAKO@UIUCHEPG  mako@uihepa.hep.uiuc.edu
 Fermilab:   FNAL::MAKO    MAKO@FNAL      mako@fnal.fnal.gov
Newsgroups: comp.os.vms
From: robert@triton.jpl.nasa.gov (Robert Angelino)
Subject: Motif DecWindows Locking up on overloaded systems...
Reply-To: robert@triton.Jpl.Nasa.Gov
Organization: Jet Propulsion Laboratory, Pasadena CA
Date: Thu, 9 Apr 1992 17:27:02 GMT

Gurus,
	Has anyone been experiencing this??  If so has anyone found a
solution??  We have a cluster of three 6000s with about 60-70 terminals
(vt1200).  lately (when they put motif decwindows on) the system has
slowed down to a screaching halt.  The OS version is 5.4-3, the motif
version is DECWINDOWS/MOTIF- V1.0.  What usually happens is the process
(the window manager) goes into a MUTEX state (I don't know what this is??)
and the screen locks up and I have to power cycle the vt1200.
When I log back in, the set of processes I thought I nuked are still
there and I can't kill them.

Any suggestions are welcome and appreciated.
-- 
    -     ------       -                              Robert Angelino
   | |   | ----  \    | |                             ms T-1704L
   | |   | |   \ |    | |                             4800 Oak Grove Drive
   | |   | | --  |    | |                             Pasadena, CA 91109
---| |   | | \__/     | |___                          robert@triton.jpl.nasa.gov
\____|et |_|ropulsion |_____\aboratory                (818) 354-9574
From: massey@travis.llnl.gov
Newsgroups: comp.os.vms
Subject: 3 Motif Questions
Date: 13 Apr 92 18:34:18 GMT
Organization: Lawrence Livermore National Laboratory

Does anyone know why I cannot do a cut/paste from/to a pair of Motif windows,
one being local to the workstation that I'm at, the other belonging to a 
remote machine (created with "Set Display/Create/Node" & "Create/Term/Detached
/Window"). This worked before I switched to Motif.

The program from mdchaney@iubacs to reposition the login box under Decwindows 
does not appear to work under Motif. Does anyone have a program that does or 
know how to fix Darrin's?

How can I influence the class/types of messages that the Motif message window 
displays? 


\/\/./\/./\/\.\/\/./\/./\/\.\/\/./\/./\/\.\/\/./\/./\/\.\/\/./\/./\/\.
Warren N. Massey
Lawrence Livermore National Laboratory
P.O. Box 808, L-495
Livermore, Calif. 94550
(510)422-1958

Massey@Travis.LLNL.Gov
\/\/./\/./\/\.\/\/./\/./\/\.\/\/./\/./\/\.\/\/./\/./\/\.\/\/./\/./\/\.
From: byron@yogi.hsc.ucalgary.ca
Newsgroups: comp.os.vms
Subject: SUMMARY: ACLs and file ownership
Date: 11 Apr 92 15:37:43 GMT

A while back I asked:
>I've setup a "common" directory with an ACL that provides access to a
>group of users, each with the appropriate identifier, as follows:
>
>COMMON.DIR;1
>          (IDENTIFIER=IDX,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE+DELETE)
>          (IDENTIFIER=IDX,ACCESS=READ+WRITE+EXECUTE+DELETE)
>
>All works well, except I need to have all files created in this directory
>(and all subdirectories) to have the same owner as the common directory.
>Currently files created in this common directory are owned by whichever user
>actually created the file. Is there anyway to setup an ACE (or anything else)
>that will do this automatically?  None of the users have privs to set the
>files ownership by themselves.  Thanks in advance for any pointers.

I received 5 replies via mail.  The solution is to make the identifier a
RESOURCE id, then grant it as such to each user.  Set each file/directory
to be owned the the resource identifier and you are on your way.  I've
summarized all responses and can mail the file to anyone who is interested.

Special thanks to the following for pointing me in the right direction!

FLOWERS@memstvx1.memst.edu
BRENDAN@otago.ac.nz
LAURI@fndcd.fnal.gov
VAXS09@v7.vitro.com
D_North@onDEC.lonestar.org

:byron
________________________________________________________________________
Byron Draudson, Systems Manager               byron@yogi.hsc.ucalgary.ca
Radiology, Foothills Hospital, Calgary, Alberta, Canada   (403) 670-2442
From: mark@mivax.mc.duke.edu (MARK)
Newsgroups: comp.os.vms
Subject: UCX 1.3/VMS 5.5 quota problem?
Date: 7 Apr 92 20:02:00 GMT
Organization: Duke University Medical Center
News-Software: VAX/VMS VNEWS 1.41

I have recently upgraded a VAX 6210 from VMS 5.4-2 to 5.5.  In addition I
installed UCX 1.3.  After testing TELNET and FTP to and from the VAX I 
concluded the installation was complete and intact.  (By the way, i added
342,000 to NPAGEDYN and NPAGEVIR in MODPARAMS, AUTOGENed, and rebooted as
the UCX installation guide suggested. 

I am now seeing the following message on the operator's console when a 
network user attempts to login to the VAX using TELNET:

Message from user INTERnet on VAX
INTERnet ACP Remote TTY Request Aborted Status = "SYSTEM-F_EXQUOTA"


This behavior seems to occur after 6 or 8 other users have successfully 
TELNETed to this VAX.

I am interested in figuring out what quota is being exceeded and what process
is exceeding it - the user TELNETing in or the host system UCX software?

Have tried without success to get DEC software support to return a call so far
and thought someone out there might have experienced the same situation.
Thanks.
From: dittman@skitzo.dseg.ti.com (Eric Dittman)
Newsgroups: comp.os.vms
Subject: Re: Error starting clients in Motif 1.0A
Date: 16 Apr 92 18:14:31 CDT
Organization: Texas Instruments Component Test Facility

In article <1992Apr15.093021.476@skitzo.dseg.ti.com>, dittman@skitzo.dseg.ti.com (Eric Dittman) writes:
> In article <1992Apr15.034208.2636@spcvxb.spc.edu>, terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes:
>> In article <1992Apr14.200033.475@skitzo.dseg.ti.com>, dittman@skitzo.dseg.ti.com (Eric Dittman) writes:
>>> When I select a new application from the Session Manager Application
>>> menu under Motif 1.0A, I get the following message when I look at the
>>> output from "Work in Progress":
>>> 
>>> %DCL-W-PARMDEL, invalid parameter delimiter - check use of special characters
>>> \;EXT_21_2\
>>> 
>>> I have no idea where this is coming from.  I've looked everywhere for this
>>> string.
>> 
>>   It's some brain damage somewhere. I actually searched the whole ssytem disk
>> for this once in a vain attempt to stomp it. After I applied the 1.0A update
>> the quantity of these went _way_ down, though. Are you sure you've really got
>> 1.0A installed?
> 
> Yes, 1.0A has been installed.  I could always install it again to make
> sure, though.

I installed the 1.0A update again, and the problem is gone, so I must
have NOT installed it when I thought I did.
-- 
Eric Dittman                  Texas Instruments - Component Test Facility
dittman@skitzo.dseg.ti.com    (214) 578-3575
Disclaimer:  Not even my opinions.  I found them by the side of the road.
From: imhw400@indyvax.iupui.edu
Newsgroups: comp.os.vms
Subject: Re: UCX TCP/IP
Date: 9 Apr 92 08:59:14 -0500
Distribution: world

In article <A3319E3EE040357A@SNYMORVA.BITNET>, DREWWE@snymorva.BITNET (Bill Drew -- Serials Librarian) writes:
> Can anyone tell me why UCX TCP/IP does not have a TN3270 capability?

Because UCX V1 was designed, it seems, to provide NFS service and only such
other tools as might be useful in setting up NFS.  Some time after it was
released, DEC noticed that thousands of sites were demanding to know why UCX
wasn't a full-function IP product suite, and eventually they decided to do
something about it.  The something is UCX V2, coming soon or so they say.  But
I dunno whether it will have TN3270 even yet.
-- 
Mark H. Wood, Lead Analyst/Programmer    +1 317 274 0749   [@disclaimer@]
Internet:  IMHW400@INDYVAX.IUPUI.EDU     BITNET:  IMHW400@INDYVAX
Celebrate freedom:  read a banned newsgroup.
Newsgroups: comp.os.vms
From: tihor@acf3.NYU.EDU (Stephen Tihor)
Subject: Re: C++ compiler for VMS
Organization: New York University
Date: Sat, 11 Apr 1992 22:39:00 GMT

YOu might want to talk to your DEC salesrep about DEC's C++ plans and status.
From: rubin@visual1.jhuapl.edu (Don Rubin)
Newsgroups: comp.os.vms
Subject: Re: Setting ICON and window titles on VT1200's
Date: 16 Apr 92 17:06:20 GMT
Reply-To: rubin@visual1.jhuapl.edu (Don Rubin)
Organization: Johns Hopkins University

Matt Holdrege writes:

Is there any way to kick off a command procedure upon returning from a 
CTERM or TELNET session?

Yes, I do this all the time. Simply create a command file to
call TELNET or SET HOST and in the com file call your code
that updates the window title. Then make a foreign command
out of your com file, eg.

$ MYTELNET :== @sys$login:mytelnet.com

$create mytelnet.com
$telnet 'p1
$@update_window_title
^Z

You get the idea.
-- 
Don Rubin, Consultant
Johns Hopkins University APL
rubin@procon.jhuapl.edu
(301)953-6386 or (301)588-8010
Newsgroups: comp.os.vms
Subject: How to tell DIALUP from DCL?
From: cctr127@csc.canterbury.ac.nz (Jason Haar, Network Consultant, CSC)
Date: 15 Apr 92 12:53:20 +1200
Organization: University of Canterbury, Christchurch, New Zealand


Can you figure out whether an account has dialup access from the command-line
(e.g. via lexicals)?

The story is, we want to move our modems off our VAX onto a terminal server -
but we want to still use the DIALUP access bit in the UAF to decide whether to
let the user actually log in. What we'd do is get SYLOGIN to check to see if
the terminal server is the modem one, and then see if the user has DIALUP
access. I realise we could create an Identifier to do this with - but it would
require extra work ;-))

We run VMS V5.3-1

Cheers

Jason Haar
From: robin@lsl.co.uk (Robin Fairbairns)
Newsgroups: comp.os.vms
Subject: Re: SMG$ENABLE_UNSOLICITED_INPUT - help please.
Date: 15 Apr 92 13:47:12 GMT
Organization: Laser-Scan Ltd., Cambridge

In article <king.703126437@tasman>, king@tasman.cc.utas.edu.au (Edward King) writes:
> 
> I have been trying to get the SMG unsolicited input to work in a fortran
> program without success. The small test program below is a distilled version
> based loosely on the example in the Grey Wall. I must be missing something
> somewhere but I can't see what it is. Can anyone tell me what I am doing 
> wrong, or perhaps send me a simple working example of using the 
> SMG$ENABLE_UNSOLICITED_INPUT routine (preferably in fortran).

Can't manage Fortran, I'm afraid.  Used to be my system-programming 
language of choice, but I don't do so much of that nowadays under VMS 
:-(

However, attached is a bit of jollity extracted from my upgrade to Mark
Resmer's Vassar Spell.  It's in Pascal, so (of course) you'll be able to
understand it trivially  :-) 

VAR
...
    had_unsol_input : [VOLATILE] BOOLEAN; {TRUE if unsolicited input
                                           has been received}
...

[asynchronous,unbound] PROCEDURE unsol_input_notification;

BEGIN

had_unsol_input := TRUE;

END;

...

IF had_unsol_input
THEN
  BEGIN
  had_unsol_input := FALSE;		{SMG seems to guarantee that
  					 this is safe}
  key_return := smg$read_keystroke(keyboard,key.term_code,timeout:=0);
  IF odd(key_return)			{read something puckah}
  THEN
    [process the key read]

...

BEGIN					{the code that actually gets
					 to use the thing}

had_unsol_input := FALSE;
smg$enable_unsolicited_input(pasteboard,unsol_input_notification);
smg$cancel_input(keyboard);


NOW...

This looks, in essence pretty similar to yours.  The significant 
difference is that my AST routine doesn't specify any parameters, 
whereas yours does.  I can't imagine what's going wrong for you.

								Robin

Robin Fairbairns, Senior Consultant, postmaster and general dogsbody
Laser-Scan Ltd., Science Park, Milton Rd., Cambridge CB4 4FY, UK
Email: robin@lsl.co.uk  --or--  rf@cl.cam.ac.uk
Newsgroups: comp.os.vms