HDTenEightyP/NetNews huggingface dataset:
Newsgroups: vmsnet.internals
Subject: Re: device driver hackery
From: jeh@cmkrnl.com
Date: 11 Apr 92 17:12:51 PDT
Organization: Kernel Mode Consulting, San Diego CA

In article <s2qaaINNmvu@ucsd.edu>, gkn@ucsd.edu (Gerard K. Newman) writes:
> In article <1039@mitech.com> gjc@mitech.com (George J. Carrette) writes:
>>I've seen VMS device drivers written in C, even though that isn't
>>a highly-recommended thing to do, by the use of some macro code to
>>call into the C code entry points.
> 
> How does one do the self-relative pointer to the timeout routine
> generated by the WFIKPCH (or WFIRLCH, for that matter) macro in
> C?
> 
> Just curious.

obviously, you can't.  But you can return back to your macro 'jacket' start
I/O routine, which can then do the WFIKPCH.  

And if you think about it, you will see that you HAVE to do it that way.  Even
if you could trick C into generating a WFIKPCH call. 

There's a lot more going on in WFIKPCH than just the self-relative pointer 
to the timeout routine (a brain-dead design if ever I saw one; why can't the
DDT simply contain an entry for the timeout routine?).  In addition to 
generating the offset, it actually does a JSB to EXE$WFIKPCH.  (or is it IOC$?
no matter, you know what I mean.)  This routine then pops the return address
off the stack and stuffs the result into the operand of the JMP instruction in
the IDB.  It then does a simple RSB to return to its caller's caller -- ie,
to return to your caller.  

Like everything that uses the "return to caller's caller" mechanism, this trick
depends on those two JSB return addresses being at the top of the stack.  If
you did a WFIKPCH from a C procedure, there would be a single JSB return
address on the stack, followed by a call frame (for the CALL from the Macro
jacket routine to your C start I/O routine). 

The only way out of this is the (undocumented) VAX C #pragma that declares that
a routine should be accessed with JSB linkage.  Then you could write your start
I/O routine directly in C, and not bother with jacket routines.  But I still
can't think of a way to emulate WFIKPCH in pure C. 

For myself, I haven't used WFIKPCH (or WFIRLCH) for years.  It just does too
much work that I usually find myself having to undo.  

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru, VMSnet (DECUS uucp) Working Group, 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: DEREK@U.WASHINGTON.EDU
Newsgroups: vmsnet.internals
Subject: Re: What's the use of SETPRV privilege?
Date: Thu, 9 Apr 92 11:09 PDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Carlo Mekenkamp,

As I recall, what you did used to work -- a long time ago.  Now, however,
it doesn't.  As I recall, the $SETPRV system service now checks the
AUTHORIZED privilege mask, but only affects the PROCESS privilege mask.
Therefore, the attempt to do a "$ SET PROC/PRIV=some-other-priv" fails.

'nuf said.

-Derek S. Haining
 University Computing Services
 University of Washington
 Seattle, Washington  98195
 (206) 543-5579

 DEREK@MAX.BITNET
 DEREK@MAX.U.WASHINGTON.EDU
Newsgroups: vmsnet.internals
From: brennan@coco.cchs.su.oz.au (Luke Brennan)
Subject: IOCTL ~ECHO problem..
Organization: Cumberland College of Health Sciences
Date: Sun, 12 Apr 1992 10:59:25 GMT

	Hi people!  (and Ehud :-))

	I've asked the people I thought would know, and haven't come up
	with any solution, so I'm grovelling to the holders of deep VMS
	wisdome for some answers...

	In a unix thingo I've ported to VMS, they use the IOCTL stuff
	to disable echo while grabbing a password from the user.
	Now, it goes something like this..

	if ((tty=fopen("/dev/tty","r")) == NULL)
		tty=stdin;
#ifndef VMS
	if (ioctl(fileno(tty),TIOCGETP,(char *)&tty_orig) == -1)
		return(-1);
	bcopy(&(tty_orig),&(tty_new),sizeof(tty_orig));
