HDTenEightyP/NetNews huggingface dataset:
From: rankin@EQL.CALTECH.EDU (Pat Rankin)
Newsgroups: comp.os.vms
Subject: Re: VAXC divide problems (V3.2)
Date: 28 Jan 93 01:10:18 GMT
Distribution: world
Organization: The Internet

>>      Gruesome details are available in the CRTL portion of the VMS
>>      listings.  This ugly violation of the VMS Procedure Calling Standard

> In what way is this a violation of the Procedure Calling Standard?  It is
> perfectly legitimate for a procedure to reserve space on the stack for data of
> local interest; nothing says that that space has to correspond to variables
> visible to the user.

     That won't wash.  The violation is in VAXC$ESTABLISH, which will
clobber the top of your stack if you haven't allocated the undocumented
hidden variable for it.  It mungs its _caller's_ stack; that's completely
different from extra stack space being used by the current procedure.

     Alternatively, your own code can clobber the saved handler address,
which in turn can result in an ACCVIO inside VAXCRTL for non-longjmp
conditions.  The documentation for VAXC$ESTABLISH states that it is only
usable from code compiled by VAX C because that particular compiler
allocates stack space for its use, but it still violates the procedure
calling standard.

>                      It is perfectly permissible for a condition handler to
> make calls to other procedures, basing its choices on locally available data.
> That's just what this condition handler is doing; it's no different, in
> principle, from having a local variable that indicates what you were trying
> to do, and a condition handler that checks that variable to decide what
> further action to take.

     That would be true if such usage didn't interfere with user code.
Try calling VAXC$ESTABLISH from code compiled by some other compiler
sometime (recent releases of GCC excepted), then tell me that it isn't
violating the procedure calling standard.

>>      is for setjmp/longjmp handling, and is inherited from the Pascal
>>      compiler of all places! ...

> Actually, I think it's the BASIC compiler (which had to pull the same kind
> of trick to implement its user error handling).

     My post was not based on speculation; check the source listings.
They took the implementation from Pascal's GOTO handler.  Perhaps the
Pascal implementation was derived from BASIC's, but if so, the C code
doesn't mention it.

		Pat Rankin, rankin@eql.caltech.edu

Newsgroups: comp.os.vms
From: bcking@HQ.Ileaf.COM (Christine King)
Subject: Re: How to repeat "new Mail message" ?
Organization: Interleaf, Inc.
Date: Thu, 21 Jan 1993 17:09:34 GMT

To check for new mail any time you like, try this:

$! CHECKMAIL.COM
$!	Is there any mail for me?
$!==
$ Msg_Status = f$environment("message")
$ set message/nofac/noid/noseverity/notext
$ mail
dir newmail
exit
$ set message 'Msg_Status'


If you only want the number of messages, not the dir listing too, just
leave the 'dir newmail' line out of the comfile.
-- 
 Christine King, bcking@ileaf.com
 Interleaf, Inc.      | My opinions are not  | "Time is like that,
 9 Hillside Avenue    | necessarily those of |  except for the cannon
 Waltham MA 02154 USA | Interleaf, Inc.      |  and the donut." -Dilbert
Newsgroups: comp.os.vms
From: tjl@zeus02.desy.de (Tim Llewellyn)
Subject: Re: Problems with EXABYTE tape drive
Keywords: EXABYTE
Reply-To: tjl@zeus02.desy.de (Tim Llewellyn)
Organization: Bristol University Particle Physics Group /ZEUS Online
Date: Sat, 23 Jan 1993 00:22:57 GMT

In article <1993Jan22.200938.22220@das.harvard.edu>, chen@speed.uucp
(Lilei Chen) writes:
|>Path: 

