| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 68.1 | Offline crash dump analysis | KERNEL::PETTET | Norm Pettet CSC Basingstoke | Fri Aug 11 1989 18:00 | 27 |
| Gents,
Should you be asked to analyse a crash dump supplied on tape please
follow these guidelines:-
1) Ring Geoff Judd (system manager confirm OK)
2) set default to DISK$DUMPS:[CSG_SYSTEMS]
3) Copy dump from tape to DISK$DUMPS: using BUNTY's tape
it is known as $2$MUA0 and is labeled on TU81 transport as such.
example of typical commands:-
$ backup/list/rewind $2$mua0:*/save ;gets saveset name off tape
$ backup/log/rewind $2$mua0:crash.bck/save disk$dumps:[csg_systems]*
4) Dismount and remove the tape from $2$MUA0:
5) Analyse crash as per normal, please don't forget to delete crash
dump and/or errorlog after analysis.
Cheers...Norm
|
| 68.2 | CTSC info | KERNEL::PETTET | Norm Pettet CSC Basingstoke | Fri Aug 11 1989 18:03 | 5 |
| Should you log a software TSC call as a result of a RSDS call please
include your name at the end of the trouble statement so that the
software engineer can contact you direct.
Cheers..Norm
|
| 68.3 | PATCH notesfile | KERNEL::PETTET | Norm Pettet CSC Basingstoke | Fri Aug 11 1989 18:09 | 38 |
| The whole issue of how we issue patches to customers from this building is
currently being reviewed .
As part of the process a 'PATCHES' notes file has been set up. This is a
members only conference and was set up initially to be used as a method
for 'tracking' who had been sent patches. However , it is also a useful location
for holding patch information.
The only patches that are referenced in this notes file are 'official' VMS
related patches at present.
There are various steps being taken to improve the process of patch distribution
For the time being you can carry on with the 'current' process that you have
in place. However ,any queries that you might have can be directed at either
myself or Steve Wibrew.
More news will be available as the process improves. For the time being all
RDC Engineers should have been set up as members of this notesfile ..
COMICS::VMS_PATCHES ..
Please read the introductory notes which details format, patch location etc..
However the location of the patches will be changing !
The STARS database will also be updated with an entry for each of these patches.
Regards,
Rob.
|
| 68.4 | RSDS procedure | KERNEL::PETTET | Norm Pettet CSC Basingstoke | Fri Aug 11 1989 18:10 | 63 |
|
RDC PROCEDURES FOR LOADING VMS PATCHES
When analysing VMS crash dumps, if it is determined that the crash
is due to a known problem and is fixed by a patch or a new image, then
it is now possible for RDC to supply the patch instead of logging a
software call.
A new notes file has been setup containing a list of the problems
that we have fixes for:-
Note file = COMICS::VMS_PATCHES
If the fix is listed in the notes file then we can supply it
over the RD link. If the problem is a "known problem" thats not
listed in the above notes file then log a Software Call.
* Advise the branch that it is a software problem and the RDC
will supply the fix.
* Get the customers agreement before down line loading the patch
* The patches will usually consist of a backup saveset of the new
image or patch and a .README text file. They should be available
on comics in SYS$PUBLIC or SYS$VMS_PATCHES
* Copy the files from Comics to your Kernel directory
* Using RFT downlinw load them to the RHM account
* Write a REPLY to the notes file indicating that the patch has
been sent to the system. This is most important, we need to
identify to who the patches have been sent.
* Advise the customer that the files are in the RHM directory
and that it is up to the customer to install them.
* Delete the patch files from your directory as required.
The use of RDC to supply both the Problem Diagnosis and Problem
Solution is a most important step into the 1990's. It should only
add about 20 minutes to the call duration but will save a significant
amount of time in re-logging the call with SSDU/ TSC and the time it
takes the TSC to handle the call, make up the kit onto magtape and
send it to the customer. It will have a significant befefit to the
customer too, they get the fix NOW and not next week, they will also
save time on installing the patch as it has alredady been loaded into
their system disk.
Give it a go, you may like it. Give us a shout
if you get problems.
Regards,
Steve W.
|
| 68.5 | | KERNEL::SCOTT | trying to be inoffensive | Fri Aug 11 1989 18:16 | 19 |
| Here's the one you deleted Norm...
Here is a much more convenient location for the patches.
They are now in a sub directory of RDC$common and here is the line to add to
your login.com file.
$define patches rsds$disk:[basingstoke.patches]
Now at the RFT "from" prompt simply type "patches:filename.ext <CR>"
The patches will be updated by Rob Haskings in the normal manner.
Hope this makes life just a little easier.
Regards,
Ken.
|
| 68.6 | Rules is rules.... | KERNEL::SOWTON | Diagnosis does it down the phone.. | Fri Aug 11 1989 18:23 | 14 |
|
RE: 68.1
Sorry Norm...I tried for hours to get this customer supplied
dump on a TK50 on to MUA1, but no matter what I tried, it wouldn't
fit.
Eventually I sussed it out....it goes on MUB6 !!!!!
and then guess what ...there wasn't any room on the DUMPS disk !!
Hope I haven't broken anything...
Bob
|
| 68.7 | Dump Tape Lables. | KERNEL::ADAMS | Venus on Remote Control | Fri Nov 10 1989 08:26 | 21 |
|
With assistance from John Johnson, the branches have been
asked to lable dump tapes as follows, when sending them in
for analysis. Where requested, tapes will be returned to the
DEC engineer submitting them.
*************************************************************
Customer Name..............Contact.............Phone............
Tape Label..............Tape-Format..eg 6250/1600/TK50/TK70.....
Saveset Name..........................File Size..........Blocks.
Command line used...............................................
VMS Version..........System Type & Serial #.....................
Date/Time of Crash.................Engineer Name................
Any Associated Log #.............. Branch/CC....................
|
| 68.8 | VMS 5, versions/patches-info. | KERNEL::ADAMS | Venus on Remote Control | Fri Nov 10 1989 08:30 | 122 |
|
Article detailing patch revision for Memory Management Routines
---------------------------------------------------------------
There are many patches for VMS v5 that affect memory management routines. In
addition to this many of the VMS upgrades modify the routines. This article
may help to explain.....
VMS upgrades
------------
VMS 5.0 New images
VMS 5.0-1 IO_ROUTINES.EXE (NEW image)
PAGE_MANAGEMENT.EXE (NEW image)
PROCESS_MANAGEMENT.EXE (NEW image)
VMS 5.0-2 IO_ROUTINES.EXE (PATCH image) ECO 2
PAGE_MANAGEMENT.EXE (PATCH image) ECO 2
PROCESS_MANAGEMENT.EXE (PATCH image) ECO 2
WORKING_SET_MANAGEMENT (PATCH image) ECO 1
VMS 5.1 IO_ROUTINES.EXE (PATCH image) ECO 3,4
PAGE_MANAGEMENT.EXE (NEW image)
VMS 5.1-1 IO_ROUTINES.EXE (PATCH image) ECO 5
PATCHES to memory management -
----------------------------
IO$$PATCH01_500 provides NEW image for IO_ROUTINES.EXE
IO$$PATCH02_500 provides PATCH image for IO_ROUTINES.EXE , ECO 7
This patch originally set ECO 5 in error which
conflicted with both VMS 5.1-1 upgrade and also
with original VMSMMG$PATCH02_500 patch.
VMSMMG$PATCH01_500 provides PATCH image for PAGE_MANAGEMENT.EXE , ECO 4
VMSMMG$PATCH02_500 provides PATCH image for IO_ROUTINES.EXE , ECO 6
" " " " PAGE_MANAGEMENT.EXE , ECO 5
This patch originally set ECO 5 for P_M and
ECO 5 for IO_R . This was in error as the ECOs
conflicted with 5.1-1 upgrade and original
IO$$PATCH01_500 patch.
VMSMMG$PATCH03_500 provides PATCH image for PAGE_MANAGEMENT.EXE , ECO 6
" " " " WORKING_SET_MANAGEMENT ECO 2
VMSMMG$PATCH04_500 provides PATCH image for PROCESS_MANAGEMENT.EXE ECO 3
What happens when I do my upgrades if I have patches ?
-------------------------------------------------------
IO$$PATCH01_500
If a system has the patch IO$$PATCH01_500 and an upgrade from VMS 5.0 to 5.0-1
is performed then the IO_ROUTINES.EXE supplied with the patch must be reapplied.
This is because VMS 5.0-1 upgrade provides a NEW IO_ROUTINES.EXE. Any other
upgrade that modifies IO_ROUTINES.EXE does so by applying a patch to the
exisitng image; thus no further action is required.
IO$$PATCH02_500
If a system has the patch IO$$PATCH01_500 and an upgrade from VMS 5.0 to 5.0-1
is performed then the IO_ROUTINES.EXE supplied with the patch must be reapplied.
This is because VMS 5.0-1 upgrade provides a NEW IO_ROUTINES.EXE. Any other
upgrade that modifies IO_ROUTINES.EXE does so by applying a patch to the
exisitng image; thus no further action is required.
VMSMMG$PATCH01_500
If a system has the patch VMSMMG$PATCH01_500 and an upgrade from VMS 5.0 to
5.0-1 is performed then the PAGE_MANAGEMENT.EXE supplied with the patch must
be reapplied. This is because VMS 5.0-1 upgrade provides a NEW routine for
PAGE_MANAGEMENT.EXE. This also applies if upgrading to VMS 5.1 as this upgrade
also provides a new PAGE_MANAGEMENT.EXE. Any other upgrade that modifies
PAGE_MANAGEMENT.EXE does so by applying a patch to the exisitng image; thus no
further action is required.
VMSMMG$PATCH02_500
If a system has the patch VMSMMG$PATCH02_500 and an upgrade from VMS 5.0 to
5.0-1 is performed then the IO_ROUTINES.EXE and PAGE_MANAGEMENT.EXE supplied
with the patch must be reapplied.This is because VMS 5.0-1 upgrade provides a
NEW IO_ROUTINES.EXE and PAGE_MANAGEMENT.EXE. This also applies if upgrading to
VMS 5.1 as this upgrade also provides a new PAGE_MANAGEMENT.EXE. Any other
upgrade that modifies PAGE_MANAGEMENT.EXE and IO_ROUTINES.EXE does so by
applying a patch to the existing image; thus no further action is required.
VMSMMG$PATCH03_500
If a system has the patch VMSMMG$PATCH03_500 and an upgrade from VMS 5.0 to
5.0-1 is performed then the PAGE_MANAGEMENT.EXE supplied with the patch must
be reapplied.This is because VMS 5.0-1 upgrade provides a NEW routine for
PAGE_MANAGEMENT.EXE. This also applies if upgrading to VMS 5.1 as this upgrade
also provides a new PAGE_MANAGEMENT.EXE. Any other upgrade that modifies
PAGE_MANAGEMENT.EXE and WORKING_SET_MANAGEMENT.EXE does so by applying a patch
to the existing image; thus no further action is required.
VMSMMG$PATCH04_500
If a system has the patch VMSMMG$PATCH04_500 and an upgrade from VMS 5.0 to
5.0-1 is performed then the PROCESS_MANAGEMENT.EXE supplied with the patch must
be reapplied.This is because VMS 5.0-1 upgrade provides a NEW routine for
PROCESS_MANAGEMENT.EXE. Any other upgrade that modifies PROCESS_MANAGEMENT.EXE
does so by applying a patch to the existing image; thus no further action is
required.
|
| 68.9 | SDA Lable help. | KERNEL::ADAMS | Venus on Remote Control | Fri Nov 10 1989 08:47 | 16 |
|
From: COMICS::GLEDHILL "02-Nov-1989 0838" 2-NOV-1989 08:46:29.40
Subj: SDA SYMBOLS.
I have patched SDA.exe so that it gives larger symbol displacements when doing a
show stack etc. Remember all that tedious ltdriver1 = ltdriver + 1000,
ltdriver2 = ltdriver + 2000 etc. I will put the files in disk$public in the
v51_sda and v52_sda subdirectories. The patches are probably a bit dodgy so I
would only use them on a dump_file not on a running system (just in case they
crash it!.
2cd1a in v5.1, 2e135 in 5.2 - both longwords.
DG
|
| 68.10 | | KERNEL::MOUNTFORD | | Thu Mar 01 1990 10:35 | 7 |
| Perhaps we could re-vamp this topic with input from Dave Gledhill
on the latest info he has? Paul is with us this week in Systems,
should we set up a regular swap between groups, to provide job
experience?
Richard
|
| 68.11 | The "Known Bug" scenario - An idea !! | KERNEL::ADAMS | Venus on Remote Control | Tue Feb 05 1991 10:10 | 52 |
|
To help to solve the "Why didn't you tell us there was a
patch available" situation,I have spoken to Clive Brooker,Frank
Briggs and Chris Spooner.Having made enquiries regarding DECtel,
a change in the way we inform the customer, can take a lot of the
heat out of most situations.
I.E.
1. Remote Diagnosis reveals "Known Problem" .
2. Do NOT mention "Known Bug/Patch" yet, to the customer.
******************************************************
3. Ask customer CAREFULLY if they are aware of/use DECtel.
(Most customers calling for service should be entitled.)
4. If answer is "No" or "What's that", BRIEFLY tell them what
it is. (Anyone who doesn't know, come and see me.)
5. GENTLY tell the customer that they might have pre-empted
the problem, by checking in DECtel.
6. If the customer needs passwords/phone numbers etc for access,
refer customer to Tom Scuffham/Kevin Gant in CCD or to
Tina Linehan in Response as appropriate. This currently
applies only from 07:00 to 24:00. ROUTER has information on
modem numbers etc.
7. If they DO use DECtel, and haven't been able to find the
information, please mail brief details to CIB @UVO
(Julie Wakefield) who will attempt to get the information
onto DECtel within two weeks.
8. If you sense any hostility or problems in this area, from
the customer, (e.g. They say they don't have the time or
resources,) contact the Duty manager at the customer's
service office, asking for the A/R and COM to handle it.
This way, they should be able to approach the customer,
before he/she complains to DIGITAL.
9. Now advise the customer, as appropriate, that :-
a. There is a patch and you can downline load it.
OR
b. A patch is available from TSC and you will log the call
for them.
|