Newsgroups: vmsnet.decus.journal
Subject: DECUServe Journal, January 1993
From: FREY@Eisner.DECUS.Org
Date: 5 Jan 93 21:50:28 -0500
Organization: DECUS

                            The DECUServe Journal
                            =====================
                                January 1993


    Hello!  I'm glad to present the first Internet issue of the DECUServe
Journal.  This issue is jam-packed with technical information on everything
from Datatrieve to C to VMS to DECstations.  I hope that you find this issue
of the Journal interesting and helpful.

Sharon Frey
frey@eisner.decus.org


                              Table of Contents
                              -----------------

    Contents and Credits ........................................  1
    Technical Information ....................................... 82
    Articles
       DTR Wizard Needed: Join Counting the MANY Relation .......  2
       Document Quotas ..........................................  3
       TK50Z-FA => TK50Z-GA .....................................  5
       How does one attach an LP25 to a VAX 4000? ...............  7
       Macintosh and PC share Files via Pathworks/VAX? .......... 10
       Decrease pipeline quota for PC performance? .............. 15
       Communications wiring for a new house? ................... 16
       C Pros & Cons ............................................ 23
       Needed - REGIS-capable terminal emulator ................. 35
       Can process use 2 or more pagefiles? ..................... 39
       V5 performance slowdown .................................. 42
       SYS$SETDDIR system service problem? ...................... 44
       How are quotas for STARTUP set? .......................... 46
       Can you put OPCOM on a DECTERM/Noprocess? ................ 49
       Automatic Menu Startup ................................... 51
       Collected Notes on VMS 5.5 ............................... 57
       Control over scrolling speed in DECterm? ................. 61


Editorial Staff
---------------
                  Editor:    Sharon Frey  (vmsnet.decus.journal moderator)
        Assistant Editor:    Bruce Bowler
    Contributing Editors:    Alan Bruns
                             Pierre Hahn
                             Jack Harvey
                             Larry Kilgallen
                             Jeff Killeen
                             Marc Kozam
                             Don Roberts

The DECUServe Journal             January, 1993                       Page   2


             DTR Wizard Needed: Join Counting the MANY Relation
             --------------------------------------------------

        This is an extract of the DECUServe 4GLS_AND_QUERY_TOOLS 
        conference topic 164.  The discussion took place on 
        September 1, 1992.  This article was submitted for 
        publication by Jeff Killeen, DECUServe Contributing Editor.
        Ed.

By Linwood Ferguson, Damon Brownd


(Ferguson)
----------
    There is probably some simple answer to this, but we know enough Datatrieve 
to be dangerous only:
    I have two files, X and Y.  For each record in X there are many records in 
Y, related by field A.
    I need to form a collection (in order to report) that includes the records 
in X (or certain fields) and the COUNT of the records in Y related to them.  
Sort of:
    
FIND X REDUCED TO X_KEY, COUNT OF Y WHERE X.A = Y.A
    
    Now this actually runs (well, with the right field, tables, etc.) but seems 
to ignore the COUNT part.
    This is easy in SQL, but these are RMS files.  I know I can also CROSS 
these and use SUM, but I see no way to SUM to a collection.  The best I can 
think of is CROSS them and then in the report use RUNNING COUNT or something, 
but I was looking to be a bit more elegant.


(Brownd:  My favorite solution)
-------------------------------
    Try this:
    
DTR> DECLARE Y_COUNT COMPUTED BY COUNT OF Y WITH Y.A = X.A.
DTR> FIND X REDUCED TO X_KEY
DTR> PRINT X_KEY, Y_COUNT OF CURRENT
    
    I try to avoid using CROSS because it will completely drop a record from 
domain X if there are no matching records in domain Y.


(Ferguson:  Thank you -- DECUServe does it again!)
--------------------------------------------------
    Neat.
    Sure not obvious to me how that works syntactically, but it works.  In my 
case for a collection I used:
    
FIND X REDUCED TO X_KEY, Y_COUNT OF CURRENT
REPORT CURRENT ...

The DECUServe Journal             January, 1993                       Page   3


                                Document Quotas
                                ---------------

        This article is an extract of the DECUServe All-In-1
        conference topic 396.  This discussion occurred between
        August 8, 1990 and February 17, 1991.  This article was
        submitted for publication by Don Roberts, DECUServe 
        Contributing Editor.  Ed.

By David Butterwort, Don Plorde, Chris Simon, Mark Hyde, Edward Hald, Les Paul,
Bruce Burson


(Butterwort)
------------
    I've been playing with enforcing document quotas and something seems to be 
missing.  Sure enough, when I run the CDQ housekeeping utility with my user's 
"Enforce Quota?" flag set to yes, anyone who has gone over their magic number 
gets locked into OVERQUOTA.
    But even if they delete messages, empty their wastebaskets and re-count 
their documents, up comes OVERQUOTA again when they log in the next time.  
    I have noticed that an entry is being placed in the "Document Count" field 
of their user profile which matches the total number of filed documents 
*before* they D, EW and RC.  Of course I can blank it out for them and things 
are then OK, but should I have to?
    Sorry if this has been asked before (SHOW KEYWORD/FULL came up empty).


(Plorde:  That's a known bug)
-----------------------------
    This is a known "bug".  We don't use the document quotas (the bug was one 
of the reasons).  I believe the workaround is that you have to run the 
maintenance routine again to get the "flag" cleared that allows the user to 
escape the OVERQUOTA form.  Not a quick solution by any means.
    I don't know if this one has been fixed in v2.4 or not.  I'm not holding 
my breath on 2.4 or I'll be long dead for doing so.  We will likely update to 
v2.4 next century :-(


(Simon:  Pointer to 207)
------------------------
    See topic 207 for document quota info.  The short answer is yes, it's a bug 
in 2.3.  Don't know yet whether it's fixed in 2.4.


(Hyde:  should be fixed)
------------------------
    I've not tested/witnessed it personally, but the word here in the CSC is 
that it is fixed in V2.4.



The DECUServe Journal             January, 1993                       Page   4


(Hald:  Check on 2.4 fix)
-------------------------
    I had the same problem when we first went to 2.3 last summer. I tried to 
write some code which would modify the profile quota fields when the user ran 
the recount option on the OVERQUOTA form but ran into a dead end. I could get 
it to work from a priviledged account but got an access violation on 
profile.dat when I ran it from a normal user account.  Due to lack of time I 
never tried to follow up on finding a fix.
    I just finished installing 2.4 on a test system last week and have not had 
a chance to see if this problem has been fixed. I will be doing some testing 
this week and will post any findings.
    I hope this has been fixed because we are desperately trying to find a
painless (from the system manager standpoint) way of enforcing quotas.


(Simon:  2.4 document quotas okay)
----------------------------------
    I apologize for not getting back to this thread with an answer sooner,
but...
    Version 2.4 DOES do the recount documents correctly (i.e. writes the new 
document count to the user's profile for him).


(Paul:  Not counting . . .)
---------------------------
    I have different problem. When I run the CDQ housekeeping procedure,
starting at a certain record, all document counts are recorded as "No Document 
Count Made". Atlanta CSC has been unable to help.  Any ideas?


(Burson:  Check CHANNELCNT (and reboot if necessary))
-----------------------------------------------------
    Try upping SYSGEN parameter CHANNELCNT to be at least 20 more than the 
number of entries in PROFILE.DAT.  There is a DSIN article describing this as 
causing errors with both CDQ and PT procedures. They say the following errors 
may be seen in the log file, but I've never seen them in the log.  If you run 
QUOTA.EXE from the ALL-IN-1 subprocess, you'll see the errors then.   

  Error  162  at line  310    ?Cannot open file
  %DEBUGBOOT-W-CHN, assign channel system service request failed
  %BAS-F-ERRTRANEE, ERROR trap needs RESUME
  -BAS-I-FROLINOEG, from line 510 in error handler at 510 in module DOCDB_COUNT
  -BAS-I-FROLINMOD, from line 1 in module QUOTA
  %BAS-E-FATSYSIO_, Fatal system I/O failure
  -BAS-I-ON_CHAFIL, on channel 0 for file SYS$OUTPUT:.; at user PC 000355E9
  -RMS-F-CHN, assign channel system service request failed
  -SYSTEM-F-NOIOCHAN, no I/O channel available"


(Paul:  You got the right one, BABY!)
-------------------------------------
    YEP, got that error message. Will try your suggestion. THANKS!

The DECUServe Journal             January, 1993                       Page   5


                             TK50Z-FA => TK50Z-GA
                             --------------------

        This article is an extract of the DECUServe Hardware_Help
        conference topic 1226.  This discussion occurred between
        August 7, 1992 and September 21, 1992.  This article was
        submitted for publication by Jeff Killeen, DECUServe 
	Contributing Editor.  Ed.

By Bruce Dow, Brian Schenkenberger


(Dow)
-----
    There is a FCO to upgrade a TK50Z-FA to a -GA (so it can be used on a
VS4000/VLC and other SCSI devices).  Will the BC19J cable still work?


(Schenkenberger:  FCO ye. real need no?)
----------------------------------------
    Yes there is or Was...
    I have a TK50Z-FA which I have modified to a pseudo TK50Z-GA and it works
file on 3100.  Despite what others may have to say about its no implementing
full SCSI.

    If you want to know how its quite simple. 

    1) open the box.

    2) there is a board on the top of the drive mechanics held by four plastic
standoffs.  Carefully pull back the retaining tabs and free the board.  You 
may wish to remove the ribbon cable to make access easier.

    3) you will find 3 reddish/orange resistor packs (with 11 leads) in sockets.
These are the SCSI terminators. The FA was terminated internally.  Carefully 
pull them from the socket (as you may want to  make your box an FA again and 
its harder than %&!! to find the same resistors if you break them)

    4) in the corner of the board are a set of 5 shorting jumpers.  The first 
three (from back of board) define the scsi address.  A TK50Z-FA is addressed as 
SCSI Address 1.   The addressing is a binary count.  1 is represented by 
REMOVAL of a jumper  a 0 is repersented by INSERTING the Jumper.  Your 
TK50Z-FA should have the first removed and the next two inserted.  (I have 
added a short ribbon cable to a dip switch epoxied on the rear of my box for 
ease of changing the SCSI address.

    5)  You need a terminator on the machine now since you will have pulled the
internal terminator.

    6)  the other two of 5 jumpers are for test/troubleshooting functions.

    I have had mine working on 3100 VAXstations of several flavors, and other 
3100 VAXes up thru and including a 3100m80 VAX.  I don't see why the same
thing shouldn't work on the 4000.


The DECUServe Journal             January, 1993                       Page   6


(Schenkenberger:  I'm using the old cable!!)
--------------------------------------------
     BTW,  I still using the same cable.  Off the top of my head I'm not sure
of the number BC19J.  If that's the cable for connecting the TK50Z-FA to a 
VAX/VAXstation 2000 then it should still work.

(Dow:  Need FCO number)
-----------------------
    Does anyone know the FCO number for the -FA => -GA change?  The FS rep
hasn't found it yet.


(Schenkenberger:  Checked BC19J is OK)
--------------------------------------
    In reference to [my previous reply]:
    I just got home and looked at my cable.  It IS a BC19J-06.  So to answer
your question, YES.  You can still use your BC19J.
    Also, think you should consider the information in [the first reply].  
It will save a lot of $$$ and time.  In fact, you can use the TK50Z-FA as is 
on your SCSI if its the  
    1) last on the bus (since its internally terminated and 
    2) of you can accept it addressed at SCSI addr 1.  (refer [to the first 
       reply] to address to something else.)


(Dow:  TK50Z-FA => -GA part number)
-----------------------------------
    Actually, according to the FS rep, it is not an FCO, but rather you need 
to order 3 proms to be replaced, part number 23-453E6-00 from DEC Direct.  
Price ~$30.


(Schenkenberger:  Keep the $30.00)
----------------------------------
    I still find no problem with the -FA on the SCSI except for the need to 
open  box to address SCSI id.  Try the box before you swap the ROMS (as per 
[the first reply]).  I don't think the prom's do anytyhing more than change 
the devices HWID.  (And you can put the $30 in your pocket!!)


(Dow:  DECUServe saves $$$ again)
---------------------------------
    Thanks Brian for your help.  I did order the PROM from DECdirect (my 
system manager recommended we do that), but with the help from your notes
I installed the prom myself and removed the three orange internal SCSI 
terminators (DEC wanted $200/hour to install with a two hour minimum; thanks 
for saving us $$$).
    Here are a few differences I discovered on my particular TK50Z-FA.
    
> 3) you will find 3 reddish/orange resistor packs (with 11 leads) in sockets.
>    These are the SCSI terminators. The FA was terminated internally.
    
    My resistors had 8 leads.  They were the only orange resistors in sockets.


The DECUServe Journal             January, 1993                       Page   7

    
> 4) in the corner of the board are a set of 5 shorting jumpers.  The first three
    
    My board has 6 shorting jumpers in the corner of the board.  It's original 
configuration was:  --
                    --
                    ==
                    --
                    ==
                    ==		== is jumper on back of board
    
    I tried changing the last three to jumpered, no jumper, jumpered but the 
system didn't recognize the TK50.  So I changed it back to the original 
configuration and it worked as SCSI id 1.
    Of course, now that I reread your instructions to my reply, I see that the key 
is that JUMPER OFF means 1.  oops.  I already had a device 2.  Well, 
everything is working and I know how to change it in the future if I need to.
    
    Thanks again.
    
    WARNING:  For the blind who skim notes and assume that the jumpers
              work the normal way in selecting the scsi id -- think again.
    
              REMOVE JUMPER to represent a 1.
              INSERT JUMPER to represent 0.
    

(Schenkenberg:  Memory lapses???)
---------------------------------
    Still 3 res. packs?  I did [in first reply] speak from memory.  I knew it 
had some odd numbering of pins relative to the norm for these inlines (10).
    When I first ripped mine apart, I too was confused by the jumpering. But, 
the VS2000's rom based tests and its T50 command status help me figure that out
quickly.  Again, sorry about the number of pins, I modified the box about a
year and a half ago.   I think I'm suffering from "Anheuser's" disease!!
    I have heard rumours that the tk50z-fa configure as I described _might_
hang the scsi bus on other nonVAX2000 boxes.  I've carried mine from 
Portsmouth NH to Decatur IL to load/test/backup/etc. on many varied systems.
I have yet to find any 'hanging'.  
    By the way, the carrying handle on those boxes make it a nice little piece 
of carry on luggage and fits nicely under the seat of most commercial airliners.
Although its a little hard (sometimes) to get the idiots at the security check
(x-ray) to understand its a computer tape drive and not a BOMB!.
glad you took my word and saved the $$$'s.


                  How Does One Attach an LP25 to a VAX 4000?
                  ------------------------------------------

        This article is an extract of the DECUServe Hardware_Help
        conference topic 1235.  This discussion occurred between August
        19, 1992 and September 8, 1992.  This article was submitted for
        publication by Jeff Killeen, DECUServe Contributing Editor.  Ed.

By Saul Tannenbaum, Frank Nagy, Linwood Ferguson, John Burnet, Tom McIntyre,
Terry Kennedy, Nick Donovan

The DECUServe Journal             January, 1993                       Page   8


(Tannenbaum)
------------
    I have an old LP25 that is currently connected to the "printer port" of a 
DMF-32 on a VAX-11/785.
    The VAX-11/785 is going away, soon to be replaced by a VAX 4000 Model 500.
How does one attach an LP25 to a VAX-4000? 
    P.S. I'm looking for a cheap solution.


(Nagy:  LPV11 Line Printer controller?)
---------------------------------------
    I think the Q-Bus version of the LP11 controller (which is basically what 
the parallel port of the DMF32 is) is the LPV11.


(Ferguson:  Some possibilities)
-------------------------------
    Yes, we've done this often, at least for LP26's which should be the same.
    I always get confused however between "short line" and "long line" and 
which is which and whether the DMF32 and the LPV11 are the same.  There is a 
conversion we've often used available from Data Products, installable and 
servicable by DEC, with no visible side effects (i.e. it is still a "DEC" 
printer and works just fine without any finagling with the queues or settings).
    If the LPV11 is viable for you (I do not think it is exactly cheap) and 
you need to know for sure, let me know and I'll find out if the long->short 
or short->long is needed (actually someone will probably have already posted 
the right answer by then  :-)
    Another cheaper possibility is a serial to parallel converter, which 
should be available relatively cheaply from Black Box or others.  Since the 
LP25 is 300 lpm (I think) speed should not be an issue.  Obviously needs a 
serial port.
    And a final possibility if you have a LAN is the DECserver 250 (at least I 
think that's the name) that will control several printers including I think 2 
parallel ones).  Probably the most expensive of the three choices, but offers 
a lot of growth and configuration flexibility.


(Burnet:  Serial->parallel converters)
--------------------------------------
    We did this on a 4000 with a DEC LXY12 (Printronix 300).  Since our P300 
originally had a Dataproducts interface, my first attempt used the Black Box 
serial->parallel converter for Dataproducts printers.  Then I found that that 
particular device won't work reliably at high speeds without hardware flow 
control, which DEC *almost* supports on the CXY08 (via SET TERM/COMMSYNC), 
but not quite, as of VMS 5.5.  So I then ordered the Centronics cable for the 
P300 from Printronix (no jumper changes or even termination changes were 
required), and got a very good, inexpensive ($100) serial-to-Centronics 
converter from Telebyte that does XON/XOFF flow control.  This combination has 
been working well for the last few months, and with the port set to 19,200 bps, 
the P300 does print at 300 lpm.
  As [the previous reply] mentions, the DECserver 250 is the preferred 
solution, but it's expensive.


The DECUServe Journal             January, 1993                       Page   9


(McIntyre:  Second hand LPV-11 is not expensive)
------------------------------------------------
    The last time I looked at the Midwest used computer catalog, the LPV-11 was 
$250.  A new one from DEC would cost quite a bit more of course.


(Burnet:  But was it an -S?)
----------------------------
    The question is, can an LPV11-S (skunked) be had for that low a price?  
It's always possible to cheat by using the old-style board and letting the 
cable hang out of the cabinet, but that's ugly and you lose the RFI shielding.


(McIntyre:  FCC is for sissies)
-------------------------------
    Well... Unless you are near an airport, the FCC probably won't come looking 
for you.  Short answer the cheap boards are the old standard duals I believe.


(Kennedy:  More on Dataproducts)
--------------------------------
    Various random answers:

    All DEC LPxx are "standard" Dataproducts. CSS offered a version with the
"long line" interface, which was retired and replaced by the LLF01 extender, 
which is itself retired now.
    Older Dataproducts / DEC printers used a Winchester MRAC connector. The
newer models (Bx00, LP2x) use a DB-50.
    The supported controllers are:

    LP11 - older Unibus
    DMF32 - newer Unibus
    LPV11 - older Q-bus
    LPV11-SA - newer (S-box) Q-bus
    DS250 - LAT/Ethernet

    Don't buy Black Box Dataproducts converters - they're a rip-off at $435.
