HDTenEightyP/NetNews huggingface dataset:
From: rankin@EQL.CALTECH.EDU (Pat Rankin)
Newsgroups: comp.os.vms
Subject: Re: RMS RAB & FAB for VAXC file
Date: 9 Jan 93 03:27:25 GMT
Organization: The Internet

>>Coming back from my Christmas I have read a long discussion about VAX C
>>buffer flushing. Many people say that it is easy to get the RAB/FABs from
>>a VAX C FILE *
>>
>>OK so how do you do it ???

     It has been discussed here several times over the years.  However
said it was "easy" has mislead you, because it's an invitation to future
problems.

> Sorry, that was a mistake on my part.  I was confusing two RTLs.  From
> the FORTRAN RTL, you can get the RAB from the LUN via the (undocumented,
> last time I checked) routine FOR$RAB.  There's no such routine (at least
> under VMS v5.4-2 in the VAXC RTL), though Ehud had indicated that a
> perusal of the listings will allow you to figure out how to find it.

     FOR$RAB is discussed briefly in the section of the FORTRAN manual
(User's Guide) dealing with USEROPEN routines.  So, I wouldn't classify
it as undocumented.

     The routine for accessing VAXCRTL's RMS structures is undocumented
and intended to be private to the library.  If you link against the
shareable image version of VAXCRTL you won't be able to use it at all.
If you link with the object library, you will--until you try to move
to DEC C and DECC$SHR that is.

#include <stdio.h>
#include <rms.h>
	/* _fstat() is a private routine internal to VAXCRTL */
extern int _fstat(int, struct FAB **, struct NAM **, struct RAB **);
...
    FILE *fp = fopen(...);
    struct FAB *fab_p;
    struct NAM *nam_p;
    struct RAB *rab_p;
    int result = _fstat(fileno(fp), &fab_p, &nam_p, &rab_p);
    if ( result >= 0 ) {
	/* do something with one or more of the RMS blocks */
    }

     It's also possible to derive a RAB pointer by doing some magic
arithmetic on a FILE pointer, but that goes beyond undocumented and
unsupported to _unsupportable_.  I'd advise against doing that or using
_fstat().  If you want access to RMS, then use RMS.

		Pat Rankin, rankin@eql.caltech.edu

Newsgroups: comp.os.vms
From: brent@uwovax.uwo.ca (Brent Sterner)
Subject: Re: Long standing apparent Backup or XQP problem
Organization: University of Western Ont, London
Date: Wed, 6 Jan 1993 13:27:02 GMT

In article <9301052330.AA21443@relay1.UU.NET>, gleeve@galaxy.dnet writes:
> When making up masters for the VMS/L&T sig tapes at the recent
> DECUS symposium, I encountered a problem making a Backup
> saveset which had happened at the prior symposium as well. I thought
> the community might appreciate an alert that this can happen.
> 
> What I did:
>   I ran Backup on a VAX 6660 to create savesets, on the same disk,
>    where the disk had plenty of space (well, it had plenty before
>    I started :-) ). The commands were of the form

   This follow-up is entirely speculative, and only because a colleague
   in our accounting office recently had a problem moving files disk-to-
   disk.  He was *not* creating backup savesets, but shovelling large
   quantities of (sometimes) large files (with the directory structure)
   to another spindle.  His problem was also intermittent, but different
   than what Glen describes.

   He occasionally had the job fail with "quota exceeded" (or some such).
   The problem was *not* disk quota; we monitored that for days before being
   certain.  Last resort was to boost a bunch of his uaf quotas (to match
   those of our operational backup account).  So far (touch silicon) his
   problem has vanished.  Oh, BTW, this is on a VAX 4500 (one processor)
   running VMS 5.5-1.  Disks are all RF72's.

   As I said, this post is speculative.  But there *may* be a common thread.
   If there is, I'm sure this community will discover it.  b.
--
Brent Sterner				AIX System Manager Apprentice
Fast:		<BRENT@uwovax.uwo.ca>	<129.100.2.13>
Medium:		(519)661-2151 x 6036	Fax:   (519)661-3486
Slow:  Computing & Communications Services, Natural Sciences Building
       The University of Western Ontario, London, Ontario, Canada  N6A 5B7
From: anos@trixie.ineab.ikea.se (Anders Ostling)
Newsgroups: comp.os.vms
Subject: Re: Handling multiple client connections with VMS TCP/IP servers?
Date: 4 Jan 93 22:49:26 GMT
Organization: IKEA Northern Europe AB

>Is multi-threading the server (QIOs and ASTs) the only method?  In which case
>how are telnet, rsh, ... connections, that create network processes under a
>different UIC, handled?

	No, DEC has a RTL for such applications. If you are on contract
	for VMS updates and docs, you should have recived a book on
	multithreaded programming, "Guide to DECThreads". This book has
	lots of examples [using C] on how to use the multithreaded 
	library.

	I have not tried it myself, and have not heard about anybody else
	that have used DECThreads. Maybe somebody could give a hint on
	the usability and reliability of these routines.

	Anders

-- 
Anders Ostling <Vax/Un*x Systems Manager>, IKEA Northern Europe AB, Sweden
Voice <+46 42 25 73 08> Internet <anos@ineab.ikea.se>
From: Chris_F_Chiesa@cup.portal.com
Newsgroups: comp.os.vms
Subject: Directory Fun...
Date: Wed,  6 Jan 93 19:06:30 PST
Organization: The Portal System (TM)
Distribution: world


Here's a more detailed update on my experiments with patching the "TYPE"
field of the first entry in a .DIR file (directory), on my VMS V5.4-3 
system.  Jerry, Carl, I'll bet you'll both have a field day with this!

I find that the undocumented DUMP/DIR command recognizes three different
values in the TYPE field, in the sense that it displays a different keyword 
when I patch each of the three values into the field, and "*UNKNOWN*" 
otherwise:

	TYPE field	   DUMP/DIR
	  value		"TYPE" keyword

	    0		     FID
	    1		   LINKNAME
	    2		    TYPED

Patching a value of 3 into the field causes DUMP/DIR to display "*UNKNOWN*"
for this field, and causes the following behavior:

	$ DIRECTORY [.patched_directory]

		- works fine, lists the contents of the directory as usual

	$ DIRECTORY /SEC [.patched_directory]

		- works fine, lists the contents of the directory includ-
		  ing each file's owner, protection, and ACL as usual

	$ DIRECTORY /DATE [.patched_directory]

		- works fine, lists the contents of the directory includ-
		  ing each file's creation date

	$ DUMP [.patched_directory]file.typ

		- fails with the following error messages:

		  %DUMP-E-OPENIN, error opening [filespec] as input
		  -RMS-E-FND, ACP file or directory lookup failed
		  -SYSTEM-W-BADIRECTORY, bad directory file format

		  (And yes, the proper filespec appears in the first
		  message; I've merely edited it for its inclusion in
		  this article.)


	$ BACKUP [.patched_directory]*.*;* SYS$LOGIN:TEST.BCK/SAVE

		- fails with the following error messages:

		  %BACKUP-E-BADDIR, directory [patched_directory] has invalid 
		  format
		  %BACKUP-W-NOFILES, no files selected from [patched_directory]

		  (The proper directoryspec appears in both messages, AS
		  A DIRECTORY, i.e. dev:[dir...patched_directory], NOT as
		  a FILE (dev:[dir...]patched_directory.dir).)

  What other experiments shall I try?   :-)

  Chris

    Chris_F_Chiesa@cup.portal.com
From: RING@JUNCOL.JUNIATA.EDU (John Charles Ring)
Newsgroups: comp.os.vms
Subject: Suggestion & misc. question.
Date: 12 Jan 93 19:12:43 GMT
Distribution: world
Organization: The Internet


   First, I'd just like to say that, maybe? due to the start of a new semester
at academic locations, the number of postings asking for help without providing
enough information seems on the rise, again :-(  I've not looked at our Faq for
awhile; is it made clear in there that information such as:

   Complete & accurate error messages supplied by the machine, and
   how the application/program was invoked.

should, at least, be included for a reasonable chance of understanding the
solution?  If not, it -may- be reasonable to make such quite clear, maybe in
the message sent to a user when he/she subscribes?

   Ok, back to a real (small) question: Does anyone have, know of, a procedure
to perform the inverse of sys$update:vmsinstal, like maybe a deinstall?  I
don't imagine that this is really possible, but I've been wrong before :-)

                                             John Ring
                                             Ring@Juncol.Juniata.Edu
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: HELP! VAX NOT SENSE MAKING!
Date: 4 Jan 1993 07:44:47 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 <091004301292@fruit.botswana.edu>, kpltrw17+@fruit.botswana.af writes:
>HELP MANAGER I AFRICAN NETWORK VEGETABLE AND FRUIT VAXES YES!
>VAX NOT HAPPY, VERY SICK. SAY NO FILE NO RUN! IS NEW IN AFRICA.
>I NOT MANUAL. HELP IS NO FILE NO RUN! SERVICE DIGITAL NOT IN
>AFRICA! INFOVAX HELP PLEASE!
>
>INFORMATIQUE: VAX 11-23 VMS RSTS/E WITH CHUM CHUMS AND BOOR BOORS.
>HELP PLEASE!
>
>GHIANNA KPLTRW
>BOTSWANA

