HDTenEightyP/NetNews huggingface dataset:
From: garry@ithaca.com (Garry Wiegand)
Subject: Re: VMS shareable images q.- Please help
Organization: Ithaca Software
Date: Wed, 30 Sep 1992 02:06:25 GMT

In a recent article winalski@adserv.enet.dec.com (Paul S. Winalski) wrote:
>VAXCRTL.EXE ships as part of VMS, not with the VAX C compiler.  Your sponsors
>shouldn't need VAX C installed on their systems for your program to work.  In
>what way is the program "crashing"?
>
>You should never have to link against the .OLB version of the VAX C RTL unless
>you're writing inner-mode code.

If you link against Vaxcrtl.exe and then carry that linked image to
any "sufficiently old" VMS system and try to run it, you will get a
message like:

    Error activating image VAXCRTL
    Image file SILVER$DKA0:[SYS0.SYSCOMMON.][SYSLIB]VAXCRTL.EXE;1
    Ident mismatch with shareable image

This may be the "crash" originally spoken of. The reason for the message is 
that whenever Dec makes a significant change to Vaxcrtl (or any shareable 
image) they bump the shareable image ID/match control number. This 
prevents you from making the error of linking to a routine that exists in 
the new image only and then trying to run using the old image - the
image activator looks at the numbers and generates the above error. This
magic unfortunately *also* prevents you from making reference to *any* 
routine in the old image.

Now that we know about the problem we always link against a very old
vaxcrtl.exe that we've preserved from bygone days. Linking against
an old locally and then running with a new on some remote machine is
no problem and perfectly legal. 

If you haven't preserved an old vaxcrtl.exe then you have to drop down
to using the .olb. With the ensuing difficulties.

DEC ought to redo their shareable-image technology. The current method
was invented almost 15 years ago and has a variety of problems.

Garry Wiegand --- garry@ithaca.com --- Ithaca Software, Alameda, California
Newsgroups: comp.os.vms
From: efricha@vortex.rti.org (Eric F. Richards)
Subject: Re: Problem with detached/subprocess output files
Organization: Tybrin Corporation
Date: 3 Oct 92 18:43:09 EST

In article <009617E6.745BF960.11463@swdev.si.com>, tillman@swdev.si.com
("Brian Tillman, Smiths Industries, VAX Support, x8425") writes:
> Eric Richards (richarde@eglin.af.mil) writes:
> 
>>(Even though using LOGINOUT will solve our problem, the question remains:
>>Is this behavior really a desirable feature?  The only way to be absolutely
>>safe it to always use $PUTMSG for output or to never run a program without
>>CLI support.)
>
> I don't see why you'd need to change any programs.  Perhaps you could share
> why you think that would be necessary.

	It comes down to editing all these programs, changing each $CREPRC
to run LOGINOUT with a command file, putting each command file in place,
and testing them.

	The kicker:  These are real-time programs running in a "maxed-out"