Dataproducts is the same as Centronics except that the strobe is inverted and 
the termination is _lots_ stiffer. You can convert Centronics to DP w/3 chips 
(1 7404, 2 7407's) and some resistors. Schematics available on request.


(Burnet)
--------
    Also DMB32 (VAXBI).
    When I mentioned that no termination changes were required on the P300, I 
should have said that I was expecting that changes would be required, but I 
found that the cable was short enough that the printer worked fine with the 
resistors that were in place (1k-ohm instead of 220/330-ohm).


(Kennedy)
---------
    I have heard conflicting things about this board. I _know_ it doesn't have

The DECUServe Journal             January, 1993                       Page  10


all the same stuff as a DMF32, but was unsure which parts were missing. Thanks
for clearing this up.
    You mean that the P300 had "loose" termination (1K) already, right? In
that case things should work fine. LP2x printers are "stiff" and won't work
properly without a change.


(Burnet:  DMB32 should be fine for a Dataproducts-interface printer)
--------------------------------------------------------------------
    Well, all I can say for sure is that we have used P300, P600, and LG02
printers on DMB32s for a long time, and they all work fine (one was even moved 
directly from a DMF32 to a DMB at one point).
    I think that what's missing is the general-purpose parallel-I/O port.  The 
DMB32's parallel port is LP32 only and won't do DR11-C (bidirectional) as the 
DMF32 will.


(Tannenbaum)
------------
    Ask a simple question, get a prompt, detailed Decuserve response.
    We'll probably let Black Box rip us off for Dataproducts protocol converter 
- the GSA discount for it renders it less of a rip off and I wouldn't know 
what to do with a 7404 and 2 7407s...
    Thanks for the answers, folks.


(Donovan:  Try an Emulex box)
-----------------------------
    As an alternative to the DECserver 250.
    Emulex makes a LAT-Ethernet to Parallel box for under $1000.  We have been 
quite please with the one that we have.


              Macintosh and PC Share Files via Pathworks/VAX?
              -----------------------------------------------

        The following article is an extract of the DECUServe 
        Pathworks conference topic 393.  This discussion 
        occurred between May 20, 1992 and July 23, 1992.  This 
        article was submitted for publication by Jeff Killeen, 
        DECUServe Contributing Editor.  Ed.

By Bart Lederman, Mike Lampson, Nick Donovan, Shawn Chapla, Ta Fuh Chiam


(Lederman)
----------
    One of the things which Digital has demonstrated using Pathworks is to have 
a Macintosh put a file into a disk server (or virtual disk, or whatever) on 
the VAX, and then an IBM-type PC picks it up and uses it.
    We would like to do that here.  The person trying to set up the PC end of 
things is having a lot of trouble.  The Macintosh has no problem getting to 
it's AppleShare volume.

The DECUServe Journal             January, 1993                       Page  11


    Has anyone done this (defined a disk and/or file service on the VAX which 
is access from both Macintoshes and PC)?  Could you explain briefly how it is 
done?


(Lampson: Can do, sometimes a little painful)
---------------------------------------------
    There are detailed steps for doing this documented in the PATHWORKS for 
VMS (Macintosh) Server Administrator's Guide (AA-PBFFC-TE), Appendix C.
    In short, you need to define the root directory of your shared file 
service from both the Macintosh server and DOS server administration utilities.
Then, you need to set up ACLs on the directory structure so that all current 
and future files have these ACLs on them.  Then you can grant the VMS accounts 
that your PC and Macintosh users are using these identifiers. 
    Note that Macintosh files have something called data forks and resource 
forks.  These "forks" are stored as separate files on a VAX (the resource fork 
is in a [.MSAF$RESOURCE] subdirectory).  Therefore, DOS users can only access 
the data fork of a Macintosh file.  This is fine for most data sharing as text 
files, word processing documents, etc. store their data in the data fork.  If 
there is a resource fork for these files, it would hold information such as 
font names and word processor preferences.
    Also note that a DOS user can only see a file on this shared disk if the 
name has less characters than the 8.3 file name limit for DOS files.  Also, if 
the Macintosh user uses non-DOS (and non-VMS) usuable character in the file 
name, then the name is adjusted slightly by PATHWORKS (e.g. My Resum.wpc looks 
like MY_RESUM.WPC on the DOS machine).
    Let me know if you don't have the Server Admin manual and I'll type in the 
most significant commands.  However, I recommend you get the manual as it is 
quite useful.
        

(Lederman:  By golly, it works!)
--------------------------------
    Just having the pointer to the correct location in the correct manual saved 
me at least an hour of searching, and probably more.
    The instructions there are fairly clear, though some of the steps are a bit 
redundant.  And they don't give the steps which have to be done in ADMIN/PCSA 
to set up all of the PC side of it: after creating the service, you still have 
to start the service, make it known, and then grant each individual user 
access to it (that last step escaped us for a while), and you have to be 
certain that anyone who needs to write to the shared file gets write access.
    I really do not understand why I need two entirely separate sets of 
controls on the disk: one using VMS and ACLs, the other buried within 
Pathworks.  The Macintosh seems to work fine with just one set of controls, 
though the PCFS* ACLs seem to take precedence over the ACL identifiers I 
created according to the Appendix C instructions, and I don't know why I need 
two sets.  (I don't like ACLs much to begin with.)
    But it is working, and seems to work well now that we set it up.  And it 
isn't all that much trouble, once you know what has to be done.


(Donovan:  Don't have to use PCSA security)
-------------------------------------------
    A common question/complain.  PCSA maintains its own security database. 
When a tries to mount a service, the PCSA file server checks its database to 

The DECUServe Journal             January, 1993                       Page  12


see if the user has access to the service.  This would have been setup with 
the PCSA_MANAGER> GRANT command.  The file server then uses the ACLs that it 
put on the directory so it can have access.  You do not have to use this 
method, but DEC does not do a very good job of explaining the alternative.  A 
file service does not have to have been exported for a PC to mount it, ie:

USER ?: \\VAX7\DUA0:[WP_FILES]%JSMITH *

will mount the directory [WP_FILES] without a service having to be created.  
In this case standard VMS security is used.  There are other notes about this 
in the conference.

>(I don't like ACLs much to begin with.)

    If you play with ACLs you will find that they are very useful.  The key is 
to set them up correctly.  For example, if you put the following ACL on a 
directory:

UAF> ADD/ID WP_FILES

EDIT/ACL WP_FILES.DIR and add:

(ID=WP_FILES,ACC=R+W+E+D)
(ID=WP_FILES,ACC=R+W+E+D)
(ID=[*,*],ACC=NONE)
(ID=[*,*],ACC=NONE)

and then if you want to grant access to it, use the command:

UAF> GRANT/ID WP_FILES JSMITH

or to another user later:

UAF> GRANT/ID WP_FILES BJONES

ACLs are very flexible!


(Chapla:  Is pathname supported?)
---------------------------------
    If you use COMMON file services for the DOS users (instead of APPLICATION 
services), then the PCFS* ACE's don't propagate down to files and 
subdirectories under the root. Then, standard RMS protections (i.e. ACL's) 
handle the protection for your DOS users (though you still need to register 
them with access to the service).
    
>A file service does not have to have been exported for a PC to mount it, 
>ie:
>USER ?: \\VAX7\DUA0:[WP_FILES]%JSMITH *
>will mount the directory [WP_FILES] without a service having to be 
>created.  In this case standard VMS security is used.
    
    That's true that this works, but this isn't supported by DEC, is it? Even 
so, a drawback is that it requires your users to know full file pathnames to 

The DECUServe Journal             January, 1993                       Page  13


get to the service. If you have to move the service to another disk, your 
users have to be notified of its new location. If you stick with the service 
names, the users are blissfully ignorant (and isn't that the way we like them?).


(Lederman:  Even works with VMS files.)
---------------------------------------
    Actually, things are working fairly well now.  I can even transfer files 
between PCs and Macs and the VAX now by just copying them to/from the correct 
directory.  I can even put a VMS text file into the directory, and it shows up 
with the proper TeachText Icon and resource idendifiers on the Mac.
    It's just that, for our particular application, UIC based protection would 
do everything we need with less work on the system manager's part than ACLs.
    The big stumbling block now is going to be having the users (especially on 
the Mac side) save the files with attributes and file names that the MS-DOS 
people can read.
    I haven't tried to read the virtual disk with PCDISK, but I agree with the 
previous sentiment: it's really useful for reading and writing PC diskettes on 
the one VAXstation we have which has a floppy drive.  Not all of our machines 
are going to have Pathworks, and this is a handy option to have around.


(Donovan:  Use logicals)
------------------------
>That's true that this works, but this isn't supported by DEC, is it?
    
    I think that it is supported.  I know of some big users that do not want to 
export thousands of services, one for each directory that they have.  If DEC 
changes this, they will have some major complaints from many sides.
    
>Even so, a drawback is that it requires your users to know full file
>pathnames to get to the service. If you have to move the service to
>another disk, your users have to be notified of its new location. If
>you stick with the service names, the users are blissfully ignorant
    
    Not a problem.  Use logicals.  I was just using an example that anyone
could understand.  The real service (at our site) might be:
    
USE J: \\VAX7\AREA$MARCOM:[MARCOM]%JSMITH *
    
The logical AREA$MARCOM points to the correct disk.


(Chapla:  Connection to directories will go away?)
--------------------------------------------------
>>That's true that this works, but this isn't supported by DEC, is it?
>I think that it is supported.  I know of some big users that do not
>want to export thousands of services, one for each directory that they
>have.  If DEC changes this, they will have some major complaints from
>many sides.
    
    Since I originnaly made the point about support of a connection to a
specific VMS directory rather than a service name, we had a conference call 
with some DEC PATHWORKS development managers (arranged by our eager local 

The DECUServe Journal             January, 1993                       Page  14


sales reps) on PATHWORKS futures. One thing they mentioned is not to get too 
in deep with this technique. DEC's goal is to make PATHWORKS as LAN 
Manager-like as possible, and since this is not appropriate LAN Manager format, 
it is *very* likely to go away in a near-term release (though they conceded 
they will keep the personal file service capability).


(Donovan:  Another silly idea from DEC...)
------------------------------------------
>One thing they mentioned is not to get too in deep with this technique.
>DEC's goal is to make PATHWORKS as LAN Manager-like as possible, and
>since this is not appropriate LAN Manager format, it is *very* likely
>to go away in a near-term release (though they conceded they will keep
>the personal file service capability).

    This is the silliest thing that I have heard in a long time.  If a VAX 
looks like nothing more than a big PC, then why the hell would I buy a VAX and 
not a much cheaper PC?
    The value of Pathworks is that I can integrate a VAX file system with a PC 
network filesystem and keep a unified environment.  If I wanted a pure PC 
network, I would buy Novell, not Pathworks.

Grumble....

    With brilliant minds like this "managing" the Pathworks group, no wonder
DEC is losing billions...

    Did you raise any objections?  What was the response?

    Again to re-iterate my complaints.  I have thousands of .DIRs on my
VAXcluster any one of which, a PC user could want to access.  If DEC removes 
the VMS filename capability from Pathworks, then I would have to export 
thousands of file services (one for each .DIR) (I guess that a user could learn 
to use SETDIR, but this does not sound like "standard LAN MAnager" either and 
I assume that it would go away also).  I use ACLs to control access to these 
.DIRs and PCSA has its own security database, so my entire security database 
would have to be replicated (and maintained) within the Pathworks security 
database.  This would take weeks, even with automation, and all for what?  So 
I can be "LAN Manager compliant".  Who cares?

    How do I register my complaint?


(Chiam:  Business_Practices?)
-----------------------------
    BUSINESS_PRACTICES? It is gaining more and more topics nowadays.

The DECUServe Journal             January, 1993                       Page  15


                 Decrease Pipeline Quota for PC Performance?
                 -------------------------------------------

        This article is an extract of the DECUServe Pathworks 
        conference topic 418.  This discussion occurred on 
        July 24, 1992.  This article was submitted for 
        publication by Jeff Killeen, DECUServe Contributing 
        Editor.  Ed.

By Rick Davis, Jamie Hanrahan, Alan Striegel


(Davis)
-------
    In the VMS P/W 4.1 release notes, section 2, there's a short section called 
"improving performance".  In it DEC states you should decrease the DECnet 
pipeline quota to something between 2304 and 3455 IF you are using a VAX 4000 
or other VAX using the SGEC (second generation ethernet controller) AND you 
have PC ethernet cards with (1) no multibuffering support and (2) <16k memory.  
This is supposed to allow the PC NIC to keep up with the SGEC, and prevent the 
SGEC from initiating waits.
    We use 4000's, and have a fair number of WD8003e and Interlan 5210 cards 
which fit the description.  I've talked to DEC about this issue, and haven't 
gotten a satisfactory answer as to whether I should pay attention to changing 
the pipeline quota.  Performance not always being what we'd like it to be, 
this seems like something to consider.
    Can anyone shed any light on this?  Is this a valid suggestion?  What side 
effects does decreasing pipeline quota cause?  DOES IT HELP?


(Hanrahan:  Take DEC's advice with several grains of salt...)
-------------------------------------------------------------
    I infer from this that they are talking about reducing the pipeline quota 
on the VAX side.  (I'm not sure if it's even configurable on the PC side.)
    This may result in a severe performance hit for other DECnet applications 
(those talking to nodes other than Pathworks).   Here's why:

    When an application under VMS writes to a DECnet logical link, it is told 
that the write is done (ie the $QIO to the network link completes) as soon as 
the data has been copied to a buffer in local nonpaged pool.  Eventually DECnet 
moves it to a buffer in the destination node, at which time the local buffer 
is freed. The pipeline quota determines the amount of pool that you can use 
for this, on a per-logical-link basis.  This gives you the benefit of multiple 
queued writes with write-behind cacheing with no extra effort on the part of 
the application programmer!  This benefit vanishes if you make the pipeline 
quota small.  (Many DECnet experts advise you to *increase* the pipeline quota, 
from its default of 10000 bytes to several times that value, to increase 
performance on most applications!) 
    The pipeline quota is also used to determine the initial size of the 
transmit window at the NSP (logical link) layer.  The transmit window is the 
amount of data that can be sent before stopping and waiting for an ACK from 
the far end.  It is init'd to 2/3 of the pipeline quota, and adjusted up or 
down from there depending on acks, credits, etc., received; it can never be 
larger than the pipeline quota (for obvious reasons).  As anyone who has used 
old Kermit implementations can tell you, a small transmit window really hurts 
performance if you have a lot of data to move.  

The DECUServe Journal             January, 1993                       Page  16


    Another aspect of this is ... what are you trying to improve the 
performance of? If it's virtual disk or file services, forget it. These use 
the LAD protocol, which in turn is layered on LAST, which is layered directly 
on Ethernet... ie DECnet is not involved!  (Take a look in NCP> SHOW KNOWN 
LINKS :  do you see logical links for PC disk or file services?)  In which 
case, forget DEC's advice about pipeline quota completely!  (Unless there's a 
pipeline quota for LAST, settable in LASTCP?  I haven't looked.) 
    DECnet is only involved in Pathworks file transfers when you are running 
FAL or NFT on the PC.  Homegrown applications that talk from the VAX to 
programs running on Pathworks nodes of course also use DECnet.  If you do a 
lot of these things, then you might consider DEC's advice... but you will be 
hurting the performance of VAX-to-VAX DECnet applications, including remote 
file access. 
    The real trouble, I guess, is that you can't tell DECnet/VMS to use a 
different pipeline quota for different nodes (ie larger values for VMS nodes, 
smaller for Pathworks). 


(Striegel:  Well... let's not assume too much)
----------------------------------------------
>DECnet is only involved in Pathworks file transfers when you are running 
>FAL or NFT on the PC.  Homegrown applications that talk from the VAX to 
>programs

    Not entirely true all the time.  File services only use LAST if you 
explicitly configure the client node for that (it is not the default) then it 
tries to connect using LAST first.  If it fails, it used DECnet instead.  LAD 
applies only to Disk services and CD-ROM services.  Note also that neither 
LAST nor LAD can be used on token ring networks or across wide area 
connections.  (Even in some ethernet configurations it may not work if traffic 
or bridge delays make LAST unreliable.)


                    Communications Wiring for a New House?
                    --------------------------------------

        This article is an extract of the DECUServe Shop_Talk
        conference topic 37.  This discussion occurred between
        July 30, 1992 and August 6, 1992.  This article was 
        submitted for publication by Alan Bruns, DECUServe 
        Contributing Editor.  Ed.

By Keith Hare, Curtis Reid, Bill Mayhew, Jamie Hanrahan, Linwood Ferguson,
Charlie Luce Jr., Ed Bailey, Jack Harvey, Arnold DeLarisch, John Burnet, 
Jack Stevens, Rob Brown


(Hare)
------
    I am in the process of building a new house, and am looking for comments 
and/or suggestions on data communications wiring.  I figure that it is better 
to wire now, than wire later, even if I have no immediate needs.
    I am thinking in terms of a star configuration, where I basically run wires 
to most rooms, but just drop them into the basement for the moment.

The DECUServe Journal             January, 1993                       Page  17


    My questions (so far) are:

    Is it possible to run tv and data over the same wire, either at the same 
time, or not?  The house is nowhere near a tv-cable line (or anything else, 
for that matter), but a satalite dish is a remote possibility.  Is it possible 
to run tv over rg58 cable?
    
    What is cheapest - thinwire or something like 10baseT over twisted pair?  
Which is going to have the most support in 10 years?
    
    Is it worth running fiber at this point or is the cost of the cable
prohibitive?
    
    Is there something else I should consider?


(Reid)
------
    In my house, I have a twisted 3-pair telephone cable (I forget which kind) 
connected in each room in the house and each all drop to the basement to be 
connected on a 66-block.  This way, I can control certain rooms such as guest 
room from making excessive long distance calls or (heaven forbid) 900 numbers.  
Another feature is that it is easier to troubleshoot which line is bad.
    As for the tv cable, it is in similar setup like I did for the phone cable.


(Mayhew:  Soooo much cheaper now than later!)
---------------------------------------------
    Relatively speaking, cable is cheap.  Labor isn't.  In new construction, 
while the labor is also cheap (i.e. before the walls go up), I would string 
something like 12- or 25-pair cable to each room.  You never know when you're 
going to decide to turn one room into an office with a need for N serial ports 
or N unshielded-twisted-pair links and it is oh-so-easy to take advantage of 
them when they're already there :-)
    I would simultaneously string at least one thinwire Ethernet link and at 
least one coax TV line... more, maybe, depending on the wall layouts.
    In our 70-year-old house we are retrofitting as time and $$ allow.  The 
first floor rooms, except the kitchen, now have at least two loaded DECconnect 
wall plates each.  The second floor is a whole lot more trouble and is mostly 
serviced by a Rabbit for TV (you know... the thing that will retransmit your 
"VCR" (or cable, but of course they don't advertise that) signal from your 
main TV to 'satellites'; ours uses mini untwisted single-pair wire, there are 
new ones that do it over the house wiring, which I wouldn't trust in a house 
with lots of competing electronics).  Data service to the upstairs rooms is 
either by modem ;-} or by the throw-a-cable-down-the-stairs method.  I wish it 
were better and it will have to be some day.
    And don't skimp on the electrical service or number-of-outlets, either
    :-)


(Hanrahan)
----------
>Is it possible to run tv and data over the same wire, either at the same 
>time, or not?  

The DECUServe Journal             January, 1993                       Page  18


    Sure.  It's called "broadband".  In essence you have transceivers that 
take the Ethernet info and put it on a carrier, and vice versa.  Since the 
carrier is at a different frequency than any of your TV channels, it can 
coexist on the same wire, just as multiple TV channels do.  Sorta expensive 
for home use though. 
    It'd also be lovely if there were PBX systems that could ride on broadband
Ethernet, so that you wouldn't have to run phone wires as well as cable, but
I don't think that exists yet.

>Is it possible to run tv over rg58 cable?

    Not unless you like lots of ghosts.  rg58 is 50 or 52 ohm impedance, TV 
cable (RG59, RG6) is 72.  
    
>What is cheapest - thinwire or something like 10baseT over twisted pair?  

    For a star configuration thinwire is more expensive for the cable, but
twisted pair will need a hub in the basement.  otoh, if you really want a star 
configuration, thinwire will need a "hub" like a DEMPR as well, or else two 
cables to each room (one going, one coming back).  

>Which is going to have the most support in 10 years?

    Your guess is as good as mine.  Actually my guess is that 10 years is a 
VERY long time in this business and new installations at that time will be 
done with something that's unheard of now. 

>Is it worth running fiber at this point or is the cost of the cable
>prohibitive?

    The cost of the cable isn't that bad, but if you do this without intending 
to use it right now, you run the risk of your fiber not being compatible with 
whatever you do end up using. 
    
>Is there something else I should consider?

    The previous reply about power is good advice.  Especially with regard to 
your "computer room".  The manual for my HP LaserJet III, for example, says 
that it should be on its own circuit.  I would run no fewer than four separate 
20-amp circuits to this room.  
    Similarly, if you are planning a "media room" with something formidable in 
the way of TV projectors, high-power audio amps, etc., use at least one 
separate circuit for this equipment -- maybe more.  (Real audio nuts will put 
the power amp on its own circuit, the other audio gear on another circuit, and 
video gear, if any, on yet a third.) 


(Ferguson:  Belt and suspenders)
--------------------------------
    After you do all the wiring, go back and put some conduit in.  Put in a 
box in each room (or ones you might *ever* want something in) and stub the 
conduit off in the crawlspace or attic.  Then in a couple of places run some 
all the way from the crawlspace to the attic so you can get stuff up and down.
    If you never need these you spend about $5 per room.  If you ever need 

The DECUServe Journal             January, 1993                       Page  19


them you save hours and hours and lots of sheetrock repair.
    If you never need these you guessed exactly right on all the wiring; go 
directly to Vegas and start playing.


(Luce:  Dissenting Experience)
------------------------------
>I would simultaneously string at least one thinwire Ethernet link and
    
    For the record, I wouldn't -- 10BaseT is far easier to work with.  If you 
keep an eye on the CDDI (Copper, as opposed to Fiber, Distributed Data 
Interface) and run some proper shielded twisted pair you will be able to 
upgrade from 10 to 100Mbps if you ever feel the need (and want to spend the 
$$$ on new hub and interfaces, of course).


(Mayhew:  Maybe I'm underinformed about new developments, but...)
-----------------------------------------------------------------
>For the record, I wouldn't -- 10BaseT is far easier to work with.
    
    Isn't 10BaseT limited to one station per segment?
    In any case I will disagree about it being easier to work with.  Admittedly 
you need to make an investment in tools (or beg/borrow them), and that may be 
an obstacle in itself, but once you have 'em -- and I think we're talking 
under $100 here -- thinwire is no problem, compared to unshielded twisted 
pair.  Either one is easier to deal with than shielded twisted pair IMO.
    I much prefer the notion of shielded cable carrying those high frequency 
signals around the rooms where I and potentially my family and kids spend the 
bulk of our lives.  Am I being paranoid?


(Bailey:  Put in conduit!)
--------------------------
    I'd have to agree with - uh, drat, I forgot their name; sorry! - about
putting in conduit.  There's no telling what the preferred method of hooking 
stuff together will be in ten years (I'd bet on some sort of wireless 
technology myself), so why not concentrate on a method that will give you the 
most flexibility?  Conduit doesn't care if it has rusty coathangers soldered 
together or a bundle of fiber in it, so put the conduit in now, fill it with 
whatever is best for your needs right now, and enjoy.  Later, you can add more 
stuff in, or rip it out and put in the latest and greatest...
    Some thoughts on conduit.  (I just installed a satellite dish in the
backyard and ran conduit to it, so I'm an expert...:-)   )  I'd use the nice 
grey PVC conduit instead of the steel stuff - it cuts easily, you don't have 
to worry about bending it (you buy prebent sections), and assembly is a snap.  
Also, if you want to take a break while "gluing" the stuff together, simply 
take a good whiff of the solvent, and you'll be in another world for a 
while... :-) :-)

    Some other thoughts:
    You can never have conduit that is too big (there once was a person that 
thought they put in conduit with too large a diameter, but after walking 
through it, and looking around, he changed his mind... :-)   )  Bigger conduit 
lets you stuff more cable through it, and (as long as you don't put *too* much 

The DECUServe Journal             January, 1993                       Page  20


stuff in it) makes pulling cable easier.  For a house with typical 2X4 stud 
construction, you should be able to get away with something on the order of 
inch and a half to 2 inch conduit.
    You will probably want to add cable to it after some time, so it never 
hurts to pull a hunk of rope/good twine along with your initial bundle (and 
with every subsequent bundle).  The electricians have a name for this, but I 
forgot it.
    Stubbing the conduit up to the attic and down to the basement is a good
way of doing it (though if there's a floor in the middle you will have some 
challenges); just make sure you will be able to get to the attic and/or 
basement end of the stubs when the house is complete.  My attic is mostly 
covered with a couple feet of blown fiberglass; I'd not relish going through 
it very much.  Oh, and you will need to talk to your builder about leaving you 
a good size "core" from the top of the house to the bottom, so that you can 
put in a large hunk of conduit, and connect the basement and attic stubs.  I'd 
go at least double the size of the stubs on the core.
    If you do this, you'll never have a problem connecting anything in your 
house.  Then, when everything goes wireless, you can use the conduit for a 
central vacuum system!  :-)
    
Ed_who_missed_his_chance_at_installing_conduit,_and_regrets_it_still...  :-(


(Harvey:  A vote for Thinwire in this case)
-------------------------------------------
>Isn't 10BaseT limited to one station per segment?

    Yes.  What may be confusing is that prior to the 10BaseT standard, there 
were some low cost twisted pair to RG58 baluns that allowed you to directly 
interconnect Thinwire and twisted pair.  This is VERY HAIRY.  
    True 10BaseT has full Ethernet reliability, but requires a non-trivial hub 
box at the center of the star to feed each arm going to a single node.  Unless 
you have such a box for free, RG58 will probably be far cheaper for a ten room 
house.  Don't buy made-up cables.  Buy the parts and make them for about $30 
per room.


(Luce)
------
>Isn't 10BaseT limited to one station per segment?
    
    I prefer to think of it as only being able to wipe out one node at a time 
:-)  Besides, [the original question] specified a star configuration.

>I much prefer the notion of shielded cable carrying those high frequency 
>signals around the rooms where I and potentially my family and kids spend the 
>bulk of our lives.  Am I being paranoid?
    
    I'm not an expert on EMI, but given that DEC has proposed FDDI speeds over 
UTP I suspect that Etherspeed isn't leaking all that much.
    OTOH, I question of a wiring scheme that lets Junior (or Spot) trash the 
net at any node by playing with the T.


The DECUServe Journal             January, 1993                       Page  21


(DeLarisch:  Residential FCC regulations are stricter than commercial) 
----------------------------------------------------------------------
    Just a small point:
    I believe that the FCC rule in residential areas are stricter then in 
commercial buildings. Standard RS-232 cables wreak havoc with FM reception.
There is even some splatter from good shielded RG58.
    If it were me, it would be either fiber (assuming I hit at least on 
jackpot in Las Vegas) or good ol' RG58.
    Remember, whatever they get to work over shielded/unshielded twisted pair
will be much easier to do over coax (Yes, I know ... gross oversimplification
OK, High Freq. EE's begin trouncing 8-{) but I think its very close to reality).

P.S. I believe that the FCC has no sense-of-humor about rf/emi radiation
     in residential areas. Cease and desist is what is their normal solution.


(Harvey)
--------
>I much prefer the notion of shielded cable carrying those high frequency 
>signals around the rooms where I and potentially my family and kids spend the 
>bulk of our lives.  Am I being paranoid?
                                ^^^^^^^^
    Yes.  The high frequency signals from the horizontal sweep circuits of
your TV sets are far stronger.
    However, this is a religious issue, with no answer.  Some people won't eat 
food from microwave ovens because it has been exposed to "radiation".


(Burnet:  Some near-field non-ionizing radiation can be a health hazard)
------------------------------------------------------------------------
    Agreed, but...
    The second part (not eating food from microwave ovens) is obviously silly,
but I disagree that there is "no answer".  First, it's necessary to specify
explicitly what range of frequencies you're talking about.  And then, with
certain frequencies of non-ionizing radiation, the answers have been
deliberately obscured for decades by stonewalling on the part of computer and 
CRT manufacturers, the newspaper industry (a major CRT user with vested 
interests in keeping its employees ignorant), the big power utilities, and 
especially the U.S. regulatory agencies like OSHA, under the Reagan and Bush 
regimes.
    The certain frequencies that I'm referring to, of course, are in the 60-Hz 
neighborhood (power-line frequencies) and the 15-kHz neighborhood
(flyback-transformer frequencies in video monitors).


(Hanrahan:  obligatory skeptic's reply)
---------------------------------------
>Some near-field non-ionizing radiation can be a health hazard

    This simply has not been proven.  At best there is a lot of anecdotal 
evidence and some studies that *may* show correlation between exposure to such 
radiation and health problems, depending on how you look at the data.  
    But correlation is not proof of cause-and-effect.  You might as well claim 
that the CRT evidence shows that long-term exposure to trace amounts of ozone 

The DECUServe Journal             January, 1993                       Page  22


causes problems.  There is also good reason to suspect that the correlations 
that have been shown between living near high-tension powerlines and incidence 
of certain cancers has a lot more to do with exposure to PCBs (used in older 
distribution transformers), to the defoliants often used around power poles, 
and to the wood preservatives used on wooden utility poles, than with exposure 
to ELF radiation.  


(Mayhew)
--------
    Hey, I'm a card-carrying skeptic, too.  I agree with Jamie in [the previous
reply], e.g.
    But, when I wire my house, I have control over it.  That means I get to
make the decision -- I don't have to live with the decision made by a power 
company or TV manufacturer that is *possibly* more concerned with profit than 
with my family's personal health.
    In addition, the TV flyback frequencies only happen while the TV is on. 
Ethernet would be running 24 hours a day, and hidden in the walls where it's 
easily forgotten.
    So even if I am paranoid, I am inclined to be cautious when I'm readily 
able to.  Particularly if there are very young children in the picture.
    As to the risk of Bobby unhooking the T connector ... isn't that what the 
fancy make-before-break dual-cable Ethernet wallplate jacks are for?


(Harvey:  <:-}=  )
------------------


(Hare:  Summary, RG58, RG59, and lots of circuits)
--------------------------------------------------
    Sounds to me like the best bet is to pull rg58 for data and rg59 for tv
(I'm more likely to use the rg58 than the rg59).
    I'm not overly concerned about fm interference and the FCC - this house
will be in the middle of 15 acres.
    And, plenty of circuits, and some extra conduit, just in case.  Shouldn't 
be a problem, since my brother, the electrical contracter, will be helping me 
wire.

    
(Stevens:  Home Busses Are Being Designed)
------------------------------------------
    Since I don't have a copy of Popular Science handy, I can't give details, 
but there are a couple of house-specific wiring systems (cables, faceplates, 
protocols) you may want to evaluate.  They include the things one would expect 
in a house:  power, communications, entertainment, and smart-appliance bus.  
Naturally, there is no agreement among appliance manufacturers about which one 
to use, but you may want to look them up and see what they bundle together.


(Brown:  A pointer to the Articles conference)
----------------------------------------------
    19.49 in the articles conference may be of interest (or it may not).


The DECUServe Journal             January, 1993                       Page  23


                                  C Pros & Cons
                                  -------------

        The following article is an extract of the DECUServe Shop_Talk
        conference topic 41.  This discussion occurred between August
        19, 1992 and October 6, 1992.  This article was submitted for
        publication by Jeff Killeen, DECUServe Contributing Editor.  Ed.

By Dana Schwartz, Brian Schenkenberger, Mike Terrazas, Bart Lederman, 
Eric Husby, George Merriman, Jane Furze, Jack Harvey, Jeff Killeen, Dale Coy,
Bill Wood, Frank Nagy, Bob Hassinger, Bill Mayhew, Matt Holdrege, 
Charlie Luce Jr., Bruce Bowler, Jack Patteeuw, John Burnet, Curt Snyder,
Wayne Steffen, Larry Kilgallen


(Schenkenberger:  Calling all C haters)
---------------------------------------
    Hello,
    I saw your disclaimer that you added to the bottom of a reply on keeping 
TECO on AlphaVMS in the VMS conference.  I just had to say hello.
    I too find great disdain of the C language.  Possibly for several reasons, 
of which you too may confer (and add onto if you wish.) 

1) Its ridiculously (and intentionally) designed and written to be cryptic!
2) It reeks of UNIX (a four letter word in my book)
3) Sophomoric concepts of file access and architecture. 
4) Its being sold (thrust down the thoughts of) corporate management as the
   portable language to end all languages.
5) If you're on VMS->WHY C?   C is to UNIX what Bliss is to VMS (I'm certainly
   no Bliss advocate!! Give me Macro or give me death!)

    Maybe like the Little Rascal's Women Haters Club, we could start a 
