HDTenEightyP/NetNews huggingface dataset:
From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: re: PCA limitation / Unix "strip" for VMS
Date: 26 Jan 93 01:09:49 GMT
Distribution: world
Organization: The Internet


	[Mr. Fitch describes a problem with PCA when applied to a certain
	very large file.]
	The description of this error in the documentation says to submit an
	SPR to DEC if the same module works with the regular debugger.  It
	seems to (I can "set module" to the module PCA complains about if I
	use the normal debugger), and in any case, if I substitute  a null
	version of that program,  PCA simply complains about another one.
	This implies that I'm simply bumping up against some limit in PCA.

I suspect your conclusion is correct.

	This may or may not be fixable, but I'd rather not wait months or
	years for a fix.

	The application which I'm trying to use PCA on is still growing (it's
	in a development phase), so we'd still like to have all the symbols in
	the subroutines for debugging purposes.  It takes a long time to
	recompile everything, so I'd rather not do that if I can avoid it.

Well ... for the most part, you only have to do that ONCE.  After that, as
pieces are modified, you could compile each one twice, once with and once
without /DEBUG.  Except for the one long recompilation, what this would
really cost you is disk space.

	What I'd like to find out is:

	- is there a known workaround for the PCA problem?

Perhaps some PCA user can answer this one.

	- is there something I can specify to LINK to tell it
	  to ignore debug symbols for a _subset_ of library modules?

No, sorry.

	- is there a VMS equivalent of the Unix "strip" command
	  that I can apply to object files?  (Ideally, this
	  would also work on an object library on a selective
	  basis.)  For what I'm doing with PCA, I can "a priori"
	  determine that many of the modules don't need debug  
 	  symbols.  By giving PCA less to cope with, I could
	  presumably work around the problem.

I've never seen one.  To tell you the truth, until your example, I've never
seen the need for it.

	- could I create my own equivalent of "strip" by somehow 
	  setting the count of debug symbols in the object module 
	  header (or wherever) to zero?  If this is feasible, can
	  someone recommend a good starting point so I don't have
	  to develop this from scratch?

It should actually be pretty easy to create such a thing.  An object file is
a series of records of different types; all the debug information is in
Debugger Information records.  A "strip" program would merely read the records
one at a time, ignore Debugger Information records, and copy the rest.  The
format and even the type flag values for object file records are all described
in the Linker documentation.  (The detailed internals of Debugger Information
records isn't described - you have to look in the Debugger listings for that -
but you don't really care about the innards for this application.)  The
definitions of the various symbols are in STARLET as, for example, the
$OBJDEF macro.  (OBJRECDEF.H for C programs.)

If you write such a program, I'm sure others would find it useful, too.

							-- Jerry

Newsgroups: comp.os.vms
From: dwight@geohub.gcn.uoknor.edu (Dwight D. Moore)
Subject: Re: Problems with EXABYTE tape drive
Originator: news@kittyhawk.ecn.uoknor.edu
Date: Mon, 25 Jan 1993 14:32:49 GMT
Reply-To: dwight@geohub.gcn.uoknor.edu
Organization: Geosciences Computing Network, Univ. of Oklahoma
Keywords: EXABYTE

In article <1993Jan22.200938.22220@das.harvard.edu>, chen@speed.uucp (Lilei Chen) writes:
|>Path: constellation!mimbres.cs.unm.edu!ogicse!das-news.harvard.edu!speed!chen
|>From: chen@speed.uucp (Lilei Chen)
|>Newsgroups: comp.os.vms
|>Subject: Problems with EXABYTE tape drive
|>Keywords: EXABYTE
|>Message-ID: <1993Jan22.200938.22220@das.harvard.edu>
|>Date: 22 Jan 93 20:09:38 GMT
|>Article-I.D.: das.1993Jan22.200938.22220
|>Sender: usenet@das.harvard.edu (Network News)
|>Organization: Aiken Computation Lab, Harvard University
|>Lines: 11
|>
|>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)
|>
Exabyte 8200 write in 512 byte blocks. If you write small records
< 512, then space is wasted (or block size that aren't multiples
of 512 also). The 8200 isn't smart enough to pack the
blocks on tape. This will cause a less that optimal tape usage.
The 8500 writes in 1024 byte blocks, but can also fill unused
portions of the block, so is an improvment from the 8200 drive.
Also, the inter-record gap is rather large, so the bigger the
output records, the better tape usage you get...
----------------------------------------------------------------------------
Dwight D. Moore
Geosciences Computing Network
University of Oklahoma

