HDTenEightyP/NetNews huggingface dataset:
From: ecf_stbo@jhuvms.hcf.jhu.edu (UNIX of course, now what was the question?)
Subject: Re: Question of SYSGEN.....
News-Software: VAX/VMS VNEWS 1.41    
Organization: The Johns Hopkins University - HCF
Date: Tue, 5 Jan 1993 20:07:00 GMT

In article <1993Jan5.162741.22277@nntpd.lkg.dec.com>, sander@rm222.enet.dec.com (Warren Sander) writes...
>Feedback to Sabry,
> 
>	You forgot to tell us one of the most important pieces of information
>about your VMS system. 


I think is a VAX 3500, by 12Mb with vms 5.5-1.


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: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: re: RE: SYSDUMP.DMP File Question...
Date: 10 Jan 93 21:48:31 GMT
Distribution: world
Organization: The Internet


	Are there any other side effects for managers that have no page/swap
	files on the boot drive?  Is VMS non-paged until a pagefile is
	installed and present?

Not quite.  The system must be able to get through startup to the point where
the first pagefile is installed without requiring the use of a pagefile, but
keep in mind that a great deal of paging activity goes directly to image
files:  Read-only image sections (all code, for example) will never end up in
the pagefile.

Theoretically, startup can deadlock if there is not enough physical memory.
At one time, this was a significant issue, which usually showed up not so much
when there was no primary pagefile as when SAVEDUMP was set to 1, making a
large piece of the pagefile inaccessible until an ANALYZE/CRASH could be done.
Given the amount of main memory on modern systems - many have more main memory
than many VMS systems of 10 years ago had disk space! - this is very unlikely.

BTW, the same considerations apply to a primary swapfile - though many systems
these days do entirely without a swapfile, primary or otherwise.

			        Is the boot drive pagefile faster or better
	for the primary system processes that get created before external
	pagefiles are installed?

No; there's no longer any difference.  (At one time, there were things a
primary pagefile could be used for that secondary pagefiles could not, but
that's all history now, with the sole exception that even today, only the
primary pagefile can be used for dumps if no SYSDUMP.DMP exists.)

				  Just curious...

Yellow or Blue?
							-- Jerry
From: gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546)
Newsgroups: comp.os.vms
Subject: Re: Boot VAX3800 problem, help please!
Date: 6 Jan 93 04:19:00 GMT
Reply-To: gavron@ACES.COM
Organization: ACES Consulting Inc.
News-Software: VAX/VMS VNEWS 1.4-b1

In article <1993Jan5.175824.4035@proton.llumc.edu>, lin@primus.llumc.edu (P. James Lin) writes...
# 
#When I boot VAX3800 VMS5.3-1 which recovered for power supply failured,
#message
#	Error opening primary input file SYS$INPUT
#	Error in device name or inappropriate device type for operation
# 
#What is it? How Should I take care of it?

	I suspect that somewhere in your startup procedures you
	are using SYS$INPUT.  Instead of SYS$INPUT which may point
	to the startup database, use SYS$OUTPUT which points to the
	console output.  

	Normal .COM file: $ define sys$command "''f$trnlnm("sys$input")'"
	Startup .COM file:$ define sys$command "''f$trnlnm("sys$output")'"

#P. James Lin                      INTERNET: lin@proton.llumc.edu
#Radiation Research Laboratory     UUCP    : ..ucrmath!proton!lin 
#Loma Linda University Medical Center, 11234 Anderson St., Loma Linda, CA 92354
#Tel: (714)824-4066 FAX: (714)824-4067

	Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com
Can I have an IMPULSE ITEM instead?
From: gavron@it.sunquest.com (Ehud Gavron 602-570-2546)
Newsgroups: comp.os.vms
Subject: Re: Non-privileged REPLY program?
Date: 13 Jan 93 02:18:00 GMT
 <11JAN199319283363@spades.aces.com> <1993Jan12.191041.7327@organpipe.uug.arizona.edu>
Reply-To: gavron@ACES.COM
Distribution: world,local
Organization: ACES Consulting Inc.
News-Software: VAX/VMS VNEWS 1.41AXP

In article <1993Jan12.191041.7327@organpipe.uug.arizona.edu>, 
vance@lpl.arizona.edu (Vance Haemmerle x4021) wastes bandwidth...
#In article <11JAN199319283363@spades.aces.com> gavron@ACES.COM writes:
#>#	   STATUS = LIB$DO_COMMAND( '@SYS$LOGIN:MAIL.TMP')
#>#	   CALL EXIT( STATUS)
#>
#>NB: LIB$DO_COMMAND does not return to the caller, so your exit
#>     won't really execute.
#>
#>	Ehud
#>
# 
#   Bzzzt. 