environment.  We'd have to recertify each of these programs to make sure that
they all work properly -- a failure of one of these can be dangerous.
I appears that this is a moot point, since it looks like this is what we'll
have to do, anyway. :-(

> As an aside, and in reference to the quoted text above, mixing $PUTMSG and
> RMS I/O has long been cautioned against in VMS documentation.

	Really?  Where is this documented?  It's scary, when you think about
the ramifications!  Consider that the traceback handler (and therefore any
call to LIB$SIGNAL, LIB$STOP, an exception, etc.) uses $PUTMSG to output its
data.  If this is not the appropriate method of signalling success or failure,
what is?

	BTW, I did a little fiching yesterday to look at how LOGINOUT handles
its PPFs, and to look at LIB$PUT_OUTPUT and $PUTMSG to see what they do. It
doesn't look like there should be any reason for problem with sharing these
output streams -- both use RMS $OPENS and $PUTs, with fairly generic
attributes set.  What neither have set are any sharing bits.  That looks
like an artifact from VMS in the days before multiple writers to
sequential files allowed.

	One REALLY strange feature of $PUTMSG is that if it's called from
a processor mode other than USER (presumably SUPER, if the IDSM cautions
are to be followed), it sets the PPF bit in its own $FAB!  It then keeps
the IFI/ISI around in a logical SYS$PUTMSG.  Curiouser and curiouser...

	I guess if I were DEC, I'd make $CREPRC (EXE$PROCSTRT) do is try
to open SYS$OUTPUT and SYS$ERROR as PPFs.  I wonder why they didn't?

Eric Richards
Tybrin Corp.
richarde@eglin.af.mil
904/882-9793
From: mzagsaa@v4.cgu.mcc.ac.uk (Tony Arnold)
Newsgroups: comp.os.vms
Subject: Re: Nobroadcast
Date: 1 Oct 92 08:31:39 GMT
Reply-To: A.C.Arnold@mcc.ac.uk
Organization: Manchester Computing Centre


In article <01GPBXU3L0HS8WWMAB@scorva>, CAPTANSKI33@SNYCORVA.BITNET
(CHRIS TANSKI) writes:
|>From: CAPTANSKI33@SNYCORVA.BITNET (CHRIS TANSKI)
|>Newsgroups: comp.os.vms
|>Subject: Nobroadcast
|>Date: 29 Sep 92 00:45:00 GMT
|>
|>I know this is an FAQ so please reply directly to the above address.
|>I
|>am having trouble setting nobroadcast for my acct. I type:
|>
|>$ SET BROADCAST=NONE
|>
|>However I still get phone calls and mail etc. How do I set it so I
|>don't get anything? Thanks.
|>
|>Chris Tanski
|>
Just do SET TERM/NOBRAODCAST. This kills ALL broadcasts.

Tony Arnold,
Manchester Computing Centre,
University of Manchester.
From: nreadwin@micrognosis.co.uk (Neil Readwin)
Newsgroups: comp.os.vms
Subject: Re: VAX-C VMS 5.3, open(), file protections dont work?
Date: 28 Sep 92 11:30:30 GMT
Organization: Micrognosis, London, UK.

In article <2ac7239e.e10@grace.cri.nz>, srghcxp@grace.cri.nz writes:
|> Using VAXC, open(), the protection flags don't seem to work.
|> 
|> Anyone know why, have I done something stupid?

It may be that you have done a SET PROT=.../DEFAULT. This overrides the
value passed to open(). Interestingly, a default protection ACL does not.
-- 
 Phone: +44 71 528 8282  E-mail: nreadwin@micrognosis.co.uk
 Anything is a cause for sorrow that my mind or body has made
From: 88175839@CPHKVX.CPHK.HK
Newsgroups: comp.os.vms
Subject: Shrink ALL-IN-1 working set
Date: 29 Sep 92 21:56:00 GMT
Reply-To: 88175839@cphkvx.cphk.hk
Organization: The Internet

Does anyone know how to set the ALL-IN-1 main process working set size
to minimum ? It is because we use ALL-IN-1 as a menu system; it will create 
sub-process to handle functions selected and the main process then just 
become idle (wasting memory) until control returns to ALL-IN-1.

KC Tam (88175839@CPHKVX.BITNET)


Newsgroups: comp.os.vms
From: beutel@chdasic.sps.mot.com (Jim Beutel)
Subject: 7000 Cluster Usage 
Reply-To: beutel@chdasic.sps.mot.com
Organization: Motorola SPS ASIC, Chandler, AZ
Date: Wed, 30 Sep 1992 21:48:09 GMT

Does anybody have the pleasure of running one of the new 7000
systems yet...? I will be recieving a 7000-620 in the next few 
weeks. Presently have a 9000/8840 cluster running 5.4 Besides 
for the obvious of the 5.5-2 upgrade, any inputs on "gotchas"
dealing with the 7000 system? I know the queue manager has been
changed. Did not seem to bother me to much on my microvax system.
Except for the LACK of prior notice. 

Thanks,
Jim

---
Jim Beutel	
Motorola SPS ASIC            beutel@chdasic.sps.mot.com
1300 N. Alma School Rd       Operations Manager
M/S CH290  AZ50              office:  (602) 821-4967
Chandler, Arizona 85224	     telefax: (602) 821-4963
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: a way to show que entry status?
Date: 26 Sep 1992 21:17:45 GMT
Organization: HST Wide Field/Planetary Camera
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <1992Sep26.150210.7495@micrognosis.co.uk>, nreadwin@micrognosis.co.uk (Neil Readwin) writes:
>|> This information seems to show up occassionally in sho/que/all info, but
>|> I can't find a way to make the information show up when I want it.
>
>Speculation follows ... this value is not continuously updated, probably
>because there is no obvious need for it to be exactly right.

This value is, unless I'm very much mistaken, updated only when the symbiont
calls SMB$SEND_TO_JOBCTL with a non-zero value for the checkpoint argument. 
Quoting from the SMB routines manual:

Note:	Because each checkpoint causes information to be written into the job
	controller's queue-data file, taking a checkpoint incurs significant
	overhead.  Use caution in regard to the size and frequency of
	checkpoints.  When determining how often to checkpoint, weigh processor
	and filesystem overhead against the convenience of restarting.
--------------------------------------------------------------------------------
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
Subject: Control-Y causes hanging (rec locking)
From: kyle@yogi.hsc.ucalgary.ca (Kyle Maschmeyer)
Date: 25 Sep 92 13:49:38 GMT
Organization: Sharecom Ind.
Nntp-Posting-User: kyle

Here's my problem: when users type control-Y and interrupt the
software I've written, SUUUUthey often do it when RMS has a record
locked. Because they are supposed to be able to use the VMS DCL
command CONTINUE, the record remains locked while the system
waits for a new DCL command. If they go for coffee at that point,
the record is locked for a long time, interfering with other users'
access to it.

Other than disabling control Y's altogether, is there any way of either
a) causing VMS to release all the RMS record locks and terminate the
 image when a control Y is pressed, so that a CONTINUE would be impossible?