dwight@geohub.gcn.uoknor.edu (129.15.40.10)
These opinions do not necessarily represent the opinions of OU or the GCN.
----------------------------------------------------------------------------
From: marten@ilt.fhg.de (Lutz Marten)
Newsgroups: comp.os.vms
Subject: Re: duhE
Date: 28 Jan 1993 13:34:10 GMT
Organization: FhG-ILT
Distribution: world,local
Reply-To: marten@ilt.fhg.de
NNTP-Posting-Host: 192.44.11.6


brennan@tango.cchs.su.oz.au (Luke Brennan) writes:
> ?drawkcab daer enoyreve t'naC
> 
> lliB
>
>	No.. I can't easily - I don't have SAS !!
>	(SAS has a built-in to do this apparently! (I have NO idea why!))

Did you never tried to create stickers for your car windshield? I mean the kind
you put on the window from inside! :-)

oaiC
ztuL- 

--
# Lutz Marten,  Postmaster and general dogsbody 
# Fraunhofer-Gesellschaft Institut fuer Lasertechnik 
# BITNET: KQ040MA@DACTH11 , InterNet: marten@ilt.fhg.de                        
# HEPNET: 13533::52714::MARTEN, Phone: +49/241/8906-112, -0
From: RMCEWEN@CCS1.BBN.COM (Regis McEwen)
Newsgroups: comp.os.vms
Subject: Re: SYSUAF.DAT access - the real world
Date: 22 Jan 93 20:50:00 GMT
Distribution: world
Organization: The Internet

In article <9301202243.AA01736@uu3.psi.com>, leichter@lrw.com (Jerry Leichter) writes:

[...]

> In Mr. Perucci's position, the ideal would be to be able to give the auditor
> read-only access to the SYSUAF.  Unfortunately, AUTHORIZE demands WRITE
> access.  I consider this a serious limitation, since it makes it unnecessarily
> more difficult to implement an "outside auditor" facility.  One way to do this
> would be to give the auditor just read access and have him copy the live
> SYSUAF.DAT to a private file, which he could then modify to his heart's
> content without damaging anything.  Another approach is to trust the auditor
> not to do anything stupid - but have someone else check the audit logs for any
> changes he might make to the SYSUAF.  (Again, make sure two people have to
> work together to subvert the system.)
>
> Of course, with the listings it should be simple to patch AUTHORIZE NOT to
> demand write access - just pull out the explicit check.  If it keels over when
> someone tries to write to the file, well, big deal.

	Another suggestion along these lines is to write a GETUAI program,
	installed with SYSPRV and WORLD that has the "look and feel" of
	AUTHORIZE.  Several DECUS programs and a few by Joe Meadows could
	be used as a jump-off point to cannibolized one together.

	Or a quick-n-dirty solution would be to have a program installed that
	will only do a (pseudo-code):

		$ read/prompt="Username [*]: " sys$command: username
		$ if username .eqs. "" then username := "*"
		$ define/user sysuaf sys$system:sysuaf.dat
		$ mcr authorize list/full 'username	(or show/full)


	Subtlely (or not so subtlely!) hidden observation in your post is
	that while some of us are charged with the responsibility of machines:
	security, maintenance, integrity, whatever -- the machine is still
	not *OURS* -- we are just the caretakers of a resource that might
	even be used or owned by others.  And sometimes that means, unless a
	specific request goes against your princibles, that you have to come
	up with a solution you'd might not feel entirely comfortable with.

	Real world situations, demand real world solutions:

	Good post, Jerry !


							-Regis

Newsgroups: comp.os.vms
From: brennan@tango.cchs.su.oz.au (Luke Brennan)
Subject: Re: How to repeat "new Mail message" ?
Organization: Cumberland College of Health Sciences
Date: Tue, 26 Jan 1993 11:58:43 GMT