|>
|>On our site we use EXABYTE tape drive for backup purpose.  But we
|>can not get more than 500MB on a 112M tape which is supposed to be
|>able to hold more than 2GB according to the specification.  We have
|>about five drives and all behave the same way.  We even tried it on
|>a PC with an ADAPTEC SCSI controler, but the result is the same.
|>EXABYTE claimed that they don't know anything about the possible
|>cause.  So I am asking the net if anyone has encountered similar
|>problems with EXABYTE tape drive and/or knows its possible cause.
|>Thanks.
|>
|>Jim (xue@cfaft5.harvard.edu)
|>

you're not using tapes formatted at low density in a high density drive, are
you. I didn't think it was possible to WRITE to a lower density, only
read from it?

How do you arrive at the 500 MB figure? Are you using the correct blocksize
to calculate it...


--
Tim Llewellyn			
Zeus-UK VMS guru
Soukous Addict
ZEUS02::TJL,BRSPVA::TJL,TJL@ZEUS02.DESY.DE,TJL@SIVA.BRIS.AC.UK
Newsgroups: comp.os.vms
From: jrw@psl.wisc.edu
Subject: Wanted: PostScript network printer
Reply-To: jrw@psl.wisc.edu
Organization: University of Wisconsin - Physical Science Lab
Date: Wed, 27 Jan 93 15:52:18 GMT

I'm looking for a laser printer with the following
specifications:

Requirements:
     o 11 x 17 paper;
     o 8.5 x 11 paper;
     o PostScript;
     o 300 x 300 DPI or higher;
     o Hangs off the Ethernet and works with VMS (we speak DECnet
       and TCP/IP);
     o Relatively fast, especially the first page.

We're considering the DEC LPS-20, but it's a little pricey.
Please e-mail any info that you have about such a beast
(including the price), either positive or negative, and I will
post a summary if there is enough interest.  Thanks in advance!
--
Jim Winkle, PSL System Manager       jrw@psl.wisc.edu      608-877-2261
Physical Sciences Laboratory         jrw@wiscpsl.bitnet   
University of Wisconsin - Madison    psl::jrw
From: iglesias@draco.acs.uci.edu (Mike Iglesias)
Subject: TLZ04 BACKUP /BLOCK value?
Newsgroups: comp.os.vms
Organization: University of California, Irvine
Date: 22 Jan 93 23:02:22 GMT


We have a group on campus that has a VAX running VMS 5.4-2 with a TLZ04 DAT
tape drive and 2 RF72 disks.  They would like to start doing backups on the
system.  I've never used one of these for backups, and I'm not sure what a
good value for BACKUP's /BLOCK qualifier is.  They're not sure where the
manuals are for the tape drive, so if the information is in there I may not
be able to get it. 

If you have any other advice about BACKUP qualifiers to use with the
TLZ04, I'd appreciate hearing them.


Thanks,

Mike Iglesias                        Internet:    iglesias@draco.acs.uci.edu
University of California, Irvine     BITNET:      iglesias@uci
Office of Academic Computing         uucp:        ...!ucbvax!ucivax!iglesias
Distributed Computing Support        phone:       (714) 856-6926
From: SYSTEM_JB@UNODE2.NSWC.NAVY.MIL ("SYSTEM SUPPORT")
Newsgroups: comp.os.vms
Subject: operator accounts
Date: 21 Jan 93 15:44:00 GMT
Distribution: world
Organization: The Internet

I've been working with this one a bit lately.  We had been using a separate
account for OPERATOR  (it was captive and did the mean and dirty stuff with
privs) as well as an OPRWORK account (a few added privs to do some simple
grunt work) and an individual account for mail, etc.)

I created an executable (pretty much justs spawns) that starts up a menu
system. The executable is installed with SETPRV and is started up by typing
OPERATOR from the individual account.  This meant 1 instead of 3 passwords to
learn, no sharing of accounts, and if anything happens, you can audit the
idividual accounts.  The executable calls a DCL based menu program that is kept
tight for errors and control-c stuff so they don't keep bombing.  if an error
does occur, the operator should be booted from the program and all installed
privs resinded. use reads instead of inquires and all that stuff.  seems to be
easier for the operators as well as easier for use to maintain and hold down
any funny stuff. (also, on the shared accounts, had to reset password every
time someone left) 