C hater's club.  ???


(Terrazas:  C the language people love to hate.)
------------------------------------------------
>1) Its ridiculously (and intentionally) designed and written to be cryptic!

    Yes it is intentionally designed.  It is not written to be cryptic, it is 
written to be concise.  Many C newbies make it cryptic, based on bad habits 
from languages like Fortran and early versions of BASIC where variables had 
limitations on length.

>2) It reeks of UNIX (a four letter word in my book)

    Since C came first, perhaps it would be better to say that Unix reeks 
of C.

>3) Sophomoric concepts of file access and architecture. 

    Any portable language cannot expect to find the rich file structure you 
find on ODS2 disks or under RMS control.  The price for portability is 
over-generalization.  The careful programmer has a file handling subsystem 

The DECUServe Journal             January, 1993                       Page  24


that uses the features of the operationg system s/he is on, and re-writes that 
subsystem for the different platforms that s/he is running on.  If you choose 
a language that covers that for you, then you're at the mercy of the compiler 
implementers as to the behaviors you see.  I'd love to tell you about the 
frustrations our COBOL programmers are having trying to get the same 
application to have the same temporal characteristics on our Amdahl, Cyber, 
and VAX machines.  They can't even find an acceptable compiler on some other 
platforms (DECsystem, HP-UX, PCs and others).

>4) Its being sold (thrust down the thoughts of) corporate management as the
>   portable language to end all languages.

    Interesting.  Our management views C as the language of choice only when 
more productive tools fail to meet requirements.  Some of the tools they 
prefer are 4GLs, authoring languages and the like.  These tools seem to all 
have a C interface.  Not so with any other language we've looked at.

>5) If you're on VMS->WHY C?   C is to UNIX what Bliss is to VMS (I'm certainly
>   no Bliss advocate!! Give me Macro or give me death!)

    Indeed.  How long are you going to remain purely VMS?  How long is Macro 
going to sustain your needs?  Decisions about what technical corner you paint 
yourself into should be made with an attempt to look at least 5 years down the 
road.  Preferably 10-20.  I don't have that kind of faith in Macro, VMS or 
even DEC.  If you do, I hope you're right.

    MikeT who was DECUS' representative to X3J11 (C Language Standard) 
until last week.


(Lederman:  It's not the computer, it's us.)
--------------------------------------------
    I've switched my "3GL" programming from FORTRAN to C over the past few 
years, and looked at a lot of programs.
    I find the biggest problem with C programs being cryptic isn't the 
language, it's the programmers.  People trying to show how "clever" they are, 
how many odd "tricks" they can put into a program, how many statements they 
can collapse into one, etc.  [As usual, of course: it's almost always not the 
tools that are at fault, it's the people using them.]
    I wouldn't want to be forced to use a language which is so rigid you can't 
do any 'tricks' at all: I wrote programs in RPG when I had to (it was the only 
tool available), and it's a language where you simply cannot have any unusual 
language constructs.  But there is a lot it simply will not do.
    Not that I think C is perfect either, but I don't think the majority of bad 
C programs can be blamed on the language.


(Schenkenberg:  put it in perspective)
--------------------------------------
>>Indeed.  How long are you going to remain purely VMS?  How long is 
>>Macro going to sustain your needs?  

    If the application is targeted for a platform (ie. some program just chock-
full-o'-VMS-system-services) then use a language more adapted to the job.
I've written in C as well as many others from Ada to Pascal.  I can't see why

The DECUServe Journal             January, 1993                       Page  25


you would contort yourself with a language in which you must bend over back-
wards to solve a problem.  Try calling the SMG menu functions in VAX C and
VAX Fortran and then tell me its easier in C.
    And I agree that the programmer has a lot to do with its cryptographic 
nature.  But then that's the nature of the beast.  Its a mindset which has 
been promulgated throughout the UNIX community where C first reared its head 
from the murky primorial waters.

>> MikeT who was DECUS' representative to X3J11 (C Language Standard) 
>> until last week.

    Every Mother loves her child!


(Husby:  In defense of C)
-------------------------
    I'm no real fan of C although I've used it to make a living for the past 5 
years.  But had to answer this.  The secret to using C to call routines in 
other languages ( an all VMS RTL's and System Services are other languages) is 
to use a wrapper. Either a macro or a routine that translates C to the other 
language.  This way you only do the "translation" once, not every time you use 
the function. This is similar to the comment a previous poster made about a 
record management system, which, incidentatly is not ODS-2.  
    With proper coding styles, C can be as easy to read as any language.  The 
coding mistakes that C programmers make can be made in any language.


(Terrazas:  Beginners code is always bad.)
------------------------------------------
    [Regarding the previous reply by Brian Schenkenberger]

    Eric's reply in [the previous reply] answered your first point very well.  
I've done LOTS with SMG and other system services in C.  I have no problems.  
It is quite a bit easier than in Fortran for me, because I can't read Fortran, 
and the one program I had to do in it took me 8 times as long as it should.  
It was probably very bad Fortran, too.  That doesn't make Fortran bad, though, 
just useless to me.

>And I agree that the programmer has a lot to do with its cryptographic nature.
>But then that's the nature of the beast.  Its a mindset which has been prom-
>ulgated throughout the UNIX community where C first reared its head from
>the murky primorial waters.

    Again, Unix came from the C, the source of all life ;-}

    But germane to your point: in general, the good programmers on Unix write 
very readable C code.  Problem is that a lot of the C programs people look at 
come from college students.  Students never code with the thought that someone 
else will have to look at this code.

>>MikeT who was DECUS' representative to X3J11 (C Language Standard) 
>>until last week.
> Every Mother loves her child!


The DECUServe Journal             January, 1993                       Page  26


    I have some criticisms for C that are a lot more substantive than I've ever 
seen on this system.  I spent an hour once discussing them with Dennis Ritchie, 
and he agrees.  I use C a lot.  I know some of the biggest warts as good 
buddies.  The point of my replies here is that the usual complaints against C 
can be leveled at any other programming language, particularly if you look at 
student code or entry-level programmer code.


(Merriman:  Recommended reading)
--------------------------------
    I suggest anyone who wants to take other people's money to write C code 
get a copy of a Digital Press book called "DEC Guide to Software Engineering" 
or some such. It contains a C coding style guide, which if followed carefully, 
produces very maintainable C code. It makes your code look a lot like Pascal, 
in fact.


(Furze:  C is powerful, not cryptic)
------------------------------------
    Everyone talks about C being portable then complains about the differences 
in the implementation of the RTLs on different platforms.  One day I finally 
realized the virtue of C.  It is the only language I have used (abused?) 
that is guaranteed to produce bug free code every time if you use it in it's 
pure, vanilla, unenhanced form - that means no added RTLs.  Vanilla C has no 
input or output instructions; these are implemented via RTLs.  If you cannot 
get any data out then, obviously, you cannot get any errors so the code must 
be bug free!

>the Little Rascal's Women Haters Club

    Don't forget who's note you are replying to!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>
sarcasm hat firmly in place but with a smile >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>

>Many C newbies make it cryptic

    I took a C night course in college from a fellow who spends his days in the 
real world writing C code for American Express.  In his first lecture he 
repeated, at least once every 5 minutes, that well written C code is not and 
should not be cryptic.  The rest of the semester was spent learning all of the 
neat things you could do with one line of C code because it is so powerful.  I 
got a B in the course when I thought I would get an A.  I have always thought 
that this was directly related to the 1/2 hour argument he and I had one night
over whether the instruction 
	
    if ((++x != ERROR) && (x-- != ERROR)) then x++

is 'powerful' or 'cryptic'.

>The price for portability is over-generalization.  

    Think of how much simpler things would be in the auto industry if only 

The DECUServe Journal             January, 1993                       Page  27


someone would design one 'portable' engine that could be installed in any and 
all makes of cars - whether it be a VW BUG or a Jaguar.  The designer would 
make a fortune because customers would insist that every auto manufacturer 
use that standard, portable engine.

>How long is Macro going to sustain your needs?  

    One C proponent explained to me that it's easier to think in C if you 
think of it as a high-level language designed by and for PDP-11 machine-level 
programmers.

    So instead of

    (R3)++  

C lets me say  

    x++ 

    Oh, gee, I see the light now.  That's a lot less cryptic and by 
programming in C I can, essentially, have the power and flexibility of PDP-11 
machine code when I program my HP-900.  Hey, this is really terrific.  Do I see 
a merger of DEC & Motorola in the offing?  GREAT RUMOR. Let's start it!

>MikeT who was DECUS' representative to X3J11 (C Language Standard) 
>until last week.

    Glad to hear you finally returned to reality, Mike.  Welcome.


(Harvey:  Macro is passe)
-------------------------
>5) If you're on VMS->WHY C?   C is to UNIX what Bliss is to VMS (I'm certainly
>   no Bliss advocate!! Give me Macro or give me death!)
                                                 ^^^^^
    You've got it!  I have written tens of thousands of lines of both Macro-11
and Macro-32, and I love both.  This Spring, I took to calling Macro-32 a dead 
language, like Latin.  Recently, I decided to start calling it a zombie 
language.  Why all this "attitude" about Macro?  

                                      Alpha.

    1. You can't count on Macro-64 as a high performance implementation
language on Alpha.  You would probably have to recode for each new model of 
Alpha in order to achieve maximum performance, and the coding will be a 
statistical nightmare.  Machine code is something best left to the new 
generation of super compilers for high level languages on Alpha.

    2. A Macro-32 compiler will be available on Alpha, but:
           a. It isn't an optimizing compiler.  You may take a performance
              hit over a program written for Fortran or C.
           b. You frequently need to revise your Macro-32 code to get it to
              work right, or so say the Digital developers.
           c. There is no promise it will be supported in the future.

The DECUServe Journal             January, 1993                       Page  28


    At first glance, it might appear that any sensible programmer could write a 
compiler that will turn out good error-free Alpha code.  The hitch is the 
combination of "good" and "error-free", and this is because the Alpha machine 
does not have physical status bits which your Macro-32 code may very well 
expect, in tricky ways, to exist.
    I am not criticizing the Digital developers when I call Macro-32 on Alpha a 
zombie language.  It's dead and they have done an amazing thing: they got it 
to work!  Just don't expect it to be warm and friendly.
    So, as much as I love Macro, I have decided to write off that part of my 
skill set and get on with becoming proficient in C.


(Wood:  Use the "right" language for the job at hand.)
------------------------------------------------------
    Can one language really be all things to all people?  Would anyone really 
want to write a device driver in COBOL?  Isn't it really easier to read a 
database, keep some totals and sub-totals, and format 132 column business 
reports in COBOL than C?
    C is good for writing utilities, drivers, system level code, etc.  C 
programs are only maintainable if they're written by good, well disciplined, 
programmers.  C is a horrible choice for our shop, since we mostly use 
contract programmers who are neither good, nor well disciplined.
    I believe the concise nature of the C constructs encourages C programmers 
to write in a concise nature.  Unfortunately what appears concise when it was 
written looks quite cryptic to someone else, or even to the author several 
years after writing it.  In contrast the more verbose style of the COBOL and 
PASCAL languages encourages a more verbose coding style which can be easier to 
maintain several years later.  I find it amusing that an earlier note used a 
phrase like "code which looks like PASCAL" to describe a good C coding style.
    I also believe in the value of strongly typed languages, such as PASCAL.  
Most people, and I am clearly one, have bugs in our code.  I like my computer 
to do as much work as possible.  I much prefer having my compiler catch my 
typoes to having my users catch my typoes because they ran a code path I 
didn't completely test (since we can't test all code paths completely in 
medium or large applications.)  
    On the portability argument, FORTRAN makes pretty portable code if the
coder sticks to standard FORTRAN.  It also provides less opportunity to shoot 
oneself in the foot than C.  Of course that is because it is less powerful.  
But many application development efforts don't need, and shouldn't have access 
all that extra power.  The principle is much like using a cannon to swat a fly.


(Schenkenberg:  Help Jane!  Stop this crazy thing!!!)
-----------------------------------------------------
    The reference to the 'Little Rascal''s episode was not intended to offend
the women or to be sexist but... more an analog (you know - pre-digital).  
I happen to like women... even married one!!!  Also, my current supervisor is 
a woman.  Understanding, intelligent, and willing to listen.  180 from my past 
male supervisors.  
    Glad to see I was able to 'RAKE up the MUCK' about C.  
    Like the Idea of the Standard engine! Fits in anything from a VW to a 
J(ust) A(t) G(arage) U(ndergoing) A(nother) R(epair).  Will it be a 500+ cu.in. 
V8 configuration or a 750 cc salad oil fueled 4 banger? 
    Personally, I won't give up my King-of-the-Road.


The DECUServe Journal             January, 1993                       Page  29


(Terrazaz:  Shouldn't this be moved?)
-------------------------------------
>vanilla, unenhanced form - that means no added RTLs.  Vanilla C has no input 
>or output instructions; these are implemented via RTLs.  If you cannot get 
>any data out then, obviously, you cannot get any errors so the code must be 
>bug free!

    This used to be true.  Since the ANSI Standard there is an RTL with 
documented behavior that is part of the language.  stdio happens to be one of 
those libraries.  I realize the paragraph was supposed to be a joke, but I was 
afraid someone might believe your statement.

>I took a C night course in college from a fellow who spends his days in the 
>real world writing C code for American Express.  In his first lecture he 
>repeated, atleast once every 5 minutes, that well written C code is not and 
>should not be cryptic.

    Just because someone gets paid for something and just because s/he 
professes something doesn't mean they're good at it...

>    if ((++x != ERROR) && (x-- != ERROR)) then x++

    Is the type of code that's typical of the beginner.  In my book, a 
beginner is one who doesn't code for the maintenance programmer.

>Think of how much simpler things would be in the auto industry if only 
>someone would design one 'portable' engine that could be installed in 
>any and all makes of cars - whether it be a VW BUG or a Jaguar.  
>The designer would make a fortune because customers would insist that 
>every auto manufacturer use that standard, portable engine.

    I agree.  I'm not arguing that C is the only language one should use.  By 
the same token, to rule it out because one has Macro is very much like saying 
that no other car should be used besides a Peterbilt cab-over with back bench.

>Can one language really be all things to all people?

    No.

>Isn't it really easier to read a database, keep some totals and sub-totals, 
>and format 132 column business reports in COBOL than C?

    Not for me, I've never done any COBOL.  I do have a set of report function 
primitives that allow me to read databases and format reports in as little 
time (or less) than most of our COBOL programmers.  Those primitives did take 
me some time to develop, and I wish I was at liberty to put them in the SIG 
Tapes, but I'm very productive now.

The DECUServe Journal             January, 1993                       Page  30

    
>C is a horrible choice for our shop, since we mostly use contract programmers 
>who are neither good, nor well disciplined.

    It's also a rotten choice for many of our programmers.
    
>later.  I find it amusing that an earlier note used a phrase like "code which 
>looks like PASCAL" to describe a good C coding style.

    Remember, the person who made that comment was George Merriman.  George 
has posted several notes on this system about how much better Pascal is than C.
    
>I also believe in the value of strongly typed languages, such as PASCAL.  
>Most people, and I am clearly one, have bugs in our code.  I like my computer 
>to do as much work as possible.  I much prefer having my compiler catch my 
>typoes to having my users catch my typoes because they ran a code path I 
>didn't completely test (since we can't test all code paths completely in 
>medium or large applications.)  

    If you like strong typing, you can pass your C code through Lint, or you 
can use C++.  But even strongly typed languages don't catch all your bugs.


(Furze:  Is anyone really serious about C?)
-------------------------------------------
    I suppose some might say the arguments presented border on political 
disagreement.  If so, then I have been a DECUserve-badgirl since we do not 
discuss/argue politics here.  But when it 'some-how' migrated to my WHO_AM_I 
note, I couldn't resist the temptation to respond.  You might say  "The devil 
made me do it."
    Since some people insist on treating this topic seriously (How can anyone 
take "C" seriously?) and sharing legitimate information perhaps the discussion 
belongs in a more meaningful conference.  If someone suggests a better home 
for it, I will do the move (and then try to keep my opinions on the subject to 
myself).


(Coy:  Languages are fair game)
-------------------------------


(Nagy:  My experience with C)
-----------------------------
    Take my comments here in context - I'm not a manager and have written only
a couple of pages worth of code in the last couple of years...
    I came to C from Fortran (one roommate accused me of speaking Fortran in my 
sleep - just to set the tone).  I did so in the context of the Fermilab 
Accelerator Control system.  Having just finished the central alarm processing 
system - a totally asynchronous, dynamic memory, queue-driven program handling 
heterogeneous data structures -- and written in Fortran, I was looking for a 
new language to provide data structures and better dynamic memory support 
(pointers basically).  In addition to Fortran, we had VAX Pascal V1 - a 
useless product for doing anything useful.  I considered Bliss (having been 
exposed to it in my dim dark undergraduate days) but the compiler cost was 
more than twice that of VAX Fortran.  Just at this time, Digital came out with 
VAX C and I jumped on that.  It solved my problem and was an easy transition

The DECUServe Journal             January, 1993                       Page  31


