HDTenEightyP/NetNews huggingface dataset:
From: saul_sy@hnrc.tufts.edu (Saul Tannenbaum)
Newsgroups: vmsnet.internals,comp.os.vms
Subject: Re: VMS shareable images, what's wrong with them?
Date: 7 Oct 92 18:38:39 GMT
Organization: USDA HNRC at Tufts University

In article <1992Oct6.201520.24059@e2big.mko.dec.com>, lionel@quark.enet.dec.com (Steve Lionel) writes:
> 
> Dynamic linking has been
> available for some years on VAX/VMS through LIB$FIND_IMAGE_SYMBOL.
> --

While LIB$FIND_IMAGE_SYMBOL is far,far better than nothing, I would contend
that it is *not* dynamic linking, it's run time activation of a shared
image. Real dynamic link as implemented in e.g. Multics, should not require
the writing of code for it to work.

Real dynamic linking (the resolution of external references at image
activation time) should have been in VMS since day 1, and LIB$FIND_IMAGE_SYMBOL
is, IMHO, a fairly ugly kludge to graft in those capabilities after the fact.

> 
> Steve Lionel                    lionel@quark.enet.dec.com
> SDT Languages Group
> Digital Equipment Corporation
> 110 Spit Brook Road
> Nashua, NH 03062

********************************************************************************
Saul Tannenbaum                         |
Manager, Scientific Computing           |Internet: STANNENB@HNRC.TUFTS.EDU
USDA Human Nutrition Research Center on |
    Aging at Tufts University           |
*********************** Standard Disclaimers Apply *****************************
From: Yaacov Fenster @ISO 882-3153  08-Oct-1992 0821
Newsgroups: vmsnet.internals
Subject: RE: VAX and Alpha: differences in image size for same program
Date: Thu, 8 Oct 92 07:19:30 MET
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

> From: VBORMC::"MACRO32@WKUVX1.BITNET" "MAIL-11 Daemon"  8-OCT-1992 07:46:28.80
> To:   MACRO32@WKUVX1.BITNET
> CC:   system@EIMONI.TUWIEN.AC.AT
> Subj: VAX and Alpha: differences in image size for same program
>
> I've recently worked on an alpha and written a programm in MACRO.
> I had a
> x:      .blkb   16*1024*1024
> statement and whoa! my image file had over 32000 blocks !
>
> On the vax if you had that .blkb statement, the image file was just a
> couple of blocks and (i believe) the image activator would create those
> pages when you ran the image. On alpha it seems to be the linker who

You are talking about whether or not the linker caused the pages
to be Demand Zero Pages or not.

> preallocates them. Can this behaviour be modified ?
>
> I have no "real" access to the alpha system, i can only put up
> benchmark programs and have them compiled, linked and executed,
> so please forgive me if a simple $ help link or something similar
> would have told me waht to do.

Without going into detail, my guess is that you had it compiled/linked against
 one
of the Field Test versions, since this is "Old Stuff".

>
> Thanks, Franz.
>
>
> Franz Schoenbauer, Tech. Univ. Vienna,    :  schoenbauer@eimoni.tuwien.ac.at
> Resselg. 3/188  A-1040, Vienna, Austria   :  +43(1)58801 ext. 4131
>

        Yaacov
-------------------------------------------------
Yaacov Fenster                  +(972)-3-9307239
y.fenster@ieee.org
fenster@taveng.enet.dec.com     DTN 882-3153
All the opinions voiced are mine alone and do not reflect anyone else's
opinion. (Including Dec).
From: <mahan@TGV.COM>
Newsgroups: vmsnet.internals
Subject: Re: Shared images, some differences on ALPHA
Date: Mon, 12 Oct 92 17:40:26 PDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

