[comp.os.vms] Info-Vax Digest V0 #12

Info-Vax-REQUEST@KL.SRI.COM.UUCP (05/08/87)

Info-Vax Digest          Thursday, 7 May 1987      Volume 0 : Issue 12

Today's Topics:
  DECnet executor buffer size
  JClock for VMS
  Clearing the screen
  DEC multicast addresses
  Q-bus versus Unibus
  Wanted:  P/D tar tape reader for VMS
  Problems with two UDA controllers in a MicroVAX
  Re: Need faster VMS spawn
  Command line redirection for VAX C
  tape conversion program wanted
------------------------------

Date: Tue,  5 May 87 18:07 EDT
From: AB Stine <ABSTINE%CLVMS.BITNET@wiscvm.wisc.edu>
Subject: DECnet executor buffer size

Is there any advantage to setting the executor buffer size above 576?
The SYSGEN manual recommends that LRPSIZE be equal to the executor
buffer size for performance reasons, which i know, but what about
ethernet lines? they are set up at a buffer size of 1498. The books
seem to indicate that line buffers come out of LRP  as well as serving
for NSP msgs. Just wondering...

art stine
systems programmer
clarkson u

------------------------------

Date: Tue, 5 May 87 17:18 EDT
From: MKrieg%UMASS.BITNET@wiscvm.wisc.edu
Subject: JClock for VMS

$!    JCLOCK ARCHIVE FILE.
$!
$!      CREATE A NEW, EMPTY SUBDIRECTORY, "SET DEFAULT" TO IT,
$!    PUT THIS FILE IN THE NEW SUBDIRECTORY AS JCLOCK.ARC AND THEN @JCLOCK.ARC
$!
$!
$!    SUPER-ULTRA-GIVE-AWAY-WARE PROGRAM...COPY AND DISTRIBUTE AT RANDOM.
$!
$!
$!                    MARK KRIEGSMAN, AUTHOR 87-05-05
$ write sys$output "This takes a minute; please wait..."
$ create jclock.com
$ deck/dollars="Bleah!Bleah!"
$ set nocontrol=(T,Y)
$ startup:= $JCLOCK$BASE:jclock.exe
$ startup 'p1
Bleah!Bleah!
$ create jclock.for
$ deck/dollars="Zap!Ouch!"
!=============================================================================!
!                                          !
!     J C L O C K - By Mark Kriegsman, around 2-87, at Hampshire College      !
!                   Inspired by JCLOCK for the Macintosh (and God knows       !
!                   where that came from)                      !
!                                          !
!     WHAT IT DOES is stick the current time (12 hour format) in the upper    !
!                  right hand corner of the screen, and optionally ring an    !
!                  Alarm (and blink) at a preset time.                  !
!                                          !
!     REQUIRES that users who wish to run it have at least one "free"         !
!           subprocess slot (try it, you'll get a message if you don't)    !
!     REQUIRES that it be run on a VT100 (or better) work-alike terminal.     !
!              The cursor codes are hard wired in to the program, and         !
!              not all terminals support "SAVE_CURSOR_POSITION" and the       !
!              corresponding RESTORE.                          !
!                                          !
!     BAD THINGS about it include: editing gets funny looking sometimes,      !
!                DCL gets spare CR/LF pairs thrown in sometimes.  None        !
!                of this is fatal, or even Very Bad, but some is annoying.    !
!                                          !
!     ODD THINGS about it include: mainly that if you start JC and then       !
!                SET HOST to a different node, the JC output follows you.     !
!                                          !
!     INSTALLATION NOTE: many users can be running JC at once (each as their  !
!                        own subprocess), so it is recommended that someone   !
!                        put the files (JCLOCK.COM, JCLOCK.INIT, JCLOCK.EXE)  !
!                        a World:Read+Execute subdirectory, and that          !
!                        everyone run it from there.  We do this, and         !
!                        everybody gets to use it without having to HAVE it.  !
!                                          !
!     RESOURCE DRAIN is really, really small.  The subprocess HIBERnates for  !
!                    most of the time, and even the IO is non-single-char.    !
!                    Just for kicks, try using MON PROC/TOPCPU and watching   !
!                    how little time it uses.                                 !
!                                          !
!     AUTHOR, ADDRESS: Mark Kriegsman                          !
!                      Hampshire College                                      !
!                      Amherst, MA  01002                                     !
!                           -or-                          !
!                      MKrieg@UMass.BITNET                      !
!                                          !
!=============================================================================!


        REAL SECS,ONESEC
    INTEGER HOUR,MINUTE,SECOND,ALLEN,MAZBUZ,BUZYET
    CHARACTER*1 ESC,BEEP
    CHARACTER*2 SAVE,REST,POST,TWODIG
    CHARACTER*4 NORMAL
    CHARACTER*7 HOME
    CHARACTER*8 FLASH
    CHARACTER*9 PRE
    CHARACTER*10 TIME
    CHARACTER*21 BIGGIE
    CHARACTER*33 BIGGER
    CHARACTER*10 ALTIME

    STATUS = LIB$GET_FOREIGN(ALTIME,,ALLEN)        ! See if we got an
    IF (ALLEN .EQ. 0) ALTIME = 'No_Alarm'        ! Alarm request

    BEEP = CHAR(7)                ! just to be clear:
    ESC = CHAR(27)                ! these codes work on
        SAVE = ESC // '7'            ! VT100s and "better"
        REST = ESC // '8'            ! terminals, perhaps ONLY.
        HOME = ESC // '[0;70H'
    FLASH = ESC // '[5m' // ESC // '[1m'
    NORMAL = ESC // '[0m'
    PRE = SAVE // HOME
    POST = REST
    ONESEC = 1.0                ! how often to update.
    MAXBUZ = 3
    BUZYET = 0