Bzzzt?  BZZZT?!  You can't read Macro, have a moron's grasp of Fortran,
no talents to speak of which leaves you mired as a minor flunky at the U of A,
and you think you can use the word "bzzzt."  Go buy some balls, little boy.

#   'If successful' being the key phrase.  LIB$DO_COMMAND can return the 
#   following condition values: ... 

not...

Go check out [.LIBRTL.LIS]LIBDOCOM.LIS which says:
! SIDE EFFECTS:
!
!       Does not normally return to its caller.

Then go check out the listing of EXE$CLI and if you get someone to read
the MACRO code to you, and go look at the original posting, and even
someone as dense as you will discover why the code would NOT get an 
error back, and why you are a weasel. (Please don't post any more
useless command procedures either.)


#--
# Vance Haemmerle                              vance@arizona.edu
# Support Systems Analyst, Senior              vance%toyvax@arizona.edu
                                                     ^^^^^^

Yes, go back and play with your toys.  (with apologies to Don ;-)

Ehud

--
gavron@aces.com
Do you feel FUCKED yet?  I'm not even WARM!  Yow!
From: JOE@SPOCK.FHCRC.ORG (Joe Meadows)
Newsgroups: comp.os.vms
Subject: Re: Running old executables on later VMS versions
Date: 8 Jan 93 01:43:00 GMT
Distribution: world
Organization: The Internet

>> It is strongly suggested that applications be recompiled and relinked as
>> part of a major operating system upgrade. You indicate the problems started
>> after the recent upgrade, I would start there.
>
>This seems to be one of those persistent myths about VMS.
>
>I don't know who "strongly suggests" this.  Most applications do NOT need to
>be recompiled and relinked for VMS upgrades.

Actually, I recall statements such as this being made in the release notes for
at least one version of VMS, if not several.

The first time was when they broke up VMSRTL into several images (forgive a
possibly fading memory, it was one of the run-time libraries however, if not
VMSRTL) and they suggested that you relink to improve image activation time.

The most recent time was when they introduced the "modular executive". Of
course, the idea with introducing the modular executive was to further reduce
the amount of relinking required (for images linking against the executive
that is).

Other times have generally been for specific reasons, such as the TPU case
cited earlier. In fact, the callable tpu fiasco was the first time I ever had
non-internals code break from an upgrade (call me lucky [or carefull]).

I'd say VMS has done a very good job of maintaining compatability, and as
Jamie points out, there were & are several very old pieces of VMS code sitting
around that still work just fine.

While there have been things that they have obsoleted, generally that just
means they stop documenting a routine or interface (or at least move it to the
obsolete features manual). Off the top of my head I can't even think of one
that has actually been removed. Of course, not actually killing these things
has been what allows old code to run so well, but on the flip-side it's also a
fair bit of extra baggage to be carrying around!

Anyone care to dredge up some old memories? It's gotta be a lot funner than
the flame-fest we've been having lately (not to they they haven't been
somewhat humorous, but even [name-your-comedian-here] gets boring after a
while).

Cheers,
Joe Meadows meadowsj@boeing.com

Newsgroups: comp.os.vms
From: pyron@skndiv.dseg.ti.com (Dillon Pyron)
Subject: Re: How to run DECwindows clients on non-dec workstations
Reply-To: pyron@skndiv.dseg.ti.com
Organization: TI/DSEG VAX Support
Distribution: usa
Date: Mon, 11 Jan 1993 19:26:35 GMT


In article <1993Jan11.180930.11077@news.nd.edu>, losecco@undpdk.hep.nd.edu     (John LoSecco) writes:
>We have numerous non dec workstations, sun, IBM, Silicon Graphics, HP.
>We would like to run DECwindows clients, such as DECterm on these
>workstaions.  The problem is DEC provides no ``supported'' way to map
>the keyboard on the VMS version.  (The ultrix manual even includes an
>example to do remapping.)

Can we get some terminology straight.  The client is the computer which
actually runs the software.  The server is the display system (computer or
X-terminal) that displays the output.  A client running DECterm will, by
definition, always be a VAX.  The server can be a Whateverthehell Model 200.

>
>The biggest, but not only, problem is DEC's use of the non standard rubout
>for delete and not the backspace.  Most of our systems are unix or PC based

That's odd, my cubey's IPC, as well as all the other Suns I know of, use DEL as
delete and ^H to annoy us.  :-)

>and come with keyboards that emit backspace.  The only solution DEC
>would propose is to use xmodmap to remap the server's keys.  This blows away
>most local use and use on other unix clients, without a great deal of remapping.