#endif

	... lots of code that does "C" things with tty :-) 

#ifndef VMS
	tty_new.sg_flags &= ~ECHO;
	if (ioctl(fileno(tty),TIOCSETP,(char *)&tty_new) == -1)
		return(-1);
#endif

	... lots more code that does "C" things with 'tty' ....

	then another call to turn ECHO back on...


	Due to the fact that 'tty' gets used in other things, is there
	a way I can somehow map that FILE* tty to the kind of channel beasty
	that QIO expects? Then I could just use IO$M_NOECHO, etc...

	Is there a simple way to nuke screen echo that I'm missing?

	of course, I *know* Ehud could find a way :-) :-) 
	(probably just poke the device driver or something magical!)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Luke Brennan                             e-mail: brennan@coco.cchs.su.oz.AU +
+ EDP Unit, S209                                   lukeb@casino.cchs.su.oz.AU +
+                                    brennan%coco.cchs.su.oz.au@cunyvm.BITNET +
+ Cumberland College of Health Sciences,                              ,-_|\   +
+ The University of Sydney                  voice: +61 2 646 6402    /     \  +
+ East Street, Lidcombe, NSW 2141             fax: +61 2 646 4853    \_,-._*  +
+ AUSTRALIA                                                               v   +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
From: bruce@ais.com
Newsgroups: vmsnet.internals
Subject: Re: device driver hackery
Date: 16 Apr 92 00:36:23 GMT
Organization: Applied Information Systems, Chapel Hill, NC

In article <1992Apr11.171251.417@cmkrnl.com>, jeh@cmkrnl.com writes:
> There's a lot more going on in WFIKPCH than just the self-relative pointer 
> to the timeout routine (a brain-dead design if ever I saw one; why can't the
> DDT simply contain an entry for the timeout routine?).

I agree that the self-relative pointer in WFIKPCH is pretty lame,
but I think the point is so that the timeout routine is NOT in the
DDT ... if it were then it would be somewhat more inconvenient to
have a different timeout routine for each state the driver might
be in (of course you can do this with a CASE instruction in the
timeout routine but it's somewhat less obvious since there has to
be something going on 'behind the scene' to save the state routine
number to branch to, etc).