1    SECS = SECNDS(0.0)            ! What time is it?
    ISEX = IFIX(SECS)            ! in seconds.

    HOUR = ISEX / 3600            ! convert to HMS
    IF (HOUR .GE. 12) HOUR = HOUR - 12
    IF (HOUR .EQ. 0) HOUR = 12
    ISEX = MOD(ISEX,3600)
    MINUTE = ISEX / 60
    SECOND = MOD(ISEX,60)            ! now to HH:MM:SS

    TIME = ' ' // TWODIG(HOUR) // ':' // TWODIG(MINUTE) // ':'
    1      // TWODIG(SECOND) // ' '

        BIGGIE = PRE // TIME // POST        ! build string to send
    IF (TIME(2:9) .GE. ALTIME(1:8)) THEN
        BIGGER = FLASH // BIGGIE // NORMAL
        WRITE (*,102) BIGGER
        IF (BUZYET .LT. MAXBUZ) THEN
            WRITE(*,103) BEEP
            BUZYET = BUZYET + 1
        END IF
    ELSE
            WRITE (*,101) BIGGIE
    END IF

    STATUS = LIB$WAIT(ONESEC)        ! Wait for update
    IF (.TRUE.) GOTO 1            ! most of the time, eh?

    STOP

101     FORMAT('+',$,21A)            ! Watch string length!!
102     FORMAT('+',$,33A)
103    FORMAT('+',$,1A)
    END

c-------------------------------------------------------------------

    CHARACTER FUNCTION TWODIG*2(INTGR)

c    Takes as input an integer and returns a two-character string.

    INTEGER INTGR,LD,HD

    HD = INTGR / 10
    LD = INTGR - (HD*10)

     TWODIG = CHAR( HD +48) // CHAR( LD +48)

    RETURN
    END