In article <C1Et0H.BFI@micrognosis.co.uk>, nreadwin@micrognosis.co.uk (Neil Readwin) writes:
> In article <01GTTQ24GO5U006MJF@VAXF.COLORADO.EDU>, DWING@UH01.Colorado.EDU (Dan Wing) writes:
> |> >[...] many VMS-Sysops clear the screen for a Mesage-Of-The-Day-Info,
> |> >before the User can enter DCLs at the "$" prompt
> |> 
> |> I don't get excited too often, but WHAT A STUPID THING TO DO.  A user on your
> |> system has no way of validating their last-login times, and have little, if 
> |> any, chance of seeing "xx unsucessful logins" messages!!!
> 
> Well, 'no way' is not strictly true. If the user wants to see these
> they could still display them using the LAST_LOGIN_N, LAST_LOGIN_I and
> LOGIN_FAILURES item codes to the f$getjpi lexical. Neil.

	Hey! it's *sillier* than that!
	What about GROUP login.com files! *they* often have their own
	MOTD and clear away everything Yet Again..

	I can assure you that 'xx unsuccessful logins' wouldn't even
	register in the consciousness of most of the users here - 
	it's LONG gone before they start to focus... :-}

	No point in thinking WHAT A STUPID THING.. It might be from
	*your* viewpoint - but it's NOT the groups... They don't care
	a hoot about you, or the sysop!!

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Luke Brennan                             e-mail:   L.Brennan@cchs.su.EDU.AU +
+ EDP Unit, S209                       L.Brennan%cchs.su.edu.au@cunyvm.BITNET +
+ Cumberland College of Health Sciences,                              ,-_|\   +
+ The University of Sydney                  voice: +61 2 646 6402    /     \  +
+ East Street, Lidcombe, NSW 2141             fax: +61 2 646 4853    \_,-._*  +
+ AUSTRALIA                                                               v   +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Programming
Date: 26 Jan 1993 06:26:58 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 <9301260253.AA28593@ucbvax.Berkeley.EDU>, CTANSKI@ONONDAGA.BITNET (Chris Tanski) writes:
>I am going to be taking a programming course next year and I want to know
>which one to take. My options are: BASIC, Pascal, FORTRAN, C, and COBOL. I
>want to be able to write programs on my VMS acct. so whichever programming
>language is best for that is the one I want. Thanks and please reply directly
>to ctanski@onondaga.bitnet.

Depends on what you want out of the course.
	BASIC:		Qualifies you to write programs for PC owners;
	Pascal:		Similar to C, but with strong typing;
	FORTRAN:	Good for scientific programming, but you're likely to
			learn very little about data structures;  better than
			COBOL or BASIC, at least; 
	C		If you learn this one, you're going to learn a lot
			about how computers work.  You'll learn about things
			like data storage and structures.  It is, in my
			opinion, the best of the lot, if you really want to
			learn how to program.
	COBOL		Take this one, by all means, if you want to spend the
			rest of your life writing payroll programs.
Hope you can find someone willing to reply to you via e-mail, given that you
can't be bothered to take the time to read the group.
--------------------------------------------------------------------------------
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: MACRIDES@SCI.WFEB.EDU (Foteos Macrides)
Newsgroups: comp.os.vms
Subject: Re: LIB$SPAWN and privileges...
Date: 25 Jan 93 14:57:24 GMT
Distribution: world
Organization: The Internet

In article <01GTXHT0P1IC00007S@SCI.WFEB.EDU>, Stephen Tihor <tihor@ACF3.NYU.EDU> writes:
> FYI there are things called user written system services which are
> a fair approximation to installed privileged sharable images.   They requires
> special caution in writing whihc is probably why Carl did not include them.

	Has anybody written a SYS$PURGE and/or SYS$RENAME system service?  I
want to do some file cleanup operations from a CtrlY-trapping AST, and can't
use LIB$SPAWN or system() cuz the child process can't bring the parent back
out of hibernation.

				Fote

=========================================================================
 Foteos Macrides           Worcester Foundation for Experimental Biology
 MACRIDES@SCI.WFEB.EDU     222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
From: welchb@woods.ulowell.edu
Subject: Warning: bug check messages
Organization: University of Lowell
Date: Fri, 22 Jan 1993 21:05:29 GMT

	We are running VMS 5.5-2 on a VAX 6610.  When a privileged user, 
inside mail, says   

Mail>show forwarding/user=*

we get the correct response listing the approximately 30 users who have
set forwarding.  But the execution of the instruction causes bug check
mail messages from VAXsimPLUS; apparently it has something to do with
generating stuff coming across the network.
	We reported this as a hardware problem; after dialing in they 
asked us to call it in as a software problem.  Software has never seen
this.  The only way they could solve it would be to change a sysgen
parameter which allows a crash to occur from non-fatal errors; we find 
this to be unacceptable on our busy machine.
	Has anyone had any experience with this?
Brendan Welch, UMass/Lowell, W1LPG,  welchb@woods.ulowell.edu
Newsgroups: comp.os.vms
From: welchb@woods.ulowell.edu
Subject: Please explain SUBMIT action.
Organization: University of Lowell
Date: Fri, 22 Jan 1993 21:12:12 GMT

	I am used to the fact that I often have trouble with submitting
