[Info-vax] Is OpenVMS 8.4 ready for production

Post by bert
Hello,
I am considering running VMS 8.4 (ia64) in a production environment in
order to take advantage of running clusters over IP. To that effect I
am looking for any feedback (positive or negative) on deploying and
running VMS 8.4 in a production environment.
thanks,

How do you expect to benefit from clustering over IP instead of DECnet?
As far as I know neither 8.4 nor clustering over IP have any "track
record" to speak of. Traditional clustering has something like 25 or
more years of "track record".

How do you justify the risk of adopting clustering over IP? What does
it do that traditional clustering does not?

I would want to run it in a "test and development" environment for a
while before running it in production! It may be the greatest thing
since sliced bread. Then again, it may not!

If you install it in production and it falls on its face, you will have
egg all over your face! There are lots of people who would be thrilled
to replace you!

Arne Vajhøj

2010-10-17 01:38:23 UTC

Post by bert
I am considering running VMS 8.4 (ia64) in a production environment in
order to take advantage of running clusters over IP. To that effect I
am looking for any feedback (positive or negative) on deploying and
running VMS 8.4 in a production environment.

How do you expect to benefit from clustering over IP instead of DECnet?
As far as I know neither 8.4 nor clustering over IP have any "track
record" to speak of. Traditional clustering has something like 25 or
more years of "track record".
How do you justify the risk of adopting clustering over IP? What does it
do that traditional clustering does not?
I would want to run it in a "test and development" environment for a
while before running it in production! It may be the greatest thing
since sliced bread. Then again, it may not!
If you install it in production and it falls on its face, you will have
egg all over your face! There are lots of people who would be thrilled
to replace you!

The advice to test is good.

Especially since there has been some bug reports om 8.4.

But the use of IP has some organizational benefits. Most
network groups these days are IP only and not very
keen on other protocols.

Arne

Richard B. Gilbert

2010-10-17 02:01:54 UTC

Post by Arne VajhÃ¸j

How do you expect to benefit from clustering over IP instead of DECnet?
As far as I know neither 8.4 nor clustering over IP have any "track
record" to speak of. Traditional clustering has something like 25 or
more years of "track record".
How do you justify the risk of adopting clustering over IP? What does it
do that traditional clustering does not?
I would want to run it in a "test and development" environment for a
while before running it in production! It may be the greatest thing
since sliced bread. Then again, it may not!
If you install it in production and it falls on its face, you will have
egg all over your face! There are lots of people who would be thrilled
to replace you!

The advice to test is good.
Especially since there has been some bug reports om 8.4.
But the use of IP has some organizational benefits. Most
network groups these days are IP only and not very
keen on other protocols.
Arne

I don't see where he is going to need a lot of support from the network
group. If he has two Ethernet NICs in each box, he can connect two
boxes back to back with a "crossover" patch cord. I've done just that
with a pair of Alphas. Cluster traffic was handled over the patch cord
and was seldom or never seen on the local Ethernet. The other NIC in
each box connected the two machines to the local Ethernet.

With only one NIC in each box the switch is going to have to work a bit
harder but is still shouldn't be a problem.

FrankS

2010-10-17 12:11:55 UTC

Post by Richard B. Gilbert
I don't see where he is going to need a lot of support from the network
group. If he has two Ethernet NICs in each box, he can connect two
boxes back to back with a "crossover" patch cord.

What if two or more cluster nodes are physically seperated by a
distance greater than the length of any known patch cord?

Jan-Erik Soderholm

2010-10-17 14:51:14 UTC

Post by FrankS

What if two or more cluster nodes are physically seperated by a
distance greater than the length of any known patch cord?

If I remember correctly from the TUD, the current recomended max
distance for IPCI is 100 Km. The "widest" cluster in Stockholm
seemed to be 25 Km, but not running IPCI at the moment, as far
as I understood.

Post by FrankS
How do you justify the risk of adopting clustering over IP?
What does it do that traditional clustering does not?

IPCI runs over IP-only networks.
Isn't that the only reason there *is* an IPCI at all ?

There was some talk about running IPCI over public IP networks.
IPCI (or SCS) *as such* has no encryption. There was some
slides showing different ways of encrypting your IPCI traffic
including IPsec enabled routers or running IPsec on VMS itself
(not "today", of course, "next year" was mentioned).

You can always (as today with SCS over LAN) setup VLAN's, but using
VLAN's to run IPCI is a but counter-productive, if you use VLAN's,
you can just as well run SCS over LAN.

Post by FrankS
Q: Is there anyone here running 8.4 in a production environment?

One major interest for 8.4 is running VMS under HP-VM. One
customer/site running VMS under HP-VM reported on the TUD that
"VMS is VMS". You can not see any difference between a VMS system
under HP-VM from a VMS system running on it's own Hardware.
There is some command you can use from DCL to tell if your're
a HP-VM guest, if you need to know. As far as I understod, VMS
under HP-VM is in use at some customers/sites.

There are some benefits regarding licensing when running
VMS as a guest under HP-VM, since you only licens as much as
you have allocated for each specific VMS instance. And the
VMS licenses has changed from "per core" to "per CPU" which
in effect (using the new 4-core IA64) meens lower cost
for more performance. YMMV, of course.

Richard Maher

2010-10-17 21:39:19 UTC

Hi Jan-Erik,

Post by FrankS

What if two or more cluster nodes are physically seperated by a
distance greater than the length of any known patch cord?

Post by FrankS
How do you justify the risk of adopting clustering over IP?
What does it do that traditional clustering does not?

December? July? Q1? - "next year"

Cheers Richard Maher

Richard Maher

2010-10-17 21:39:19 UTC

Hi Jan-Erik,

Post by FrankS

What if two or more cluster nodes are physically seperated by a
distance greater than the length of any known patch cord?

Post by FrankS
How do you justify the risk of adopting clustering over IP?
What does it do that traditional clustering does not?

December? July? Q1? - "next year"

Cheers Richard Maher

Bob Koehler

2010-10-18 15:06:12 UTC

Post by Jan-Erik Soderholm
You can not see any difference between a VMS system
under HP-VM from a VMS system running on it's own Hardware.

Unless you are sensitive to timing issues that belong to markets
DEC long ago untargetted for VMS. But still works damn good on
it's own hardware.

JF Mezei

2010-10-17 20:48:39 UTC

Post by FrankS
What if two or more cluster nodes are physically seperated by a
distance greater than the length of any known patch cord?

Ethernet connectivity is available across a country now.

And if you don't want to pay for that, you can get a router to establish
an L2TP tunnel over an IP network to connect 2 LANs into one logical
ethernet segment.

John Wallace

2010-10-17 21:07:28 UTC

Post by FrankS
What if two or more cluster nodes are physically seperated by a
distance greater than the length of any known patch cord?

Ethernet connectivity is available across a country now.
And if you don't want to pay for that, you can get a router to establish
an L2TP tunnel over an IP network to connect 2 LANs into one logical
ethernet segment.