In article <3026@mitech.com> you write:
#
#By the way, LINK/SHARE works a bit differently on ALPHA. Indications I've
#gotten (e.g. months ago from OSF/MOTIF source codes) are that there is
#no longer any "globalref" or "globaldef" stuff, for example. e.g.
#
#     #if defined(VMS) && !define(ALPHA)
#     globaldef ...
#     #else
#     extern ...
#     #endif
#
#was seen.
#
#Transfer vectors work differently too.
#

Global def's, ref's and value are still supported under Alpha/VMS.  And yes
transfer vectors are different, but only because the calling standard changed.
Actually, I think it is a good improvement.

--
Patrick L. Mahan

--- TGV Window Washer ------------------------------- Mahan@TGV.COM ---------

Waking a person unnecessarily should not be considered  - Lazarus Long
a capital crime.  For a first offense, that is            From the Notebooks of
                                                          Lazarus Long
From: ewilts@galaxy.gov.bc.ca (Ed Wilts)
Newsgroups: vmsnet.internals
Subject: Re: Finding a users disk name
Date: 7 Oct 92 08:47:04 -0700
Reply-To: EWILTS@GALAXY.GOV.BC.CA
Organization: BC Systems Corporation

In article <1992Oct7.031040.5662@gw.wmich.edu>, 737ochs@gw.wmich.edu writes:
> Hello, I'm helping a friend of mine write a program that kinda simulates
> a unix-type operating system. What we are having trouble with is the
> cd ~user  command. We don't know how to get the person's disk area name
> from their username. We'd like to be able to do cd ~user and have the 
> program give us back disk$xxx:[user]. Is there an easy way to do this, 
> and a way to do it without having operator privileges. Oh, we are using
> VMS version 5.5

The only place the user's default device and directory is stored is in
SYSUAF.DAT.  Any method you choose for determining the device must have read
access to this file.  This doesn't require "operator privileges" - READALL,
SYSPRV, or BYPASS will suffice, or you can install the image you use to get the
default with privilege so that the end user doesn't need them.

What you can do is pick up the GETUAI utility off of an FTP site (see Ric
Steinberger's monthly posting for locations).  Then you can do stuff as simple
as:
	$ INSTALL GETUAI/PRIV=READALL	! do at system boot time
	$ GETUAI/DEFAULT=joesdir JOE
	$ SET DEFAULT 'joesdir'

It's interesting to note that the following does *not* work (unfortunately):
	$ POSIX
	psx> pwd
	/disk1/fred
	psx> cd ~joe
	psx> pwd
	/disk1/joe
	psx> ^d
	$ SHOW DEFAULT
	DISK1:[FRED]

-- 

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: vmsnet.internals
From: rf@cl.cam.ac.uk (Robin Fairbairns)
Subject: Re: C Language question
Reply-To: rf@cl.cam.ac.uk (Robin Fairbairns)
Organization: U of Cambridge, England
Date: Thu, 8 Oct 1992 13:44:46 GMT


In article <23000B53_00073190.00961C83B1DAD300$668_1@UK.AC.KCL.PH.IPG>,
SYSMGR@IPG.PH.KCL.AC.UK writes:
|> (To those who get offended by questions that stray outside a group's main
|> intention - Sorry, please hit delete now. I'm not sure what the appropriate
|> mail list is, and I do know that the folks that follow this one are likely
|> to know!)

Sure as hell is the wrong group - you need comp.lang.c or somesuch.
However, it may not be available as a mailing list: get yourself
Usenet news, Nigel!

|> Question: in C, if one declares char a[I][J], is there anything in the
|> language standard that guarantees that &a[0][0] is the first of a set of
|> I*J contiguous chars, and that a[i+1][0] is guaranteed to be the same
|> storage location as a[i][J] ).

The standard (actually I only have a copy of the 1st DIS, but it's
hardly likely to have changed) says "... The definition of the
subscript operator [] is that E1[E2] is identical to (*(E1+(E2))).
..."  It then goes on to say "... If E is an n-dimensional array
(n>=2) with dimensions ixjx...xk, then E (used as other than an
lvalue) is converted to a apointer to an (n-1)-dimensional array with
dimensions jx...xk.  If the unary * operator is applied to this
pointer explicitly, or implicitly as a result of subscripting, the
result is the pointed-to (n-1)-dimensional array, which is itself
converted to a pointer if used as other than an lvalue.  It follows
from this that arrays are stored in row-major order (last subscript
varies fastest)."