jobs.  In particular, if the job creates a file, and if the execution
time is lengthy, I often try to look at the log file, or the file being
created (with TYPE, DUMP, EDIT) with no luck; the file is locked by
another user.
	I was running such a job, when the machine crashed.  When it
rebooted itself, the locked files were now unlocked.  The job continued
to run correctly, but I could now TYPE the output file as it grew
during the execution.
	I admit that I messed around quite a bit, submitting several
jobs, some with the log file /KEEP, some with /USER=SYSTEM, and maybe
other variations.  Yet I am reasonably certain that the phenomenon 
above is correctly described.  What was happening?
-- 
Brendan Welch, UMass/Lowell, W1LPG,  welchb@woods.ulowell.edu
From: vivekr@osc.COM (Vivek Rau)
Newsgroups: comp.os.vms
Subject: Flushing file buffers to disk in VAX C
Date: 21 Jan 93 18:02:22 GMT
Reply-To: vivekr@osc.UUCP (Vivek Rau)
Organization: Versant Object Technology, Menlo Park, CA

The problem:
------------
I am running VMS 5.5-1 on a VAXstation 4000 model 60. I find that
the C library call fsync() does not write the file buffers to disk
as it is supposed to. Could someone else run the program below on 
this or earlier versions of VMS and check it? Run the program on 
one terminal, and when it stops to wait for input, kill the process
using the STOP command from another terminal. If I understand the
functionality of fsync() correctly, the buffers should have been
flushed to disk - but when you look at the file after stopping the
process, it is still empty. Is this a bug? 

Some more details:
-----------------

I am using VAX C version 3.2 - earlier versions of the RTL may not 
support the fsync() call. It is not documented in the RTL reference
manual even in the current version, but it is available in the
library. There is no other way to ensure that C file data has
been written to disk and the disk version is up-to-date (short of
closing the file).

I do not think the bug is in the fsync() routine itself; you can verify 
that the routine calls the RMS routine sys$flush() internally, as you
might expect. (You can check this out by stepping through the
assembly instructions with the debugger). I have tried calling
sys$flush() directly, and it returns without error - still
without writing the buffers to the file. So is the error in RMS?

Another puzzle which I wonder if someone could explain to me - the
C write() routine does not call RMS sys$write() at all. It calls
sys$read() instead! Is there something wrong with my debugger
symbols or is this the right thing for write() to do? It works, i.e.
the file does get written to normally. Does this have something
to do with the above problem?

Please reply to me by email if you have Internet access: vivekr@osc.com
If anything interesting emerges I will summarize the results in another
post to the net.

----------------- Source code begins here ----------------------------
#include <stdio.h>
#include <file.h>

main()
{
	int fd;
	char buf[] = "This is a test record\n";
	char testFileName[] = "chks.out";

	if ( (fd = open(testFileName, O_RDWR | O_CREAT)) < 0) {
		fprintf(stderr, "Error opening file. Exiting... \n");
		exit(0);
	}

	fprintf(stderr, "The file being used is %s\n\n", testFileName);
	fprintf(stderr, "%s%s%s%s%s",
	"A record has been written to the file and sync'ed. If the fsync()\n",
	"call works correctly the data should be in the file even if the\n",
	"process is stopped. You can now halt the process from another\n",
	"terminal or window using the STOP command, or hit any key to let\n",
	"it run to completion...\n"
		);
	fflush(stderr);

	write(fd, buf, sizeof(buf));
	fsync(fd);

	/**
		You can now stop the process from another terminal or
		window while it waits, or let it complete.
	**/
	getchar();

	close(fd);
	fprintf(stderr, "Wrote the record and closed the file\n");
}
From: tp@mccall.com (Terry Poot)
Newsgroups: comp.os.vms
Subject: Re: Recursion in FORTRAN
Date: 21 Jan 93 15:26:28 GMT
Reply-To: tp@mccall.com (Terry Poot)
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-User: tp


In article <1993Jan20.195642.13310@dbased.nuo.dec.com>,
lionel@quark.enet.dec.com (Steve Lionel) writes:
>As of DEC Fortran V6.0 on OpenVMS (currently shipping on Alpha AXP systems,
>soon to come on VAX), SAVE will NOT be a no-op.  So be sure to use it if you
>want the value saved upon exit from the routine.  Note that SAVE does not
>necessarily mean "static allocation"; there is a STATIC statement for that.
>(In practical terms, SAVE does cause static allocation, but you should say
>what you mean and mean what you say.)

