HDTenEightyP/NetNews huggingface dataset:
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: VAX c
Date: 27 Dec 1992 07:41:27 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 <1992Dec26.100030.299@rlgsc.com>, gezelter@rlgsc.com writes:
>I will admit that the following solution is a bit of hitting a 
>small ant hill with a large explosive, but ...

If memory serves, it's even worse than that!

>When the time expires, close the file. Then re-open it in append 
>mode. This will ensure that all of your buffers are flushed out 
>to the disk.

I tried that once.  Maybe it had to do with the way the file dealt with
records, but what I ended up with with was a file that had *ONE* record per
block.  Not what one would want.

Now, DEC support recommended an "undocumented and unsupported" routine.  I'm
99.9999999999999999999999% certain that this routine was one that returned the
RAB associateded with a file id.  Given that, the worst that could happen if
you tried to use it (i.e., ran the routine, then tried to do a SYS$FLUSH on the
RAB at the address returned) would be that you'd get a status complaining about
an invalid stream identifier (OK, OK, there's a [n infitesimal] chance that if
the routine failed to work properly, it would return the address of SOMETHING
that looked like a valid RAB, and who knows what would happen then?  But do you
have any idea what the odds are against that?)

>If I remember correctly from the original post, the application 
>in question is not a high bandwidth application. The periodic 
>close/reopen cycle should not appreciably increase your CPU 
>consumption.

CPU's not the problem here.  The problem is that every time you do it, you use
up another block on the disk.

>I hope that the above is helpful. If I have been unclear, or if I 
>can be of further assistance, please feel free to contact me via 
>Email or phone.

Please note that I'm not trying to put Bob down;  his solution WILL work;  but
it uses up lots of disk space.  The better alternative is to use the
"undocumented and unsupported" function that returns the RAB associated with
the file descriptor, and do a $FLUSH on that.

IMNSHO, there ought to be a documented and supported (though perhaps
discouraged) way to get the RAB associated with a file descriptor [anybody from
DEC listening?  You guys've probably got what you think is a good reason for
not doing this:  care to share?])
--------------------------------------------------------------------------------
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: anos@elmrd6.ineab.ikea.se
Newsgroups: comp.os.vms
Subject: Connection rejected by remote host
Date: 22 Dec 92 09:47:24 GMT
Organization: IKEA Northern Europe AB

Broadcast to all network gurus ;

I have a problem with RT-terminals (or lack of them ;-) on a system that
previosly was used via LAT, but not any more. Since we moved it away from
our LAT network we can't create enough logins

	%SYSTEM-F-REJECT, connect to network object rejected

I'm pretty sure that some system parameter (or possible PQL's for the
REMACP on the remote node) is involved, but can't find what parameter
to modify. Does anybody have a quick answer (or not so quick, but correct)?

Christmas Greetings

Anders

+------------------------+--------------------------------------------------+
| And my name is ...     | Anders Ostling				    |
| employed by ...        | IKEA Northern Europe AB (INEAB)                  |
| located in ...         | Helsingborg, Sweden                              |
| Return mail address to | anos@ineab.ikea.se				    |
| Phone                  | +46 42 15 29 06                                  |
+------------------------+--------------------------------------------------+
From: system@condor.navsses.navy.mil
Newsgroups: comp.os.vms
Subject: re: How do I use more memory?
Date: 29 Dec 92 18:57:13 GMT
Organization: NSWCCD, Naval Ship Systems Eng Sta, Phila PA

In article <9212282032.AA07085@uu3.psi.com>, leichter@lrw.com (Jerry Leichter) writes:
> 
> 	I've recently acquired a VAXstation with 80 Mbytes of physical memory,
> 	and I would like to use the memory almost exclusively to run really
> 	big (large arrays) scientific computational code. I'm more than
> 	willing  to sacrifice other management concerns.  
> 
> 	and boosted up my user authorizations to:
> 
> 	   WSdef:          150     
> 	   WSquo:       163840    
> 	   WSextent:    163840
> 
> This will work, but I would recomment making WSQUOTA smaller - perhaps 40000
> or so at most.  When the system has plenty of free memory (as it should for
> what you are trying to do to make any sense) WSQUOTA will be pretty much
> irrelevant, as a process that needs memory will be limited by WSEXTENT.  But
> there are going to be times when you want to run a couple of big, but not
> really huge processes, and it's nice to have the WSQUOTA control in effect.
> 

Why would you want to force every image you run to have to work very hard to
get a decent working set size each time you run it.  When you activate an image
the system sets your working set limit to the size specified by the WSdef value
in your uaf record.  The system will then increase your working set limit by
WSINC if your fault rate is above PFRATH over the period specified by AWSTIME. 
What I have set up for most of the users on my 6000's (Each has 256MB) is
something like this:

	WSDef:  8192
	WSQuo:  8192
	WSExt: 16384