What is technically possible and what any given company policy permits
can be very different. There are plenty of companies where something
as simple and harmless as connecting an unauthorised switch to the
network is a breach of policy. Sometimes there are good reasons for
this, often there are not. "Because IT say so" has frequently become a
sufficient excuse tp not do something in a given way, even if a
business case can be made to show that the business would benefit from
doing things differently than "the IT way". Let's suppose a particular
hypothetical task can be done via either of two options. Option A
conforms to IT policy and costs $100K up front and maybe more later.
Option B provides an arguably better solution for the task at hand,
costs only a quarter of Option A with no ongoing costs, but requires
flexibility from the IT department on one of their core religious
beliefs (e.g. "our network must be IP only", "our servers must be
Windows only", whatever). Which one will win? I think we know.

Richard B. Gilbert

2010-10-17 23:57:28 UTC

Post by John Wallace

Post by FrankS
What if two or more cluster nodes are physically seperated by a
distance greater than the length of any known patch cord?

Ethernet connectivity is available across a country now.
And if you don't want to pay for that, you can get a router to establish
an L2TP tunnel over an IP network to connect 2 LANs into one logical
ethernet segment.

What is technically possible and what any given company policy permits
can be very different. There are plenty of companies where something
as simple and harmless as connecting an unauthorized switch to the
network is a breach of policy. Sometimes there are good reasons for
this, often there are not. "Because IT say so" has frequently become a
sufficient excuse tp not do something in a given way, even if a
business case can be made to show that the business would benefit from
doing things differently than "the IT way". Let's suppose a particular
hypothetical task can be done via either of two options. Option A
conforms to IT policy and costs $100K up front and maybe more later.
Option B provides an arguably better solution for the task at hand,
costs only a quarter of Option A with no ongoing costs, but requires
flexibility from the IT department on one of their core religious
beliefs (e.g. "our network must be IP only", "our servers must be
Windows only", whatever). Which one will win? I think we know.

Bottom line, IT works for the company and not the other way around!
If the boss says "Do it my way!" the IT guys can either do as they're
told or look for a new job! The state of the economy suggests that this
is a poor time to go looking for a new job!! It also suggests that
there is a good supply of people who WILL do what the boss wants done!

Arne Vajhøj

2010-10-18 01:02:20 UTC

Post by John Wallace
What is technically possible and what any given company policy permits
can be very different. There are plenty of companies where something
as simple and harmless as connecting an unauthorized switch to the
network is a breach of policy. Sometimes there are good reasons for
this, often there are not. "Because IT say so" has frequently become a
sufficient excuse tp not do something in a given way, even if a
business case can be made to show that the business would benefit from
doing things differently than "the IT way". Let's suppose a particular
hypothetical task can be done via either of two options. Option A
conforms to IT policy and costs $100K up front and maybe more later.
Option B provides an arguably better solution for the task at hand,
costs only a quarter of Option A with no ongoing costs, but requires
flexibility from the IT department on one of their core religious
beliefs (e.g. "our network must be IP only", "our servers must be
Windows only", whatever). Which one will win? I think we know.

Bottom line, IT works for the company and not the other way around!
If the boss says "Do it my way!" the IT guys can either do as they're
told or look for a new job! The state of the economy suggests that this
is a poor time to go looking for a new job!! It also suggests that there
is a good supply of people who WILL do what the boss wants done!

True.

But most bossed want to do things the standard way.

Either because they can see the future support problems
of all the one offs or because no one will blame them
if problem arise and they just went with the company
standard.

Arne

Arne Vajhøj

2010-10-18 01:00:49 UTC

Post by John Wallace
What is technically possible and what any given company policy permits
can be very different. There are plenty of companies where something
as simple and harmless as connecting an unauthorised switch to the
network is a breach of policy. Sometimes there are good reasons for
this, often there are not. "Because IT say so" has frequently become a
sufficient excuse tp not do something in a given way, even if a
business case can be made to show that the business would benefit from
doing things differently than "the IT way". Let's suppose a particular
hypothetical task can be done via either of two options. Option A
conforms to IT policy and costs $100K up front and maybe more later.
Option B provides an arguably better solution for the task at hand,
costs only a quarter of Option A with no ongoing costs, but requires
flexibility from the IT department on one of their core religious
beliefs (e.g. "our network must be IP only", "our servers must be
Windows only", whatever). Which one will win? I think we know.

Yes.

But often for good reasons.

Standardized solution make long term support a lot easier.

Sure this little 1K$ smart thingy is a lot cheaper than the
100 K$ standard thingy.

But what if the guy that brought the smart thingy into the
house get run over by a bus? Anybody else in the company
that can support the smart thingy?

When the entire company network get restructured in 2 years
will the smart thingy work in the new environment?

Etc.etc..

Arne

Arne Vajhøj

2010-10-17 13:39:37 UTC

Post by Arne VajhÃ¸j

How do you expect to benefit from clustering over IP instead of DECnet?
As far as I know neither 8.4 nor clustering over IP have any "track
record" to speak of. Traditional clustering has something like 25 or
more years of "track record".
How do you justify the risk of adopting clustering over IP? What does it
do that traditional clustering does not?
I would want to run it in a "test and development" environment for a
while before running it in production! It may be the greatest thing
since sliced bread. Then again, it may not!
If you install it in production and it falls on its face, you will have
egg all over your face! There are lots of people who would be thrilled
to replace you!

The advice to test is good.
Especially since there has been some bug reports om 8.4.
But the use of IP has some organizational benefits. Most
network groups these days are IP only and not very
keen on other protocols.

I don't see where he is going to need a lot of support from the network
group. If he has two Ethernet NICs in each box, he can connect two boxes
back to back with a "crossover" patch cord. I've done just that with a
pair of Alphas. Cluster traffic was handled over the patch cord and was
seldom or never seen on the local Ethernet. The other NIC in each box
connected the two machines to the local Ethernet.
With only one NIC in each box the switch is going to have to work a bit
harder but is still shouldn't be a problem.

If the location of the boxes allows that and if the network group
allows it, then that is also an option. But that was two if's.

Arne

Michael Moroney

2010-10-17 02:32:34 UTC

I've heard in this group that there are some lovely bugs in V8.4.
Set up and use a V8.4 test system before going into production.

Post by Richard B. Gilbert
How do you expect to benefit from clustering over IP instead of DECnet?

SCS (clustering) and DECnet are separate protocols, with nothing to do
with each other other than some VMS restrictions such as if you're running
DECnet in a cluster, the DECnet nodename and address must match the
cluster nodename and address.

IP is yet another protocol, however they've encapsulated SCS into IP
(UDP) packets, and have done something similar to DECnet as well.

b***@gmail.com

2010-10-17 06:17:29 UTC

Post by Michael Moroney

I've heard in this group that there are some lovely bugs in V8.4.
Set up and use a V8.4 test system before going into production.

Post by Richard B. Gilbert
How do you expect to benefit from clustering over IP instead of DECnet?

SCS (clustering) and DECnet are separate protocols, with nothing to do
with each other other than some VMS restrictions such as if you're running
DECnet in a cluster, the DECnet nodename and address must match the
cluster nodename and address.
IP is yet another protocol, however they've encapsulated SCS into IP
(UDP) packets, and have done something similar to DECnet as well.

Small correction: they have NOT done SCS over DECnet, AFAIK.

Bart

Wilm Boerhout

2010-10-17 06:48:02 UTC

Post by b***@gmail.com

Post by Michael Moroney

I've heard in this group that there are some lovely bugs in V8.4.
Set up and use a V8.4 test system before going into production.

Post by Richard B. Gilbert
How do you expect to benefit from clustering over IP instead of DECnet?

SCS (clustering) and DECnet are separate protocols, with nothing to do
with each other other than some VMS restrictions such as if you're running
DECnet in a cluster, the DECnet nodename and address must match the
cluster nodename and address.
IP is yet another protocol, however they've encapsulated SCS into IP
(UDP) packets, and have done something similar to DECnet as well.

Small correction: they have NOT done SCS over DECnet, AFAIK.
Bart

No, but I read something else in Michael's post: "they" have done DECnet
over IP as well as SCS over IP.

JF Mezei

2010-10-17 08:31:42 UTC

Post by Wilm Boerhout
No, but I read something else in Michael's post: "they" have done DECnet
over IP as well as SCS over IP.

But other have built routers that do L2TP which transport any ethernet
frame over IP. Yu can then go "native" with SCS over ethernet and mix
all your machines, including VAX at 7.3 in your cluster.

Arne Vajhøj

2010-10-17 13:43:53 UTC

Post by Michael Moroney

Post by Richard B. Gilbert
How do you expect to benefit from clustering over IP instead of DECnet?

SCS (clustering) and DECnet are separate protocols, with nothing to do
with each other other than some VMS restrictions such as if you're running
DECnet in a cluster, the DECnet nodename and address must match the
cluster nodename and address.
IP is yet another protocol, however they've encapsulated SCS into IP
(UDP) packets, and have done something similar to DECnet as well.

Yep.

6007, 6003 and 0800 are not identical.

Arne

Phillip Helbig---undress to reply

2010-10-17 09:24:22 UTC

How do you expect to benefit from clustering over IP instead of DECnet?

Two points. First, clustering and DECnet have practically nothing to do
with each other. (Yes, a satellite can "boot over DECnet", but a) this
really has nothing to do with DECnet and b) satellites can boot via MOP
with no DECnet at all. Apart from the limited application of
satellites, what does clustering have to do with DECnet?) Second,
running a cluster over IP might be the only option if only IP packets
are let through the network. Yes, DECnet is a networking protocol and
IP is as well, but either can be used within a cluster, between
clusters, between non-clustered nodes, between a cluster and a
non-clustered node etc.

Post by Richard B. Gilbert
As far as I know neither 8.4 nor clustering over IP have any "track
record" to speak of.

A common "problem" for new stuff.

Post by Richard B. Gilbert
Traditional clustering has something like 25 or
more years of "track record".

Yes, and it is good, but it is not an option in all environments.

Post by Richard B. Gilbert
How do you justify the risk of adopting clustering over IP? What does
it do that traditional clustering does not?

See above.

Post by Richard B. Gilbert
I would want to run it in a "test and development" environment for a
while before running it in production!

Sure.

Post by Richard B. Gilbert
It may be the greatest thing
since sliced bread. Then again, it may not!

Right.

Jose Baars

2010-10-17 10:51:11 UTC

In a test environment cluster over ip looks pretty good, we
only had some hard to reproduce boot issues when we
were trying unsupported things like having expected
votes set to 1 in a three node cluster.

Something under documented is that nodes that are on the
same(V)LAN, i.e. can communicate using traditional SCS
protocol will prefer to speak SCS to each other, in stead
of IP. On nodes that have IP clustering set up, both IP and
SCS channels are set up to nodes that are reachable by both
SCS and IP. On nodes that have no SCS connectivity to
other nodes, only the IP channel is set up. All nodes need to
see each other in some way, over at least one channel, whether
IP or SCS (CI, Memory channel, FDDI are not very widely
used anymore I guess).

Bob Koehler

2010-10-18 15:02:11 UTC

How do you expect to benefit from clustering over IP instead of DECnet?

No version of VMScluster ever shipped running over DECnet.
VMScluster protocols and DECnet protocols are different. When
run over ethernet they use different ethernet level protocol
numbers.

JF Mezei

2010-10-17 01:48:54 UTC

based on feedback heard here, the short answer is : <bold> NO </bold>

You should wait for 2 patch releases. (the first one won't fix all known
problems). You should wait until at least January, and check this
newsgroup often because new bugs may be discovered. The one with the
DIRECTORY command was only discovered after the final relese was shipped
to customers.

With regards to IP clustering, this only works if all of your nodes in
the cluster are capable of using IP clustering. (i.e.: 8.4).

Each node must have connectivity with all other nodes in the cluster. So
a node you upgrade to 8.4 with IP clustering will need require LAN
interconnect to see the unupgraded nodes in the cluster.

IP clustering only becomes interesting if you have only 8.4 nodes, all
with IP clustering configured/enabled. Only then is the requirement to
have LAN or other common interconnect removed.

Phillip Helbig---undress to reply

2010-10-17 09:19:09 UTC

In article

There has been a lot of discussion on comp.os.vms recently with regard
to the fact that 8.4 seems to be the most half-baked release in the
history of VMS, with apparently bumbling newbies screwing up stuff which
has worked for decades.

I can't comment on cluster over IP.

Question: Is there anyone here running 8.4 in a production environment?

Bob Gezelter

2010-10-17 11:57:24 UTC

bert,

Completely unrelated to 8.4, I have long generally recommended that
clients wait several months before starting to move production to a
new release. 8.4 is no different in this way than any other. In
situations where a specific new feature is critical to meeting a
business need, that rule can be finessed, but additional caution and
preparation for the unforeseen is highly recommended.

The citation is:

"Provides interoperability with servers running earlier versions of
OpenVMS Clusters that are LAN based. Cluster over IP is available only
with OpenVMS Version 8.4. Hence, if the node requires IP interconnect
to be a part of the cluster, then all the nodes of the cluster must be
running OpenVMS Version 8.4 and HP TCP/IP Services for OpenVMS,
Version 5.7. " [OpenVMS Cluster Systems, 3.3.3 System Characteristics]

The relevant words in the above passage are "if the node requires IP
interconnect to be part of the cluster, then all nodes must be running
OpenVMS Version 8.4 [RLG Note: or later] ..."

The simple answer is yes, nodes must be at 8.4. However, that is not
the complete story. I have not tested all of the possibilities, but
the phrasing implies that the actual issue might be more accurately
described in terms of maintaining quorum. Since all interconnects are
at least potentially used at all times, the case of a multi-
interconnect OpenVMS cluster allows one (or more) of the interconnects
to be out of server, scheduled or unscheduled, at various times.

This implies that the actual question is one of voting, not cluster
membership.

That said, in most configurations running OpenVMS clusters over IP, I
would probably opt to follow the "upgrade to 8.4, then enable IP
clustering" path.

- Bob Gezelter, http://www.rlgsc.com

JF Mezei

2010-10-17 20:43:03 UTC

Post by Bob Gezelter
The relevant words in the above passage are "if the node requires IP
interconnect to be part of the cluster, then all nodes must be running
OpenVMS Version 8.4 [RLG Note: or later] ..."

Say you have a 4 node cluster using SCS. Shouldn't you be able to
upgrade one node to 8.4 and enable IP clustering on it, while the rest
is still at 8.3 ? The new 8.4 node will still be able to talk to every
other node via ethernet and its IP clustering won't see any node.

Then, as you progressively upgrade other nodes, IP clustering would
start to be used between the 8.4 nodes.

Jan-Erik Soderholm

2010-10-17 21:02:44 UTC

Say you have a 4 node cluster using SCS.

Now, correct me if I'm wrong, but doesn't *all* clusters
use SCS as the cluster communication ? Then the SCS traffic can
go over CI, MC, FDDI, LAN or (now) IP, but it is always SCS, not ?
So you can't have a cluster *not* using SCS.

Post by JF Mezei
Shouldn't you be able to
upgrade one node to 8.4 and enable IP clustering on it, while the rest
is still at 8.3 ? The new 8.4 node will still be able to talk to every
other node via ethernet and its IP clustering won't see any node.

Right, if all nodes was/are on the same LAN they will continue to
use SCS over LAN.

Post by JF Mezei
Then, as you progressively upgrade other nodes, IP clustering would
start to be used between the 8.4 nodes.

No. Not until you move some node out of the "LAN". The PE driver
will select the path with lowest overhead and that is still
SCS over LAN before IPCI. And if you move one node out of the local
LAN, *it* will use *only* SCS/IP and the other will mix depending
on which node they are talking to (IP remote and LAN localy).

But yes, if you have one or more nodes that today are remote
using a VLAN or some other special setup, you can (when all
nodes have been upgraded) shut down the VLAN and let all SCS
traffic (to the "remote" nodes) go over plain-IP.

Bob Koehler

2010-10-18 15:07:22 UTC

Post by JF Mezei
Then, as you progressively upgrade other nodes, IP clustering would
start to be used between the 8.4 nodes.

Don't fool yourself into a false sense of success. Clustering
will prefer not to use IP as long as there is another path.

JF Mezei

2010-10-18 14:16:13 UTC

Post by Bob Koehler
Don't fool yourself into a false sense of success. Clustering
will prefer not to use IP as long as there is another path.

The text of the HP notes was misleading. You can enable IP clustering on
8.4 nodes even if there are 8.3 nodes on the cluster. (as long as the
8.4 node still has ethernet access to the others).

Where the "magic" begins is after you have all nodes in your cluster
with IP clustering enabled, you can then deploy a new node from a remote
location which requires IP clustering.

The notes should have been worder to state that the minute you have a
node whose sole means of communication is IP, then all others nodes must
also be at 8.4 with IP clustering enabled.

But as long as all nodes retain ethernhet conncetivity, the different
versions of VMS can coexist in the cluster.

Bob Koehler

2010-10-18 17:45:16 UTC

Post by Bob Koehler
Don't fool yourself into a false sense of success. Clustering
will prefer not to use IP as long as there is another path.

The text of the HP notes was misleading. You can enable IP clustering on
8.4 nodes even if there are 8.3 nodes on the cluster. (as long as the
8.4 node still has ethernet access to the others).

Yes, but if he wants to know that IP clustering is working he
needs to force at leas one node to stop running SCS directly on
the ethernet.

IanMiller

2010-10-17 20:07:25 UTC

Install V8.4 + the latest patch kit and your application and test it.
Don't rely on hearsay, half-truths nor other peoples testing.
Only your testing in your environment counts.

JF Mezei

2010-10-17 20:53:35 UTC

Post by IanMiller
Install V8.4 + the latest patch kit and your application and test it.
Don't rely on hearsay, half-truths nor other peoples testing.
Only your testing in your environment counts.

One needs to remember that not everybody has a test environment they can
play with. Not everyone runs VMS in a mission critical business with
large budgets that allow test environments.

And it is perfectly logical and good for someone to ask other users
about their experience/opinion of a new version. It at least allows that
person to tell their boss that 8.4 will require lots of testing and that
more human resources/man hours should be allocated to that uypgrade than
in previous ones.

Arne Vajhøj

2010-10-18 00:57:03 UTC

Post by IanMiller
Install V8.4 + the latest patch kit and your application and test it.
Don't rely on hearsay, half-truths nor other peoples testing.
Only your testing in your environment counts.

One needs to remember that not everybody has a test environment they can
play with. Not everyone runs VMS in a mission critical business with
large budgets that allow test environments.

But in that case you could argue that they have decided at
least implicitly that they can live with problems.

Arne

JF Mezei

2010-10-18 01:14:01 UTC

Post by Arne VajhÃ¸j
But in that case you could argue that they have decided at
least implicitly that they can live with problems.

nop. They may have decided to seek advise from the community on whether
a new version of the OS is ready for prime time or not.

The combined experience of the community provides greater analysis of
the quality of the new OS version than a single person could.

If you don't have a test environment, then you need to wait for others
to do the testing for you.

The Macro/Debug bug that mr Vaxman found may not affect me personally,
but it does point to a failed quality control and failed quality control
leads to lack of confidence in the OS.

Arne Vajhøj

2010-10-18 01:36:49 UTC

Post by Arne VajhÃ¸j
But in that case you could argue that they have decided at
least implicitly that they can live with problems.

nop. They may have decided to seek advise from the community on whether
a new version of the OS is ready for prime time or not.
The combined experience of the community provides greater analysis of
the quality of the new OS version than a single person could.
If you don't have a test environment, then you need to wait for others
to do the testing for you.
The Macro/Debug bug that mr Vaxman found may not affect me personally,
but it does point to a failed quality control and failed quality control
leads to lack of confidence in the OS.

Given that I was replying to:

#One needs to remember that not everybody has a test environment they can
#play with. Not everyone runs VMS in a mission critical business with
#large budgets that allow test environments.

then I don't understand your reply.

Arne

V***@SendSpamHere.ORG

2010-10-17 21:46:02 UTC

Post by IanMiller

Install V8.4 + the latest patch kit and your application and test it.
Don't rely on hearsay, half-truths nor other peoples testing.
Only your testing in your environment counts.

If he can get 'em. ;)

Sorry Ian, V.4 is full o' bugs.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

Arne Vajhøj

2010-10-18 00:56:01 UTC

Post by IanMiller

Install V8.4 + the latest patch kit and your application and test it.
Don't rely on hearsay, half-truths nor other peoples testing.
Only your testing in your environment counts.

I don't agree.

Other peoples experience does count towards a general
impression of the quality.

It is not very realistic to be able to test absolutely
everything, so general quality impression can supplement
own test results.

Arne

vancouver

2010-10-20 12:53:21 UTC

Post by IanMiller

Install V8.4 + the latest patch kit and your application and test it.
Don't rely on hearsay, half-truths nor other peoples testing.
Only your testing in your environment counts.

Best advice I have seen yet...
Regards

Guy Peleg

2010-10-18 15:53:34 UTC

I would say it depends on the size of your hardware. If you are using
a small
box, say rx2600, test it make sure it works and go ahead. If you are
using a large
integrity box, I would advise against it.

A customer we worked with recently went live with OpenVMS V8.4 on
BL870c i2,
they were forced upgrading to V8.4 because of the hardware. They went
back
to the old computer the next day.

fwiw,

Guy Peleg
Maklee Engineering
www.maklee.com

Simon Clubley

2010-10-18 16:32:20 UTC

Post by Guy Peleg
A customer we worked with recently went live with OpenVMS V8.4 on
BL870c i2,
they were forced upgrading to V8.4 because of the hardware. They went
back
to the old computer the next day.

Are you allowed to say what problem actually caused the decision to
be taken to revert to the old hardware ?

Thanks,

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

V***@SendSpamHere.ORG

2010-10-18 20:59:59 UTC

Are you allowed to say what problem actually caused the decision to
be taken to revert to the old hardware ?

Guy sent me a private email detailing it. Essentially, it is the problem
he mentioned here a few days ago.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

Simon Clubley

2010-10-19 11:19:35 UTC

Are you allowed to say what problem actually caused the decision to
be taken to revert to the old hardware ?

Guy sent me a private email detailing it. Essentially, it is the problem
he mentioned here a few days ago.

Thanks for the feedback.

I take it this is the hanging I/O problem when using mailboxes ?

If the nature of the problem is such that even Guy cannot work around
it or get a fix from HP in a reasonable amount of time, then what hope
is there for a normal VMS site ?

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

JF Mezei

2010-10-19 11:44:46 UTC

Post by Simon Clubley
If the nature of the problem is such that even Guy cannot work around
it or get a fix from HP in a reasonable amount of time, then what hope
is there for a normal VMS site ?

8.3 is still working.

When VMS 5.0 came out, they had not gone through a complete blood as has
happened in the past 12 months with a new engineering team. Yet, 5.0 has
serious problems. (lookup "VAXORCIST" :-)

So, 8.4 has many problems. Give the newbies 2 patch cycles to see how
many self inflicted problems they can fix.

Of course, there won't be any hobbysist to test the patches to tell real
customers whether they are worth installing or not.

Jan-Erik Soderholm

2010-10-19 11:52:45 UTC

Post by Simon Clubley
If the nature of the problem is such that even Guy cannot work around
it or get a fix from HP in a reasonable amount of time, then what hope
is there for a normal VMS site ?

8.3 is still working.
When VMS 5.0 came out, they had not gone through a complete blood as has
happened in the past 12 months with a new engineering team. Yet, 5.0 has
serious problems. (lookup "VAXORCIST" :-)
So, 8.4 has many problems. Give the newbies 2 patch cycles to see how
many self inflicted problems they can fix.
Of course, there won't be any hobbysist to test the patches to tell real
customers whether they are worth installing or not.

JF, That is the most reasonable you've written in a while... :-)

I don't see any particular specific with this release.
If you do not *need* any of the new stuff in 8.4, there
is no rush, is there ?

V***@SendSpamHere.ORG

2010-10-19 12:32:27 UTC

Post by Simon Clubley
If the nature of the problem is such that even Guy cannot work around
it or get a fix from HP in a reasonable amount of time, then what hope
is there for a normal VMS site ?

8.3 is still working.
When VMS 5.0 came out, they had not gone through a complete blood as has
happened in the past 12 months with a new engineering team. Yet, 5.0 has
serious problems. (lookup "VAXORCIST" :-)
So, 8.4 has many problems. Give the newbies 2 patch cycles to see how
many self inflicted problems they can fix.
Of course, there won't be any hobbysist to test the patches to tell real
customers whether they are worth installing or not.

Which has been my impression in the past. Hobbyist aren't running production
systems and can risk installing the latest and not so greatest. They'll find
bugs, make them known and, hopefully, a better product in the end.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

Arne Vajhøj

2010-10-20 02:33:46 UTC

Post by Simon Clubley
If the nature of the problem is such that even Guy cannot work around
it or get a fix from HP in a reasonable amount of time, then what hope
is there for a normal VMS site ?

8.3 is still working.
When VMS 5.0 came out, they had not gone through a complete blood as has
happened in the past 12 months with a new engineering team. Yet, 5.0 has
serious problems. (lookup "VAXORCIST" :-)
So, 8.4 has many problems. Give the newbies 2 patch cycles to see how
many self inflicted problems they can fix.
Of course, there won't be any hobbysist to test the patches to tell real
customers whether they are worth installing or not.

They will just not be able to get the fix for the bug .....

Arne

Richard B. Gilbert

2010-10-20 04:53:41 UTC

Post by Arne VajhÃ¸j

Post by Simon Clubley
If the nature of the problem is such that even Guy cannot work around
it or get a fix from HP in a reasonable amount of time, then what hope
is there for a normal VMS site ?

8.3 is still working.
When VMS 5.0 came out, they had not gone through a complete blood as has
happened in the past 12 months with a new engineering team. Yet, 5.0 has
serious problems. (lookup "VAXORCIST" :-)
So, 8.4 has many problems. Give the newbies 2 patch cycles to see how
many self inflicted problems they can fix.
Of course, there won't be any hobbysist to test the patches to tell real
customers whether they are worth installing or not.

Which has been my impression in the past. Hobbyist aren't running
production
systems and can risk installing the latest and not so greatest.
They'll find
bugs, make them known and, hopefully, a better product in the end.

They will just not be able to get the fix for the bug .....
Arne

Commercial users of VMS frequently have test and development systems
that are used to make sure that "production" will run without error on
the latest release of the O/S before production systems are upgraded.

I can't see many of these commercial users relying on hobbyists to do
their testing.

I'm sure that many hobbyists can and do find bugs. If they are not
paying for support HP is probably not listening to them!

JF Mezei

2010-10-20 05:31:32 UTC

Post by Richard B. Gilbert
Commercial users of VMS frequently have test and development systems
that are used to make sure that "production" will run without error on
the latest release of the O/S before production systems are upgraded.

Yes, thsoe are the very customers HP is expecting to be on VMS and those
are the ones HP is catering to.

HP doesn't care about the smaller customers who do not have the luxury
of having tests systems, and large amount of man hours needed to debug
softwware that should have been debugged by HP's engineers.

Rich Jordan

2010-10-20 14:34:33 UTC

Yes, thsoe are the very customers HP is expecting to be on VMS and those
are the ones HP is catering to.
HP doesn't care about the smaller customers who do not have the luxury
of having tests systems, and large amount of man hours needed to debug
softwware that should have been debugged by HP's engineers.

We used to do that testing for our small customers; we always loaded a
test box as close as possible to the customer system with the version
and ECO they would be upgrading to and tested prior to the upgrade on
the live system. We've got two test Alphas, two VAXen soon to be
retired as our last customer upgrades to (probably) an Alpha, but no
spare Itanics yet.

It wasn't perfect because we really could not duplicate the hardware
all that closely, but it still caught some issues. So much for that
service... unless patches are available via the customer. Even with
an upgrade license purchase I'm not sure how we or they are supposed
to get hold of 'current' patches for the new version, which I would
hope they are entitled to even without an ongoing contract.

V***@SendSpamHere.ORG

2010-10-19 11:56:26 UTC

Are you allowed to say what problem actually caused the decision to
be taken to revert to the old hardware ?

Guy sent me a private email detailing it. Essentially, it is the problem
he mentioned here a few days ago.

Thanks for the feedback.
I take it this is the hanging I/O problem when using mailboxes ?
If the nature of the problem is such that even Guy cannot work around
it or get a fix from HP in a reasonable amount of time, then what hope
is there for a normal VMS site ?

I will allow Guy to publicly air his comments and concerns he's privately
confided in me if he so wishes.

I, however, will go on record to say that I am not at all impressed with
the V8.4 bug-to-fix turn-around time. There also appears to be, I could
be wrong, a "we-can't-reproduce-it-so-it-ain't-a-bug" mentality. That's
my impression from that 'ssh -X/xauth' bug when I reported it and I just
can seem to shake it. I am still waiting patiently for something to fix
the VMSINSTAL faux pas; albeit, I will never be able to recover my money
from the project this nonsense crippled nor the good faith in me by this
client that this nonsense eroded. Macro debugging? Well, there's always
DELTA (gawd, let's hope so anyway) and listings.

I've had a few other dealings in recent weeks with HP that gave me great
concern and this has nothing to do with the group in India either. This
is focused here in US support. Two product vendors and the HP camarilla
teamed up to point the accusatory finger at a third product vendor whose
product wasn't even running on the system in question. I say, grow some
spine.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

JF Mezei

2010-10-19 12:19:05 UTC

So, lets declare 8.4 a disaster.

The question people should be asking is whether the new maintainers of
VMS will get better in time, or whether this is as good as it gets
because budgers are so tight that they don't have time/resources for
proper Q/A.

In other words, is this just a one time ramp up problem, or is this the
shape of things to come ?

Are Sujatha and Shuba aware of the poor quality of 8.4, and what are
they saying about it ? Are they admitting their team isn't quite ready
for prime time, or are they saying that they are doing their best under
the budgets allocated ?

At this point in time, if VMS management don't come forth to provide an
explanation, customers will start to assume the worse (shape of things
to come).

Jan-Erik Soderholm

2010-10-19 12:31:19 UTC

Post by JF Mezei
So, lets declare 8.4 a disaster.

:-)

Post by JF Mezei
The question people should be asking is whether the new maintainers of
VMS will get better in time, or whether this is as good as it gets
because budgers are so tight that they don't have time/resources for
proper Q/A.
In other words, is this just a one time ramp up problem, or is this the
shape of things to come ?
Are Sujatha and Shuba aware of the poor quality of 8.4, and what are
they saying about it ?

Have you asked them ?

Post by JF Mezei
Are they admitting their team isn't quite ready for prime time, or are
they saying that they are doing their best under the budgets allocated
?

Aren't we all ?

Post by JF Mezei
At this point in time, if VMS management don't come forth...

How do you know they haven't ?
When was the last time you met and talked to anyone
from the current VMS group ?

Post by JF Mezei
to provide an explanation, customers will start to assume the worse
(shape of things to come).

*Customers* talkes directly to HP.
And they do not talk to HP through c.o.v.
They do not have to assume anything.

Do you expect to see something from the VMS group on c.o.v ?
That will not happen. C.o.v is "monitored" but they will
not post anything here from the group itself.

JF Mezei

2010-10-19 13:53:27 UTC

Post by JF Mezei
At this point in time, if VMS management don't come forth...

How do you know they haven't ?

If VMS management had provided some customers with an explanation for
the low quality of 8.4 and indications that this is a temporary "ramp
up" problem, I suspect that there would have been such discussions here.

NDA might prevent discussing specifics, but someone could still say
something akin to "I have been given a warm and fuzzy feeling about the
improving capabilities of VMS engineering"

I have not seen any such posts in the past year.

Anone who had seen Sue's postings or attended one of her presentations
in person would have seen how she was able to provide warm and fuzzy
feelings about the state of VMS.

I have not seen not hears of such presentations, except from you for a
swedish TUD. But you did not provide any indication of whether they had
given you some information on the status of training/experience of the
engineering team.

Post by Jan-Erik Soderholm
When was the last time you met and talked to anyone
from the current VMS group ?

It was at that webcast last year where Sue and Sujatha answered some
questions.

In that web cast, they were clearly NOT allowed to discuss the size of
the new team.

Post by Jan-Erik Soderholm
*Customers* talkes directly to HP.

Large, privileged customers talk directly to HP. Not the small ones, nor
the hobbyists.

Post by Jan-Erik Soderholm
Do you expect to see something from the VMS group on c.o.v ?

No. It was pretty clear from the start that they would coocoon
themselves and not participate on C.O.V.

And their participation in COV would be pointless since they would not
be allowed to release the information that many are seeking, just as
Sue/Sujatha had been prevented from doing so during the webcast.

Consider that we were told that we were not allowed to publish the
following slide from the Sue/Sujatha presentation:
Loading Image...

You may be in a privileged situation with direct contacts with HP.
Perhaps you are under NDA. But consider that the rest of the VMS
community is not so fortunate.

And even if you were under NDA, you could post something akin to " I am
under NDA, but I can say that I have been given a warm and fuzzy feeling
about the capabilities of VMS engineering and that they are confident
the quality issue is a one time ramp up issue". I didn't see something
like that from you.

Perhaps HP India has only one customer (HP Corp), then they may be under
strict orders to funnel all customer communications through HP Corp
marketing. I don't know how they function.

I am still waiting for an org chart showing the chain of command between
Hurd/Livermore and Shobha/Director of VMS. That too seems to be taboo.

HP has the right to keep the size/capabilities of VMS engineering
secret. But by choosing to do so, they have to accept that people will
still question the capabilities of the team, especially in light of the
bad quality of 8.4 and the type of errors made by the new team.

Post by Jan-Erik Soderholm
That will not happen. C.o.v is "monitored" but they will
not post anything here from the group itself.

If they see some concern made by many here, they could arrange for
answers to make it to the group via informal channels. But then again,
they may not be allowed by HP Corp to provide such answers.

8.4 has not sparked questions about "when is the next version", it has
sparked questions about the VMS team is really qualified to handle such
a complex operating system. Such lack of confidence should be a concern
to HP, a concern which would be easily fixed with better communications.

Jan-Erik Soderholm

2010-10-19 14:50:15 UTC

Post by JF Mezei
At this point in time, if VMS management don't come forth...

How do you know they haven't ?

Why ?
Remember that there was aprox 30 attendees from Sweden alone at
the last Bootcamp, yet you never see anyone of them *here*.

Most VMS sites/customers just couldn't care less about c.o.v.

Post by JF Mezei
NDA might prevent discussing specifics, but someone could still say
something akin to "I have been given a warm and fuzzy feeling about the
improving capabilities of VMS engineering"

I did not get the impression that there was a *general* concern about VMS.
One Swedish customer I talked to had doubled their VMS developer team
reasently and also canned a porting project for one of their VMS systems.
I didn't saw any major change in opinion or directions due to the
8.4 release as such.

Post by JF Mezei
Anone who had seen Sue's postings or attended one of her presentations
in person would have seen how she was able to provide warm and fuzzy
feelings about the state of VMS.

Was that any better ? Is the *felling* about it all that counts ?
I think you put too much value in what Sue did or did not.

Post by Jan-Erik Soderholm
*Customers* talkes directly to HP.

Large, privileged customers talk directly to HP. Not the small ones, nor
the hobbyists.

You do not have to be "privileged" (whatever that is), a support
contract would probably be enough.

Post by JF Mezei
Consider that we were told that we were not allowed to publish the
http://www.vaxination.ca/vms_org_chart1.jpg

Simon Clubley

2010-10-19 16:57:23 UTC

Post by Jan-Erik Soderholm
That will not happen. C.o.v is "monitored" but they will
not post anything here from the group itself.

If they see some concern made by many here,...

They absolutely do. Just mention "Mezei" and everyone get
a happy smile on their faces... :-)

And what do they think about the rest of the people here ?

Are valid comments dismissed simply because they are in made in c.o.v.
or are they still listened to ?

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Jan-Erik Soderholm

2010-10-19 17:32:41 UTC

Post by Jan-Erik Soderholm
That will not happen. C.o.v is "monitored" but they will
not post anything here from the group itself.

If they see some concern made by many here,...

They absolutely do. Just mention "Mezei" and everyone get
a happy smile on their faces... :-)