Zap!Ouch!
$ create jclock.init
$ deck/dollars="gurglepop"
$ verify = f$verify(0)
$ normal1 = %x10000001
$ normal2 = %x00030001
$ message = f$environment("message")
$ set message/noid/noseverity/nofacility/notext
$ if p1 .eqs. "SHOW" then goto SHOWJCLOCK
$ if f$getdvi(f$trnlnm("tt"),"tt_ansicrt") .eqs. "FALSE" then goto NOTANSICRT
$ tries = 0
$ me = f$getjpi("","MASTER_PID")
$ !me = f$trnlnm("tt") - "TA" - ":"
$ TryStop:
$ on error then goto TryNewTT
$ stop "''me'_JClock"
$ if $status .eq. normal1 .or. $status .eq. normal2 then goto Stopped
$ write sys$output "Starting JClock"
$ altim = "XX:XX:XX"
$ if p1 .eqs. "" then goto NoAlarm
$ altim = f$cvtime(p1,,"hour") + ":" + f$cvtime(p1,,"minute") + ":" + f$cvtime(p
$ NoAlarm:
$ on error then goto NoSpawn
$ spawn/now/nonoti/out=tt:/proc="''me'_JClock" @JCLOCK$BASE:jclock.com 'altim
$ goto Done
$ TryNewTT:
$ if tries .eq. 2 then goto BigProblem
$ tries = tries +  1
$ me = "''me'" + "$"
$ goto TryStop
$ BigProblem:
$ write sys$output "Got a problem too big to fix, can't run JClock."
$ goto Done
$ ShowJClock:
$ scan/sub/nohead/trail/image="JCLOCK"
$ goto Done
$ NotAnsiCrt:
$ write sys$output "Terminal can't support JClock!"
$ if JCLOCK$TOLDYASO .eq. 1 then goto Done
$ JCLOCK$TOLDYASO == 1
$ write sys$output "Try SET TERM/INQ, or SET TERM/VT100."
$ goto Done
$ NoSpawn:
$ write sys$output "Can't spawn JClock subprocess!"
$ Stopped:
$ write sys$output "JClock Stopped"
$ Done:
$ set message'message
$ verify = f$verify(verify)
gurglepop
$ create jclock.help
$ deck/dollars="redbutton"


This is the subdirectory that contains all the parts and batteries for
using the JClock program (so called after the MacProgram of the same name).

JClock puts the current time in the upper right hand corner of any
VT100 (or better) terminal, and keeps it re-paints it every second.

To use it, use

     $ DEFINE/NOLOG JCLOCK$BASE $$$MAGIC$$$
     $ JC*LOCK :== @JCLOCK$BASE:JCLOCK.INIT

to set the command to access it.

Then, use JC to "install" JClock, and JC again to "remove" it.  It conflicts
with a few things, but not PHONE, MAIL, <DCL>, or most anything else.

You can also use JC 4:30 (or something) to set an "alarm" for 4:30.  Note that
1) this can be turned off by "removing" the ringing JCLOCK, and 2) it
only uses 12-hour time...not 24-hour.


redbutton
$ create $$$read.me
$ deck/dollars="bonanza"


No, on second thought don't read me, read JCLOCK.HELP.

Sorry for the difficulty.

bonanza
$ fortran jclock
$ link jclock
$ delete jclock.obj;*
$ set protection=(s:rwed,o:rwed,w:e) jclock.*
$ set protection=(w:re) jclock.for,jclock.help
$ here = f$enviro("default")
$ define/nolog JCLOCK$BASE 'here
$ open/write out jclock.temp
$ write out "$ edit jclock.help"
$ write out "subs/$$$MAGIC$$$/''here'/1:end/notype"
$ write out "exit"
$ close out
$ @jclock.temp/out=nl:
$ purge jclock.help
$ delete jclock.temp;*
$ write sys$output "ok, everything's unpacked."
$ write sys$output "You can delete JC.ARC now, but I'm not going to in case you
$ write sys$output "A) want to pass it along to someone else, or B) need to re-r
$ write sys$output "Execute the JCLOCK.INIT file to start or stop the program."
$ write sys$output "Use the command JC to test JClock now.  (and to stop it, too
$ write sys$output "(Hit a few <RETURN>s after starting it.)
$ esc[0,8]=27
$ write sys$output "''esc'#3''esc'[1m''esc'[7mAND FOR GOD'S SAKE READ THE HELP."
$ write sys$output "''esc'#4AND FOR GOD'S SAKE READ THE HELP.''esc'[0m"

------------------------------

Date: Tue, 5 May 87 19:55 EDT
From: Jim Murawski <R021JM9W@CMCCVB>
Subject: Clearing the screen


        The method that I use to clear the screen in DCL is via
        a symbol definition in my Login.Com,

        $ Bl*ank :== Type /Page NL:
                                        -Jim Murawski
                                        -Carnegie Mellon Computing Services
                                        -Pittsburgh, PA
        Disclaimer:  Any opinions contained in the above message do not
                     necessarily reflect the views of my employer,
                     Carnegie Mellon.