If this was the point it would still have been better to do a 
'MOVAB timeout_routine,rx' (choose a register) than to have that
stupid self-relative pointer.  But that takes a couple of extra
instructions (one to load the register and one to save it ... as I
recall IOC$WFIKPCH doesn't actually calculate the timeout routine
address, it gets calculated only if the timeout occurs.

The only time I've used WFIKPCH/WFIRLCH lately was when debugging
an old (and itself rather brain-dead) driver ... it usually *does*
seem like more trouble than it's worth.

Bruce C. Wright
Xref: sparky vmsnet.internals:733 comp.os.vms:8450
From: flowers@admin1.memst.edu (Harry Flowers)
Newsgroups: vmsnet.internals,comp.os.vms
Subject: RE: Help - Device allocated/mounted to non-existant process
Date: 16 Apr 92 14:51:39 -0600
Organization: Memphis State University

In article <1992Apr16.182010.7959@ucselx.sdsu.edu>, yates@wctdpv.gd.com
 (Jeff Yates (619)547-4726) writes:
>    Actually, I did receive and install CSCPAT_0245 - IO_ROUT.EXE last
>    november while I was running VMS 5.4-2.  That got me thinking that
>    maybe my subsequent upgrade to VMS 5.5 (Feb'92) replaced "DISMNTSHR.EXE"
>    with a new (and still bugged) version.  Such is not the case.  I verified
>    that I am using the patch version.

CSCPAT_0245 has gone through some changes.  I've gotten two versions: 1.2
which patched the IO_ROUTINES.EXE among others, and 1.6, which supplies
SYS$MANAGER:CSCPAT_0245_USE_WITH_CAUTION_MTDISMOUNT.EXE instead of patching
any images (which didn't work, anyway).  I'd suggest getting CSCPAT_0235016
and going back to the VMS 5.5 system images.
--
Harry Flowers                           Internet: FLOWERS@MEMSTVX1.MEMST.EDU
Memphis State University                & Bitnet: FLOWERS@MEMSTVX1
Newsgroups: vmsnet.internals
Newsgroups: vmsnet.internals
Subject: Re: Help getting image dumps?
From: jeh@cmkrnl.com
Date: 7 Apr 92 15:01:31 PDT
Organization: Kernel Mode Consulting, San Diego CA

In article <9204071514.AA17947@ithaca.Eng.Sandy.Novell.COM>,
 <ed_heinrich@npd.novell.com> writes:
>         Years ago I worked for a company with sites throughout the world and
> we had the requirement to have a dump file to examine back in the development
> office.  The following are the extracted relevant pieces that I used in an
> exception handler to cause an image dump file.  It also has the feature of
> purging the dump file to prevent exhausting the customers disk space.
> [...]

Wow!  Thanks!!! 

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protool guru, VMSnet (DECUS uucp) Working Group, 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

p.s.:  Chalk this one up as a time that News/vmsnet/the internals mailing list
wins over DECUServe... I posted the same q on DECUServe, at about the same
time, and so far have gotten only "make sure that sys$procdmp points to a
device and directory that the process can write", and this is not the problem,
since for my simple test cases this logical was not defined. 

Don't get me wrong, I like DECUServe -- I'd better, I'm a moderator there --
but I like News more, and the "community" on the vmsnet part of News is 
every bit as "kind and gentle" as that on DECUServe.
From: dsroberts@beckman.com
Newsgroups: vmsnet.internals,comp.os.internals
Subject: Re: How to implement a mail printing service?
Date: 8 Apr 92 08:35:45 PDT
Organization: Beckman Instruments

I'm not at all clear why this is in vmsnet.internals rather than
vmsnet.mail.misc, but...

In article <1992Apr7.195807.17280@aplcen.apl.jhu.edu>, ddml@aplvm.jhuapl.edu (Dave Libershal) writes:
> We are using DEC's MAILBUS with Message Router in a VMS environment. We support	
> mail to/from many different computer systems but currently, only for users of 
> one of those systems. We want to provide hardcopy mail output for non-system 	
> users. I would appreciate feedback and comments from those of you who may have
> implemented a similar function.  		
> 
> The approach which we are taking will use reverse lookups in the DDS for all 
> staff who do not have computer access. That lookup will route their mail to a
> unique userid on our MAIL router machine. That user will be running a detached
> process which extracts the print mail message, parses it to locate the "true"
> intended recipient, does a lookup in the DDS to determine the recipient's 
> address and phone number, and then builds a header page with the addressing  
> info and prints the header and the message to a printer located in our mailroom.
> Mailroom staff will send the message to the designated recipient via our normal
> manual delivery system.
> 
> I am considering the use of a detached process that uses DCL commands. 
> Have any of you done anything like this? This is my first VMS project and I 
> appreciate any helpful advice. Are their similar alternatives you might be
> aware of? I was looking at ALL-IN-1 mail services support initially but we
> do not have that on the router machine and we need to get something going
> soon.
> 
In our case we took a slightly different approach.  We created services in
message router that address to Softswitch Central on our IBM mainframe.  By
attaching that users address to a specific form, both the IBM and our HP's know
to automatically print that mail.  Thus we don't need a generic user id, but we
can have everything be unique by user.  So, a DDS lookup on the user would
result in an address of user@print-service@SSW which softswitch central would
know to send to the correct form which prints.  We haven't even tried to
automate this process for VMS, but if we were to do so, we would address in a
similar fashion and use PMDF's DELIVER (or the PD version) to take the address
supplied by MR (not really ALL-IN-1 at this point) and have it automatically
print.  Thus no need for a "detached" process or any extra Daemon to sit around
waiting for things to happen.

So, where does the internals stuff come in?
-- 
   Don Roberts                   Internet:  don@beckman.com
   Beckman Instruments, Inc.     Phone:     714/961-3029
   2500 Harbor Bl. Mailstop X-12 FAX:       714/961-3351
   Fullerton, CA  92634          Disclaimer:  Blame me, not Beckman.
   Sometimes I feel like I'm the only one born without an instruction manual.
           - Ron Tye
From: "Hunter Goatley, WKU" <goathunter@WKUVX1.BITNET>
Newsgroups: vmsnet.internals
Subject: BLISS article available from WKUVX1
Date: Wed, 15 Apr 1992 13:50:10 CDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Have you ever wanted to learn more about the BLISS programming language?
The original article that introduced BLISS to the world appeared in the
December 1971 issue of _Communications of the ACM_.  As part of our DECUS
BLISS PSS, I TeX'ed up the article.  Our PSS was cancelled, but the article
(a PostScript version) has been made available from FILESERV@WKUVX1.BITNET.
To get it, send the following command in the body of a mail message to
FILESERV@WKUVX1.BITNET:

SEND BLISS-ARTICLE-PS

The article will be available from ftp.spc.edu by the morning of April 16.

Hunter
------
Hunter Goatley, VMS Systems Programmer, Western Kentucky University
goathunter@WKUVX1.BITNET, 502-745-5251
Newsgroups: vmsnet.internals
From: pensakmj@estslc.nohost.nodomain (Martin Pensak)
Subject: Re: VCRP
Reply-To: pensakmj@estslc.nohost.nodomain (Martin Pensak)
Organization: DuPont Engineering Physics Laboratory
Date: Tue, 14 Apr 1992 23:57:34 GMT


This may be entirely unrelated to your problem, but --

last time we saw our various non-paged pools being eaten alive,
and rapidly, it was shortly after we had upgraded from VPA
to using DEC-PS, DEC's new Performance Solution.  A good AUTOGEN
and a reboot made the problem go away, although we aren't sure why.

I"m pretty sure we were seeing VCRPs in the pool, and had equally little
idea what / why.

Otherwise, the next obvious question is what else has changed lately
on your systems ?  Any new software? New drivers?
--
From: GAVRON@VESTA.SUNQUEST.COM
Newsgroups: vmsnet.internals
Subject: FABs from FILEs
Date: 13 Apr 92 16:07:08 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

>>#include stdio
>>#include rab;
>>#include fab;
>>#include nam;
>>#define fcb_l_rab 0x0f4;    /* This offset might change depending on vms
>>                                version.  It works for 5.4. */
>>struct FAB *fabptr;
>>struct RAB *rabptr;
>>struct NAM *namptr;
>>FILE fp;
>>int *mp;
>>main()
>>{
>>int fn = 0;
>>fp = fopen("stuff.dat","w");
>>mp = fp;
>>rabptr = *mp + fcb_l_rab;
>>printf("RAB.BID = %x.RAB.BLN = %x. RAB.FAB = %x. \n",
>>       rabptr->rab$b_bid,rabptr->rab$b_bln,rabptr->rab$l_fab);
>>fabptr = rabptr->rab$l_fab;
>>printf("FAB.BID = %x.FAB.BLN = %x. FAB.NAM = %x. \n",
>>       fabptr->fab$b_bid,fabptr->fab$b_bln,fabptr->fab$l_nam);
>>namptr = fabptr->fab$l_nam;
>>printf("Per NAM block, file name string is %.*s. \n",
>>       namptr->nam$b_rsl,namptr->nam$l_rsa);
>>}
        Ehud

--
Ehud Gavron        (EG76)
gavron@vesta.sunquest.com
"The world bores you when you're cool."
From: MILLER@TGV.COM
Newsgroups: vmsnet.internals
Subject: Re: ALPHA MB instruction
Date: 15 Apr 92 00:10:55 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List


>Yeah, lots of detail on 4.11.3 :-)  It sounds like you're referring to using MB
>as illustrated in 5.6, but I was more interested in the discussion in 5.5.3 and
>5.5.4.  Perhaps I'm being fooled by this discussion of spin loops.  Wouldn't be
>the first time :-)

79 character lines are real annoying...

I *am* talking about 5.5.3 and 5.5.4.  The MB instructions don't really
have anything more to do with the "spin-lock" than the BR instructions
do, really. I think...

----------------------------------------------------------------------------
Bruce R'. Miller, MILLER@TGV.COM        (408) 427-4366  in Santa Cruz CA
        "And through the wire, we can talk..." - PG
From: HSIEH34@SNYBUFVA.BITNET
Newsgroups: vmsnet.internals
Subject: getch and c callable assembler routines
Date: 17 Apr 92 09:56:00 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Date sent: 17-APR-1992



I recently had the pleasure of finding the ftp site ftp.spc.edu where all
these neat little assembly language programs such as login.mar and the swim
program....

        I viewed a few of the replies to the macro32 mail serve and had a few
question..I figured out how to use getch in VAX C and once I found this forum..
I couldn't help but come up with a question on assembly (which I have learned
the basics to in these last few weeks while I had a chance to)

        I made a routine in macro to read a char with the sys$qio routines which
is similar to smg$read_keystroke... Now suppose I want to use that routine
in my c programs.. Does anyone have an example of how to call user-defined
c-callable routines.. and also how I could use it in dcl.. inquire does not
read extended key codes...

        Finally I read a reply here but I didn't see an answer to how to make
a lexical for example F$read_keystroke..
Thanks :)
-------------------------------------------------------------------------------
|Keith J. Bieniek               | | Bitnet: Bitnet%"hsieh34@snybufva.bitnet"  |
|Email: keith@toz.buffalo.ny.us | | Inet:   hsieh34@snybufva.cs.edu           |
|Phone: 716-895-3484            | | Phone:  716-895-3484                      |
-------------------------------------------------------------------------------
Newsgroups: vmsnet.internals
Subject: Re: Help getting image dumps?
From: mark@infocomm.com
Date: 11 Apr 92 07:51:27 PDT
Organization: INFO COMM - Computer Consulting, Redwood City, Ca

In article <9204071514.AA17947@ithaca.Eng.Sandy.Novell.COM>, <ed_heinrich@npd.novell.com> writes:
>         Years ago I worked for a company with sites throughout the world and
> we had the requirement to have a dump file to examine back in the development
> office.  The following are the extracted relevant pieces that I used in an
> exception handler to cause an image dump file.  It also has the feature of
> purging the dump file to prevent exhausting the customers disk space.
> 
> 
>         It has been a while since I looked into the conditions that allow/
> disallow RUN/DUMP from creating a dump file but I got around those checks
> by calling the image dump merge routine directly.  This approach allows a
> dump to be generated no matter what RUN command is used.
> 
>         After the exception handler had written out messages to a disk file
> and the system console, it would set the PHD$M_IMGDMP bit in the PHD and then
> call the EXE$IMGDMP_MERGE code to merge in the image dump facility and
> execute it.  This assumes that the code thread is executing in user mode and
> that the process has CMKRNL privileges.  (Actually the real version called a
> user-written service to set the PHD bit so that the process did not need
> CMKRNL privs).  This approach gets around the requirement that a process be
> RUN/DUMP.  It worked very well for us.