This way a proccess' working set limit will start high and therefore it will
not have to fight the system for increases to its working set limit.
-- 
Mike Jacobi
NAVSSES VAXCluster system manager
System@Eagle.Navsses.Navy.Mil
System@Condor.Navsses.Navy.Mil

Disclaimer - I speak for myself.  No-one else.
Xref: sparky comp.os.vms:20201 vmsnet.admin:501
From: michaelb@wshb.csms.com ( WSHB Operations Eng)
Newsgroups: comp.os.vms,vmsnet.admin
Subject: Zmodem
Date: 31 Dec 92 21:31:49 GMT
Followup-To: comp.os.vms
Organization: WSHB, Herald Broadcasting Syn., Inc., Cypress Creek, SC, USA

I have some associates who do not have easy access to the net and have
asked me to post a question about zmodem for them. I'm not much on VMS, so
I plead ignorance about the correctness of the question. It seems to me
they simply want to add zmodem as a choice on a menu program written in
whatever VMS uses as a user shell. If responses could be directed directly
to him, cosseboomm@rachel.csps.com, I would appreciate it. Anything that
comes to me I will forward. Thanks. Here is the text of his message.

=======================

Date: Tue, 29 Dec 92 20:14:40 EDT
From: <cosseboomm@rachel.csps.com>
To: wshb!michaelb
Subject: zmodem information needed from network


	We would like to use the file transfer protocol called
zmodem which we received from decus in our vax vms command
procedures.  We need to know how to code the dcl
command so we can send a file from our pc to vax.  I need the
filename to be a differant name then what is on the pc so we can
properly dispatch it to the user or to automatically include in
an application.  I know how to this with the protocols kermit
and xmodem but what do I do for zmodem?

	Can anyone help?


======================

Thanks,
Michael
-- 
Michael Batchelor--Systems/Operations Engineer #compliments and complaints
WSHB - An International Broadcast Station of   #   letterbox@csms.com
       Herald Broadcasting Syndicate, Inc.     #technical questions and reports
michaelb@wshb.csms.com         +1 803 625 5552 #   letterbox-tech@csms.com
From: SKELTON@MMC.BITNET (Hank Skelton)
Newsgroups: comp.os.vms
Subject: Grammatical Irrelevancies
Date: 29 Dec 92 17:20:44 GMT
Distribution: world
Organization: The Internet

>
> you'd be better off picking up a dictionary, grandstander.
> also a style guide, since very few english sentences should end with ellipses.
>
> murphy@npri6.npri.com 602 Cameron St. Alexandria, VA 22314 (703) 683-9090

