HDTenEightyP/NetNews huggingface dataset:
Newsgroups: vmsnet.internals
Subject: Re: Source CDs
From: jms@carat.arizona.edu (A virtually vegetal non-entity)
Date: 1 Oct 1992 08:34 MST  
Reply-To: jms@Arizona.EDU
Distribution: world,local
Organization: University of Arizona MIS Department - Mosaic Group
X-Lunar-Date: 3 days, 0 hours, 28 minutes since the new moon
News-Software: VAX/VMS VNEWS 1.50A   

In article <8434779@MVB.SAIC.COM>, "CCF::GPE%hermes.mod.uk"@relay.MOD.UK
writes... 

>Can someone please give me some information on the VMS source CDs. EG

Before you go too far, you need to distinguish between SOURCE and LISTINGS. 
Actually, to really confuse things, Digital refers to the listings as the
SOURCE LISTINGS, so when you ask about "source," you're really getting
listings.

Getting listings is easy.  Since you're in the UK, the price will vary. You
should call your local office.  They can either sell you a single CD (or
Microfiche, I think) or add it to your maintenance contract.  Either way,
it's not too expensive---couple of hundred dollars.

They are usually not too behind VMS.  I think that the 5.5 listings 
are available, but I'm pretty sure that the 5.5-1 listings are not.

SOURCE, on the other hand, is extremely difficult and expensive (about $25k
in the US).  If I were you, I'd give it up.  It took me three years to get
Digital to cough up a source kit for VMS (although they did send 5.4).  I have
been told by the product manager that there will probably never be a 
SOURCE kit done after 5.4. 

jms

Joel M Snyder, 1103 E Spring Street, Tucson, AZ, 85719 
Phone: 602.882.4094 (voice) .4095 (FAX) .4093 (data)
BITNET: jms@Arizona  Internet: jms@arizona.edu  SPAN: 47541::telcom::jms
Yow!  I'm having a quadrophonic sensation of two winos
 alone in a steel mill!
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: vmsnet.internals
Subject: Re: Source CDs
Date: 4 Oct 92 08:27:54 GMT
Distribution: world,local
Organization: St. Peter's College, US

In article <1992Oct2.133612.704@cmkrnl.com>, jeh@cmkrnl.com writes:
> Source listings on fiche or mag tape are no longer available. 

  Right. The last set issued, as far as I know, was for 5.4-3. Of course, the
index has been utterly wrong since 5.1. Alan Frisbie single-handedly waged a
major battle to get the fiche re-issued with the correct indexing, and finally
won. I'll let him relate the story if he chooses to...

> I wouldn't say so.  Getting your local sales critter to even admit that such
> things exist can be difficult.  "Oh, no, we don't sell listings."  This is
> especially painful since a lot of us in DECUS went to a lot of trouble to
> convince DEC to offer the machine-readable listings kit... and they may well
> withdraw it if it doesn't sell well... and it won't sell very well if the sales
> dweebs won't admit that it exists! 

  Well, I haven't had any problems. When V4.whatever (4.5, I think) came out
with the "you have to pay for this if you want it" bit for fiche, I called and
read them the part number. That worked until the big price jump (at contract
renewal, I got hit around 5.3) at which time they noted that fiche would be
discontinued and we'd have to switch to CD. Again, I called up and gave them
the part number.

  I don't think the local offices will do any better or worse with listings
than anything else, provided you give them the part number. Also, I doubt that
thet could do the right thing for simple stuff, like VAX BASIC.

  [This isn't a dig at my local folks, who are as good as I'd wish. However,
I have been to the local office and watched them enter my contract into the
system, only to have it generate a renewal hallucination which got it all
wrong... Strange.

  BTW, they will always master CD's for the CSC - that's where the fiche went
to, and when the CSC switched to CD, so did everybody else.

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.internals
Subject: Shared images, some differences on ALPHA
Date: 6 Oct 92 09:17:23 GMT
Organization: Mitech Corporation, Concord MA

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. 

My biggest gripe about sharable images has always been that if you wanted
to share data psects in an upward-compatible way you had to be
DARNED CAREFUL to collect things properly in your linking.

In fact, if you were really careful you needed to write a program
that would parse the linker /MAP/FULL file and check to be sure that
your transfer vector was the same size at the front, and your data
psects were in all the same places after that, etc.

And DIGITAL never provided explicit examples to your average C programmer
on how to make "extern" variables sharable in a GSMATCH upward image.

On the other hand, if you asked hotline support an explicit question like:
"how do I make something work in my /SHARE image like stdout works
in the VAXCRTL.EXE" you would get the info you need.

-gjc

p.s. Of course, anybody who thinks he has a gripe with any inconvenience
     of the VMS linker should try looking at how you have to do things
     under SUN-OS with sharable images!
From: "CCF::GPE%hermes.mod.uk"@relay.MOD.UK
Newsgroups: vmsnet.internals
Subject: Source CDs
Date: Thu, 1 Oct 92   9:19 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Having damaged my brain on IDS I am now hoping to go for the kill by getting
the VMS source :-)