This stuff looked great, but I've noticed the following:

      - The CMKRNL priv really isn't needed since a user process can merely do
	a $ SET PROCESS/DUMP to turn on the PHD$M_IMGDMP bit without any extra
	privs.
      - The automatic purging of the old dump files is great!
      - The code (when executed from User Mode anyway), ONLY ends up producing
	a dump if the image that is being run is NOT installed with privs.

I remember something about a security hole related to ANAL/PROCESS_DUMP and
images installed with privs.  The first work around to this problem was to 
protect ANAL/PROCESS_DUMP (SYS$SYSTEM:ANALIMDMP.EXE) so users couldn't run it
(OR to NOT install it with privs), I don't remember the detail.  In any case it
seems that the eventual fix was to make sure that installed images NEVER have
process dumps taken, and hence avoid the problem entirely.

--
Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca
PHONE:	(415)369-9366	UUCP:  decwrl!infopiz!mark or uunet!lupine!infopiz!mark
DOMAIN:	mark@infocomm.com
From: dsroberts@beckman.com
Newsgroups: vmsnet.internals
Subject: RE: System service calls & access modes
Date: 8 Apr 92 08:20:23 PDT
Organization: Beckman Instruments

In article <1992Apr8.211413.1660@zl2tnm.gen.nz>, don@zl2tnm.gen.nz writes:
> I've attached my cleaned up (ie as *I* write this stuff) code, including
> sanity checks, to this message.  Since you can't really nest kernel 
> modes, I figured recursive calls shouldn't be allowed either.  If I 
> detect an out of sequence call, I just exit quietly.
> 
I think this (and Bruce's) is a nifty piece of code, and I'm happy to see it as
an instruction of approaches to things.  But I'm having a bit of difficulty
coming up with a concept of what you would use this sort of thing in.  could
someone post an example of a real use for this piece of code, where normal
CMKRNL calls would be less convenient?  Something more specific than the
calling sequence, that is. :-)