Sorry if this is kind of schetchy, but I'm hungry and it is lunch time here.

Jon

-----------------------------------------------------------------------------

         ////                   Jonathan C. Baker
         ^[^                    Naval Surface Warfare Center
         \_/                    Code N23A
                                Dahlgren, VA 22448
                                703-663-8705
                                INTERNET:  system_jb@unode1.nswc.navy.mil

          "Is it true that Asfault is a rectal disease???"
Newsgroups: comp.os.vms
Subject: Re: LAT PRINTER PAUSING
From: hansher@bclcl1.im.battelle.org (Kevin Hansher, Battelle Computing Center)
Date: 26 Jan 93 10:29:16 EST
Distribution: world
Organization: Battelle, Columbus, OH

In article <930125100004.22e0044c@XAVIER.XU.EDU>, DICKHAUS@XAVIER.XU.EDU writes:
> Original post asked about que on Datability server pausing under vms 5.5-2.
> 
> We operate several Datability servers under 5.4-2, soon to be 5.5-2,
> and occasionally have the same problem. Maybe it is worse under 5.5-2;
> I'll have to check with Datability for the minimum version of the chips
> on the network card that is OK with 5.5-2.
> 
> Have found that doing a stop/reset on the que, then going into the server
> and doing SHOW PORT nn STATUS reveals that output is Xoffed.
> LOGOUT PORT nn clears this. Then restart the que.
> 
> Carl Dickhaus
> XAVIER UNIV., CINCINNATI
> BITNET: SYSTEM@XAVIER.BITNET
> INTERNET: SYSTEM@XAVIER.XU.EDU
> 

We have had very similar problems with Emulex P4000's.  Seems to be a lot
worse after 5.5-2 upgrade.  Also, a temporary workaround appears to be to
move the queues to a slower node.  We don't see the problem on our "soon
to be replaced 8800's" but constantly on our 6610's and 6410.  Hmmmm...
Same sympton that you mentioned above...server port Xoffed.  I have also
applied CSC LAT Patch 511 V3.3.  LATSYM.EXE version listed as V5.3-037.

We do not appear to be having the problem with any of the DECservers.  One
of those cases where someone's decision to buy cheaper, costs more in the
long run.  (This isn't the only problem we've had with the Emulex boxes!)
And we don't appear to be getting anything resolved.  We have not been
able to get Emulex software that will let us get both printing and, of course,
the normal inbound terminal connections working at the same time.  We have to
sacrifice one for the other.  Of course, the P4000's were swapped in for
P8000's a couple of years ago...don't even want to get into problems
encountered there!!!

-- 
------------------------------------------------------------------------------
Kevin Hansher			Symposium Session Quality Coordinator -
Battelle		        U.S. DECUS VMS Systems SIG
505 King Avenue	                Internet:	hansher@bclcl1.im.battelle.org
Columbus,  OH  43201		Voice: 614-424-4008  Fax:  614-424-5263
Newsgroups: comp.os.vms
Subject: Re: TPU mail quoting procedure available?
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 24 Jan 93 08:29:09 GMT
Distribution: world
Organization: The Wolery

cg656@cleveland.Freenet.Edu (Michael O. Bartz) writes:
> 
> I am currently using a TPU file that has the ability to quote
> a message when replied with REPLY/EXTRACT in mail.  It's something that
> I whipped up that simply looks until it finds a blank line and
> then it deletes everything above it.  Then it quotes the rest of
> the message.  Simple!  However not so simple since mail is in this form:
> 
>       non-local                            local mail
> 
> [vax 4 line header]             |     [vax 4 line header]
>      S P A C E                  |         S P A C E
> [the rest of the net-headers]   |     [body of message]
>      S P A C E                  |
> [body of message]               |
> 
> So the problem is that the TPU procedure can't tell the difference
> between net-mail headers and the body of the message.  If I call the
> procedure twice, it will delete the first paragraph of local mail.

Well, obviously, you're going to need more smarts than that.  What I do
(in EDT) is to go down _two_ paragraphs, search backward for a "From:"
(be it a VMS header or a net header --  most mailers duplicate the From:
line in the "in-body" headers), go to the end of the paragraph and delete
everything from the beginning of the buffer to the current position.  If
it's not a network message, you may lose the first paragraph if it contains
a "From:".  Them's the breaks.

In EDT:

change;br ((+2par) -"From:" +par dbr) ex

For completeness, my EDT "remove header, quote & sign" macro goes:

change;br ((+2par) (-"From:" +par dbr) br 32767(i>^Z ll -v) ^M sel ^M^M) ex
include SYS$LOGIN:SIG.TXT
change; -sr ex

You will of course need to write a longer procedure for TPU.

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
From: SYSMGR@IPG.PH.KCL.AC.UK
Newsgroups: comp.os.vms
Subject: Re: computers, automobiles (and bignums)
Date: 25 Jan 93 11:12:56 GMT
Distribution: world
Organization: The Internet

>> If the automobile industry were like the computer industry
>> over the past 30 years, a Rolls-Royce would now cost $5.00,
>> would get 300 miles to the gallon, and once a year would
>> explode killing all passengers inside!
>
> This statement can be supported (except the exploding part.)
>
> Gorden Bell in "Computer Engineering" (p. 55) quotes a 1973 study by Fusfeld
> in which the Automobile "Measure of Progress" is between 6 and 13 while the
> Computer's "Measure of Progress" is greater than 10**12. FYI, Light bulbs,
> Titanium, Aircraft, and Turbojet engines are also in the study.


The first statement is just plain WRONG. 

Top speed of Roller = 160mph? \approx 75 metres/second. Speed-up over 30
years is at least 10**5, so now have 7.5E6 m/s: faster than any spacecraft
yet built and about 2% of the speed of light.

As for fuel, an IBM dinosaur was probably 100 kW, an Alpha chip is 25W. 
But, that's fuel per unit TIME where as mpg is fuel per unit DISTANCE.
Therefore the analogy is that the car uses 10**5 * 4*10**3 times less
fuel; if it started at 10mpg its now on 4E9 mpg, or over 1000 miles on
fuel equivalent to one crystal of sugar.

I don't know how often 1960-era computers crashed, but I'd be surprised if
it was less often than current ones and I'd guess 10-100 times less often
which would make the Roller as safe as a train.(Modern computers CAN be made
orders of magnitude more reliable, but it isn't often economic to do so.
The same probably applies to cars, although there's not a lot one can do
about the nut that holds the steering wheel :-]

A factor of 10**12 is the difference between two millennia and 1/60 second.
In "more Programming Pearls" there is an example of a numerical problem which
with 1950's knowledge would have taken milennia and now takes ... 1/60 second.
The improvement factors are split roughly equally: 10**6 (a million) because
of faster hardware, 10**6 because of better algorithms now known.

There's a couple of morals here. Firstly, unless you try to express factors
of bignum in terms that a person can visualize, the bignum remains meaningless.
Secondly, if you can find a better algorithm you may have accomplished in
a moment something equivalent to the entire progress of a multi-billion-dollar
industry over thirty years!

Speculation: humans are just a better algorithm. (I don't necessarily agree.
             It's a good starting point for some interesting research, though).

		Nigel Arnot

		NRA%ipg.ph.kcl.ac.uk@nsfnet-relay.ac.uk   (internet)
		NRA%uk.ac.kcl.ph.ipg@ukacrl.bitnet        (bitnet)
From: TARKA10@SNYBUFVA.BITNET (Mark Tarka)
Newsgroups: comp.os.vms
Subject: Stan Smith
Date: 27 Jan 93 17:08:40 GMT
Organization: from SUNY College at Buffalo, NY 14222

Incomming:  COM%"INFO-VAX@SRI.COM" 27-JAN-1993 11:35:55.22
Stan Smith, system@DOC.BMD.TRW.COM, says:

< some stuff deleted >

>Well, this HAS been fun, but I really don't have much time for fun. I have
>an REAL job. I'm afraid this really must be my last word. CarryOn!
>
>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Stan Smith, Vax System Manager          |ssmith@oz.bmd.trw.com (801) 625-8163 |
>TRW, Ogden Engineering Operations       +-------------------------------------+
>1104 Country Hills Drive                | Opinions expressed, do not belong.  |
>Ogden,  Utah       84403                | Defense, so we can have our Space.  |
>If we couldn't laugh, then we'd all go insane.                                |
>                                 Jimmy Bufffet (Changes in Latitudes)         |
>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Stan.

Ten of us have been formally active since 23 January, attempting to get
some assistance for Sabry Kotob el-Ganzory, an operator in Egypt who
lacks manuals.  Our immediate goal is to coordinate a shipment of
materials, and to minimize the lines of communication.  Could you please
assist us with answers to the following:

(1)  Are you  n o w  actively assisting Sabry?

(2)  Have you, or are you going to send any, or do you have manuals to
send?  In any case, please provide titles/versions/dates/; complete sets?
Sabry's machine: MicroVAX 3400 12.00MB; VAX/VMS 5.2-1.

(3)  If you are actively assisting Sabry, would you be willing to join
us?  If not, can we assist you?

Please respond to Carl J Lydick < carl@sol1.gps.caltech.edu >.  He will
summarize and forward the information for our database.

Thanks,

Mark

Mark Tarka  (Addresses valid until 1 April 93; then, bye bye)
tarka10@snybscva.bitnet  vax 6610  vms(5.5-1)  mail(5.0)
tarka10@snybufva.bitnet  vax 6520  vms(5.5-1)  mail(5.0)
(Bartender!  Are you supposed to spear the olive lengthwise, or ....?)
Newsgroups: comp.os.vms
From: houseman@hopper.ACS.Virginia.EDU (Carl Houseman)
Subject: Re: PATHWORKS
Organization: UVA. FREE Public Access UNIX! 
Date: Tue, 26 Jan 1993 17:22:48 GMT

In article <9301261610.AA29598@ucbvax.Berkeley.EDU> CXNHJP@manadon-engineering-college.ac.uk writes:
>We have just recently installed PATHWORKS and are having great difficulties in
>trying to get aspects of the PCSA MENU to work from any other account that the 
>system account. After copying the system account to another account and using
>that account with all privs except bypass functions from the User Options
>menu still come back with %SYSTEM-F-NOPRIV, no privilege for attempted operation
>error message.
>
>Can any body out there shed some light on this black art of getting a perfect
>pathworks installation.

You have already shed the necessary light.  Certain functions require
BYPASS privilege.  Don't ask me why.  I think it's stupid.


Carl Houseman
houseman@hopper.acs.virginia.edu
GENICOM Engineering, Waynesboro, VA
703-949-1323
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: mailboxes with DCL?
Date: 22 Jan 1993 12:44:08 GMT
Organization: HST Wide Field/Planetary Camera
Distribution: world
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <1993Jan21.032056.373@wega.rz.uni-ulm.de>, ORAKEL@rzmain.rz.uni-ulm.de (Framstag) writes:
>I know, this topic has been discussed several times in the last years, but
>I haven't saved these articles, because I wasn't interested in, and now I
>need it:
>
>Some (easy, of course :-) ) examples of DCL programs handling with
>mailboxes with normal user privs (netmbx,tmpmbx).
>
>What exactly I want: process-communication between a DCL-program running in
>a detached (via run sys$system:loginout/input=...) or batch process and a
>"user in front of his terminal".
>
>The user should be able to send DCL-commands via a mailbox to the
>detached/batch program which scans, say... every 10 sec the mailbox and
>then executes the command. It will not be necessary to return output to the
>interactive user's terminal. (But nice, if :-) )
>
>example:     $ write mailbox: "@do_something"
>or:          $ @mbox_frontend "backup d1: d2:"
>
>or something like that. I hope I have expressed myself clear enough - Carl,
>don't beat me too hard ;-)

You can't create mailboxes from DCL.  You've got to write a program to create
them (and, since you're probably restricted to creating temporary mailboxes,
they go away, by default, at image rundown).  What you need to do is:
	1)  Write a program that uses $CREMBX (use the command HELP SYS $CREMBX
	    for details) to create a mailbox, assigning to it a known logical
	    name, then reads a single record from it (sample program included
	    below); and
	2)  Run that program from a spawned asynchronous subprocess, then use
	    the DCL OPEN command with the known logical name to assign a
	    channel to the mailbox from the parent process;
	3)  Write a record to the mailbox (e.g., with the VMS COPY command);