Can someone please give me some information on the VMS source CDs. EG

* Part number

* Cost

* Are they
  (a) licensed like a piece of software (ie pay a licence fee and an
      ongoing maintenance charge)
  or
  (b) just sold like a book (pay once and get one copy)

* Assuming (a), how often are they updated and how far behind the VMS release

* Any other useful information (on the source CDs - before anyone interprets
  that too widely!)

Thanks in advance

Graham

Graham Evans
GPE%hermes.mod.uk@relay.mod.uk or GPE@hermes.mod.uk (INTERNET)
GPE@uk.mod.hermes (JANET)
Newsgroups: vmsnet.internals,comp.os.vms
From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Subject: 5.5 fiche PN
Organization: Curtin University of Technology
Date: Tue, 6 Oct 1992 09:24:00 GMT

In article <01GPFO58Y54G96VM2T@MONMOUTH-etdl1.Army.MIL>, SCHENKENBERG@Monmouth-ETDL1.Army.MIL writes:
...
> The last source listings 'fiche' (real microfiche) that I have is v5.2. _IF_
> someone knows of 'real' microfiche source listings for version 5.5, please
> post the P/N here.
> 
AH-PN4LB-SE

Newsgroups: vmsnet.internals
From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Subject: re: file header full on system disk
Organization: Curtin University of Technology
Date: Wed, 30 Sep 1992 13:58:49 GMT

In article <1992Sep25.104629.16194@infocomm.com>, mark@infocomm.com writes:
> In article <2180229E_00057EE8.009612482C133540$6_1@UK.AC.KCL.PH.IPG>, SYSMGR@IPG.PH.KCL.AC.UK writes:
>> After you have done your backup/restore, it is a good idea to make sure
>> that the header file is extended before the disk gets fragmented again.
>> There are two ways to do this. The slow safe way is to CREATE a large number of
>> empty files (as many as you want there to be space for, up to a maximum
>> of ^50,000), then delete them again. The quick but unsupported way is to use
>> the $EXTEND service on INDEXF.SYS to force it to add as many more headers
>> as you like. After you do this, run ANALYZE/DISK. It will report that the
>> backup index file header is bad -- it's no longer a faithful copy of the
>> main one. ANALYZE/DISK/REPAIR fixed this.
>> 

An idle speculation, how about $CREATEing a file with FID=80000 or so? This
should cause the XQP to do the extend.
~Paul
From: jeh@cmkrnl.com
Newsgroups: vmsnet.internals
Subject: Re: Source CDs
Date: 2 Oct 92 13:36:12 PDT
Distribution: world,local
Organization: Kernel Mode Consulting, San Diego, CA

In article <1OCT199208343987@carat.arizona.edu>, jms@carat.arizona.edu (A virtually vegetal non-entity) writes:
> In article <8434779@MVB.SAIC.COM>, "CCF::GPE%hermes.mod.uk"@relay.MOD.UK
> writes... 
> 
>>Can someone please give me some information on the VMS source CDs. EG
> 
> Before you go too far, you need to distinguish between SOURCE and LISTINGS. 
> Actually, to really confuse things, Digital refers to the listings as the
> SOURCE LISTINGS, so when you ask about "source," you're really getting
> listings.

This is funny.  In the past, Digital has always referred to the listings as
"listings".  In fact one of the VMS product managers once told me that a large
source of the confusion within DEC re. this product was that customers kept
asking for "source listings" and DEC didn't know if they wanted sources or
listings.  These days I guess they've decided to change the product name to
match what people are asking for. 

Anyway, the part numbers and U.S. prices are:

	QB-001AB-E8	VMS SOURCE LSTS & LIC CDROM	$ 2180.00

If I read things correctly this comes with a year's worth of update service.
After that, the update service is:

	QT-001AB-Q8	VMS SOURCE LSTS CDROM UPD SVC	$  780.00 (per year)

Source listings on fiche or mag tape are no longer available. 

> Getting listings is easy.  

I wouldn't say so.  Getting your local sales critter to even admit that such
things exist can be difficult.  "Oh, no, we don't sell listings."  This is
especially painful since a lot of us in DECUS went to a lot of trouble to
convince DEC to offer the machine-readable listings kit... and they may well
withdraw it if it doesn't sell well... and it won't sell very well if the sales
dweebs won't admit that it exists! 