or
b) having all control-Y's be interpreted as control-C's instead, which are
trappable by the program (we write in VAX BASIC), allowing us to close
all the files before exiting?

Please send a reply directly to me, even if you post it as well, since
I don't manage to read all the network postings regularly.

-- 
| Kyle Maschmeyer, B.Sc.	| Internet address: 			     |
| Programmer/linguist		|  "animal::kyle"@yogi.hsc.ucalgary.ca	     |
| c/o Sharecom Industries, Box 8| To specify on VAX/VMS:		     |
| DeWinton, Alberta, Canada	|  "'animal::kyle'@yogi.hsc.ucalgary.ca"     |
| Tel. (403) 256-4766 days MST	| Alternate, if the quotes are a problem:    |
|				|  kyle@yogi.hsc.ucalgary.ca		     |
From: fox@rudolf.nscl.msu.edu (Ron Fox)
Newsgroups: comp.os.vms
Subject: Impact of Vaxstation-4000/90 on MI cluster
Date: 2 Oct 92 13:09:03 GMT
Reply-To: fox@rudolf.nscl.msu.edu (Ron Fox)
Organization: National Superconducting Cyclotron Lab.

--
  We recently received a few VAXstation-4000/90 systems and ran
into the following interesting set of hinks in VMS 5.5-2HW which
is required to run this box:

"Restrictions
1. VMS Volume Shadowing for SCSI devices is not supported in V5.5-2HW. 
   This restriction will be lifted in the OpenVMS VAX version 5.5-2 
   release"

This makes that system very hard to integrate into our cluster since
we rely on SCSI volume shadowing to produce high availability disks
on workstations.  There is one other restriction that doesn't bite
us but might bite others:

"2. Attempting to boot V5.5-2HW Standalonge Backup (SAB) with a 
    non-Digital TURBOchannel device instgalled will result in a fatal
    bug check.

    This restriction does not apply to the following Digital 
    TURBOchannel devices: PMAD-AB, PMAZ-AB, DEFZA-AA.

    In order to boot SAB, any non-Digital TURBOchannel device must
