HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.os.vms
Subject: Re: DECterm across DECnet to X Terminal
From: domiller@ualr.edu
Date: 1 Jan 93 23:13:21 GMT
Distribution: world
Organization: University of Arkansas at Little Rock

In article <01GSYWHD85IQ006MJF@VAXF.COLORADO.EDU>, DWING@UH01.Colorado.EDU (Dan Wing) writes:
> I've got an X Terminal (VT1200, only does X with LAT), which I'm using 
> DECwindows/Motif on now.
> 
> There's another VAX, accessible only over DECnet, that I'd like to get run 
> Bookreader from.
> [text deleted]

As has already been pointed out, VT1200s can't do DECNET.  OTOH, your local
VAX (running LAT) can run bookreader and access the files on the remote VAX.
We are doing it that way now.  (Just for confusion, we have 3 CD readers for
the documentation set, on 3 nodes.) Just define the logicals on your local node
something like:

$ define/system/exec DECW$BOOK - 
	RIGEL::DKB400:[DECW$BOOK],-
	ORION::DKB400:[DECW$BOOK],-
	ODIN::DKA400:[DECW$BOOK]
$ define/system/exec DECW$BOOKSHELF -
	RIGEL::DKB400:[DECW$BOOK]DMASTER.DECW$BOOKSHELF

Access would probably improve somewhat if you copied the .BOOKSHELF files to
magnetic media on your local node and added it into the search list, but would
require updates with each new copy of the docs.

P.S. Be sure you set up some appropriate DECNET proxy access.
	Dale
----------------------------------------------------------------------------
| Dale O. Miller                          | #   #  ###  #     ####         |
| University of Arkansas at Little Rock   | #   # #   # #     #   #        |
| 2801 S. University                      | #   # ##### #     ####         |
| Little Rock, AR  72204-1099  USA        | #   # #   # #     #  #         |
| (501)569-8714                           |  ###  #   # ##### #   #        |
| DOMILLER@UALR.EDU, DOMILLER@UALR.BITNET | Disclaimer: This does not      |
| 92-20-28 W,34-43-30 N.ICBMNET           | say what I say it doesn't say. |
----------------------------------------------------------------------------
From: bruce@ais.com (Bruce C. Wright)
Newsgroups: comp.os.vms
Subject: Re: How Open is Open VMS?
Date: 1 Jan 93 13:36:50 GMT
Organization: Applied Information Systems, Chapel Hill, NC

In article <1992Dec31.164508.1051@cmkrnl.com>, jeh@cmkrnl.com writes:
> In article <1992Dec31.190236.29454@zooid.guild.org>, Mark Kovarski <kovarski@zooid.guild.org> writes:
>> 
>> Could someone tell me how "open" Open VMS really is. Is it so open that
>> someone can obtain the source codes, or is it another proprietary operating
>> system with the word "Open" attached to it? Thanks.
> 
> VMS is just as proprietary as, for example, SCO Unix, SunOS, HP-UX, etc.

Just about the only really `open' system is GNU.  IMHO, most OS vendors
who use the term are really engaging in FUD, including DEC's `Open' VMS
and Sun's absurd `Open' posturing.

For what it's worth, one of the products that AIS sells runs on multiple
platforms:  VMS and various flavors of Unix.  Although VMS != Unix and
there have been certain problems keeping things coordinated between the
two systems, by far the _worst_ problems have been with certain Unix
systems, both because of compiler problems and because of OS problems.
I don't think I'm at liberty to discuss the details so please don't ask,
but the vendors I'm thinking about are very well-known Unix vendors.

> [...]
> 
> It is generally not necessary, though, to recompile nor even to relink any
> part of VMS in order to add to it or change it.  In particular, device
> drivers can be added to a live running system.  You can even replace an
> old version of a driver with a newer one on a live system.

You can often replace an old driver with a new driver, but if any of the
driver's data structures change (UCB changes, for example), you may need
to make special provisions for this in the driver's code.  For example,
VMS will not automatically unlink and reallocate a UCB if the UCB length
changes for the new driver.  If you reload a driver that has had that
kind of change, and which doesn't provide for reallocating the system
data structures itself (a complex task in the general case: it may have
to know what the format of every data structure it's ever used is so that
it can properly unlink everything), a system crash is _highly_ likely.