Well, as long as we're completely off the subject of VAXes and their uses,
perhaps you should borrow the style guide when he's finished with it, since
very few English sentences should begin with lower-case letters (unless
you're e. e. cummings).

            Hank Skelton - Meharry Medical College
             Computer Center, Nashville, TN 37208
            BITNET: SKELTON@MMC       615/327-6289
          INTERNET: SKELTON%MMC@CTRVAX.VANDERBILT.EDU
            "That's my opinion - oughtta be yours"
From: Plain@FandM.edu (Jack Plain)
Newsgroups: comp.os.vms
Subject: Phone Number for Standard Memories
Date: 21 Dec 92 18:09:49 GMT
Distribution: world
Organization: The Internet

Would anybody have a current phone number for Standard Memories or WesPac
Peripherals?
I have the these numbers disconnected numbers:
714-583-7500
714-851-6700
714-851-8622
800-543-3323
800-247-9313
Thanks


Jack Plain
Franklin and Marshall College
Plain@FandM.edu


Newsgroups: comp.os.vms
From: shibuya@bl.applicon.slb.com (Hiroto Shibuya)
Subject: Re: VAX-C SHELL$FIX_TIME and SHELL$MATCH_WILD
Reply-To: shibuya@bl.applicon.slb.com
Organization: Applicon; Billerica, MA (USA)
Distribution: comp
Date: Thu, 31 Dec 1992 02:03:48 GMT

Following up on myself.

Hiroto Shibuya writes:
>   I was trying to port Todd Aven's VMS/MAKE v3.4 to Alpha and got the
>   following undefined symbols at the link time.
>
>	   SHELL$FIX_TIME
>	   SHELL$MATCH_WILD
>
Well, I found corresponding functions DECC$FIX_TIME and
DECC$MATCH_WILD on Alpha.

hiroto
From: DWING@UH01.Colorado.EDU (Dan Wing)
Newsgroups: comp.os.vms
Subject: Re: TT_AccPorNam field remains null on a SHOW USERS output ?
Date: 29 Dec 92 16:32:34 GMT
Distribution: world
Organization: The Internet

Pete Sabotka, sabotkap@woods.ulowell.edu, writes:

>From a terminal hardwired to the system (ours is VMS 5.4):
[...]
> Username  Node   Process Name    PID     Terminal
> SABOTKA  CIRRUS  SABOTKA       202060C2  TTA0:
>                                           ^ (hardwired terminal)
>
>When logged in from a server, or remote system, the server/remote port
>information is sometimes left blank:
>
> Username  Node   Process Name    PID     Terminal
> SABOTKA  CIRRUS  P. Sabotka    20206DCB  LTA2633: (FOG::NETWORK)
>                                                   ^ (we can't always get this)
>
>
>When logged in from a non-hardwired terminal, when during login is the
>TT_AccPorNam information obtained ?  It seems a SET TERMINAL/INQUIRE in
>our SYLOGIN.COM is responsible for getting this field, but at other times,
>an otherwise normal login will not retreive this information.

(To the best of my limited knowledge) LOGINOUT.EXE is responsible for setting 
this field.  The purpose of this field is to identify a non-hardwired (for 
example, via your network) login's source.  Because TTA0: is hardwired, you 
always know its physical location.  If you identify the offending DECserver 
or remote system to your system manager, I believe he/she may be able to 
explain why it isn't happening.  The terminal server sends this information
to the VMS system.  Prior to VMS V5.2 (?), this information wasn't displayed
by SHOW USERS; I don't know if the version of LAT (or LAT+, or whatever it
was at that time) didn't send the information to the VAX, or if the VAX
couldn't handle displaying or storing it.  Someone more familiar with the
history of this field, and maybe access to sources, could explain why and
how this came about.

>My motives: We have a captive account which we would like to monitor by
>            writing the login time, and any server/remote port information
>            to a log file.

If TT_ACCPORNAM is blank, then store the terminal-name in your audit-log file 
or whatever, something like:

     :
  $ ACCESS_PORT = F$GETJPI(0,"TT_ACCPORNAM")
  $ IF ACCESS_PORT .EQS. "" THEN ACCESS_PORT = F$GETJPI(0,"TERMINAL")
  $ WRITE LOG_FILE F$GETJPI(0,"USERNAME"), ACCESS_PORT, F$TIME()
     :

... Somewhat related to this, it shore would be 'cool' if DEC could include
this same information for the FTAnn: devices for X terminals.  Ah, well, 
maybe next version?

-Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11)
 Systems Administrator, University Hospital, Denver
From: gege@CAL.ENST.FR (Why not ?)
Newsgroups: comp.os.vms
Subject: NEWS Posting to comp.os.vms
Date: 22 Dec 92 16:58:27 GMT
Distribution: world
Organization: Ecole Nationale Superieure des Telecommunications, Paris
From: gege@cal.enst.fr (Why not ?)
Newsgroups: comp.os.vms
Subject: Re: Disable proxies with LPD under UCX 2.0
Date: 22 Dec 92 11:58:12 GMT
Organization: Centre de calcul, E.N.S.T. Paris

In article <9212211106.AA12410@ucbvax.Berkeley.EDU>, gloesener@ISTVAX.IST.LU writes:
> 
> Hi,
> 
> I've installed UCX 2.0 last week and tried the LPD for use with a SUN station.
> Every time when the SUN wants to print UCX complains about a missing proxy
> for the user which want to print. Now I want to setup LPD to be accessible
> for any user on that machine. I've tried to eliminate the PROXY flag from
> the service with 'SET SERVICE LPD/FLAGS=NOPROXY' after enabling the LPD,
> the flag had disappeared but it is still complaining about missing proxies.
> Can anybody help me here ?
> 
	you should disable the 'APPLICATION_PROXY' flag

================================================================================
! Guillaume Gerard                ! Email  gerard@enst.fr                      !
! Systems responsible             ! X400   C=FR AD=ATLAS PD=TELECPARIS         !
! France Telecom University       ! PSI    *2080750412855::gerard              !
================================================================================
%SYSTEM-W-TMNYFNGRS, too many fingers on keyboard
From: mcmahon@TGV.COM (Looking for a corner at Dupont Circle)
Newsgroups: comp.os.vms
Subject: Re: There is any way to disable pause in DECwindows Session Manager ?
Date: 21 Dec 92 17:49:00 GMT
Distribution: world
Organization: The Internet