Anyway, the QB kit includes the media and the necessary license.  You are 
required to sign a special source license agreement.  

> SOURCE, on the other hand, is extremely difficult and expensive (about $25k
> in the US).  If I were you, I'd give it up.  It took me three years to get
> Digital to cough up a source kit for VMS (although they did send 5.4).  I have
> been told by the product manager that there will probably never be a 
> SOURCE kit done after 5.4. 
> 
> jms

Well, once again, if enough people would buy it, DEC will sell it.  
What was the model number for the source kit?  I can't find it on the e-store. 

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
From: GAVRON@VESTA.SUNQUEST.COM
Newsgroups: vmsnet.internals
Subject: RE: Program code to SET UIC
Date: 30 Sep 92 18:00:24 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Date sent:  30-SEP-1992 10:57:55


>I need to write a little routine to change UIC for an arbitrary, captive
>user.  Fortunately, INFO-VAX has been following this for the last few days,
>and has produced the following CMKRNL routines:
>
>(1)     .ENTRY  KERNEL, ^M<R2,R3,R4>            ;Save our registers
>        JSB     SMP$GET_CURPCB                  ;Get ther current PCB
>        MOVL    NEWUIC,PCB$L_UIC(R4)            ;Tweak its little UIC
>        MOVZWL  #SS$_NORMAL,R0                  ;Return happy
>        RET                                     ; as a little bird
>
>(2)     .ENTRY  CMKRTN, ^M<>                    ;Registers, what registers
>        MOVL    G^CTL$GL_PCB,R0                 ;GET THE PCB ADDRESS
>        MOVL    UIC, PCB$L_UIC(R0)              ;GET THE NEW UIC
>        MOVL    #SS$_NORMAL,R0                  ;SET OK RETURN CODE
>        RET                                     ;BACK
>
>Personally, I like (2) best, since I cannot see what the hell happens
>when I JSB to SMP$GET_CURPCB (what with no listings or fiche).
>
>I throw this out to the MACRO32 list for ideas and comments.

SMP$GET_CURPCB is an undocumented could-go-away-at-any-time entry point.
However, I would rewrite the second piece of code as:

        .entry  setuic,^m<>
        movl    uic,pcb$l_uic(r4)
        movl    #ss$_normal,r0
        ret

        Note: SYS$CMKRNL automatically puts the PCB address in R4

>Thanks in advance,
>
>
> Louis B. Moore                      Internet: lbmoore@tchden.org
> Systems Programmer                  Phone:    +1 303 837 2513
> The Children's Hospital of Denver   Denver, Colorado USA 80218


        Ehud

--
Ehud Gavron        (EG76)
gavron@vesta.sunquest.com
"The world bores you when you're cool."
From: Donley Computer Center <RON@LTUVAX.BITNET>
Newsgroups: vmsnet.internals
Subject: Ehud's flame...
Date: Tue,  6 Oct 1992 06:59 EDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

While making a point in the act of flaming, Ehud says:

>        So this hacker, field service engineer, and a Scientific
>        are in a car and coming down a steep hill the breaks appear
>        to fail.  The Hacker (who is driving) pumps the break and
>        downshifts and finally the car comes screeching to a halt
>        JUST at the edge of the precipice with two wheels over the
>        edge.
>
>        The Hacker suggests they fix the breaks.
>        The field service engineer suggests they call in an expert.
>        The Scientific says "Let's start moving and see if the
>        brakes fail the same way again."

Ehud, I'm surprised...3 out of 4 times in this story you used BREAK rather
than BRAKE!

Ron
From: Arne Vajhxj <ARNE@ko.hhs.dk>
Newsgroups: vmsnet.internals
Subject: Re: SET WATCH
Date: 01 Oct 1992 21:18:42 +0100
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

> One thing I found out when trying to use it is that it requires CMKRNL as an
> AUTHORIZED privilege.  I used Ehud's PRCPRV to give an account CMKRNL to use
> SET WATCH, and it wouldn't work.  So, if you've got CMKRNL as a default priv,
> but not an authorized one, I don't believe that it will work.

I have not used PRCPRV, but SET WATCH FILE works great on my username with
"only" SETPRV as authorized privs:

$ write sys$output f$getjpi("","AUTHPRIV")
SETPRV,TMPMBX,NETMBX
$ write sys$output f$getjpi("","CURPRIV")
TMPMBX,NETMBX
$ set watch file/class=major
%SYSTEM-F-NOPRIV, no privilege for attempted operation
$ set proc/priv=cmkrnl
$ write sys$output f$getjpi("","AUTHPRIV")
SETPRV,TMPMBX,NETMBX
$ write sys$output f$getjpi("","CURPRIV")
CMKRNL,TMPMBX,NETMBX
$ set watch file/class=major
$

????

                                                          Arne

Arne Vajhxj                             local DECNET:  KO::ARNE
Computer Department                     PSI:           PSI%23831001304030::ARNE
Business School of Southern Denmark     Internet:      ARNE@KO.HHS.DK
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: vmsnet.internals
Subject: Re: Source CDs
Date: 6 Oct 92 04:03:16 GMT
Distribution: world,local
Organization: St. Peter's College, US

In article <1992Oct5.020922.714@cmkrnl.com>, jeh@cmkrnl.com writes:
> I know
> of no other hardware-vendor-supported OS (proprietary or otherwise) for which
> you can get listings for only $2K. 

  Back when DEC shipped fiche free with VMS updates, IBM shipped _source_
(real source, not listings) with VM/SP and fiche with layered products such
as the Fortran compiler, etc.

  Now DEC sells the listings and IBM is OCO (Object Code Only). The "new
frontier" is in things like BSD/386 from BSDI, which is a full Berkeley-
style Unix (tm) environment which is a supported commercial product. Of
course, they don't sell hardware...

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381
From: Ian Kitching, System Manager
Newsgroups: vmsnet.internals
Subject: Re: SET WATCH
Date: 2 Oct 92 08:29:00 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

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

Followup:

Whatever I do as regards process or image privileges, SET WATCH never modifies
the PIO$GW_DFPROT cell so nothing happens. I just wrote a program that toggled
the low bit and XQP messages appeared, so the problem is in SET WATCH.

As it happens I have SETWATCH installed with CMEXEC.

It seems to be the correct version of the image, as loaded by VMS V5.4
installation.

So, any ideas?

Ian Kitching    systimk@va.anglia.ac.uk


SYS$COMMON:[SYSEXE]SETWATCH.EXE;1
Created:  20-JUL-1990 08:31:40.42
Revised:  20-JUL-1990 08:31:40.79 (1)
Fixed Header Information
        system version (major/minor): 1.0
        system version array information: (Image Value / Current System Value)
                                SYS$K_FILES_VOLUMES : (1.64 / 1.64)
                                SYS$K_SHELL : (1.64 / 1.64)
Image Identification Information
        image name: "SETWATCH"
        image file identification: "X-5"
        link date/time:  5-JUL-1990 16:30:34.37
        linker identification: "05-05"
Newsgroups: vmsnet.internals
Subject: Re: Reading VMS Trace Back Dumps 
From: allebrandi@inland.com (Tom Allebrandi)
Date: 1 Oct 92 12:54:14 CST
Organization: Inland Steel Company; East Chicago, IN

In article <299@cgi.UUCP>, baw@cgi.UUCP (Barry Waters) writes:
> I have a problem that >seems< to be internals oriented so I will
> post it here. I have a program that is linked with several shareable
> images (RTLs). This program is submitted to a batch queue nightly.
> Every fouth or fifth night the guy suffers an access violation and
> produces a trace back dump in the .LOG file produced by the batch 
> handler.
> 

From your example, I would guess that your test method is flawed and that
you are looking at two different problems:

> 	%SYSTEM-F-ACCVIO, access violation, reason mask=00,
>         virtual address=00000018, PC=0011037f, PSL=03c00004
> 

> 	%SYSTEM-F-ACCVIO, access violation, reason mask=00,
>         virtual address=0000000, PC=00095632, PSL=03c00004
> 


Regardless of where the shareable image lands in memory, the address of
the failure modulo 512 (200 hex) should always be the same. Note in
your examples that they are not. (17f != 032)


Have you tried enabling process image dumping (SET PROC/DUMP)?


I have some practice in hunting these kinds of things down. (Ever hear
of the DECUS UUCP "Infamous Access Violation"?) Let me know if you need
some further assistance.

--- Tom
Tom Allebrandi             | Mail guru   - DECUS UUCP Development Team
Inland Steel Research Labs | NFS grunt   - CMU/Tek-IP
East Chicago, IN           | Chairperson - VMSnet Working Group, DECUS VAX SIG
219 399 6306               | Internet:  allebrandi@inland.com
DECUServe: allebrandi      | UUCP:      ...!uunet!inland!allebrandi
From: GAVRON@VESTA.SUNQUEST.COM
Newsgroups: vmsnet.internals
Subject: RE: Ehud's flame...
Date: 6 Oct 92 21:35:54 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Date sent:  6-OCT-1992 14:35:35