(I was already familiar with C but hadn't written any) in that I could get 
"down and dirty" when I needed to; Pascal, on the other hand, restricted me to 
such an extent that I was unable to call system services and RTL routines I 
needed.
    Since then, we've used C as a major implementation language at Fermilab.
The new EPICURE beam line control system is mostly written in C, at least for 
the support subsystems and such.  The applications programs are written in a 
mix of C and Fortran (a particular program is in one or the other language).
    I've really had little problem reading my own C code.  Others have since
taken over my code with few problems.  I do extensively comment my code (as I 
write it, not afterwards).  This is especially true of any tricky code 
(written for the sake of run-time efficiency) which usually has a large 
comment block preceeding it telling the reader what I've done.
    In summary, I've found C to be productive for me and not a burden for
people taking over my code.


(Hassinger)
-----------
    I'll bet you wrote good, understandable FORTRAN code.  With that discipline 
as your background, I think it is far more likely that you would tend to write 
clear, understandable C.
    I think there are really two problems with C.  One is that it makes it too 
attractive and easy to write dense, obscure, tricky code.  The other is the 
culture that has grown up around the language that seems to perpetuate and 
encourage that kind of code.
    FORTRAN II was not very "powerful" (I know, I used it with punch cards and 
on a 4K PDP-8!), but modern Fortran is really quite powerful, particularly in 
it's VAX/VMS incarnation.  In fact, I will argue that it is at least as 
"portable" as C.  In its standards compliant form it includes effective I/O as 
well as the rest of the tools you need.  Because it has been in place and 
_standardized_ for a long time, there are many standards compliant, solid 
compilers available on nearly all platforms.  Indeed, modern OS's are designed 
to accommodate the needs of Fortran I/O.  This is not so true for C (note 
VAX/VMS C and its less than satisfactory RTL and accommodation to the VMS 
environment for example).
    In just about any compiled language comments cost nothing in execution
performance.  Source formatting designed to reveal the structure and flow cost 
nothing in execution performance.  And typically, expressing the program as a 
series of simple steps rather than folding as much as possible into one 
complex statement cost very little at execution time.  These principles apply 
equally well to FORTRAN, C, Macro and just about every other language.


(Mayhew:  Historical perspective on portability)
------------------------------------------------
    Several comments appear in [earlier replies] indicating that C 
gave birth to UNIX.
    Not so.
    UNIX was originally born on the PDP-7 and -9 (in 1969-70, for those of you 
who think UNIX is newer and therefore better than VMS).
    The PDP-11 version became operational in February, 1971 on the PDP-11/20.
    The third version ran on other PDP-11s and used memory management.
    In the summer of 1973, the first licensed installation of UNIX, using this 
version, was installed outside the Bell System.  I did the installation, along 

The DECUServe Journal             January, 1993                       Page  32


with a colleague named Brent Byer.
    C was developed for the PDP-11 in 1972.
    Version 4 was the first version written in C.  It was written during the 
summer of 1973 at Bell; we installed it late that year.
    This history (documented, in addition to my memory, in "The UNIX 
Time-Sharing System", Bell System Technical Journal, July-August 1978) also 
demonstrates that portability was not the original goal of UNIX.  In fact, 
Dennis Ritchie, one of the originators of C, states as much in his paper, "A 
Retrospective", in the same journal: "An extremely valuable, though ORIGINALLY 
UNPLANNED, benefit of writing in C is the portability of the system."
    The first known ports of UNIX were to a virtual-machine partition under
VM/370 on an IBM System/370 in 1976-77, to an Interdata 7/32 at the University 
of Wollongong in Australia in approx. 1977-78, and to an Interdata 8/32 at 
Bell in 1977-78.  Thus the first portability exercises for a system that is 
said to be so portable were not completed until nearly a decade after the 
system was introduced, 4 years after it was first publicly available, and 5 
years after the ostensibly-more-portable-than-anything-else C language was 
developed.
    We now return you to your regularly scheduled program. ;-)


(Schenkenberg:  Vindicated at last!)
------------------------------------
    Thank-you for setting it straight!
    And... As somewhat the perpetrator of this whole thread... I am amazed to 
see that what was originally intended as "let's poke fun at C" humor has turned
into such a sensitive (to some) topic.
    I find it rather entertaining!!!  Keep it up!


(Holdrege:  Fascinating history)
--------------------------------
>UNIX was originally born on the PDP-7 and -9 (in 1969-70, for those of you who 
>think UNIX is newer and therefore better than VMS).
    
    Interesting! What language was it written in? Macro 7?


(Mayhew:  A little more history)
--------------------------------
>Interesting! What language was [original UNIX] written in? Macro 7?
    
    C evolved from BCPL and from the language B, which Ken Thompson wrote in 
1970 for early UNIX systems on the PDP-7 and -11.  B did not last long.  
Neither B nor C are dialects of BCPL, so perhaps "evolved from" is too strong, 
but they share a number of attributes with it.
    The B compiler ran in fewer than 4K 18-bit words on the PDP-7 and was
limited to word-access to memory -- but in that era there was not yet a
standardized notion of "byte" and memory was commonly measured in words.
    (Above from "The C Programming Language" in the same edition of the Bell 
System Technical Journal, written by Dennis Ritchie, S.C. Johnson, M.E. Lesk, 
and Brian W. Kernighan.)
    The "UNIX Time-Sharing System" paper mentioned earlier states that early 
versions were written in assembly language, until 1973 when it was rewritten 
in C.

The DECUServe Journal             January, 1993                       Page  33


    As late as at least 1977, the UNIX kernel consisted of about 10,000 lines 
of C and 1,000 lines of PDP-11 assembler (NOT Macro-11 btw, but a simple 
assembler called "as"), about 200 lines of which were for efficiency's sake 
and 800 lines to perform hardware functions not possible in C (e.g. executing 
various memory management hardware instructions that don't exist in the C 
language).  [Ref: "UNIX Implementation" by Ken Thompson in the same issue of 
the BSTJ.]


(Luce:  "FORTRAN 77, the only true universal assember")
-------------------------------------------------------
>FORTRAN II was not very "powerful" (I know, I used it with punch cards and on 
>a 4K PDP-8!), but modern Fortran is really quite powerful, particularly in 
>it's VAX/VMS incarnation.  In fact, I will argue that it is at least as 
>"portable" as C.  In its standards compliant form it includes effective I/O 
>as well as the rest of the tools you need. 


(Nagy:  Today's VAX Fortrn much, much better now!)
--------------------------------------------------
>>Frank,
>>  I'll bet you wrote good, understandable FORTRAN code.  With that
>>  discipline as your background, I think it is far more likely that you would 
>>  tend to write clear, understandable C.

    Thanks for the compliment, the poor ego needs all the egoboo it can get
(egoboo == ego boost).

    One amplification of my previous comment.  That project would be a lot
simpler to have done in C, but could also be done in today's VAX Fortran almost 
as easily.  The reason is, of course, that modern Fortran now provides 
flexible definition and manipulation of heterogeneous data structures 
(STRUCTURE and RECORD statements).  The only tricks I would need to use 
concern the use of dynamic memory and this would be easily accomplished with 
%VAL statements.


(Bowler)
--------
>(egoboo == ego boost).

    I thought EGOBOO would have meant "Boot from device EGO"  :-)


(Nagy:  Do that other funny thing you do...)
--------------------------------------------
>>I thought EGOBOO would have meant "Boot from device EGO"  :-)

    Nah, that would have to be "BOO EGO".  Besides, one never boots from the 
EGO, one always boots from the ID.


(Patteeuw)
----------
    Interesting topic!
    I haven't had the chance to "plow" through [the earlier replies] but I too 

The DECUServe Journal             January, 1993                       Page  34


must admit that I'm not a C lover!
    In our area of the company some people (including myself in the past) must 
maintain assembly language programs that are several thousand lines long 
(automotive electronic fuel injection).  Management has a big problem in 
hiring (either as full time employees or as contractors) people who are 
competent assembly language programmers (especially for Intel 8096).
    We are moving to a new CPU architecture and part of that move will include 
using a high level language.  The "company" made a decision to use C without 
investigating any other languages (Ada may have been a good alternative, but 
we'll never know).
    "Management" likes C because "lots of people know it", and this is exactly 
what scares me !  I don't care how many 19 year old have written how many 
Windows Apps using MicroSoft C or Borland C, I want programmers that are 
experienced in Real Time Embedded Controls and know how to write structured 
code that is easily maintainable.
    Notice I didn't say that this couldn't be done in C, just an observation 
that most C programmers I have talked are NOT experienced in my type of 
application.  I would expect that most Ada would be experienced in RT EC.
    Also most C programmers I have met, seem to have the "UN*X" attitude that 
"I can hack something together with awk and grep and yacc to do that for you 
real fast"  (where did I see that description of C programmers being like pick 
up trucks with a bunch of tools bouncing around in the back).  These solutions 
are usually not easy to maintain.


(Burnet:  Yikes)
----------------
>We are moving to a new CPU architecture and part of that move will include 
>using a high level language.  The "company" made a decision to use C without 
>investigating any other languages (Ada may have been a good alternative, but 
>we'll never know).

    I can just imagine what a conversation with a Ford dealer might have been 
like, circa 1997:  "Yes, not only does this new model have all the latest 
computer-controlled dashboard features and efficiency monitoring, but you can 
also plug in your PC to access the 16-megabyte Ada run-time library in ROM!"


(Snyder:  Picking on C?  You nuts?)
-----------------------------------
    Sigh. I'm a relatively experience C programmer who has NEVER worked on a 
UNIX platform.  C, like any other language, can be written well or poorly.  
Make sure when Ford hires their programmers that they don't hire those 19 year 
olds you mentioned. An experienced programmer will write legible, 
easily-maintainable code. How much of that assembler language code was easily 
maintainable?  Almost all of it, IF it was written by a knowledgeable 
programmer.  And maintained by same.  So quit your griping and start coding! ;-}


(Steffen:  The Future Past)
---------------------------
>I can just imagine what a conversation with a Ford dealer might have
>been like, circa 1997:  "Yes, not only does this new model have all

    Might have been in like in 1997... You have read "The Restaurant At The

The DECUServe Journal             January, 1993                       Page  35


End of the Universe" too many times or will have been reading too many
times. 

>the latest computer-controlled dashboard features and efficiency
>monitoring, but you can also plug in your PC to access the 16-megabyte
>Ada run-time library in ROM!"

    How does the DoD do RT EC with Ada? Or isn't Ada being used in that way?


(Kilgallen:  In support of higher level languages)
--------------------------------------------------
    Of course I am a Bliss-bigot when it comes to lower level languages, but
I think the real answer to long-term maintainability is the use of higher level 
languages.
    I have a lot of experience revisiting code which has been written years
ago -- by me.  Maintaining a Pascal or Ada program correctly is _much_ easier 
than a program written in Bliss, Macro or TECO.  The compiler is able to alert 
you about many errors which would be "legal" in lower level languages.
    Additionally, high level languages are much better for those who switch
languages.  The chances that "thinking in another language" will result in an 
error-free compile is much lower.


                  Needed - REGIS-capable Terminal Emulator
                  ----------------------------------------

        The following article is an extract of the DECUServe Unix_Os
        conference topic 100.  This discussion occurred between July
        31, 1991 and August 2, 1991.  This article was submitted for
        publication by Jeff Killeen, DECUServe Contributing Editor.
        Ed.

By Dale Coy, Richard DeJordy, John McMahon, Terry Kennedy


(Coy)
-----
    My boss now has a MIPS box on his desk.  He _used_ to be able to use his 
PC to acces the VAX, and get graphics output on his screen from an
application that uses DECGraph.  That was because REFLECTION knows how to do 
REGIS.
    Now he is in the situation where the VAX knows perfectly well that he
doesn't have a REGIS-capable terminal.  So he can't get graphics.
    Is there a "terminal emulator" for UNIX that will run over TCP/IP and will 
do REGIS?


(DeJordy:  DECterm?)
--------------------
    I would think you should somehow be able to get a DECterm window open over 
TCP/IP that will support ReGIS....



The DECUServe Journal             January, 1993                       Page  36


(Coy:  Somehow?)
----------------
    I guess I need some education (guess?).  This is a MIPS box running MIPS 
software.  Are you saying I can get DECTerm to somehow run on it?  If so, that 
would be an ideal solution.


(McMahon:  Xwindows!)
---------------------
    Well, I have never seen a MIPS box... however...  If you can get the MIPS 
to run Xwindows, and you have TCP/IP on the VAX you can do the following:

    1)  On the MIPS, authorize (via XHOST) the VAX to be able to open
        windows on the MIPS.
    2)  On the VAX, issue a SET DISPLAY command... /TRANSPORT=TCPIP
        /NODE=mips-node-name
    3)  On the VAX, issue a CREATE/TERMINAL

    Hope this helps...


(Coy:  Who would have looked at CREATE?)
----------------------------------------
    It is running Xwindows (it says).  Slowly (but that's another story).
    Well, I knew about SET DISPLAY.  Useful for lots of stuff on my
VAXStations.  I had played around with it a bit this afternoon, with no
success.  The missing hints were:
    
> 1)  On the MIPS, authorize (via XHOST) the VAX to be able to open
>     windows on the MIPS.
> 3)  On the VAX, issue a CREATE/TERMINAL
    
    I'll let you know how it works.


(Coy:  Almost?)
---------------
    Well - 
    I did all of that, as suggested.  No errors on the XHOST or the SET DISPLAY.
    
    CREATE/TERMINAL
    
    Outer space for about 2 minutes (The VAX had obviously done something
and was waiting).  No visible effect on the MIPS (that is, no new windows).
    Finally, 
    	NONAME message   Message number 02DBC002
        System-F-IVLOGNAM, invalid logical name
    
    Any clues as to where I should look?  Or how to diagnose?  It looks very 
much like it's _trying_ to _almost_ work.


(Kennedy:  How about this?)
---------------------------
    Sounds like a problem translating DECW$DISPLAY. Try adding /PERM and
/EXECUTIVE_MODE to your SET DISPLAY/CREATE command and try again.

The DECUServe Journal             January, 1993                       Page  37


(Coy:  Making progress - but no cigar)
--------------------------------------
    That changes the behavior.  It used to take about 2 minutes to come back 
with the 02DBC002 message.
    It now takes about 4 minutes to come back with a 02DBC072 message.
    BTW - I can telnet in using a VAXStation and do the commands suggested
before (without /perm/exec), and it brings up a DECTerm window on the
VAXStation just *FINE*.  Seemingly proving that the problem lies somewhere in 
the MIPS box.  [Thanks, folks - at least I can now do it on my VAXStation 
using TCP/IP if I need to]
    Question: The XHOST command being used on the MIPS (per local advice)
is 
    	XHOST +
which, we are told, should allow "anything".  Should I be suspicious of that?  
(other than the fact that I suspect "everything")?
    

(McMahon:  Can't Open Display)    
------------------------------
>   I did all of that, as suggested.  No errors on the XHOST or the SET DISPLAY.

    FYI: SET DISPLAY has no error checking...

>Finally, 
>     NONAME message   Message number 02DBC002
>     System-F-IVLOGNAM, invalid logical name

    *Sigh* Typical DECwindows...

Message File: SYS$COMMON:[SYSMSG]DECW$TERMINALMSG.EXE;1
---> %DECW-E-CANT_OPEN_DISPL, Can't open display

    Which isn't a very descriptive error.  I am assuming this is your MultiNet 
VAX.  If it is, and you are running V3.0 try the following command:

	MU X11DEBUG/LOG

It will try to diagnose the problem for you.


(McMahon:  A very, very long note that will save the Bacon)
-----------------------------------------------------------
    FYI:  SET DISPLAY creates a logical name DECW$DISPLAY which points to a 
WSA device.  Typically this logical is in the Job or Process table.  It is a 
good idea to do a SHOW DISPLAY when debugging a DECwindows problem to make 
sure that the logical exists in the same context where you are issuing the 
command.
	
>It now takes about 4 minutes to come back with a 02DBC072 message.

Message File: SYS$COMMON:[SYSMSG]DECW$TERMINALMSG.EXE;1
---> %DECW-E-TIMEOUT_CONTROL, Timeout waiting for DECterm controller to start

    One of the more annoying DECterm errors...
    The way DECterms work is a "Controller" process is established as a 
multiplexer between the network and the user processes.  This controller 

The DECUServe Journal             January, 1993                       Page  38


process is running the image DECW$TERMINAL and typically has the process name 
of DECW$TE_X.  It communicates to the user processes through a psuedoterminal 
device.  The user end is TWDRIVER, the controller end is PYDRIVER.
    Anyway, what has happened here is that your terminal controller tried to 
start up and crashed.  A method of debugging it is to do the following:

$ SET DISPLAY /TRANS=TCPIP/NODE=foo/CREATE
$ SPAWN/NOWAIT RUN SYS$SYSTEM:DECW$TERMINAL ! Start the controller as a 
                                              subprocess
$ CREATE/TERMINAL

    Now watch for errors.  I'll bet that the Controller subprocess crashes 
after a complaint about missing fonts.

    Three ways to solve this...

1)  Modify the resource files to force DECterm to use fonts that you know 
    the MIPS box has.  This works most of the time but is totally unsupported
    :-)

	Create a file SYS$LOGIN:DECW$TERMINAL.DAT containing:
	#
	# Large font search list
	#
	*bigFontSetName:    -*-*-*-*-*--24-*-*-*-c-*-*-*
	#
	# Small font search list
	#
	*littleFontSetName: -*-*-*-*-*--14-*-*-*-c-*-*-*

    This particular file tells the Xserver to choose a non-proportional font
    (the "c") in either 24 point or 14 point depending on the "Big/Little Font"
    switch.  All other font criteria is wildcarded.

2)  Take the FONTS.ALIAS file from DECW$EXAMPLES and FTP to the MIPS box.
    Merge this file with the fonts.alias file on the MIPS.  This will map 
    the Digital specific font requests to MIT equivalents.  This is probably
    your safest bet.

3)  Get copies of the DEC fonts, FTP them to the MIPS and install them.
    This (probably) costs a lot of money.

>   XHOST +
>which, we are told, should allow "anything".  Should I be suspicious of that?  

    Suspect everything...  that is about the only problem with "XHOST +".

    Some potentially good references on this material:

VAX Professional (V13 #2 - April '91)  "A Remote DECterm Client and Server"
 By: John McMahon


The DECUServe Journal             January, 1993                       Page  39


Atlanta Spring 91 DECUS:  Session GR001/UN123 "Customizing DECwindows
 Applications via the DECW$*.DAT files" By: John McMahon

Atlanta Spring 91 DECUS:  Session GR032 "Can't Open Display:  Debugging X
 Transport Problems" By: John McMahon

Atlanta Spring 91 DECUS:  Session UN(I Forgot) "DECwindows on Non-DEC
 Equipment" By:  John McMahon

    Obviously, I have a vested interest in the VAX Pro Article...


(Coy:  OK)
----------
    Thanks, John.  We'll try this Monday (my boss has already gone home, and 
I'm half-out-the-door).
    
>FYI:	SET DISPLAY creates a logical name DECW$DISPLAY which points to a WSA
>	device.  Typically this logical is in the Job or Process table.
    
    Yep.  All of the fine references you folks pointed me to helped out.   I've 
been using SHOW DISPLAY every time (in debugging-mode, check _everything_ 
- and then verify it).


                      Can a Process Use 2 or More Pagefiles?
                      --------------------------------------

        The following article is an extract of the DECUServe VMS
        conference topic 1159.  This discussion occurred between
        November 13, 1990 and November 17, 1990.  This article was
        submitted for publication by Jeff Killeen, DECUServe 
        Contributing Editor.  Ed.

By Ernest Bisson, Linwood Ferguson, Stuart Fuller, Dan Esbensen, Ed Bailey,
Seton Droppers, Pat Scopelliti


(Bisson)
--------
    Can a process have virtual pages reside in 2 or more pagefiles or must 
they all be in the same one?
    Many moons ago I thought I had read that under VMS V5.x this was true, but 
I can't find the reference to it. Am I dreaming?
    I ask this because we are getting "page file badly fragmented" problems on 
our Vaxstation II. It has a primary pagefile of 2000 blocks on the system disk 
and a secondary one of 20000 blocks on another disk. I have seen the primary 
file go to 0 free pages, while the secondary file still has several thousand 
free.  If the above is true why should we get this error?


(Ferguson:  Install pagefile early)
-----------------------------------
    I don't know the answer to the real question, but have a suggestion.  Are 
you installing the pagefile very early in the boot process?  If you wait until 

The DECUServe Journal             January, 1993                       Page  40


alot of the overhead processes start, they might be consuming the only 
pagefile at the time.


(Fuller:  Nuke the small pagefile)
----------------------------------
    You'd be better off to not bother with the 2k pagefile on the system disk, 
and just use the 20k pagefile on the other disk.  Just make sure the 20k 
pagefile is installed in SYPAGESWAPFILES.COM (or however it's spelled).  This 
is as I understand it from VMS Engineering.  I don't recall the details, but 
it has something to with the processes that get started up early in the 
system's life all mapping to the small pagefile. 


(Esbensen:  Check out "Reserve page count" parameter)
-----------------------------------------------------
    There is a "special" sysgen parameter for controlling when VMS moves
pagefile allocation information to a new pagefile.  The name of the parameter 
is something like "RSVPGCNT"...anyway, the REAL name can be seen by:
    
       $ mcr sysgen
        sysgen> show/special
             .
             .  the last parameter on the screen is the one I mentioned
             .
    
    The CURRENT value will be 2048...(decide which pagefile to use next every 
2048 pages for a given process).  Change this value from 2048 to 512... and 
VMS will do a much better job of "guessing" which pagefiles to use.
    

(Bailey:  I'd go the SYPAGSWPFILES.COM approach...)
---------------------------------------------------
    Neat info, Dan.  My personal preference tends towards nuking the small
primary on the system disk, however.  Here's how to do it:
    
    Edit SYS$MANAGER:SYPAGSWPFILES.COM to perform the following tasks:
    
    o  Check to see if the drive holding your page (and optionally swap) files 
       exists.  This is probably not necessary for any system that is *not* 
       part of a cluster (clusters need this check because the CONFIGURE 
       process was *just* started prior to running this command procedure, and 
       it takes a while to find things like HSC-connected drives).  If the
       drive isn't there yet, wait a while and try again...
    
    o  Mount the desired drive(s).  Probably want to have some error checking 
       and retry logic here as well...
    
    o  Issue the necessary SYSGEN commands to get your page/swap files 
       installed.  Make sure it worked correctly.
    
    o  If any of the above steps failed, or the SYSGEN parameter STARTUP_P1 is 
       equal to the string "MIN", attempt to install the pagefile 
       SYS$SYSTEM:PAGEFILE.MINIMUM.  (If you got here by errors, you probably 
       want to print out errors messages with bells, etc., and do whatever is 

The DECUServe Journal             January, 1993                       Page  41


       necessary to prevent your full production environment from coming up on 
       a wimpy pagefile...
    
    Then, create the appropriate files/directories on the appropriate drive(s), 
and rename SYS$SYSTEM:PAGEFILE.SYS to SYS$SYSTEM:PAGEFILE.MINIMUM.  Reboot, 
and you're in business!
    I hope I got the message across that this code should really be
bullet-proof, as if it fails, you aren't going to be able to get very far.


(Droppers:  Dump file can be used too)
--------------------------------------
    We use the dump file as an alternative "minimum" file.  This only works
if you have a dump file ;-).
    Don't forget the bells and whistles -- We print nearly three pages of xxx's 
in a row with the message about missing page/swap files.  You wouldn't believe 
how big a help this is when you boss is breathing down you back because 100 
users can't do anything...


(Bisson:  Where is RSRVPAGCNT documentation?)
---------------------------------------------
>                 -< Check out "Reserve page count" parameter >-

    Where is this parameter documented? I can't find it in the V5.0 SYSGEN 
manual.  Is it a new feature with V5.2? I didn't find any mention of it in 
the V5.2 New Features manual or Release Notes. Unfortunately, we don't get 
documentation updates for the manual set. It also doesn't appear with the 
SHOW/ALL command within SYSGEN, but does appear with SHOW/SPECIAL.

>    The CURRENT value will be 2048...(decide which pagefile to use next
>every 2048 pages for a given process).  Change this value from 2048 to
>512...and VMS will do a much better job of "guessing" which pagefiles to use.

    Anyway, I decreased it to 512 and about half of the primary pagefile is 
still free after reboot. Before the decrease next to nothing would be free. 
It seems this parameter also controls the amount of pagefile reserved for a 
process when it is created, as well as which pagefile to use. Is this true?
    I think I will get rid of the pagefile on the system disk [as suggested].
Does anyone see any problems if I also decrease RSRVPAGCNT to 512?


(Ferguson:  Only in the fiche, probably)
----------------------------------------
    SPECIAL parameters are generally not documented.


(Scopelliti:  Even KDBs take a while...)
----------------------------------------
>    o  Check to see if the drive holding your page (and optionally swap) 
>       files exists.  This is probably not necessary for any system that is 
>       *not* part of a cluster (clusters need this
    
    Oh yes, it _IS_ necessary!  We have an 8800 with three KDB50s and it takes 
a while for the second and third to finish initializing and recognize their 
attached disks.

The DECUServe Journal             January, 1993                       Page  42


    How long is "a while"?  Longer than it takes to get to the MOUNT command 
in SYPAGSWPFILES.COM; and shorter than it takes for you to login after system 
startup gets trashed, successfully mount the disk and wonder "Why does it work 
now?"  Yeah.. well, we all have our own set of scars ;-}


(Esbensen:  SYSGEN "help" tells about "special" parameters!)
------------------------------------------------------------
    $ mcr sysgen
    sysgen> help par rsvpgcnt
    
    The HELP file in SYSGEN most always has something to say...even about
"special" parameters!


(Ferguson:  So that's where they [some of them] are)
----------------------------------------------------
    Learn something new everyday.  However, at least on 5.3-0...
    They're not here.  They seem to be:
    
             SYSGEN> help par special etc.
    
    And RSRVPAGCNT isn't in there even then.  A few others are that I didn't 
know where documented, however.  The "Special_params" topic is underneath the 
"Params" topic, and at the bottom of a LONG list where I never noticed it 
before.


                            V5 Performance Slowdown
                            -----------------------

        The following article is an extract of the DECUServe VMS
        conference topic 1187.  This discussion occurred between
        December 13, 1990 and December 19, 1990.  This article was
        submitted for publication by Jeff Killeen, DECUServe
        Contributing Editor.  Ed.

By John Briggs, Saul Tannenbaum, Wayne Bruzek, Bob Graham


(Briggs)
--------
    We have a performance problem under VMS 5.2 on a VAX 6410, clustered.  
With two compute bound processes (one I/O every two seconds or so) running at
interactive priority, the rest of the users on the system get terrible response.
    I was able to reproduce the behavior by running two compute bound 
processes and setting up two user processes doing wild-card directories on one 
of our disks. ($ DIR disk:[*...]).
    Watching one of the users, I saw it at priority 4, computable most of the 
time (this is from $ SHOW PROCESS /CONTINUOUS).  
    The directory display would sometimes scroll at full speed and at other 
times slow greatly -- to about 25% of full speed.  I was able to restore full 
speed by increasing priority of the user process (thus discrediting any 
argument that the performance slowdown was based on locking contention).  I 
was also able to restore full speed by changing QUANTUM from 20 down to 2.

The DECUServe Journal             January, 1993                       Page  43

    At elevated priority, the simulated user processes would chew 16-20% of the
CPU each.  Without priority elevation, the two compute-bound processes would
consume almost 50% of the CPU each and the user processes got almost nothing.
    Can someone out there explain why this is happening?  Alternatively, just 
give me a feel for what I am giving up by reducing quantum to this level.  
Could I get similar effects by disabling the V5 scheduling algorithm change?


(Tannenbaum:  Scheduler preemption changed)
-------------------------------------------
    You are most likely suffering from a change in the scheduler preemption
algorithm. Somewhere in the early 5.n's, the scheduler was changed to require 
that, for process_1 to preempt computable process_2, process_1 would have to 
be 3 (?) priority levels higher.  Otherwise, it would wait for process_2 to 
come to quantum end (or otherwise go out of the computable state).
    Version 5.4 makes this priority difference settable through a system
parameter.
    This changed really killed sites that had (what they thought were) low 
priority batch queues (priority 3) that suddenly were hogging systems. In that 
case, the fix is easy; set the base priority of the que to zero or 1. 
    I'm not sure what I would do in your situation (if you can't lower the 
priority of the compute bound processes, that is). Lowering quantum step by 
step until performance is acceptable would be a good first start.


(Bruzek:  Between a rock & a hard place!)
-----------------------------------------
    Some while back, we lowered our batch que priorities to 1, and found that 
a batch job, while logging in, lost CPU with SYSUAF locked open, blocking other 
users from logging in, etc. CSC slapped our wrists, and told us to keep batch 
queues at 3!


(Graham:  patch the scheduler)
------------------------------
    I agree, it sounds like your problem is with the scheduler preemption
change that showed up in v5.2.  We had the same problem on our 8550.
    After asking around at a DECUS symposium, I finally found the DEC
developer that was in charge of that part of the scheduler.  He wasn't able to 
explain exactly why it should have behaved that way, but the patch that he 
gave me to the PROCESS_MANAGEMENT.EXE image to disable the preemptive boost 
did the trick.  When v5.3 came out, I had to change the patch a little to make 
it work (the table the patch zeroed moved by 1 page).
    I think I've still got the patch procedures somewhere (even though we've 
gone to v5.4, which make the preemption a SYSGEN parameter).  If I get a 
change to get back to my system,I'll try to copy the patches here.


(Briggs)
--------
    Thanks.  I'd like to give that a try.


(Graham:  v5.2 & v5.3 patches)
------------------------------
    Here's the patch for v5.2 [and the v5.3 patch].  Use this at your 
own risk.  And make sure you keep a copy of the original, unpatched

The DECUServe Journal             January, 1993                       Page  44


PROCESS_MANAGEMENT.EXE.  You'll want to put it back before performing any VMS 
updates.

|------------ v5.2 -------------|------------- v5.3 ----------------|

process_management.exe		process_management.exe
examine 3158:31d8		examine 3358:33d8
repl 3198			repl 3398
1fff				1fff
0fff				0fff
07ff				07ff
03ff				03ff
01ff				01ff
00ff				00ff
007f				007f
003f				003f
001f				001f
000f				000f
0007				0007
0003				0003
0001				0001
0000				0000
0000				0000
0000				0000
exit				exit
7fff				7fff
3fff				3fff
1fff				1fff
0fff				0fff
07ff				07ff
03ff				03ff
01ff				01ff
00ff				00ff
007f				007f
003f				003f
001f				001f
000f				000f
0007				0007
0003				0003
0001				0001
0000				0000
exit				exit
update				update
exit				exit


                       SYS$SETDDIR System Service Problem?
                       -----------------------------------

        This article is an extract of the DECUServe VMS conference
        topic 1236.  This discussion occurred between February 15,
        1991 and February 23, 1991.  This article was submitted for
        publication by Mark Kozam, DECUServe Contributing Editor.  Ed.

By Jean-Francois Mezei, Jamie Hanrahan, Stu Fuller, Chris Rhode, Jack Pattueew,
Larry Kilgallen

The DECUServe Journal             January, 1993                       Page  45


(Mezei)
-------
    Is there a known problem with the SYS$SETDDIR system service ?
    It seems to change the default directory, but not the default device.
    
    (eg: current directory:   USER1:[name1.name2]
         specify in SETDDIR:  USER2:[name3.name4]
    
    Result afterwards:  USER1:[name3.name4]

    Is there something I am doing wrong ? The status code returned from
SETDDIR is success. Is there a system service to change the default device 
also ?
    VMS 5.4 (no -1, that site doesn't feel it is important to install !).  The 
disks are shadowed on an HSC. the USER1 and USER2 are logical names.


(Hanrahan:  use logical sys$disk to define default device)
----------------------------------------------------------
    That's all it's supposed to do. 

>Is there a system service to change the default device also ?

    Not exactly.  What you need to do is redefine the logical name SYS$DISK.  
That's the "device" part of the "default device and directory".  


(Mezei:  Thanks for the hints)
------------------------------
    So, in essence, the equivalent of SET DEF is to 1- change the logical name 
SYS$DISK to point to the device in the target directory, and the call 
SYS$SETDDIR to change the directory portion.
    The VMS documentation should have a warning. I spent many hours trying to 
figure out why it didn't work. (by default, I assume problems are my fault...)
    Thanks for the hints !


(Fuller)
--------
    Well, the name of the service is "SET DEFAULT DIRECTORY".  It doesn't
claim to set the default device.
    However, you're correct in that the manual should have a mention (I would 
consider "warning" to be too strong) that one should also diddle with the 
SYS$DISK logical.


(Rhode:  I think SYS$DISK+SYS$SETDDIR is far from intuitive)
------------------------------------------------------------
    I didn't find it intuitive that one changes your default disk/directory by
calling a somewhat obscure RMS routine and redefining a logical name ...
especially after many months of experience exclusively with system service
calls (I wasn't smart enough to figure out that a set default function wouldn't
be a system service call, seemed at the time that you could do ANYTHING with
system services :-) Fortunately the first time I wanted to do this, I had
existing sample code to go from.  I -am- somewhat surprised that you didn't get
some sort of error out of SYS$SETDDIR ...

The DECUServe Journal             January, 1993                       Page  46


(Patteeuw:  DCL lets you SET DEF to a non existent directory !)
---------------------------------------------------------------


(Kilgallen:  It's a feature!)
-----------------------------

$ SET DEFAULT [VERY.OBSCURE.DEEPLY.NESTED.DIRECTORY.SPECIFICATION]
$ CREATE/DIRECTORY []

lets you perform the complicated typing just once.



                         How Are Quotas for STARTUP Set?
                         -------------------------------

        The following article is an extract of the DECUServe VMS
        conference topic 1300.  The discussion occurred between April
        8, 1991 and April 12, 1991.  This article was submitted for
        publication by Alan Bruns, DECUServe Contributing Editor.  Ed.

By Larry Stone, Stu Fuller, Terry Kennedy, Mark Hyde


(Stone)
-------
    Where does the STARTUP process (the one that runs STARTUP.COM at boot time) 
get its quotas. Is it the PQL_Dxxxx SYSGEN parameters?


(Fuller:  Yep)
--------------


(Stone:  Well I'm not so sure now)
----------------------------------
    If only what I'm seeing now would let me believe that. To fill in the story 
(now that I have time to write it :-) ), our SYSTARTUP_V5 invokes a command 
procedure that starts our primary application. This command procedure includes 
an RDO OPEN on the application's database. The RDO OPEN sometimes causes an 
RDB bugcheck (and yes that is sometimes as in not always).
    A review of the bugcheck dump indicates that the problem is "exceeded
enqueue quota." OK - I can deal with that - let's up ENQLM. But where?
    The bugcheck is even nice enough to tell you what the original quota for 
the process was - in this case it says 100. Well PQL_DENQLM is 60 and the 
SYSTEM account ENQLM is 20,000. WHERE IS THE 100 COMING FROM?
    Is this hard coded into the boot?
    I would expect the quotas to be the PQL_Dxxx parameters. If I understand 
things right, when the STARTUP process is created, VMS (such as it exists at 
that point) wouldn't even know where to find SYSUAF to get the SYSTEM account 
quotas.
    
    Details:
    VMS V5.3-1
    VAXcluster with two 8530s and two 3500s (the machines with the

The DECUServe Journal             January, 1993                       Page  47


    bugchecks were 1 8530 and 1 3500)


(Fuller:  What's PQL_MENQLM set to?)
------------------------------------


(Kennedy:  PQL's, mostly)
-------------------------
>Where does the STARTUP process (the one that runs STARTUP.COM at boot time) 
>get its quotas. Is it the PQL_Dxxxx SYSGEN parameters?

   It copies them from the "system PQL" area (per the listings for SYSINIT).
I'm unsure if they mean the _D's or the _M's. All quotas are created that way 
except for WSEXTENT (built from SYSGEN WSMAX) and WSQUOTA (built from
min[SYSGEN WSMAX, 64K-1]). That last bit seems to be recent (added in 1989).


(Stone:  4)
-----------
>What's PQL_MENQLM set to?


(Hyde:  fixed values)
---------------------
    At system boot time, the SYSINIT process creates the STARTUP process which 
executes the SYSTARTUP_V5.COM file and any other startup files specified in 
SYSMAN etc. When SYSINIT sets up the $CREPRC system service call to create 
the STARTUP process, it specifies *all* the limits and quotas for the process 
as arguments to the $CREPRC call. The values that it uses are values from a 
system data structure called PQL$AB_SYSPQL, the SYStem Process Quota List. 
These are hardcoded, fixed values.  I'm at home and don't have the list handy. 
They are defined in SWAPPER.LIS.


(Stone:  Sounds like I need to go detached or batch)
----------------------------------------------------
    So in other words, if something in SYSTARTUP_V5 needs higher quotas than 
these fixed values, I need to create a detached process or a batch job. Are 
there any other options?


(Hyde:  not really)
-------------------
    Just set the PQL_Mxxxx values to your needed values.
    Here's a more complete explanation. I just happen to have this handy 
because I had to write it up to explain some of the behaviour seen during 
MAILbus startup. Forgive the MAILbus specifics but the same kind of behaviour 
happens to other things as well.
    Maybe this can help clear up the mystery surrounding the use of PQL 
parameters. MAILbus requires that specific PQL parameters be set, but it 
has not been clear exactly how the PQL_Dxxxx values are related to or interact 
with the PQL_Mxxxxx values.
    (The following is adapted from the VMS Internals and Data Structures Book.)
    When a process is created, the system uses two tables in the executive to 
set up quotas for the new process: a minimum quota table and a default quota 

The DECUServe Journal             January, 1993                       Page  48


table. Each quota or limit in the system has an entry in both tables. The 
contents of the minimum table are determined by the SYSGEN parameters whose 
names are of the form PQL_Mquota-name; the contents of the default table are of 
the form PQL_Dquota-name. The following is a list of steps used to determine 
the value for each quota or limit during process creation.
    PQB = Process Quota Block, a temporary data structure used during process 
creation that holds various values that will be copied into the Process Header 
after the process has come into existence.

        1. The default (PQL_Dxxxxx) values are copied into the PQB as
           the initial values.

        2. If any quotas or limits are specified as arguments in the
           $CREPRC system service, (how this whole thing got started
           anyway), they are copied in the PQB, replacing the corresponding
           values from Step 1.

        3. Now, all values in the PQB are checked against the PQL_Mxxxxx
           values and forced to be at *least* the minimum. If the value at
           this point is already larger than the PQL_Mxxxx value then it is
           left alone.

        4. Sometime after this the process will come into being and the
           PQB values will be copied into the Process Header.

        5. If this is an interactive user process, the LOGINOUT image
           will run and copy the values for the quotas/limits from the
           SYSUAF record into the Process Header, overwriting whatever is
           there from the setup of the PQB.

    One of the questions then is why will the MAILBUS startup procedures 
sometimes complain about quotas and limits during a system boot but not when 
you manually run the startup procedures after the system is booted.
    At system boot time, the SYSINIT process creates the STARTUP process which 
executes the SYSTARTUP_V5.COM file and any other startup files specified in 
SYSMAN etc. When SYSINIT sets up the $CREPRC system service call to create the 
STARTUP process, it specifies *all* the limits and quotas for the process as
arguments to the $CREPRC call. The values that it uses are values from a 
system data structure called PQL$AB_SYSPQL, the SYStem Process Quota List. 
These values are hardcoded, fixed values (see SWAPPER.LIS sources).
    So in the scheme of things above, at Step 2, these values are supplied by 
the $CREPRC system service call, over-writing all the PQL_Dxxxx values from 
Step 1.  At Step 3, if the PQL_Mxxxx values are NOT set properly, the STARTUP 
process winds up with incorrect values for it's quotas and limits.  The STARTUP
process does not run as a user process and does not use Step 5 from above so 
whatever it has in the PQB at the end of Step 3 are the ones copied into the 
Process Header and in use while the startup procedures are running. When the 
MAILBUS startup procedures run, they use a DCL loop of F$GETJPI's to get the
current value of the quotas and limits that it cares about.  These are 
compared with the values coded into the procedure and can result in the 
infamous,

        "%MB-E-QUOLOW, The following quotas for MR....may be too low."

message. 

The DECUServe Journal             January, 1993                       Page  49


    For example,  the SYSPQL list has a value of 10 for ASTLM, but
MB$$MS_START.COM checks for a value of 24 or larger. Likewise for DIOLM, 
SYSPQL sets it to 10, MB$$MS_START.COM wants 18 or more.
    Later when you login as SYSTEM and execute the startup procedures you may 
not get message. This could be because of Step 5. When you logged in as SYSTEM 
the LOGINOUT image eventually ran and filled in the process quotas and limits 
from the SYSTEM account SYSUAF record. Normally, these are large enough to 
satisfy the MAILBUS startup procedures.
    So it is important that the PQL_Mxxxx values be set as required by MAILBUS. 
Most of the PQL parameters are DYNAMIC so it is tempting to set them on the 
fly, however you then find them changing back to their default values when you 
run AUTOGEN.  So it is also important that these be placed in MODPARAMS.DAT so
they will be set whenever AUTOGEN runs and consequently be set correctly for 
the next system reboot.


                  Can You Put OPCOM on a DECTERM/Noprocess?
                  -----------------------------------------

        The following article is an extract of the DECUServe VMS
        conference topic 1341.  This discussion occurred between
        May 25, 1991 and May 28, 1991.  This article was submitted
        for publication by Don Roberts, DECUServe Contributing 
        Editor.  Ed.

By Alan Bruns, Glenn Zorn, Ed Bailey


(Bruns)
-------
    I have a VT1200 and would like to bring up a DECTERM window, preferably
without a separate process attached to it, that would do nothing but display 
OPCOM messages.  I'd rather not reinvent the wheel, though.  Since this seems 
like such an obvious thing to do, _somebody_ out there has this already.  
Probably something like
    
    		1 Set up a /Noprocess DECTERM window
    		2 Set an AST from DCL to trap broadcast messages
    		  and redirect them to said window
    		3 REPLY/ENABLE
    
    Having "New Mail" notices mixed in doesn't bother me.
    Being rather frugal, I'd just as soon not waste a process to do this.  And 
it's rather tiresome to have to get up and go the 50' or so over to the 
console every time the printer doesn't have the sound of a "normal" message.
    I asked the DECwindows folks at DSNlink about this.  The first reply I got 
suggested that VCS would take care of this.  I was polite when I replied to 
that sillyness, and their second message contained a command procedure that 
directs OPCOM messages to the Session Manager window.  I'll probably fool 
around with that and see if it can be adapted to my purpose.  But if somebody 
out there has the code to do what I want you'll save me some trouble by 
posting it...



The DECUServe Journal             January, 1993                       Page  50


(Zorn:  Put it into the Session Manager window)
-----------------------------------------------
    Yes. Put it into your Session Manager window since that is used very little 
otherwise. The code below will do it if spawned from DECW$LOGIN.  (I got the 
code from Ed Bailey before he left CUC, hope you don't mind) (Before anyone 
comments on the date of this note: 1) I am oncall this weekend, 2) Our 
production cluster needs to be rebooted at midnight and I am coordinating the 
downtime)
    
$ !
$ ! DECwindows OPCOM Option...
$ !
$       SET PROC/PRIV=ALL
$       SET PROC/NAME="Xopcom"
$ !
$ ! Get the name of our session manager window...
$ !
$ GET_DEVICE:
$       DEVICE = F$GETJPI(F$GETJPI(0,"OWNER"),"TERMINAL")
$       IF DEVICE .NES. ""
$       THEN
$               WAIT 00:00:30
$               ASSIGN/USER 'DEVICE' SYS$COMMAND
$               REPLY/ENABLE
$               ASSIGN/USER 'DEVICE' SYS$COMMAND
$               REPLY/DISABLE=(SECURITY, CENTRAL, NETWORK)
$               EXIT
$       ENDIF
$ !
$ ! The session manager isn't there yet, wait and try later...
$ !
$       WAIT 00:00:10
$       GOTO GET_DEVICE


(Bailey)
--------
    No problem, Glenn; although I should be honest - I got this (if I remember 
correctly) from a DSNlink article.  I did massage it a bit, though...
    Seems like some things never change at ol' CUC, eh? :-)


(Bruns:  Did it myself.. code included here.)
---------------------------------------------
    OK, so I decided to try to do this myself.  About time I posted some code 
up here, anyway.
    This code will create a window /noprocess and direct OPCOM messages to it.  
It works fine on my VT1200.
    
$!
$!			O P C O M - W I N D O W
$!
$!	Hang a DECTERM window on the current process, and REPLY/ENABLE
$!	to send OPCOM messages to the new display.
$!
$!	DEALLOCATE OPCOM_Window to turn it off.

The DECUServe Journal             January, 1993                       Page  51


$!
$!	Alan Bruns  May '91
$!
$ CREATE/TERMINAL/LITTLE_FONT/DEFINE=(TABLE=LNM$Job,OPCOM_Window)-
   /NOPROC/WINDOW=(ROWS=5,COLUMNS=132,ICON="opcom",TITLE="OPCOM Window",-
   X_POSITION=5,Y_POSITION=800,INITIAL_STATE=ICON)
$ ALLOC OPCOM_window
$ DEFINE/USER Sys$Command OPCOM_window
$ REPLY/ENABLE
$ EXIT


                            Automatic Menu Startup
                            ----------------------

        The following article is an extract of the DECUServe VMS
        conference topic 1379.  The discussion occurred between
        July 15, 1991 and August 21, 1991.  This article was 
        submitted for publication by Jeff Killeen, DECUServe
        Contributing Editor.  Ed.

By Jack Harvey, Geoff Bryant, Michael Baydoun, John Osudar, Mark Shumaker,
Jon Jones, Dale Coy, Gary McCready, Chuck McMichael, Brian Tillman, 
John Burnet


(Harvey)
--------
    As we all know, SYLOGIN.COM runs before the user's LOGIN.COM.  This is a 
good place for the system manager to do things in the user's process that can 
be common to all users.  This paragraph is sort of to set your thinking frame.
    Now, how can the system manager get a command file, let's call it
SYLOGIN_2.COM to execute *after* LOGIN.COM?  It needs to do things after 
LOGIN.COM has altered the process environment and completed. (The case of a 
LOGIN.COM that never completes prior to logout probably isn't significant at 
this site.)
    Obviously, if LOGIN.COM itself executed SYLOGIN_2.COM, the problem is 
solved, but the system manager can't count on that happening.
    Any ideas?


(Bryant:  Try this...)
----------------------
    SYLOGIN_2 does:
    
        $ IF F$SEARCH("SYS$LOGIN:LOGIN.COM") .NES. "" THEN -
          @SYS$LOGIN:LOGIN
        $ POST_LOGIN_STUFF
    
    Then in SYSUAF don't point LIGCMD to LOGIN...


(Baydoun:  Heres a thought)
---------------------------
    How about renaming your all your users login.com files to something else, 
ie user.com.

The DECUServe Journal             January, 1993                       Page  52


    Then have sylogin.com do something like this:

    Run sylogin normal commands
    Figure out who the user is, process name maybe?
    @[user.directory]user.com 
    The rest of your post login.com commands
    
    As far as VMS is concerned, the user will not have a login.com.  You
probably do not even have to rename them, just go into authorize and modify 
LGICMD = (null).  The only difficulty might be determining who is logging in 
and what their directory should be, depends on your sites standards.


(Osudar:  null LGICMD won't do it?)
-----------------------------------
    Modifying LGICMD to be null won't work, as I recall; a null value causes 
LOGIN.COM to be executed from the user's default directory.  What you may want 
to do is set LGICMD to something like NLA0: instead.  Then have your SYLOGIN 
look for the user's LOGIN.COM, execute it, and do the post-LOGIN stuff.
    (The next question is, what will you do when your users want a LOGIN_2.COM 
to execute after your SYLOGIN_2.COM, so they can change some of the things you 
do there? :-)


(Shumaker:  Post-login may not run when expected)
-------------------------------------------------
    Well, you can plug something like SYS$SYSTEM:USER_LOGIN.COM into LGICMD in 
SYSUAF, and have USER_LOGIN look for a LOGIN.COM in the user's directory and 
execute it if there, then do your stuff (as in [the previous reply]); BUT, if 
the user's LOGIN.COM sets up some stuff and then invokes the program in which 
the user normally does his work (like a CAD system, for example), then your 
post-login commands won't run until the user leaves that program.  Would this 
be a problem?


(Jones:  The bratwurst approach)
--------------------------------
    We use SYS$SYLOGIN to point to those things that absolutely shouldn't be 
skipped, not even for a username/NOCOM.  We then point all the LGICMDs to 
another logical that "wraps" the call to LOGIN.COM within before and after 
commands (like the menu system).


(Harvey:  DECUServe Does It Again!)
-----------------------------------
    Thanks very much, people.  You have answered my question perfectly...
which really was, "Am I overlooking something?"  The somewhat bizarre notion 
(it seems to me) of perverting LGICMD had occurred to me.  My version was to 
have it *be* SYLOGIN_2.COM, with SYLOGIN.COM assigned the duty of executing 
SYS$LOGIN:LOGIN.COM, if found.
    That others might want such a feature seemed pretty obvious, and like so 
many things in VMS, it might already have been implemented, documented and 
then overlooked by me.  It seems that in this case, I managed to keep up.
    How come something like this hasn't been codified?  I expect John put his 
finger on it:


The DECUServe Journal             January, 1993                       Page  53


>(The next question is, what will you do when your users want a LOGIN_2.COM to 
>execute after your SYLOGIN_2.COM, so they can change some of the things you 
>do there? :-)

    VMS Engineering knows better than to go down that rat hole.


(Harvey:  Restated Problem)
---------------------------
    The system manager I have in mind is Dale Coy and the system is DECUServe.  
(This may be a surprise to Dale, but I doubt it.)
    We have been looking into ways to offer "options" to DECUServe subscribers 
that they can select or de-select as easily as clicking on a menu item.  The 
idea is to try to eliminate complex instructions such as "edit your login.com 
to include DEFINE BARF NEW_MAGIC to enable this dandy new service for you".   
Readers of this conference won't benefit, of course, but such an instruction 
upsets some, who reply: "But you don't have vi!  I *can't* edit login.com, 
whatever that is."
    Now, some options can be controlled in the grandly simplified manner I'm 
looking for without the postulated SYLOGIN_2.COM.  I expect enabling OneKey 
Noting will be offered without requiring editing in the future.  But how about 
a menu system itself?
    Suppose that the next time you log into DECUServe, Dale has converted it 
to Ultrix.  A few reading this might be comfortable or even pleased.  I expect 
the rest would be forming a lynching party.  No, it isn't about to happen. 
Although, come to think of it, there is an ominous announcement about 
something happening on July 26.  However, people with a strong taste for Unix 
probably have about the same reaction to DECUServe *now* as you might have on 
July 27. 
    So I'd like to be able to *offer* a $-free environment - where the
subscriber is swaddled in menus from start to finish, never having to try to 
guess what the magic DCL (or csh) command might be to accomplish today's 
objective.  (Please note I said OFFER, not establish, and a menu item would be 
an escape to DCL (or csh), if I still have any say in the matter.)
    So I am looking for a way to bridge the gap between the end of LOGIN.COM 
(which we can't control) and menu startup.  So let me rephrase the question:

    1. How can I get a menu scheme to start automatically on login without
    depending on login.com to do it?

    2. Is there anything really wrong with perverting LGICMD to do this as
    suggesting by earlier notes in this thread?


(Coy:  Who, me?)
----------------
    [Regarding question #2 above:]
    
    Nothing inherently wrong.  One caution: there are some subscribers on
DECUServe who (I believe) essentially give their Username and Password, and 
that's the last thing they do.  An automatic procedure takes care of all of 
their "work".  


The DECUServe Journal             January, 1993                       Page  54


(Jones:  Computing with a mixed bag of users)
---------------------------------------------
    We do this routinely.  We use identifiers with clever names like DCLUSER, 
MENUSER, CUSTUSER, MEN2USER to split the exection of the joint login file.  
So programmers get dropped to DCL, most users into generic menu system, 
customers into a specialized menu system, etc.  I don't find this a perversion 
of LGICMD any more that "IF F$MODE() .EQS. ..." is.
    With VMS 5.4, you can use f$getjpi to find out if an identifier is held by 
the process.  (Prior to 5.4, we used a special image.)
    Here, though, you'd probably want to make this user selectable, so you'd 
need some way for users to change their default identifiers.


(McCready:  Finding a pre 5.4 ID holder via DCL)
------------------------------------------------
    Pre-v5.4 I Kludged DCL - the only real trick is that the identifier has
to have the DYNAMIC attribute - the code follows:
    
    $saved_message=f$environment("MESSAGE")
    $set mess/noident/notext/noseverity/nofacility
    $saved_privs=f$setprv("NOCMKRNL")!have to turn off if present
    $                               !or else always returns "success"
    $set noon
    $set rights/enable 'id_to_check'
    $saved_status=$status
    $set message'saved_message'
    $set proc/priv=('saved_privs') !restore it if it was there
    $!
    $!if below is true then user had identifer granted to them
    $!
    $if  saved_status
    $       then enabled="Y"
    $       else enabled="N"
    $endif
    

(McMichael:  Grail?  We already got one!)
-----------------------------------------
>    1. How can I get a menu scheme to start automatically on login without
>    depending on login.com to do it?

    Our installation has set up command files to do that.  If you're 
interested, I can see about trying to upload them for your perusal.


(Harvey:  Yes!)
---------------
    Most certainly, if you have a improved technique over those already
discussed in this thread.

The DECUServe Journal             January, 1993                       Page  55


(McMichael:  They're here!)
---------------------------
    I've put the following files in USR_SCRATCH:[MCMICHAEL]

AAAREADME.TXT
MASTER_MENU.COM
MASTER_MENU_ITEMS.COM
MASTER_MENU_START.COM
MASTER_MENU_USERS.COM


(Harvey:  Concrete)
-------------------
    Hey, thanks, Chuck.  As I see it, your scheme works by having SYLOGIN
execute LOGIN.COM (if found) and then start a menu if appropriate for the 
username. 
    This is a very nice package, and I shall certainly study it for details
and to see how it handles things.  I snarfed a copy of it.  Thanks.
    However, what you have here is an essentially complete submission,
including the AAAREADME.TXT, for the DECUServe Tape Library.  Why not submit 
it?  It certainly has general interest.
    To find out how, type:  Notes> help decuserve tape
    
    It's fun!  :-)


(McMichael:  Try again.)
------------------------
    Thanks for the complement.  If I can find a way around the "feature" that
makes it execute LOGIN.COM whether or not a normal login would, I'll submit it.
    Also, for documentation purposes, can anyone say which version of VMS had
the session manager process of DECwindows change from "username_VUE" to
"username_SM"?


(Harvey)
--------
    Except for some trick accounts related to mail and not individuals, I
believe every account on DECUServe has LGICMD pointing to SYS$LOGIN:LOGIN.COM.  
So this is not an issue on DECUServe.
    What is an issue is that I'd like our menu (if it were to happen) to be
able to exit to the DCL prompt.  If the menu is running via SYLOGIN.COM, when 
the menu exits, SYLOGIN.COM exits, and then LOGIN.COM runs a second time.  
This creates a requirement that LOGIN.COM be able to do that safely.


(McMichael:  It's in there!)
----------------------------
    As you wish.  If you'll check the bottom of MASTER_MENU.COM, you'll see 
that in the case where P1 is true (which should only be at login) and 
LOGIN.COM was run, the procedure issues a STOP command to prevent LOGIN.COM 
from running again. The procedure also sets up the symbol MENU to reinvoke the 
menus without rerunning LOGIN.COM when the user gets tired of DCL. 



The DECUServe Journal             January, 1993                       Page  56


(Harvey:  STOP!)
----------------
    DECUServe does it again!  This never occurred to me.  If SYLOGIN.COM ends 
with a STOP, the LOGINOUT image is what stops, right?  That prevents whatever 
is being pointed to by LGICMD from being executed.  We don't have to point it 
to the null device or other strangeness.
    I *think* this solves all the problems I have been concerned about for this 
particular application.
    Now, Chuck, if I give you a program to define a DCL symbol containing
LGICMD, will that solve your problem?  :-)


(McMichael:  Serendipity)
-------------------------
    Strangely enough, the latest VAX PROFESSIONAL has an article dealing with 
$GETUAF.  I'll get back to you folks in a week or so.


(Harvey)
--------    
    Two versions of this have been submitted to the librarian.


(Tillman:  Doesn't STOP just terminate the current command procedure?)
----------------------------------------------------------------------
    Jack, I don't think that having STOP in SYS$SYLOGIN stops LOGINOUT. 
According to the documentation (HELP) for STOP, having STOP merely stops the 
command procedure containing it.  Did you test to see in, in fact, LOGINOUT 
does stop?


(Burnet:  No but yes)
---------------------
    Right -- at the point the SYLOGIN procedure runs, LOGINOUT.EXE has already
passed control to DCL, so the STOP has no effect on it.  In any case, if DCL 
is interpreting a command procedure, then (almost by definition) no image is 
active except the ones that the command procedure invokes.
    However, putting the STOP in the SYLOGIN procedure does prevent the user's
LGICMD from being run, so this story should have a happy ending.


(Harvey:  Needs more investigation...)
--------------------------------------
    Brian, I didn't test it exhaustively, but I did find out that a command 
file pointed to by LGICMD doesn't execute. That's just not a full answer.  


(McMichael:  Full STOP)
-----------------------
>According to the documentation (HELP) for STOP, having STOP merely stops the 
>command procedure containing it.

    And in the case of nested command procedures, it stops all the levels 
above it.



The DECUServe Journal             January, 1993                       Page  57


(Harvey:  Clarification)
------------------------
    Brian Tillman, former MoS here, has been jostling my elbow. :-)
    I may have implied earlier that on DECUServe, LGICMD contains
SYS$LOGIN:LOGIN.COM.  (Because I thought it did.)
    In fact, it's blank.  Loginout (or whatever) executes
SYS$LOGIN:LOGIN.COM by default for normal accounts.
    I also want to assure people that we aren't thinking of *requiring* that 
they keep a login.com file.  My whole concern has been to be able to offer 
options such as an automatic menu with minimum or zero impact on users.


(McMichael:  Revised Standard Version)
--------------------------------------
    The revised version of MASTER_MENU is now in USR_SCRATCH:[MCMICHAEL]
This one uses MM_LGICMD.EXE to compute the login command file name.

There are two files you need

MM.TLB text library containing
        AAAREADME.TXT
        MASTER_MENU.COM
        MASTER_MENU_ITEMS.COM
        MASTER_MENU_START.COM
        MASTER_MENU_USERS.COM
        MM_LGICMD.EXE
        MM_LGICMD.FOR
        MM_LGICMD.LIS
        MM_LGICMD.OBJ
EXTRACT_TLB.COM to decompose the text library

    [Editor's note:  If you are interested in a copy of the files mentioned
in this article, try looking in the DECUS Library Tapes, or on the DECUShare
CDROM library.]


                            Collected Notes on VMS 5.5
                            --------------------------

        This article is an extract of the DECUServe VMS
        conference topic 1800.  This discussion occurred between
        July 7, 1992 and August 7, 1992.  This article was 
        submitted for publication by Pierre Hahn, DECUServe
        Contributing Editor.  Ed.

By Chris Rhode, Don Roberts, Mike Mattix, Tyler Mainquist, Matt Rollinson


(Rhode)
-------
    The following was compiled from DECUServe, and other sources.  References 
to DECUServe VMS conference note numbers are in [] at the end of bulleted 
items.  I worked forward mid-June from 1604.x in the VMS conference to compile 
this (there may be material from earlier than that because I also used notes 
taken from DECUServe, USENET, our LUG etc. over the past few months which are 
not always great in pointing out where the material came from :-)   I reviewed 

The DECUServe Journal             January, 1993                       Page  58


the source material with an eye towards items of interest to our site, and 
thus may have omitted certain areas (such as DECwindows, problems discovered 
with unsupported areas of VMS, etc.).  These notes are not guaranteed to be 
accurate (though I put some effort into proofing the stuff I drew from 
DECUserve, which is the vast majority of the material) or complete.  You can 
use the note number cross references to get more detail on things you are 
concerned about or don't believe -}.  Your mileage may vary.
    I hope this is useful to somebody ... I put it together for somebody that 
was thinking about upgrading to 5.5.  I think some of this material will be 
useful even for people going to 5.5-1 or beyond ...
    If anybody reads this and can point out inaccuracies, provide new details,
etc., please do ...

o If you are running LAT get the latest version of patch kit 0511 (V3.2 or
    later) and install it ASAP after the upgrade.  There were also separate
    ECOs (#1 and 2) for LATSYM in conjunction with V3.0 of this patch kit,
    find out if they are needed. TEST LAT SERVER ALL may crash the
    system even under latest patch revs.  [1699.13, 1725.4, 1657.0 etc.]
o STOP/NEXT on a queue follow by START on that queue is broken in that
    the queue must actually stop fully before START will work.  Change in
    behavior. [1604.51]
o The queue manager data files are not properly saved as part of a BACKUP
    operation, even under standalone backup.  Backup and restore of a 5.5 
    system disk will result in lost queue information.  Workaround: stop the 
    queue manager, do backup, then restart 
    the queue manager.  [1604.59, .64, .76 etc.].  [Note: it's never been 
    "safe" to try to backup the queue files with the queue manager running, 
    but now it appears you have NO chance of recovery, even from a 
    standalone backup.]
o Do NOT convert the queues as part of the upgrade procedure.  Just Say No,
    and after the upgrade run @SYS$UPDATE:VMS$UPGRADE_A55_V55 [1604.27]
o The VMS 5.5 upgrade procedure destroys the password history list file;
    preserve a copy of this file before the upgrade and restore it manually
    after the upgrade. [1604.1]
o Disks that go into Mount Verify may cause a system crash.  Fixed in 5.5-1.
    [1604.3]
o Pathworks for Mac V1.1 DAL will not work under VMS 5.5
o Pathworks for DOS V4.0 breaks under 5.5.  Get patch kit 3018, or wait
    for Pathworks V4.1.  Make sure you get a patch kit with a version of
    S4.0N or later. [1604.4, .5, .6]
o See Chapter 5 of the release notes, you must have the QMAN$MASTER logical
    name defined in SYLOGICALS before upgrading. [1604.23]
o MONITOR DISK/ITEM=QUEUE may be broken (only on SMP machines?) [1604.29]
o CPU limits will be ignored on batch queues [1604.31]
o If running DQS 1.2 get patch 0554.  The installation procedure for this
    patch may be buggy, there is a workaround [1604.41]
o See section 6.5 of installation guide, there is a mistake, SYSUAF must be
    in SYS$COMMON:[SYSEXE] [1604.44]
o Batch jobs present in queues and submitted with the /PRINT qualifier
    will be lost during the queue file upgrade. [1604.45]
o Carefully check the system date/time after each reboot during the upgrade,
    including after MUPs etc, it may drift by days or years.  Stop accounting
    and all queues before the upgrade and disable anything that might start
    them during the upgrade.  Fix the system time before restarting them
    and before installing layered products. [1604.45, .90, .91]

The DECUServe Journal             January, 1993                       Page  59


o Under VMS 5.5, one-to-one mapping of characteristic names to number is
    enforced.  A workaround exists [1604.46, .54]
o Apparently the queue manager is supposed to "remember" that it was started
    across reboots and restart itself on reboot (no more need for
    START/QUEUE/MANAGER in SYSTARTUP).  Actually this doesn't work. [1604.71]
o Queue manager may run out of virtual memory and die, corrupting your queue
    file. [1604.72]
o Get CSCPAT 1011 - patch for crash scenario (with locks?) [1604.74]
o Under VMS 5.5, there are changes in lock performance due to POSIX, ENQ/DEQ
    are 6% faster but CONVERT is 12% slower [1604.75]
o DELETE/ENTRY on a job that was submitted /NOTIFY will no longer send the
    "job deleted ..." broadcast message to the submittors terminal [1604.79]
o SET AUDIT/SERVER/NEW_LOG may result in a corrupted new audit server file.
    Get CSCPAT_0061. [1604.80]
o ANALYZE/AUDIT under VMS 5.5 does not handle some flavors of V5.4 audit
    records [1604.80]
o Force TMSCP_LOAD to 0 in MODPARAMS on nodes without local tape drives or
    on nodes where you don't want to serve the tape drives.  If you don't
    do this, you may get %TMSCPLOAD-E-SERVE_ERR errors on reboot, among other
    things.  You should force TMSCP_LOAD to 0 in the Standalone Backup
    parameter set.  See the VMS 5.5 Cover Letter. [1604.85, .86]
o You can't upgrade from 5.0 thru 5.3-n to 5.5 in a cluster.  There is a
    workaround [1604.88]
o If you are running ACMS, see DEC about a patch for a mailbox problem
    [1604.93]
o Possible problems upgrading from the InfoServer, with workarounds
    [1604.97, .99, .108]
o If non-Decwindows Debugger seems to want DECW$TRANSPORT_COMMON loaded, try
    installing the image manually.  DECW$STARTUP may have tried to do this
    and failed due to an exceeded quota (try increasing PQL_MBYTLM to 65000)
    or DECW$STARTUP may be partially or fully inhibited
    depending on system/startup configuration. [1604.104, .116, .117]
o There is a patch for 6610 systems, #1000, but it may cause "hideous
    performance loss" [1606.0]
o Read the New Features Manual for VMS 5.5 carefully, especially regarding
    the new batch/print queue system.  Also check out the new SET PREFIX
    command.
o CSCPAT_1012 for queue manager, get latest version.  Helps with but does
    not eliminate queue stalling problems. [1725.x]
o If running WordPerfect, get latest version/patch set from vendor
    [1706.x, 1725.5]
o Get CSCPAT_1101 for BACKUP, supersedes old _0101 [1734.0]
o If running DECserver 200s, get "BL37B" patch (talk to field service) [1737.2]
o Keeping times of cluster nodes in synch is now even more critical for
    queueing system, set up a procedure to do this several times a day.
    [1766.x]
o Check with DEC for latest news on 5.5 if you are an All-in-One shop,
    there are potentially major problems. [1604.44, .52 (background formatter),
    1757.4 (patch #1012 may fix)]
o Check with Multinet vendor ... patch needed ... 3.0 Rev H is okay
o If running a DEBNA get patch 0543
o A default LRPSIZE of 1504 is now okay
o Ignore p. 2-13 on increasing BYTLM by 320 for users if all users
    currently have over 10K BYTLM (which they should anyway).  A BYTLM
    of 20480 is a good number for most users. [1661.x]
o Custom print symbionts -may- break.  [1692.x]

The DECUServe Journal             January, 1993                       Page  60


o Check into patch 1001 for VERIFY utility
o A POSIX -license- is included with the VMS 5.5 license.  You must purchase
    a media kit.  Get POSIX patches, 1021.
o If you have a SYSMANINI file which includes a SET FILE/CLUSTER command, this
    may cause problems for AUTOGEN. [1579.0]
o Check into patch 0059 for TUDRIVER [1710.6]
o VPA becomes unsupported under VMS 5.5, use DECps instead [1604.44]

1604.44 - General warning about 5.5
1604.47 - ditto
1604.95 - good writeup on autostart queue mechanism
1604.96 - one site's project plan for 5.5 upgrade
1757.2  - list of patches
1757.3  - list of patches


(Roberts:  Thanks for compiling this Chris!)
--------------------------------------------
    Well, I just found out that some third party print symbionts will fail with 
5.5, and you need patches 1012 (listed before) and 1022 (not listed) to fix 
this.
    This looks like a very thorough list, Chris.  I just wish you had posted 
it two weeks ago, before I upgraded :-(


(Mattix:  I have not seen this mentioned before??)
--------------------------------------------------
    Just adding one thing.  Let's see if I can get this right...
    If you have a heterogenous cluster (more than one SYSUAF) and you convert 
to the new Queue system you will be in for a rude awakening.  It seems that the 
new Queue Manager looks for an entry in the SYSUAF.DAT on the node that starts 
the Queue Manager for any batch jobs submitted.  Even if the Queue the job is 
submitted to is running on an another node with a different SYSUAF.DAT file. 
This bit us this last weekend when merging two clusters into one.  One was 
5.4-2 and the other was 5.5.  DEC CSC claims this is the way it is planned to 
work and has no intention of fixing(??) it.  It has caused us to put duplicate 
entrie on the 6520 that is running the master queue manager for all accounts
on a VAX4300 running a totally separate application suite.
    This is obviously progress..


(Mainquist:  New (5.5) queue manager on heterogeneous cluster)
--------------------------------------------------------------
    The issue in [the previous reply] bit us hard, too, and we were told the 
same story: 

"The queue manager was not intended to support a heterogeneous cluster, and 
this has been true for quite awhile."

    At the time we had somewhere between 12 and 14 nodes in the cluster with 
about 5 different UAF environments.  We had the luxury of being able to choose 
which of the 5 UAFs to run on the queue managing node, so we took the one with 
the most users submitting jobs.
    BTW(1):  This affects more than just batch queues. We are running ALL-IN-1
and the jobs sent to OA$FORMATTER (server queue) were failing left and right 
after the 5.5 upgrade weekend.  Doesn't it report a "record not found" error 
or something like that?  I can't remember if straight PRINT jobs were affected.
    BTW(2):  If users choose to "correct" this situation by adding UAF entries 
on the queue managing node, the entries do not have to be "usable."  All that 

The DECUServe Journal             January, 1993                       Page  61


is required is that the queue manager process be able to find a (any) record 
for the user in its SYSUAF file.  You can make them DisUser, no privs, no 
access, etc., so set up a template account and UAF> COPY it.
    We had considered going back to the old queue manager, but the performance 
gains we experienced made the UAF effort WELL worth keeping the new.


(Rollinson:  v5.5, queueing and multiple uafs)
----------------------------------------------
    Some additional info on what we did on Mike's system.

1)  Tracked down usernames not on the Queue manager's node.
2)  Added all of those usernames regardless of original UIC to a single
    DISUSERed UIC.

    The queue manager just wants to see ANY record with the appropriate
username.  (At least on v5.5...)

3)  Started chewing on how we are going to combine UAFs and appropriately
    change our security scheme.


                   Control Over Scrolling Speed in DECterm?
                   ----------------------------------------

        This article is an extract of the DECUServe Workstations
	conference topic 204.  This discussion occurred between 
        March 13, 1992 and April 17, 1992.  This article was submitted
        for publication by Jeff Killeen, DECUServe Contributing 
        Editor.  Ed.

By Mark Katz, John Burnet, Jack Harvey, Bart Lederman, Eric Husby, Bill Mayhew,
Geoff Bryant, Jamie Hanrahan, Duncan Brown, Simon Szeto, Bob Koehler, 
Bill Wood, Linwood Ferguson, Matt Holdrege, Larry Kilgallen, Keith Chadwick,
Patrick Mahan, Gail Walker


(Katz)
------
    Is there any way to control the scrolling rate in a DECterm window 
(running V5.5, MOTIF, VS4000 Mod 60)?
    On my character cell terminal I always used 9600 baud and jump scroll 
which was just right for most cases. I didn't have to wait a painfully long 
time for things to display, but I could react fast enough to stop the 
scrolling with the info I wanted somewhere in the middle of the screen.
    Now with this workstation, I don't have a serial line to throttle things 
and this CPU spits stuff out so fast that its off the screen before I can stop 
it.  I know, I can always scroll back and see it but stopping and backing up 
gets tiring after a while.


(Burnet:  Probably no easy answer)
----------------------------------
    Part of the problem is that X is normally an asynchronous protocol.  By the 
time the DECterm code receives notification of the key-press event, several 
more lines (possibly a couple dozen more lines) have scrolled by.  This can 

The DECUServe Journal             January, 1993                       Page  62


also be affected by Ethernet loading, if the particular DECterm isn't running 
on the same system as the keyboard/mouse/display server.


(Harvey:  It is a real problem, though)
---------------------------------------
    I expect smooth scrolling (or even jumpy scrolling) could be emulated but 
with considerable difficulty with existing hardware.  Hence it isn't.  
    It would seem that the developers decided the scroll bar and mouse is an 
adequate workaround, which in my opinion, is dead wrong.  I understand later 
versions of Windows/Motif have provided a keyboard way to switch window 
keyboard focus.  Has anything been done about a keyboard way of reverse 
scrolling?  Like Prev Screen, for example?  That would be a big improvement 
over the scroll bar, I think.
    DECterm function is a sore point with me.  I have much need of character 
cell terminals in my work.  I wanted a VT420; instead I got a DECstation 3100.  
The monochrome display is terrific - much better than a VT420 - but it is a 
terribly poor substitute for a proper terminal.  It lives in its box and I 
have two VT220s on my desk to approximate VT420 capability.  


(Lederman:  I think there is an easy answer.)
---------------------------------------------
    I agree completely.  I am constantly amazed at some of the (in my opinion, 
very stupid) things DECwindows does.  I don't understand why the programmers 
who implemented this stuff would be willing to use it themselves.
    The least that should happen is that the window on the local station should 
stop scrolling immediately, even if the client is still sending data (which 
can be buffered locally).


(Harvey)
--------
    I think Erik Husby said somewhere here that he seldom if ever uses
DECterms.  It's my guess that the Windows developers don't use DECterms either, 
and that the workstation/windows product managers consider DECterms to be a 
temporary workaround which will disappear when we are all windowized.
    Erik, what do you think?


(Husby:  A workstation is much more than a couple of terminals)
---------------------------------------------------------------
    Since you asked, my feeling is if you want the performance of a traditional 
terminal, use a traditional terminal.  They are not that expensive. One could 
easily have two or more for the same price as a workstation. I used to be very 
productive with a VT220 hooked to a terminal server.  Between kept subprocesses
and the terminal server session switching commands, I could keep very busy.
    But with my workstation, I am learning to work differently.  Now, not only 
can I keep different sessions going.  But I can link them together in ways 
that are just not possible with a VT220.  For instance, I can browse my list 
of files in FileView.  Select one of them, and then have LSE open it.  My 
DECwindows mail knows how to trigger my existing LSE session to edit a message.
I can link my mail messages to calendar entries. On and on.



The DECUServe Journal             January, 1993                       Page  63


(Lederman:  Can't give up DECterms for a long, long time.)
----------------------------------------------------------
    It isn't possible to give up DECterm (though I'm sure the users here would 
like to).
    It's the only interface to DCL.  Lots of things run as command procedures 
or batch jobs.  DECterm is the only way to get this work done.
    Also, while development may be done on the workstation, a lot of the "real" 
work runs on a 3600.  The workstation have to SET HOST to the 3600 to do stuff 
in DCL.
    So we're stuck with DECterms, and they don't work right.  They need to be 
fixed.
    P.S.: even if Digital came up with a windowed replacement to DCL, I doubt 
if anyone here would use it.  They have tried FileVue and loathe it intensely.  
And they are NOT DCL "bigots".  They all come from a Macintosh background, and 
would much rather use a windowed interface, if the utilities are anything less 
than abominable.


(Burnet:  X over DECnet may be preferable to CTERM over DECnet)
---------------------------------------------------------------
    A short side trip here...  :-)  If you're using CTERM-flavor SET HOST (as 
opposed to SET HOST/LAT), you may get better results if you scrap that method 
and instead have the 3600 create a DECterm window directly on the workstation 
with CREATE/TERMINAL.  From the workstation, you can use either SUBMIT/REMOTE 
or DECnet task-to-task to request the CREATE/TERM/DETACH.


(Husby:  DECTerm is a terminal emulator, not a terminal)
--------------------------------------------------------
    My comment about the workstation not being a terminal has not seem to have 
struck home.  DECTerm is a terminal emulator, hence, as in all emulators, will 
have differences from the real thing.  That being that, learn to use the 
workstation the way it works best.
    In regards to controling the scrolling rate via XON/XOFF (i.e. 
Control-S/Control-Q), that is a technique appropriate to a RS232 communication 
path.  It is not appropriate technique on an X communication path.  What is 
appropriate in X is to capture the output in a file or memory like DECterm 
does, and then use editor like controls to view it.
    In regards to FileView, I agree, the Macintosh Finder is nicer.  However, 
with a little (and I mean little) bit of work it is possible to make one's 
life very easy with FileView.


(Mayhew:  Do you really mean...?)
---------------------------------
> [^S/^Q] is not appropriate technique on an X communication path.  What is 
>appropriate in X is to capture the output in a file or memory like DECterm 
>does, and then use editor like controls to view it.
    
    But wait. (Note that I have not yet used one of these beasts yet; I'm
happy with VWS for the time being but I do see Father Time's shadow on the 
wall.)
    It is often the case that I want to look at the beginning of the output
from some program and, based on what I see, decide to let it continue or to 
abort it.  It is often the case that the programs in question will generate 

The DECUServe Journal             January, 1993                       Page  64


enough output, or short-enough lines, that relying on the bandwidth of the 
data link, or the scroll rate of the terminal, is not sufficient; I need to be 
able to say "stop displaying NOW".  I don't mind if some (moderate) amount of 
additional output piles up in a buffer somewhere, but having to wait for it 
all to finish and then scrolling back-and-forth is unacceptable.
    Are you saying that (e.g.) the Hold Screen key, or ^S/^Q, on a VAXstation
running DW/Motif essentially has no effect?  That's unacceptable from a
"terminal emulator".  Silly me, I expect it to *emulate* the terminal,
including this fundamental behavior of "stop displaying NOW".
    Am I misreading something, or am I really going to detest switching to the 
X environment?


(Bryant:  Scroll bars are the answer)
-------------------------------------
    DECterm is actually better at this than my VT!  Sure the HOLD-SCREEN or the 
^Q may be slow, but you get these nifty scroll bars to back with!
    I find now that when I'm at home I have a harder time since I can't be
lazy with the noscroll key and go back with a scroll bar.  My Vt100 just won't 
do that.


(Harvey:  A Broken UI)
----------------------
>DECterm is a terminal emulator, hence, as in all emulators, will have 
>differences from the real thing.  

    Yes, but these are serious bad differences.  Any decent PC based terminal 
emulator will emulate far better.

>In regards to controlling the scrolling rate via XON/XOFF (i.e.
>Control-S/Control-Q), that is a technique appropriate to a RS232 communication 
>path.  It is not appropriate technique on an X communication path.  

    The communication technology is quite beside the point.  I have a Hold
Screen key on my x-windows keyboard *and it doesn't work!*  This is a failure 
of the User Interface. 
    The ability to use the mouse to scroll back through a couple of hundred
lines of text is valuable (and I even use it sometimes) but this is not a 
substitute for a working Hold Screen key, or even a practical workaround.  The 
two features are quite different.


(Hanrahan:  DECterms really aren't that bad.)
---------------------------------------------
    The Hold Screen key *does* work.  It's just a little slow.  
    (I'm told that the delay is due more to the "hardware buffering" in smart
display devices like GPX and SPX cards than to the DECwindows client/server
implementation.  Supposedly if you run DECwindows on the old single-bit 
graphics card (QVSS? something like that) in a Q-bus backplane, even with
a 3600 processor dropped in, "hold screen" becomes near-instantaneous.  )
    I suppose that "hold screen" could compensate for the speed of the display
hardware and automatically "back up" the display to compensate.  

    However....


The DECUServe Journal             January, 1993                       Page  65


    Frankly, I hear the echoes here of many, many old arguments.  For example,
programmers who were used to working on ASR-33 teletypes and on their 30 cps
counterparts (thermal printing terminals, daisywheel printing terminals, etc.)
complained, when CRTs came in, that they couldn't see as much "history" of
their session as they were used to.  And make no mistake, they were *right*.
    What happened?  Two things.  One, our work habits changed.  Two, we got
different tools -- screen-based text editors, for example.  With the new tools
and new work habits it turned out that we didn't *need* to see that much of
"past history" at once.  And lo and behold, the new terminals were more useful
than the old ones. 
    The same applies here.  The fact that "hold screen" doesn't work *quite* 
fast enough to be useful is (imho) far overshadowed by :

    You can now have a 48 line by 132 col terminal.  Or larger!
    And many of the size increases do not require a condensed type font.

    You can have FOUR 24 x 80 terminals without overlapping them!  (At least
you could before Motif came along)

    You can use the mouse to cut and paste between windows.  e.g., do a 
DIRECTORY in one window.  Want to edit a file that you see there? Does it have 
a huge, long directory spec and file name?  No problem.  Either in that window 
or another, type EDIT and then "pick up" the directory-and-device spec from 
the directory header, and then the file name from the directory listing.  
Almost as good as FileView might be if I ever get used to using it.  
    Displays happen MUCH faster. In fact I'm not sure that part of the
"problem" with "hold screen latency" wouldn't go away if the display was 
loafing along at the ~480 char/sec or so you would typically get out of a VT100.
    You can trivially scroll back to display a previous screen -- or even save 
a whole screen to a file.  (Don't want to save in Postscript form?  Go to 
another window and type   CREATE SAVESCREEN.TXT at the DCL prompt.  Go back to 
first window, use the mouse to select the part or all of a display (there's a 
SELECT ALL under the Edit pulldown if you want everything), go to second 
window, paste, type ^Z.)

    Note to DEC:  There really oughtta be a menu option for this.  
                  Sun has it!  And you should have the option of retaining 
                  display attributes like bold, reverse video, etc.)

    And all of that is without using any new tools like FileView.  Personaly
I'm just not used to FileView yet, but I do (finally) use the 'more' that
Don Roberts put up here, and that has made life a WHOLE lot simpler.  If you 
get in the habit of typing 'more' instead of 'type', you may come to never use 
your hold screen key... or miss it.
    OTOH, if you *really* miss "hold screen", try setting your DECterm to 48 
lines.  I then find the "hold screen" to be quite fast enough; that is, the 
24 lines I "wanted to see" are still on the screen by the time it stops.
    Bottom line:  Yes, DECterms are different from real CRT terminals.  And, 
yes, some of those differences will require us to adopt some new work habits 
and some new tools before we will stop missing some of the old functionality. 
But that's nothing new; it's been going on since the dawn of technology. You 
might as well complain that your buggy whip isn't very useful on your car! 
    And once the new tools become part of your work habits, I promise you that
a few DECterms on your workstation screen will be much handier than a bunch of 
*real* terminals.*  Besides, you don't have to have space on your desk for all 
those CRTs... and all those keyboards!

The DECUServe Journal             January, 1993                       Page  66


    But if you really have no use for that workstation that's still sitting its
box, why don't you throw it away?   Just give me a bit of advance notice.  I
promise you, it'll never hit the ground.  
    *Unless, of course, you really need to make a hardwired RS232 connection to 
something without going through your workstation's CPU and Kermit or whatever!


(Harvey:  Maybe we are broke...)
--------------------------------
>The Hold Screen key *does* work.  It's just a little slow.  

    On my DECstation 3100, the time it takes to work is apparently infinite.  
I have never seen it work. The DECterm also doesn't understand about most of 
the LK201 upper row function keys - F10 for example.  I have to use CTRL Z.

>But if you really have no use for that workstation that's still sitting its
>box, why don't you throw it away?   Just give me a bit of advance notice.  I
>promise you, it'll never hit the ground.  

    I tried to get rid of it several ways - the boxes are big and clutter
up my office.  My boss won't let me.  Sorry.
    Jamie, you make a good point that workstations do represent major
technology improvements, and I agree - I wish I could use the large screen 
capability of the one I have.  The broke DECterm prevents it, however.  There 
is just too much wrong.
    I guess your TPU/EVE/EDT is broke too, since you still use EDT.EXE. :-)


(Brown:  But don't investigate this- just send me the DECstation...)
--------------------------------------------------------------------
>On my DECstation 3100, the time it takes to work is apparently infinite.  I 
>have never seen it work. The DECterm also doesn't understand about most of 
>the LK201 upper row function keys - F10 for example.  I have to use CTRL Z.
    
    I've never seen a DECstation, but it sure sounds like your DECterm is
acting as a VT100 emulator!  Is it possible there's a setting somewhere that 
needs to be tweaked?  Or maybe the Unix DECterms aren't as nice as the VMS 
DECterms....?


(Hanrahan)
----------
>On my DECstation 3100, the time it takes to work is apparently infinite.  I 
>have never seen it work. The DECterm also doesn't understand about most of 
>the LK201 upper row function keys - F10 for example.  I have to use CTRL Z.

    Do you mean DECstation or VAXstation?  And, yes, F10 works for ctrl-Z 
here (VAXstation).  
    The upper row function keys are supposed to be programmable, just like on a 
real VT(>220).  If all else fails you could set them up yourself...

>I guess your TPU/EVE/EDT is broke too, since you still use EDT.EXE. :-)

    Yes, I still use EDT.EXE, for reasons I explained elsewhere.  And this is
more of the same thing -- sluggishness to adapt to new tools.  

The DECUServe Journal             January, 1993                       Page  67


    I know that TPU/EVE with EDT keypad would give me lots of things I don't 
have now, like support for those 48-line DECterms, not to mention CALLability 
(my EDT is customized in ways that require it to be invoked by code of my own,
hence I'm using SPAWNed, not CALLable, EDT form NOTES).  
    But, just as i haven't taken the time to get used to FileView, I haven't 
taken the time to translate my customizations to TPU and to otherwise use EVE.  
And my fingers are very used to those customizations.  I'm far more productive 
than I could ever be with satandard EDT.  
    (Oh, otoh, it isn't quite the same thing -- I'm not going around saying 
"TPU/EVE/EDT is broke", just "I haven't had time to switch over".  Stop putting 
words in my fingers.)


(Harvey:  DECstation)
---------------------
>Do you mean DECstation or VAXstation?  
    
    As in MIPS Ultrix.  Maybe my boss is hoping it will turn out to be an Alpha 
in disguise.  :-)
    I've tweeked everything in sight.  Atlanta, who were absolutely tops
helping me stumble through getting ULtrix, DECnet, LAT, etc., up and working, 
seem to think it's doing what it's supposed to do.  It's a DECterm.  :-}


(Szeto:  cultural difference in function keys?)
-----------------------------------------------
    Well, I never had the pleasure (yet) of using a DECstation, but I do
believe that F10 and F6 as ^Z and ^Y are VMS-isms.  Unless you are displaying 
back to your DECstation from your VMS system, your DECterm probably doesn't 
know about F10 and F6.


(Mayhew:  emulate: to imitate with effort to equal or surpass)
--------------------------------------------------------------
    I concede Jamie's point; I don't want to be stuck in the horse-and-buggy 
era forever.
    What I find annoying though is that my VWS VAXstation gives me all of the 
attributes Jamie mentioned in .-5 or so, PLUS an instantaneous Hold Screen and 
^S (which behave slightly differently from each other, for rational reasons).
    Moving into the future is only useful if you can drag your customers
along with you.  In my case, selling workstations or even X terminals to my 
clients is about as likely as DEC selling me a personal 9000-210.  Some day, 
when the price comes down and I can afford an Alpha that runs as fast as 
today's 9000-210, I'll buy it.  Clients tell me the same thing about 
workstations and X terminals today.
    Consequently I am trying to use new tools to maintain and develop "old
technology" (character-cell-interface software).  If I have to have a separate 
VT on my desk, then I maintain that DECterm isn't doing its job as an emulator 
and should be advertised instead as a "DCL window" or some such thing (a 
VMS-centric definition to be sure but you get the point).
    BTW the definition in the title is from the Random House Dictionary.



The DECUServe Journal             January, 1993                       Page  68


(Koehler:  add a scroll bar)
----------------------------
>On my DECstation 3100, the time it takes to work is apparently infinite.
    
    The default setup under ULTRIX does not seem to be as robust as VMS.  To 
start with, you probably need to customize in a vertical scroll bar and save 
the customization.
    ULTRIX DECwindows seems to be an effort to prove that a single GUI can be 
great on one machine and poor on another.  I use FileView on my VAX all the 
time, and with a little customization, I rarely bring up a DECterm.  UE on 
ULTRIX use fairly useless, and I cannot find any customization that allows 
prompting for data and getting the user's response in a shell variable.  (Or 
am I missing something?) The developers I talked to just shrugged and said 
they don't use UE.
    Looks like VMS was easier to do well early. (Gee, wow, big surprise :-))


(Wood:  DECterm works just grand here.)
---------------------------------------
    Thanks Jamie, I was really beginning to wonder what these guys have been 
talking about.  My VAXstation 3100 with monochrome (not grey scale) monitor 
has never been slow in responding to the Hold Screen key.
    I do notice that when I run the EWS software (essentially as a DECwindows 
terminal) served from a DECstation Hold Screen is a bit sluggish.  Using SET 
DISPLAY and CREATE/TERM/WINDOW/DETACHED does better.
    I also notice that if I use DLOGIN from a DECstation to a VMS machine VMS 
doesn't know a terminal type until I Set it.  Obviously the upper row function 
keys don't work until VMS knows I am a VT3xx emulation.
    Maybe the reason I have never spent the time to make a Fileview environment 
which will work well for me is that DECterms are working so well.  (It may 
also be because I keep 13 DECterms active on 9 nodes across 3 clusters and I 
don't know where to begin customizing Fileview to support me.)


(Burnet:  Ultrix 4.2 DECterm is flaky -- use the VMS one instead)
-----------------------------------------------------------------
    Jack, there may be a very simple solution, *if* what you want is one or
more DECterm windows giving you access to one or more VMS systems.  Yes, the 
Ultrix DECterm is busted in many ways, but that should only affect you if you 
want to use Ultrix.  If you want to use VMS, *don't use the Ultrix DECterm* 
except to start up VMS DECterms (via dlogin or rsh or DECnet task-to-task or 
whatever other method you prefer).  On the VMS system of your choice, just 
type

        $ create/terminal/display=node::0

to get your very own VMS DECterm, displaying on your Ultrix DECstation.  You 
will need to use "session manager -- customize -- security" to allow access to 
the X server from the VMS node and username that you will be using.
    In the CREATE/TERM command, you can also specify the window title and
icon name.



The DECUServe Journal             January, 1993                       Page  69


(Burnet:  CREATE/TERM/DETACH)
-----------------------------
    Sorry, I forgot to add /DETACH.  Also, it's best to set up some easy way
of executing the command remotely so that you don't even have to dlogin to the 
VMS system.  I'm being intentionally vague here -- although I've done this for 
VMS-to-VMS connections, I haven't yet got around to doing it for our few 
Ultrix workstations.  rsh or its DECnet-Ultrix equivalent, if any, might do 
what you want.


(Harvey:  Hey, maybe I can get rid of my twin VT220s!)
------------------------------------------------------
>Jack, there may be a very simple solution, *if* what you want is one or more 
>DECterm windows giving you access to one or more VMS systems.  

    Bingo!  I'll drag the blamed thing out and try your suggestions.  Who 
knows?  Maybe I'll end up with the world's most expensive X-term.

>Yes, the Ultrix DECterm is busted in many ways, but that should only affect
>you if you want to use Ultrix.  
     ^^^^^^^^^^^^^^^^^^^^^^^^^

    Bite your tongue!  Why would anyone who knows VMS want to do that?  :-)

    Anyway, thanks, John, for the confirmation that it has problems.  


(Burnet:  OK, so I was wrong... there *is* an easy answer :-) )
---------------------------------------------------------------
    Back to the scrolling-speed problem...

    I just happened to be browsing through the DECwindows Motif user's manual,
and I ran across this gem in Appendix E:

There is a DECterm resource (under Decw$terminal.Main.Terminal) called
syncFrequency that can be changed in DECW$XDEFAULTS.DAT and that

        "Specifies the number of lines scrolled before DECterm
        synchronizes with the server.  This number limits the
        rate of scrolling.  The higher the number, the faster
        DECterm scrolls.  The default is 10."


(Husby:  X seems to have more resources than VMS has sysgen parameters!)
------------------------------------------------------------------------
>OK, so I was wrong... there *is* an easy answer  :-)

    Glad that you were able to gain control of your DECterm (I've recently 
switched jobs and the new one is not quite up to Motif yet so I don't have 
access to the new manuals).
    I was also pleased to see my opinions generate a little discussion.



The DECUServe Journal             January, 1993                       Page  70


(Ferguson:  Possibilities)
--------------------------
>$ create/terminal/detach/display=node::JACK
>%NONAME-E-NOMSG, Message number 02DBC002
    
    That message is "Can't open display".
    Were you logged in to node at the time?  If not, you need separate security 
settings (DECW$SERVER_ACCESS_ALLOWED.DAT in SYS$MANAGER).
    Also, I'm not familiar with the format "node::JACK".  What I had been doing 
is:
        set display /create/node=node
        create term/detach
    
    I can't say the SET DISPLAY is needed, but it works when I used it.  I 
don't know what to use for "node::JACK" to make it work that way.


(Burnet:  Node/server/screen specifiers)
----------------------------------------
    The format of a display name (using DECnet) is node::server.screen -- for
example, FOO::0.1 to specify the second screen of the first server on node 
FOO.  On single-screen systems, the server and screen area always 0.0, which 
is the default.  So "node::JACK" is incorrect (I presume that JACK is the 
username?) -- try "node::0" instead.
    FWIW, "set display/create" followed by "create/term" (without a /DISPLAY
qualifier) is equivalent to "create/term/display", all other things (node, 
server, screen, and transport) being equal.


(Harvey:  I'm in over my head)
------------------------------
    First some explanation.  Linwood was responding to a note I deleted out 
from under him.  I realized what one major mistake was and tried to hide my 
goof by deleting the stupid note.  I should know better. 
     
    This was *exactly* my command.  The nodename is JACK.     |-}
    
>    $ create/terminal/detach/display=node::JACK
    
    So I went back and tried:
    
    $ create/terminal/detach/display=JACK::0
    
    where JACK is the nodename of the VMS workstation.  This didn't work
either, and I can't reproduce what happened the first time I tried it.  I got 
a message about an invalid logical name, DWS$?.  Now it just hangs and never 
completes.  I broke it.
    
>    %NONAME-E-NOMSG, Message number 02DBC002
>    That message is "Can't open display".
    
    How did you get the message text?  My host system and the workstation can't 
translate 02dbc002.  Maybe something is missing here.
    
    $ create/terminal/detach/display=JACK::0
    

The DECUServe Journal             January, 1993                       Page  71


    This command now just hangs forever on both the host and the workstation.  
(Still pure VMS - no Ultrix yet.)


(Ferguson:  5.4-3?  Need 0.0)
-----------------------------
    What VMS?  I just noticed in 5.4-3 there is a note in the release notes
that you must include the screen number (i.e. jack::0.0).
    I tried the above (though substituted LEF for JACK) and it worked (above = 
0.0 on 5.4-2).
    
>How did you get the message text?  My host system and the workstation can't 
>translate 02dbc002.  Maybe something is missing here.
    
    I use this wonderful routine someone posted on DECUServe to look at all 
the message files.  Since I can't find it right now, here it is (it's short).  
Do @MESSAGE <hex-string>

$       set noon
$       on control_y then goto exit
$       file = "<default>"
$       goto middle
$
$loop:
$       file = f$search("sys$message:*.exe")
$       if file.eqs."" then exit
$       set message/noid/notext/nofac/nosev
$       set message 'file'
$       stat = $status
$       set message/id/text/fac/sev
$       if .not. stat then goto loop
$
$middle:
$       x = f$message(%x'p1')
$       y = f$element(0,",",f$element(2,"-",x))
$       if y.eqs."NOMSG" then goto loop
$       write sys$output file
$       write sys$output x
$
$exit:
$       set message/id/text/fac/sev
$       exit


(Holdrege:  Try from a DECwindows node)
---------------------------------------
    I get the invalid logical name and the NONAME error message when I try
the CREATE/TERM command from a non-DECwindows node. (a node that does not have 
decwindows started and the decwindow logicals defined.)
    Are you sure you are trying this from a node with DECwindows FULLY enabled?


(Harvey:  Progress!)
--------------------
    This is what I think the situation is.  I have two VMS 5.4-2 nodes, let's 
call them HOST and JACK.  They are LAVC clustered and DECnetted.   HOST is a 

The DECUServe Journal             January, 1993                       Page  72


4000-200, no graphics device, and probably did *not* have DECwindows enabled, 
but does now.  JACK is a VS3100 with a display, and is running DECwindows. 
    I'm not sure about *anything* in this area, but I think I've stumbled on 
how to do this.  Doing:
    
    $ create/terminal/detach/display=JACK::0    !on HOST

produces a hang.  The "hung" process is logged in via a terminal server.  Node 
name JACK, username HARVEY (me), under DECwindows, is where I did the session 
manager -- security stuff.  However, Linwood provided the clue:

    $ create/terminal/detach/display=JACK::0.0    !on HOST

works, *provided* username HARVEY is logged into a window session on JACK.  
That isn't immediately obvious, until it becomes obvious.  :-)  Now I'm off to 
find a piece of RG58 to splice in so I can connect the Ultrix beast in my 
office.  That's something I know how to do!


(Harvey:  DECUServe Does It Again!)
-----------------------------------
    Hey, I'm logged in via a GOOD VMS DECterm running on the worlds most
expensive X-terminal - the DECstation 3100 on my desk.  Now we know what these 
things are good for.  VAXstation 2000 replacements.  :-)
    The function keys all seem to work, including Hold Screen.  What a pleasure!
    Thanks to all, many, many thanks.


(Ferguson:  More off-topic stuff on creating DECterms)
------------------------------------------------------
    The security settings you said you changed are YOUR security settings, and 
apply only while you are logged in.  The default security settings (which 
apply when noone is logged in) do not allow the random user to display things 
on the workstation (i.e. Joe in the other room can't put up a login-like 
screen).
    The file DECW$SERVER_ACCESS_ALLOWED.DAT in SYS$MANAGER can be used to allow 
access when noone is logged in.  I keep mine with:
    
    * * *
    
    Which means from all nodes, all users, all transports (not sure which 
* is which actually).
    DOING SO IS A SECURITY RISK, but simplifies mucking around with putting
things up on different displays when noone is logged in. 
    I haven't tried this explicitly with a Decterm, but it applies to the 
login screen.
    BTW, I'm not sure what you're trying to do, but it sounds like you might 
want to do what I do with my 4000-200.  I go into my VaxStation and STOP/ID 
the loginout process, then go to the 4000-200 and do:
    
        SET DISPLAY/CREATE/EXEC/NODE=vaxstation
        R SYS$SYSTEM:DECW$STARTLOGIN
    
    This puts up a new login screen (it went away when I STOP'd the other
process) but running from the 4000.  You can then log in, and all sessions and 
everything else are running from the 4000, but displayed on the workstation.

The DECUServe Journal             January, 1993                       Page  73


(Harvey:  On to the next problem)
---------------------------------
    Yeah, I'm going to get around to fooling with the scrolling speed and
report results here.
    In the meantime, my purpose for this exercise was two replace my twin
VT220s with a single machine.  I haven't done that, because (and I know I 
didn't tell you people this) one of the VTs was being my debugger DBG$INPUT and 
DBG$OUTPUT.  That terminal must be logged out so the debugger can use it for 
terminal I/O.  (I'm working on screen forms, and I *hate* to debug the 
software drive the form on the same terminal that is displaying the debugger.)
    So, moderators, where should I ask about solving this problem?  I.e.,
how do I get DBG$INPUT and DBG$OUTPUT to another window on my workstation?  
I've still got one VT220 too many.


(Brown:  Try it- I think it can do what you want...?)
-----------------------------------------------------
    I'm a DECWindows neophyte, but the one time I fired up the native
DECwindows debugger, it sure looked like it could do all you want and more!  
(Separate windows for each of the debugger functions).  I think you're going 
to like this X stuff once you use it for a while!


(Burnet:  You can do it even with the CCT debugger interface)
-------------------------------------------------------------
    [The previous reply] is probably right -- the DECwindows flavor of the VMS 
debugger will do what you want.  However, if you want to stick with the 
tried-and-true VT interface (line mode or screen mode), you can do that too.  
Just use CREATE/TERMINAL/NOPROCESS, which will create the terminal window on 
your screen but will not associate a process with it or log it in.  I recommend
using the /DEFINE_LOGICAL qualifier as well, so that you never have to mess 
with WSAn: or FTAn: physical device names (or TWAn:, if you're using DECwindows 
V2).  Then you can define DBG$INPUT and DGB$OUTPUT to point to that window.  
You can even create two windows and use one for input and one for output if 
you want.
    This is in addition to your previously-existing logged-in DECterm windows,
of course.
    Ain't life fun when everything's virtual?  8-}


