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

Info-Vax-REQUEST@KL.SRI.COM (Ramon Curiel) (05/18/87)

Info-Vax Digest          Monday, 18 May 1987       Volume 0 : Issue 25

Today's Topics:
  LANBridge behavior
  terminal emulator for hp-9000
  SWINGing on ...
  Re: <FF> when using control libraries (Info-Vax Digest V0 #19)
  Network partner exitting during long mail send, plus shutdown$time
  RE: Mail via DECnet
  possible solution to logical question
  Re: TI 2115 OMNILASER Laserprinter?
  Mailer Timeouts
  Public-domain tar(1) for VMS?
----------------------------------------------------------------------

Date: Fri, 15 May 87 09:40 EDT
From: William Thompson <WTHOMPSON@rcca.bbn.com>
Subject: LANBridge behavior


    I was wondering if anyone else in the community has observed the
    following behavior on the part of LANBridge 100's:  occasionally,
    LANBridges are observed to transmit a steady stream of 1's on the A
    port (the units in question accept transceiver cables on both ports),
    effectively disabling that side of the bridge.  The other port, and
    it's local traffic, continue to behave normally, but nothing may be
    passed to the rest of the world.

    The behavior does not follow the LANBridge unit, as several units have
    shown this pattern over time.

    Has anyone else experienced this phenomenon?

    .bill.

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

Date: Fri, 15 May 87 09:28:17 CDT
From: vtcf@ncsc.ARPA (Williams)
Subject: terminal emulator for hp-9000

Does anyone know of a terminal emulator for an HP-9000 computer? We have a
few of these floating around, and it would be nice to hook them up to our VAX.
VT100 and Tek 4010 emulation would be nice.

Thanks in advance
Tom Williams

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

Date: 15-MAY-1987 18:10:28
From: MACALLSTR%vax1.physics.oxford.ac.uk@Cs.Ucl.AC.UK
Subject: SWINGing on ...

I've just got round to installing SWING on our system. Many thanks to
 the original author and also to those who have ironed out the wrinkles.

The command procedures sent over the net work a treat - and the
 package does too!

I'd say it was invaluable for system managers and anyone else with
 complicated directory structures. Inexperienced users will also find
 it useful for coming to terms with directories - I know some users who
 are afraid to place files in subdirectories for fear of losing them!

I also applied the three fixes which came over the net and have made some
 ( very simple ) mods of my own to meet our specific requirements.

 (1) I increased the MAX_NODES and MAX_LINES parameters from 600/300 to
      6000/3000 to enable listing of disk structures with a large number
      of directories.

 (2) Mod to EXIT_SWING to print out a reminder of what the current default
      directory is on exit.

 (3) Changed the default 'Option' to be 'ON' so that the current default
      directory is always displayed on the second-top line. You can still
      switch it on and off with the Options command.

 (4) Mod to LOAD_NODES to cater for directory specs containing a ','
      e.g. [0,0] , [1,54], etc.

I'll post the code to the net if anyone's interested : the changes are quite
 small.


John

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

Date: 14 May 87 11:36:27 GMT
From: munnari!moncskermit!jam@seismo.css.gov  (John Mann)
Subject: Re: <FF> when using control libraries (Info-Vax Digest V0
         #19)

>"Andrew J. Grigor" <flash@brl-lvax.ARPA> wrote
> Earlier someone called the print symbiont brain dead since it insisted
> on sending a <FF> to the printer after configuring the printer using
> specified modules in the control library.  It is merely paranoid.  The
> print symbiont has no idea how the modules in the control library will
> affect the printer.  By performing a <FF> the printer is in a known
> state (upper left hand edge...whereever it may be).

> We have a QMS Lasergrafix with the QUIC command controller.
...
> I am currently living with the blank pages.  I can sleep at night since
> the extra scrap generated goes to the Boy Scout's paper drive and is not
> totally wasted.

        There is no need to live with these blank pages forever.
        Just apply this simple patch (:-) :

-------------------------- smbsrvshr.com ------------------
$ patch/jou smbsrvshr.exe
! Patch the File Flag routine to not supply a form feed. (null instead)
! VMS 4.4 fiche 369 K10, 371 H6
def file_flag=7c1
rep/i file_flag+90
' MOVB #0C,(R3)'
exit
' MOVB #0,(R3)'
exit
update
exit
-----------------------------------------------------------

        At Monash we have a QMS 800 (QUIC) printer driven by a font manager
print symbiont (TFMSMB) from Talaris.  The printer is located inside our
job reception area and runs at just under 1000 pages per day and so it is
important to have job flag pages but little wastage.  When it was first set up
we were spitting out a lot of blank paper, and now after a few iterations
on the problem we waste very few.  I think we get one blank page when the
queue gets started, and perhaps a blank page if you do a print/noflag.

        It was almost a year ago that I last touched this problem so I can't
remember all the details but here goes:

        I fiddled with TALDEVCTL.TLB (the device control library) a little bit
for local conditions but dont think't that decreased the number of blank
pages.  I changed QTEX (the QUIC TeX printer driver) for A4 size pages and to
omit the "^," (throw a page command) at the end of the job.  I also hacked the
plot packages (NCAR etc.) so that they produced as few blank pages as possible.

         The major problem is the number of FFs that the Print Symbiont wants to
generate itself.  I read the fiche in VMS V4.3 days and determined where
they all came from.  In the VMS V4.4 manuals starting at PSM-27 descriptions of
the input routines that generate FFs are referenced by PSM$K_FILE_FLAG,
PSM$K_FILE_SETUP_2, PSM$K_FILE_TRAILER, PSM$JOB_COMPLETION, PSM$K_JOB_FLAG,
PSM$K_JOB_SETUP, and PSM$K_JOB_TRAILER.  See page PSM-16 for the order in
which the PSM input routines will be called if required.  There is some
new_page code (in the formatter) that looks at the data stream and if it sees
a formfeed and if it thinks that the printer is already at line 1 column 1 then
it decides the FF is superflous and throws it away.  In our environment,
FORM_SETUP moved the virtual print position away from line 1 column 1, and so
the FF at the beginning of FILE_FLAG caused a page throw.  My solution
(the patch given above) excises the FF from the FILE_FLAG subroutine.
This solution did not require any changes to Talaris' TFMSMB.

        Most of our other printer symbionts print over a terminal network
and their queues are only started when they are not empty.  In this case our
output subroutine tricks the new_page, column 1, line 1 logic to avoid the
blank page when the queue is started.  Some of our other symbionts have had
their JOB_SETUP and JOB_COMPLETION routines replaced by the dummy:

--------------------- no_ff.for -----------------------------
        integer function no_ff (context, work_area, func, func_desc,
     1                          func_arg)
        implicit none
        integer context, work_area, func, func_desc, func_arg
        external psm$k_read, psm$_eof, psm$_funnotsup
        if (func.eq.%loc(psm$k_read)) then
            no_ff = %loc(psm$_eof)
        else
            no_ff = %loc(psm$_funnotsup)
        endif
        return
        end
------------------------------------------------------------

        I don't think the print symbiont is brain dead or paranoid.
I think the developers did make an improvement on the VMS V1/2/3 symbionts,
perhaps they got a bit too worn out to cater for all non-DEC printers.

        John Mann

PS. Anyone tried using the VMS include-a-file-here escape sequence in
    a device control library to include a setup module without changing the
    virtual print position?

--
---
John Mann, Computer Centre, Monash University, Victoria 3168, Australia
ACSnet: jam@moncskermit.oz      Phone: +61 3 565 4774
UUCP:   ...!{seismo,hplabs,mcvax,ukc,nttlab}!munnari!moncskermit.oz!jam
ARPA:   jam%moncskermit.oz@seismo.CSS.GOV
   "Any code from DEC with an IF statement in it is fair game for Patch"

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

Date: 15 May 87 15:24:00 EDT
From: "WILKINSON R.O." <sherman@nusc.arpa>
Reply-to: "WILKINSON R.O." <sherman@nusc.arpa>
Subject: Network partner exitting during long mail send, plus
         shutdown$time

> I keep doing this stupid thing:
>
>         MAIL> send/edit
>         TO:   node::user
>         SUBJ: Real long, important memo
>
> I then spend fifteen or twenty minutes composing this important memo
> in EDT and exit, expecting it to get sent.  Instead, I get informed
> that the partner has exited and the logical link is broken. And, of
> course, the temporary file is gone and there is no .JOU.
>
> Daniel P. B. Smith         ARPA: smith%eri.decnet@mghccc.harvard.edu

Actually, mail should keep its own temporary file (with no name no less!)
around, and so you should be able to do a SEND/LAST to somebody - perhaps to
yourself - so that you may forward it to its true addressee at a later date.
I've used this trick before (also useful if an addressee is over his diskquota
and so won't be able to receive a long memo - grrrr!).


As a side note, with all this talk about entering beeps into command procedures,
I was reminded of something that I've set up at several sights.  Once a shutdown
had been scheduled, the logical name SHUTDOWN$TIME is set to the absolute time
that the system is scheduled to shut down.  In our system-wide login procedure,
I do a

        $ shut = f$trnlnm("SHUTDOWN$TIME")
        $ if shut .nes. "" then -
          write sys$output beep, tab, "** Shutdown Scheduled for ", shut, " **"

It's sometimes nice for a user to know when she/he first logs in that the
system will be shutting down in N minutes.  This way, she/he might be able to
adjust her/his computing schedule accordingly.

                                                                      Bill.

+------------------------------------------------------------------------------+
| ARPANET:  sherman@nusc.arpa           USPS:  Bill Sherman                    |
| AT&T:     (203) 440-6210                     Naval Underwater Systems Center |
|                                              MIS/OA/WP Group, Code 334       |
|                                              Building 28, Room 200           |
|                                              New London, CT  06320           |
+------------------------------------------------------------------------------+
| "Age does not diminish the extreme disappointment of having a scoop of ice   |
|  cream fall from the cone."                                                  |
|                                                           - Jim Fiebig       |
+------------------------------------------------------------------------------+

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

Date: 15 May 87 12:33:00 PDT
From: "Oberman, Kevin" <oberman@lll-icdc.arpa>
Reply-to: "Oberman, Kevin" <oberman@lll-icdc.arpa>
Subject: RE: Mail via DECnet

>I keep doing this stupid thing:
>
>        MAIL> send/edit
>        TO:   node::user
>        SUBJ: Real long, important memo
>
>I then spend fifteen or twenty minutes composing this important memo in EDT and
>exit, expecting it to get sent.  Instead, I get informed that the partner has
>exited and the logical link is broken. And, of course, the temporary file is
>gone and there is no .JOU.
>
>Obviously there's some question as to whether it is I or VMS Mail who/which is
>brain-damaged. Still, I keep wondering whether this happens to other people and
>why the VMS manual doesn't warn you about it. And is there some obvious reason
>why MAIL doesn't just try to re-establish the logical link?

There IS a solution, though not ideal. It is the SEND/LAST command. If there
is a failure in the DECnet communication you can retransmit the message.
And if the link is really down and dead for a while, you may SEND/LAST to
yourself and then forward it to its `real' destination at a later time.
It's also nice when you realize someone else should also receive a copy.

                                        R. Kevin Oberman
                                        Lawrence Livermore National Laboratory
                                        arpa: oberman@lll-icdc.arpa
                                        (415) 422-6955

P.S. The copy of this message to info-vax was sent via SEND/LAST. I forgot
to put them on the first send.

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

Date: Fri, 15 May 87 14:53 EST
From: <HOGENCAM%WILLIAMS.BITNET@wiscvm.wisc.edu>
Subject: possible solution to logical question

johnc from ge asked how to make a logical for non-vms id's.  i have done this
for bitnet addresses in the following manner

     $    assign coms:mike.address mike

in the file coms:mike.address i placed mike's address

     bitnet%"mike@williama"

with an editor.
at the mail prompt i enter send, at the to: prompt i enter "@mike".  it works,
tho it clutters up a dir with small files.  i found that mail kept stripping
every combo of " and ' i came up with.

I modified this procedure by putting john's arpanet address in a file called
john.address, and in the file had his long address johnc%cad2.decnet@ge-crd.arpa
Then assigned the logical jd to a the john.address file.  Then in Gmail, at the
gto prompt, entered "@jd".  worked fine in test mode.  i'll try to send this
message to info-vax and johnc now.


angie hogencamp
user services
jesup hall
williams college
williamstown mass 01267
bitnet : hogencamp@williams
413-597-2089

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

Date: 15 May 87  3:22 -0800
From: Christos Zervos <christosz%ppc.ubc.cdn%ubc.csnet@RELAY.CS.NET>
Subject: Re: TI 2115 OMNILASER Laserprinter?

  We also got here recently a TI2115 postscript printer. The printer
printed just 300 pages and then ... QUIT PRINTING!  Blank pages started
coming out of the printer. We called the local TI service twice. We called
the engineering unit in Dallas, we called the factory in Temple, Texas, we
called the TI Hot line. We called AGAIN and AGAIN and AGAIN and AGAIN. No
hope for doing something to solve the problem.
  When the printer was printing the quality was very good though. From what
I found out it seems to be a bad design on the development drawer
manufactured by RICOH (the drawer holds the toner hopper and the OPC belt).
It is true that so far TI has made a lot of changes on the TI2115. They
had LOTS of problems (single pixel uniformity problems, postscript
controller problems, defective gears and lens inside the engine, firmware
problems and many many more ;  the upgrade kit that they are going to send
out is supposed to correct all the above).
 THE mystery of the story however is that the printer we got was one of
the re-engineered ones!  And there are units out there that presented the
same exactly problem as ours.  It is TRUE that the OPC belt lasts less than
what it was rated for. Our 1st toner cartridge (rated for 3000 pages)
lasted for ... (I will not say the number because you might be disapponted!)
 My understanding is that they will either STOP the production on these
units at all, OR they will ship out every now and then little ... patches
to temporarily fix every problem that comes out!
  We are generally unhappy so far with all these problems and we told TI,
BUT from the conversations I had with all the TI people I found out that
they DO STAND BEHIND THEIR PRODUCTS and they assured me that they will
fix all the problems.  I do not know what to say!
                                                                CCZ

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

Date: Fri, 15 May 87 13:20:36 PDT
From: carl@CitHex.Caltech.Edu
Subject: Mailer Timeouts

I've also had a problem similar to this one.  It appears that the mailer on the
other end times out somehow, and the link is terminated.  The VAX mailer sets
up connections to all recipients before accepting the input message, giving you
a chance to quit if not all recipients are reachable.  It doesn't seem to
consider the possibility that reachability of any recipients will change before
the message is sent.

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

Date: 15 May 87 18:47:53 GMT
From: columbia!cheshire.columbia.edu!leland@seismo.css.gov  (Lee
      Woodbury)
Subject: Public-domain tar(1) for VMS?

A friend without access to the USENET asks:

Does anyone know of a fully-implemented UNIX tar (tape archiver) which
runs under VMS and is public domain?  If so, please respond by
electronic mail to this account.

Lee Woodbury
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
ARPANET (or Internet):  leland@CS.COLUMBIA.EDU
USENET:                 ...!seismo!columbia!cs!leland
BITNET:                 leland%CS.COLUMBIA.EDU@WISCVM
USmail:                 457 Computer Science
                        Columbia University
                        New York, NY  10027
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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

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