I want to be real clear about this (I hear the sound of 200,000 lines of legacy
fortran code shattering to little bits). As of v6.0, values not explicitly
mentioned in a SAVE statement can not be guaranteed to survive from call to
call, right? Any qualifiers to preserve the current behavior?

Of course, *I* don't write code this way, but I didn't write most of the stuff I
support, and I haven't attempted to go into all our code and find where it needs
SAVE statements (it needs lots of them). (Time to read up on SCA's inspect
command, I guess.)
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA
From: Chris_F_Chiesa@cup.portal.com
Newsgroups: comp.os.vms
Subject: Re: CDA-Viewer mystery
Date: Sun, 24 Jan 93 20:59:24 PST
Organization: The Portal System (TM)

Eberhard Heuser-Hofmann (no Internet address in message body, and Portal
doesn't pull it from the header for me) writes: 

>I have a problem with the MOTIF-1.0A-CDA-VIEWER.
>I use that tool to display ps-files. If I log into the consol, everything 
>works,
>but if I use an X-Terminal I can't select the conversion PS, because there is
>no PS menu-item.
>
>Has someone seen this, too?

Well, at least you HAVE a console.  When I first encountered this problem I 
had ONLY an X terminal (DEC VT1000) and thus NO way to CDA VIEW PostScript
files.

The problem is that the PS interpretation is done by "PostScript extensions"
in the X _server_, not in the CDA-Viewer _client_ -- and DEC did NOT put the
necessary PS interpretation capability into the server code built into the
VT1x00 series of X terminals.  As far as I know, there is therefore no way to 
CDA-View a PostScript file on a DEC X terminal, and it also seems unlikely
that "generic" X terminals would have the necessary DEC extensions either.
(But I know very little about this subject and could be wrong on the subject
of "generic" X terminal behavior.)

I suggest finding an alternate X-based PostScript interpreter/viewer in
which the client side does the conversion-to-X-image; I do not know any 
such software specifically.

Chris Chiesa
  Chris_F_Chiesa@cup.portal.com
From: tshin@husc8.harvard.edu (Tae Shin)
Newsgroups: comp.os.vms
Subject: Suggestions for VMS/DCL manuals
Date: 22 Jan 93 09:51:18 GMT
Article-I.D.: husc8.TSHIN.93Jan22015118
Distribution: world
Organization: Harvard Arts and Sciences Computer Services, Cambridge, MA

Hi!  I'm sort of novice to the world of VAX/VMS and I was wondering if there 
were any good books about using VMS/DCL and system administration.  Our lab has
a VAXstation 3500 using V5.4-2.  If there's a FAQ and/or FTP site with this 
information, please let me know about it.  Thanks ahead of time for any help
you can provide.

T.B. Shin
Department of Chemistry
Harvard University
tshin@husc8.harvard.edu
From: ISENHOUR@FNAL.FNAL.GOV (John L. Isenhour)
Newsgroups: comp.os.vms
Subject: (none)
Date: 20 Jan 93 17:23:31 GMT
Organization: The Internet

REMOVE ISENHOUR@FNALO.FNAL.GOV
REMOVE ISENHOUR@FNALA.FNAL.GOV
REMOVE ISENHOUR@FNALC.FNAL.GOV
REMOVE ISENHOUR@FNALF.FNAL.GOV
REMOVE ISENHOUR@FNALNM.FNAL.GOV
REMOVE ISENHOUR@FNALNO.FNAL.GOV
REMOVE ISENHOUR@FNALNA.FNAL.GOV
REMOVE ISENHOUR@FNALNB.FNAL.GOV
REMOVE ISENHOUR@FNALNC.FNAL.GOV
REMOVE ISENHOUR@FNALND.FNAL.GOV
REMOVE ISENHOUR@FNALNE.FNAL.GOV
REMOVE ISENHOUR@FNALNF.FNAL.GOV
REMOVE ISENHOUR@FNALNG.FNAL.GOV
REMOVE ISENHOUR@FNALNH.FNAL.GOV
REMOVE ISENHOUR@FNALNI.FNAL.GOV
REMOVE ISENHOUR@FNALNJ.FNAL.GOV
REMOVE ISENHOUR@FNALNK.FNAL.GOV
REMOVE ISENHOUR@FNALNL.FNAL.GOV
REMOVE ISENHOUR@FNALNN.FNAL.GOV