(Burnet:  Expensive, but a *great* X terminal!)
-----------------------------------------------
    Jack, I just wanted to point out that the DECstation itself doesn't have 
to be completely wasted, even if you hate Ultrix.  You can use it to run 
clients locally that don't have to run on VMS.  This might amount to a small 
fraction of what you use every day, but at least the clock and calculator and 
puzzle and stuff won't take up memory on your VAX systems or consume network 
bandwidth.  CPU-bound programs will probably run much faster on the DECstation 
anyway.  :-P


(Harvey:  /NOPROCESS, of course!)
---------------------------------
>DECwindows debugger, it sure looked like it could do all you want and more!  
>(Separate windows for each of the debugger functions).  I think you're going 
>to like this X stuff once you use it for a while!

The DECUServe Journal             January, 1993                       Page  74


    DECwindows debugger?  Canon violation!  It's too full of mice and bugs.
I've done quite a bit of X stuff, using and writing, and I hate it.  I like 
software that returns error messages when I screw up, instead of just ignoring 
me.
    Anyway, thanks for the tips, John, I'll probably get this all cleaned up 
by tomorrow.  I like using the tried-and-true debugger in a big window, by the 
way.  It knows what to do with it.  The big breakthrough for me here, is 
learning that I can get a real VMS DECterm on the MIPS box.  This is amazingly 
*faster* than the Ultrix DECterm, too.