Or, you could simply have the subprocess sleep for long enough for you to
assign the channel.  Here's the program to create the mailbox:

#include stdio
#include descrip
main()
{	$DESCRIPTOR(lognam, "FUBAR");
	unsigned short chan;
	FILE *fp;
	char buff[10];

	SYS$CREMBX(0, &chan, 0, 0, 0, 0, &lognam);
	sleep(30);

	fp = fopen("FUBAR", "r");
	fgets(buff, 10, fp);
}
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
From: winalski@adserv.enet.dec.com (Paul S. Winalski)
Newsgroups: comp.os.vms
Subject: Re: Image activations, page faults and disk I/O
Date: 27 Jan 93 22:24:42 GMT
Reply-To: winalski@adserv.enet.dec.com (Paul S. Winalski)
Organization: Digital Equipment Corporation, Nashua NH


In article <1993Jan26.155208.131143@mswe.dnet.ms.philips.nl>,
hdavids@mswe.dnet.ms.philips.nl (Henk Davids) asks about the design rationale
behind VMS image activation, in particular, why successive activations of the
same image are not faster than the first, and other such optimizations.

The main reason is conservation of physical memory.  The minimum memory
configuration available for the first VAX-11/780s was 256K.  VMS V1 was
designed to run in that configuration.  Keeping track of which image that
a page on the free list belonged to requires additional non-paged data
structures.  Non-paged pool was a precious commodity on 256K VAX systems.
Furthermore, the odds are that on such a system the memory would almost
immediately be scarfed up into another process's working set, so you won't
be able to scavenge those pages, anyway.  This is also why VMS doesn't share
read-only portions of an image by default, but rather requires that you
INSTALL the image first--known image entries consume nonpageable memory, and
in small memory configurations, you're better off not eating up the physical
memory just on the off chance that another user will simultaneously run the
same program.  Cases where the is a payback can be handled by the INSTALL
command.

There is an unsupported hack that you can do to speed up image activation.
You write a program that does the following:

	1) for each image in a list of images you wish to "turbo-charge":
	2)     call the $IMGACT service to activate the image
	3)     touch each page in the image to fault it into the working set
	4) when all images have been processed, hibernate

Install all of the images in the list /SHARE.  Then run the above program in
a process with sufficiently large working set limits to hold all of the images
in physical memory, and with working set adjustment and swapping turned off.

This will insure that all of the global pages of the images are always
resident in physical memory, thus, there will be no need to fault them in off
disk when the image is activated and run.  In situations where the same small
set of images is run repeatedly, this can result in vastly improved performance.

Of course, this only works on systems where you can afford to have the
physical memory tied down like this.

--PSW