first
    be removed.  Please be sure to power down the system before
    attempting this operation.

    Once the standalone BACKUP operation is complete, the system may
    then be powered down and the non-Digital TURBOchannel device
    reinstalled

    This problem will be corrected in a future OpenVMS VAX Release."

Who thinks up these little problems... I think there must be a 
department in DEC... the Murphy department which is responsible for
thinking up the one restriction which will be most painful to
workaround
and requesting that engineering put that restriction into hardware
specific releases of VMS.

	RF.
Ron Fox                     | FOX@MSUNSCL.BITNET      | Where the name 
NSCL                        | FOX@RUDOLF.NSCL.MSU.EDU | goes on before
Michigan State University   | MSUHEP::RUDOLF::FOX     | the quality
East Lansing, MI 48824-1321 |                         | goes in.
USA
Newsgroups: comp.os.vms
Subject: Where is Nick de Smith?
From: kaplan@misvax.mis.arizona.edu (RayK)
Date: 30 Sep 1992 09:33 MST  
Distribution: world,local
Organization: University of Arizona MIS Department
Keywords: Help
News-Software: VAX/VMS VNEWS 1.41    

Appologies for obvious brainfade.  Can anyone point me toward Nick de Smith
(He's known to post here - I've tried the obvious places).  Thanks in
advance.

RayK 8)
Newsgroups: comp.os.vms
Subject: Phone control
From: kaplan@misvax.mis.arizona.edu (RayK)
Date: 3 Oct 1992 08:35 MST  
Distribution: world,local
Organization: University of Arizona MIS Department
Keywords: DECalert for free
News-Software: VAX/VMS VNEWS 1.41    

A friend asks:

Is there something like DECalert's ability to control the phone available
for VMS?  Such code would allow a program (DCl or otherwise) to dial a
number and then issue whatever what is attached to the number requires
(i.e.: might be a pager number that needs a phone number sent over to it or
some device that actually controls something that would need some exchange
of authentication).  Easy to write, certainly, but not trivial.  I recall
something called VMSnet that had such code in it from the DECUS tapes a
while back, but I can't find it.

RayK 8)
Ray Kaplan
internet: kaplan@mis.arizona.edu
BITNET: KAPLAN@ARIZMIS
From: lionel@quark.enet.dec.com (Steve Lionel)
Newsgroups: comp.os.vms
Subject: Re: Why is demand-zero compression for shareable images unsupported?
Date: 5 Oct 92 18:03:22 GMT
Article-I.D.: e2big.1992Oct5.180322.28288
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH


A minor correction to my posting regarding the history of the UNSUPPORTED=1
linker option to get demand-zero sections in shareable images: the breakup
of VMSRTL happened for VMS V4, not V3 as I said.  Though the work I did was
indeed in the 1982-1983 timeframe, V3 shipped in the spring of 1982; V4,
which contained the split VMSRTL, shipped in late 1984.  Thanks to 
Tom O'Toole for pointing out my error.
--

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
From: ewilts@galaxy.gov.bc.ca (Ed Wilts)
Newsgroups: comp.os.vms
Subject: Re: Reading Bookreader Help on VT330
Date: 2 Oct 92 16:24:31 GMT
Reply-To: EWILTS@GALAXY.GOV.BC.CA
Organization: BC Systems Corporation

In article <1992Oct2.103735.1486@wega.rz.uni-ulm.de>, CCC_KARG@rzmain.rz.uni-ulm.de (ComRam) writes:
> As printed documentation gets more and more rare, programmers have to rely
> in almost any case on the online documenation accessible via
> decw$bookreader. The only problem for me is, we use standard VT330
> Terminals here, so using decw applications is causing some problems :-)
> Is there any reasonable way to access the documentation data anyway, e.g.
> converting them to ASCII or whatever ? Or perhaps even a complete
> 'bookreader-like'-ASCII Interface ?