The LK201 emits a backspace as (I think) F12.
>
>Surely, since DECwindows originated with xwindows, there is an ``unofficial''
>way to remap the client keyboard.

Once again, please be clear on what you mean by client.  If you mean server
(displayer), then the mapping should not really be a problem, since you are
really using the HP/Sun/IBM(arrgh) keyboard, and all have a true DEL key.  If
you are running xterm on the Unix box and displaying on the VAXstation, there
should not be a problem using F12.
>
>Our present access to vax is via telnet in an xterm window with a remapped
>keyboard.  We would like to use X too.

Part of the problem is the sloppy terminology.  But we get to live with it now.
>
--
Dillon Pyron                      | The opinions expressed are those of the
TI/DSEG Lewisville VAX Support    | sender unless otherwise stated.
(214)462-3556 (when I'm here)     |
(214)492-4656 (when I'm home)     |"Pacts with the devil are not legally
pyron@skndiv.dseg.ti.com          |binding!"
PADI DM-54909                     |-Friar Tuck   _Robin Hood:The Hooded Man_
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: SYSDUMP.DMP File Question...
Date: 11 Jan 1993 10:29: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 <1993Jan11.185512.1@tango.cchs.su.oz.au>, brennan@tango.cchs.su.oz.au (Luke Brennan) writes:
>
>	Ehud,
>		are you telling me that all those little squares on that
>		bit of the map to the right AREN'T part of Queensland???

Well, if you look *DOWN* and to the right (OK, maybe you've got to look pretty
far to the right), you'll find something called the Ross Dependency.  Take a
look at who's in charge of that area sometime.

>		hell.. just when I thought I had the world figured.. :-}
>		ahh.. *now* I understand why the timezones are so far
>		behind for that part of OZ.. er.. USA.. :-)

Puerto Rico is also a part of the U.S.A.
--------------------------------------------------------------------------------
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: gleeve@galaxy.dnet
Newsgroups: comp.os.vms
Subject: Re: movefile query
Date: 4 Jan 93 14:26:21 GMT
Distribution: world
Organization: The Internet

There are a couple longs for additional operation status codes in
a FIB. The Movefile primitive uses one of these (see the i/o support
manual chapter on ACP interface for detail) to report what the
movefile actually did.

Incidentally, I have implemented a softlink facility for VMS, embedded
in the filesystem, using some of the techniques described in the last
magic session at DECUS. (<evil grin for those who wanted humor and
didn't listen...you'll have to wait for the next symp. where I can
give a regular session...>). Unfortunately, not being DEC, it doesn't
er, I didn't use the normal directory file hooks...can't easily break
into the relevant parts of RMS. (Pardon the garble...someday I'll compose
using an editor :-) ).
   Forcing an open of another file is simple. The tricky stuff is handing
the markings in some kind of sensible way and getting the user channel
back where he expects it when close occurs. Fail to do that and all sorts
of odd, but generally harmless, things happen.
   There are conceptual issues too. On a VMS system, you can reasonably want
a link not to a device, but to a volume on that device. It's interesting to
check for these, but has to be a user option; imagine the pathological
case in which your hard disk farm has a bunch of softlinks to files on
different floppies, and only one floppy drive. Lots of deadlock possibilities
exist where applications try to open different combinations of files on
different volumes; fielding things correctly would require intercepting
read/write virtual and ensuring the correct volume was there before allowing
things to proceed. While this can be done, it's questionable whether anyone
would actually want to do it. ("seek time" takes on a whole new meaning when
it means rummaging thru a pile of floppies :-) for such a case...)
Glenn
Everhart@raxco.com

Newsgroups: comp.os.vms
From: huang@maui.cs.ucla.edu (Shan-Chiao Huang)
Subject: Volume summary data not found -- Help needed!
Organization: UCLA, Computer Science Department
Date: Wed, 13 Jan 93 00:20:35 GMT

I am helping someone to upgrade VMS from 4.7 to 5.4 for her VAXstation II/GFX. 
I boot the machine by 4.7 standalone backup tape and then "backup/verify mua0:
vms054.b/save_set dua0:" as mentioned in the manual. However, I got the error
message -- "volume summary data for DUA0: not found -- /IMAGE cannot be used". 
I tried "ana/disk/repair" but no luck.

Does anyone meet the same problem before or know how to solve this problem? 
Any suggestions are welcomed.

Thanks in advance.