And what do they think about the rest of the people here ?

I can just guess since I didn't asked that specificaly.
Some on c.o.v of course realy does represent true customers,
and they are generelly known to anyone who cares. And as I
said, at least for Sweden, many of the true VMS customers
are not here on c.o.v at all.

I do not think you can use c.o.v as some rule to get the
*general* state-of-mind of VMS *customers*.

Post by Simon Clubley
Are valid comments dismissed simply because they are in
made in c.o.v. or are they still listened to ?

No, that was not at all my impression! Not at all.

*Valid* comments are certenly taken note of. But as with
anything else, it's always boiling down to business. You
can say and think whatever you like, but if it doesn't add
to the bottom-line, I don't see why anyone whould care.

We have all seen VAXman's post about the VMSINSTAL issue.
Now, *IF* he is the only one having issues with VMSINSTAL,
which priority would everyone else like to see put into
that by the VMS group ? It seems to be solved now, but
had it been worth a higher priority ? I don't know...

As I said, c.o.v is monitored but of course the validity
of anything said here must be valued against other views
and so on, just as anything said anyware else, nothing
unique about c.o.v (or VMS) in that regard at all.
Just my personal view on that...

Post by Simon Clubley
Simon.

John Wallace

2010-10-19 17:44:46 UTC

Post by Jan-Erik Soderholm
That will not happen. C.o.v is "monitored" but they will
not post anything here from the group itself.

If they see some concern made by many here,...

They absolutely do. Just mention "Mezei" and everyone get
a happy smile on their faces... :-)

And what do they think about the rest of the people here ?

I can just guess since I didn't asked that specificaly.
Some on c.o.v of course realy does represent true customers,
and they are generelly known to anyone who cares. And as I
said, at least for Sweden, many of the true VMS customers
are not here on c.o.v at all.
I do not think you can use c.o.v as some rule to get the
*general* state-of-mind of VMS *customers*.

Post by Simon Clubley
Are valid comments dismissed simply because they are in
made in c.o.v. or are they still listened to ?

No, that was not at all my impression! Not at all.
*Valid* comments are certenly taken note of. But as with
anything else, it's always boiling down to business. You
can say and think whatever you like, but if it doesn't add
to the bottom-line, I don't see why anyone whould care.
We have all seen VAXman's post about the VMSINSTAL issue.
Now, *IF* he is the only one having issues with VMSINSTAL,
which priority would everyone else like to see put into
that by the VMS group ? It seems to be solved now, but
had it been worth a higher priority ? I don't know...
As I said, c.o.v is monitored but of course the validity
of anything said here must be valued against other views
and so on, just as anything said anyware else, nothing
unique about c.o.v (or VMS) in that regard at all.
Just my personal view on that...

Post by Simon Clubley
Simon.

Mistakes happen from time to time even in the best managed
establishments. However, the best managed establishments make sure
that mistakes ideally don't reach the outside world and aren't
repeated.

Some of the stuff we've seen reported here is wrong, independent of
who is saying it. Some of it is nothing to do with newness of staff to
VMS and everything to do with poorly managed staff and processes.

Two examples spring to mind for me but others may well be aware of
more:
1) OS code changing (with no visible excuse), and bugs being
introduced, between end of field test and start of shipment.
2) Existing regression test processes and procedures being abandoned
resulting in detectable, avoidable errors in shipped code

Things like that are not good by anybody's engineering standards, even
if for some reason they seem to be relatively widely acceptable in
much of the IT world (well, the Windows-dependent bits anyway).

JF Mezei

2010-10-19 18:26:20 UTC

Post by Jan-Erik Soderholm
I do not think you can use c.o.v as some rule to get the
*general* state-of-mind of VMS *customers*.

This of course, is HP's view.

People on c.o.v. tend to have their eyes opened to every small tidbit of
information to get a feeling on what the owner of VMS is planning.

Few customers read that Stallard document of May 7th. But when a c.o.v.
participant read it and noticed the not so subtle text where Stallard
said in black an white that HP expected VMS customers to migrate to
HP-UX but would support VMS until they are ready to migrate.

The c.o.v. immediatly saw the HUGE mistake that section was. It created
enough anger at HP, on the very first day of HP being owner of VMS, that
they revised the document not once but twice to tone down the message.

5 individual customers see 1 2 3 4 and 5 respectively. By seeing only a
singel digit, they can't draw any conclusions.

c.o.v. gets to see all 5 and can conclude that 1 +2 + 3 + 4 + 5 = 15

HP probably hates it that c.o.v. exists because they can't control the
flow of information. Had it not been for c.o.v., HP would have succeeded
in keeping the dismantlement of VMS engineering a secret.

But it is a two edged sword. No HP employee wants to be fired and lose
their pension etc because they said something on c.o.v. that HP didn't
authorise them to say.

And if a soon-to-be ex employee wanted to send a farewell letter to
customers last year, they had to get it vetted/writen by marketing.

The corporation provides talking points. Employees are expected to use
them. So the posts you see from emplotyees represent corporate speak,
not their own opinions.

So while some employee may personally agree 200% with something a c.o.v.
poster is saying, they will still respond with a standard answer such as
VMS having fewer patches than Linux, or that VMS customers don't need
such and such a feature, don't need upgrades or that porting to x86
won't fix VMS.

c.o.v. is a bit like the national enquirer. We're the ones who notice a
dimple appearing on a supermodel's leg and draw the conclusion that she
must be developping skin cancer and will likely have to go to a
hospital in a few months. And we'll notice when it's gone, so we can
draw the conclusion that she has gone to get it fixed. Other people
wouldn't notice any of that.

JF Mezei

2010-10-19 17:48:49 UTC

Post by Simon Clubley
Are valid comments dismissed simply because they are in made in c.o.v.
or are they still listened to ?

Arne Vajhøj

2010-10-20 02:39:39 UTC

On 19-10-2010 13:48, JF Mezei wrote:

Steven Schweda

2010-10-20 17:14:56 UTC

[...]

If real customers don't complain about a bug, why should HP spend money
to fix it if it only affects hobbyists ?

Makes perfectly business sense.

Perhaps. Perhaps not. A hobbyist might install, say, VMS
V8.4 before many real (paying) customers would dare. A bug
discovered by a hobbyist might be important enough to fix
_before_ it affects a real (paying) customer. Which would
make a customer happier, getting a bug fixed after he reports
it, or never seeing the bug at all?

What would make perfect business sense to me would be to
collect as much information about bugs as possible, and then
to prioritize the work to fix them. Having a real (paying)
customer waiting for a fix would certainly tend to raise the
priority for a particular bug fix, but it's not obvious to me
that that should be a requirement to get some bug fixed.

My current list of pending bugs includes these:

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1385911
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1444509

I'm not holding my breath. (Especially if I couldn't get the
patch which provides the fix.)

glen herrmannsfeldt

2010-10-20 19:46:40 UTC

Post by Steven Schweda

[...]

If real customers don't complain about a bug, why should HP spend money
to fix it if it only affects hobbyists ?

Makes perfectly business sense.

Note in addition that Microsoft often releases trial versions,
with a one year or six month limitation, before the official
release. Now, I don't know that is quite the same a a hobby
license, but it does allow for people not running production
to test out and find bugs in software.

More obvious to me, it allows administrators for large organizations
to run a test machine with the new system before using it in
a production environment.

-- glen

FredK

2010-10-21 14:54:10 UTC

Post by Steven Schweda
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1385911

I found an open internal bug report on this. It does not appear to be
fixed.

Post by Steven Schweda
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1444509

I didn't find anything on this... but it may simply be my searching skills
in the database are not adequate (narrow search failed, a broader search is
still crunching after 30 minutes). But the ITRC reports do get logged into
the system as WEB submitted problems.

Post by Steven Schweda
I'm not holding my breath. (Especially if I couldn't get the
patch which provides the fix.)

Your comment about "paying victims" is correct. WEB reported issues are
not the same as a bug report from a customer with a support contract. So I
have no doubt that the issues are in the system, but unless the web based
report on it's surface appears to be critical... other work will tend to
come first.

V***@SendSpamHere.ORG

2010-10-20 18:28:29 UTC

Post by Steven Schweda

[...]

If real customers don't complain about a bug, why should HP spend money
to fix it if it only affects hobbyists ?

Makes perfectly business sense.

Perhaps. Perhaps not. A hobbyist might install, say, VMS
V8.4 before many real (paying) customers would dare. A bug
discovered by a hobbyist might be important enough to fix
_before_ it affects a real (paying) customer. Which would
make a customer happier, getting a bug fixed after he reports
it, or never seeing the bug at all?
What would make perfect business sense to me would be to
collect as much information about bugs as possible, and then
to prioritize the work to fix them. Having a real (paying)
customer waiting for a fix would certainly tend to raise the
priority for a particular bug fix, but it's not obvious to me
that that should be a requirement to get some bug fixed.
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=3D13859=
11
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=3D14445=
09

If you put your long URLs into something like tinyURL, they be much easier
to follow since they'd be more likely to not get munged by quoted-pukeable
encoding for the 'equal sign' and line wrapping that makes quoted-pukeable
so notably annoying.

That said, I'll keep my eyes peeled for bug fixed for these.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

Jilly

2010-10-20 17:44:50 UTC

This is why, when there was VMS engineering presence, whenever someone
reported a bug here, they could not elevate it themselves, they would
ask that customers use support channels to report it.

I may not be Engineering but I have certainly logged issues from c.o.v into
the PTR system.

V***@SendSpamHere.ORG

2010-10-20 18:29:25 UTC

Post by Jilly

This is why, when there was VMS engineering presence, whenever someone
reported a bug here, they could not elevate it themselves, they would
ask that customers use support channels to report it.

I may not be Engineering but I have certainly logged issues from c.o.v into
the PTR system.

I, and I am sure others here, thank you!

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

Phillip Helbig---undress to reply

2010-10-19 18:41:11 UTC

Post by Simon Clubley
Are valid comments dismissed simply because they are in made in c.o.v.
or are they still listened to ?

V***@SendSpamHere.ORG

2010-10-19 20:42:29 UTC

Post by Jan-Erik Soderholm
That will not happen. C.o.v is "monitored" but they will
not post anything here from the group itself.

If they see some concern made by many here,...

They absolutely do. Just mention "Mezei" and everyone get
a happy smile on their faces... :-)

And what do they think about the rest of the people here ?
Are valid comments dismissed simply because they are in made in c.o.v.
or are they still listened to ?

Seen any @HP.IN addresses in the posting header here? That should answer
your question.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

Jan-Erik Soderholm

2010-10-19 22:54:27 UTC

Post by Jan-Erik Soderholm
That will not happen. C.o.v is "monitored" but they will
not post anything here from the group itself.

If they see some concern made by many here,...

They absolutely do. Just mention "Mezei" and everyone get
a happy smile on their faces... :-)

And what do they think about the rest of the people here ?
Are valid comments dismissed simply because they are in made in c.o.v.
or are they still listened to ?

your question.

Why would there be @hp.in headers here becuse someone listens/reads ?

Guy Peleg

2010-10-20 00:28:17 UTC

I doubt that we would ever see anyone official from the new regime
replying in this forum.
They might monitor it, I do not know, but again, I doubt they would be
replying.

When I was still in engineering I really enjoyed conversing with
customers over c.o.v.,
I really appreciated the honest, direct and never sugar coated
feedback in the forum.
I remember multiple times I thought something was a great idea but
people on
c.o.v., who are real OpenVMS users thought otherwise. Most engineers
writing
code are not VMS users, for example, I used to own DCL, I know DCL
internals and
I added many new features to DCL, however, while inside HP, I never
had a chance
nor the need to write a DCL procedure. The new regime employs many
young
engineers, chances are most of them never used VMS. That’s why I
personally
think that it is VERY important to listen and monitor c.o.v. even
though you
don’t always get hugs and kisses here.

Going back to V8.4, what I wrote to Mr. VAXMAN will stay between the
both of us, Maklee’s official position is that V8.4 is not yet
production ready,
it would need some time to mature. I encourage people to test it so we
can find bugs and surface them to engineering, but I would not bet
my production workload on it yet.

fwiw,

Guy Peleg
Maklee Engineering
www.maklee.com

Rob Brooks

2010-10-20 15:06:31 UTC

Post by Guy Peleg
When I was still in engineering I really enjoyed conversing with
customers over c.o.v., I really appreciated the honest, direct and
never sugar coated feedback in the forum.
I remember multiple times I thought something was a great idea but
people on c.o.v., who are real OpenVMS users thought otherwise.

I completely agree with the above. While no longer a member of VMS
Engineering, I still read comp.os.vms every day. I also found some useful
feedback here for some of the work I was doing with $GETDVI, and that feedback
directly led to the addition of the LAN_ item codes and the enhancements
for $ SHOW DEVICE/FULL for LAN devices, all of which were done for V8.3 and
unofficially backported to V7.3-2.

It is true, however, that vast majority of VMS Engineering did not read
comp.os.vms, and those that did felt that the signal-to-noise ratio
was not particulary favourable. I agree with that sentiment, but felt
it was (and is) useful to read nonetheless.

--
Rob Brooks CFE -- Marlborough, MA brooks!cuebid.usa.hp.com

Rich Jordan

2010-10-20 14:28:30 UTC

I completely agree with the above. While no longer a member of VMS
Engineering, I still read comp.os.vms every day. I also found some useful
feedback here for some of the work I was doing with $GETDVI, and that feedback
directly led to the addition of the LAN_ item codes and the enhancements
for $ SHOW DEVICE/FULL for LAN devices, all of which were done for V8.3 and
unofficially backported to V7.3-2.
It is true, however, that vast majority of VMS Engineering did not read
comp.os.vms, and those that did felt that the signal-to-noise ratio
was not particulary favourable. I agree with that sentiment, but felt
it was (and is) useful to read nonetheless.
--
Rob Brooks CFE -- Marlborough, MA brooks!cuebid.usa.hp.com

Guy, Rob,
thank you both for this input. Both the info regarding C.O.V.
and about VMS V8.4 are helpful, and the latter especially will help us
make determinations regarding customer V8.4 upgrade cycles, the first
of which is already on hold pending a lot of testing.

Rich

Paul Anderson

2010-10-20 14:49:01 UTC

I completely agree with Guy Peleg and Rob Brooks (at least with regards
to the value of comp.os.vms). ;-)

The disappearance of OpenVMS Engineering participation in this newsgroup
is a loss to both HP and to customers.

Issues reported to engineering through supported channels always got
priority, but I fixed and improved DCPS many times because of
conversations started in comp.os.vms.

Paul

V***@SendSpamHere.ORG

2010-10-20 15:36:36 UTC

Post by Paul Anderson
I completely agree with Guy Peleg and Rob Brooks (at least with regards
to the value of comp.os.vms). ;-)
The disappearance of OpenVMS Engineering participation in this newsgroup
is a loss to both HP and to customers.
Issues reported to engineering through supported channels always got
priority, but I fixed and improved DCPS many times because of
conversations started in comp.os.vms.

The problem I had was navigating those channels; especiallly, after they
dried up or were damned up by the Compaq and HP acquisitions/mergers. I
found comp.os.vms to be the only place to air problems I encountered and
then, I maintained the hope that somebody in VMS Engineering would read
it and respond or pass along my issue to the approppriate handler.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

FredK

2010-10-21 13:56:27 UTC

I stopped reading cov on a regular basis for probably a couple of years
because the s/n level was so out of hand. It was far too easy to get sucked
into the vortex. In reality there has only ever been a small handful of
engineering that directly read cov, and fewer who would risk participating.

Issues that come up in cov *do* filter up into engineering by those that
read here - sometimes as an informal mail message, or an internal notesfile
posting, and even as an internal bug report. I know that there are
engineers in India who also read cov - however given the hostility that
sometimes comes out here you might imagine why you might not see them
posting here.

JF Mezei

2010-10-21 15:05:44 UTC

Post by FredK
posting, and even as an internal bug report. I know that there are
engineers in India who also read cov - however given the hostility that
sometimes comes out here you might imagine why you might not see them
posting here.

If the new VMS engineering engaged with the community, perhaps we would
get to know them and have greater respect for their issues/challenges
and provide better understanding between the community and engineering.

By isolating the new team from the community, it creates a huge void
which attracts speculation. Is HP hiding the new team because it knows
they are not up to the task, or because HP doesn't want the community to
find out that the new team is much much much smaller than the original
one and can't possibly maintain the quality because they are so short
staffed ?

Just an example:
If the guy responsible for the IP clustering participarted here and
provided technical details on how it is implemented, it would send a
message to the community that there are very competent people who know
their stuff. And might provide some background on why other areas have
experienced problems.

Some of the errors in 8.4 seem to indicate lack of regression testing.
But what if someone from engineering provide some explanation such as
the Indian office not having completed the conversion of the USA
regression tests to the different system used by the Indian team for a
long time ?

The noise in C.O.V. is HP's own doing. The lack of information is what
creates the speculation.

Jan-Erik Soderholm

2010-10-21 15:28:38 UTC

Post by JF Mezei
If the new VMS engineering engaged with the community,

Some of them (and I) did that last week.

Post by JF Mezei
If the guy responsible for the IP clustering...

IPCI was discussed last week and there was plenty of time to
ask any questions you wanted on IPCI.

Are you expecting someone from VMS engineering to ring in your door ?

V***@SendSpamHere.ORG

2010-10-21 15:44:02 UTC

If the new VMS engineering engaged with the community, perhaps we would
get to know them and have greater respect for their issues/challenges
and provide better understanding between the community and engineering.
By isolating the new team from the community, it creates a huge void
which attracts speculation. Is HP hiding the new team because it knows
they are not up to the task, or because HP doesn't want the community to
find out that the new team is much much much smaller than the original
one and can't possibly maintain the quality because they are so short
staffed ?
If the guy responsible for the IP clustering participarted here and
provided technical details on how it is implemented, it would send a
message to the community that there are very competent people who know
their stuff. And might provide some background on why other areas have
experienced problems.
Some of the errors in 8.4 seem to indicate lack of regression testing.
But what if someone from engineering provide some explanation such as
the Indian office not having completed the conversion of the USA
regression tests to the different system used by the Indian team for a
long time ?
The noise in C.O.V. is HP's own doing. The lack of information is what
creates the speculation.

OMFG! I'm going to see the doctor myself. I, too, am agreeing with JF.
Did I miss it? Was there a grand syzygy that has aligned the universe?
Should I play the lottery or the ponies tonight?

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

FredK

2010-10-21 15:49:32 UTC

I suggest you read some of the things *you* have written - and then place
yourself in the shoes of the people you have written about.

Post by JF Mezei
By isolating the new team from the community, it creates a huge void
which attracts speculation.

You have been speculating (mostly without facts) for a decade. What you
fail to realize time and again is that this isn't the local pub, and the
engineers that respond here simply can't reply to much of your speculation -
even when it is 100% dead wrong - or when it is 100% right.

Post by JF Mezei
Is HP hiding the new team because it knows
they are not up to the task, or because HP doesn't want the community to
find out that the new team is much much much smaller than the original
one and can't possibly maintain the quality because they are so short
staffed ?

No. You choose to ignore what I said - c.o.v. participation by engineering
has always been a tiny minority. Remember when I challenged you to actually
name "important" engineers? While a number of what I would consider
"important" engineers have read and some responded here -- most never have.

And again, you make a speculation that isn't something that even *can* be
responded to. OR one that would have been responded to 10 years ago, or 20
years ago in c.o.v.

I started to reply to the rest of your reply, and decided not to.

Richard B. Gilbert

2010-10-21 19:16:52 UTC

If the new VMS engineering engaged with the community, perhaps we would
get to know them and have greater respect for their issues/challenges
and provide better understanding between the community and engineering.
By isolating the new team from the community, it creates a huge void
which attracts speculation. Is HP hiding the new team because it knows
they are not up to the task, or because HP doesn't want the community to
find out that the new team is much much much smaller than the original
one and can't possibly maintain the quality because they are so short
staffed ?
If the guy responsible for the IP clustering participarted here and
provided technical details on how it is implemented, it would send a
message to the community that there are very competent people who know
their stuff. And might provide some background on why other areas have
experienced problems.
Some of the errors in 8.4 seem to indicate lack of regression testing.
But what if someone from engineering provide some explanation such as
the Indian office not having completed the conversion of the USA
regression tests to the different system used by the Indian team for a
long time ?
The noise in C.O.V. is HP's own doing. The lack of information is what
creates the speculation.

And what creates these long digressions into "Global Warming" and other
unrelated topics????

Please don't answer that! But think about it.

Then have a look at the archives from 1986--1990. Some high powered
people (Jerry Leichter, the late Carl j. Lydic (SP??), a few people from
VMS Engineering, and others) were actually writing about VMS and how to
use it to best advantage.

V***@SendSpamHere.ORG

2010-10-21 15:36:06 UTC

Post by FredK

I stopped reading cov on a regular basis for probably a couple of years
because the s/n level was so out of hand. It was far too easy to get sucked
into the vortex. In reality there has only ever been a small handful of
engineering that directly read cov, and fewer who would risk participating.
Issues that come up in cov *do* filter up into engineering by those that
read here - sometimes as an informal mail message, or an internal notesfile
posting, and even as an internal bug report. I know that there are
engineers in India who also read cov - however given the hostility that
sometimes comes out here you might imagine why you might not see them
posting here.

I know they read it and have email proof thereof.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

Phillip Helbig---undress to reply

2010-10-20 19:21:55 UTC

In article

Post by Guy Peleg
When I was still in engineering I really enjoyed conversing with
customers over c.o.v.,
I really appreciated the honest, direct and never sugar coated
feedback in the forum.
I remember multiple times I thought something was a great idea but
people on
c.o.v., who are real OpenVMS users thought otherwise.

The appreciation is mutual.

Post by Guy Peleg
The new regime employs many
young
engineers, chances are most of them never used VMS.

What IS this world coming to? I did think it was cool that Roland's top
keyboard-synthesiser designer is a guitarist, but people writing VMS who
don't themselves use it is like a virgin writing the script for a porn
film.

V***@SendSpamHere.ORG

2010-10-20 20:21:30 UTC

Post by Phillip Helbig---undress to reply
In article

Post by Guy Peleg
When I was still in engineering I really enjoyed conversing with
customers over c.o.v.,
I really appreciated the honest, direct and never sugar coated
feedback in the forum.
I remember multiple times I thought something was a great idea but
people on
c.o.v., who are real OpenVMS users thought otherwise.

The appreciation is mutual.

Post by Guy Peleg
The new regime employs many
young
engineers, chances are most of them never used VMS.

What IS this world coming to? I did think it was cool that Roland's top
keyboard-synthesiser designer is a guitarist, but people writing VMS who

I didn't know that and I own several Roland keys including their first,
the SH-1000.

Post by Phillip Helbig---undress to reply
don't themselves use it is like a virgin writing the script for a porn
film.

Rated ZZZzzz...

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

V***@SendSpamHere.ORG

2010-10-19 12:34:13 UTC

Post by JF Mezei
So, lets declare 8.4 a disaster.
The question people should be asking is whether the new maintainers of
VMS will get better in time, or whether this is as good as it gets
because budgers are so tight that they don't have time/resources for
proper Q/A.
In other words, is this just a one time ramp up problem, or is this the
shape of things to come ?
Are Sujatha and Shuba aware of the poor quality of 8.4, and what are
they saying about it ? Are they admitting their team isn't quite ready
for prime time, or are they saying that they are doing their best under
the budgets allocated ?
At this point in time, if VMS management don't come forth to provide an
explanation, customers will start to assume the worse (shape of things
to come).

Let's sum it up in a word and you decide. Hubris.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

V***@SendSpamHere.ORG

2010-10-19 14:57:11 UTC

Post by JF Mezei
So, lets declare 8.4 a disaster.

:-)

Have you asked them ?

I'm fearful that that contingent has convinced themselves that V8.4 is
as bug-free as an autoclave on max.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

Arne Vajhøj

2010-10-20 02:35:23 UTC

Post by JF Mezei
So, lets declare 8.4 a disaster.

That seems a bit early.

So far it seems as if there are unusual many
bugs for a .4 version, but we will first know
its long term status in a couple of years.

Arne

Craig A. Berry

2010-10-19 12:46:31 UTC

Post by V***@SendSpamHere.ORG
I, however, will go on record to say that I am not at all impressed with
the V8.4 bug-to-fix turn-around time. There also appears to be, I could
be wrong, a "we-can't-reproduce-it-so-it-ain't-a-bug" mentality. That's
my impression from that 'ssh -X/xauth' bug when I reported it and I just
can seem to shake it. I am still waiting patiently for something to fix
the VMSINSTAL faux pas; albeit, I will never be able to recover my money
from the project this nonsense crippled nor the good faith in me by this
client that this nonsense eroded. Macro debugging? Well, there's always
DELTA (gawd, let's hope so anyway) and listings.

I might have missed it in this long thread, but no one seems to be
talking about the fact that UPDATE v4.0 arrived last Thursday with 60+
bug fixes. The answer to the OP's question about production-readiness
might well be different based on what ECO level he has.

I suppose another casualty of the patch lockdown is that the public
reputation of v8.4 will be based on its pre-lockdown status since there
doesn't seem to be a way for the public to even know what's been fixed.

In UPDATE v4.0 I see two fixes to VMSINSTAL. There are new MACRO.EXE and
DEBUG.EXE images, but I don't see any indication they are about MACRO
debugging. I see no mention of xauth.

Jan-Erik Soderholm

2010-10-19 13:35:14 UTC

Post by Craig A. Berry

My impression from the TUD last week was that the reported bugs
and other problems had been dealt with. That might have been
relating to some ECO still in the works, that was not clear.
The VMSINSTAL issue is/was mentioned.

I do not know how the priorities between the different
bugs/problems are set, but probably not according to the
highest voice on c.o.v. And that is probably right.

Post by Craig A. Berry
I suppose another casualty of the patch lockdown is that the public
reputation of v8.4 will be based on its pre-lockdown status since there
doesn't seem to be a way for the public to even know what's been fixed.
In UPDATE v4.0 I see two fixes to VMSINSTAL. There are new MACRO.EXE and
DEBUG.EXE images, but I don't see any indication they are about MACRO
debugging. I see no mention of xauth.

V***@SendSpamHere.ORG

2010-10-19 15:04:05 UTC

Post by Craig A. Berry

I might have missed it in this long thread, but no one seems to be
talking about the fact that UPDATE v4.0 arrived last Thursday with 60+
bug fixes. The answer to the OP's question about production-readiness
might well be different based on what ECO level he has.
I suppose another casualty of the patch lockdown is that the public
reputation of v8.4 will be based on its pre-lockdown status since there
doesn't seem to be a way for the public to even know what's been fixed.
In UPDATE v4.0 I see two fixes to VMSINSTAL. There are new MACRO.EXE and
DEBUG.EXE images, but I don't see any indication they are about MACRO
debugging. I see no mention of xauth.

The xauth issue had been fixed with a TCP/IP patch release. The bigger
issue was that of trying to get it acknowledged AS a bug/problem in the
first place.

Sadly, we will all, most of us anyway, continue to see V8.4 and a petri-
dish of antibiotic resistant bugs because the pharmacopeia is unreadable
(patch digest) and pharmacy has gone out of business(patch access). So,
even if this update you speak to does indeed cure the V8.4 ills, we will
never know.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

V***@SendSpamHere.ORG

2010-10-19 15:15:19 UTC

Post by Craig A. Berry

My impression from the TUD last week was that the reported bugs
and other problems had been dealt with. That might have been
relating to some ECO still in the works, that was not clear.

I can deal with bugs too! Ignore them or simply choose not to use V8.4. I
have resorted to the latter and I think many others will too!

Post by Jan-Erik Soderholm
The VMSINSTAL issue is/was mentioned.

It should NEVER have been an issue. It's all moot now. I lost development
time, a substantial amount of money, and a client because of that horseshit.
The VMSINSTAL issue is going to keep me forever soured toward this group's
acumen and judgement. I'm growing to like mac-n-cheese.

Post by Jan-Erik Soderholm
I do not know how the priorities between the different
bugs/problems are set, but probably not according to the
highest voice on c.o.v. And that is probably right.

If you're referring to my voice, I'm not the only squeaking wheel here that
has been voicing these problems loudly.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

John Santos

2010-10-20 19:51:09 UTC

In article <***@SendSpamHere.ORG>, VAXman-
@SendSpamHere.ORG says...>

Post by V***@SendSpamHere.ORG
can seem to shake it. I am still waiting patiently for something to fix
the VMSINSTAL faux pas;

This seems to have been fixed in UPDATE 4, which has been out about a
week for both Itanic and Alpha.

The way it works, according to the release notes, is you define a
(/JOB so subprocesses see it) logical name that tells VMSINSTAL to
ignore the signing stuff. I think it still tells you that this is
an unsigned kit, but just proceeds automatically.

I haven't tried it yet.

--
John Santos
Evans Griffiths & Hart, Inc.

V***@SendSpamHere.ORG

2010-10-20 20:24:44 UTC

Post by John Santos
@SendSpamHere.ORG says...>

Post by V***@SendSpamHere.ORG
can seem to shake it. I am still waiting patiently for something to

fix

Post by V***@SendSpamHere.ORG
the VMSINSTAL faux pas;

This seems to have been fixed in UPDATE 4, which has been out about a
week for both Itanic and Alpha.
The way it works, according to the release notes, is you define a
(/JOB so subprocesses see it) logical name that tells VMSINSTAL to
ignore the signing stuff. I think it still tells you that this is
an unsigned kit, but just proceeds automatically.
I haven't tried it yet.

Yes, since I received my SAID today, I have read the contents of the
update 4 patch and I have already added it to some of my kits. I'm
still out the money and the time and lost the client that this short-
sightedness caused.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

Phillip Helbig---undress to reply

2010-10-21 12:37:48 UTC

Post by John Santos
@SendSpamHere.ORG says...>

Post by V***@SendSpamHere.ORG
can seem to shake it. I am still waiting patiently for something to

fix

Post by V***@SendSpamHere.ORG
the VMSINSTAL faux pas;

This seems to have been fixed in UPDATE 4, which has been out about a
week for both Itanic and Alpha.

Really no point in posting stuff like this here anymore. Those with
support contracts can check for themselves if they are interested, those
without cannot access the patches.

Jan-Erik Soderholm

2010-10-21 12:51:06 UTC

Post by Phillip Helbig---undress to reply

Post by John Santos
@SendSpamHere.ORG says...>

Post by V***@SendSpamHere.ORG
can seem to shake it. I am still waiting patiently for something to

fix

Post by V***@SendSpamHere.ORG
the VMSINSTAL faux pas;

This seems to have been fixed in UPDATE 4, which has been out about a
week for both Itanic and Alpha.

Really no point in posting stuff like this here anymore. Those with
support contracts can check for themselves if they are interested, those
without cannot access the patches.

In this case it was rellevant since VAXman has told us
before that he has access to the patches. I got my
ITRC user working yesterday, b.t.w.

A question:

In the former FTP site there was a patch-directory called
"layered products" where you could find compiler patches
and so on. Does anyone know how to find them (if at all)
on the ITRC site ?

V***@SendSpamHere.ORG

2010-10-21 15:23:12 UTC

Post by Phillip Helbig---undress to reply

Post by John Santos
@SendSpamHere.ORG says...>

Post by V***@SendSpamHere.ORG
can seem to shake it. I am still waiting patiently for something to

fix

Post by V***@SendSpamHere.ORG
the VMSINSTAL faux pas;

This seems to have been fixed in UPDATE 4, which has been out about a
week for both Itanic and Alpha.

Really no point in posting stuff like this here anymore. Those with
support contracts can check for themselves if they are interested, those
without cannot access the patches.

In this case it was rellevant since VAXman has told us
before that he has access to the patches. I got my
ITRC user working yesterday, b.t.w.
In the former FTP site there was a patch-directory called
"layered products" where you could find compiler patches
and so on. Does anyone know how to find them (if at all)
on the ITRC site ?

That's a very good question. I'm wondering if they consider Macro a layered
product and the patch for the bug I reported may be there.

Instead of SPAMming me using the email address I gave to HP *solely* for the
SAID with ads for mobile phone toys and other things I could care absolutely
nothing about, how about a webinar on how to navigate the ITRC patch access.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

FredK

2010-10-21 15:53:58 UTC

Post by V***@SendSpamHere.ORG
That's a very good question. I'm wondering if they consider Macro a layered
product and the patch for the bug I reported may be there.

AMACRO is part of OpenVMS. See my earlier post. The problem is fixed and
checked into the next update patch kit. If you don't have a copy of the
fixed image, and since you are in the program that can get patches - I'll
see if I can get you a copy of the image.

Martin Vorlaender

2010-10-20 20:00:27 UTC

Post by V***@SendSpamHere.ORG
I am still waiting patiently for something to fix
the VMSINSTAL faux pas;

V***@SendSpamHere.ORG

2010-10-18 16:36:50 UTC

Post by Guy Peleg

I would say it depends on the size of your hardware. If you are using
a small
box, say rx2600, test it make sure it works and go ahead. If you are
using a large
integrity box, I would advise against it.
A customer we worked with recently went live with OpenVMS V8.4 on
BL870c i2,
they were forced upgrading to V8.4 because of the hardware. They went
back
to the old computer the next day.

Guy, would you write up a brief synopsis for me of what you encountered?
Private email me... unless you'd like to share with the world. I've got
a problem with a client and similar h/w.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

Keith Parris

2010-10-18 23:08:05 UTC