In article <1992Dec21.122611.28201@ghost.dsi.unimi.it> you write:
=>I have some Vaxstations in a common work area, which are mainly used as
=>X-term. Many users use Pause function in order to reserve the work place and
=>I must restart DECwindows server in order to restore the access to the system
=>when these users go home. I wonder if there some way to disable the pause
=>function.

Under DECwindows Motif, the Pause screen function is handled by a 
separate image (DECW$PAUSESCREEN.EXE in SYS$SYSTEM I think).  I expect
that if you put an ACL on it to prevent people from executing it they
would be prevented from pausing the screen. 
--
John 'Fast-Eddie' McMahon    ()
TGV, Incorporated            () "Any networking problem can be solved by
603 Mission Street           ()  the application of 33 miles of Unshielded 
Santa Cruz, California 95060 ()  Twisted Pair (UTP)"   
408-427-4366 or 800-TGV-3440 ()                      [InterOp Spring 1992]
E-Mail: MCMAHON@TGV.COM      ()
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: re: Re: HELP!!! Security problem for gurus. [Directories]
Date: 30 Dec 1992 11:19:05 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 <9212290242.AA00964@uu3.psi.com>, leichter@lrw.com (Jerry Leichter) writes:
>BTW, it's not impossible that SOME invalid directory entries will could cause
>(probably non-fatal) bugchecks.

Hmmm.  After the way DEC screwed up the V5.4 release*, I don't really believe
in "non-fatal" bugchecks any more.

I *THINK* it was 5.4.  Maybe it was 5.2.  The old-timers know what I'm talking
about:  The time some DEC developer didn't change the SYSGEN parameter
BUGCHECKFATAL back to FALSE before shipping (for those not familiar with this
sysgen parameter, if it's set to TRUE, then *ALL* bugchecks are fatal.  It's
intended [as best I can tell] [almost {maybe}] exclusively for DEC developers
to use while they're testing a new version of the operating system.  When
something goes wrong, they get a nice system dump, which allows them to debug
the O/S.  On a production system, you don't normally want a continuable
bugcheck to give you a system dump.  The sudden >>> prompt on the console might
confuse somebody :-).
--------------------------------------------------------------------------------
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.
Newsgroups: comp.os.vms
From: jweiss@casbah.acns.nwu.edu (Jerry Weiss)
Subject: Re: UCX TELNET name.name.name portnumber -- How?
Organization: Northwestern University, Evanston Illinois.
Date: Mon, 21 Dec 1992 21:18:13 GMT