I think that answers your question

|> A friend asserts that it is, and says his experience on several systems
|> 'proves' this. My belief is that there is nothing that says this will
|> always be the case, and that the only constraint is that every valid pointer
|> a[i] will point to J chars. Which of us is right?

Your friend is obviously neither a scientist nor a mathematician ;-)
--
Robin (come back John Drummond) Fairbairns       rf@cl.cam.ac.uk
U of Cambridge Computer Lab, Pembroke St, Cambridge  CB2 3QG, UK
From: REGI's <NUNEZ@esevvx.cica.es>
Newsgroups: vmsnet.internals
Subject: (None)
Date: Thu, 15 Oct 1992 17:08:00 UTC+0100
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

>X-Envelope-to: MACRO32@WKUVX1.bitnet
>X-VMS-To: IN::"MACRO32@WKUVX1.BITNET"

1
12-OCT-1992 16:25:05.69
   1 00:00:00.00
13-OCT-1992 16:25:05.69
@UKCC.uky.edu:MacroMan@WKUVX1.BITNET
gutier@SEVAXU.CICA.ES

Received: from UKCC.uky.edu by ESEVVX.CICA.ES ;  9-OCT-1992 16:24:52.03
Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 4200; Fri, 09 Oct 92 11:23:41 EDT
Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 8730;
 Fri, 09 Oct 92 11:23:39 EDT
Errors-To: MacroMan@WKUVX1.BITNET
X-ListName: "VMS Internals, MACRO, and BLISS Discussions"
    <MACRO32@WKUVX1.BITNET>
Received: from CUNYVM.BITNET (MAILER) by WKUVX1 (MX V3.1C) with BSMTP; Fri, 09
          Oct 1992 10:18:06 CDT
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 2002; Fri,
          09 Oct 92 11:05:52 EDT
Received: from aardvark.ucs.uoknor.edu by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2)
          with TCP; Fri, 09 Oct 92 11:05:50 EDT
Date: Fri, 9 Oct 92 10:05 CDT
From: Chris Petroff <CHRIS@aardvark.ucs.uoknor.edu>
Reply-To: MACRO32@WKUVX1.BITNET
Subject: Re: Finding a users disk name
To: MACRO32@WKUVX1.BITNET
X-VMS-To: IN%"MACRO32@WKUVX1.BITNET"

> Hello, I'm helping a friend of mine write a program that kinda simulates
> a unix-type operating system. What we are having trouble with is the
> cd ~user  command. We don't know how to get the person's disk area name
> from their username. We'd like to be able to do cd ~user and have the
> program give us back disk$xxx:[user]. Is there an easy way to do this,
> and a way to do it without having operator privileges. Oh, we are using
> VMS version 5.5

What we do here for nonpriv access to low-level SYSUAF info is use the
LIST command from AUTHORIZE to gererate a file with basic info, and then
place it in a world readable spot with appropriate access privs so that
anyone can use it.  A simple SEARCH on this file will return not only
the home directory/device of a user, but also his UIC, Personal Name,
privs (NORMAL/ALL), base priority and Account name.  After we make the
SYSUAF.LIS file, we strip out some stuff and leave only the username,
owner/personal name, UIC, and Directory.  We have a command file which
does this for us which we run after adding/deleting accounts.  We also
have several utilities which are driven off this file...

This allows nonprivilaged access to the info, but the real benifit at
the time it was implimented (on a 11/780) was that we did not keep
trashing SUSUAF.DAT everytime we wanted to look someone up!  On a
6320 (what we have now) it's still more efficient but probably not so
big a deal....