-- 
   Don Roberts                   Internet:  don@beckman.com
   Beckman Instruments, Inc.     Phone:     714/961-3029
   2500 Harbor Bl. Mailstop X-12 FAX:       714/961-3351
   Fullerton, CA  92634          Disclaimer:  Blame me, not Beckman.
   Sometimes I feel like I'm the only one born without an instruction manual.
           - Ron Tye
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: vmsnet.pdp-11,comp.sys.dec
Subject: Re: SCSI-controller/disk for the PDP-11/23+
Date: 13 Apr 92 22:24:50 GMT
Organization: St. Peter's College, US

In article <1992Apr13.180423.29110@mits.mdata.fi>, karttu@mits.mdata.fi (Antti Karttunen) writes:
> Currently I have the PDP-11/23+ with the four 10 MB RL02-drives and
> 2MB of RAM. It is running the RSX-11M version 4.? (or RSX-11M-PLUS 2.?).
> However, I would like to have something little more effective for the
> mass storage. So I'm thinking about purchasing the SCSI-controller
> for the beast. Some questions:
> 
> 1) Is it possible for the PDP-11/23-PLUS?

  Yes. A number of companies make Q-bus SCSI controllers. Some of the more
popular ones are Dilog (SQ700 series), Emulex (UC series) and CMD.

> 2) Are there any used ones (controllers) available in U.S.A?
>    In this part of Europe? Prices?

  Probably. I've seen them now and again, usually in comp.sys.dec or misc.
forsale.computers.

> 3) Hardest problem: The software. Is there any device drivers for SCSI
>    available in RSX-11M-(???) ? Do I have to do the SYSGEN to get the
>    system know the SCSI-disk? (I have _no_ sysgen packs! :-()
>    How hard it's to hack the OS to boot from the SCSI-disk, and not use
>    the RL02's at all?

  Nobody puts un-emulated SCSI on the Q-bus any more. The controllers you
will find today emulate one of the DEC device types, normally MSCP - the
DU device. This is because MSCP is self-sizing, while the older types needed
patches to reflect the actual size and geometry of your SCSI disk.

  As far as the boot goes, depending on the age of your quad-width 11/23 CPU,
you may or may not have DU bootstrap support. You could always order the DEC
kit KDF11-B3, which consists of two new ROMs to upgrade that board to a Micro-
PDP-11 with full bootstrap support for the newer devices. I think it costs
about US $100.

  I think you'll need to do some sort of configure/sysgen to get RSX to see
the new disks - but I'm not an RSX person.

	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