>In article <1992Dec21.092203.1@gallua>, CADS_COLE@GALLUA.BITNET (Kevin Cole; Washington DC) writes...
>>[Since vmsnet.networks.tcp-ip.ucx appears dead, I thought I'd try here...]
>>I notice that I cannot type:
>>       telnet name.name.name portnumber
>>(It complains that it can't find a host record.)  But I can type:
>>       telnet name.name.name
>>and    telnet number.number.number.number portnumber
>>Why does it understand one and not the other?  And is there anything *as a user
>>not a systems manager* I can do about it?  Is there a way to feed it the 
>>parameters in a way that it will understand that it should translate the host
>>name to the numeric address and then apply the port number?  Or am I misdiag-
>>nosing the symptoms? 

If you have UCX 1.X, then your observed behavior is a known bug.
It was fixed in UCX 2.0.


-- 
Jerry S. Weiss	  "If you can't stand the heat, stay out of the antimatter!"
j-weiss@nwu.edu    Dept. Medicine, Northwestern Univ. Medical School
From: powers@ELROS.STG.TRW.COM
Newsgroups: comp.os.vms
Subject: Re: Need VMS Gopher Client
Date: 29 Dec 92 20:36:15 GMT
Distribution: world
Organization: The Internet


tihor@acf3.nyu.edu (Stephen Tihor):
> the gopher client seems to be missing the link file.
> The Xgopher client seems to need the DEC C RTL rather than the
> VAXCRTL (eg the ansi C stuff.)

1.  I believe that link files are things used only by gopher servers.  I have
    no link file with my gopher client on VMS, and the software doesn't
    miss it.  As I recall, the only external file needed by the client is
    the help file.

2.  The VMS Xgopher client from Ohio State (FTP job.acs.ohio-state.edu)
    uses the plain ol' VAXCRTL.  One problem with the Xgopher client:  It
    will crash mysteriously and with great violence if it hits a security
    restriction on your own local computers.  I don't recall the nature 
    of the crashes -- access violations or worse (probably worse) -- but I do
    remember that it is VERY misleading.  That could, perhaps, lead a person
    to mistakenly think that there is a RTL problem or some other weird thing.

       Lester Powers
       powers@elros.stg.trw.com
       (E-mail receipt iffy here -- no electricity for our domain nameservers)


Newsgroups: comp.os.vms,vmsnet.tpu
From: reinig@augie.enet.dec.com (August Reinig)
Subject: Re: Help on "simple" EVE/TPU procedure
Reply-To: reinig@augie.enet.dec.com (August Reinig)
Organization: Digital Equipment Corporation
Date: Tue, 22 Dec 1992 14:51:06 GMT

Untested, but the following should truncate each line in the file 
to 72 characters and then remove any trailing blanks.  With a small
modification, the truncate count could be a parameter to the routine
but I can't remember the EVE syntax for this off the top of my head.
Perhaps Bill will oblige.

This routine won't work if there are tabs in the sources.  There
are EVE routines to change tabs to spaces which you should use 
first if tabs are present.

				August G. Reinig
				

procedure eve_truncate

local
    pat1,
    r1;

pat1 := LINE_BEGIN + arb(72) + (remain @ r1);
position (buffer_begin);
loop
    exitif search_quietly(pat1, forward, exact) = 0;
    position(r1);
    erase(r1);
endloop;

edit(current_buffer, trim_trailing);

endprocedure;
From: phaniraj@plains.NoDak.edu (V. Phaniraj)
Newsgroups: comp.os.vms
Subject: Bypassing missing F11BXQP on startup ?
Date: 25 Dec 92 23:57:03 GMT
Article-I.D.: ns1.BzuAJ3.LoE
Organization: North Dakota Higher Education Computing Network

Hi

After the VMS 5.5-2 upgrade, we've notivced some missing files.
For ex., SUBMIT.EXE was missing from SYS$SYSTEM. Today I did
a standalone backup and restore of the system disk, and it appears
that F11BXQP.EXE is also missing. The system startup fails with the
error

SYSINIT-E Error mounting system device, status=07280b4
SYSINIT-E Error opening or mapping F11BXQP, status = 00018272.

I don't want to go to an older backup just yet, so are there any ways
around this ? I have a recent standalone backup created with
STABACKIT on another disk, could this be used along with backup/noinit
to be of some use ? Xmas day is a bad day to get into such a mess :-)

Dr V. Phaniraj  phaniraj@plains.nodak.edu  (701) 298-1024
-- 
V. Phaniraj					phaniraj@plains.NoDak.edu
Assistant Professor, Electrical Engineering	phaniraj@ndsuvm1 (BITNET)
North Dakota State University, Fargo ND 58105	(701) 298-1024 (work)
						(701) 237-8677 (FAX)
From: MORRIS@PATRICK-PIMS.AF.MIL ("Jay Morris")
Newsgroups: comp.os.vms
Subject: RE: Request for sources
Date: 23 Dec 92 13:04:00 GMT
Organization: The Internet

>From:     "Kevin Mitnick" <FZC@CU.NIH.GOV>
>Date:     Tue, 22 Dec 1992  21:44:47 EST
>Subject:  Request for sources
>
>Can someone E-Mail me the sources to VMS?
>
>Thanks, Kevin
>

While you're at it, could someone E-transfer me a couple hundred thousand $?

(^: Merry  Christmas!

j
morris@patrick-pims.af.mil
From: ercn50@castle.ed.ac.uk (Lifesupport)
Newsgroups: comp.os.vms
Subject: Backup question
Date: 29 Dec 92 11:27:08 GMT
Organization: Edinburgh University

Hi All - Seasons Greetings !! - can someone/anyone help with the
following ? - any HELP much appreciated ...

------------ forward message -------------------------------------------
                 I have a situation whereby a user has identified a loss
of data on a magtape (the magnetic tape should contain data going back
quite some time but the savesets on the tape only go back a few months).

I can only assume that the tape had been initialised at some stage this
is reinforced by the fact that the first saveset on the tape is not the
start of a saveset.

What I think has happened is that a backup to tape requested mounting a
second (relative) volume and by mistake the same volume was loaded hence
causing the tape to be initialized and this would explain the fact that the
first saveset on the tape is not the beginning of the saveset.

My question  is how can I recover data from the initialized tape ...
------------  end forward message ----------------------------------------

Kenny Stevenon
Edinburgh University Computing Service
From: kpltrw17+@fruit.botswana.af
Newsgroups: comp.os.vms
Subject: HELP! VAX NOT SENSE MAKING!
Date: 31 Dec 92 12:08:21 GMT
Reply-To: <info-vax@ucbvax.Berkeley.EDU>
Organization: The Internet
X-Unparsable-Date: Wed 30 Dec '92

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