Sorry, but the above is *NOT* a very good spoof of posts by SABRY@SHEBIN.EG.
--------------------------------------------------------------------------------
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: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: re: Question about RMS and MSCP-pair
Date: 4 Jan 93 15:05:09 GMT
Distribution: world
Organization: The Internet


	I discovered some oddity with RMS and MSCP-served disk, at least I
	think so.  I understand that MSCP-served disks (aka RQDX3) may do
	bad-block-revectoring on the attached disk. I also understand that,
	when the original block showes unrecoverable READ-errors, the "forced
	error flag" on the copied block will be set.

No; not quite.  It's a question of "how bad" the original block went.

If the original block went "only a little" bad, the data in it is recoverable
using the ECC (error-correcting code) value stored in the sector.  In that
case, the revectoring logic - whether running entirely in the disk adaptor, or
as part of the driver - calculates what the original data in the block was,
attaches a new ECC value, and writes that to the new block.  It does NOT set
the "forced error" flag; all RMS (and your application) ever see is that some
I/O operation took an unusually long time to complete.

If the original block was BADLY damaged, however, the ECC does not contain
sufficient information to recover.  In that case, the new block is marked
with the "forced error" flag, which indicates that it contains no useful
data:  The data was lost due to the original error.  The "forced error" flag
describes the (lack of) DATA in the block, not the block itself - it will
remain set until you write to the block, at which point it will be cleared
silently.

BTW, the exact boundary between "recoverable" and "badly damaged" blocks
varies with each disk and controller - it's mainly a matter of how large the
ECC is.  For current DEC disks, any error involving less than somewhere in the
low hundreds of bits is recoverable.  Some very cheap third-party drives are
lost if more than 11 bits go bad.

	What I don't understand is why the RMS then refuses to read the file
	where the forced error-block is in. It always returns the (correct)
	error (xxx, forced error flag set). So why does the revectoring take
	place? I don't care if the file is unreadable because of read-errors
	or  forced errors. Or asked different, why isn't RMS showing the file
	as it  is with a warning about the damaged block?

*RMS* does.  The forced error return comes back only when you read the partic-
ular block that has the error in it.  A program, if it wishes, can ignore
the error and continue to access the file.  BACKUP does this, for example.
Many simple programs don't.

	Can anybody give an explanation to me?

	Oh, I know that revectoring bad blocks on the controller-level has
	it's  advantages and I like the concept with the forced error flag BUT
	I don't  like RMS's handling of these blocks.

RMS is doing the only thing it possibly can with these blocks.  Your problem
is with the PROGRAMS that call RMS.  (Note again that, whatever RMS, the
drivers, the programs, etc., may do, the data originally "under" the forced
error is gone.)
							-- Jerry

Newsgroups: comp.os.vms
From: lionel@quark.enet.dec.com (Steve Lionel)
Subject: Re: Variable length records to tape
Organization: Digital Equipment Corporation
Distribution: na
Date: Tue, 5 Jan 1993 02:14:18 GMT


In article <1993Jan4.224831.5366@sobeco.com>, szweep@sobeco.com (Steve Zweep) writes...
>Can someone tell me how to write variable length physical blocks to tape
>with VMS, so that the tape can be read again on a foreign system?
> 

Mount the tape /FOREIGN.  Then whatever you write is what ends up on
the tape.  Write 100 bytes, you get a 100-byte block, etc.  No padding,
no record length.  If you're using RMS (or HLL I/O), you can open the
tape drive by specifying the device name.  To write a tape-mark, close
the file.  This is also pretty easy with $QIOs.

The only caveat is that you can't write blocks shorter than 14 bytes
due to a restriction the magtape driver enacts.

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: HELP!!! Security problem for gurus. [Directories]
Date: 10 Jan 1993 10:16:26 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 <61050112@acf3.NYU.EDU>, tihor@acf3.NYU.EDU (Stephen Tihor) writes:
>Just a note for the purists SECURITY is often misapplied as meaning only
>PRIVACY but in its own technical domain Security means a triad of basic interests and one additional concern at least:
>
>Security = Privacy + Integrity + Availablility
>		+ Accountability

I've heard bad things about the New York educational system in the past, but
didn't think it was this bad.  (C'mon, "triad," then a list of four items?) :-)

>Now different real world enviornments may tip the balance among these items
>so we as professional must make tradeoffs among them and the usual cost and 
>performance parameters [although some argue that performance is part of 
>availability.]
>
>Of course most people are most used to the Privacy aspect of Security since its
>the one that gets the highest weight with most National Security information and
>thrillers.

Hmmm.  I'd've thought that the integrity aspect would be the better known (at
least among computer users and managers);  after all, once integrity is
breached, the other three are vulnerable (admittedly, some privacy breaches can
have the same effect [e.g., if someone violates privacy by snagging a
privileged username/password combination]).
--------------------------------------------------------------------------------
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: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: comp.os.vms
Subject: Re: SHRIDMISMAT error message on NOTES
Date: 7 Jan 93 04:24:02 GMT
Organization: St. Peter's College, US

In article <00966356.3E1E2A60.1584@VAX1.Bemidji.MSUS.EDU>, dmiller@VAX1.BEMIDJI.MSUS.EDU ("Prof. David Miller") writes:
> When attemping to run NOTES on DECwindows (XUI, not MOTIF) on a PC on
> Pathworks, I get the following message ...
> 
> SYSTEM-SHRIDMISMAT Ident mismatch with sharable image
> 
> NOTES (current version)

  If you mean Notes V2.3, consider that the release notes say:

              o  To use VAX Notes with the DECwindows Motif interface,
                 you must install VMS V5.4 or higher, and VMS DECwindows
                 Motif V1.0 or higher. Any other version may result in
                 incorrect operation of the DECwindows Motif interface
                 of VAX Notes.

  I believe this means that Notes will no longer run under non-Motif versions
of DECwindows.

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381
From: david@ittpub.nl (David P. Morgan)
Newsgroups: comp.os.vms
Subject: Re: Using C to read Fortran File
Date: 7 Jan 93 19:20:43 WET+0100
Organization: ITT Publitec R+D BV, Amsterdam


Can you work around this and make the output more suitable for reading by C ?

Include CARRIAGECONTROL='LIST' in your FORTRAN OPEN statement so the
output file has normal carriage control. I think you can also specify
STREAMLF as a keyword for TYPE or CARRIAGECONTROL.

--------------------------------------------------------------------------------
David P. Morgan                        Internet: david@ittpub.nl        |ucannot
ITT Publitec R+D BV                    UUCP:     ...!sun4nl!ittpub!david|readdis
Amsterdam                              PSI:      020412905761212::DAVID |onavt52
From: ecf_stbo@jhuvms.hcf.jhu.edu (CHUNGA is dead, long live CHUNGA)
Newsgroups: comp.os.vms
Subject: Re: Ethernet address (sans code) ?
Date: 12 Jan 1993 10:36 EST
Organization: The Johns Hopkins University - HCF
Distribution: world
NNTP-Posting-Host: jhuvms.hcf.jhu.edu
News-Software: VAX/VMS VNEWS 1.41    

In article <1993Jan12.115708.81@ittpub.nl>, david@ittpub.nl (David P. Morgan) writes...
>> 
>>     $ MC NCP SHOW NODE <node_name> CHARACTERISTICS
>> 
>>     Look for the line starting "Hardware address" in the output.
> 
>it doesn't work on the executor node, of course



$mc ncp sho kno line char






Tom O'Toole - ecf_stbo@jhuvms.hcf.jhu.edu - JHUVMS system programmer 
Homewood Computing Facilities, Johns Hopkins University, Balto. Md. 21218 
>Here comes a jet ski.
>weuh weeuhh weeuhh weeuhh WEEUHH WEEUHH WEEUHH WEEUHH weeuhh weeuhh weeuhh weuh
From: tihor@acf3.NYU.EDU (Stephen Tihor)
Newsgroups: comp.os.vms
Subject: Re: Question about RMS and MSCP-pair
Date: 5 Jan 93 16:57:00 GMT
Organization: New York University