----------------------------------------------------------------------------
Beam me up, my Lord.
----------------------------------------------------------------------------
Shan-Chiao Huang    UCLA Computer Science Department
huang@cs.ucla.edu   ..!{uunet,ucbvax,rutgers,cepu,trwspp}!cs.ucla.edu!huang
From: jeh@cmkrnl.com
Newsgroups: comp.os.vms
Subject: Re: Question of SYSGEN.....
Date: 5 Jan 93 20:24:50 PST
Distribution: world
Organization: Kernel Mode Consulting, San Diego, CA

In article <9FDCDBC6045F0001B5@EGFRCUVX>, SABRY@SHEBIN.EG (Sabry Kotob El-Ganzory) writes:
> Please, Question of SYSGEN and to you SYSGEN>show/all
> [...]
> Pardon me If I'm asking a silly questions.......ok.
> Does anyone have any suggestions on these output from our SYSGEN???
> As a matter of fact, I send this output because I want system tuning help
> Request.
> Please, Forgive me If I asking a silly questions.

Gahhh.... 

How are we supposed to give you advice when we don't know what you want?

	- we don't know how much memory you have.
	- we don't know which model CPU you have
	- we don't know what types of disks you have
	- we don't know how many users you need to support
	- we don't know what the users will be doing on the system
	- we don't know what, if any, performance problems you're currently
	  experiencing
	- and so forth, and so forth, and so forth.  

In fact, you have asked a completely open-ended question.  You might as well
have asked "What shall I do with my time tomorrow?"  

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
drivers, internals, networks, applications, and training for VMS and Windows-NT
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
From: gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546)
Newsgroups: comp.os.vms
Subject: Re: Question of SYSGEN.....
Date: 7 Jan 93 21:51:00 GMT
Reply-To: gavron@ACES.COM
Organization: ACES Consulting Inc.
News-Software: VAX/VMS VNEWS 1.4-b1

In article <1993Jan6.114759.1081@cmkrnl.com>, jeh@cmkrnl.com writes...
# 
#Most people will get MUCH better results from AUTOGEN than they will from 
#most of the consultants who claim that AUTOGEN has serious problems. 

Yes, and that's what keeps the rest of us consultants who know AUTOGEN's
problems and can do a much better job employed!

#	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
#Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com

Ehud

--
Ehud Gavron        (EG76)     
gavron@aces.com
From: ewilts@galaxy.gov.bc.ca (Ed Wilts)
Newsgroups: comp.os.vms
Subject: Re: Ctrl-C disabling with VMS sessions
Date: 12 Jan 93 08:20:01 -0800
Distribution: world
Organization: BC Systems Corporation

In article <980674E8559F002FC3@BC750.BITNET>, WAYNE@BC750.BITNET writes:
> 
> Is there anyway to disable the Ctrl-C within a VMS session, in DCL level or
> within an application image ?

Yes.  I've got some old Fortran code lying around (author FJM, last modified
1988) that enables/disables Control-C for you.  It also lets you trap the ^C
and do whatever your code wants to do, like an orderly shutdown.

I'll post to vmsnet.sources in a single part VMS_Share file.  Two modules - one
that does the work and one short program that tests it.

-- 
Ed Wilts, BC Systems, 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8
EWilts@Galaxy.Gov.BC.CA     Office:  (604) 389-3430   Fax: (604) 389-3412
From: Chris_F_Chiesa@cup.portal.com
Newsgroups: comp.os.vms
Subject: re: Re: Running LOGINOUT [SYS$CLI]
Date: Mon, 11 Jan 93 21:59:19 PST
Organization: The Portal System (TM)

Whew... it's been a whole five days since I read-and-posted here... and it's 
1AM even so...

In response to an earlier posting of mine, Jerry Leichter writes:

>	Is it possible that the "running LOGINOUT" issue, [...] might be
>	related to the thoroughly undocumented nature of [...] SYS$CLI?
>
>Nope; not connection at all.
>
> [...more drivel from me...]	
>
>SYS$CLI is a catch-all; essentially all it means is "CLI, please perform some
>service for me".  A parameter specifies which service, and all the rest of the
>parameters vary depending on the service to be provided.

That much I know.  It's just that the data structure isn't documented 
anywhere.  A disconcerting proportion of the "regulars" on this group
seem to have access to VMS source code; I'd give my left eyetooth to 
come within spitting distance of it, myself, as that seems to be not 
only the "definitive" reference but in some cases the ONLY source of
information, on some topics, SYS$CLI being one of them.  I suppose, though,
that if I ever DID encounter VMS source code I'd be disappointed: I 
imagine it being heavily and clearly commented and easy to follow, and
I'd be awfully teed off if it turned out to be obscure and obfuscated...

But I digress.

