DECUServe Journal July
Sharon Frey
The DECUServe Journal
=====================
July, 1994
From the Editor's Keyboard
==========================
Good news! The DECUServe Journal is back from its summer
vacation. Postcards and travelogues will be forthcoming shortly.
Seriously, as you may have noticed, the Journal has been quiet
for the last few months. What has been going on? We've been
changing editors, and the process took slightly longer than
expected. Sharon Frey (wild applause), tireless and steadfast
editor of Journals past, had to give up the post when she changed
jobs. After some delay, your all-new, improved (Well, maybe just
"improving?" Would you believe, "willing to learn?") editors are
Brian and Sherrie McMahon. See the "Contact Information" section
for the myriad ways to get in touch with us.
We would love to hear your comments, be they good, bad, or
indifferent. We'd also like to sincerely apologize for the long
delay in our "cluster state transition." In this case, the
sincerest form of apology is to resume cranking out issues, so
without further blather, on with the (DECUServe) show!
Table of Contents
=================
From the Editor's Keyboard . . . . . . . . . . . . . 1
Table of Contents . . . . . . . . . . . . . . . . . 1
DEC C for Alpha/AXP (VMS) . . . . . . . . . . . . . 2
DECconnect Wiring Problem . . . . . . . . . . . . 10
DLT2000 vs. TZ87 . . . . . . . . . . . . . . . . . 13
LK450 Keyboard . . . . . . . . . . . . . . . . . . 16
PATHWORKS Printing Problem . . . . . . . . . . . . 22
BPSG Licensing Question . . . . . . . . . . . . . 23
Frame Relay . . . . . . . . . . . . . . . . . . . 26
About the DECUServe Journal . . . . . . . . . . . 29
Contact Information . . . . . . . . . . . . . . . 30
The DECUServe Journal July, 1994 Page 2
DEC C for Alpha/AXP (VMS)
DEC C for Alpha/AXP (VMS)
=========================
This note from the DEC_SOFTWARE conference contains two
separate threads. The first involves a quickly-resolved licensing
problem after installing DEC C V4.0 under OpenVMS for AXP V6.1; the
second thread concerns differences in C behavior between DEC C,
which is ANSI, and VAX C, which is not.
Participants include Bob Doherty, Ken Johnson, Pete Sivia, and
Ray Whitmer.
Note 651.1, 8-Jun-1994
Johnson: DEC C V4.0 (Alpha AXP) won't recognize personal license
----------------------------------------------------------------
Yesterday I installed OpenVMS 6.1 for AXP. Seems fine.
I tried to install DEC C V4.0 today. It won't recognize my personal license.
I tried a LICENSE MODIFY C /RESERVE=JOHNSON. Didn't help. The license does
show as active. The license part number on the DEC quote matches the one
in the SPD, so it seems to me like it ought to work. It worked with Version
1.2 of DEC C. (The version we had used with V1.5 of VMS) It it just me, or
does anyone else have this problem?
Note 651.2, 8-Jun-1994
Sivia: Was the license re-loaded?
---------------------------------
When you did the LICENSE MODIFY command, did you also do a LICENSE
UNLOAD C and LICENSE LOAD C to make the modified version active?
Note 651.4, 9-Jun-1994
Johnson: Thanks! (insufficient RTFM'ing)
-----------------------------------------
Nope. That fixed it. Thanks. Failure to RTFM sufficiently.
But I am still puzzled. I'm quite sure (because I checked with LICENSE
LIST/FULL before entering the note in a minimal effort to avoid embarrassment)
that the license was active. Yet, this morning, the LICENSE UNLOAD command
gave a -W-NOENT, no license loaded for this product error. I am unable to
explain this discrepancy. As long as things keep working, I won't try to.
Note 651.3, 9-Jun-1994
Whitmer: Apparent DECC bug
--------------------------
We submitted this bug over a year ago to a DEC porting center
and eventually forgot about it because we stopped developing on
DECC (and AXP) because we lacked a compatible VAX compiler. Now
we are back porting to DECC (VAX and AXP), and the bug has reared its head
again, apparently it was not fixed. We know we can modify the thousands
of places the problem occurs in our source code, but if there is an easier
fix or work-around available, I would like to know.
The DECUServe Journal July, 1994 Page 3
DEC C for Alpha/AXP (VMS)
The error appears to occur regardless of the specified /STANDARD=xxx.
/*
In the routines that follow, the test_short1 routine causes a compiler
error in DEC C. The file compiles cleanly with VAX C, and the only
difference between test_short1 and test_short2 is the way the parameter
list is declared in the routine.
The corresponding test_int1 and test_int2 routines are identical to
test_short1 and test_short1 except the types are int instead of short.
test_short1 is the only routine that causes errors to be reported.
*/
short test_short1(short);
short test_short2(short);
int test_int1(int);
int test_int2(int);
/* The routine test_short1 causes a compiler error using the DEC C */
short test_short1(p1)
short p1;
{
return(p1);
}
/* test_short2, which differs only in the typedef in the parameter list
does not cause any compiler errors. */
short test_short2(short p1)
{
return(p1);
}
/* test_int1 and test_int2 both compile without errors. They are different
from the test_short routines in that all types are int instead of short */
int test_int1(p1)
int p1;
{
return(p1);
}
int test_int2(int p1)
{
return(p1);
}
$ cc test_short/standard=ansi
The DECUServe Journal July, 1994 Page 4
DEC C for Alpha/AXP (VMS)
short test_short1(p1)
....^
%CC-E-NOTCOMPAT, In this declaration, the type of test_short1 is not compatible
with the types of previous declarations of test_short1.
at line number 27 in file SHRDEV:[RAY]TEST_SHORT.C;1
Note 651.5, 9-Jun-1994
Doherty: This is NOT a bug!
---------------------------
> short test_short1(short);
^^^^^
this is an ANSI declaration for test_short1
> short p1;
^^
this is a K&R (pre ANSI) declaration. An ANSI compiler will treat it
as if it were `short test_short(int p1)'
> int p1;
Even though this is also a K&R declaration, it is interpreted by an
ANSI compiler as the real declaration.
> short test_short1(p1)
> .....^
> %CC-E-NOTCOMPAT, In this declaration, the type of test_short1 is not
compatible
> with the types of previous declarations of test_short1.
> at line number 27 in file SHRDEV:[RAY]TEST_SHORT.C;1
meaning that the declaration didn't match the definition, which in fact
it doesn't.
Mixing K&R and ANSI declarations produces undefined behavior with many
ANSI compilers, and if the standard doesn't warn about this behavior,
it should. This is NOT a compiler bug. The fact that it works with
VAXC only illustrates that VAXC is a `pseudo'-ANSI compiler.
The only real solution is to bite the bullet and correct the
definitions to be ANSI. I realize for a large body of code, this is a
pain, but it will get harder and harder to find compilers which will
accept this code.
There are utilities (protoize from GNU comes to mind) which can be used
to transform K&R to ANSI. A utility of that type might be useful.
The compiler recognizing this as an error is actually an advantage
since this kind of prototype mixing can cause disaster when ported
between little-endian and big-endian architectures.
The DECUServe Journal July, 1994 Page 5
DEC C for Alpha/AXP (VMS)
Note 651.6, 10-Jun-1994
Whitmer: Thanks for the pointer, it still seems to be a bug.
------------------------------------------------------------
I may better understand why it works this way, now. I also appreciate
the pointer to the GNU utility. That will help us deal with the
problem.
I still feel it is a bug because it accepted the definitions made
underneath per K&R. If it does not accept that form (especially with
/STANDARD=VAXC) then it should flag it as an error. It also seems to
accept other declarations declared underneath quite painlessly. For
example, if I change each use of "short" to be "short*", it compiles
without error, even with explicit /STANDARD=ANSI. If I change "short"
to "char", it still generates the error. If I create a structure
consisting of two ints and substitute the (8-byte) structure for the
short, no errors are reported.
The documentation of DECC makes no mention of the fact that it will not
accept non-ANSI routine prototypes. The help on /STANDARD=VAXC only
mentions incompatibility in preprocessor directives. Only
/STANDARD=ANSI or /STANDARD=RELAXED_ANSI even mention the need for ANSI
conformance, and even these state they work "along with any extensions
not prohibited by that standard".
Are K&R declarations prohibited by the standard? If so, then I guess
every other standard we compile this code on from Borland to SUN and
GNU must be pseudo-ANSI since this form seems to be accepted everywhere
else (and no little-big endian issues).
Note 651.7, 10-Jun-1994
Doherty: The problem is mixing K&R & ANSI...
--------------------------------------------
I would tend to agree that this is a bug in the VAXC emulation. Since
VAXC is not ANSI, and in this case behaves in a non-ANSI compliant
manner, DEC C should also.
> accept other declarations declared underneath quite painlessly. For
> example, if I change each use of "short" to be "short*", it compiles
> without error, even with explicit /STANDARD=ANSI. If I change "short"
Whether the mixed declarations work or not depends on the promotion
rules for K&R declarations. short (and char) are promoted to int --
and incidentally float to double -- whereas pointers are not. Since
all pointers are the same size with VAX/DEC C there's no problem.
> to "char", it still generates the error. If I create a structure
> consisting of two ints and substitute the (8-byte) structure for the
> short, no errors are reported.
There's also no problem with structures (passed by value) or by pointer
-- again no promotion rules.
> The documentation of DECC makes no mention of the fact that it will not
The DECUServe Journal July, 1994 Page 6
DEC C for Alpha/AXP (VMS)
> accept non-ANSI routine prototypes. The help on /STANDARD=VAXC only
If it's an ANSI compliant compiler, it will accept K&R declarations and
definitions, the problems arise when an ANSI declaration is mixed with
a K&R definition, and argument promotion is involved. GCC (VMS 2.5.7)
with /stand=portable (-ansi -pedantic -Wall) gives the same behavior as
DEC C (well almost, it generates warnings, not errors) for mixed
prototypes.
> Are K&R declarations prohibited by the standard? If so, then I guess
> every other standard we compile this code on from Borland to SUN and
> GNU must be pseudo-ANSI since this form seems to be accepted everywhere
> else (and no little-big endian issues).
Again, the problem is NOT K&R declarations/definitions. It is mixing
K&R and ANSI in cases where the argument(s) are subject to promotion.
Also, as far as Borland goes, except with flat 32-bit models, int and
short are the same, so no promotion occurs. For character, it should,
and in strict ANSI mode, Borland gripes about mismatched prototypes.
Note 651.8, 11-Jun-1994
Whitmer: I think I understand, even if I do not like it.
--------------------------------------------------------
What scares me most is that (with the help of your explanations and my
own tinkering) I am almost starting to think I understand why it is
behaving the way it is, it is not just picking on me.
> If it's an ANSI compliant compiler, it will accept K&R declarations and
> definitions, the problems arise when an ANSI declaration is mixed with
> a K&R definition, and argument promotion is involved.
I see. I had always thought that:
myroutine(int, short, char);
was a non-ANSI prototype. I believe you are saying that both:
myroutine(int, short, char);
and
myroutine(int p1, short p2, char p3);
are ANSI and the non-ANSI is:
myroutine();
> Also, as far as Borland goes, except with flat 32-bit models, int and
> short are the same, so no promotion occurs. For character, it should,
> and in strict ANSI mode, Borland gripes about mismatched prototypes.
If DEC C only did it in strict ANSI mode we would be OK.
The mismatching seems to cause problems both ways:
The DECUServe Journal July, 1994 Page 7
DEC C for Alpha/AXP (VMS)
short test();
test2()
{
short a,b;
return(test(a,b);
}
short test(short a, short b)
{
return((int)a);
}
This generates a similar mismatch error when it finally finds the
definition of test, whereas if test is defined per K&R, no problem
again
So the problem, if I understand correctly, is that:
test(short a, short b);
test(short, short);
and
test(short a, short b)
{
}
all promote the same, but differently from:
test(), real function calls,
and
test(a, b)
short a;
short b;
{
}
which also match each other in the way they promote.
This makes sense even if it is aggravating to have to change someone
else's code (which works fine for them on the multitude of UNIX
compilers and used to work well for us until we wanted to run on AXP).
Protoize seems to be tightly tied to the gnu C compiler. It will be a
major VAX installation, and GNU C will have to correctly compile our code
before we can hope to be able to "protoize" it. Even sadder: I just
saw a directory of code for which my earlier guesstimate of thousands of
corrections required in our code is an understatement.
We may be able to talk our UNIX group into protoizing it before they
give it to us. They used to support a number of UNIX platforms for
which no ANSI compiler was available. This is where the mix came from.
They have GNU everywhere. Something like protoize will be essential
unless we can get DEC to really fix VAXC emulation mode.
Thanks, again.
The DECUServe Journal July, 1994 Page 8
DEC C for Alpha/AXP (VMS)
Note 651.912-Jun-1994
Doherty: Problem understood, if not solved!!
--------------------------------------------
It's not only you. The problem of legacy code in pre-ANSI C is a large
and continuing one. Add to that the compilers which are somewhere
between K&R and full ANSI(e.g. VAX C and the default cc on many UNICES)
and you end up with a lot of headaches.
> I see. I had always thought that:
>
> myroutine(int, short, char);
>
> was a non-ANSI prototype. I believe you are saying that both:
>
> myroutine(int, short, char);
> and
> myroutine(int p1, short p2, char p3);
>
> are ANSI and the non-ANSI is:
>
> myroutine();
That's exactly correct. The variable names in the ANSI prototypes are
throwaways. For most compilers they're not even checked, i.e.,
myroutine(int p1, short p1, char p1);
passes through with nary a gripe.
> If only DECC only did it in strict ANSI mode we would be OK.
If DECC really claims to have a full VAXC mode, then what you observe
is certainly a bug. What they may claim is that it is mostly VAXC
compliant -- I don't know, we've got DEC C v4.0 for VMS but I haven't
cracked open the box yet, let alone installed it.
> So the problem, if I understand correctly, is that:
>
> test(short a, short b);
> test(short, short);
> and
> test(short a, short b)
> {
> }
>
> all promote the same, but differently from:
> test(), real function calls,
Correct!
> and
> test(a, b)
> short a;
> short b;
> {
> }
The DECUServe Journal July, 1994 Page 9
DEC C for Alpha/AXP (VMS)
> which also match each other in the way they promote.
also correct!
> Protoize seems to be tightly tied to the gnu C compiler.
I have never used protoize, I just know it exists. If it does use some
of the idiosyncrasies of GCC (and some of them are VERY weird, from a C
point of view), then it would be uncompilable on anything else.
> We may be able to talk our UNIX group into protoizing it before they
> give it to us.
For their long term sanity, your UNIX group probably should convert to
full ANSI prototyping, and then process the code with unprotoize when
they have to have K&R code for a particular compiler. The K&R legacy
code problem is certainly not going to get better with time!
> Thanks, again.
You're more than welcome. It's fun to play language lawyer wannabe
every once in a while! The real ones hang out on comp.lang.c and
comp.std.c, but they can have real unfriendly reactions to questions
they consider stupid. This particular question, is not that by any
means, but you never know how they're going to react.
Note 651.10, 20-Jun-1994
Whitmer: More incompatibility -- between DECC/VAX and DECC/AXP.
---------------------------------------------------------------
I got the FAQ off the Internet and was able to better understand a
couple of additional issues.
Our AXP version of DECC is about a year old, whereas our VAX version is
only a couple of months old. There seem to be some incompatibilities
between the two when using the same qualifiers. About 10% of our files
compile under DECC/VAX and do not compile under DECC/AXP using
identical qualifiers (/DECC/STANDARD=VAXC/EXTERN=STRICT). There seem
to be two features of DECC/AXP which do not work as I read the
documentation or as they work on VAX, although the documentation is
identical:
/WARN=DISABLE=MISSINGRETURN
I must add this qualifier on AXP to get warnings to go away which do
not appear by default on VAX by default.
/NEST=INCLUDE
On both systems, this is listed in the help as being the default
behavior. It appears to be the default behavior on VAX. On AXP, it is
not the default behavior, and I cannot even get this behavior by
explicitly adding /NEST=INCLUDE. Fortunately, there were not too many
places like this to fix.
The DECUServe Journal July, 1994 Page 10
DEC C for Alpha/AXP (VMS)
I am still tracking down some additional less-frequent cases where VAX
compilation succeeds and AXP fails. I have found no cases of the
reverse: where AXP succeeds and VAX fails.
After I have said all of this, I am generally very pleased by both the
VAX and AXP versions of DECC. Just in the past week, it eliminated
thousands of lines of change we would have had to make with
globaldef/globalref nonsense as well as other areas where VAXC was
incompatible with ANSI, and we are now better able to build our mixed
cluster so that developers can actually load balance between the mixed
architecture and notice no differences between the two nodes as they
compile, link, and run. All of the changes we have had to make for
DECC/VAX are changes we had to make anyway for DECC/AXP in any case.
Also, VAXC had a very bad habit of terminating listings after 65535
lines. This is fixed in DECC/VAX. Diagnostics files still seem to get
lost after 65535 lines. Is the .DIA file format incapable of handling
line numbers over 65535? I do not know.
All of our new development can be now compiled without /STANDARD=VAXC,
with all the warnings turned on, and the code can be kept much cleaner,
and many bugs can be prevented before they happen.
DECconnect Wiring Problem
=========================
Whether we like it or not, all of us are affected by wiring.
If it's good, we never notice it. If it's bad....
This is a discussion of the aftermath of some "do-it-yourself"
work with DECconnect components, taken from the DEC_NETWORKING
conference. Participants: Mike Durkin, Mike Gray, Keith Hare, Joe
Matuscak, Michael Mazzoni, James Stang, John Vottero.
Note 1062.0, 27-May-1994
Hare: Network protocol for DECconnect cable?
--------------------------------------------
We are working with a client who currently has their office wired with
DECconnect cable. That is, the gray, 6-wire flat telephone-like cable.
All of the cables start in the computer room, since they are currently
using them with muxes to support vt220s, and some PC terminal emulators.
They really need to connect the PCs they have in a better way, and replace
most of the VT220s with PCs.
The question is, is there any networking protocol that will run over the
DECconnect cable? Will 10baseT work with non-twisted pair?
Or, is the only solution to use the current cable to pull something else?
The DECUServe Journal July, 1994 Page 11
DECconnect Wiring Problem
Note 1062.1, 29-May-1994
Vottero: Do it right, don't do it over.
---------------------------------------
> We are working with a client who currently has their office wired with
> DECconnect cable. That is, the gray, 6-wire flat telephone-like cable.
What they have is already unsupported. That flat 6 wire cable is
supposed to be used between the office wall plate and the terminal.
The wire from the wall plate to the computer room should be twisted
pair.
Since they are already illegal, plug in 10baseT and see if it works!
Note 1062.2, 31-May-1994
Stang: we use DECconnect here
-----------------------------
We installed a 'DECconnect' wiring scheme in our building about two
years ago. We run 10baseT almost exclusively. basically 'DECconnect'
is more of a 'plan' for installing a structured cable plant in a
building. It includes hardware for the wallplate and wiring closet and
can specify what wire to use between the two.
I have never seen a DECconnect spec that allowed flat gray from the
wiring closet to the wall plate so you 'should' have twisted pair
there. Then just change the flat gray interconnect cables between the
wall and the PC and in the wiring closet and 10baseT should be fine
(assuming your twisted pair can meet 10baseT distance and signal
specs).
Note 1062.3, 31-May-1994
Matuscak:
--------------------------------------------------------------------------------
The normal way that DECconnect "V1", with the MMJ jacks on the
faceplates was wired was to run 4 pair cable to the box on the wall,
and terminate all 4 pairs to the jack. One of the pairs was basically
looped at the jack. If this is what you have, you can buy/make some
cables that map the MMJ (6 pin) connector to the RJ45 that 10bT uses.
Alternatively, you can get some of the official DECconnect RJ45 jacks,
cut off the MMJ ones, and reterminate the cable with RJ45s. I've done it
both ways.
OTOH, if you really have the flat cable from the computer room to the
offices... I agree with .-?, junk it and do it right this time.
Note 1062.4, 1-Jun-1994
Hare: I Know it's wrong, but will it work?
-------------------------------------------
> The normal way that DECconnect "V1", with the MMJ jacks on the
> faceplates was wired was to run 4 pair cable to the box on the wall,
> and terminate all 4 pairs to the jack.
The DECUServe Journal July, 1994 Page 12
DECconnect Wiring Problem
I agree that this is the normal way of doing this.
However, in this case, my client did the communications wiring them selves
when their building was under construction. They are a small, low-budget
organization.
So, the place really is wired with the flat gray cable.
I would like to be able be able to tell them that they could use the
current cabling, but so far, I haven't seen anything that suggests it will
work.
Note 1062.5, 1-Jun-1994
Mazzoni: Try it
---------------
"One test is worth 1,000 expert opinions" - ? can't remember who said that ?
What could be more in harmony with the philosophy of a small, low-budget
organization than trying something to see if it works? If your test is
successful, you're a hero because you saved them $$$. If your test failed, you
at least tried to save them $$$. How can either of you lose?
Note 1062.6, 1-Jun-1994
Gray: DEC MMJ fails LANmeter test
---------------------------------
I just tried a test with DEC MMJ cable. I cut the ends from a 50'
extension cable and put RJ45's on it. When I tested it with a Fluke
650 Lanmeter it failed on NEXT at 22 dB and impedance at 191 ohms. It
also thought there was a split pair on pins 3,6.
I don't think you would be able to get 10baseT to work on this cable.
P.S.: Typical values for 10baseT cable is NEXT (Near-End cross-Talk) at
>26dB and Attenuation at < 11 dB. Impedance should be around 100 ohms.
Note 1062.7, 1-Jun-1994
Durkin: I think I've been there and done that
---------------------------------------------
We had one of our sites wired poorly and the contractor wound
up using MMJ faceplates rather than RJ11 as this did happen quite
some time ago and well before DEC began to market it's DECconnect
system. Since we have an application which requires 10baseT links,
we had to have some customized patch cables engineered to avoid
re-terminating the cubicles/offices. I can check with our cabler,
I think DEC did this work, to obtain the pinouts for the MMJ/RJ45
office cables. Is the terminating patch panel in the wiring closet
RJ45/MMJ/RJ11 ? There might be a bit more work/research you need
to do before you can come back with a proposed solution ? If it's
RJ45, I would think either the BN25G or BN24F would work paired
with the customized spec I'll post shortly ? But I won't swear to
it. :-)
The DECUServe Journal July, 1994 Page 13
DECconnect Wiring Problem
Note 1062.8, 2-Jun-1994
Durkin: Specifications for customized RJ45/MMJ & RJ45/RJ12 patch cables
-----------------------------------------------------------------------
Here are the specifics for the cables we had crafted by DEC in
our particular unique situation. Bear in mind the UTP terminations
in the closet were into an RJ12 patch panel and the cubicle/office
jacks were MMJ, so I'm not 100% confident this information will be
of any value, but it just might. Keep us updated on your progress.
Closet Patch Cable Office Patch Cable
RJ45 RJ12(RJ11) RJ45 MMJ
1 White-Orange 2(1) 1 Blue-White 3
2 Orange-White 3(2) 2 White-Blue 2
3 Blue-White 4(3) 3 Orange-White 5
6 White-Blue 5(4) 6 White-Orange 4
Note 1062.9, 3-Jun-1994
Stang: flat gray ... no way ;-)
-------------------------------
As an aside....
I wired my the office of my sister and brother-in-law last spring (93).
A local person (I am 200 miles away from where they live) was
responsible for installing the computers and patch cables and used flat
gray for the patches. When I came back to look at the completed install
I almost fainted ;-^)
The equipment was all working (all 4 PCs) but... I tested one 2 foot
piece of flat gray patch cable with my (borrowed) HP NEXT scanner and
guess what ? The two foot segment failed 10T specs on NEXT. Overall the
single two foot piece was worse than 150' of type 4 cable. I replaced
all of the patch cables with 10T certified ones. I know it was working
but they are also betting their business on the new systems.....
Note 1062.10, 7-Jun-1994
Hare: Thanks for the responses
------------------------------
Thanks for all of your responses and tests. The scary thing is I understood
most of it -- I'm a database consultant, not a network consultant.
DLT2000 vs. TZ87
================
Recently in the HARDWARE_HELP conference, the following
discussion took place concerning the DLT2000, which is the OEM
version of Digital's TZ87 tape drive. Participants: Barton Bruce,
Stu Fuller, Frank Nagy, John Osudar, Pete Sivia.
The DECUServe Journal July, 1994 Page 14
DLT2000 vs. TZ87
Note 1694.0, 9-Jun-1994
Osudar: TZ87 vs. DLT2000 digital linear tape?
---------------------------------------------
Does anyone know what the difference is, if any, between the TZ87 DLT
tape drive sold by Digital to end users, and the DLT2000 drive they
sell to OEMs? (I hope I have the right correspondence between TZ and
DLT model numbers; if not, please post the correct information.) We
wanted to buy a TZ87 but have been offered a DLT2000 for about $2K
less, and we're wondering what the catch might be.
Note 1694.1, 9-Jun-1994
Fuller:
-------
One difference, from my reading on Usenet, is that when queried, the
TZ87 says that it's a "TZ87 ", while the DLT2000 says "DLT2000 ".
Now, when the MKDRIVER (the SCSI tape class driver) queries the drive,
it looks up in a table of known and supported tape devices, and will
find the TZ87, but won't find the DLT2000. Therefore, it turns off the
caching on the unsupported tape drive. One of the side effects of
turning off the cache is poor performance of the drive.
Note 1694.2, 9-Jun-1994
Osudar: aha
-----------
Thanks, Stu; since this drive wouldn't be going on a VMS system, that
wouldn't be a problem.
Note 1694.3, 9-Jun-1994
Sivia: Maybe eprom upgrade differences as well
----------------------------------------------
Another is that the DLT's (supposedly, not confirmed) don't support
in-field eprom upgrades, the TZ86/TZ87's do.
Note 1694.4, 9-Jun-1994
Sivia: Maybe a way to fake out MKDRIVER
---------------------------------------
> Now, when the MKDRIVER (the SCSI tape class driver) queries the drive,
> it looks up in a table of known and supported tape devices, and will
> find the TZ87, but won't find the DLT2000.
The same series of notes that talked about the DLT vs. TZ identification
and cache problems (discussed within the last 3-4 days in COMP.SYS.DEC
as I recall), also gave hints as to how to fake out the MKDRIVER. I
read the note only very briefly but I recall it was something like to
use one of the RESERVE or spare entries in the device table and convert
the device id entry to the phrase DLT2000 with trailing space padding.
Ah... found it:
The DECUServe Journal July, 1994 Page 15
DLT2000 vs. TZ87
Relay-Version: ANU News - V6.1 08/24/93 VAX/VMS V5.5-2; site eisner
Path: eisner!spcuna!uunet!olivea!decwrl!pa.dec.com!chmist.zso.dec.com!cja
Newsgroups: comp.sys.dec
Subject: Re: DLT2000 poor transfer rate
Message-ID: <2svki3$s...@usenet.pa.dec.com>
From: c...@chmist.zso.dec.com (Carl J Appellof)
Date: 6 Jun 1994 16:57:39 GMT
References: <dave.19....@bcl.co.nz>
Organization: Digital Equipment Corporation
NNTP-Posting-Host: chmist.zso.dec.com
Lines: 41
In article <dave.19....@bcl.co.nz> da...@bcl.co.nz (Dave Green) writes:
>
>I have a DLT2000 tape drive that exhibits very slow data transfer rates on
>both Alpha and Sun systems.
>
>On the Alpha/OpenVMS system, backup aborts with "too many errors" message
The answer on VMS from some tape engineering guys is this: The
DLT2000 reports a different SCSI ID string than a TZ87. ("DLT2000"
vs. "TZ87"). When the VMS SCSI tape driver, MKDRIVER, first
finds a tape drive, it looks at the SCSI ID string to figure out what
kind of drive it is. If it's a known drive type, VMS enables the
drive's hardware cache buffer, otherwise VMS doesn't enable the cache.
Unfortunately, MKDRIVER only recognizes "TZ87" and "TZ877" (for the
loader version), and does not recognize "DLT2000", so it treats this
device as a "generic SCSI" tape drive and doesn't enable the cache.
Running a DLT2000 with the cache disabled results in extremely slow
performance, as the tape must be repositioned between each write
operation. My experience says that performance drops from over 1
MB/sec to about 20 KB/sec.
If you felt adventurous, you could patch
SYS$LOADABLE_IMAGES:MKDRIVER.EXE, since there are a few reserved table
entries with the strings "RESERVE1", "RESERVE2", ...
Changing one of these strings to "DLT2000 " (8 chars blank filled),
and changing the byte preceding this string from DT$_GENERIC_MK (1C)
to DT$_TZ87 (hex 28), followed by a reboot MIGHT fix things for you.
Similar comments apply to the DLT2700 vs. TZ877
(DT$_TZ877 == 32 hex).
I haven't tried this myself, and don't speak for Digital software
support folks.
--
Carl J. Appellof (c...@chmist.zso.dec.com)
Storage Management Group
POLYCENTER NetWorker Save and Restore
Digital Equipment Corporation
The DECUServe Journal July, 1994 Page 16
DLT2000 vs. TZ87
Note 1694.5, 10-Jun-1994
Nagy: DLT2000 works *Fast* under VMS w/o patches
------------------------------------------------
We have tested the DLT2000 on a number of systems. It worked fine on
SGI Irix, IBM AIX, SUN (both SunOS and Solaris, I believe) and VAX VMS.
In particular, I did the VMS testing on my VS4000/60 and did NOT suffer
poor performance (measuring 1.25 MB/sec in uncompressed mode - precisely
the rating of the drive).
Another group here has also gotten the DLT2000 working on a VME-based
data acquisition system (not sure which processor boards).
Note 1694.6, 10-Jun-1994
Osudar: now for the software... :-)
-----------------------------------
Thanks for all the comments.
We're hoping to add to Frank's list of systems on which the DLT2000
works well -- we're going to try it on a 2100 AXP server under NTAS
(if Daytona ever ships, and if we ever get a driver for the tape drive :-)
Note 1694.7, 11-Jun-1994
Bruce: all incarnations read TK50/TK70 tapes?
---------------------------------------------
Does the OEM version also read TK50 and TK70 tapes, or would
that become a significant difference for some folks?
Note 1694.8, 11-Jun-1994
Nagy: DLT2000 and DLT2000N
--------------------------
Yes, I believe that the DLT2000 reads even grungy old TK50s (although
I have not tested this). The DLT2000N is the version which drops
the ability to ready TK50 and TK70 (but will read TK85/6/7) and has
a lower price.
LK450 Keyboard
==============
This next stream is from the PATHWORKS conference, discussing
certain ups and downs of DEC-style keyboards in the PC world.
Participants: Rob Brown, Linwood Ferguson, Terry Kennedy, Joe
Matuscak, Billy Youdelman.
Note 719.0, 13-May-1994
---------------------------------------
Can someone translate the attached for me? It came today via DSNlink.
So far I have been unable to reach anyone at CSC "I'm in the queue"
but I am not hopeful for an informative answer.
The DECUServe Journal July, 1994 Page 17
LK450 Keyboard
> The lk450 kit is not created by the pathworks engineers and in fact the
> lk450 is only supported by pathworks in "industry standard mode".
> See attached excerpt from Pathworks V5 Questions / Answers:
>
> Q. Will PATHWORKS V5.0 still support my LK250 keyboards? What about
> LK450 keyboards?
>
> The Digital-mode LK250 keyboard drivers are no longer included in the
> V5.0 client kit as our strategy is to support "industry-standard"
> keyboards. PATHWORKS will continue to support the LK250 keyboard in
> industry- standard mode. (We will make previous Digital-mode LK250
> drivers available on our forum on CompuServe but not support them.)
> LK450 keyboard drivers are also not provided nor supported.
The last sentence sounds particularly scary. As far as I know I cannot
buy a LK250 keyboard any more, right?
We have been buying LK450 keyboards for every Digital PC we buy. They
work nicely with Reflections and seem to work OK with eXcursions (once
you sort through the appropriate number of patches).
A CompuServe kit they sent (setup 1.1J for LK450) says "eXcursion 1.1
and eXcursion NT come with native LK450 support.
I am baffled whether the Pathworks VT320 really supports the LK450 or
works "unsupported" or neither.
I do not understand whether Pathworks does not support this but some
other group in Digital does?
I WANT a VT-compatible layout on our PC's. Does this mean that if
I buy LK450's Digital is trying to tell me that pretty soon I can
forget about using them with Pathworks (and which part's of Pathworks
or DEC PC products or 3rd party PC products or etc).
Does anyone understand exactly what part of Digital does and does not
support the LK450's and how and to what extent and in what modes?
Note 719.1, 13-May-1994
Kennedy: Gory details of the LK450
----------------------------------
> Does anyone understand exactly what part of Digital does and does not
> support the LK450's and how and to what extent and in what modes?
I looked into this a while ago when trying to add support for the LK450 to
MS-DOS Kermit. Petri and other folks from DEC were quite helpful in getting
me the info I needed. Unfortunately, I discovered that the LK450's emulation
of the LK250 was pretty brain dead (which was confirmed by the DEC engineer
that wrote the 450's design spec).
Some detail is in order. CSC may be confused about what the LK450 engineering
group meant by "unsupported".
The DECUServe Journal July, 1994 Page 18
LK450 Keyboard
The LK250 has 2 modes, which we'll call "industry standard" and "DEC mode".
In industry standard mode most of the keys on the top row are disabled and
the keyboard pretends to be an XT-class keyboard. It does a pretty good job
of emulation, except that some key sequences (like Ctrl-Alt-Esc) don't work,
which means you can't get into SETUP mode with an Award BIOS, and the ESCape
key is inconveniently located. In DEC mode, all of the keys are "live" and
send unique codes, which the software (either MS-Kermit or the VT320 app)
converts into the sequences a real VTxxx would send.
The LK450 has an "industry standard" mode as well, although it pretends to
be an AT keyboard. It includes an emulation of the LK250's "DEC mode" solely
for backward compatibility with software that knows only how to talk to
LK250's. The major failings of this LK250 emulation are that the ESCape key
(called Compose on the LK250) sends the same sequence as PF1, and that the
keys added to the LK450 (right-alt, etc.) send gibberish. The LK450 people
told me that the way to use the LK450 is to select one of the alternate key-
board maps that exist in "industry standard" mode (new for the 450, not in
the 250). Some of these maps support the "unique scan code for each key"
definitions that MS-Kermit (and presumably the VT320 app) need.
However, code space in MS-Kermit is very tight and I wasn't going to add
yet another complete keyboard map initialization in there.
I was told that the LK250 emulation was "unsupported" and the alternate
keymaps in industry-standard mode were "supported". CSC may be interpreting
this to say that the LK450 is unsupported. Or, DEC could have had a change
of policy and decided to desupport the whole thing entirely.
Note 719.2, 13-May-1994
Ferguson: What do the pieces do?
--------------------------------
I guess I am wondering if I should reconsider completely trying to make
our PC's more compatible with our other DEC gear -- VT's in particular.
The problem is going with industry standard keyboards makes for a tough
transition in Reflections (or equivalent) for VT users.
On the other hand, maybe we should just trash DEC and VMS completely.
That would solve my LK450 problem. I mean, can it really be that much
harder to switch to unix and Sybase than to figure out how to hook up
a DEC Lk450 keyboard? It's probably easier (and you can probably get
straighter answers). :-)
Still waiting for clarification from DEC, but since Terry provided some
internal details, maybe he can also enlighten me (us) on the pieces
involved.
In SYSTEM.INI, after installing their "unsupported" kit, it changes
[boot] keyboard.drv=lk450.drv
[keyboard] keyboard.dll=kbdus450.dll
[386Enh] keyboard=LK450.386
The DECUServe Journal July, 1994 Page 19
LK450 Keyboard
Running Windows for Workgroups this does not work well for me. The top
row keys are mostly dead (don't recall if it works with Reflections or
eXcursions in that mode). This is with the DEC light off or on.
However, if I change:
[boot] keyboard.drv=keyboard.drv
and leave the rest the same, the keys F14-F17 start working again
in my non-DEC apps (Uniface in particular) (though F18, F19 and F20 do
not). I discovered this completely by accident.
Does this make any sense? What does the above combination do?
Is there any simple way to write my own windows driver for the thing
where I can assign keys anyway I want (would DEC give away the source
to theirs so I could change it, or find someone to? If it's
"unsupported" what's to loose?)
Note 719.3, 13-May-1994
Kennedy: What I think
---------------------
> Running Windows for Workgroups this does not work well for me. The top
> row keys are mostly dead (don't recall if it works with Reflections or
> eXcursions in that mode). This is with the DEC light off or on.
I believe that only applications that know how to ask for DEC-style keyboard
mapping will get such mapping in the above configuration. If DEC is doing what
I think they are, the DEC light should stay off.
> and leave the rest the same, the keys F14-F17 start working again
> in my non-DEC apps (Uniface in particular) (though F18, F19 and F20 do
> not). I discovered this completely by accident.
What do you mean by "working"? I would think that using the standard
keyboard.drv would give you additional scan codes, but that they wouldn't be
mapped to anything.
> Is there any simple way to write my own windows driver for the thing
> where I can assign keys anyway I want (would DEC give away the source
> to theirs so I could change it, or find someone to? If it's
> "unsupported" what's to loose?)
Assuming you have the Microsoft Windows DDK (not SDK) and sign a
non-disclosure with DEC, you would have all the information you would need to
write
such a driver. Whether you could coerce apps you don't have the source for to
cooperate with such a driver better than they cooperate with DEC's is another
matter (as is the skill set needed to develop such a driver). If you want to
pursue this, let me know and I'll point you at the right folks.
The DECUServe Journal July, 1994 Page 20
LK450 Keyboard
Note 719.4, 14-May-1994
Ferguson: More info
-------------------
> What do you mean by "working"? I would think that using the standard
> keyboard.drv would give you additional scan codes, but that they wouldn't be
> mapped to anything.
You're right, they are not "working" correctly. It goes something like
F13-F17 overlap F3-7 or something like that in terms of what codes are
visible to Uniface (my real problem).
I do not understand all the terminology so bear with me. I have this
example Quick C program that when I run in this configuration it shows
three numbers in the KEYDOWN event. Setup with
"Keyboard.drv=Keyboard.drv", For F17 it shows "76,1,141". For F7 it
shows "76,1,41". It appears the part Uniface is seeing is the "76"
(plus shift state, etc.) and not the difference in the 141 vs. 41.
This is all supposition of course.
PF1 (for example) return 90,1,145 and it is (apparently) interpreting
the "90" as Numlock and discarding it.
When I switch to "Keyboard.drv=LK450.drv" with the latest driver, F17
comes out as "E3,1,141" which falls in the "OEM specific" category and
is presumably being discarded by Uniface. PF1 still returns the same
and is being discarded because it is Numlock.
> Assuming you have the Microsoft Windows DDK (not SDK) and sign a non-dis-
> closure with DEC, you would have all the information you would need to write
> such a driver.
I have none of that, but presumably we only have to decide how much it
is worth and buy each (including hiring someone to write it).
Does this mean Digital is likely to cooperate?
Presuming I have done something like this, causing keys to return
different codes so I can "see" them. I presume this drive would have
no awareness of what applications are running? In other words, by
fixing Uniface in this fashion, I probably break Reflections (for
instance)?
Alternate question: This little QuickC program shows it is simple to
write a program to see the events directly. Is there someway I can
write such a program that somehow stands between the driver and Uniface
(and only between it and Uniface) so it could change some particular
key types on the fly and leave others alone? I'm perfectly happy to
map them to some legitimate key sequence like alt-shift-something that
we do not otherwise need, but which Uniface can "see". Kind of a hook
into the process that gives keyboard I/O to Uniface?
The obvious answer is to attack Uniface to provide more full support.
However it appears that not enough of their customers use the LK450 to
generate any interest from them at all in doing so. Since about 30% of
The DECUServe Journal July, 1994 Page 21
LK450 Keyboard
their customers (they say) are VMS based, makes me wonder about how
frequently people use LK450's even in DEC shops.
Note 719.5, 14-May-1994
Kennedy: Yet more
-----------------
> Does this mean Digital is likely to cooperate?
Quite possibly. After all, they talked to me...
> Presuming I have done something like this, causing keys to return
> different codes so I can "see" them. I presume this drive would have
> no awareness of what applications are running? In other words, by
> fixing Uniface in this fashion, I probably break Reflections (for
> instance)?
Mostly. The LK450+driver combo should have the non-IBMPC-compatible keys
"dead" unless an app specifically asks for them to be enabled, at which point
they should return unique codes. The real solution is to fix the apps. Vendors
may or may not do this for DEC, but as international demand for their products
grows, they will be faced with decoding additional scan codes (especially in
the Far East markets), and eventually they'll use a keyboard definition map
rather than hard-coding the map in their application. Of course, this may take
a while 8-).
> Alternate question: This little QuickC program shows it is simple to
> write a program to see the events directly. Is there someway I can
> write such a program that somehow stands between the driver and Uniface
> (and only between it and Uniface) so it could change some particular
> key types on the fly and leave others alone?
The problem is that the keyboard is only "owned" by the Uniface app when
the pointer is in the Uniface window(s). I don't know if you have all the info
you need to detect that externally. For an example of how it works, fire up
some DECterms on a DECwindows display and hit No Scroll. Then move the mouse
around and note that the No Scroll LED goes on and off when focus moves into
and out of the held window.
> However it appears that not enough of their customers use the LK450 to
> generate any interest from them at all in doing so. Since about 30% of
> their customers (they say) are VMS based, makes me wonder about how
> frequently people use LK450's even in DEC shops.
We got our first (and last) LK450 when we DECmailered an LK250. Since then
we've been hoarding the LK250's and buying more on the used market. Nobody
here likes the LK450.
Note 719.6, 14-May-1994
Youdelman:
----------
Perhaps a "LK4250" (so to speak) would solve some of these problems?
I don't recall, how accessible is the LK450's firmware? Hopefully it's
The DECUServe Journal July, 1994 Page 22
LK450 Keyboard
not ROM inside in a one-chip-does-it-all custom package..
Note 719.7, 15-May-1994
Brown: It might not be too late ...
-----------------------------------
You should have come to the Vancouver symposium. DEC Canada Refurbished
Products was selling new LK250s (without cables) for CAD25.00 each.
Try calling Brian Lamothe at (613)591-4654.
Note 719.8, 15-May-1994
Kennedy: Thanks!
----------------
Thanks! I'll try calling and see if there are any left. If there are, and the
number is larger than our needs, I may just pick 'em all up and make 'em avail-
able at cost to other folks here.
Note 719.9, 16-May-1994
Matuscak: Custom map??
----------------------
> The problem is going with industry standard keyboards makes for a tough
> transition in Reflections (or equivalent) for VT users.
Actually, one of the nice things about Reflections is its ability to
redefine the keyboard. Rather than screw with the funky DEC keyboards,
I made a custom keymap for Reflection and just put it on the network as
the default. It puts VT f6 thru f20 across the top row of PC F keys,
and maps the editing keypad to the "correct" spots, and makes the PC
keypad "+" key VT , and ALT+ VT KP-. Its actually pretty painless to
go from the VT to the R2 custom map.
PATHWORKS Printing Problem
==========================
Here is another item from the PATHWORKS conference, wherein a
well-known problem with printing PostScript files is hunted down and
squashed. Participants include Carl Nelson, John Saunders, and Mike
Stewart of Digital PATHWORKS Support.
Note 717.0, 12-May-1994
Nelson: Works/Pathworks problem...
----------------------------------
I am having a problem with Pathworks- actually a combination of PC and
Mac. Our PC's connect to queues on our VAX which are connected to Apple
Laserwriters via Shiva Fastpaths. We recently upgraded our Mac
Pathworks from V1.0 to V1.2.
Our PC clients who are using MicroSoft Works to print to the
The DECUServe Journal July, 1994 Page 23
PATHWORKS Printing Problem
laserwriters are now getting "PostScript Errors: Error:
OffendingCommand:" sheets instead of their documents as they had
before. I now have them using the "wrapped" (tty) port, but they lose
their formatting.
We are using Pathworks for DOS V4.0, for Mac V1.2, and it doesn't
matter what version of Works we are running.
Note 717.1, 13-May-1994
Saunders: Which Command?
------------------------
Can you post the offending command?
Note 717.2, 17-May-1994
Stewart: OOLLDD problem
-----------------------
This is a known issue. 1.0 used to filter out ALL control-D characters
(something that DOS/Windows print jobs love to stick on the end because
they think all printers in the DOS world are locally attached). We
stopped filtering them ALL because they are valid in a bitmap. So we
filter them from beginning and end of job. Please get the latest ECO for
the printing SW CSCPAT_3101
Note 717.3, 25-May-1994
Nelson: Got patch, still have problem.
--------------------------------------
Thanks, Mike, we got the patch and installed it (CSCPAT 3101 V1.1).
Unfortunately, though, it did not fix the problem. Interesting to note
that the release notes for this patch did not mention this particular
problem. (We installed it anyway out of hope and the need to support
(soon) printers which had descriptions in this patch.)
Note 717.4, 31-May-1994
Nelson: Problem resolved!
-------------------------
Problem resolved. I searched around and found that the problem was that
there WAS a ^D character embedded in the data stream to the printer
(Not as part of a bitmap). I looked in the works directory, and found
several files with the extension .INI. I looked at these and found that
they were files which were simply 'dumped' before the main text, and
that the ^D character was the last character in each file. I edited
them out, and NO MORE ERRORS! ** WHEW! **
BPSG Licensing Question
=======================
The following discussion concerns software licensing, an
ever-popular topic for the Business Practices Service Group (BPSG)
The DECUServe Journal July, 1994 Page 24
BPSG Licensing Question
in DECUS. It concerns the licensing implications of an in-cabinet
upgrade of an OpenVMS VAX system, and took place, quite naturally,
in the BUSINESS_PRACTICES conference.
Participants: David Campen, Bill Mayhew (BPSG Chair), Pete
Sivia (BPSG Licensing Issue Manager), Matthew Wilbert.
Note 422.0, 2-Jun-1994
Wilbert: In-cabinet upgrade of Vax 6620 has me confused. Help!
----------------------------------------------------------------
I am finding it hard to understand exactly what is involved from a
licensing standpoint in doing an in-cabinet upgrade of a VAX 6620 to
a VAX 6630 or 6640. I know Digital has part numbers for these
upgrades which take care of the operating system related licensing
issues, and in the past this is how we have done our upgrades; it is
simple.
Now I am looking at alternatives, but I am realizing that I don't
understand everything I have to buy if I am buying it in pieces. It
seems clear that I can buy the processor boards. My impression is
that as soon as such a board is installed in my 6620, it is, for these
purposes, a new machine, and it needs a completely new VMS license (I
have a 2400 unit PAK from when it was a 6440--we previously
"downgraded" to a 6620--so I assume it would run, but I need to be
legal). I think this approach is logical when changing one box out
for another (because you can transfer the VMS license to the new owner)
but when upgrading a single machine it appears that considerable value
is lost.
What I am unclear on:
1) What besides the VMS license do I need to replace (DECNET,
VAXCLUSTER?)
2) Is there any standard trade-in allowance on these things, or are
they negotiable, or are they non-negotiable?
3) Is there any way the (relatively) new user-based licenses can help
me in this situation? I can't see any, but that's why I am asking.
4) The bottom line: does it make sense to consider doing this in an
unbundled fashion at all?
Note 422.1, 3-Jun-1994
Bill Mayhew: Should not be a problem
------------------------------------
There are a-la-carte upgrade licenses that you can buy when you add a
CPU to an SMP machine like a 66x0. These are listed in the price book
(which I don't have a current copy of) and they take into account the
value of your existing license.
I believe this is true for OpenVMS, DECnet, and VAXcluster software.
The DECUServe Journal July, 1994 Page 25
BPSG Licensing Question
I'm trying to remember what the situation is for layered products and I
can't remember clearly enough to say... Pete, are you watching this?
Note 422.2, 3-Jun-1994
Sivia: Info
-----------
> 1) What besides the VMS license do I need to replace (DECNET,
> VAXCLUSTER?)
DECnet, VAXcluster, and all layered products, must have the appropriate
number of units to run on the 66xx. For layered products, the 6620
needs 1800 license units; the 6630 or 6640 needs 2400. Don't forget
your third party software vendors may also want you to upgrade their
software licenses.
> 2) Is there any standard trade-in allowance on these things, or are
> they negotiable, or are they non-negotiable?
DEC's standard discounts apply. If you get DEC to give you more via an
allowance, go for it. Remember, too, DEC's fiscal year ends on July 2,
1994, so the sales reps undoubtedly are interested in "deal making".
If you go third party, you'll need to make sure that you follow the
details of DEC's "Software License Transfer Policy" [see page 6.18 of
the April 11, 1994, US Systems/Service Price List for a copy] and have
the relicense forms filled out and approved by Digital and you will
have to pay the relicensing fee (still $300/product as I recall).
> 3) Is there any way the (relatively) new user-based licenses can help
> me in this situation? I can't see any, but that's why I am asking.
If you can act by July 1, 1994, DEC will move your operating system and
layered product licenses from the 6620 to the 6630 or 6640 at no
additional cost. You'll have unlimited licenses on the new system if
you had unlimited licenses on the 6620. DEC refers to this as the
"Momentus offer". See the DEC Customer Update of February 28, 1994, for
details. Note in particular that you must upgrade your software on the
same purchase order as the system upgrade.
Note that there exists a 75% conversion credit for layered product
licenses that has been temporarily superseded by the "Momentus" offer.
However, there is no program to convert or trade-in capacity operating
system licenses for user-based operating system licenses.
> 4) The bottom line: does it make sense to consider doing this in an
> unbundled fashion at all?
To figure out unbundled vs. bundled, verify the unbundled against these
part numbers and prices:
o For a 6620 to 6630 upgrade from DEC, it's part number 66CUA-AM, list
price of $46,500 as of 11-APR-94, which includes CPU module, unlimited
user VMS, Rdb runtime, and DECnet Full-Function licenses.
The DECUServe Journal July, 1994 Page 26
BPSG Licensing Question
o For a 6630 to 6640 upgrade from DEC, it's part number 66DUA-AM, list
price of $46,500. Includes same as above.
Note 422.3, 13-Jun-1994
Campen: DEC's Refurbished Equipment Group
-----------------------------------------
When I upgraded from a 6310 to a 6410 I purchased the CPU board from a
used equipment dealer and paid DEC to upgrade my VMS and DECnet
licenses. The only reason I did it this way though was because of my
company's byzantine purchasing regulations. It would have been cheaper
to buy everything via DEC's Refurbished Equipment program. They
essentially throw in the hardware for the cost of the licenses.
I originally tried to buy from DEC Refurbished Equipment but out DEC
salesman did not understand the program and kept insisting that the
Refurbished Equipment groups price was just for hardware and didn't
include VMS and DECnet. By the time he figured out what he was doing I
was out of time so I paid him for the licenses and bought the hardware
elsewhere.
For VMS and DECnet license upgrades we got a credit for 75% of the
value of the existing 6310 licenses applied to the cost of the 6410
licenses.
Frame Relay
===========
If you've been wondering (worrying?) about frame relay
technology lately, this may be interesting reading. Shawn Allin,
Barton Bruce, Scott Burns, Linwood Ferguson, Matt Holdrege, Hal
Kuff, Gregg Nelson, Kevin Roels, and Glenn Zorn discuss implications
for LAT, routing, and performance in the DEC_NETWORKING conference.
Note 1063.0, 28-May-1994
Kuff: Frame or not Frame
------------------------
We need to connect our Corp office in Maryland with offices in
Florida, California, Michigan, and Texas.
We want to run LAT sessions and later Pathworks (very lite traffic,
just copy over a spread sheet every now and then, and E-mail).
We could go leased line analog (but what about Pathworks), or we
could go X.25 packet over Tymnet or Compuserve (doesn't that cost $50/day
per dialup, or a pad) or couldn't we go Frame and do better?
I am pondering a T1 to a carrier such as Cable and Wireless, and
56kb from each office to the local POP. I understand CIR, but what's this
about a CIR=0? Also can't we get a monthly rate, so we don't have to
pay per packet?
What vendors would you recommend?
The DECUServe Journal July, 1994 Page 27
Frame Relay
Note 1063.1, 29-May-1994
Holdrege: frame relay
---------------------
With your geography, frame relay might be the best choice. You pay by
month, not by the packet.
I would invite AT&T, Sprint, MCI & Wiltel in for a meeting to tell you
about their service. I can't tell who might be the best fit for you.
You will hear interesting things about zero CIR from each of them.
Native LAT will not work over frame relay. I use DECNET and TCP/IP
only.
Note 1063.2, 29-May-1994
Ferguson: Why not LAT?
--------------------------------------------------------------------------------
> Native LAT will not work over frame relay. I use DECNET and TCP/IP
> only.
Why?
I have no technical knowledge of it, but when I was discussing it with
various people this was never mentioned.
Note 1063.3, 30-May-1994
Nelson: Frame Relay: Bridge, Route, or Both?
--------------------------------------------
Yes, I'm very much interested in this answer myself. We are installing
frame relay circuits to tie six different sites together and were led to
believe one could bridge or route over frame relay.
Are you saying frame relay will only route?
Note 1063.4, 31-May-1994
Allin: Bridging will work
-------------------------
We're currently running a Frame Relay pilot here in Canada with
Bell/Stentor's "HyperStream" offering. We've had the option to either
bridge or route, the Frame Relay part is transparent.
Note 1063.5, 31-May-1994
Roels: Bridge or Route, not both...
-----------------------------------
If I understand it correctly, frame relay circuits/end-points must
either be addressed separately (like different subnets in a routed
network), or all the same (like a bridged network). If you were to
install the standard frame relay network to run a routed network, a
bridged protocol such as LAT would not be able to traverse the links.
It can be encapsulated within IP packets (ala cisco router style, for
instance), but then it is no longer a native implementation, and adds
The DECUServe Journal July, 1994 Page 28
Frame Relay
complexity.
I'm not an expert on this, so don't take it as gospel. This is one of
the reasons given to me.
Note 1063.631-May-1994
Zorn: LAT usable but not guaranteed
-----------------------------------
We are running FR here, with a PVC as the backup to our dedicated T1.
The problem with FR is it will not guarantee packets on the network and
the response time is not smooth. We have used LAT on it when our T1
was out but it did not always stay up. Go with IP.
Our London, England office has dialup lines that connect via IP to
our systems in the US. Round trip time for a packet is around 250 ms
which our clients over there can deal with, since they used to use
TELNET or trans-Alantic dialup before.
Note 1063.7, 31-May-1994
Burns: You Can Do Both
----------------------
Frame works much like X.25. You address the remote end (it's DLCI number)
then within that DLCI you can have multiple PVC's. So One PVC could have
bridging, one IP routed, one DECnet routed etc. We are running on the Canadian
Bell offering as well in test mode. We have Bridging, DECnet and IP over the
same link at the same time. We are evaluating Cisco and Xyplex. Each allow
some type of prioritization of packets so make the routed protocols a low
priority and LAT (bridging high) and all should be OK. We are running on
this on speeds from 56KB to T1.
Note 1063.8, 2-Jun-1994
Holdrege: clarification
-----------------------
Sorry about saying that native LAT would not work. It can be made to
work, but everyone I have talked to say that performance is terrible
and I should route. Of course if you route, you would need to
encapsulate LAT (which can be hairy) or use CTERM or telnet.
Note 1063.9, 19-Jun-1994
Bruce: get cisco protocol translation
-------------------------------------
cisco's 3rd tier 2501 software only lists at $700 more than the 2nd tier
you must have to support Decnet. That 3rd tier includes protocol translation
between LAT|X.25|Telnet sessions.
Each router has hardware that lists at $995. the 3rd tier s/w is $3000.
The bummer is that you really should get 9.21 or better 10.0 software,
and only 9.14 runs with the native 2 meg ram. Now you MUST populate
the single SIMM socket with a 4 meg (or 16 meg) 36 bit 72 pin simm.
The DECUServe Journal July, 1994 Page 29
Frame Relay
BUT, for this commodity class item anyone can get for ~$175, cisco
will charge $700 at list!, or 'only' $1500 for the 16 meg one.
You can order the router for use with the newer s/w but without THEIR
rip-off SIMM. I think it comes with a minimal net boot image or something.
I simply have ordered 9.14 s/w (which does fit and they can run final
test/burn-in on) with the newer (9.21 or 10.0) manuals. You can FTP
the newer s/w from cio.cisco.com and COPY TFTP FLASH after you load in
a SIMM. You will need to use a DIFFERENT image name as their
default has a few too many periods :-( for a VAX. The first file
in FLASH is what gets booted and you can pick the name.
Remember that cisco stopped autoshipping manuals because many sites
have 10 or 100 times as many routers as places to possibly use manuals.
You ARE welcome to the FREE, but MUST explicitly request them on the order -
get the ones for the 10.0 s/w which should just now be available.
You may also substitute cdrom for paper. If you have your routers on
'SMARTNET' service, you can always get some newer manuals free, anyway.
That price was the ethernet with no ISDN-BRI box. Anything else costs $more$.
About the DECUServe Journal
===========================
Publication Information
Topic threads in the DEC Notes conferences on DECUServe are
selected for publication on the basis of strong technical content
and/or interest to a wide audience. They are submitted to the
editor from various sources, including DECUServe Moderators,
Executive Committee members, and other volunteers. Suggestions for
inclusion are enthusiastically solicited. Articles selected for
publication are edited on an OpenVMS VAX system in TPU and then
formatted with Digital Standard Runoff.
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, of DECUS, or of
DECUServe, unless specifically stated. Content has been deemed
acceptable by the DECUServe Moderators according to the DECUServe
Canons of Conduct.
How Can I Use DECUServe?
DECUServe is available 24 hours a day, seven days a week,
except for the last Thursday of every month at 5:00 p.m. Eastern
time for backups. Membership is by individual subscription only;
the current annual fee is US$75.00.
The DECUServe Journal July, 1994 Page 30
About the DECUServe Journal
On-line subscription information is available in the U.S. by
dialing 1-800-521-8950 and logging in with username INFORMATION.
DECUServe and the INFORMATION account can also be reached on the
Internet via telnet connection to decuserve.decus.org.
Contact Information
===================
The editors of the DECUServe Journal are Brian and Sherrie
McMahon. They can be reached by any of the following means:
mcma...@decuserve.decus.org
mcma...@decuserve.decus.org
mcma...@decus.org
grif...@decus.org
mcm...@ac.grin.edu
grif...@ac.grin.edu
+1 515 269 4901 (normal office hours, U.S. Central time)
+1 515 269 4936 FAX