DEC is rumoured to have a product named BookReader Plus in internal field test
that gives you an ASCII interface to BookReader files as well as giving you
search capabilities (something BR doesn't currently have).

When, or even if, this product will ship is unknown.

-- 

Ed Wilts, BC Systems Corp., 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8
EWilts@Galaxy.Gov.BC.CA   |   Ed.Wilts@BCSystems.Gov.BC.CA   |   (604) 389-3430
Newsgroups: comp.os.vms
Subject: Re: DCL says 1 = 0 (puzzle solved)
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 6 Oct 92 19:50:46 GMT
Distribution: world
Organization: The Wolery

moeller@gwdgv1.dnet.gwdg.de ("GWDGV1::MOELLER") writes:
> The first solution (in postmark order) came from Don Stokes
> <don@toyunix.zl2tnm.gen.nz>:
> 
>    $ z = f$context("PROCESS",1,"USERNAME","NOONE","EQL") + f$pid(1)
> 
> My own solution was re-discovered about 10 hours later by
> Arne Vajhxj <ARNE@KOPC.HHS.DK>:
> 
>    $ loop: if f$pid(1) .nes. "" then goto loop
> 
> who also noted that f$csid() can be used here instead of f$pid().
> 
> The second solution has the obvious advantage that it does work
> on VMS V4.7 (and probably also on 3.x - f$pid() was introduced in 3.0).

And the first has the advantage that it runs a lot faster.... 8-)

--
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
Newsgroups: comp.os.vms
Subject: Re: Disk Defrag & System Disk
From: dan@ttisms.com
Date: 1 Oct 92 21:45:58 PDT
Distribution: world
Organization: Touch Technologies Inc., San Diego CA

> I use the product PerfectDisk from Raxco to defrag various disks
> on mine machines.  Can anyone comment on what they see as the best
> way to defrag a system disk.  The problem being so many files are
> open and thus don't get optimized, I assume.
> 

Hi,

There is no way to DEfragment open files that are already fragmented. 
You will need to boot minimum and run your defragmenter...or good-old
backup/restore.

However, our company has just announced a product called "Fragmentation
Controller".  This product reduces or eliminates file fragmentation AS
FILES ARE BEING CREATED AND EXTENDED.

So, the very files that defragmenters can't defragment (those that are
in use) are EXACTLY those that FC helps out.  We have been averaging 95%
reduction in fragmentation!!

Dan E.  (FC designer and co-developer)
DAN@TTISMS.COM
From: eychaner@suncub.bbso.caltech.edu (Another casualty of applied metaphysics)
Newsgroups: comp.os.vms
Subject: Re: A mysterious SMG behaviour...
Date: 1 Oct 1992 22:53:19 GMT
Organization: Big Bear Solar Observatory, Caltech
Reply-To: eychaner@suncub.bbso.caltech.edu
NNTP-Posting-Host: suncub.bbso.caltech.edu

I wrote:

>I'm still writing a user interface using SMG$ routines.  I have some displays
>on the pasteboard, including a large output display just above a small 1-row
>input display, both pasted in column 1 and the same width as the pasteboard.
>I get the behaviour that when the large display is viewported, reads from the
>small display ($READ_STRING, $READ_KEYSTROKE) abort with SMG$_INVCOL.  When
>the large display is NOT viewported, reads from the small display work fine.
>Output to the small display always works.  Is this normal behaviour, and what
>can I do about it?  (I need the large display viewported; sometimes it needs
>to be larger than the screen space available.  By the way, it STARTS without
>a viewport, and then is unpasted and pasted with a viewport later; is this
>important?)  Sorry I can't describe the problem better, but if you want any
>clarifications, I'll be happy to provide them.

Some more clarifications:

* Making the input display larger does NOT appear to affect the problem.
* Pasting the input display ABOVE the output display DOES solve the problem.
* There is a blank row between the bottom of the output display (or its
  viewport) and the top of the input display.  If the output display is
  exactly 1 row larger than its viewport, the problem does NOT occur.  (It
  is as though the output display must "run over" the input display.  The
  position of the viewport on the output display does not matter, however.)