>Ehud, I'm surprised...3 out of 4 times in this story you used BREAK rather
>than BRAKE!
>
>Ron

        Ron, gimme a break ;-)

        Ehud

--
Ehud Gavron        (EG76)
gavron@vesta.sunquest.com
Xref: sparky vmsnet.internals:1390 comp.os.vms:16131
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.internals,comp.os.vms
Subject: Re: VMS shareable images, what's wrong with them?
Date: 6 Oct 92 08:57:07 GMT
Organization: Mitech Corporation, Concord MA

In article <Bvo7FC.M01@ithaca.com>, garry@ithaca.com (Garry Wiegand) writes:
> Only later did code
> modularity, and library shareable images, become interesting
> concepts, and by then it was too late to change the defaults.

Pure fantasy and fiction. The importance of shareable images
has existed in VMS since before the first line of VMS was written.

> Everyone with portable code nowadays has to has to use a linker
> options file to override all the compiled psect declarations. 

And every smart person creates this options files automatically.

So even if the default were NOSHR, should the default be NOSHR,LCL or not?

Don't forget, that in Multics, well, sigh, I bet you have never heard
of Multics in any useful detail...


-gjc

Newsgroups: vmsnet.internals,comp.os.vms
From: garry@ithaca.com (Garry Wiegand)
Subject: Re: VMS shareable images, what's wrong with them?
Organization: Ithaca Software
Date: Mon, 5 Oct 1992 22:49:59 GMT

In a recent article I wrote:
>> DEC ought to redo their shareable-image technology. The current method
>> was invented almost 15 years ago and has a variety of problems.

And Nigel Arnot responded:
>        I'm curious. I know that making a shareable image can be tedious,
>but once put together they seem to work rather well. What improvements
>do you have in mind, and has anyone done something like them already?

The Big 3 that come to mind:

1. Writeable psects should default to "no-share" in all the higher languages.
2. Transfer tables should go away.
3. Shareable image version numbers should go away.

#1 is an artifact of the way someone at DEC was thinking about
virtual memory in the early days. The rule became "if you're shared,
and you have a Fortran common block, say, you MUST be trying to
communicate through writeable shared memory - why would any user
program want to be shared otherwise??"   Only later did code
modularity, and library shareable images, become interesting
concepts, and by then it was too late to change the defaults.
Everyone with portable code nowadays has to has to use a linker
options file to override all the compiled psect declarations. 

The way to achieve #2, the departure of the transfer table, is by
"lazy binding" of symbols - the linker just checks that the symbols
needed are there in the current version of a referenced shareable
image; the image activator does the work at run-time of making the
final symbol-to-address binding. The first time I saw this, years
ago, I said "naah, that can't possibly be fast enough - image
activation will be slowed down bigtime." Being scientific, I
immediately set out to prove my foregone conclusion. Un-for-tunate-ly,
in all the torture tests I could dream up the slowdown due to the
dynamic binding was either trivial or completely undetectable. And
since then CPU's have gotten a lot faster. (The activator code I was
testing was probably a BSD4.3 Unix derivation on a Sun. They did a
good job of that code.)

The primary purpose in life of #3, the shareable image version
numbers, is to guard to the transfer table against "accidents". Once
the transfer table is gone (#2) one can immediately do away with the
version numbers (or change the default setting to "match any".)
You'll recall that version-number unpleasantness on Vaxcrtl.exe is
what got us started on this thread originally.

Wouldn't it be nice to build a shareable with a simple /SHARE,
no options file and no assembler code?

Finally, Mark Porter points out to me privately that there is a
security problem in this area. Which I won't go into. (As far as I
can see he's right.)

Garry Wiegand --- garry@ithaca.com --- Ithaca Software, Alameda, California
Xref: sparky vmsnet.internals:1395 comp.os.vms:16146
From: gkn@ucsd.edu (Gerard K. Newman)
Newsgroups: vmsnet.internals,comp.os.vms
Subject: Re: VMS shareable images, what's wrong with them?
Summary: Thanks!
Keywords: LIB$FIS
Date: 6 Oct 92 22:51:23 GMT
Organization: TGV, Inc.
NNTP-Posting-Host: ucsd.edu

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.

One of my favorite toys.  Thanks, if you had anything to do with it.


-- 
Gerard K. Newman,  TGV, Inc.  603 Mission St.  Santa Cruz, CA  95060
gkn@tgv.com | 619.591.4717 (voice+fax) | 800.TGV.3440 | 408.427.4366