(Harvey:  Off and running)
--------------------------
    I sent the following this morning on my work system:
    
From:   nnn::HARVEY       "Jack Harvey" 20-MAR-1992 08:46:37.71
To:     xxx    
Subj:   You had your chance, and you blew it!

My DECstation 3100 workstation is no longer available for sale or for    
reassignment elsewhere.  My friends on DECUServe showed me how to use it as a
VMS workstation.  It is now a superior X-terminal, and considerably better than
a VT420.  
    
                 ~~~~
    
    I'm still having lots of beginner problems with this, but they are things 
that Digital telephone support can handle.  So I won't need to bother the 
experts here anymore.  Again, thanks.


(Kilgallen)
-----------
    Let's see, if expert advice costs $60 per year, then TSC must be cheap :-).


(Harvey)
--------
    Nice thought, Larry, but Xcom knows the truth.  The $60 per year is silly 
nonsense.  The true cost of getting the benefit of all this expertise is far 
higher.  First, there is the communication cost, which can run up around one 
or two grand a year for someone who really digs in here and uses all the 
available goodies.
    Second, there is the cost of the member's own time.  People reading
DECUServe conferences are not *simultaneously* solving immediate problems for 
their boss.
    In my particular case, I was greeted this afternoon by a smiling vice
president joking about my sudden protective behavior towards the X-terminal 
(a.k.a. DECstation 3100) I was trying to get him to get rid of, but which is 
now proudly occupying the seat of honor on the typing-table side-arm of my 
desk.  
    I've got some mechanical fiddling to do to get this dressed up to my