(a) that is not my impression but perhaps I misunderstood Ken bates
when we were talking about it.  (b) So, there is in fact no tool
available to proerply (and in a recomendable or at least guarenteed
safe manner) stress test a disk.  I proposed one that would.  If BAD
worked on DSA disks or if ANAL had a /REWRITE check mode that rewrote
every file on disk those might be sufficient.  I will settle for
testing the currently accessible blocks set since they can be reached
in user mode with normal I/O if you own the disk.  
Newsgroups: comp.os.vms
From: sander@rm222.enet.dec.com (Warren Sander)
Subject: Re: Question of SYSGEN.....
Reply-To: sander@rm222.enet.dec.com (Warren Sander)
Organization: Digital Equipment Corporation
Date: Tue, 5 Jan 1993 16:27:41 GMT


To: SABRY@SHEBIN.EG (Sabry Kotob El-Ganzory)
Cc: 
Subject: Re: Question of SYSGEN.....



RE: all the flames.. If you can't be constructive at least try not to be 
    distructive. The guy asked a question? give him some constructive feedback

Feedback to Sabry,

	You forgot to tell us one of the most important pieces of information
about your VMS system. 


	WHAT KIND OF VAX IS IT? How much memory? What version of VMS?

Your params are probably OK for an 11/750 or even some 3100 models with small
amounts of memory. If it is for a 9000 you can do a lot of tuning to make things
run better.

	First I would try AUTOGEN to see what is says. I'm not the biggest fan
of autogen but for a first pass it can give you some good info. 

	Look at a show memory. Have the pools/packets increased or hit their
limits? IRP, LRP, SRP, NPAGE etc. 

	Do a $INSTALL LIST/GLOBAL/SUM do you have any global sections/pages
		left? 
	Have you run out of process slots?

	Do you have VPA, DECps, SPM, etc installed and running, What do they
	tell you to do. What do their reports say?

	Do you have any money? Hire a consultant or Digital to help tune
	your system. Make sure they show/teach you what they do so you can do
	it if it ever has to be done again.

	Go to a course given by Digital or Decus on tuning your VAX

	Find other VAX system managers in your area and talk with them, ask
	them if they have a system similar to yours that is running the same
	sorts of applications as you do. See if they will give you a copy of
	their params. Study the differences and don't make any changes until
	you understand the implications of the change.

Hope this gives you a start..

Warren Sander - Systems Consultant - Digital Equipment Corp
From: brennan@tango.cchs.su.oz.au (Luke Brennan)
Subject: RE: 5.5 Upgrade blues.
Organization: Cumberland College of Health Sciences
Date: Sat, 9 Jan 1993 17:11:45 GMT

In article <9301070001.AA20914@ucbvax.Berkeley.EDU>, simons/G=Colin/I=CB/S=Sewell/O=H.A.Simons.Ltd/OU=CORP@mhs.attmail.com writes:
> carl kacher writes:
> !In a previous article, DAHMS@ifk20.mach.uni-karlsruhe.de (Heribert Dahms) wrote:
	[...]
 
> 	i think everybodys missing the real problem. the original
> 	post contained "file not open by dcl" errors at the beginning
> 	of the vms upgrade phase II. i had the same problem and found
> 	out that the upgrade process was running out of virtual memory
> 	for the process i/o segment when opening dcl files. the solution

	EXACTLY...

> 	was to crash the system at phase II, bring the system up under
> 	conversational boot and increase PIOPAGES (and maybe CTLPAGES too)
> 	at "sysboot>". continuing from that point starts phase II again
> 	and everything procedes normally.

	I've been trying to post that this DID fix the problem..
	(thank you!! thank you!!) but the central newserver went
	bezique :-}

 
> 	and yes, the VMS055.% savesets must be in the [00000] dir of any
> 	locally accessible disks.

	yep.. worked fine.

	I just autogenned with PIOpages and CTLpages bumped up by
	50-odd (I can't remember precisely) to be the same as a
	VAXstation 4000 I was able to check with.
	I then recommenced and it chugged away beautifully.
	Note: I *still* had the password checking (phase II or IV ?)
	go weird, but was able to ignore that..
	(the bit where it invokes AUTHORIZE was complaining about
	<something I can't remember> memory exhausted or something.)

	anyway.. it's all up and running!!! YAAYY! :-)

	can someone explain why a 3100 has DEFAULT settings that
	are too low to allow a &^@$@% upgrade???!!! :-}
	What precisely do these params do? I wouldn't have thought of
	it.. without the net I'd still be prostrate over the console :-}

	thanks again Colin!! (whew!)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Luke Brennan                             e-mail:      brennan@cchs.su.oz.AU +
+ EDP Unit, S209                          brennan%cchs.su.oz.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   +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+