This may seem like a bothersome way of doing it, but it is VERY simple
and easy to maintain.  Also, it is not likely to break with the next
version of VMS, but if it does, it is real simple to fix!

Just my $.02

:-)

Chris
From: ewilts@galaxy.gov.bc.ca (Ed Wilts)
Newsgroups: vmsnet.internals
Subject: Re: Finding a users disk name
Date: 7 Oct 92 12:22:53 -0700
Reply-To: EWILTS@GALAXY.GOV.BC.CA
Distribution: world,local
Organization: BC Systems Corporation

In article <7OCT199210243904@carat.arizona.edu>, jms@carat.arizona.edu (A virtually vegetal non-entity) writes:
> In article <1992Oct7.031040.5662@gw.wmich.edu>, 737ochs@gw.wmich.edu writes...
>>We don't know how to get the person's disk area name
>>from their username. We'd like to be able to do cd ~user and have the 
>>program give us back disk$xxx:[user]. 
> 
> Do a $TRNLOG on SYS$LOGIN.  If you just want the device, look at
> SYS$LOGIN_DEVICE.

In Unix, cd ~user sets your default directory to that of *another* user. 
Translating SYS$LOGIN_DEVICE only makes sense if you're looking for your own
device.

-- 

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: vmsnet.internals
From: kenoyer@cujo.enet.dec.com (Spook)
Subject: Re: re: SET WATCH
Organization: Digital Equipment Corporation
Date: Thu, 8 Oct 1992 23:46:28 GMT


In article <8435551@MVB.SAIC.COM>, "Ian Kitching, System Manager" writes...

>However... I know SET WATCH FILE worked under VMS V5.0 but it hasn't worked
>for me since V5.2. I've eliminated lack of CMEXEC privilege as the problem.

>Ian Kitching    systimk@uk.ac.anglia.va

Ian,
	I just tried it on a  VAXstation running v5.5 and it worked fine (?)

		gdk

+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:
 Greg Kenoyer			     kenoyer@cujo.enet.dec.com
 Digital Equipment Corporation	     Colorado Springs, CO
     any opinions expressed are mine (not Ken's, et.al.), so tough
+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:
Xref: sparky vmsnet.internals:1433 comp.os.vms:16349
From: murphy@npri6.npri.com (David P. Murphy)
Newsgroups: vmsnet.internals,comp.os.vms
Subject: Re: VMS shareable images, what's wrong with them?
Date: 8 Oct 92 19:59:45 GMT
Article-I.D.: npri6.6372
Distribution: world
Organization: NPRI, Alexandria VA


 >    Seeing as recent discussion on this thread  has  degenerated  into  a
 >    flame  fest,  allow me to express my general disgust at the responses
 >    to Garry's (garry@ithaca.com) thoughts on VMS shareable  images  from
 >    the self professed VMS "experts" in this group.
 >
 >[stuff about ehud and carl deleted]
 >
 >    Sorry guys ... any argument that relies on four-letter-friend-getters,
 >    sarcasm, and personal attacks holds little weight in my book.
 >
 >    If  you  don't  have  anything  else  to  offer,  I,  for  one, would
 >    appreciate it if you would go find another thread to flame.
 >
 >mjensen@BBN.COM (Martin Jensen)

while it's true that ehud routinely shifts into Heavy Ridicule Mode,
this is the first time i've seen carl get emotional in the year and a half
i've been netting; he has always been helpful, informative, polite, and
(bonus points here) correct.  if he says that garry is indulging in
dec-bashing without offering any solutions, i'm willing to believe him.

it's not even a religious issue --- there's nothing to discuss.
dec decided to implement shareable images in a certain way, and so they did,
and that's all there is to it.  i certainly wish they had done it differently,
but there's no chance of changing it now because it would be incompatible.

ok
dpm
-- 
murphy@npri6.npri.com 602 Cameron St. Alexandria, VA 22314 (703) 683-9090

              When every one is dead the Great Game is finished.  Not before.
                              --- Hurree Babu, "Kim"
Xref: sparky vmsnet.internals:1399 comp.os.vms:16170
From: mjensen@BBN.COM (Martin Jensen)
Newsgroups: vmsnet.internals,comp.os.vms
Subject: Re: VMS shareable images, what's wrong with them?
Date: 7 Oct 1992 15:09:31 GMT
Reply-To: mjensen@BBN.COM (Martin Jensen)
NNTP-Posting-Host: reliant.bbn.com

carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:

>Forget your simplistic arm-waving.  Tell us, oh genius, in detailed terms,
>exactly how you plan to  avoid this sort of problem.   In other words, jackass: 
>PUT UP OR SHUT UP!  I'd be willing to bet you $100 against your $1 that you
>can't do it.  C'mon, put your money where your mouth is.

    Seeing as recent discussion on this thread  has  degenerated  into  a
    flame  fest,  allow me to express my general disgust at the responses
    to Garry's (garry@ithaca.com) thoughts on VMS shareable  images  from
    the self professed VMS "experts" in this group.

    Ehud (gavron@vesta.sunquest.com) spouts a fair amount of drivel about
    hackers, engineers and "scientifics". Carl (carl@SOL1.GPS.CALTECH.EDU)
    sounds like he would prefer  a  fistfight  to  a  discussion  on  the
    subject.   Neither  one seems to offer any insights or other coherent
    thoughts on  why  (technically)  Garry's  ideas  are  so  bad.   They
    actually  tend to sound somewhat like a VMS "Moral Majority" - VMS is
    good ... DEC did it right ... anyone who says different is  evil  and
    must be exorcised from the NET.

    Sorry guys ... any argument that relies on four-letter-friend-getters,
    sarcasm, and personal attacks holds little weight in my book.

    If  you  don't  have  anything  else  to  offer,  I,  for  one, would
    appreciate it if you would go find another thread to flame.

---   Martin Jensen     \   BBN Communications     \  #include          ---
 ---   mjensen@bbn.com   \   150 CambridgePark Dr.  \  <std.disclaimer>  ---
  ---   (617) 873-4859    \   Cambridge, MA   02140  \                    ---
Xref: sparky vmsnet.internals:1445 vmsnet.misc:927 comp.lang.c:14941
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: vmsnet.internals,vmsnet.misc,comp.lang.c
Subject: Re: malloc() as a user defined function
Date: 10 Oct 92 12:22:21 GMT
Organization: University of Helsinki

ytang@red.crayola.cs.psu.edu (Yuan-Ling Tang) asks about writing a
wrapper around malloc to check its return value and do error recovery if
the allocation fails.  His approach led to the need to write a new
function for each type.

The usual way to solve this problem is probably to use the same type as
malloc, that is `void *' when using Standard C, `char *' otherwise.  You
then get a function similar to this one:

	#include <stdio.h>
	#include <stdlib.h>

	void *my_malloc(size_t size) {
		void *p;

		p = malloc(size);
		if (p == NULL) {
			fprintf(stderr, "can't allocate %lu bytes, "
					"aborting program.\n", 
					(unsigned long) size);
			exit(EXIT_FAILURE);
		}
		return p;
	}

(The above code is untested.  Also note that I printed the error to
stderr, as is customary for error messages, and returned EXIT_FAILURE
instead 0, so that the exit code of the program indicates an error. 
Depending on your application, you may have to change the behaviour when
malloc fails.)

The user will then use my_malloc exactly like malloc, but with no need
to check the return value (if the function returns at all, the value is
valid).  For example:

	struct foo *ptr1, *ptr2;

	ptr1 = my_malloc(sizeof(struct foo));
	ptr2 = my_malloc(sizeof(struct foo));

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
Newsgroups: vmsnet.internals,comp.os.vms
From: winalski@adserv.enet.dec.com (Paul S. Winalski)
Subject: Re: VMS shareable images, what's wrong with them?
Reply-To: winalski@adserv.enet.dec.com (Paul S. Winalski)
Organization: Digital Equipment Corporation, Nashua NH
Date: Wed, 7 Oct 1992 17:48:49 GMT


In article <1aubqgINNbhn@gap.caltech.edu>,
carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes a very snide and insulting
flame challenging those who criticize the VMS method of shareable image version
checking to come up a method of solving the backwards-incompatibility checking
problem without using shareable image version numbers.

Here is one approach that solves the problem.  First, you do away with
transfer vectors and instead bind the references to routines in a shareable
image at run-time (this is in fact the way that Alpha AXP OpenVMS does it).
Second, you do away with the shareable image version ID and replace it with a
separate version ID for each entry point.  That way, a program that doesn't
use any of the new stuff in a shareable image can still run against an older
version of the shareable image.  The only cases where you get the backwards
compatiblity problem is where you are actually calling routines that have
backwards compatibility problems.

--PSW
From: jnelson@gauche.zko.dec.com (Jeff E. Nelson)
Newsgroups: vmsnet.internals
Subject: Re: VAX and Alpha: differences in image size for same program
Date: 7 Oct 92 22:34:44 GMT
Reply-To: jnelson@gauche.zko.dec.com (Jeff E. Nelson)
Organization: Digital Equipment Corporation


In article <00961BED.B4C4E4C0.8746@EIMONI.TUWIEN.AC.AT>, "Franz
Schoenbauer, Computer Science, +43-1-58801-4131" writes:
|>I've recently worked on an alpha and written a programm in MACRO.
|>I had a
|>x:      .blkb   16*1024*1024
|>statement and whoa! my image file had over 32000 blocks !

An image on an OpenVMS Alpha AXP system is usually larger than the
equivalent image on an OpenVMS VAX system. This difference is due to
many factors; probably the most dominant factor is simply the number of
RISC instructions it takes to equal one CISC instruction.

However, I took the following Macro source file:

        .psect  $data$,rd,wrt,noexe
x:      .blkb   16*1024*1024

and generated an OpenVMS Alpha AXP system executable image (with no transfer
address, of course), and the size of the file was 2 blocks, the same as the
size of the equivalent OpenVMS VAX system executable image.

|>On the vax if you had that .blkb statement, the image file was just a
|>couple of blocks and (i believe) the image activator would create those
|>pages when you ran the image. On alpha it seems to be the linker who
|>preallocates them. Can this behaviour be modified ?

It appears that the behavior you saw (a) has been reported as a bug (and
fixed), or (b) is unrepeatable from your example.

|>I have no "real" access to the alpha system, i can only put up
|>benchmark programs and have them compiled, linked and executed,
|>so please forgive me if a simple $ help link or something similar
|>would have told me waht to do.

It is my understanding that field test sites of the OpenVMS for Alpha
AXP operating system have access to Digital support. You should be using
those support channels to report problems and other suspected anomalous
behavior. If you don't have a Digital support channel available or if it
isn't working for you, please let me know. Posting to vmsnet.internals isn't
the best way to get answers to your questions.

-Jeff E. Nelson
-Digital Equipment Corporation
-Internet: jnelson@gauche.zko.dec.com
From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Subject: Re: Shared images, some differences on ALPHA
Organization: Curtin University of Technology
Date: Thu, 8 Oct 1992 20:47:26 GMT

In article <3026@mitech.com>, gjc@mitech.com (George J. Carrette) writes:
> By the way, LINK/SHARE works a bit differently on ALPHA. Indications I've
> gotten (e.g. months ago from OSF/MOTIF source codes) are that there is
> no longer any "globalref" or "globaldef" stuff, for example. e.g.
> 
>      #if defined(VMS) && !define(ALPHA)
>      globaldef ...
>      #else
>      extern ...
>      #endif
> 
> was seen.
> 
Would this perchance be a VAX-C/DEC-C difference, rather than LINK?

~Paul

Xref: sparky vmsnet.internals:1426 vmsnet.misc:903 comp.lang.c:14736