| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 149.1 | AES Flashmail | KERNEL::ADAMS | Brian Adams CSC-Viables '833-3790 | Fri Apr 10 1992 11:54 | 63 |
|
I N T E R O F F I C E M E M O R A N D U M
Date: 09-Apr-1992 09:14am BST
From: Mary Challenor
CHALLENORM
Dept: Change Management
Tel No: 7843 6164
Please find below details about Flashmail, how it is created and how
individual Service Delivery Units, PTG and Product Service Centres for
hardware, software can contribute to its generation.
AES - FLASHMAIL/CIB
---------------------
AES contains a feature by which we can send a mail to all AES
Customers. This mail is called a "Flash Mail" as far as Customers are
concerned. Internally we call it a CIB (Critical Information Bulletin).
We currently send these out every two weeks.
The idea is that if a Customer reads all his flash mails then, over a
period of time, he will come to a situation where if he suffers a system
or layered product problem and calls a CSC, he will not be told that "it
is a known problem and we have a fix for it". He should have been
notified about "all known critical problems" in the flash mails.
It is therefore important that the CIB Flash-Mails are complete and
cover all products. This is so that Customers can depend on them and do
not really have to go searching through STARS for other than minor
problems and programming examples.
Suitable candidates for CIB Flash-Mail articles are issues discovered
which could cause the Customer to experience unexpected down time
(system or application crashes, security issues), reduced system manager
productivity (typically installation problems, product
incompatibilities), or anything which could cause the customer loss of
data. For examples of suitable articles see the most recent articles in
the STARS CIB database.
Articles are submitted by mailing them to KERNEL::CIB. They are packaged
into a bulletin every two weeks (or sooner if circumstances dictate).
The bulletin then goes through a five day review (product mangement,
legal, technical review ...) during which time it is in the STARS CIB
database as a non-Customer readable article. After the review period,
the issue is modified as per review feedback and then published.
Publication consists of making the article customer readable in STARS,
making it a DECtel "Flash" article and mailing it to all (400+) AES
Customers.
What is proposed that the individual service delivery units, PTG and
Product Service Centres for hardware, Software Service Centres (with
PTG) for software are responsible for ensuring that all suitable issues
are submitted as CIBs. The measurements on this might be that no
Customer (with AES or DECtel) calls us and we tell him about a critical
known problem (that is more than two weeks old). That no Customer asks
us why a particular item has not been flashed (that has happened
already). Thirdly, that the CIB editor does not discover any suitable
issues that have not been submitted by a Service Centre or PTG.
|
| 149.2 | No NAME or PHONE | KERNEL::MCGAUGHRIN | What a Marvelous Delivery | Wed May 20 1992 20:25 | 95 |
|
This note explains how to fix a customer request that does not
include a name and phone number on the NICE log number, it is
YOUR responsibility to fix the customers system for him. The
answer is in section 3, the rest is for information.
SDD 1.6 and AES SIGNATURE FILES
-------------------------------
There have been a number of queries in the past few weeks regarding the
SDD$PROFILE for SDD 1.6 and the AES signature files. Below you will find
an explanation that should help to clear up any confusion. There is also
a problem with SDD and these signature files which is also explained and
the fix is included at the bottom.
1. SDD$PROFILE
The SDD$PROFILE is required on the customers system to be set to NONE,
it was designed to be used in the US to provide contact information
for their call handling system (not NICE). But is still needed for the
pre-processing on the customers system and the post processing in our CSCs.
To gain a better understanding of this you might want to examine the
command procedure SDD$EXE:FMGR$BUILD_SISR.COM;1. The post processing
at the CSC looks at the finished file from this command procedure once
it has been transferred, and then re-orders the three sections, so the
DSN$MAIL_SIGNATURE is at the top of the description, if the Phone and
Name are there it then puts these into the front screen of the request.
If however the SDD$PROFILE is missing (or any other portion) then this
re-ordering does not take place correctly at the CSC. Post processing
expects the signauture file to end up at the top of the description in
the NICE request, in some cases you may have defined the DSN$MAIL_SIGNATURE
correctly, but it is at the bottom of the description and therefore it will
not place the name and phone number in the front of the NICE request. It
is for this reason that the SDD$PROFILE is required.
2. DSN$MAIL_SIGNATURE
The signature files are set up like this, using the logical defined in
DSN$STARTUP.COM called DSN$MAIL_SIGNATURE. But are also defined in the
startup file for DSN MAIL which if used then overrides any other system
wide logical for dsn$mail_signature.
$ ds DSN$MAIL_SIGNATURE SYS$LOGIN:DSN$MAIL_SIGNATURE.TXT
During AES installation a signature file is created that is put in
3 places.....
SYS$MANAGER
SYS$MAINTENANCE
SYS$SYSTEM
This means that the users SYSTEM and FIELD get their own signature files.
Users who log calls using DSN MAIL have no signature file, so the system
wide information is used from SYS$SYSTEM. Even if users do not modify the
information, DSN MAIL creates a user signature file in their SYS$LOGIN
directory.
3. PROBLEM WITH SDD AND DSN$MAIL_SIGNATURE
The SYS$LOGIN directory for VAXsimPLUS is SDD$MANAGER, defined by the
logical SDD$MGR. The AES startup, NOT the SDD startup, will copy the
system signature file from SYS$SYSTEM to SDD$MANAGER, hence SDD should
find its signature file in SDD$MGR.
However, there is a problem at the moment with SDD logging requests for
unsupported devices. If the device is unsupported (e.g. sysbugchk) then
only the CLIENT software is used and the detached process does not login
to SDD$MANAGER and therefore SYS$LOGIN is not defined and it does not see
the logical for the signature file. This needs to be fixed by you.
Check the following :
definition of DSN$MAIL_SIGNATURE
existence of SYS$SYSTEM:DSN$MAIL_SIGNATURE.TXT
existence of SDD$MGR:DSN$MAIL_SIGNATURE.TXT
The easiest way to do this (thanks to Graham Baxter) is to redefine the
logical name so it has two places to look for the signature file.
- Edit SYS$STARTUP:DSN$MAIL_STARTUP.COM
$ ds DSN$MAIL_SIGNATURE SYS$LOGIN:DSN$MAIL_SIGNATURE.TXT, -
SYS$SYSTEM:DSN$MAIL_SIGNATURE.TXT
- restart DSN MAIL
Regards
Ian McGaughrin
|
| 149.3 | some useful DSN bits | KERNEL::SCOTT | you can trust a teddy bear | Sat Jun 13 1992 23:55 | 32 |
|
1/ The DCN Nodename. If not known, the following command will help:-
$ SHO LOG DSN$NETWORK_PROCESS
"DSN$NETWORK_PROCESS" = "NMSUVO::DSN" (LNM$SYSTEM_TABLE)
In this instance, the DCN is NMSUVO
2/ Give you an account and password on the DCN. Also, get an account,
password and nodename of all systems affected by the symptoms.
3/ Authorize remote logins over AES to the target system (XXXXXX::) by
issuing the following command *ON THE DCN*:-
$ DSN AUTHORIZE/UNTIL=TOMORROW REMOTE_LOGIN/NODE=XXXXXX
4/ Connect to the system with whichever of the following commands you
normally use. Remember to make sure that the system to be connected
to is registered on the NICE system you are working from (Search
DSN$REGISTRATION for the serial number to be sure).
*EITHER*
$ DSN HOST DECEISUVO00-INDEC XXXXXX (....where XXXXXX is the
nodename entered in step 3)
If this fails, examine the NETSERVER.LOG file relating to your
request, for more information. (This file resides at
DISK$APD3:[DSN$DNET_P] on the South NICE system and
DISK$NICE_3:[DSN$DNET_P] on the North NICE system).
"%DSN-E-NOTAUTHNOW, this application is not currently authorised"
means that Step 3 above was not successful.
*OR*
$ VTE/NICE=<Log number>
|
| 149.4 | DSN connect via Warrington without set host.... | KERNEL::TRAVELL | John T, UK_Remote_Services_Support | Mon Jun 22 1992 06:08 | 27 |
| $ Vfy_Ctx = 'f$veri()' ! DSN_NORTH.COM Connect Warrington without set host
$!
$ if f$mode() .nes. "INTERACTIVE" then exit
$!
$ esc[0,8] = 27
$ ws = "write sys$output"
$ rsvp = "read sys$command /prompt=" ! later use:- $ rsvp "prompt" symbol
$ err_status = %X00000001
$!
$ set control_y
$ on control_y then goto end
$ on error then goto end
$!
$ if p1.eqs."" then rsvp "Please supply NICE log number :- " p1
$ callid=p1 - "." - "-" - "-"
$ ws " Logical name DSN$REMOTE_LOGIN_NODE being set to connect via North CSC."
$!
$ def/job/nolog DSN$REMOTE_LOGIN_NODE "war002::""0=dsn$decnet"""
$ def/super/nolog sys$input 'f$trnl("sys$command")
$ vterm/nice='callid
$ deass/job DSN$REMOTE_LOGIN_NODE
$!
$ ws " Logical name DSN$REMOTE_LOGIN_NODE reset to connect from South CSC."
$!
$end:
$ if err_status .ne. %X00000001 then ws f$mess('err_status)
$ exit ($Status + (0 * f$veri(Vfy_Ctx)))
|
| 149.5 | More helpful stuff | KERNEL::ADAMS | Brian Adams CSC-Viables '833-3790 | Mon Jul 13 1992 21:20 | 80 |
|
If you have a problem connecting to the customer system, using
DSNLink (either DSN HOST or with VTERM set to DSNLINK), then
here are some checks you can make.
1. Check DSN$REGISTRATION for the customer details.
2. Get the customer to type $ DSN SHOW NET/CONT on the "DCN"
If it really is the DCN, the display will be something like;
Control mailbox, logical/name: DSN$CTL_1 / MBA1583:
VMS process name: DSN$001-LTA1001
DECnet object name: DSN$1
Communications device: _MARVEL$LTA1001:
Current links, local/remote: 0 / 0
Dial attempts/failures: 0 / 0
Last dial time: None
Last hangup time: 6-MAY-1992 13:40:38.09
Last connect time: 6-MAY-1992 13:34:26.47
If it is not the DCN, then the display will be like;
Control mailbox, logical/name: DSN$CTL_1 /
Error communicating with process:
%DSN-E-NOTPRESENT, DSNlink network software is not present or is not running.
REMEMBER, THE DSN AUTH/UNTIL=hh:mm/NODE= xxxx REMOTE_LOGIN
must be entered on the DCN. (/NODE= specifies the network node
on which you are going to login. It may be the DCN or any other
node in the customer network. THE /NODE= xxx MUST BE SPECIFIED
even if you are logging in to the DCN.)
NOTE:- The customer CAN NOT use SYSMAN to enter DSN commands.
The command should returm a message indicating the authorised time
slot has been accepted by DSN. If it doesn't, then the customer has
done something wrong. Check command,DCN, /Node= etc.
3. Having checked the DCN and the Authorise, you may still fail
to get a proper connection. If so then check this on your session
here;
$ TYPE DISK$APD3:[DSN$DNET_P]Netserver.Log
If you are on the NORTH system, you'll need to use ;
$ TYPE DISK$NICE_3:[DSN$DNET_P]Netserver.log
Check for the following;
DSNlink for VMS V1.1-1/BL12
Copyright (c) 1989, 1991 by Digital Equipment Corporation
Confidential and Proprietary Diagnostic Software
Property of Digital Equipment Corporation
All Rights Reserved
Connected at 6-MAY-1992 10:50:52.85
Processing connect request for access number: CLUK0200000-CLUST
Disconnected at 6-MAY-1992 11:51:31.86
Received 1 messages (48 bytes) from DECnet
Sent 0 messages (0 bytes) via DECnet
Received 0 messages (0 bytes) from DSNlink
Sent 0 messages (0 bytes) via DSNlink
%DSN-E-NOTAUTHNOW, this application is not currently authorised
DSN$DNET_P Job terminated at ........
If this happens, then get the customer to log a dummy call on
the DCN, with a problem statement of "Please route to ......."
His/her command will be;
$ DSN Mail etc
Check this call, when you get it, to ensure that the NODE is the
same as you have on the first line of RA DATA from VTERM.
(It is easy to get N/M or B/P or F/S mixed up.)
Having checked all this, you should be able to make a good
connection. If it still fails, find out if it has ever worked, etc
as per ATS/PSDM procedures.
|
| 149.6 | Even more help. | KERNEL::ADAMS | Brian Adams CSC-Viables '833-3790 | Fri Aug 28 1992 01:43 | 34 |
|
If you are not sure of the customers registration detail,
for ESR/SICL/AES calls, check the M (Mail Address) Description.
eg.
*** Service Request Interface, Reserved information ***
0GA127H0960-6560 ! Registration
ESR ! Call Type (Electronic Service Requset)
LOGGED VIA WARRINGTON. ! Northern System
OR
*** Service Request Interface, Reserved information ***
CLUK0002200-CLUST ! Registration
SICL ! Call Type (System Initiated)
LOGGED VIA BASINGSTOKE. ! Southern System
OR (New Style Registration)
*** Service Request Interface, Reserved information ***
11UK0000300-AESDN ! Registration
SICL ! Call Type
LOGGED VIA WARRINGTON. ! Northern System
So, now when VTE/Nice=abcde.00-xxx-yyyy doesn't give you the
connection information, you know what to search for in
DSN$REGISTRATION and whether it is on the South or North.
Easy peasy .... eh !!
Brian.
|