satisfaction, but that will happen.  With a hole here and there, the thick 
pizza box MIPS cpu in the DECstation 3100 will be under my desk and I will be 
able to get this gorgeous monochrome very high resolution (sorry for you poor 
suckers with color) display down to where Jack thinks it should be.  I've got 

The DECUServe Journal             January, 1993                       Page  75


a VT4200, at least!  I have 52 lines when I read VAX Notes, and I'm being 
conservative!
    *Two* clean classic VT220s are available for disposition to many needy
desks.  (Yes, I've got the debugger running reliably [I hope] in one {or two} 
windows.)  I still have to battle the stupid mouse technology, but there is 
hope.  I'll try a track-ball, and who knows?  Maybe X-windows will grow up.


(Harvey:  Aye of Newt...)
-------------------------
>I'm still having lots of beginner problems with this, but they are things 
>that Digital telephone support can handle.  

    Okay, I was right about this.  I'm trying to make this point in
BUSINESS_PRACTICES also.  Digital Telephone Support is tuned for dummies, 
(like me in this case) and you general-purpose DECUS wizards just shouldn't be 
allowed to complain (Jack's rule) if Telephone Support can't answer 
wizard-level questions. 
    I had some real sillies:  why does an attempt to save the session
attributes fail on permission?  Answer: I'm a campus wheel at this site.  Real 
Answer?  The DECstation 3100 trying to save session setup parameters into a 
file in my SYS$LOGIN: can only use the owner authority on SYS$LOGIN:.  I 
didn't own my own SYS$LOGIN.  My having bypass didn't solve this (entirely 
correctly, from a Security viewpoint) so rewrite of the options file into my 
directory failed properly.  By correcting the ownership, suggested by Atlanta, 
the problem is solved.  
    Second dumb problem.  I wanted a 52 line DECterm.  I fiddled with the
create/TERM command (/window_attributes=rows=52) and with the default file and 
got exactly the same:  I would get a 52 line window, which then after a few 
seconds shrank to 24 lines.  Dumb explanation suggested by Atlanta:
    I had a SET TERM/INQUIRE in my LOGIN.COM.  It looked at the DECterm, saw 
it was a VT320, and set the page to 24 lines.  My window box clamped down to 
therefore 24 lines.  !Comment out the SET TERM/INQUIRE in my LOGIN.COM and 
Atlanta wins again.  (This guy was good.)
    Now, you people don't want to be bothered with that level of nonsense,
right?  THAT'S the level of nonsense we pay Digital to support, and rightly so, 
because there are far more dummies like me than there are wizards like you.  
But wait.
    Can you imagine Digital telephone support people, no matter how skilled 
they are,  being able to  handle a complaint along the lines of:

    "I think the DECstation 3100 stinks and I am trying to get my
    management to get it out of my office.  Aren't they silly for not doing
    this?"

    Yet, this is pretty much what I gave this conference as a problem, not even 
knowing it myself.  DECUServe people were able to see underneath my 
frustration and reveal the truly creative solution: turn my DECstation (MIPS) 
into a super X-terminal, thereby benefiting everybody involved.
    This is the magic of DECUServe.  Larry, we can't put a price on magic.
Well, maybe we could, but none of us would be able to afford it.  Let's just 
rejoice that it's here.



The DECUServe Journal             January, 1993                       Page  76


(Ferguson:  DEC should refund money if I am "not allowed")
----------------------------------------------------------
    I'll stop complaining as soon as they provide support for what you (not me) 
call "wizard level questions".  Some of the questions I ask that they cannot 
answer , I think, do not fall in that category, but let your definition stand. 
WHY SHOULD DEC NOT BE ABLE TO ADDRESS THIS AUDIENCE.  WHY SHOULD I NOT BE 
ALLOWED TO COMPLAIN, since DEC does not complain about accepting "wizard level" 
money?
    But [token effort to try to stay on topic], Jack, I'm glad you summarized 
the problems here because now the next person will be able to get their 
solution from DECUServe and never have to bother CSC.  


(Burnet:  Not quite infinitely customizable, but almost...)
-----------------------------------------------------------
>I've got a VT4200, at least!  I have 52 lines when I read VAX Notes, and I'm 
>being conservative!

    Are you using the DECwindows interface, or just Notes in a DECterm?  Try 
the DW interface -- you'll like it.  For local conferences, I mean -- I don't 
think you can get it to work for DECUServe connections over a serial line.  
:-(  The same goes for VMS Mail: you might prefer the DW interface to just 
running Mail in a DECterm.

>I still have to battle the stupid mouse technology, but there is hope.  I'll 
>try a track-ball, and who knows?  Maybe X-windows will grow up.
    Two thoughts about that:  First, I assume that your DS3100 has the old 
VSXXX-AA "corporate mouse" (round).  If you don't like it, get one of the 
newer models (can't remember the model number, but I think it just has a 
different suffix).  You might like the new design better.  Both mice are made 
by Logitech, but the new one is the standard new Logitech ergonomic design 
that's more comfortable to use.

    Second, remember that Motif has key bindings for most window and menu 
actions.  Take a look at Appendix A of the VMS DECwindows Motif User's Guide.  
Motif is available for Ultrix too.


(Harvey:  Key driven window hopping)
------------------------------------
    Motif is what I need to be able to use a key to move the keyboard focus
between windows, right?
    
>Motif is available for Ultrix too.
    
    Does this mean I need to install Motif on *both* the VMS system and my
Ultrix X-terminal?


(Burnet:  Motifying your DECwindows is recommended)
---------------------------------------------------
>Motif is what I need to be able to use a key to move the keyboard focus
>between windows, right?

    Yep.
    

The DECUServe Journal             January, 1993                       Page  77


>Does this mean I need to install Motif on *both* the VMS system and my Ultrix 
>X-terminal?

    I don't think so, although it depends on what version of DECwindows (and 
thus what version of Ultrix) you're running on the DECstation.  Motif requires 
an X11R4-compliant server.  I don't know whether the Ultrix 4.2 DECwindows 
(DECwindows V2?) server is R4-compliant... can someone else here say whether 
this is the case?

    There are discussions in USER_INTERFACES-WINDOWS about mixing DECwindows V2
and V3 (pre-Motif and Motif).

    For ordering information for Ultrix Motif, see topic 135 in the UNIX_OS
conference.  If you have Ultrix 4.2A (or maybe 4.2 is good enough), you don't 
need a license, just the H-kit.


(Kilgallen:  Why I haven't considered DECwindows interfaces)
------------------------------------------------------------
> Are you using the DECwindows interface, or just Notes in a DECterm?

    Have either of these products fixed previous problems requiring that
editors be spawned (editors which can be called in a normal process)?


(Burnet:  Don't know, myself... anyone?)
----------------------------------------


(Chadwick:  VSXXX-GA)
---------------------
>old VSXXX-AA "corporate mouse" (round).  If you don't like it, get

    The new mouse part number is VSXXX-GA.


(Holdrege:  Irish mice)
-----------------------
    Are you sure the mice are from Logitech? They are made in Ireland and they 
don't say Logitech anywhere on them. I realize Logitech could have OEM'd them 
for Digital, but I didn't think they were in Ireland.


(Mahan:  Give it a try!)
------------------------
>Does this mean I need to install Motif on *both* the VMS system and my
>Ultrix X-terminal?

    Depends.  Chances are the X window server that is running under Ultrix is 
X11R4.  If it is still at X11R3, then there are some problems when running an 
X11R4 client to an X11R3 server.  Most of these problems are due to ICCCM 
non-conformance.



The DECUServe Journal             January, 1993                       Page  78


(Szeto)
-------
>    Are you sure the mice are from Logitech? They are made in Ireland and
    
    I don't know any more than you do about this, so ignore my place of
employment.  Could it be that only the design was Logitech's?


(Szeto:  That's no editor; that's the text widget)
--------------------------------------------------
>Have either of these products fixed previous problems requiring that
>editors be spawned (editors which can be called in a normal process)?
    
    No, Larry, they both use the Text Widget still.  I understand that some
part of the NAS architecture would make it possible for these two applications 
to call the editor of the user's choice, but I don't think that either 
DECwindows Motif Mail or VAX Notes V2.2 supports it.
    By the way, if you do use the Text Widget instead of doing your editing in 
another window that has your favorite editor, I suggest you turn off auto-wrap.
(No, I haven't followed my own advice; I'm also not a heavy user of DECwindows 
Mail, except for reading and short replies, and I seldom use DECwindows Notes.)


(Brown:  Even DEC says it's a Logitech)
---------------------------------------
>Are you sure the mice are from Logitech? They are made in Ireland and they 
>don't say Logitech anywhere on them. I realize Logitech could have
    
    We wondered about that- we compared it to a Logitech mouse we have and they 
appear IDENTICAL...yet it doesn't say Logitech anywhere on it.  But if you 
look in the docs- I believe it's the packing list- it says "Logitech mouse" !!
    DEC may indeed make it (using Logitech's design, if not also tooling),
since it has the previous-DEC-mouse-compatible connector on it.


(Harvey:  SHOW SERVER)
----------------------
>Depends.  Chances are the X window server that is running under Ultrix is 
>X11R4.  
    
    Any idea how to determine if I have X11R4?  I've got the full Ultrix doc 
set unstashed on a shelf behind me, but I haven't a clue where to look.


(Mahan:  Some solutions that should help)
-----------------------------------------
    Jack, I believe you will need to load the unsupported tape that came with 
the Ultirx OS.  This contains a lot of X applications, most notably, 
"xdpyinfo" (quotes are mine).  If that is not a possiblity, then check for the 
server log on the Ultrix box (not sure exactly where they are).  Basically, if 
it says something about Motif or bug compatiblity mode, the X server is at 
X11R4.
    Failing all the above, I will post the X11R4 xdpyinfo here and you can 
make a stab at building on the Ultrix, or go ahead and load DECwindows/Motif 
and you can build it under VMS.

The DECUServe Journal             January, 1993                       Page  79


    If you do use "xdpyinfo" the basic rule of thumb is that if it reports 
anything about X Server extensions, then it is an X11R4 server.


(Harvey:  X11R4 xdpyinfo)
-------------------------
    I have checked my Ultrix node and find no mention of xdpyinfo in the
unsupported section of the doc set.  I'll also look for the other indications 
you mentioned, and try Atlanta. I don't want to try altering the node at this 
time, so no need to post for me.
    At any rate, my "workstation" has now become a real workstation; both
VT220s are shelved, the classic debugger window (but 50 lines) is great.  I'll 
be summarizing what I needed to do to get it all going shortly. 


(Walker:  xdpyinfo results on Ultrix 4.2)
-----------------------------------------
    I have xdpyinfo in /usr/bin/X11, I'm pretty sure it came off the
unsupported tape. When I run it I do get information about 8 extensions so I 
guess it is based on X11R4.
    I'm running Ultrix 4.2 on a DECstation 5000 model 120.


(Husby:  Why do you need to spawn?)
-----------------------------------
>Have either of these products fixed previous problems requiring that
>editors be spawned (editors which can be called in a normal process)?
        
    But with a X based system, why do you need to spawn an editor.  My editor 
is always running, so I simply switch to it and edit a way. One can either 
write a file or cut/paste to get into Notes or Mail.  Note, that you can have 
TECO running in a DECterm window and use the DECterm cut/paste capablities.


(Kilgallen)
-----------
    I want the editor to automatically start up with the text in it (and the
quotation margin inserted) when I do something simple in the communications
tool.


(Harvey:  DECterm 3100 Hold Key)
--------------------------------
    My DECstation 3100 serving as an "X-terminal" for VMS DECterms is working 
out very well.  As reported earlier, the Ultrix version of DECterms apparently 
has no support for the Hold Screen key, but a VMS originated DECterm does.
    However, there is an anomaly which once understood is no big problem.
    In this setup, the Hold Screen key (F1) is a repeater.  That is, if you
hold the key down, the Hold Screen LED on the LK201 keyboard rapidly cycles on 
and off.  
    Until I understood this, I was getting some *very* strange behavior.  The 
time interval for holding it down before the Hold state starts cycling on and 
off is pretty short - maybe 100 milliseconds.  If the current state is hold, 
and you press the key to release the screen, but forget to release it quickly, 
the screen advances a few lines and the hold state comes back on.  Weird, 
until understood.

The DECUServe Journal             January, 1993                       Page  80

    
    I haven't found a use for this yet - I expect it was done on purpose - but 
once I learned to just tap the key quickly, the behavior seems to be fine.  :-)
    Oh, yes, I guess I have the only terminal that needs disk backups. :-}


(Katz:  Thanks for scrolling slowdown help)
-------------------------------------------
    Interesting thread started by my "simple" question. I haven't had a chance 
to try out the solution John presented in .24, but I think that is what I 
need.  Right now, my WS has been taken off it's own system disk and is using a 
system disk off on an HSC elsewhere in the cluster (A5.5 vs. V5.5 issue), so 
the network slows things down enought that it isn't as much of a problem.
    Once I can run on my own again, I'll try it out.


(Harvey:  Command File for DECterms)
------------------------------------
    Early we had some chat about /DISPLAY=<nodename>::0 vs.
/DISPLAY=<nodename>::0.0
    
    Linwood, I think, reported the second form [0.0] as a new syntax, and I
said it was required.  I lied.  The old form works too. For someone needed a 
working example, here is the command file I execute when I dlogin to VMS from 
my RISC workstation.  RISC is also the DECnet nodename.

$       !DECterm.com create three named DECterms on RISC
$   create/terminal/detached/display=RISC::0/window_attributes=( -
     x_position=100,y_position=10, -
     rows=48, -
     title="Debug Top1",icon_name="Debug Top1",initial=icon)
$   create/terminal/detached/display=RISC::0/window_attributes=( -
     x_position=200,y_position=20, -
     rows=24, -
     title="Top2",icon_name="Top2",initial=icon)
$   create/terminal/detached/display=RISC::0/window_attributes=( -
     x_position=300,y_position=30, -
     rows=52, -
     title="Modem",icon_name="Modem",initial=icon)


(Harvey:  Debugger in DECterm Window)
-------------------------------------
    This is the command file I execute to creat a window on RISC that will be 
used by the VMS debugger.
    
$       create/terminal/display=risc::0/detach/noprocess -
        /window=(rows=50,title=debug,icon_name=debug,init=icon, -
                 x_position=300,y_position=60) -
        /define_logical=(debugit)
$       allocate debugit
$define/nolog dbg$output debugit:
$define/nolog dbg$input debugit:



The DECUServe Journal             January, 1993                       Page  81


(Burnet:  node::server.screen (for DECnet & LAT transports, anyway) )
---------------------------------------------------------------------
>Linwood, I think, reported the second form [0.0] as a new syntax, and I said 
>it was required.  I lied.  The old form works too.

    The first number (before the dot) is the server number, and the second is 
the screen number.  The screen number should always default to zero if it's 
omitted, so "foo::0" should be equivalent to "foo::0.0".  You would only need 
to be concerned about the screen number if you were working with a two- (or 
more-) headed display, where one server controls more than one screen.


(Ferguson:  Bug)
----------------
    Actually, it was that I had read somewhere (some release notes, but I 
cannot find it now) that for some version(s) of VMS and/or DECwindows and/or 
Motif the ".x" part was required due to a bug (or restriction or some such).
    That I cannot find it now may mean this happened in one of those dream 
worlds, of course.

The DECUServe Journal             January, 1993                       Page  82



                   The DECUServe Journal - Technical Information
                   =============================================


Publication Information
-----------------------
    Topic threads in the DECUServe VAXNotes conferences are selected for
publication on the basis of strong technical content and/or interest to a wide
audience.  They are submitted to the editor by a team of Contributing Editors
who are DECUServe Moderators, Executive Committee members and other volunteers.
Articles in the DECUServe Journal are downloaded to a 286 PC and formatted 
using a standard text editor.


Editorial Content Disclaimer
----------------------------
    Opinions and information presented here belong to each individual author.
No inferences should be made that the authors are expressing the policies of
their employers unless specifically stated.  Content has been deemed acceptable
by the Moderators of DECUServe according to the DECUServe Canons of Conduct.


How can I use DECUServe?
------------------------
    DECUServe is available 24 hours a day, 7 days a week, except for Fridays
between the hours of 7am to 9am Eastern time for backups.  Membership is by
individual subscription only, and subscriptions are sold on a yearly basis
currently for $75.00.  Subscription forms are always included in DECUS New 
Member packets and Symposia registration packets.  Free six-month subscription 
forms are often distributed at symposia as well.
    Also subscription forms can be downloaded directly from DECUServe by dialing
1-800-521-8950 with the username INFORMATION.  Set your modem to 2400 or 9600,
no stop bits, 8 bits, 1 parity bit.  Other access modes are Tymnet, PC pursuit,
and Internet.