| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 37.1 | Requested Notify Changes. | KERNEL::ADAMS | Venus on Remote Control | Tue May 09 1989 11:09 | 25 |
|
I'll kick off with the requested changes to the Notify sections.
Pete is working on these points, which were decided on by joint
consultations between Systems/Devices/Exceptions, and a late input
from Comms.
1. Problem Summary: No Change
2. Engineer Reqd (y/n/?): No Change When: Change to eng skill level reqd.
3. Branch Action: Change to Impact statement and when eng is reqd.
4. Fail Device: No change Is Not: Change to Serial #
5. Freq/Time of Failure: Include "Repeat call" if appliccable.
6. Technical Findings: No Change
7. Most Probable cause: Use for - Most likely FRU.
8. Other possible causes: Use for - Any other FRU's, adjustments etc.
|
| 37.2 | But will you tell them? | KERNEL::EDMUNDS | | Wed May 10 1989 22:18 | 11 |
|
Brian.
That all looks fine.Hopefully,once a format can be agreed,this will
be conveyed to op-sec's/call screeners at all branches,then we shall
be able to make use of all that space under "technical findings"for
a reasonable "English" statement about what's going on!
This may even result in cutting down on engineers phoning in about
our updates,and op-sec's thinking we speak only in Ultrix....whch
s nt tru.
|
| 37.3 | This year, Next year, Sometime, Never ?? | KERNEL::ADAMS | Venus on Remote Control | Fri May 12 1989 08:59 | 15 |
|
Thanks Steve, I thought everyone had died, judging by the
under-whelming response so far.
The latest on the Notify front, seems to be that JJ is getting
bent out of shape by the branches, because they have had to
learn to read, to find the info in our updates. Ops Support say
they are looking into it, but someone else is actually doing it.
Seems like a load of council workmen round a hole in the ground,
"Yes Sir, we are looking into it !!"
Let's hope we get something resolved before Pete leaves us for
pastures new.
.- Brian.
|
| 37.4 | | KERNEL::WRIGHTON | Pass me a +L-14005 | Sat May 13 1989 00:54 | 6 |
|
Brian , I replied to your mail .
Dave W
( I agree with all the proposals )
|
| 37.5 | | KERNEL::MOUNTFORD | | Fri Jul 14 1989 12:03 | 33 |
|
SETTING HOST TO REMOTE SITES.
----------------------------
You may have had some mail a while ago about using the command
"SET HOST/LOG" when doing an RDC session on an inhouse system.
This command allowed us to set host and create an RDC log file
without going into a system via the RDC port .
The actual format was....
SET HOST/LOG=RSWS$LOG:RlognumCC.LOG
where Rlognum = log number
CC = cost centre
Unfortunately , using the file extension " .LOG " stops you
doing a REV/EDT or REV of the session because the RSDS package
expects the logfiles to have a " .DAT " extension .
So , the fix ...... use the following command
SET HOST/LOG=RSWS$LOG:RlognumCC.DAT
where Rlognum still = log number
CC still = CC
regards Dave Wrighton
|
| 37.6 | | KERNEL::MOUNTFORD | | Fri Jul 14 1989 12:03 | 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.
|
| 37.7 | | KERNEL::MOUNTFORD | | Fri Jul 14 1989 12:04 | 11 |
|
For those of you that use RDC$COMMON:RDCLOGIN.COM,
Patches is now defined there, so you will not need to add it to
your own Login.Com.
Cheers
Brian
|
| 37.8 | CANASTA | KERNEL::MOUNTFORD | | Wed Jul 19 1989 12:28 | 22 |
| From: KERNEL::JAMES "ALAN JAMES @UVO, 7833-3443 17-Jul-1989 1235" 17-JUL-1989 12:37:40.18
To: @POST:SYSTEMS,MARSH,DICKSON
CC:
Subj: CANASTA Available to All
Hello All,
CANASTA is now available to ALL. This Crash Analysis
assistant should be useful in helping with Bugchecks.
Please can you make an effort to use it and give feedback
on it's performance. The AIAG group in the States will be pleased to
tailor it to suit our (and other CSCs) requirements.
Unfortunately we cannot make use of the CANASTA Crash
Database at the moment as we are not running the necessary version of
Stars at Basingstoke.
The program can be invoked by 'CANASTA' at the $ prompt.
Cheers,
Alan.
|