* Changing the display creation order does NOT affect the problem.  (Should I
  repaste the input display after repasting the output display viewported,
  even though they don't occlude?)
* Note that $CHANGE_DISPLAY is used on the output display to resize it before
  it is viewported.  Both this and $CREATE_VIEWPORT return success status.

Any help is appreciated.  Source code provided on request.  (It's too big to
post.)  I will continue to experiment and report if no answer is received.

Thanks again, -G.
******************************************************************************
Glenn Eychaner, Big Bear Solar Observatory, California Institute of Technology
NSI/DECnet: SUNCUB::EYCHANER        Internet: eychaner@suncub.bbso.caltech.edu
USmail: 40386 North Shore Lane                eychaner_g@caltech.edu
        Big Bear City, CA  92314    Phone: (714) 866-5791 or (818) 356-4014
                                           (909) after November 14, 1992
"I don't do Windows."
"Even the hardest concrete never quite sets.  And the sun never sweats."
From: bruce@ais.com (Bruce C. Wright)
Newsgroups: comp.os.vms
Subject: Re: Utility to delete 0 block file
Date: 28 Sep 92 13:19:49 GMT
Organization: Applied Information Systems, Chapel Hill, NC

In article <1992Sep28.055212.1411@nuscc.nus.sg>, edbis@solomon.technet.sg (Koh Eng San) writes:
> Koh Eng San (edbis@solomon.technet.sg) wrote:
> : Hi there,
> : 
> : I am looking for a file utility that deletes 0 block file. Is such a utility
> : available?
> 
> Perhaps I have not myself clear. My apologies. What I am looking for is a
> command or utility that allow s me to delete all 0 block files such as
> "DELETE/SIZ=0 *.*;*". I know there is no such VMS command...

I don't know about any programs that will do this, but this is a very
easy problem for a DCL .COM file -- the following file was thrown
together in a couple of minutes.

Good luck,

Bruce C. Wright

---------------------------- cut here -----------------------------
$!
$! Usage:
$!
$!	delz*ero :== @dev:[dir]delzero
$!
$!	delzero source [/LOG] [/EOF]
$!
$! Files with zero blocks allocated are deleted.
$!
$! /LOG logs file deletions.
$! /EOF deletes files whose end-of-file marker is 0 rather than
$!	files which have 0 blocks allocated.  This is slightly
$!	less conservative since there are a few cases where some
$!	useful information may have been written to a file before
$!	a program crashed that could still be recovered.
$! 
$	if p2 .nes. "" then goto parm
$	write sys$output "Usage: delzero filespec"
$	exit
$!
$ parm:	all_files = 0
$	log_str = ""
$	type_str = "ALQ"
$	old_name = ""
$	if p2 .eqs. "" then goto loop
$	if p2 .eqs. f$extract (0, f$length (p2), "/LOG") then log_str = "/LOG"
$	if p2 .eqs. f$extract (0, f$length (p2), "/EOF") then type_str = "EOF"
$	if p3 .eqs. "" then goto loop
$	if p3 .eqs. f$extract (0, f$length (p3), "/LOG") then log_str = "/LOG"
$	if p3 .eqs. f$extract (0, f$length (p3), "/EOF") then type_str = "EOF"
$!
$ loop:	on error then continue
$	fname = f$search (p1, 1)
$	if fname .eqs. "" .or. fname .eqs. old_name then goto endit
$	old_name = fname
$	if f$file_attributes (fname, type_str) .eq. 0 then -
		delete 'fname' 'log_str'
$	goto loop
$!
$ endit:exit
Newsgroups: comp.os.vms
From: RAHLFS@BEATE.RZ.FH-ULM.DE (RZ D. Rahlfs)
Subject: VMS Print Jobs redirection to Ultrix print queue
Organization: FACHHOCHSCHULE ULM (GERMANY)
Date: Mon, 5 Oct 1992 11:49:04 GMT
X-News-Reader: VMS NEWS 1.22

Who knows something about redirecting a VMS Print Job to an Ultrix
queue?
Is there a (public domain) LPD packet for VMS anywhere?
Xref: sparky comp.os.vms:15685 vmsnet.admin:422 vmsnet.sysmgt:258