------------------------------

Date: Tue, 05 May 87 20:08:03 EDT
From: Pat Barron <pdb@SEI.CMU.EDU>
Subject: DEC multicast addresses

Does anyone have a list of the multicast addresses the various DEC Ethernet
devices use (like the MOP remote boot request address, etc.)?

--Pat.

------------------------------

Date: Tue, 5 May 87 15:52:20 EST
From: LES@vaxi.UWO.CDN
Subject: Q-bus versus Unibus

 We want to take a number of our word processing users off of a VAX
11/785 and put them on a MicroVAX II. The MicroVAX will eventually
support 16 or more interactive processes, using EVE and WordPerfect,
and about a half dozen serial printers. User will communicate with
the MicroVAX via DHV11s at speed of up to 9600bps. Some interactive
communications via DECnet will also occur. The six of so printers
will operate at up to 19.2Kbps. The MicroVAX will also be connected
to our LAN via DECnet/Ethernet. The MicroVAX will have 13MB of memory,
3 DHV11s for asynch communications, a third party disk drive such as a
Fujitsu Eagle or CDC drive and a third party disk controller. The
system also has a TK50 for backup and a RD53/RQDX3.

 Questions: - Will the MicroVAX handle 16 wordprocessing users, DECnet and
              the six printers? (Some RUNOFF and TEK processing may
              also be performed but we could restrict this to BATCH
              usage only and put a JOB_LIMIT on the queue).

            - What's the I/O rate of a Unibus versus the Q32 bus?

            - Would the RD53/RQDX3 be useful after we install the much
              bigger and faster third party disk (i.e. for paging,
              swapping, system disk, etc.) or should we move everything
              to the larger disk?

            - What bottlenecks or other problems should I watch out
              for?

 Any information and personal experiences with a similiar environment
would be appreciated.

 Les Flodrowski
 Assistant Director (Systems and Applications)
 Social Science Computing Laboratory
 University of Western Ontario

 E-mail address: LES@UWOVAX.BITNET

------------------------------

Date: 5 May 87 21:53:51 GMT
From: sundc!hadron!klr@seismo.css.gov  (Kurt L. Reisler)
Subject: Wanted:  P/D tar tape reader for VMS

I am trying to locate a VMS utility that would permit a UNIX tar
tape to be read.  I am aware that the tar utility is a part of
the DECShell product, but the individual who needs the utility
does not have the funds available to purchase the DECShell.

If you have any knowledge of such a beast, please get in touch
with me directly (phone or E-mail) as I do not regularly read
this news group.

Thanks in advance

 Kurt Reisler (703) 359-6100
 ============================================================================
 UNISIG Chairman, DECUS US Chapter                       | Hadron, Inc.
 ..{seismo|sundc|rlgvax|dtix|decuac}!hadron!klr          | 9990 Lee Highway
 Sysop, Fido 109/74  The Bear's Den   (703) 671-0598     | Suite 481
 Sysop, Fido 109/483 The Pot of Gold  (703) 359-6549     | Fairfax, VA 22030
 ============================================================================

------------------------------

Date: Tue, 5 May 87 23:41:53 EDT
From: Jeffrey C Honig <jch@omnigate.clarkson.edu>
Subject: Problems with two UDA controllers in a MicroVAX


I just purchased a Systems Industries QDA4EC/4382 combination.  The
controller emulates a UDA/KDA50.  I'm installing it on a MicroVAX-II that
already has an RQDX3/RD54 combination running BSD 4.3 Unix (Mt Xinu's
43+nfs).

I generated a system to support the current rqdx3/rd54 disk AND the new
controller/disk.  The new disk is not yet installed but I booted anyway
to check the configuration. I was very surprized to watch it configure
uda0 and uda1 at the same address (172150). I wasn't that surprized to see
the system lock up after that point though.

After rebooting my old vmunix I looked at the uda driver code.  It has
a section of conditional code delimited by VAX630 (i.e. MicroVAX) that
checks for (cpu == VAX_630) and assumes that there is one controller at
172150.  Normally this code would init the controller at the gened in
address and wait for it to initialize.