>The last time I checked, all the SYS$CLI services were accessible through
>library procedures; you'd gain nothing by using SYS$CLI directly.

Ah... now that's where you're mistaken!  From the few feeble bits of
information I -was- able to dig up on SYS$CLI, from Pat Rankin and 
Joe Meadows and the like, I've found a couple of things I can do via
SYS$CLI that I CAN'T do through library procedures.  One, "chain" to
another executable program after the one I'm running completes.  Two,
do that AND issue another independent DCL command, both after the 
program I'm running completes.  Heaven only knows what else I'd find 
if I could follow the scanty docs any better...

Chris Chiesa
  Chris_F_Chiesa@cup.portal.com
From: DESMITH_N@COLLOQUIUM.CO.UK (Nick de Smith)
Newsgroups: comp.os.vms
Subject: Re: TT_AccPorNam field remains null on a SHOW USERS output ?
Date: 4 Jan 93 12:09:00 GMT
Distribution: world
Organization: The Internet

Hi,

In article <01GSVSPU15CY006MJF@VAXF.COLORADO.EDU>, DWING@UH01.Colorado.EDU (Dan Wing) writes:
>(To the best of my limited knowledge) LOGINOUT.EXE is responsible for setting 
>this field.  

The port drivers (eg. LTDRIVER.EXE et al) set this field.

Then Thomas H. Hopson wrote:
>I installed a hook into FTDRIVER called ATG_FT_PATCH from one of the recent
>DECUS tapes (also available off ftp.spc.edu in [.macro32.savesets] or from
>Hunter Goatley's fileserv).  It forces FTDRIVER to allocate space for an
>access port name that can be later set under program control.

As the author of ATG_FT_PATCH (now called NMS_FT_PATCH) I was wondering who out
there uses it, as I am considering updating it for AXP. Note that it still works
fine with VMS V5.5-2. As far as I know, this code is the only way to set access
port names for FT devices, and DEC have not mentioned any plans for this
(Forrest? Are you out there? Any comment?).

So, if you or your site is using ATG_FT_PATCH, I would like to know (by EMAIL
please - there's enough crud on Info-VAX as it is...)

Have a Happy and CALM New Year!

Nick
Newsgroups: comp.os.vms
Subject: Re: Question: Reading keys with command procedures.
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 9 Jan 93 06:22:52 GMT
Distribution: world
Organization: The Wolery

leichter@lrw.com (Jerry Leichter) writes:
> In theory, any undocumented language support routine is subject to change in
> future versions of VMS.  In practice, since the VMS group and the language
> groups try quite hard to ensure upward compatibility, it's essentially
> impossible for them to remove any such routines, or change the semantics of
> calls generated by older compilers.

Well, yes, but the implied support by not breaking existing code only
goes as far as "normal" usage.  The BASIC subroutine I derived my code
from goes:

	sub fred
		x$ = inkey$(0%, wait)
	end sub

and compiles to:

	FRED::	.word ^M<R2,R3,R4,R5,R6,R7,R8,R9.R10,R11,IV,DV>
		movab .-3,R2		; \
		movab $PDATA+4,R0	;  | This is BASIC's init code
		movl R0,R1		;  |
		jsb BAS$INIT_R8		; /
	1$:	movab 1$, -4(FP)	; This is for ERL handing
		pushl #0		; \
		pushl #0		;  |
		pushl #0		;  | I lifted this for my code
		pushaq Z$(R11)		;  |
		calls #4, BAS$INKEY	; /
		movab $PDATA+4,R0	; \
		jsb BAS$END_R8		;  | This is BASIC's exit code
		movl #1, R0		; /
		ret

with data structures to match.  It happens that BAS$INKEY *in* *this* 
*version* runs "standalone"; it's possible however that in the future, data
structures may be set up for BAS$INKEY within BAS$INIT_R8.  Code compiled
with BASIC will be fine, because it contains calls to BAS$INIT_R8, but
direct calls to BAS$INKEY from languages other than BASIC wouldn't. 

BASIC is a particularly nasty example, because of the truly awful code
the compiler generates....  (Nice language, cruddy pessimising compiler
backend.)
 
> Mr. Stokes also says that "all bets are off on Alpha."  For native Alpha

<cringe>  "Don", please.  8-)

> code, that's certainly true, since there is no reason why a native Alpha
> BASIC compiler should generate calls to the same RTL routines as a VAX
> BASIC compiler.  However, to the degree that Alpha VMS continues to support
> the running of VAX images, it will necessarily be subject to the same
> constrains as I pointed out above.

... and it's perhaps more likely that changes as outlined above may have
been made.

--
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