I'm sure Jamie knows this, and that his comment was an offhand comment 
related to the `open systems' nonsense, but if anyone else is doing this
they should be aware of the possibilities for trouble.

Bruce C. Wright
Newsgroups: comp.os.vms
From: zrepachol@cc.curtin.edu.au
Subject: re: hide directory
Organization: Curtin University of Technology
Date: Mon, 28 Dec 1992 14:09:43 GMT

In article <11DEC199211464352@robot.nuceng.ufl.edu>, sysop@robot.nuceng.ufl.edu (Shawn A. Clifford) writes:
> In article <9212101505.AA17670@ucbvax.Berkeley.EDU>, BOB@AENEAS.IMS.DISA.MIL ("Bob George") writes...
>>Subj:	HELP!!! Security problem for gurus.
>> 
>>#	I need to avoid certain people to scan a directory of mine. This
>>#	could seem a very trivial issue, if it was not for the following:

A trick I have used is to copy the data onto the end of BADBLOCK.SYS or
what ever. " Who would ever look in the BAD blocks! "
Also, if its a non DSA disk, they have the real bad blocks to crall over first!

~Paul

PS: Don't bet on it though, Encription is the only good way of securing data.
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: long, long, really long DCL commands
Date: 28 Dec 1992 23:48:50 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 <1992Dec28.172453.24421@ramsey.cs.laurentian.ca>, george@ramsey.cs.laurentian.ca (George Nassas) writes:
=Hi all!  Happy holidays!
=
=The manual tells me that DCL will gladly accept commands of 1024
=characters although each individual line cannot go longer than 256
=characters. Can anyone fill me in on how this works? I read all over
=the FM for an example but couldn't find one.
=
=At first I thought that I could get really long lines by going:
=
=		$ 256 chars -
=		  256 chars - etc...
=
=but no way. What gives? I've stumped all my local experts.

How about giving us a demonstration of what doesn't work?

For example, since:
$ X:=
$ X[0,16]=%x0A0D
$ WRITE SYS$OUTPUT -
"************************************************************************",X,-
"************************************************************************",X,-
"************************************************************************",X,-
"************************************************************************",X,-
"************************************************************************",X,-
"************************************************************************",X,-
"************************************************************************",X,-
"************************************************************************",X,-
"************************************************************************",X,-
"************************************************************************",X,-
"************************************************************************",X,-
"************************************************************************",X,-
"**********************************************"

works, it's not obvious what problem you might be having.
--------------------------------------------------------------------------------
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: don@ANZIO.GATECH.EDU
Newsgroups: comp.os.vms
Subject: ERROR MESSAGES
Date: 2 Jan 93 21:58:49 GMT
Distribution: world
Organization: The Internet

I have a real problem~r a{d I am not sure what to do.  I have a software
program that I bought but it runs too slow.  I can't hardly ~rget anything
done with it{ so I decid{ that instead I should run it on VAX.  So, I use
kermit to transfer it to VAX and it looks good it's got the same name
and everything.  But when I t{y to RUN it, I just get error messages and
I don't know why.  So, I figure that I have something wrong and I go to
the VAX guy and he says that block size needs to bg{ changed and so I use
FILE and change blocksizes.  It still doesn't work when I go this because
I run it and it just gives me a lot of numbers on the screen.  This isn't
useful.  I am wondering if it{might be because I don't have EGA on the VAX
and I think the software program might need EGA{  Is there some way I get
another program emulate EGA or something?

Thank you everybody.

Newsgroups: comp.os.vms
From: despair@netcom.com (Scott Hanson)
Subject: Re: C pointer question
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Wed, 23 Dec 1992 21:14:37 GMT

I apologize for being vague; my project is behind schedule and I don't have
time to make it perfect.  Maybe later if I can't solve this.  I was just
hoping someone had run across a similar problem and could give me some
suggestions.  You can bet I'll post a summary whatever happens.  Are there
any tips for one who has only worked on Unix, MS-DOS, Primos, and C-64
platforms?  Any "features" or uncommon (but legal) requirements?  If I
am being too vague please don't complain, I'll get to specifics as soon
as I can.  If you have any pointers (heh heh) please let me know.
-- 
Scott Hanson		This has been a recording.
despair@netcom.com
Newsgroups: comp.os.vms
Subject: Re: ballooning EXE size
From: leonard@telcom.arizona.edu (Aaron Leonard)
Date: 29 Dec 92 12:02:19 MST
Reply-To: Leonard@Arizona.EDU
Distribution: world,local
Organization: University of Arizona Telecommunications

In article <01GSUT89O7JK000J0I@XRT.UPENN.EDU>, BUHLE@XRT.UPENN.EDU ("E. Loren Buhle, Jr.
[-662-3084]", 215 writes:

| 
| I have a problem with the size of an executable going from ~1,000 blocks to 
| something on the order of 75,000 blocks. 
| 
| What am I doing? I am charged with writing a small interface to some existing 
| FORTRAN code. I have no control over the existing FORTRAN code and can only say 
| that it makes extensive use of VAX-FORTRAN Structure/record/map statements. I 
| don't own the large body of FORTRAN code and really don't relish the thought of 
| rewriting it...
| 
| When the FORTRAN interface stub subroutines (e.g. subroutines that print a "not 
| implemented" message and return) are replaced with my code, the resulting 
| executable goes from ~1,000blocks to ~75,000 blocks. 
| 
| Yes, I use some scratch arrays (scratch arrays defined as local to the 
| subroutine), so I replaced these with LIB$GET_VM and LIB$FREE_VM and the 
| executable size when back to ~1,100 blocks. I presume the difference is due to 
| my code size. Ok so far, but I can't get away with this for long....

Does your FORTRAN program declare its arrays initialized to some value?
From: dongray@GENRAD.COM (Derek Dongray)
Newsgroups: comp.os.vms
Subject: Re: DECW$TRANSPORT_COMMON not up to date ?
Date: 31 Dec 92 11:33:21 GMT
Organization: The Internet

> For those on VMS 5.4 the correct minor ID of DECW$TRANSPORT_COMMON
> is 00000D.  Thats what it is on the Vax Station at work
> and that's what DEC say it should be, I asked.  However, having
> sent out some beta software I have had two people in different parts
> of the world complain that their software don't run, and the problem
> has been traced to DECW$TRANSPORT_COMMON having the wrong minor ID
> of 00000C. ie. their DECW$TRANSPORT_COMMON is still at VMS 5.3
>
> Does this sound familiar to anyone ?  If so, could you please E-mail
> me and I'll post a summary to the Net.  If not, could I trouble
> 1 or 2 people who are on 5.4 to ANALYZE/IMAGE DECW$TRANSPORT_COMMON
> and let me know what their minor ID is.  ( I think it's about the 5th
> line, but I'm not at work now, so I can't check for sure. )

I couldn't E-mail, because there's no address given in the message (and most of
the headers are thrown away somewhere along the line ...).

>         Ben A :-)

Anyway, I'm on V5.5-1 and the minor id of DECW$TRANSPORT_COMMON is %X'00000C'.
Systems were upgraded from CONDIST CDs, July 92; previous versions were A5.5,
V5.4-2, V5.4-1, (V5.4 only long enough to put U1 on!), V5.3-1 ...

This caused me a problem some time ago, as SYS$SYSTEM:DECW$DWT_DECNET.EXE on
the same system wanted a minor id of %X'00000D'! DEC's suggestion was to pull
an old version of DECW$DWT_DECNET off an older distribution kit. I took another
option and just patched the header to accept the 'older' version. DEC weren't
aware of any significant change in either image; they did not indicate which
the 'correct' minor id should be; it seemed that either was acceptable! I
gather that since support for DECwindows/XUI has declined there hasn't been as
much checking as there should.

--------------------------------------------------------------------------------
Name : Derek Dongray, Systems Manager, GenRad Ltd.
Phone : 061 486 1511 ext 166
InterNet : Dongray@GenRad.com               UKnet : Derek.Dongray@GenRad.co.uk
PSS : 234261600119::Dongray                 CompuServe : 70374,2745
Address : Monmouth House, Monmouth Road, Cheadle Hulme, Cheshire, SK8 7AY, UK.
From: finocchiaroj@merrimack.edu
Newsgroups: comp.os.vms
Subject: help on Dec to PC emulation
Date: 21 Dec 92 20:54:01 GMT
Organization: Merrimack College, No. Andover, MA, USA

Does anyone have a copy of dec 102 or up keyboard mapper for a PC. Specifically,
for the PC'S function keys and for the keypad. I just need the escape codes for
these keys so that I can use them in my communications software. I would 
appreciate anyones help on this.
Newsgroups: comp.os.vms
From: vli@mpr.ca (Vincent Li)
Subject: Unbound array in C
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada
Date: Fri, 1 Jan 93 00:46:14 GMT

OK, this may or may not be the right place, but seems to be the best I could
find. I've looked up the VAX C reference, VAX Pascal reference, and even
descrip.h, but couldn't figure this one out. May be I'm not looking in the
right places. Here's my question: How do you call (VAX) Pascal from (VAX) C
where one of the parameters is an unbounded(?) array?

What I'm trying to do is to create essentially a .h interface to allow me
to call some Pascal functions from C programs. One of the Pascal function
is defined as:

TYPE 
   a_string = packed array [1..132] of char;

FUNCTION get_all_switch(var name : array [$l..$u:integer] of a_string
                       ):integer;

The corresponding C function would be:
int get_all_switch(desc);
where desc is a pointer to a descriptor structure.

typedef struct {
        struct dsc$descrip_a arr_dsc;
        char   *a0;
        long dsc$l_m[2];
        struct {
         long dsc$l_l;
         long dsc$l_u;
         } des$bounds[2];
} array_dsc;

array_dsc *desc;

and the actual array as:
typedef char a_string[132];
a_string name[200];

Now, what I am having problem with is how do you set up the descriptor
sturcture? I tried to follow the instructions in the C reference, but can't
get it to work. I think it is correct to use the struct dsc$descrip_a
for the descriptor. I defined the dimension to be 2, since this is an array
of strings. When I call the function, I defined a C array of array[200]
and passed in 0 for the lower bound and 199 for the upper bound (I also tried
using 1 and 200, which does not work either). Running from the debugger, I
seem to be a couple of bytes off or something in the descriptor structure.

So, how should I fill in the descriptor block in the call? Am I missing
something? I'm pretty sure I got all the & in the right places. (I even tried
just about all possible combinations with and without.) It either does a
dump or returns nothing in the array.

Thanks in advance.

-- Vince

---------------------------------------
vli@mprgate.mpr.ca        |-) It works well under pressure: Another thing
                          |-] you can say about your pillow. -- Mr Boffo
From: burkhardt@NEBULA.SSD.LMSC.LOCKHEED.COM (Spike Burkhardt)
Newsgroups: comp.os.vms
Subject: Re: PROBLEM WITH VAX C
Date: 21 Dec 92 17:51:50 GMT
Reply-To: burkhardt@NEBULA.SSD.LMSC.LOCKHEED.COM
Organization: LMSC, Sunnyvale, California

In article <Bz8FsF.8D9@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill Hallam-Baker) writes:
>In article <Bz5zIo.6FE@dale.cts.com>, glippert@dale.cts.com (George Lippert)
>writes:
>
>|>Paul S. Winalski (winalski@adserv.enet.dec.com) wrote:
>|>> Programmierer@BEIZ.mediatex.ch (055485666: MEDIAtex AG) writes:
>|>> |>On VAX-C I receive a message that there is a comma missing between the
>|>> |>two constants.
>|>> |>
>|>> |>how can I force the merging of the constants in VAX-C?
>|>> |>
>|>> |>in Borland C following two lines are equal after compiling:
>|>> |>    printf("one " "two ");
>|>> |>    printf("one two ");
>|>> You can't.  Sorry.
>|>
>|>Any Standard C compiler will do this.  The problem is that VAX C isn't ANSI.
>|>
>|>Shame on DEC for this. Two days from today (ie. 14 Dec 92) will mark the
>|>third
>|>anniversary of the ANSI approval of the Standard.  How much longer will DEC
>|>take!?
>|>
>|>You could buy a third party Standard C compiler for your VMS machine.  Here's
>|>a reference to the only one I know about:
>|>
>|>* TauMetric, ANSI C for VMS, La Mesa, CA, Sue Lindsey (Sales) 619.697.7674
>
>DEC C for alpha claims to be standard ANSI. It is also to be avaliable for VAX
>at some point by the looks...
>
>In the meantime the hack :-
>
>printf ("%s%S", "one", "two");
>
>works provided "one" and two are not intended to contain "%" stuff.
>
>Three years for implementation of ANSI standards ain't that bad. When do you
>think the FORTRAN 90 compilers will be out? 
>
>ANSI C is a plot to make everyone buy another copy of K&R.
>
>--
>
>Phill Hallam-Baker

I may be way off base but in my version of VAX C(3.2) the following program
does work:

#include <stdio.h>

main()
{
  printf("one two \n");

}

I'm linking this program with the following commands:

$ link main, c_options/opt
$

where c_options is a one line options file:

sys$share:vaxcrtl.exe/share

Spike Burkhardt
Systems Management VMS/Unix programming
Internet address - spike@lmsc.lockheed.com
408-742-1246(w)
From: jeh@cmkrnl.com
Newsgroups: comp.os.vms
Subject: Using SEARCH on HELP...
Date: 24 Dec 92 04:36:46 GMT
Organization: Kernel Mode Consulting, San Diego, CA

In article <1992Dec23.203029.1002@cmkrnl.com>, jeh@cmkrnl.com writes:
> In article <1992Dec23.160636.27010@tigger.jvnc.net>,
>> In a DCL program, I would like to be able to determine what directory the
>> invoked .com file is located in.  I seem to remember a similar thread about
>> 6 - 8 months ago, so I hope someone remembers the solution.
> 
> General rule of DCL command procedures:  If you want information about 
> something -- almost anything -- look at lexical functions.  HELP LEXICALS
> gives you a complete list.  Unfortunately this is one of those cases where
> you have to know the name by which VMS refers to something before you can
> go looking for it. 

Next time you are faced with a similar problem -- you're willing to go looking
in HELP but don't know the right words -- try something like this:

	$ library/help/extract=lexicals/outp=temp sys$help:helplib

(Yes, helplib.hlb is w:re by default.)  You now have a plain text file,
TEMP.HLP, containing all of the text under HELP LEXICALS.  It's about 300
blocks.  Next do 

	$ search temp.hlp procedure

which would have found 

   PROCEDURE          String    File specification of the current
                                command procedure. If used
 
among others. If you do your searching from inside an editor you won't even
have to go back to HELP to get the full information.

p.s. Be a good user and delete temp.hlp when you're done. 

	--- 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: jweiss@casbah.acns.nwu.edu (Jerry Weiss)
Newsgroups: comp.os.vms
Subject: Writeback Cache and other trivia
Date: 22 Dec 92 22:06:07 GMT
Organization: Northwestern University, Evanston Illinois.

During a regular test of my backup procedures (ie: my system crashed and
when it came back up a few things didn't work ;-( ) I discovered that I did
not have a copy of jbsysqueue.dat on my daily incremental backups
[backup/mod/since=backup....].  I pulled a slightly older copy off my full
image backup and sat down and tried to understand why.  Jbsysqueue.dat is
one of those files that is always open and the modified field in the
directory header is not updated.

Is there a standard way to mark the file as modified so it gets picked
up normally in this situation?  I've RTFM but it doesn't give me any
insight into this particular situation.

Should I just make a copy before my daily backups ?
[backup/ignore=(interlock) jbsysqueue.dat copy_of_jbsysqueue.dat]

Does the mount/cache=writethrough option have any bearing on this problem?
If so, how does one set this for the system disk?

Any there other files in VMS (not counting 3rd party software) that
require special attention?

Thanks for any help, pointers or suggestions you may offer.




-- 
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
Newsgroups: comp.os.vms
Subject: Re: HELP!!! Security problem for gurus. [Directories]
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 2 Jan 93 16:10:55 GMT
Distribution: world
Organization: The Wolery

leichter@lrw.com (Jerry Leichter) writes:
> very high cost estimates, or add things by just doing them.  A famous example
> is the reverse-video "Interrupt" you get for CTRL/Y.  This started out as a
> joke played on the VMS group by the terminal driver implementor:  He snuck it
> in one day.  Everyone liked it, so it ended up in the product.

It's worse than that.  Check out SYS$EXAMPLES:SYSGTTSTR.MSG sometime....

(My system says "Ouch!" of you hit Ctrl/Y... 8-)

> Seriously, I have a copy of the ODS-II spec - after all, I *did* work for DEC
> for 12 years!  It's not a particularly secret spec; I know other people have
> copies, probably more recent ones than mine.

There was a copy on a the ?Fall '91? L&T tape, or at least something that
looked very much like it.  I uses RSX style specifications.  The ODS-1 spec
was there too, along with some stuff on RMS-11 (not VAX RMS) internals.

> 	>BTW, it's not impossible that SOME invalid directory entries will
> 	>could cause (probably non-fatal) bugchecks.  
> 
> 	I remember seeing RMS bugs in the past that would delete the erring
> 	process upon encountering certain errors in on-disk or file structure.
> 	I was always surprised to find such dramatic bugs in RMS, an otherwise
> 	extremely robust-seeming entity...  

I've seen of corrupt directories blow the XQP out of the water, closely
followed by the rest of the system....  I think it was V5.3 that exhibited
that bug.  And no, BUGCHECKFATAL was *not* set....

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