Why is this code there?  Is it because someone assumed that the uVAX
will only ever have one controller, because of a Q-BUS limitation, or
because the uda controllers used in development of the MicroVAX (RQDXn)
support don't respond the same as a UDA50?

If it is not a limitation of the Q-BUS, but of one of the DEC
controllers I belive I could modify the code to assume that a
controller at 772150 is a dumb controller and controllers at other
addresses respond the same as a UDA50.  If it is a limitation of the
RQDX1 or 2 I can take the code out or add conditional compilation if an
RQDX1/2 is present.

Thanks

Jeff

----- End of forwarded messages

------------------------------

Date: 5 May 87 14:04:13 GMT
From: tedcrane@tcgould.tn.cornell.edu  (Ted Crane)
Subject: Re: Need faster VMS spawn

In article <633@cognos.UUCP> jimp@cognos.UUCP (Jim Patterson) writes:
>I'm replying to your posting just to correct some apparent misunderstandings
>about a few of the VMS services.
>
>>You will have to look at the System Services manual to find out what it's
>>called, but I know that there is also a "exec"-like routine that overlays all
>>or part of your address space with a new program image.
>
>You won't find this in the system services manual.  The routine you're
>referring to is the image activator, and it's used by DCL to merge a user
>program or image into the process address space as part of a RUN command.

Jim's right, there is an undocumented system service which interfaces to the
image activator.  There is also a Run Time Library routine called

        LIB$FIND_IMAGE_SYMBOL

which presents a limited interface to the image activator.  It will locate
an image on disk, map it into your address space, and return to the caller
the value of a global symbol from that image.  Usually, that value is the
address of a routine entry mask, and the caller can then call the routine.
If you call LIB$FIND_IMAGE_SYMBOL again (with the same image name), it is
smart enough not to map the image again--it just returns the global symbol value
from the existing image.

This technique can be used to some advantage, like not including whole portions
of your program unless they are really going to be used (example: ANAL/ERRLOG
is divided into many such images, and are bound up at run time).  Unlike
sharable images, if you aren't going to call routines in the image, the image
need not even exist on disk!

One catch: the errors returned by LIB$FIND_IMAGE_SYMBOL are sometimes less
than helpful.  For example, something like "invalid key in library" (a
librarian message) when you look for a symbol that isn't in the image!

------------------------------

Date: Wed, 6 May 87 09:41 EST
From: "GLENN EVERHART, 609 486 6328"
      <EVERHART%ARISIA%rca.com@RELAY.CS.NET>
Subject: Command line redirection for VAX C

The DECUS C kit (recently available on fall '85 RSX SIG tapes
from DECUS) contains a VAX native mode C library which has
the necessary tools to let VAX C do redirection. You just call
the getredirection() function to do it all... look in the
[.tools] directory ([5,something]) for examples. Why? Martin
Minow, at DEC, worked on DECUS C in the past and now works a lot
with VAX11 C. All the tools in that kit run native mode as well as
compat mode, and there are lots of them. The fall '85 RSX SIG tape
has other stuff of interest to VMS users (as do basically all the
RSX SIG tapes) and the recent ones are all available from the DECUS
library in both BRU format (readable on vax with vax/rsx) and in
VMS Backup format.
        Call the library and have fun... there are LOTS of nifty
little C utilities (and some big ones) in the kit. (Focal in C anyone?)
        Glenn Everhart

------------------------------

Date: 5 May 87 12:15:05 GMT
From: hao!noao!hsi!tankus@ames.arpa  (Ed Tankus)
Subject: tape conversion program wanted

I'm not sure this request belongs here but I thought I would give it a try ...

I am looking for a tape conversion program that will allow us to read in a
VMS backup tape written under VMS 4.2(?) on a VAX 11/780 on to a VAX 11/785
under 4.3BSD.

Any help or info would be appreciated! I'll summarize if there is enough
interest.

Note: this is a one-shot deal so a commercial program is out.

Cheers!

-- Ed.

Net  :  {noao!ihnp4!yale!}!hsi!tankus
Snail:  Health Systems Int'l, 100 Broadway, New Haven, CT 06511
Bell :  (203) 562-2101

------------------------------

End of Info-Vax Digest
**********************