Thread View: vmsnet.decus.journal
1 messages
1 total messages
Started by FREY
Wed, 06 Jan 1993 02:50
DECUServe Journal, January 1993
Author: FREY
Date: Wed, 06 Jan 1993 02:50
Date: Wed, 06 Jan 1993 02:50
4734 lines
220590 bytes
220590 bytes
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.
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads