Conference iosg::all-in-1_v30

    Jan,
    
    	The VMS V5.5 Queue manager problem is being looked at by VMS
    engineering.  They either have now, or will soon have, a patch
    available from your local CSC.  For more details see VAXWRK::VMSNOTES
    (DIR/TITLE=V5.5).
    
    	I think if you only upgrade to A5.5 the Queue problem will not
    appear as the difference between A5.5 & V5.5 is the new Queue manager.
    
    HTH,
    
    Martin.

    Martin,
    
    > -< see VAXWRK::VMSNOTES note 401.* >-

    I read all 41 replies. No information on the details
    of the ALL-IN-1 related BUG.
    
    > available from your local CSC.  
    > I think if you only upgrade to A5.5 the Queue problem will not

    I am local CSC. Its not our system I am afraid of (we run ALL-IN-1
    and VMS 5.5 without problem), I want to into what kind
    of trouble my customers can get.
    
    Is it just OA$FORMATTER ?
    
    Regards,
    
    Jan
    
    

This information is extracted from the ALL-IN-1 Internal Change Order which 
changes OAFORMATTER.

Richard

-----------------------------------------------------------------------------
Problem(s) fixed or functionality added:

The OA$FORMATTER symbiont was breaking the 'undocumented' rules for
communication between a symbiont and the VMS Job Controller.

A background formatter job with invalid OA$PARAMS or OA$FMTCTL parameters 
communicated back to the job controller in a way which did not adhere to 
the undocumented rules.  After receiving a START_TASK it was issuing a
TASK_COMPLETE with Error to the Job Controller without having acknowledged 
the START_TASK.

This had worked without problems on VMS V4.7 (or whatever version of VMS
was in use in June 1988 when I wrote the code) to VMS V5.4.  On a VMS V5.5
system with the new Job Controller it would cause the Job Controller to
keep giving the same job to OA$FORMATTER, and after doing this 255 times
the Job Controller would crash. 



Change(s) (include module/routine names where relevant)

After receiving a START_TASK always issue a START_TASK back to the Job 
Controller before issuing a TASK_COMPLETE, with Error or Success.


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

    Jan,
    
    I received mail from Product Management explaining the situation with
    ALL-IN-1 and VMS v5.5. It contained some text in it asking ceratin
    people to let all european CSCs know what is going on but I cut that
    out of the attached because the person who was named uses this conference 
    and might not appreciate being mentioned. I have also indicated where I 
    removed text to protect the other innocent people named.
    
    The Atlanta CSC will be going on-site to United Telecom later today
    ... more news as it happens live on CNN.
    
    Regards,
    
    Andrew.D.Wicks
    
    
    Subject: VMS V5.5 on hold in GIA (due to ALL-IN-1 OA$FORMATTER)
    
    VMS V5.5 is on hold in GIA because of printing problems within ALL-IN-1,
    resulting from the completely revised Queue Manager code in VMS V5.5.
    
    I have just returned from a hurriedly set up teleconference with VMS
    Engineering on this affair, with regard to CLD IPO 5591 (United Telecom).
    VMS engineering have 4 identical CLDS from assorted customers and most
    CSCs also have major customers in difficulties.
    
    IOSG CSE certified on VMS V5.5 some months ago (successfully), we were
    specifically warned about the new queue manager in VMS, and thoroughly
    tested EVERY function in ALL-IN-1 that hits the Queue Manager. This testing
    was also overseen and vetted by SQM and <name> I assume that the reason we
    are now in difficulties with VMS Queue Mgr is that our testing was single
    user and not a full load/soak testing of the Queue Manager itself. 
    Incidentally - our IOSG production cluster is at VMS V5.5 now - with no 
    know Queue Mgr problems known to me.
    
    The problem has so far been traced to the OA$FORMATTER symbiont code -
    which is
    not handshaking correctly with the Queue Manager. This needs further
    investigation and I understand that VMS (names) will
    be working closely with WPS-PLUS (names) on this. I have also advised
    that VMS contact (names) directly to gain
    maximim efficiency on this affair. I have also ensured that <names>
    are copied on all mails pertaining to this subject - so that we can
    provide updates to the CLD teams as required.
    
    VMS have already supplied a patch to United Tel., but this  only
    prevented the Queue Mgr itself from falling over so frequently, the 
    OA$FORMATTER still
    continues to crash regularly. More investigation is being performed NOW.
     
    <A very important name>
    

    
    	I don't buy that V5.5 was put on hold *JUST* because of ALL-IN-1.
    	There are other lock manager and queue manager problems.
    
    	The fix Richard mentioned will fix the OA$FORMATTER problem, but so
    	would a fix to the VMS queue manager, implementing the old style of
    	interface. Considering the number of customer written symbionts,
    	my guess is that VMS will produce such a fix, but I haven't heard
    	of any such fix yet.
    
    Regards,
    Paul

    Paul is correct. VMS V5.5 was not put on hold just because of ALL-IN-1.
    It is unfair slurring of ALL-IN-1's reputation to say so.  The problem
    lies in VMS, but the most obvious example where the problem comes to
    light may be on large ALL-IN-1 systems. That's not to say that it
    hasn't been more than noticed on large transaction processing sites, or
    anywhere else where you have lots of queues and symbionts. I know of
    one ACMS/Rdb shop that ran into problems and went back to VMS V5.4
    because of it. So is it an ACMS problem?
    
    Let's not accept credit for all the problems in the computing world.
    
    Tony

    Re .5, .6,                                               
    
    Gentlemen I am only passing on the official announcement. I assume
    that some of the digs in the replies were directed at me.
    
    If you have a problem with the description then you know what the correct 
    channels are - none of the words included in .4 are mine.
    
    Regards,
    
    Andrew.D.Wicks

    ANdrew,
    
    You know that I would never take a dig at you. My words are directed at
    the sometimes all-to-quick tendancy of people within Digital (or within
    the customer base) to blame ALL-IN-1 for everything. We need to resist
    this, for far too many people, again within DEC, would like to take
    ALL-IN-1 out (in my opinion). 
    
    Tony

================================================================================
Note 149.0            ALL-IN-1 v3.0 and VMS v5.5 problems?            No replies
LARVAE::SHORE "The wonderful thing about tiggers..." 15 lines   2-MAR-1992 10:10
--------------------------------------------------------------------------------
    Hi,
    
    I have just been told by my customer that Digital is advising customer not 
    to upgrade to VMS v5.5 and ALL-IN-1 v3.0, because the re-write of the 
    queue manager in VMS is incompatable with ALL-IN-1. Can anyone 
    confirm/deny this for me, and if it is true do we have a work around? This 
    has a major impact on me as I have just spent the last three months 
    convincing my customer that they want ALL-IN-1 v3.0 now.
    
    And as an aside, can anyone confirm whether we shipped last Friday, as I 
    have also heard that the release date is now mid March?
    
    Any info on the above would be very much appreciated.
    
    Thanks and regards, Angela
    

    Again, another example of how ALL-IN-1 gets tagged with a VMS problem.
    The workaround is a VMS patch to V5.5, and the installation of the SSB
    release of ALL-IN-1 V3.0.
    
    ALL-IN-1 did not ship last Friday. A statement will be made very soon
    now as to the new ship date. 
    
    Tony

We have a new ALL-IN-1 customer (a pretty strategic site) who are currently 
doing acceptance testing on version 2.4-1 (i.e. with WPS-PLUS version 4) on a 
machine we loaned them. Their own systems 3100 model 80's have just arrived and 
we want to move them onto those - but here lies the problem.

MicroVAX 3100 model 80's can only take VMS version 5.5 and the TSC tell us that 
v5.5 doesn't support ALL-IN-1 version 2.4-1.

Is this the same problem as the one with v3.0 and v5.5 VMS? And if so, will the                  
same patch fix the problem?


Thanks,   Jacqueline

    What reason did the TSC give for ALL-IN-1 V2.4 not supporting VMS V5.5?
    Was it the symbionts issue?  If so, you'll have to wait (I guess) until
    VMS engineering patch VMS.  Or maybe someone in the IOSG support team
    would care to comment?
    
    Tony

    
    	Hold on there Tony, I am not sure VMS are going to issue a
    	patch for the queue manager problem, although I expect they
    	might. Do you know something I don't know? :-)
    
    Regards,
    Paul

    Well, I guess they will fix the problem someway  - like VMS V5.5-1 or
    VMS V5.6.... Of course, this won't be called a patch, merely a release
    which continues to add functionality to the operating system.
    
    Tony

As I understand it (which may be wrong, and I am sure I will be corrected if it 
is) that the problems that have been found with the VMS V5.5 queue manager can
impact ANY application, however because of the way ALL-IN-1/WPS-PLUS implement
printing ALL-IN-1 sees the problem far more than most applications.

The problem is that the new queue manager is more fussy about the rules for
handshaking between it and an application than the old job controller used
to be.

The problem applies to ANY version of ALL-IN-1.

VMS are working on (may have released by now) a patch that stops the queue
manager from falling over when it encounters unexpected handshaking from an
application. The application that does the unexpected handshaking will still
have to comply with the tighter implementation of the rules to work fully.

Therefore an ALL-IN-1 patch will be needed to make printing work 100% against
VMS V5.5 even after the VMS patch is installed. I do not know if there are
any plans for such a patch and if so which versions of ALL-IN-1 will be
patched.

It is possible to install VMS A5.5 which is V5.5 with the old job controller,
and as far as I know all versions of ALL-IN-1 work OK under VMS A5.5

HTH

Terry

    Yeah, VMS changed the rules on handshaking without telling anyone and
    ALL-IN-1 gets blamed because it plays by the old rules.... Thanks for
    the news about VMS A5.5. I'm sure that will make people's lives a
    little easier.
    
    Tony

    Re .18,
    
    Jan please when posting STARS articles remove the hidden text
    particularly names and phone numbers. 
    
    We've unfortunately had a long history of people who read such notes 
    calling the author of the said article directly and he/she has been 
    completely swamped by the volume and doesn't understand how they got 
    his/her number.
    
    1-800-DEC-8000 for questions on this patch not (404) 343-xxxx
    
    I know you didn't mean to do this so it's just a gentle reminder. 
    
    Regards,
    
    Andrew.D.Wicks (Atlanta CSC)
                                                                     

    And now i've set my own note hidden... the ultimate moderator
    privilege.
    
    I received some mail expressing concern about some of the information 
    contained in the edited version of .18 so i've asked the person who 
    requested .18 to be hidden to explain the reasons tomorrow.
    
    Roll on VMS v5.6!
    
    Regards,
    
    Andrew.D.Wicks

    I asked Mr. Wicks to hide the note in question. The patch that it
    refers to is a very preliminary fix intended for use by a restricted
    group of people to fix a very specific problem. It was assigned a
    CSCPAT number out of convenience, and said patch is, in fact, NOT
    generally available through the CSCPAT system and if improperly
    distributed will cause more problems than it solves.
    
    When (if?) the fully authorized patch kit comes down from VMSland it
    will be generally available.
    
    mark

    Ok. Four weeks later and...
    
    It looks like VMS 5.5-1 does not fix the queue managers problem.
    
    Customers keep upgrading and will be disappointed that we do 
    not fix know bugs.
    
    What's the best way for us (the ALL-IN-1 world)
    to get this going ?
    
    Is there any contact between IOSG and VMS engineering ? 
    
    From the VMS  note file:
    
================================================================================
Note 850.9                      Patches for V5.5?                      9 of 12
CRASHR::JILLY "COSROCS -- In Thrust We Trust"       3 lines  24-MAR-1992 16:49
--------------------------------------------------------------------------------

Well since ALL-IN-1 is a heavy lock and queue management product I can see 
why you shouldn't update to V5.5 if you are using it.  Maybe the ALL-IN-1 
folks know the specific queue management problems V5.5 presents for them.

================================================================================
Note 850.10                     Patches for V5.5?                     10 of 12
VAXWRK::TCHEN "Weimin Tchen VAXworks 223-6004 PKO2"37 lines  24-MAR-1992 16:59
--------------------------------------------------------------------------------
                          -< new VOID 5.5 patch kits >-

    ALL-IN-1 queuing problems were mentioned in 401.27 & .40 . I don't
    know of any patches for this.
    
    5.5 patch kits were recently revised since the installation procedure
    were not disabling the MoveFile file attribute on some images.
    
image                       old kit                      new kit              
-----------------------     -----------------            ----------------------

process_management          SYS$02_055                   SYS$03_055      

recovery_unit_services      RMS$01_055                   RMS$02_055      
rms                         RMS$01_055

sys$cluster                 SYSCLUS$02_055               SYSCLUS$03_055  

sysloa*                     SYSLOA$04_055                SYSLOA$06_055   
                            SYSLOA$03_055                SYSLOA$05_055   

working_set_management      WSM$03_055                   WSM$03A_055     

dsdriver                    DUDSDRVR$01_055              DUDSDRVR$02_055 
dudriver                    DUDSDRVR$01_055

epdriver                    EPDRIVER$01_055              EPDRIVER$02_055 

f11bxqp                     F11X$01_055                  F11X$02_055     

loginout                    LOGIN$01_055                 LOGIN$02_055    
                            
pwdriver                    PWDRIVER$01_055              PWDRIVER$02_055 

shdriver                    QLEN$07_055                  QLEN$07A_055    
    
*** A new shadow kit with the new KITINSTAL.COM (SHADOW$03_055) containing 
SHDRIVER.EXE and has already been released ***
    

================================================================================
Note 850.11                     Patches for V5.5?                     11 of 12
JARETH::ELLISON                                    55 lines  25-MAR-1992 13:41
--------------------------------------------------------------------------------
                          -< List of fixes for 5.5-1 >-

    Here is a list of the fixes that will make up the 5.5-1 release.
    

          Table 1:  VMS Version 5.5-1 Kit Components


          Kit_Component      Description


          DECW$05_055        Various DECwindows bug fixes

          DUDSDRVR$02_055    Multiple fixes to DUDRIVER and DSDRIVER for
                             5.5 only

          F11X$02_055        Locking, MOVEFILE erase on delete, file
                             truncation fixes (F11BXQP)

          LAD$01_055         Prevents LASTDRIVER from crashing system,
                             V5.5

          SHADOW$02_055      HBVS fixes for SHDRIVER and SHADOW_SERVER for
                             V5.5 ONLY

          SYS$01_055         Unable to log into ACMS via controlled termi-
                             nal on VMS V5.5

          SYSCLUS$03_055     This kit supplies several fixes for VMS V5.5
                             SYSMAN, SMISERVER problems.

          SYSLOA$01_055      Patch for performance problem on VAX 6200
                             /6300 running VMS 5.5

          SYSLOA$06_055      Fix warmstart on battery-backed 6600, 6500;
                             intermittent time prompt on 6600

          TUDRIVER$01_055    Fixes V5.5 system crashes due to invalid
                             (T)MSCP packet data from tape device

          VERIFY$01_055      (a) Data corruption; (b) bad headers on FIDs
                             that are multiples of 64K

          Mount              Fixes to a number of Mount problems that effect 
                             host and controller based volume shadowing. In
                             addition fixes for tape compaction problems.

          SYSLOA46           Fix to machine check handler to avoid crashing 
                             when hard or soft memory errors are experienced 
                             on PMariah Workstations and PWaverly Servers.

          SMBSRVSHR          Fix addressing a Pathworks issue that is being 
                             provided due to a previous commitment.



    

================================================================================
Note 850.12                     Patches for V5.5?                     12 of 12
FDCV14::CONNELLY "Paul Connelly, US IM&T TIS"      16 lines  25-MAR-1992 15:26
--------------------------------------------------------------------------------


What is the word as far as patches that are listed in .10 but NOT in .11?
I think that would be:
                        SYS$03_055
                        RMS$02_055
                        SYSLOA$05_055
                        WSM$03A_055
                        EPDRIVER$02_055
                        LOGIN$02_055
                        PWDRIVER$02_055
                        QLEN$07A_055

Are these going into V5.5-2?  Are any of them generally important enough
such that internal users of V5.5 should apply them as a matter of course?

                                                                - paul

    
    	Hey, don't beat us up, we DO talk to VMS! :-)
    
    	Here's my understanding of the status, maybe if someone knows
    	better, they will correct me:
    
    	VMS quickly produced a patch which stopped the queue manager
    	crashing and this made it into V5.5-1. This didn't actually
    	cure the source of the problem, just made it less severe when
    	it happened.
    
    	They then worked with us to find the cause. When the problem was
    	found, BOTH sides fixed it. The VMS patch is in VMS V5.5-2 I
    	beleive, but I don't think the OA$FORMATTER patch made it into
    	SSB V3.0, BL123.
    
    	By the way, the problem only occurs when an invalid job gets
    	onto the queue. Its just a bug in the error handling, not in normal
    	operation.
    
    	So we do fix 'em, just takes a while to filter through...
    
    Regards,
    Paul

	Paul

	I understood that there were 2 problems found:

	one was a real VMS problem which VMS Engineering will (have?) fixed.

	the second was also found to be a VMS problem but a workaround within 
	ALL-IN-1 was also identified. 

	My understanding (from Martin Cook) is that VMS have fixed (or will fix?)
	all the problems as it would not have been practical to patch ALL 
	versions of ALL-IN-1.

	Please could you check this out otherwise the CSC's will get requests
	for an ALL-IN-1 patch that does not exist!

	Cheers

	Jill 

    
    	Well, sort of. Re-reading my reply, I realised that I didn't
    	make it clear when I said BOTH ends fixed the problem, that I
    	meant just that - you can use EITHER fix because they both fix
    	the whole problem, not half each. I don't think we intend releasing
    	the ALL-IN-1 fix as a patch because you can get the VMS fix as
    	a CSP, so I am told.
    
    	Now I think about it, I wish I had never mentioned the ALL-IN-1
    	workaround! I was trying to make the point that we do fix things!
    
    	Hope this clears it up!
    
    Regards,
    Paul

    Paul,
    
> 	I was trying to make the point that we do fix things!
    
    Fully agree. My major concern is/was, that there is no information
    available about a/the a fix(es). 
    
    Don't fix all bugs please, I don't want to be out of work
    and customers will stop paying us for support.
    
    Regards,
    
    Jan
    
    
    

    
    RE: .-1
    
    	Don't worry, we usually try to introduce another few bugs when
    	we fix something, just to keep you in work!
    
    Regards,
    Paul

This is probably a rat hole, but I could not let it pass...

Bug DO NOT create jobs, they create work, they cost the company millions of 
dollars and they frustrate the hell out of customers.

In the short term that may mean more people are needed to support the product
but eventually customers will move to other companies products and there will
be no jobs at Digital anymore.

If we can work towards a bug-free product (and V3.0 is a significant step 
in this direction) then we will have more and happier customers and there will
be more jobs helping customers get the most out of the product which will
be much less frustraiting, much more rewarding and much more secure as we will
be making the company money from satisfied customers.

I'll get down from my soap-box now.

Terry

    
    I understand, there is a VMS patch available.
    Somebody knows which patch it is and what number?
    
    thanks
    GJ

    
    	RE: .28
    
    	Sorry Terry, maybe I shouldn't have been so flippant. I don't
    	REALLY think anyone wants a buggy product. I am sure the folks
    	in the field realise they have much better things to do than
    	chasing down bugs in the product. (You don't really think we put
    	in bugs do you? :-)
    
    	I don't think bugs are the main field time waster though,
    	my experience is that the field specialists spend a large
    	percentage of their time fixing up customer disasters because
    	the actual products delivered are not what the customer intended.
    	(Customer ordered wrong products, Digital advised him wrongly,
    	Salesman ordered wrong products, wrong versions delivered, version
    	skew with what's installed).
    
    	(By the way, I didn't mean that to sound like engineering is
    	perfect, I'm sure we contribute to the process, but I couldn't
    	think of an example off hand.)
    
    	Fix that problem, and I think the specialists would have more time
    	to do genuine revenue generating things (like consulting).
    
    	Okay, I'll get off my soap box now...
    
    Regards,
    Paul

 Anyone out there have customers that are running A5.5 (w/ ALL-IN-1) in a
production environment?

 I'm looking for reference sites so that my customer will upgrade their
6000-420s to 6000-610s. They won't do it until they get a good comfort level
that A5.5 (without the new queue manager) will work OK.


re: .31
    	I don't think bugs are the main field time waster though,
    	my experience is that the field specialists spend a large
    	percentage of their time fixing up customer disasters because
    	the actual products delivered are not what the customer intended.

Flame ON!

 This is patently rediculous! I've just wasted almost a week of my time over
the past two and a half months trying to track down this problem and get my
customers comfortable with the issue. THE BUGS ARE MY PROBLEM, AND DIGITALS!
We (tried) to sell them the right thing but can't finish the deal BECAUSE of
the BUGS!

 We have SEVERAL customers that have Loan of Products for VAX 6000-5xx JUST
BECAUSE of the bugs. A lot of these are now running out and Digital will have
to EAT the cost of the LOPs because we can't get customers to upgrade to V5.5.

 Between the cost of my time, multiplied many times by many other Sales and
Sales Support people, plus the cost of many Loan of Product aggreements equals
a lot of MONEY that's been wasted.

 We ordered the right thing. Our customers don't want it because of the BUGS!
AND WE END UP SPENDING OUR MONEY AND NOT GETTING ANY FROM OUR CUSTOMERS!

Flame off...


 Now, to help us save time and money, does anyone out there have customers who
would be willing to be a reference site for customers who are ansy (and not
spending money...) about going to 5.5 with ALL-IN-1?



							Thanks,
							djg...

I can be reached at:

 DTN: 328-3582
 (215) 542-3582
 TBLADE::GEEHAN
 or
 Dave Geehan @PHH

    
>    	I don't think bugs are the main field time waster though,
>    	my experience is that the field specialists spend a large
>    	percentage of their time fixing up customer disasters because
>    	the actual products delivered are not what the customer intended.
>
>Flame ON!
>
> This is patently rediculous! I've just wasted almost a week of my time over
    
    Flame if you like, but it is what I and my collegues used to waste most
    of our time over when I worked in the field.
    
    I didn't mean to say bugs weren't important, of course they are - look
    at the huge cost of the support centres whose main activity seems to
    be bugs (but what do I know?).
    
    I guess one shouldn't generalise.
    
    Regards,
    Paul

    
    
    
    From what I've been able to gather, ALL-IN-1 V3.0 will work in the
    following cofigurations.  Please correct me if I'm wrong.
    
    VMS V5.5 with patch ALL-IN-1 with patch
    or
    VMS A5.5 with ALL-IN-1 without any patches
    
    

    
    
>    From what I've been able to gather, ALL-IN-1 V3.0 will work in the
>    following cofigurations.  Please correct me if I'm wrong.
    
    	ALL-IN-1 V2.4 and V3.0 are the same in this respect. Don't single
    	out V3.0.
    
>    VMS V5.5 with patch ALL-IN-1 with patch
    
    	There is no ALL-IN-1 patch. You don't need one. You just need the
    	VMS patch (or 5.5-2).
    
>    or
>    VMS A5.5 with ALL-IN-1 without any patches
    
    	Yes.
    
    Regards,
    Paul

re: -1

Paul,

 Exactly which VMS patch? I've been monitoring VMSNOTES 401.* as mentioned in
a previous reply (.30), but it's very unclear which patch you refer to (re: .23,
.25, .29, and .30).

 401.* mentions a potential patch for the queue manager (re: 401.40 and .45) but
says it isn't available yet (as of late February/early March). Since then
there's been no 'official' notice that a patch is available. (I'm cross posting
a reply to 401. to see if I can find out from there...).

 So, is the patch you mentioned (.23 & .25) ready yet and what is it called?

*****
In a somewhat related, but side issue:

 There is some confusion in the customer base about whether WordPerfect will
work with V5.5 or A5.5 and the queue manager problems with ALL-IN-1.

 I've checked with our WordPerfect relationship manager (for lack of a better
term...). She called WP and found out that the latest fix/patch/update to WP
V5.1 will correctly install with either VMS V5.5 (new Queue Manager) or A5.5
(old V5.4 Queue Manager). The WP installation procedure is automatic and will
check the VMS version and 'do the right thing'. Aparently the confusion in
the recent past was that the install was not automatic and asked questions
which confused folks.

 This is good news as my customers were very uneasy, but are now happy.



							Thanks,
							djg...

RE: .34

There is no VMS 5.5-1 or 5.5-2. So 5.5-2 isn't a solution.

There is a patch to fix the VMS queueing system problem exhibeted on certain
A1 systems. But you need to call the CSC to get the patch. (I don't know the
name of the patch kit yet.)

Valid configurations according to Tim Ellison, VMS 5.5 product manager, and
Bill Colquitt, ALL-IN-1 product manager are:

	� VMS A5.5 (=old queueing system) + A1 V2.4 or V3.0

	� VMS V5.5 with queueing system patch + A1 V2.4 or V3.0

There is no reason not to upgrade any A1 V2.4 or V3.0 system to VMS 5.5 at this
point.

-Glenn-

Interesting.  I'm the CSC/Atlanta patch person and I don't know of the patch.
I just got off the phone with the CSC/Colorado patch folks and they don't know
of the patch either.  Could you provide some more specifics either here or
via mail?

mark

When I spoke with Tim Ellison (VMS 5.5 product manager) last week he told me that
Ray Guzzman (VMS engineer who fixed queueing problem) had a patch kit for the
queueing problem. Tim also told me that the patch was submitted to the CSC a
week ago Wednesday.

However, since our systems need the patch too, I called the CSC this afternoon
to get a hold of the patch. The lady at first couldn't find it but after
explaining to her about the above she called me back and said that the
Atlanta CSC has the patch. She said I couldn't get it off the net. Atlanta is
supposed to be sending me the patch kit on TK50 (seems like a big waste of
money sending it that way, but...).

I'll update here when I get the patch kit.

-Glenn-

    And as I told Glenn, what he will get is the secret, not really a fix
    but keep the que manager from dying patch that the Atlanta folks are
    distributing as needed.
    
    Word comes just this very afternoon that the real job controller patch
    kit *should* be available this next week. It is currently undergoing
    some documentation related revisions.
    
    mark
    (I'll be glad when this is all over...)

Hi all,
re -1
>>    And as I told Glenn, what he will get is the secret, not really a fix
>>    but keep the que manager from dying patch that the Atlanta folks are
>>    distributing as needed.
    
>>    Word comes just this very afternoon that the real job controller patch
>>    kit *should* be available this next week. It is currently undergoing
>>    some documentation related revisions.
    
OK, so how do the rest of the CSCC's in the world get the patch - the patch 
advertised in STARS, CSCPAT_1012, doesn't seem to be available on our local 
system, & the bod who looks after patches is on leave & no-one knows how he 
actually gets them. (aaargh)

Meanwhile we have unhappy ALL-IN-1 & WPS-PLUS customers...

If the patch location can't be made public, could someone PLEASE mail me?

Regards,

Chele B
CSC Sydney

    Hallo,
    
    For all of you who do not have access to the wonderfull
    world of STARS hereby the supported versions (specified
    by ALL-IN-1 Product Management. I removed names and badge-numbers.
    
    What is new for me is that no version of ALL-IN-1 is supported
    on VMS 5.5 clusters.
    
    Regards,
    
    Jan
    
    ==============================================================
    
Background Formatter May Hang On a VMS 5.5 System


COPYRIGHT (c) 1988, 1989, 1990 by Digital Equipment Corporation.
ALL RIGHTS RESERVED. No distribution except as provided under contract.


PRODUCT: ALL-IN-1 V2.3, V2.4

OP/SYS: VAX VMS version 5.5 only

SOURCE: Customer Support Center/USA

INFORMATION:

On VMS version 5.5 systems, some sites have experienced problems
with printing when the background formatter (OA$FORMATTER) is used.

When jobs are submitted from the background within ALL-IN-1 or WPS-Plus
onto a device queue, and the device queue is invalid, the QUEUE_MANAGER
process will fail. Although the QUEUE_MANAGER will "fail over" to another
node in the VAXCLUSTER it will fail on that node too. It will be
necessary to delete the job from the formatter queue.

This has been been reported on very large clusters when the new VMS
v5.5 job controller is used. If the system is a stand-alone or small
clustered system, then the situation described here is not expected
to occur.

The formatter problem occurs on VMS version 5.5, because V5.5 introduces
new queue manager / job controller functionality.  To perform background
printing the OA$FORMATTER must communicate with the job controller.
The changes implemented in VMS Version 5.5, in some cases, result in
a failure of the required communication between the OA$FORMATTER and
the job controller.  When this occurs, it can cause the job controller
to hang.

Some sites may have a choice about when to upgrade to VMS version 5.5,
but others may be required to use version 5.5 now. The following
hardware configurations require VMS Version 5.5:

        VAX 6000 Model 600
        VAX 4000 Model 500
        VAX 3100 Models 30, 40, and 80
        VAXstation 4000 Model 60
        VAXstation 4000 VLC
        VAX 4000 Model 300 and 200

\ ************ DIGITAL INTERNAL USE ONLY ******************
\ Refer to the article in the VMS_V5 STARS database titled:
\
\   How To Answer Customer Question 'Should I Upgrade to VMS V5.5?'
\
\ for complete details regarding the VMS V5.5 job problem(s).

ALTERNATIVES:

If a site must use VMS version 5.5, then they can avoid the situation
described above in a number of ways. One way would be to avoid use of
the background formatter; a site can print from ALL-IN-1 without using
it.

Another way to avoid experiencing the problem, that would still allow
use of the background formatter, would be to use the VMS v5.4 job
controller instead of the new 5.5 controller. This can be done by
staying at VMS 5.4 or going to VMS A5.5. Version A5.5 is essentially
V5.5 with the v5.4 job controller.

ALL-IN-1 2.3, 2.4 will not be supported on VMS 5.5 clusters.
Single node 5.5 systems will be supported.

VMS version A5.5 will be supported in all circumstances.
\The above information is also true for ALL-IN-1 v3.0.

\ ************ DIGITAL INTERNAL USE ONLY ******************
\ CAUTION: Be aware that the following statement could cause a
\ customer satisfaction issue. The following information can not be
\ released to customers until it has been confirmed that the fix has
\ been included in VMS v5.5-1 AND is shipping to customers:
\   ALL-IN-1 product management recomends that VMS version 5.5 customers
\   wait for VMS 5.5-1 due out in June 1992 from VMS engineering for a
\   fully tested fix to the Job Controller and queue system problems.
\ ************ DIGITAL INTERNAL USE ONLY ******************

MORE INFORMATION:

During phase 6 of the VMS 5.5 Upgrade, the question is asked:

 "Do you wish to upgrade to the new JOB_CONTROL at this time [NO]?"

If this question is answered "NO", the resulting VMS system (after a
reboot) will show version A5.5 and will be running the old job
controller (v5.4). In this case, the formatter problem should not
occur.  This is the recommended configuration when running
ALL-IN-1 on the system. The new job controller can always be
enabled at a later time if desired.

If this question is answered "YES", then the new job controller is
used and the VMS version will be V5.5, not A5.5 after a reboot,
and the formatter situation described above might occur on a large
clustered ALL-IN-1 system.

\ The following information was included in a DSNlink FLASH article
\ to European customers in "Critical Information Bulletin No.34 -
\ 27th March 1992" :
If a site has already installed VMS 5.5 and also implemented the V5.5
job controller and now want to go back to the V5.4 job controller, the
following procedure may be used to accomplish this. This procedure
requires the cluster to be rebooted, and the print and batch queues to
be defined.

 The old print and batch facility is enabled by modifying the
 file SYS$SYSROOT:[SYS$STARTUP]VMS$CONFIG-050_JOBCTL.COM;.

 The change required is :-

 $master_file = f$parse("QMAN$MASTER","SYS$SYSTEM:QMAN$MASTER.DAT",,,"SYNTAX_ONL
 $if f$search(master_file) .nes. ""
 $then
 $newjobctl = 1
 $else
 $newjobctl = 0
 $endif
 $endif
 $define/user sys$output nl:
 $!
 $! Insert line here to make symbol Newjobctl=0 to use
 $! old Print and Batch Facility. The code takes the else option
 $! from the if statement.
 $!
 $ Newjobctl=0
 $!
 $!

 The difference is, insert a line of DCL after the $DEFINE/USER
 to set the symbol newjobctl=0.

 A cluster is reboot is required, a rolling reboot cannot be performed
 as only one style of print and batch facility can be active within the
 VAXCLUSTER at any one time. After the reboot the V5.4 job controller
 will be used, so the queue problem described above will not occur.

\ ************ DIGITAL INTERNAL USE ONLY ******************
\ Per VMS support there are currently, as of April 3, no
\ Engineering supplied supported patch(es) to fix the job
\ controller issues.
\ When patch(es) are available, the US Customer Support Center
\ will be notified immediately and this article should be updated.
\ It is anticipated that the patch will be available through the
\ CSCPAT Utility.
\
\ For information on the patches compatible with VMS Version 5.5,
\ activate the V5_VMS STARS database and query on "5.5  \CSCPAT_INFO"
\
\\ A1_IOS OA1 %QX902
\\ VER_2.3_A1_IOS VER_2.4_A1_IOS
\\ VER_3.0_A1_IOS
\\ ?CSCPAT_1012 PATCH
\ B36.REF
\\ UPDATE_V3.0

Jan, you have posted information that is woefully out-of-date. This information
has been know for a long time now. Both VMS product management and ALL-IN-1
product management has said for a long time that you should use VMS A5.5 with
A1 V3.0 on clusters. It is totally supported and works. (FYI, VMS T5.5-1 is
out now too which contains fixes to both the queueing and lock manager issues
plus other fixes.)

MODERATORS: you might consider hiding reply .41 since it is nothing but
dis-information and is sure to confuse the heck out of a lot of people.

-Glenn-

    Glen,
    
>Jan, you have posted information that is woefully out-of-date. This information
>has been know for a long time now. Both VMS product management and ALL-IN-1

    OUT-OF-DATE ???
    
    This STARS article is created on 18-APR-1992 11:31:15.33 !!!!!!!
    
>MODERATORS: you might consider hiding reply .41 since it is nothing but
>dis-information and is sure to confuse the heck out of a lot of people.

    The number of replies to this note and to note 401 in VMSNOTES
    indicate that the information regarding this problem
    was no that clear to the field.
    
    I thought this Stars arcticle reflected the final statement
    from ALL-IN-1 product management.
    
    Regards,
    
    Jan
    

Jan, no the article does not reflect ALL-IN-1 product managements opinion.

I think I already posted here that both Bill Colquitt (ALL-IN-1 product manager)
and Tim Ellison (VMS 5.5 product manager) both agree that ALL-IN-1 should be
run with VMS A5.5 so that the old queueing system is used. To say otherwise
is to give out mis-information.

There is absolutely no reason to not upgrade to VMS A5.5 to run either ALL-IN-1
version 2.4 or 3.0. Period. Any CSC in the U.S. should tell you this and also
tell you that it's perfectly acceptable to go to VMS A5.5 if you want to.

Lastly, when VMS V5.5-1 (T5.5-1 is already out in external field test) then you
won't have to run VMS A5.5 but will be able to go right to VMS V5.5-1.

If you doubt me, please call either Tim or Bill to get this information
confirmed. I don't think they would appreciate people giving out information
that isn't correct.

-Glenn-

Wait a minute Jan. Read your own STARS article! Here's a quote from what you
posted:

>Another way to avoid experiencing the problem, that would still allow
>use of the background formatter, would be to use the VMS v5.4 job
>controller instead of the new 5.5 controller. This can be done by
>staying at VMS 5.4 or going to VMS A5.5. Version A5.5 is essentially
>V5.5 with the v5.4 job controller.
>
>ALL-IN-1 2.3, 2.4 will not be supported on VMS 5.5 clusters.
>Single node 5.5 systems will be supported.
>
>VMS version A5.5 will be supported in all circumstances.

See the last line. VMS A5.5 is supported in all ALL-IN-1 configurations. Why do
you think otherwise?

-Glenn-

This article gives much more up-to-date information as well as step-by-step
instructions on just how to get to VMS A5.5.

-Glenn-




How To Answer Customer Question 'Should I Upgrade to VMS V5.5?'


********************   CAUTION:  FOR INTERNAL USE ONLY   *********************
*                                                                            *
*      THIS INFORMATION IS FOR USE BY DIGITAL EQUIPMENT CORP. AND ITS        *
*      EMPLOYEES ONLY.  PLEASE USE EXTREME CARE IF YOU MUST DISCUSS ANY      *
*      PART OF THIS INFORMATION WITH ANYONE WHO IS NOT A DIGITAL EMPLOYEE.   *
*                                                                            *
******************************************************************************

COMPONENT:  Upgrade                                       OP/SYS:  VMS

LAST TECHNICAL REVIEW:  15-APR-1992

SOURCE:  Customer Support Center / USA

VERSION INFORMATION:

     Information Applies to:  VMS, Version 5.5

**********************************************************************
*                                                                    *
*                              CAUTION                               *
*                                                                    *
*         The information in this article is to be considered        *
*         INTERNAL USE ONLY.  While the contents of this             *
*         article should be used to give advice to a customer,       *
*         it should not be read verbatim.                            *
*                                                                    *
**********************************************************************


QUESTION:

Should I upgrade to VMS Version 5.5?


ANSWER:

The two biggest issues reported with VMS Version 5.5 are:

        1.  Problems with the Distributed Lock Manager

        2.  Job controller problems with ALL-IN-1 and third
            party symbionts, e.g, INTERLEAF, GRAYMATTER.  These 
            problems are not totally understood at this point.

Currently, VMS Product Management and VMS Engineering tentatively plan
to start shipments of VMS Version 5.5-1 to customers in late June. 
Please note that these dates are subject to change.

This release will probably contain fixes to the Distributed Lock
Manager (see  below for details), fixes to Job Controller and Queuing
system, fixes to SYSMAN as well as fixes for other problems that may
cause  crashes or data corruption.  As of 15-APR-1992, we do not know
exactly what will be included in VMS Version 5.5-1.

When we have more details on the contents of this release, we will 
update this article.

Distributed Lock Manager
------------------------

The US CSC has a patch, CSCPAT_1011 which corrects several problems
related to the Distributed Lock Manager.  Europe and GIA will need to
obtain these patches from the SPE VOID patch distribution system. 
Please reference the following articles which are all contained in the
V5_VMS database: 

     CSCPAT_1011 Patch Information  [INTERNAL USE ONLY]                        
     V5.5 - LOCKMGRERR Bugcheck At Offset CLUSTRLOA+8DF8                       
     LOCKMGRERR And CNXMGRERR Bugchecks Occur After Upgrade To VMS V5.5        
 
Job Controller
--------------

The patch(es) to fix the job controller issues are not yet available
from Engineering.  When they are, the US Customer Support Center 
will be notified immediately.  We will make the patch(es) available
through the CSCPAT Utility.

Guidelines 
----------
Each customer situation should be evaluated individually when assessing 
whether or not a customer should upgrade to VMS Version 5.5.  There 
is no general rule of thumb when making this decision.  Please see the
SAMPLE DIALOGUE section below.

     NOTE:  We should advise customers to upgrade when there is no
            major negative impact to their business.  Currently,
            too many specialists are advising customers to wait when 
            it is not necessary.

The following guidelines may be used to help determine if a customer should
upgrade to VMS Version 5.5 at this time:

   o The following hardware configurations require VMS Version 5.5:

        VAX 6000 Model 600             
        VAX 4000 Model 500             
        VAX 3100 Models 30, 40, and 80 
        VAXstation 4000 Model 60       
        VAXstation 4000 VLC            
        VAX 4000 Model 300 and 200     
              
   o Most of the issues have been reported on very large clusters.  
     There do not appear to be any major issues with stand-alone 
     systems.  Therefore, if the customer has a stand-alone or
     small clustered system, we expect no major issues with the upgrade.

   o Customers with systems which make major use of the job controller 
     (have a lot of print/batch queues), but would like to upgrade to 
     VMS V5.5, should answer NO to the question in Phase 6 that asks:
                                                                              
        Do you wish to upgrade to the new JOB_CONTROL at this time? [NO]      
                                                                              
     This leaves the system at VMS Version A5.5.  

   o If a decision is made to upgrade to V5.5, and the site concerned 
     is a large clustered site, or the site runs ALL-IN-1 or a 3rd party
     symbiont, then you should get the customer the following patches:

        PATCH #         Fixes what issues
        ---------------------------------
        CSCPAT-1011     DISTRIBUTED LOCK MANAGER ISSUES
        CSCPAT-1012     JOB CONTROLLER ISSUES (this patch is *not* yet
                           available!!!)

   o If a decision is made to upgrade to V5.5, the upgrade/installation 
     procedures and the batch/print documentation supplied with VMS 
     Version 5.5 should be reviewed very carefully.  Directions should 
     be followed explicitly throughout the upgrade process.

   o Review various STARS articles in the VMSBUG, V5_VMS, VMSDP, VIA,
     and COMM databases using the search string "5.5" to ensure that 
     the customer is aware of other possible issues that have been 
     reported with this release.  

     For information on the patches compatible with VMS Version 5.5,
     activate the V5_VMS STARS database and query using the following:

              5.5   \CSCPAT_INFO

     Customers have access to any articles that are marked
     CUSTOMER-READABLE and READY via DSIN or 'DSNlink for VMS' ITS if
     they have a valid VMS contract. 


SAMPLE DIALOGUE:

When a customer calls wondering if there are "gotchas" with the V5.5
upgrade, you can use this sample dialogue to help them avoid the known
problems and also to decide if they should upgrade to V5.5 or A5.5.

For STANDALONE systems:

  o  If the system currently running V5.4 or a variant and the
     customer uses the VMS$PASSWORD_HISTORY.DATA file, have them make
     a copy of the file and then remind them to restore it after the
     upgrade.

  o  Does the system have a DEQNA? (SDA> SHO DEV XQ)
     If YES, the customer should not upgrade to VMS V5.5 or A5.5 until
     their Ethernet adapter has been upgraded.

  o  Have the customer check for out of range SYSGEN parameters:

       o  Make a copy of SYS$SYSTEM:SETPARAMS.DAT:

               $ COPY SYS$SYSTEM:SETPARAMS.DAT SYS$SYSTEM:SETPARAMS.COM

       o  Edit the new file:

               $ EDIT SYS$SYSTEM:SETPARAMS.COM

       o  Add the following lines to the beginning of the file:

               $ SET VERIFY
               $ SYSMAN = "$SYSMAN"
               $ SYSMAN
                 < Rest of file here with 'parameter ' added to the >
                 < beginning of each line.  Example:                >
                 <   parameter use current                          >
                 <   parameter write sys$system:vaxvmssys.old       >
                 <   parameter use default                          >
                 <   parameter    :                                 >

       o  Execute the new file:

               $ @SYS$SYSTEM:SETPARAMS.COM

  o  Is the CPU type a VAX 6200 or 6300 Series with KLESI or UNIBUS
     adapters?
     If YES, send CSCPAT_0297 to be installed AFTER the upgrade.

  o  Verify VAXCLUSTER = 0.  If not, SYSGEN> SET VAXCLUSTER 0 before
     beginning the upgrade.  AUTOGEN is run in Phase 6 and IF there is
     an entry in SYS$SYSTEM:MODPARAMS.DAT, the correct value will be
     reset at that time.

  o  Add "TMSCP_LOAD = 0" to SYS$SYSTEM:MODPARAMS.DAT before the
     upgrade.

  o  Does the customer use a print symbiont other the one supplied by
     VMS?  If YES, then upgrade to A5.5.
           If NO,  then upgrade to V5.5.

  o  To avoid an installation problem, have the customer answer the
     question:

       "Do you wish to upgrade to the new JOB_CONTROL at this time [NO]?"

     with "NO" regardless if the customer wants to go to V5.5.  After
     this question, the upgrade will complete and the system will
     reboot.  At that time have them @SYS$UPDATE:VMS$UPGRADE_A55_V55.COM
     to complete the V5.5 upgrade.

For VAXcluster systems:

  o  Send the customer CSCPAT_1011 (Lock manager).

  o  Does the customer have VAX 6000-660 with battery backup?
     If YES, then send CSCPAT_1000.

  o  Does the customer have VAX 6200 or 6300 Series machines with
     KLESI or UNIBUS adapters? (SYSGEN> SHOW/CONFIG)
     If YES, then send CSCPAT_0297.

  o  Do any of the systems have a DEQNA? (SDA> SHOW DEVICE XQ)
     If YES, the customer should not upgrade to VMS V5.5 or A5.5 until
     their Ethernet adapter has been upgraded.

  o  If the system is currently running V5.4 or a variant and the
     customer uses the VMS$PASSWORD_HISTORY.DATA file, have them make
     a copy of the file restore it after the upgrade.

  o  Is the current system running pre-V5.4?
     If YES, then have the customer SYSGEN> SET VAXCLUSTER 0 on the
     node that will be used to perform the upgrade.  AUTOGEN is run in
     Phase 6 and IF there is an entry in SYS$SYSTEM:MODPARAMS.DAT, the
     correct value will be reset at that time.

  o  If the current system is running V5.4 or a variant, the customer
     should delete any "SET ENVIRONMENT/CLUSTER" commands from all
     SYSMANINI.INI files used.

  o  Have the customer check for out of range SYSGEN parameters.  Do
     the following for EACH node in the VAXcluster before beginning
     the upgrade.

       o  Make a copy of SYS$SYSTEM:SETPARAMS.DAT:

               $ COPY SYS$SYSTEM:SETPARAMS.DAT SYS$SYSTEM:SETPARAMS.COM

       o  Edit the new file:

               $ EDIT SYS$SYSTEM:SETPARAMS.COM

       o  Add the following lines to the beginning of the file:

               $ SET VERIFY
               $ SYSMAN = "$SYSMAN"
               $ SYSMAN
                 < Rest of file here with 'parameter ' added to the >
                 < beginning of each line.  Example:                >
                 <   parameter use current                          >
                 <   parameter write sys$system:vaxvmssys.old       >
                 <   parameter use default                          >
                 <   parameter    :                                 >

       o Execute the new file:

               $ @SYS$SYSTEM:SETPARAMS.COM

  o  Does the system have PATHWORKS or is INFOSERVER software used?
     If YES, then send CSCPAT_0269.

  o  Does the customer use a print symbiont other the one supplied by
     VMS?
     If YES, then upgrade to A5.5.

  o  To avoid an installation problem, have the customer answer the
     question:

       "Do you wish to upgrade to the new JOB_CONTROL at this time [NO]?"

     with "NO".  The upgrade will complete and the customer will be
     running A5.5.  If the decision has been made to continue to
     upgrade to V5.5, they can execute the procedure
     @SYS$UPDATE:VMS$UPGRADE_A55_V55.COM.  If the decision was made to
     stay at A5.5, they should not complete the upgrade to V5.5 until
     the queue manager patches are available.
\
\
\ CONTRIBUTOR(S):
\
\      Technical:
\           Sue Clavin (140154) of SPACE
\           Karen Meadows (166532) of SPACE
\
\      Editorial:
\           Terri Gazzara (199612) of SPACE
\           Cathy Martin (120172) of SPACE
\
\\ UPDATE JOBCTL LCKMGR

    Re . previous 10 or so.
    
    Let's step back a moment guys and calm down. 
    
    Glenn has made some statements that maybe he knows to be true but this has
    not been communicated to the Atlanta CSC ALL-IN-1 group.
    
    Jan is as always posting the most up-to-date information available in the 
    ALL-IN-1 STARS database and i've just checked and at 8:21pm (EDT) on 
    Wed 22nd he is to the best of my humble knowledge still doing so and the 
    article that has been described as 'woefully out-of-date' is still 
    current in OA1.
    
    the STARS article is taken from a mail message received here
    at the CSC from Bill Colquitt himself dated 16-Apr and entered by one
    of our Electronic Solutions People on 17-apr. I have checked my mail
    and whilst I have a lot of mail from Bill I see nothing that indicates
    a change in the official position of ALL-IN-1 Product Management.
    
    I am not saying anyone is wrong here but let's be a little more
    constructive - if it's wrong we'll fix it and I don't for one moment
    doubt that Glenn is saying the right thing but let's not attack the
    messenger.
    
    I will direct the STARS people at the article Glenn posted from the VMS 
    STARS database and will also attempt to contact Bill myself.
    
    we await further developments
    
    
    regards,
    
    Andrew.D.Wicks (ALL-IN-1 CSC group - Atlanta GA)
    

Glenn,

RE .45

>Jan, no the article does not reflect ALL-IN-1 product managements opinion.

Ok. So who is responsable for the following lines from this
very article ?

STARS_BEGIN
\ Versions supported per Bill Colquitt, ALL-IN-1 Product Management
\ as of 16-APR-1992:

ALL-IN-1 2.3, 2.4 will not be supported on VMS 5.5 clusters.
Single node 5.5 systems will be supported.

VMS version A5.5 will be supported in all circumstances.
\The above information is also true for ALL-IN-1 v3.0.
STARS_END

RE .46
>Wait a minute Jan. Read your own STARS article! Here's a quote from what you
>posted:

Its not my STARS article. I am just a humble CSC specialist 
from Holland. The article specifically mentions that the information
is from Bill Colquitt...

>VMS version A5.5 will be supported in all circumstances.
>See the last line. VMS A5.5 is supported in all ALL-IN-1 configurations. Why do
>you think otherwise?
Thats known since reply 2... A5.5 works fine.

re.48  
>          -< Thanks for looking in Glenn, I changed the title on .42 >-

My title was: "ALL-IN-1 not be supported on VMS V5.5 clusters",
statement from Bill Colquitt.

<OUT-OF-DATE

So what line is out of date ? Give me ONE !

The article is close to perfect (reviewed by Faith).

	- Problem description: OA$FORMATTER problems on 5.5
	- Pointer to "how to answer customer questions" article
	- How to get to A5.5 instead of V5.5
	- How to go back from V5.5 to A5.5
	- Final solution to US CSC and arcticle update

What more do you want.

RE.-1

>    Let's step back a moment guys and calm down. 

I AM CALM, VERY CALM..... Sorry. I am calm.

>    Jan is as always posting the most up-to-date information available in the 
>    ALL-IN-1 STARS database and i've just checked and at 8:21pm (EDT) on 

Getting calmer and calmer...

Jan

Yes Jan, I'm calm too. All I'm trying to do is clear up the misunderstanding that
still seems to exist around ALL-IN-1 & VMS 5.5. I'm not trying to attack anyone
or anything like that.

>Ok. So who is responsable for the following lines from this
>very article ?
>
>STARS_BEGIN
>\ Versions supported per Bill Colquitt, ALL-IN-1 Product Management
>\ as of 16-APR-1992:
>
>ALL-IN-1 2.3, 2.4 will not be supported on VMS 5.5 clusters.
>Single node 5.5 systems will be supported.
>
>VMS version A5.5 will be supported in all circumstances.
>\The above information is also true for ALL-IN-1 v3.0.
>STARS_END

Jan, please read what you've posted carefully; it confirms exactly what I've
been saying (which I got direct from Bill Colquitt, BTW). I think I see what
the confusion is though. The line:

	ALL-IN-1 2.3, 2.4 will not be supported on VMS 5.5 clusters.

Would have been written better as:

	ALL-IN-1 2.3, 2.4 will not be supported on VMS V5.5 clusters.

See that "V" in the VMS version number? That distinguishes the version from, say,
a field test version number. If you are running VMS V5.5 then you are running
the new distributed queueing system. The new distributed queueing system has
some problems with certain products under certain loads (ALL-IN-1 is one of
those problems). The work-around is to use VMS A5.5 on an ALL-IN-1 system. Note
the "A" in the version number. This means that you are running with all of the
new V5.5 functionality except for the queueing system. A5.5 systems are using
the old, non-distributed queueing system which works just fine with products
like ALL-IN-1.

That's why Bill goes on to say:

	VMS version A5.5 will be supported in all circumstances.

VMS A5.5 works fine with ALL-IN-1 in all configurations. If a customer (or
internal system) wants to go to VMS V5.5 they should just go to VMS A5.5 if they
are running ALL-IN-1.

Jan, your original note title said "don't use VMS 5.5 with ALL-IN-1" and that
is a very wrong message to be giving at this time.

Isn't the STARS article I posted rather clear on how to get to VMS A5.5, why
you use A5.5, and that it's ok to use A5.5 with ALL-IN-1?

I'll sure be glad when they release a patch kit to fix the queueing problem.
T5.5-1 is in external field test but the V5.5-1 kit (note the version code
indicators of T and V to clearly indicate what the version is) won't be
available until June or July it looks like.

-Glenn-

When the OA$FORMATTER and new queueing system problems started showing up
there were some CLD's raised.  VMS engineering came up with a patch to 
the queue manager that did *NOT* fix the problem, it just side-stepped it
enough to keep the whole job controller/queue manager environment from crashing
when the problem occurs.  It basically tells the queue manager to look the other
way when the problem occurs.  It does not mean that the OA$FORMATTER jobs stop
having problems etc. - it just keeps the rest of the system from falling over
dead. This patch was being used to close CLD's as they occured.  They then
passed the patch down to the CSC so that we could head off the CLD's before
they happened.

I debated over how to distribute this. It was definately not a general
distribution item and sites with problems needed to be qualified as legitimately
having this particular problem before being given the patch.  At the same time
I needed to be able to keep track of who we were giving the patch to so we can
send them the real fix when it finally occurs.  CSCPAT is the best vehicle we
have for tracking distributions. After talking with the VMS patch folks in
Colorado it was determined that they already had CSCPAT_1012 set aside as the
number for the job controller patch (when it finally comes). So I plugged
the CLD workaround into our local patch system as CSCPAT_1012 so we could 
record the distributions. Consequently, CSCPAT_1012 only exists here in
Atlanta (at the moment) and is only a temporary workaround for the problem.

I was not aware that the same information was not being made available to other
CSC's etc. I will check today on the latest status of the 'real' job controller
fixes.  If another CSC somewhere wants the workaround patch, please send me
mail.

mark

As of 9:00am EDT on 23-Apr-1992, the job controller fixes, which will be known
as CSCPAT_1012, have not been released to the US CSC.

    
    Hi,
    
    I rewrote the STARS article, based on your comments and feedback
    from Bill Colquitt. Below are his message and below that is the
    new article. Hopefully this will clear up any confusion.
    By the way, feedback to STARS articles should normally be done using
    the COMMENT ability of STARS; just select the article & type C and
    youll be put into an editor. If you do this quickly, Ill try to include
    your thoughts before the article becomes available to customers. 
    
    John Bryson
    Electronic Solutions Group
    
    ==========================================
    
    From Bill Colquitt 23-APR-1992. He said that I could post this mail message
    here; he may send out a memo as well:
     
     :                 

A1PM recommends that ALL ALL-IN-1 customers wait for VMS V5.5-1 due out in June
1992 from VMS engineering for a "fully tested" fix to the Job Controller 
and queue system problems. Some lock manager changes are helpful to A1
as well.

---- 
Additional comments: I have about 12 calls for customers that need to
go to V5.5 for hardware support. VMS clearly does not and should not
be expected to understand our commercial, heavy printer using base.
Suggestion like turn off background printing and it works fine, a
just silly and should not be made. We have about 6 66XX doing nothing
over this, run A5.5 be happy. That is about 1 Million each in equipment 
hanging out.

OUR cautious customers do not jump on a VMS release (they've seen this before)
and it is not a major inconvenience to wait a month or two. That is why I
am having trouble finding a cluster (not a single node) to field test
T5.5-1. 

-----

ALL-IN-1 Starter (V2.4) and ALL-IN-1 V2.3, V2.4, V2.4-1, V3.0
(official cut over was today) will be supported on VMS A5.5 in all 
circumstances.

We will NOT support ALL-IN-1 V2.3, V2.4, V3.0 on vanilla VMS V5.5 Multi-node 
clusters. (we know there are problems here - WHY do it you have options)

We will support a single node cluster V5.5 systems, under special 
circumstances, there are risks here and VMS has a patched .exe 
to deal with these issues. It DOES not fix but reduces the problems.

Now, we all know that if ALL-IN-1 users can just get to VMS it is useless.
If ALL-IN-1 users can get to A1 but can not print that Insurance policy, or
send out the 1,000 addressees paper form letter, or issue the Purchase 
Order, whatever is on the other end of th entry form, the system is 
not functional. So, please, stay on 5.4 and start your planning for 5.5-1
or go to A5.5. 

If your customers have a Multi-node A1 test cluster with some amount of
print/batch load then volunteer the site to test T5.5-1. Notify Tim Ellison
or Bill Colquitt @ZKO. 

				Thank you,

					Bill Colquitt
					ALL-IN-1 Product Management
                       
    
    ================================================
    
    Here is the updated STARS article. I hope its more clear now. Notice
    that a lot is hidden from customers (lines that start with \) for legal
    or customer satisfaction reasons:
    
Background Formatter May Hang On a VMS 5.5 System


COPYRIGHT (c) 1991, 1992 by Digital Equipment Corporation.
ALL RIGHTS RESERVED. No distribution except as provided under contract.


PRODUCT: ALL-IN-1 V2.3, V2.4, V3.0

OP/SYS: VAX VMS version 5.5 only

SOURCE: Customer Support Center/USA

\ by John Bryson (169710)
\ Per VMS STARS, Note 134 in IOSG::ALL-IN-1, Critical Information 
\ Bulletin No.34 to European customers on 27th March 1992, and messages
\ from ALL-IN-1 Product Management 
\
\ This article addresses only the background formatter issues with ALL-IN-1
\ and VMS V5.5 and not the lock manager issues. There is much information
\ in hidden text (lines that begin with a slash) that should be considered
\ DEC INTERNAL USE ONLY. Comments should be made using the 'COMMENT'
\ functionality of STARS/TIMA.

INFORMATION:

On VMS version V5.5 systems, some sites have experienced problems 
with printing when the background formatter (OA$FORMATTER) is used. 

When jobs are submitted from the background within ALL-IN-1 or WPS-PLUS 
onto a device queue, and the device queue is invalid, the QUEUE_MANAGER 
process will fail. Although the QUEUE_MANAGER will "fail over" to another
node in the VAXCLUSTER it will fail on that node too. It will be 
necessary to delete the job from the formatter queue.

This has been been reported on very large clusters when the new VMS
V5.5 job controller is used. If the system is a stand-alone or small 
clustered system, then the situation described here is not expected 
to occur.

The formatter problem occurs on VMS version V5.5, because V5.5 introduces 
new queue manager / job controller functionality.  To perform background
printing the OA$FORMATTER must communicate with the job controller. 
The changes implemented in VMS Version V5.5, in some cases, result in
a failure of the required communication between the OA$FORMATTER and
the job controller.  When this occurs, it can cause the job controller
to hang.  

Some sites may have a choice about when to upgrade to VMS version V5.5,
but others may be required to use version V5.5 now. The following 
hardware configurations require VMS Version V5.5:

        VAX 6000 Model 600
        VAX 4000 Model 500
        VAX 3100 Models 30, 40, and 80
        VAXstation 4000 Model 60
        VAXstation 4000 VLC
        VAX 4000 Model 300 and 200

\ ************ DIGITAL INTERNAL USE ONLY ******************
\ Refer also to the article in the VMS_V5 STARS database titled:
\
\   How To Answer Customer Question 'Should I Upgrade to VMS V5.5?'
\ 
\ for complete details regarding the VMS V5.5 job problem(s).

ALTERNATIVES:

If a site must use VMS version V5.5, then they can avoid the situation
by using the VMS V5.4 job controller instead of the new V5.5 controller. 
This can be done by staying at VMS V5.4 or going to VMS A5.5. Notice 
that version A5.5 is essentially V5.5 but with the V5.4 job controller.

\ The next 3 paragraphs detail the versions supported by 
\ ALL-IN-1 Product Management, per mail message on 23-APR-1992: 
\
ALL-IN-1 Starter (V2.4) and ALL-IN-1 V2.3, V2.4, V2.4-1, V3.0 will be 
supported on VMS A5.5 in all circumstances.

ALL-IN-1 V2.3, V2.4, V3.0 on vanilla VMS V5.5 Multi-node clusters will
not be supported.

Single node cluster V5.5 systems will be supported.
                          
Please notice that VMS A5.5 is not the same as VMS V5.5.

\ *** DIGITAL INTERNAL ONLY ******
\ Under special circumstances, there are risks with the single cluster
\ configuration as well, and VMS support has a patched .EXE to deal with 
\ these lock manager issues (although this patch is not normally 
\ recommended). This lockmanager patch does NOT fix but reduces the 
\ problems. It is anticipated that a solution will be implemented in a 
\ future version of VMS.

For the hardware configurations that require VMS Version V5.5, the
options are more limited; A5.5 can not be used. It is anticipated this
will be addressed in a future release of VMS.
\ V5.5-1?

Sites that have this requirement should contact their Customer Support 
Center.
\
\ ALL-IN-1 product management recommends that customers wait for VMS V5.5-1
\ due out in June 1992 from VMS engineering for a fully tested fix to the 
\ Job Controller and queue system problems. This should also include 
\ some lock manager changes. If this is unacceptable, see the other options
\ in this article, including the note below.
\
\ NOTE: Care should be used when talking about future versions of software, 
\       so a customer satisfaction issue is not created. As of April 24,
\       VMS V5.5-1 was not available to customers, although a field test 
\       version (T5.5-1) is being evaluated.
\
\       Also, PLEASE be sure that the problem described in this article does 
\       relate to a site before trying to address the issues in this article. 
\       Not all sites are affected.
\
\ NOTE: If your customers have a Multi-node ALL-IN-1 test cluster with 
\       some amount of print/batch load, then you may want to volunteer 
\       the site to test T5.5-1. Notify Tim Ellison or Bill Colquitt @ZKO. 

MORE INFORMATION:

During phase 6 of the VMS 5.5 Upgrade, the question is asked:

 "Do you wish to upgrade to the new JOB_CONTROL at this time [NO]?"

If this question is answered "NO", the resulting VMS system (after a 
reboot) will show version A5.5 and will be running the old job 
controller (v5.4). In this case, the formatter problem should not 
occur.  This is the recommended configuration when running 
ALL-IN-1 on the system. The new job controller can always be 
enabled at a later time if desired.

If this question is answered "YES", then the new job controller is 
used and the VMS version will be V5.5, not A5.5 after a reboot, 
and the formatter situation described above might occur on a large 
clustered ALL-IN-1 system.

\ The following information was included in a DSNlink FLASH article 
\ to European customers in "Critical Information Bulletin No.34 - 
\ 27th March 1992" :
If a site has already installed VMS 5.5 and also implemented the V5.5 
job controller and now want to go back to the V5.4 job controller, the
following procedure may be used to accomplish this. This procedure 
requires the cluster to be rebooted, and the print and batch queues to 
be defined.
        
 The old print and batch facility is enabled by modifying the
 file SYS$SYSROOT:[SYS$STARTUP]VMS$CONFIG-050_JOBCTL.COM;.
        
 The change required is :

 $master_file = f$parse("QMAN$MASTER","SYS$SYSTEM:QMAN$MASTER.DAT",,,"SYNTAX_ONL
 $if f$search(master_file) .nes. ""
 $then
 $newjobctl = 1
 $else
 $newjobctl = 0
 $endif
 $endif
 $define/user sys$output nl:
 $!
 $! Insert line here to make symbol Newjobctl=0 to use
 $! old Print and Batch Facility. The code takes the else option
 $! from the if statement.
 $!
 $ Newjobctl=0
 $!
 $!

 The difference is, insert a line of DCL after the $DEFINE/USER
 to set the symbol newjobctl=0.

 A cluster is reboot is required, a rolling reboot cannot be performed 
 as only one style of print and batch facility can be active within the 
 VAXCLUSTER at any one time. After the reboot the V5.4 job controller 
 will be used, so the queue problem described above will not occur.

\ ************ DIGITAL INTERNAL USE ONLY ******************
\ Per VMS support there are currently, as of April 3, no 
\ Engineering supplied supported patch(es) to fix the job 
\ controller issues.
\ When patch(es) are available, the US Customer Support Center
\ will be notified immediately and this article should be updated.  
\ It is anticipated that the patch will be available through the 
\ CSCPAT Utility.
\
\ For information on the patches compatible with VMS Version 5.5,
\ activate the V5_VMS STARS database and query on "5.5  \CSCPAT_INFO"
\
\\ A1_IOS OA1 %QX902
\\ VER_2.3_A1_IOS VER_2.4_A1_IOS VER_3.0_A1_IOS
\\ ?CSCPAT_1012 PATCH
\ B36.REF
\\ UPDATED_V3.0
    ===================================================
    
Background Formatter May Hang On a VMS 5.5 System


COPYRIGHT (c) 1991, 1992 by Digital Equipment Corporation.
ALL RIGHTS RESERVED. No distribution except as provided under contract.


PRODUCT: ALL-IN-1 V2.3, V2.4, V3.0

OP/SYS: VAX VMS version 5.5 only

SOURCE: Customer Support Center/USA

\ by John Bryson (169710)
\ Per VMS STARS, Note 134 in IOSG::ALL-IN-1, Critical Information 
\ Bulletin No.34 to European customers on 27th March 1992, and messages
\ from ALL-IN-1 Product Management 
\
\ This article addresses only the background formatter issues with ALL-IN-1
\ and VMS V5.5 and not the lock manager issues. There is much information
\ in hidden text (lines that begin with a slash) that should be considered
\ DEC INTERNAL USE ONLY. Comments should be made using the 'COMMENT'
\ functionality of STARS/TIMA.

INFORMATION:

On VMS version V5.5 systems, some sites have experienced problems 
with printing when the background formatter (OA$FORMATTER) is used. 

When jobs are submitted from the background within ALL-IN-1 or WPS-PLUS 
onto a device queue, and the device queue is invalid, the QUEUE_MANAGER 
process will fail. Although the QUEUE_MANAGER will "fail over" to another
node in the VAXCLUSTER it will fail on that node too. It will be 
necessary to delete the job from the formatter queue.

This has been been reported on very large clusters when the new VMS
V5.5 job controller is used. If the system is a stand-alone or small 
clustered system, then the situation described here is not expected 
to occur.

The formatter problem occurs on VMS version V5.5, because V5.5 introduces 
new queue manager / job controller functionality.  To perform background
printing the OA$FORMATTER must communicate with the job controller. 
The changes implemented in VMS Version V5.5, in some cases, result in
a failure of the required communication between the OA$FORMATTER and
the job controller.  When this occurs, it can cause the job controller
to hang.  

Some sites may have a choice about when to upgrade to VMS version V5.5,
but others may be required to use version V5.5 now. The following 
hardware configurations require VMS Version V5.5:

        VAX 6000 Model 600
        VAX 4000 Model 500
        VAX 3100 Models 30, 40, and 80
        VAXstation 4000 Model 60
        VAXstation 4000 VLC
        VAX 4000 Model 300 and 200

\ ************ DIGITAL INTERNAL USE ONLY ******************
\ Refer also to the article in the VMS_V5 STARS database titled:
\
\   How To Answer Customer Question 'Should I Upgrade to VMS V5.5?'
\ 
\ for complete details regarding the VMS V5.5 job problem(s).

ALTERNATIVES:

If a site must use VMS version V5.5, then they can avoid the situation
by using the VMS V5.4 job controller instead of the new V5.5 controller. 
This can be done by staying at VMS V5.4 or going to VMS A5.5. Notice 
that version A5.5 is essentially V5.5 but with the V5.4 job controller.

\ The next 3 paragraphs detail the versions supported by 
\ ALL-IN-1 Product Management, per mail message on 23-APR-1992: 
\
ALL-IN-1 Starter (V2.4) and ALL-IN-1 V2.3, V2.4, V2.4-1, V3.0 will be 
supported on VMS A5.5 in all circumstances.

ALL-IN-1 V2.3, V2.4, V3.0 on vanilla VMS V5.5 Multi-node clusters will
not be supported.

Single node cluster V5.5 systems will be supported.

Please notice that VMS A5.5 is not the same as VMS V5.5.

\ *** DIGITAL INTERNAL ONLY ******
\ Under special circumstances, there are risks with the single cluster
\ configuration as well, and VMS support has a patched .EXE to deal with 
\ these lock manager issues (although this patch is not normally 
\ recommended). This lockmanager patch does NOT fix but reduces the 
\ problems. It is anticipated that a solution will be implemented in a 
\ future version of VMS.

For the hardware configurations that require VMS Version V5.5, the
options are more limited; A5.5 can not be used. It is anticipated this
will be addressed in a future release of VMS.
\ V5.5-1?

Sites that have this requirement should contact their Customer Support 
Center.
\
\ ALL-IN-1 product management recommends that customers wait for VMS V5.5-1
\ due out in June 1992 from VMS engineering for a fully tested fix to the 
\ Job Controller and queue system problems. This should also include 
\ some lock manager changes. If this is unacceptable, see the other options
\ in this article, including the note below.
\
\ NOTE: Care should be used when talking about future versions of software, 
\       so a customer satisfaction issue is not created. As of April 24,
\       VMS V5.5-1 was not available to customers, although a field test 
\       version (T5.5-1) is being evaluated.
\
\       Also, PLEASE be sure that the problem described in this article does 
\       relate to a site before trying to address the issues in this article. 
\       Not all sites are affected.
\
\ NOTE: If your customers have a Multi-node ALL-IN-1 test cluster with 
\       some amount of print/batch load, then you may want to volunteer 
\       the site to test T5.5-1. Notify Tim Ellison or Bill Colquitt @ZKO. 

MORE INFORMATION:

During phase 6 of the VMS 5.5 Upgrade, the question is asked:

 "Do you wish to upgrade to the new JOB_CONTROL at this time [NO]?"

If this question is answered "NO", the resulting VMS system (after a 
reboot) will show version A5.5 and will be running the old job 
controller (v5.4). In this case, the formatter problem should not 
occur.  This is the recommended configuration when running 
ALL-IN-1 on the system. The new job controller can always be 
enabled at a later time if desired.

If this question is answered "YES", then the new job controller is 
used and the VMS version will be V5.5, not A5.5 after a reboot, 
and the formatter situation described above might occur on a large 
clustered ALL-IN-1 system.

\ The following information was included in a DSNlink FLASH article 
\ to European customers in "Critical Information Bulletin No.34 - 
\ 27th March 1992" :
If a site has already installed VMS 5.5 and also implemented the V5.5 
job controller and now want to go back to the V5.4 job controller, the
following procedure may be used to accomplish this. This procedure 
requires the cluster to be rebooted, and the print and batch queues to 
be defined.
        
 The old print and batch facility is enabled by modifying the
 file SYS$SYSROOT:[SYS$STARTUP]VMS$CONFIG-050_JOBCTL.COM;.
        
 The change required is :

 $master_file = f$parse("QMAN$MASTER","SYS$SYSTEM:QMAN$MASTER.DAT",,,"SYNTAX_ONL
 $if f$search(master_file) .nes. ""
 $then
 $newjobctl = 1
 $else
 $newjobctl = 0
 $endif
 $endif
 $define/user sys$output nl:
 $!
 $! Insert line here to make symbol Newjobctl=0 to use
 $! old Print and Batch Facility. The code takes the else option
 $! from the if statement.
 $!
 $ Newjobctl=0
 $!
 $!

 The difference is, insert a line of DCL after the $DEFINE/USER
 to set the symbol newjobctl=0.

 A cluster is reboot is required, a rolling reboot cannot be performed 
 as only one style of print and batch facility can be active within the 
 VAXCLUSTER at any one time. After the reboot the V5.4 job controller 
 will be used, so the queue problem described above will not occur.

\ ************ DIGITAL INTERNAL USE ONLY ******************
\ Per VMS support there are currently, as of April 3, no 
\ Engineering supplied supported patch(es) to fix the job 
\ controller issues.
\ When patch(es) are available, the US Customer Support Center
\ will be notified immediately and this article should be updated.  
\ It is anticipated that the patch will be available through the 
\ CSCPAT Utility.
\
\ For information on the patches compatible with VMS Version 5.5,
\ activate the V5_VMS STARS database and query on "5.5  \CSCPAT_INFO"
\
\\ A1_IOS OA1 %QX902
\\ VER_2.3_A1_IOS VER_2.4_A1_IOS VER_3.0_A1_IOS
\\ ?CSCPAT_1012 PATCH
\ B36.REF
\\ UPDATED_V3.0
    

John, in the new STARS article, where does Bill say to wait more months for
VMS V5.5-1? I just read the article and it clearly states to use VMS A5.5 if
you want to (i.e., use the old job controller and you'll be fine).

I'll call both product managers yet again today and double-check that A5.5 is
ok. Perhaps one or both of them have changed their minds but they both quite
explicitly told me that they have no problem whatsoever with VMS A5.5 in any
hardware configuration even if A1 is being used.

-Glenn-

I jusr got off the phone with Bill Colquitt. He reiterated to me that if you
have to go to VMS 5.5 for hardware reasons or if you would like to use the new
5.5 features like the move file primitive (for disk defragging) then go right
ahead.

All Bill is saying now that is if you are a conservative site (and we know that
most ALL-IN-1 managers are conservative!) then you should wait until VMS V5.5-1
is available.

But Bill is definately *not* saying don't go to A5.5 if you want to. I think you
have taken his quote at the beginning of reply .54 out of context. The key word
in Bill's quote is "recommends". But as he says, if you want to go to 5.5 for
hardware reasons or to use the new features, go right ahead.

The story hasn't changed. Please don't tell folks otherwise.

-Glenn-

I hate to burst anyone's bubble, but regarding the following section of the
STARS article referenced in .54:

>This has been been reported on very large clusters when the new VMS
>V5.5 job controller is used. If the system is a stand-alone or small
>clustered system, then the situation described here is not expected
>to occur.

I have a customer who has experienced this problem on a stand-alone node. The
customer is running VMS V5.5 and ALL-IN-1 V2.4. As a workaround, we disabled
the capability to perform background formatting. The customer is pleased with
this workaround, as it allows him to take advantage of the VMS V5.5 job
controller and still print his ALL-IN-1 documents until a more permanent
solution can be delivered.

BC

    I saw in VMSnotes references to ALL-in-1 notes 134. My group, VAXworks,
    which host VMSnotes hasn't handled remedial support for 3 years but we
    try to help out.
    
    -Weimin Tchen

                 <<< $1$DUS6:[NOTES$LIBRARY]VMSNOTES.NOTE;1 >>>
             -< VAX/VMS and more!  *** FOR INTERNAL USE ONLY ***. >-
================================================================================
Note 401.55                    VMS 5.5. in Prod ?                       55 of 55
VAXWRK::TCHEN "Weimin Tchen VAXworks 223-6004 PKO2" 193 lines  30-APR-1992 12:40
            -< Queue manager kit for 5.5 (w/ same images in 5.5-1) >-
--------------------------------------------------------------------------------
    BATCH_PRINT$02_055.readme is rather lengthy so you can get it from:
    
    vaxwrk::sys$public:BATCH_PRINT$02_055.README
    
    Please get the fix from your CSC. An extract follows (I left in the
    problem analyses with references to ALL-in-1 since this seems to be
    a popular subject :-} ) :
    
    

1  KIT NAME:

     BATCH_PRINT$02_055


2  KIT DESCRIPTION:

     2.1  Version(s) of VAX/VMS to which this kit may be applied:

     VAX/VMS V5.5, A5.5.



3  PROBLEMS ADDRESSED IN THIS KIT

                    SYS$LOADABLE_IMAGES:MESSAGE_ROUTINES


     3.1  $SNDJBC can crash the system under certain circumstances

          3.1.1  Problem Description:

          A heavily loaded system  might  crash  with  PGFIPLHI  as  the
          result  of  a  $SNDJBC in EXE$SEND_TO_QMAN_KERNEL.  This is an
          extremely infrequent occurrence.


     3.2  Obsolete reference to queue address (ALTER ACTIVE QUEUE)


          3.2.1  Problem Description:

          The queue manager crashes with "%QMAN-F-INVREF, invalid object
          reference" and you have OA$FORMATTER running on your system.

          3.2.3  Problem Analysis:
    
          In this case, it is executing the  routine ALTER_ACTIVE_QUEUE
          called  from  FINISH_JOB.  This event has not been reported in
          conjunction with the  stock  PRTSMB,  LATSYM  or  CPS  to our
          knowledge.  It has been seen though in VMS V5.5 in association
          with All-In-One's OA$FORMATTER.
    
          A footprint in the V5.5 Queue manager dump  for  this problem
          is:
    
                 module name  routine name         line   rel PC    abs PC
                 MANAGE       ALTER_ACTIVE_QUEUE   830  00000036    0000A3E4
    
     3.3  A print queue seems to be executing more than one job

          3.3.1  Problem Description:

          A print queue may appear to be executing more than one job  at
          a  time  causing  the  queue manager to crash with the message
          "%QMAN-F-BADLOGIC,  internal  logic  error  detected   at   PC
          04FE1154".


     3.4  INITIALIZE/CPUMAXIMUM is being ignored

          3.4.1  Problem Description:

          A queue with /CPUMAXIMUM set  and  /CPUDEFAULT  not  set  will
          allow  a  job  infinite  CPU time if the job is submitted that
          way.


     3.5  Queue database corruption, symbiont id zero

          3.5.1  Problem Description:

          The queue manager reports queue database  corruption  of  this
          type  and  refuses  to start.  The queue manager reports queue
          database corruption and will not start.


     3.6  Symbionts that worked in V5.4 don't with V5.5

          3.6.1  Problem Description:

          Symbionts that worked previous to  V5.5  sometimes  dump  with
          JBC$_INVMSG.


     3.7  Stopping a print queue causes corruption

          3.7.1  Problem Description:

          Sometimes stopping a print queue under  VMS  V5.5  will  cause
          corruption  in  the  queue  database.   This  problem has been
          reported with PRTSMB.


     3.8  Sybionts not providing start task

          3.8.1  Problem Description:

          Symbionts crash the queue manager by sending a  task  complete
          message  without informing the queue manager that it started a
          task.

          3.8.3  Problem Analysis:
    
           Some symbionts fail to provide  the  START_TASK  message  when
          processing  a job.  The OA$FORMATTER from All-in-1 is one such
          symbiont.  In V5.4 symbionts were able to get away  with  this
          breach  in protocol.  In V5.5 the job is rescheduled over, and
          over again.


     3.9  Start new Journal failure causes corruption

          3.9.1  Problem Description:

          The Queue manager fails to rename the journal file or fails to
          create  new journal after renaming the old one, then the queue
          manager cannot to restart with that  database.   The  failures
          will  be  reported  in the operator.log as write errors in the
          rename attempt or as create errors in the creation attempt.



     3.10  Missing generic target list verification.

          3.10.1  Problem Description:

          If an executor queue being referenced by a  generic  queue  is
          deleted,  the queue manager fails when it tries to recover the
          database.  The database must be deleted and a new one created.


     3.11  Queue database corruption, starting batch job with EPID.

          3.11.1  Problem Description:

          When the database is corrupted  in  this  fashion,  the  queue
          manager  is  stopped  and  any  attempt to start it causes the
          queue manager to dump.


     3.12  Qman journal file FAB fix up.

          3.12.1  Problem Description:

          The   queue   manager   sometimes   dumps   with    SYSERRORPC
          DELETE_JOURNAL_FILE messages.



     3.13  Queue Manager may continue to crash on one particular message

          3.13.1  Problem Description:

          Queue management will stop as a result of a bad message from a
          user written symbiont.


     3.14  QMAN's handling of SYMDEL on NORMAL

          3.14.1  Problem Description:

          When shutting down a node, the queue manager signals (probably
          more than once):
            "%QMAN-E-SYMDEL, unexpected symbiont process termination
            -SYSTEM-S-NORMAL, normal successful completion".
          These    messages    are    also    accompanied     by     the
          "%QMAN-I-QUEAUTOOFF" message (indicating that the queue is now
          autostart inactive) if the symbiont had been processor for  an
          autostart queue.


     3.15  Job count broken by open jobs after fail over.
    
          3.15.1  Problem Description:

          An open, incomplete  job,  in  the  queue  may  be  marked  as
          executing,  when it is not, if the Queue manager fails over to
          another node before the job is completed.  This could occur in
          the case of PRINT requests from MAIL and having the node crash
          before the final request to print is entered.

And this kit actually is available at the CSC! :-)

CSCPAT_1012011.A - got my copy already.

-Glenn-

    After a request I put the kit in:
    
    vaxwrk::sys$public:BAT_PRNT$02_055.A;1

    Hello,
    
    I started this note, so so I might as well end it.
    
    CSCPAT_1012 is there.
    
    Here are the release notes.
    
    ====================================================================


    This patch has been provided by a Digital Customer Support Center.


                                DISCLAIMER
 
    This patch has not been through an exhaustive field test process.
    Due to the experimental stage of this software patch/workaround, 
    Digital makes no representations regarding its use, or performance. 
    Digital accepts no responsibility for any expenses, losses or action 
    incurred or undertaken by any party as a result of their use of this 
    software.  This software is provided "AS IS" and "WITH ALL FAULTS".
    Digital provides no warranties either express and implied in law, 
    including IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A 
    PARTICULAR PURPOSE.  In no event shall Digital have any liability 
    whatsoever for incidental and consequential damages as a result of
    the  performance, use or operation of this software.  The customer
    shall  have the sole responsibility for adequate protection and
    back-up data used in conjunction with the above software
    patch/workaround. 

----------------------------------------------------------------------------
Kit Description:

     Version(s) of VAX/VMS to which this kit may be applied:

     VAX/VMS V5.5, A5.5.

                             PATHWORKS CUSTOMERS

             If the customer is just upgrading to V5.5 and is  a
             user  of  PATHWORKS,  they  must  upgrade PATHWORKS
             before applying this kit as the  included  symbiont
             images update those installed by the PATHWORKS kits
             for V5.5.


                                   LATSYM

             There are associated LATSYM  fixes.   Please  check
             with  your  support  center  for  the latest LATSYM
             image.



     Images patched or replaced:


      o  SYS$LOADABLE_IMAGES:MESSAGE_ROUTINES.EXE (new image)

      o  SYS$SYSTEM:JBC$JOB_CONTROL.EXE           (new image)

      o  SYS$SYSTEM:QMAN$QUEUE_MANAGER.EXE        (new image)

      o  SYS$SHARE:SMBSRVSHR.EXE                  (new image)

      o  SYS$SHARE:SMBSRVSHR_OLD.EXE              (new image)



Problems addressed in this kit

                    SYS$LOADABLE_IMAGES:MESSAGE_ROUTINES

     A heavily loaded system might crash with PGFIPLHI as the result  of
     a   $SNDJBC  in  EXE$SEND_TO_QMAN_KERNEL.   This  is  an  extremely
     infrequent occurrence.

                   Other Batch/Print/Job Control problems

     The queue manager  crashes  with  "%QMAN-F-INVREF,  invalid  object
     reference" and you have OA$FORMATTER running on your system.


     A print queue may appear to be executing more than  one  job  at  a
     time   causing   the  queue  manager  to  crash  with  the  message
     "%QMAN-F-BADLOGIC, internal logic error detected at PC 04FE1154".

     A queue with /CPUMAXIMUM set and /CPUDEFAULT not set will  allow  a
     job infinite CPU time if the job is submitted that way.

     The queue manager reports queue database corruption  and  will  not
     start.

     Symbionts  that  worked  previous  to  V5.5  sometimes  dump   with
     JBC$_INVMSG.

     Sometimes  stopping  a  print  queue  under  VMS  V5.5  will  cause
     corruption  in  the queue database.  This problem has been reported
     with PRTSMB.

     Symbionts crash the  queue  manager  by  sending  a  task  complete
     message without informing the queue manager that it started a task.

     The Queue manager fails to rename the  journal  file  or  fails  to
     create  new  journal  after  renaming  the  old one, then the queue
     manager cannot to restart with that database.  The failures will be
     reported  in the operator.log as write errors in the rename attempt
     or as create errors in the creation attempt.

     If an executor  queue  being  referenced  by  a  generic  queue  is
     deleted,  the  queue  manager  fails  when  it tries to recover the
     database.  The database must be deleted and a new one created.

     When the database is corrupted in this fashion, the  queue  manager
     is  stopped and any attempt to start it causes the queue manager to
     dump.

     The    queue    manager    sometimes    dumps    with    SYSERRORPC
     DELETE_JOURNAL_FILE messages.

     Queue management will stop as a result of a bad message from a user
     written symbiont.

     When shutting down a node, the queue manager signals (probably more
     than once):
       "%QMAN-E-SYMDEL, unexpected symbiont process termination
       -SYSTEM-S-NORMAL, normal successful completion".
     These messages are also  accompanied  by  the  "%QMAN-I-QUEAUTOOFF"
     message  (indicating  that  the queue is now autostart inactive) if
     the symbiont had been processor for an autostart queue.

     An open, incomplete job, in the queue may be marked  as  executing,
     when  it  is  not,  if the Queue manager fails over to another node
     before the job is completed.  This could occur in the case of PRINT
     requests  from  MAIL  and  having  the  node crash before the final
     request to print is entered.


Installation Instructions:

     Install this kit with the VMSINSTAL utility  by  logging  into  the
     SYSTEM account, and typing the following at the DCL prompt:

         @SYS$UPDATE:VMSINSTAL CSCPAT_1012 [location of the saveset]

     The saveset location may be a tape drive, or a disk directory  that
     contains the kit saveset.

                                   REBOOT

             This kit will require a  system/cluster  reboot  to 
             fully take  effect.  Stopping and starting the queue
             manager will not cause all of the fixes  to  become
             active.

  This patch kit does *not* purge the original files that are updated on the
  system. Before proceeding with this installation, please save a copy of
  the original files for example:

            $ COPY SYS$SYSTEM:IMAGE.EXE - 
                     SYS$SYSTEM:IMAGE_SAVE.EXE


  Before performing subsequent VMS upgrades, please restore this saved
  version.

    
    
    

    RE: the disclaimer at the beginning of .61 --
    
    I think I'm right in saying that the clause denying all responsibility
    including "fitness for purpose and merchantability" is unlawful in
    Enlgand (unfair contract terms act, or somesuch name).
    
    So take care . . .
    
    Dave

    My customer has VMS 5.5 and ALLIN1 2.4 .I have installed the patch	
    BAT_PRNT$02_055.A .
    After this patch and reboot , I have ALWAYS some problems :
    
    		crash of OA$FORMATTER on a vax
    		job in retain on error on the queue oa$formatter on
    the other vax .
    
    Can someone else has this pb .
    
    thanks for help
    best regards
    philippe

Um, is there some reason you have given a kit from the network that is for
internal use only to a customer? That's a firing offense as I understand it.

If I were you I would have that customer call the appropriate support
organization (like the CSC) to get the proper patch for their system. The
CSC or whatever support organization should be able to help them with the
OA$FORMATTER stuff you mention.

Please, folks. Network kits, particularly patch kits, must not be given to
customers.

-Glenn-

    Hello,
    
    This patch has been given by SUPPORT FRANCE VMS.I have not token
    this by network .
    
    Is there another patch ? Why in this notes , he says that you can
    take this patch in sys$public ?
    
    thanks for help
    philippe

The patch is in VAXWRK::SYS$PUBLIC: for internal use only. It is not something
to be given to customers.

Perhaps this is the actual kit that France is giving to customers. I may have
jumped to conclusions. As long as the customer got the patch kit from the
official support channels you should be ok.

-Glenn-

    My customer just handed me a list of problems/resolutions he got from a
    CSC representative.  He's very concerned with what he read!!  This is
    what it said:
    
    -----
    
    Prob: Is WPS+ Update compatible with VMS v5.5?
    
    Sol: WPS+ Update works with VMS v5.5.  However, there are printing and
    lock manager problems with ANY version of ALL-IN-1 on VMS v5.5.  The
    recommendation is not to upgrade to VMS v5.5 unless you have to and if
    you must, upgrade to VMS A5.5.  VMS v5.5-1 does not fully resolve the
    problems but VMS v5.5-2 is expected to.  Currently there are no dates
    for the availability of VMS v5.5-2.
    
    -----
    
    Can someone explain what this means!!???  The customer was ready to
    upgrade his cluster to v5.5 with the knowledge that 5.5-1 is just
    around the bend.  With the generalization in the statement above, it
    scares the &^#@ out of them.  Hopefully they will eventually upgrade.
    
    Someone, please explain what the information stated above means.  What
    does 'v5.5-1 does not fully resolve the problems' mean?  I've heard
    that we've got many (large) ALL-IN-1 sites running fine with v5.5-1
    (PATCHes).  Please explain!!
    
    -Piyush

    Piyush,
    
    I fail to understand what you are asking for over and above what has
    already been talked to death in this note.
    
    Please see reply .54 which details the "official" position on this
    topic.
    
    Regards,
    
    Andrew.D.Wicks 

    I hate to disagree with such a distinguished Welshman, ;-) 
    but it seems to me .54 is no longer the official position.....
    
    In the end of the quoted STARS article it says that as soon as
    the patch CSCPAT_1012 is released it (the article) should be
    updated. As reported in replies .60-something the patch is now
    available, *and* the STARS article is indeed updated a week ago
    to contain info on this patch. But it seems the lock manager
    issue is still not solved. 
    
    Hans

    From .54
    
    >A1PM recommends that ALL ALL-IN-1 customers wait for VMS V5.5-1 due
    >out in June 1992 from VMS engineering for a "fully tested" fix to the
    >Job Controller and queue system problems. Some lock manager changes
    >are helpful to A1 as well.
    
    From the letter to my customer:
    
    >The recommendation is not to upgrade to VMS v5.5 unless you have to
    >and if you must, upgrade to VMS A5.5.  VMS v5.5-1 does not fully
    >resolve the problem but VMS v5.5-2 is expected to.  Currently there
    >are no dates for the availability of VMS v5.5-2.
    
    Now, you tell me, what should my customer be doing?  Who should he be
    listening to?  Maybe some of the ALL-IN-1 sites do need to wait for
    the VMS v5.5-2 release.  If so, we need to be clear on exactly which
    customers!  In other words, who can go to 5.5-1 and who needs to wait
    for 5.5-2.
    
    My customers took one of the first shipments of a 6640.  We had to
    reduce it to a 6540!!!  It's costing Digital money to keep that box
    running a 540 when we should be running a 640!  To top it all off, they
    plan on buying a couple of more of these boxes but are concerned when
    they should take delivery - can you say Q4 revenue!!!!
    
    Anyway, whatever the party line, let's get it straight!  Don't send our
    customers a short paragraph telling them that v5.5-1 wont work when
    others are being told that 5.5-1 will fix their problems.
    
    Send the field the same information our customers see (or vice versa)!
    
    -pr

If your customer purchased hardware that needs V5.5 then by all means you
should have that customer go to V5.5 and install the lock manager and queueing
system patches. Call Bill Colquitt, the A1PM, for confirmation of this.

You should listen to a product's product manager. To do otherwise is to not
be responsible.  The situation is quite simple and I fail to understand
why so many folks are making a mountain out of this mole hill!

-Glenn-

    re .-1
    
>                   -< It's been said a thousand times now! >-

    A communication failure is not always caused by the receiver,
    sometimes the sender is to blame. Repeating a message that
    is not understood a thousand times, is a waste of time.
    
    I re-read all .70 replies and all related STARS articles.
    It is still not clear to me what "lock manager" problems related to
    ALL-IN-1 existed/are fixed/are not fixed. Neither what the impact
    is at a customer side.
    
    Sorry,
    
    Jan
    
    
    fix 
    

    

Well, all I can do is repeat the message yet again. Have your customer go to
VMS V5.5, install the lock manager and queueing system patches, and ALL-IN-1
is supposed to run just fine under such a configuration. By all means, get the
customer up-and-running on his new 6640. Again, if you want to confirm this
course of action for a particular customer, call Bill Colquitt, A1PM. Seems to
me that the product manager is the ultimate source of what to advise a
customer. If you don't believe what's said here, go to the "horse's mouth".

How clearer can it be said?

-Glenn-

� Again, if you want to confirm this
� course of action for a particular customer, call Bill Colquitt, A1PM. Seems to
� me that the product manager is the ultimate source of what to advise a
� customer. If you don't believe what's said here, go to the "horse's mouth"

	Well, I've heard *other* equine anatomical references used for Bill, but
this is a new one!

	8^)

The VMS V5.5-1 SSB kit is available from the VMS kit distribution nodes now.

-Glenn-

    Hi all,
    
    Now VMS V5.5-1 is in SSB and I've read the Release Notes and found that
    following statement:
    
            1.2 Batch and Print Queuing System
    
                  This section describes release information for the VMS
                  batch and print queuing system for VMS Version V5.5-1.
    
            1.2.1 ALL-IN-1 and Batch and Print Queuing System-Problems
                  Corrected
    
                  In VMS Version V5.5, there were interaction problems
                  between the new batch and print queuing system and the
                  ALL-IN-1 software that caused the OA$FORMATTER queue to
                  function improperly and occasionally caused the queue
                  manager process to abort.
    
                  This problem has been corrected.
    
            1-2
    
    My question to you now is, what's about the Support of ALL-IN-1 with
    this new Version of VMS ????
    
    Bill, could you please post here an offical statement from your sight,
    what we can say our customers.
    
    Thank you very much for all kind of inputs for this (never) ending
    story.
    
    Best regards,
    
    Karl Ehrlich / CSC Vienna, Austria
    

    Hi,
    
      It's been another month, and can anybody update the status for VMS
    and ALL-IN-1 (and Message Router!)?
    
      This customer is running ALL-IN-1 V2.4 (patched to K604), with
    Message Router S3.2, MRX S2.2-001, and MRS X1.2-002.  They are at VMS
    V5.4-1A, planning to go to VMS A5.5.  All the notes indicate this
    should work (but there's no mention of MR; good or bad).
    
    						Cheers, Dan'l

Go all the way to 5.5-1. Then apply the latest CSCPAT_1012 and CSCPAT_1011
and all should be well with VMS, ALL-IN-1 and MR.

mark

    What are the CSCPAT_1012 and CSCPAT_1011 kits? What do they fix?
    
    -Glenn-

    1011 is the lock manager fixes
    1012 is the que manager/job controller fixes
    
    Actually, if you go all the way to 5.5-1 you don't need 1011.
    You do need 1012 though, it has fixes that have been created since
    5.5-1.
    
    I'd post more details, but 2400 baud from a laptop isn't conducive to
    large text entry.

    Hello,
    
    The Stars article which describes 1012 specifies that CSCPAT_1012013  
    is the last version. Cann't find this one on RICARD. 
    
    We have:
    
      CSCPAT_1012011.A;4   25-JUL-1992 09:04:06.20
      CSCPAT_1012011.RELEASE_NOTES;5
      CSCPAT_1012012.A;2   26-JUL-1992 09:21:13.46
                            2-JUN-1992 02:30:52.15
      CSCPAT_1012012.RELEASE_NOTES;2
                           24-JUL-1992 05:40:52.91

    Is V1.3 somewhere on the net ? Or is 1.2 also fine for 5.5-1 ?
    
    Regards,
    Jan
    
< STARS V2.5-4/TIMA Maintenance - For help press HELP or PF2 >
CSCPAT_1012 Patch Information  [INTERNAL USE ONLY]                            
\                                                                             
\      Patch Identifier:     CSCPAT_1012013                                   
\                                                                             
\      DSNlink VTX Title:    Queue Manager Miscellaneous Fixes;               
\                            VMS V5.5 - V5.5-1 #1012 V1.3                     
\                                                                             
\      Source:               CSSE                                             
\                                                                             
\      Description:          JBC$JOB_CONTROL.EXE                              
\                                                                             
\      Version(s):           QUEUE MANAGER V5.5                               
\                                                                             

    Interesting. The master CSCPAT database does not contain a V1.3 of
    CSCPAT_1012. The current kit is V1.2.
    
    mark

Article seems to be corrected the 7 of aug.

< STARS V2.5-4/TIMA Maintenance - For help press HELP or PF2 >
CSCPAT_1012 Patch Information  [INTERNAL USE ONLY]                            
\                                                                             
\      Patch Identifier:     CSCPAT_1012012                                   
\                                                                             
\      DSNlink VTX Title:    Queue Manager Miscellaneous Fixes;               
\                            VMS V5.5 - V5.5-1 #1012 V1.2                     

   Ready   | Tech. Rev.  7-AUG-1992 | VMSBUG          |  H    | 596 lines |

                                                                                

    my customer is getting ready to upgrade to vms 5.5-1 in the next couple
    of weeks. they asked me about any "problems" that ALL-IN-1 2.4 and VMS
    5.5-1 might have.
    This is a 4 node cluster with ALL-IN-1 installed on 3 of the nodes.
    
    1. will the patch CSCPAT_1012 fix the que manager problems? customer
    WILL be using the NEW job controller when they upgrade.
    i've referred customer to the DNS article "Background formatter may
    hang on a VMS 5.5 system.
    
    2. the above DSN article mentions "lock manager" problems. what
    ramifications will this produce in ALL-IN-1?
    
    	thanks - ann
         

    Ann,
    
    CSCPAT_1012 is all you need.
    
    When your customer is going to upgrade, you CSC should
    be able to tell you which important VMS patches 
    are available at that moment.
    
    If not, let me know. 
    
    Regards,
    
    Jan

    Jan,
    
    Ann knows the number of her friendly local CSC but your answer
    is as always right. Of course everything is fixed in VMS v5.5-2 (:==:)
    
    Regards,
    
    Andrew.D.Wicks

    well, unfortunatly, the customer chose the "new que manager" and no
    patches.  from the extremely helpful people at the CSC, i'm told we're
    one of the few (if any others) who have VMS 5.5-1 and ALL-IN-1 2.4.
    
    the dsn article "background formatter may hang on a VMS 5.5 system"
    says that the formatter problems "should be" (i know) resolved in VMS
    5.5-1.  the patch in the article (CSCPAT_1012) is for VMS 5.5.
    
    in the mean time, users can print using the foreground formatter.
    
    ann 

    Ann,
    
    >well, unfortunatly, the customer chose the "new que manager" and no
    >patches.  
    
    Why ?
    
    >from the extremely helpful people at the CSC, i'm told we're
    >one of the few (if any others) who have VMS 5.5-1 and ALL-IN-1 2.4.
    
    This must be a joke.
    
    >the dsn article "background formatter may hang on a VMS 5.5 system"
    >says that the formatter problems "should be" (i know) resolved in VMS
    >5.5-1.  
    
    The article should be updated.... 
    
    >the patch in the article (CSCPAT_1012) is for VMS 5.5.
    
    CSCPAT_1012 version 1.2 is for VMS 5.5 and 5.5-1.
    
    If you want it, let me know.
    
    Regards,
    
    Jan

    re .88
    
    >>why ???
    
    	i'm not sure, but things mentioned were that the question was
    confusing on how to boot back up.  i wasn't there, i didn't see the
    question.
    
    
    >from the extremely helpful people at the CSC, i'm told we're
    >one of the few (if any others) who have VMS 5.5-1 and ALL-IN-1 2.4.
    
    >>This must be a joke.
    
    	at least we were th first the person i spoke with had heard about.
        
    
    thanks for the offer of the patch jan, i'll have to check with the
    customer.
    
    	ann
    	

    Ann,
    
    Unfortunately you have way too many (subtle hint there) calls logged
    under access number 20863 here at the CSC for me to even guess when or who
    you talked to but let me assure you that we have heard from many many 
    customers running VMS v5.5-1 and ALL-IN-1 v2.4, we even have some who
    are running some form of 5.5-2 (no don't ask me)
    
    The correct information you should have been given has been posted a
    number of times in this notesfile - mostly by Jan! and as he has said
    the Patch is available from your 'local' CSC and I think Atlanta is a
    little closer than Holland.
    
    regards,
    
    Andrew.D.Wicks