Conference koolit::vms_curriculum

A copy of the "methodology" chapter is available for review in 
SUPER::ES$REVIEW:[VMS_TROUBLESHOOTING]METHODOLOGY.PS.

This chapter is a VERY rough draft, with lots of [text] place-
holders in it.  Please feel free to make suggestions about what 
to put into those gaps, and (of course) please comment on the
existing information.

Sample cases will use the methodology described in this chapter, 
so the chapter needs to be in good shape before work begins in 
July on the cases.  (See my request for sample cases in note 143.4.)  

Thanks for your help!

	Kristin

    Chapter 1  Overview of Dependable System
    
    Posted for review in:

	SUPER::$1$DUA6:[ES$REVIEW.VMS_TROUBLESHOOTING]


    This posting contains the lecture material only.  
    A lab on the System Dump Analyzer is planned. (See Note 143)
    
    All comments posted by 14-Oct-1992 will receive full consideration.
    Comments posted after that date will be considered if possible, but
    may not be included in the materials to be piloted on Nov. 16.
    
    If you have any suggestions regarding the laboratory exercise please
    send them in.
    
    

    Chapter 2  System Initialization Problems
    
    Posted for review in:
    
    	SUPER::$1$DUA6:[ES$REVIEW.VMS_TROUBLESHOOTING]VMS_TS_2_BOOT.PS
    
    
    This is the lecture material only.  See note 144.2 for a list of
    contents.  I anticipate at least 8 hours of laboratory work for this
    chapter.  Instructors will have to break this up into two sessions.
    
    This note is posted in #144 because the rest of these notes will not
    allow replies.  I will try to get that changed and move this note to
    the proper place.
    
    Regards,
    
    Emmalee

Time for my review...I'd love to hear from some others!  (Ignore my 'tough'
  comments, they aren't meant personally, just a technical critique.  Image
  smiley faces all the time.)
  
Module 1....Providing a Dependable System.

  Overall some useful info.  Tends to be too wordy on the student's pages.
  It makes a great TBI format, but doesn't allow the instructor to 'flesh 
  out the course'.  This is a major issue for me since I depend on the
  student material as a GUIDE, not a reading assignment for the students!

  Numerous small typos, I'll mention those on the student pages although
  you'll probably find them anyway.

1-3  -- we need clearly defined NON-GOALS somewhere!  Such as "this course will
        NOT teach you how to analyze a crash dump", (take Crash Dump Analysis).

        Under the resources, a book called "Building Dependable Systems: The 
        VMS Approach".  Where do we order it?  Should we have a reference
        copy for the class?  What is the part number?

1-4  -- SIGH!  I *REALLY* much prefer the terms in the BACK of the module!
        We just had an OBJECTIVE page, now a TERMS page followed by an OVERVIEW
        page!  What am I supposed to do with thes pages?  Explain the terms and
        their definitions BEFORE I teach them the chapter and it's concepts?
        It's like a mini-lecture before the lecture!  Please move the terms to
        the back of the chapter or the back of the entire book!  Overviews
        and objectives are quite adequate for "telling them what you are
        going to tell them before you tell them."!

1-6  -- Typo, first line: reliableservices.

1-7  -- Only the 2nd and 4th bullets expanded, please expand the other two.

1-8  -- Format...why have bullets with bullets...makes it difficult to
        reference.  Bring back the dashes.

        4th bullets (or 2nd major bullet)...WHAT tools?  No references anywhere
        in this chapter.  Are we talking about things like VAXsim, SPM, etc? or
        something else?

1-10 -- Weird looking flowchart.  Haven't seen many that go down AND shift
        right at the same time.  It's pretty, but doesn't add anything 
        substantial to the course that the list on page 1-9 doesn't except
        some confusion...

        How do we get from box #3 which has us analyzing and interpreting and
        classifying (head things) and then the next step is "did we fix it?" 
        Yeow! Reminds me of the "Think System" that Professor Harold Hill used 
        in the Music Man..."no need to practice or do anything boys, just 
        THINK the Minuet in G!  Dahhh De Dah De Dah De Dah De Dahhh..."

1-11 -- WHAT TO DO section, All this really belongs under step #2.  In this
        step we aren't trying to gather information or analyze data, just make
        sure we have a good problem statement.  Only two things really need to
        get done here:  Determine if this is a valid problem with a valid
        problem statement.  Things like, "I think the computer is broken
        because everyone has gone to lunch.", might not be be a valid SYSTEM
        problems statement.  Second, we MUST know at the FIRST step, what is
        attempting to be done?!  When in the Telephone Support Center I always
        asked my customers, "What are you TRYING to do."  Keeps you from 
        going down the wrong path.

1-12 -- This is a good place to mention that keeping a log book (spiral, 
        loose-leaf, clipboard, whatever is useful) at BOTH your desk and on
        top of the computers in the computer room helps.  These are the two 
        places the system manager usually solves problems.  If the list is
        only in one location then many good items will never get entered
        because it is inconvenient, so it will be forgotten.  Having two books
        is a problem of its own, but not as bad as not having only 1/2 your 
        data written down!

1-13 -- bullet 6 should also reference VAX(VMS)clusters.

1-13a - The correct order of the questions on 1-13 will come with time and
        experience.  Depending on your background, the activity in the shop
        (or office), the skill of your users, etc. will dictate the order
        for your troublehsooting.

1-14 -- item #2, add an additional line or two...
        "Stay Focused!  Try to solve one problem (or a related set of problems)
        at a time, don't go jumping around trying to solve any and all problems
        at once.  Keep other problems in your mind in case they are similar to
        the one you are solving, but stay focused!" 

1-15 -- last sentence -- belongs on the instructor's page, I might draw a
        different conclusion like throw the 3-hole paper away and give people
        a hole punch.  Besides, although it is true, putting in print that the
        end users is dumb is no to my taste.

1-16 -- TIME OUT!  Where is the testing phase?!  Here is the same problem I
        mentioned earlier!  The bulleted list on 1-16 indicates that I either
        KNOW the solution or I'm going to pass off the problem to someone 
        else.  This flow diagram is damaged -- it doesn't represent the real-
        world system manager who spends hours in trial-and-error analysis
        on the systems.  This section should be titled "Attempting to solve
        the problem".

        Also, this section requires a 4th item...Begin documentation at this
        point, don't wait until the end.  Yes, we will add more detailed info
        later, but taking notes during the trial time keep small details from
        getting lost.

1-17 -- 1st bullet.  Aren't we already assuming that we ARE the system  manager?
        If our target is the in-house system manager or the customer system
        manager, then this is true.  If we are addressing Customer Services
        people then it is a valid statement.

1-18 -- WHAT TO DO... needs more, such as restoring critical files from 
        backup, putting the system back in the state BEFORE the problems if
        necessary, etc.

1-18a - What "apparatus"?  There has been NO mention of APPARATUS up to this
        time, not even a mention that we need to install special managing
        and monitoring tools on the system.

1-19 -- 1st bullet. seems like we are working with ourself again!

1-20 -- the first bullet should be the PROBLEM STATEMENT and the 2nd bullet 
        a brief description of what the person what TRYING to do, and why.

1-21 -- Add ENVIRONMENTAL CHANGE to the numbered list to match page 1-7.
  
  More later......
  
  $

Module 1....Providing a Dependable System (continued)

1-22   4th and 5th bullets are leading statements, as a reader of this I
       would expect that to be a discussion topic.  We need a statement 
       here or on the instructor's page emphasizing our role in regards
       to System Dumps.

       last bullet, change "for" to "in".  We aren't creating or extending
       the file at dump time.  Or it could be worded as:  "There is adequate 
       space for a system crash dump to be written" 

1-24   Bullet makes overwrites text on the line.

1-25   Third bullet is a leading statement.  Student's completing SysNet III
       do not know what a System Page Table is or what it does, this is not
       properly covered (in the books) in the current curriculum until VMS 
       Internals I.  Move the second sentence of this bullet over to the 
       instructor's page

       4th bullet, wouldn't hurt to mention that this ONLY works in the page
       file on the SYSTEM disk in SYS$SYSTEM, thus not commonly useful for
       satellites or most heavy performance-loaded systems since the pagefile
       is probably not on the system disk.

1-26a  Several references to DUMPFILE.SYS -- needs to be SYSDUMP.DMP.

       2nd bullet, "For example a Digital Representative."  DEC folks usually
       require priv'ed accounts to do their work, so this isn't a good example.
       Better might be a senior Applications programmer or someone else.

1-26   1st bullet is a repeat of the 2nd bullet on page 25, kill one of them.
 
1-27a, The file name is opCcrash.exe, it has 2 'C's.  SYS$SHUTDOWN.COM doesn't
       exist on my 5.5 system. I think you mean SYS$SYSTEM:SHUTDOWN.COM, which,
       by the way, calls OPCCRASH as its way of shutting down!

1-27   1st and 2nd bullets...only useful to print if someone is going to read
       it.  Most engineers I've spoken with prefer to edit it on-line.

       Example:  What are we picking LPA0:sysdump.lis?  Shouldn't we specify a
       file that can be queued since we are assuming a specific device and we
       are also assuming that it is spooled and we are assuming the printer
       works correctly and doesn't eat the listing.  Put it to disk and print
       it later...if needed.

1-28   This formula is for V5.1 and older.  The new formula (as of V5.2) should
       be: SIZE=Total_VMS_pages + (ERRORLOGBUFFERS * ERLBUFFERPAGES) + 1

       Also, this page should mention that this formula is for the FULL dump,
       not the abbreviated dump mentioned a few pages further.

1-29   2nd bullet, if you set SAVEDUMP, then you MUST run SDA at startup or 
       the pages will NOT be released from the pagefile!

       3rd bullet, 1000 is 'old' info, as of V5.2 is needs to be:
         1001 + (ERRORLOGBUFFERS * ERLBUFFERPAGES) or greater.

1-30   Gads!  Don't show something like this and then say "do not go into
       any detail..."!  If you want to show something from SDA, then make it
       something vaguely useful like  SDA> SHOW SUMMARY /IMAGE.

       Drop the SHOW POOL stuff entirely!

1-31a  last line, is the DEQNA no longer tracked and reported by ERRLOG or
       is it that V5.5 doesn't care to play with it?  The way it is written
       leads me to believe that Error Logging no longer reports DEQNA info.

1-31   5th line from bottom, "Use can use the the ..." -- a few typos there.

1-32   5th bullets, the dashes -- First, you probably will run a command 
       procedure, not a program.  Next, is there anything special about
       naming it ERRLOG.OLD, why not ERRLOG.30-SEP-92, as I prefer.  Third,
       shouldn't we be backing up the OLD error long file?  The 2nd dash
       implies the real one.  Fourth, I only delete the OLD error log files
       as space becomes an issue.  If I have been having HW problems I might
       keep many versions on-line for Field Service to look over.
       
1-33a  How about a reminder on this page that the ERROR LOG UTILITY is covered
       (currently) in SysNet III, that our displays here will be minimal.  Is
       this true for the rewrite?...Is Error stuff still handled in SN III?!

1-37   Hmmmm, I'm running V5.5-2 and I DON'T have ERRORS in my help files.  It
       is on my V5.5-1 system, so I'm not sure what's going on here!

Overall just a brief overview of the standard tools, but we didn't mention 
many other useful ones line NCP, SYSGEN, etc. for finding problems.

$

Starting my comments on the Queue/Printer module...

1-3   Probably need to add a DECserver manual on the resource list.

1-4   2nd sentence: missing words? "The device setting OF(?) the printer..."

      3rd sentence, put "and network manager" in parenthesis, since the
      use of LAT printers and even a 2nd person is optional.

      If we cover print forms and device control libraries, does this mean
      that those topics will be removed from the SysNet3 course??

1-6   Either we need to drop the reference of IPC Links here or give a hint on 
      the instructor's page as to what this is.  I'd say drop the words but 
      leave the diagram.

      Also, they way I read the diagram it implies that the user and/or 
      application and/or batch job can communicate directly with the Queue 
      Manager via the IPC links.  Is this true?

1-7   Is there a relationship between the middle section and the last section
      of this page?  This page doesn't seem to lecture smoothly.  If you don't
      read the words, but you try to summarize the page, what is it trying
      to say?

1-8   2nd bullet, "The system manager MAY select the..." since it selects the
      system for the queue manager on it's own if left alone.

1-9a  It's been spelled QUEUEING, QUEUING and QUEUUING on a few different pages.
      The proper one is 'queuing'.

      "...on all VMS systems.", not VAX systems since ULTRIX runs on a VAX

1-9   1st bullet, IcpACP should be IpcACP.

      1st line of display is wrapped to new line.

1-10  Since you are being so careful to spell out items correctly, you might
      need to add an "R" on QUEUE_MANAGE.

      Last 2 numbered items.  Did V5.5 change?  Size oriented is the default
      under previous versions, submission time was the option.  This is 
      reversed for batch, since there is no size-sorting on batch.

1-11a What does the last sentence mean "...sharing of the master file is not
      a hindrance..."?  What sharing??

1-11  1st line is terrible.  Tell us WHY it isn't volatile...because it is
      stored in a file on disk, etc.

1-12  5th bullet, what does it mean?  why is this considered 'dynamic cluster
      information'?

      Example at bottom:  what is this "DIAGNOSTIC 0 1 2" supposed to do?
      is it documented? there should be an explanation on either this page
      or on 12a explaining it's purpose.  This section is really vague and 
      needs much more info to explain the diagnostics and why I need to
      preserve the obsolete files.  (Maybe it's explained later in the book,
      I haven't finished the chapter, but it needs SOME explanation here!)

      CMKRNL is misspelled (also on 12a) in example commands.

1-13  I assume this is a "knowledge nugget", how about a comment on 13a to
      explain our goal of this page?

1-14a Also, other good disks include disks with idle files or users, very
      small disks, even consider an ESE type disk.

1-14  4th bullet should precede 3rd bullet.  5th bullet has nothing to do
      with "Alternate Location for the Queue Database", but rather the backup
      and moving process covered adequately on the next page.  Drop this line.

      add one more bullet suggesting lightly-used or idle disk is more 
      important than fast.

1-15a 2nd paragraph makes an assumption that the system disk is backed-up
      while the system is shut down.  This is NOT necessarily true, although
      it is preferable.

      3rd paragraph, spelling: instructioS

      5th paragraph, how will saving a copy of the queue database preserve
      our forms and characteristics...leading statement.  Need a bit more text.

      last 2 sentences on this page really don't make any sense.  What is a 
      "change management system"?  Have we taught this to them?  How does A1
      really relate to this?

1-15  1st #3, example define command should be "...DEVICE:[directory-name]", not
      just directory name.

      2nd #3, again 'directory-name' needs device prefix.  Also, if I recall
      correctly JBCSYSQUE logical can still be used, it just won't use the
      file-name part of the logical, only the dev:[dir] part.
 
      last line...why not?  do they get recreated??  put something on this page
      to qualify the warning.

1-16a spelling...reCorganizations.

      Also, why are we really interested in RFA's and secondary keys?  Neither
      of these topics have been discussed in previous SysNet courses or the
      performance course.

More later....

$ 

  Hey, maybe I missed this somewhere, but is this a 3-day course?  So far
  there isn't a lot of lecture material, at least not enough for a good
  5-day course.
  
  What about a 4-day course?  Or are we expecting the labs to take a lot
  more time than the average system manager class??
  
  $

The SYSTEM INITIALIZATION PROBLEMS module isn't bad, but leaves a great many
ideas uncovered.  I'll suggest them as I think about them or find a good page
to put them on.  My copy's page numbers are for chapter 1, but I think this
is actually chapter 2.

Here are a few nits, some spelling errors, reorganizations, comments, etc....

1-3    1st line makes an assumption that we "often" shutdown, might want to
       rephrase this as there are MANY non-stop-shops that still have these
       problems during their few 'maintenance' hours.

       last bullet, GASP!  Are we going to refer them to a document that many
       of us can't even read 2 pages with success?  This resource might
       belong on the instructor's page!

1-4    shouldn't there be commas... "System initialization, or booting, ..."

       Need a better lead-in for page 1-5. This page is VERY thin and doesn't 
       'set up' the next page very well.

1-5a   This page needs objectives.  What is the purpose of discussing these
       steps?  This info is a little 'dull', do we have an objective or a
       goal?  

       Also, a reference would be good--where did you get the stuff on page
       1-5, and where can I get more detailed info if I need it?

1-5    Are we not getting a bit deeper than we need?  I haven't seen anywhere 
       in this course so far that would require much more than the major 
       bullet list.

       Multiple references to standalone, why the emphasis here?  Isn't all
       of this page really "standalone"?

       Also, you need to decide how to spell stand-alone, or was it stand alone
       or standalone?
 
       item 4, 2nd bullet, EH?  What "initialization routines"?  We'll get
       questioned on this so have some examples on the instructor's page!

1-7a   Are we making an assumption that the HARDWARE OPERATIONS GUIDE (HOG) is
       going to be provided??  It is a useful reference, but we don't need it
       as a hand-out (at least I don't think so).

       "Students should review this material before coming to class", HA!!!
       We'll probably need to include a little review, specifically of the
       R0-R5 registers, how to set up a command file for standalone backup
       booting, etc.

1-7a   If you reference an page in the IDSM, then also specify which edition of
       this book is being referenced.

1-7    I've looked at the diagram, but I'm not really sure what I'm going to
       say here.

1-8a   Comments on this page to the effect of "The exact order of these steps 
       may vary greatly from this template."

1-8    A little disorganized...

       1st bullet, isn't much/all of this handled automatically with V5.5?

       There is no reference as to where layered products startup files
       should be referenced!

1-9a   Major nit -- The Colorado Springs CSC is *not* the only CSC that
       supports the VMS operating system.  There are 3 CSCs, operating 
       together, sharing support for support of many items, including
       VMS.  Please drop the Colorado reference or expand the list to
       get all 3 (Massachusetts, Georgia and Colorado) mentioned.

1-9    2nd line and 4th line "...the system manager MAY NEED to use..."

1-10   This page needs a better intro.  The minor topic line is "When to use"
       and this isn't how the bullets/dashes  are worded, they are worded more 
       like the page sub-title was "What to use it for".

       Last bullet assumes that the HOG will be available.  I'd suggest we
       reference the manuals that ship with the VAX systems -- those that
       the HOG is built upon.

  More later...the next several pages seem rather scrambled, I'll need to
  spend some time reorganizing this for a smoother tech.

$

    I am expecting the laboratory work to take up 3/4 of the class time.
    
    I really don't see how you can teach troubleshooting any other way. You
    just have to get in there and do it.
    
    With a new course it is hard to be sure how much time things are going
    to take, but I am more worried that there will be too much material.
    
    All the laboratory exercises will be in chapter 5.

The pages between 12 and 15 seem a bit out of order and 18 needs a LOT more
meat.  So...the review:

1-9    Backup seems out of place.  I'd encourage we find another home.  Maybe
       back near 1-19 where we talk about backup as a way to recover.

1-12   Notice that we play with "SET/STARTUP" on 1-12 before we tell
       them them what it is and how to see the default on page 1-13?
       The bottom of 1-13 should be before 1-12.

       The example for fixing a forgotten password is overly complicated.
       The simpler way is:

       >>> B/1
       SYSBOOT> SET UAFALTERNATE 1
       SYSBOOT> CONTINUE

       This merely defines the logical SYSUAF to point to SYSUAFALT.DAT
       which is an alternate UAF file.  If the file exists then you have 
       to know the account and password that was set up in this file.  If
       it *DOESN'T* exist, LOGINOUT allows you to type in ANY username with
       any passwords (double password prompt) from the system console and it 
       will log you in with full privs!  You now type $ DEASSIGN/SYS/EXEC 
       SYSUAF and proceed as if nothing had changed!  You would of course fix 
       the password in the real UAF file now.

       2 minor notes...if your SYSTARTUP_V5.COM (or SYLOGICALS.COM) has
       a definition for SYSUAF logical then it would override the SYSGEN
       setting.  Also, if you were using a workstation you can't use
       double passwords to log in.  So, add the following while at SYSBOOT:

       SYSBOOT> SET STARTUP_P1 "MIN" !avoids the logical override
       SYSBOOT> SET WINDOW_SYSTEM 0  !allows double password, it doesn't let
                                     ! DECwindows start, terminal is LA120-ish

1-13   I don't know of many situations where people have an alternate
       startup file.  The system does use this for upgrades and cluster
       builds.  The order for this topic should be:

          What is SET/STARTUP
          Show setting to another file (mention cluster builds and upgrades)
          Set it to OPA0:

       This should also probably follow the UAFALTERNATE item above.

1-14   This should follow 1-11, since it is probably the most common item
       the SYSBOOT is used for -- changing a single parameter and rebooting.
       The MIN feature is used most commonly in upgrades and when the 
       SYSTARTUP_V5 file has been "mangled".  Next would come UAFALTERNATE.

1-15   5th bullet, I have problems with the phrases such as "Digital
       recommends" being placed on the student's pages.  I happen to
       disagree with the bullet.  My Guide to VMS System Management and 
       Daily Operations tells how to build Stand-Alone backup on a disk 
       *OTHER* than the system disk.  I suggest that it be built on which 
       ever disk makes the most sense to the system manager.

       6th bullet (the one that is missing) should talk about the use of
       STABACKIT and it's benefit vs tape-based stand-alone.  I know some
       of the STABACKIT info has been covered in the previous SN2 & 3
       classes, but a few bullets of review is necessary since this is
       the course that really puts this to the test.

       The second half of the page makes a few assumptions...

       "The following example boots standalone BACKUP on a MicroVAX 3100
        from a disk."  Should probably be something like "If Stand-Alone
        backup has been built on the system disk (drive 0) on a MicroVAX
        3100, the following would be an example shutdown and boot process."
        -- or something like that.

        #3 assumes the we built Stand-Alone Backup in root E, when in fact 
        the *default* is for it to be built in Root 0.  It only goes into
        root E if the disk that we are installing it on has root 0 occupied,
        such as the average system disk.

        #4 should probably mention that an identification message, AVAILABLE
        DEVICES, and then a "$" prompt is displayed.

1-16    This information should have been covered in the other courses, but
        this is a good review.  An important point to make (here or on 1-16a)
        is that a system disk should NOT be backed-up with the following
        type of command...

        $ backup dua0:[*...]*.*;* mua0:syssav.bck/sav /etc....

        As this walks through the SYSCOMMON directories multiple time and 
        will not provide us a usable backup for restoring the entire disk.
        The /image qualifier is the important topic.

        #2, example, typo: ".../LABEl=label"  mixed case problem.

        1st bullet, typo: "input-specifieR"

1-17    2nd sentence, "...TOOLS previously discussed in this chapter...", uh,
        what *tools*?  What have we previously discussed that are tools?  Are
        we referring to Backup?  That's the only tool I remember!  Maybe you
        mean the processes or methods taught in module 1?

1-18    This page makes an assumption in step one, that we need to isolate the
        hardware 1st.  We really need to get a good problem statement or a
        description 1st!  Has this system EVER booted?  Where in the boot 
        process does the system reach?  What is printed on the console when
        a boot is attempted, etc.  After gather basic info we can apply a
        test formula...

        Ask the following 4 questions:

        1) When the VAX is powered on, does ANYTHING appear on the console?
         if yes...
        2) Does the CCL prompt (i.e. ">>>") appear on the console?
         if yes...
        3) Does the VMS banner appear on the console?
         if yes...
        4) Does the VMS "site-specific" message appear on the console?
         if yes...it's probably in SYSTARTUP_V5.COM...fix it!

        If the answer to 1 is no, then the 1st step on page 1-18 is now a
        valid questions.  If after testing these items we have no clue, then
        it is a Service issue, contact your Hardware Support organization.


        If the answer to 1 is yes, we have eliminated the stupid questions of
        "is it plugged in", "is the terminal turned on", etc.  We can now
        proceed to question 2, did you see ">>>"?  If so, attempt to boot
        and try to determine where in the boot steps on pages 1-5 and 1-6 
        the system may have stopped.  If the answer is no, we didn't get
        the ">>>" prompt but we DID get the hardware initialization displays, 
        try checking the boot switches (LOCAL, REMOTE, ENABLE, DISABLE, etc.), 
        pressing ^P or HALT or F5.  If none of these get the ">>>" prompt
        then it is probably time for a service call.  
  
  
        The next real test is question number 3 above, did we make it to the
        VMS banner?  If YES, we have located a good system disk, the boot 
        files (i.e. DEFBOO.CMD, etc.) are readable and (probably) correct.
        We also eliminate major VMS files being corrupted and this makes a
        conversational boot a valid possibility for fixing the remaining 
        problem.  If we have problems making it beyond this point then steps 
        2 through 7 on page 1-18 might be valid steps.

        IF we have NOT reached the initial VMS banner then we need to explore
        the issues of a) can we boot a DIFFERENT disk or b) can we boot STAND-
        ALONE backup from tape?  The real question is, can ANYTHING be booted
        on this VAX?  If not, we probably have a HW problem.  The next step is
        checking to see if F.S. can even boot diagnostics.


        Assuming we see the VMS banner, and if the system manager has NOT 
        removed the following line from their SYSTARTUP_V5.COM:

       $ WRITE SYS$OUTPUT -
       "The VAX/VMS system is now executing the site-specific startup commands."
      
        then we should see the "site-specific" startup file message.  Now 
        the 4th statement above can help us determine if VMS has reached 
        the site-specific file, in which if there is an error we now have
        an excellent chance of finding and/or fixing the problem.  Using a
        minimum boot here can keep the SYSTARUP_V5 from running, the system 
        manager can now either rename SYSTARUP_V5.COM so the system can boot
        normally, they can place a $EXIT as the first line, etc.  Then after
        a regular reboot (minimum boot keeps various devices from being seen,
        best to reboot it NON-minimal) each line of SYSTARTUP_V5 can be 
        executed one-at-a-time to find the culprit.

        If the system prints the VMS banner, but DOESN'T print the SYSTARTUP_V5
        banner, then the problems are more difficult.  I usually start checking
        for VAXcluster errors at this time, such as Quorum.

        Now, given this info, I think page 1-18 could be expanded into several 
        pages, giving us a 'menu' or 'outline' approach to solving the problems
        of a 'non-booting' system.  (WHEW! Hope this makes sense!)

1-19    Sentence preceeding 3rd bullet, "...system file you MAY need to ..."

        5th bullet, is a leading statement, add something like "...that has 
        been changed BY RETRIEVING IT FROM THE BACKUP TAPE JUST MADE."

        6th bullet, drop the reference to "Have Customer Service" and make it
        read something like "Have the system disk connected to a different
        running system."  I read the comment on 1-19a, but it doesn't fit with
        today's systems.  the quick-release SCSI disks, the removable RA60s,
        the RF disks in separate cabinets, the 3rd party removable disks, etc.
        negate the need for Customer Services to be involved in many cases.
        Today many of the workstation disks are customer installable.  Numerous
        customer take Hardware Training from us -- it is an old-timer's comment,
        drop it.

        8th bullet, ditto.

        7th bullet, "...missing files AND REPLACING THEM AS APPROPRIATE."

1-20a   So we do this stuff AFTER breaking from lecture and doing a lab?!  
        Or we teach this with chapter 1?   Seems out of place.

        "CSC in Colorado" -- assuming again.  Remember there are 3 CSCs each
        with VMS and VAX support.
        
1-20    change management strategy should either be upper cased, capped or
        in italics -- Change Management Strategy -- it is a 'named' 
        process or philosophy, right?

1-21    This page needs a good intro...WHY do we need this?  What will this 
        provide?  This is how to AVOID a problem possible occurring in the
        first place.  interesting idea, just needs a better intro and maybe
        a better place...like in chapter 1?

        The middle paragraph is assuming the issue is related to disks.  We
        need to prefix this with the comments that this is the most likely
        area for problems or we need to de-emphasize the DISK comments.

        "standard change procedure", "standard procedure to control change",
        "the change procedure", etc.  All of these 'imply' a formal procedure,
        thus we need either a consistent name for this process or we need to
        us words like "a standard procedure for making changes","a procedure
        for making changes to the system" or "Change Management Procedure"
        (in caps).

Lots of stuff here.  There is some good info, but the organization is missing
and there is not much text (depth?) to some of it.  Hope this helps!

$

...continuing with the Printer module...

  Much of this book is a review of what I just taught my students in Sysnet
  2 or 3!!  Although the review is good, can we move the review portions 
  out to optional appendices?  If my students are good enough, 95% of that
  material is not needed.  With an appendix I can pick the pages I need
  easily, referring to them as necessary.


1-17   3rd sentence, this is some thing I SAY, not something I READ.  Please
       move it to the instructor's page.
     
       4th sentence, does "produce" need to be plural?

       LATSYM is the LAT symbiont, not LATSMB.  Also wrong on 1-17a.
       Also need to mention that CPS$SMB is the symbiont used by the
       Postscript printers on the LAT, as they will not work with LATSYM.

1-18a  I have no information on this, I'll need to research it.

1-18   bulleted list, if this is not intended to be exhaustive we need to 
       say 'some' or 'a sample of'...

1-19   last sentence, "Queues DO not..."

       Beginning on this page you waffle numerous times throughout the material
       as how to say 'rebooted'.  Initialized, although probably more accurate,
       is not as common as rebooted.  As since we are assuming these systems
       HAVE been built previously, REBOOTED is the phrase I think is the best.
       See also: 1-22, 1-34...

1-20a  Does a print queue have a priority?  The symbiont might, but I didn't
       think the print queue did.  Something new?

1-21a  What does EAST, WEST, NORTH and SOUTH have to do with the example on the
       bottom?  How does '/characteristic=1' relate to a direction?  Not clear!

       (also, '...assigns a characteristicS...' doesn't need the 's'.

1-21   This page is 1) review, 2) not referenced any further and 3) not really
       pertinent to 'troublehsooting'.  Please drop it or move it to an 
       appendix.

1-22   3rd bullet, what does "Area" mean here?  Vague.

       other bullets don't mention page length?  Is this supposed to be an
       exhaustive list?

1-23   2nd sentence only listed SET as the verb that is used to MODIFY the
       queue.  Other verbs were not specified.  Why?

       last sentence, "...the job does not print.", more accurately the
       job is queued, but holding.

1-24   Notice that the DEFAULT form is missing?  I'd suggest you put it in,
       as it is the most common of the forms seen on systems.

1-25   2nd sentence on this page and the 2nd sentence on page 1-26 are 
       identical...drop one.

1-26a  "...one piece plain piece..."

1-26   As a side note...Europe uses A4 paper, which I believe is 1 inch longer 
       and 1/2 inch narrower.

       examples, drop the the "DEFINE/FORM MEMO 3..." examples.  It isn't
       referenced.

       also, on example I suggest a left margin of 3, since 80+6 is wider
       that 8&1/2 inch paper.  This causes a fair number of complaints.

1-27   I think that 1-26 should FOLLOW page 1-27.

1-28a  last paragraph, so what command would the end user use to print a
       document using the LANDSCAPE module?  It isn't clear.

1-28   1st line, "user-written" can also be "application-provided", i.e.
       WPS-Plus, ALL-IN-1, etc.

       2nd sentence, specify SYS$LIBRARY or SYS$SHARE as the directory for
       SYSDEVCTL.TLB.  Also, note that this file does NOT exist and MUST be
       created by the system manager.

       This page also needs to mention EXTRACT, INSERT and REPLACE qualifiers
       for updating these text libraries.

1-29a  Most common is to reset the printer after a job has completed.

1-29   bullets 3-5, order of RESET then SETUP then PAGE is in decrementing
       popularity.  May want to make a comment that PAGE_SETUP is rarely used.


1-30   I think that the "Specifying a Reset Module for a Queue" should be first
       on this page.

1-31   Need an example of setting ownership and protection for a print queue.

1-32   last two items on the table don't read well, need to reword to make sure
       that they understand that the holder of these priv's access the queue
       via the system part of the protection mask, i.e. (S:E).

       It's important that they realize that these priv's give a slightly 
       access than the standard file protection.

1-33   2nd sentence, "The system Manager...", does SPOOLING actually do this?
       I thought access via the copy command was restricted via the device
       protection.  Spooling only forces the output to a 'buffer' area.

1-34a  "This is review" -- there sure is an awful lot of review in this course!


1-34   /nobroadcast -- this only prevents the broadcast messages from VMS,
       not from the LAT or other, so when used on the LAT printers we also need
       to set the port (from the LOCAL> prompt) to nobroadcast.  this tip
       probably needs to be on the instructor's page.

       
1-35a  3rd paragarph from bottom ("Certain application...") is WORD-FOR-WORD 
       from the student's page.  Delete it.

       2nd paragraph from bottom -- is good!  Needs to be on the student's 
       page.
 
       "Digital recommends..." drop it, also copied from the student page.
      
1-35   3rd bullet, please drop the "Digital recommends that you...", just
       start the sentence with the "Also...".  Almost everything we mention 
       this week is "Digital recommends".  An appropriate note on the 
       instructor's page to emphasize this point is all that is needed. 

1-36a  When deciding on the spool device, I suggest a disk that won't need to
       be dismounted, such as the system disk or the page/swap disk.  They
       might be too active so consider other non-dismounting disks.

1-37   Syntax of the SET DEVICE/SPOOLED commands is wrong.  Missing parenthesis
       and the extra DEVICE-NAME: item.

       Last two lines...How will I know if the testing is successful?

1-38a  More review (Sigh!)

More later...

$

...still continuing with the Printer module...

1-39   3rd sentence from bottom, "...application processing service."  What
       is this?  Something special, or just another service name?

1-40   Introducing Ultrix systems here doesn't help with the course, only 
       causes a digression.  Can you replace it with a 2nd VMS system, this
       would be better for discussions.

1-41   last sentence, actually the session is created BEFORE you log in, it 
       is at the time the server connects you to the service, usually offering
       you a login-banner of some form.

1-42a  What is the "TM" doing behind Digital on this page?  Can we PLEASE get
       all the trademark stuff isolated and put on the cover pages with all
       the other trademarks?!  thx!!

1-42   "A terminal server is a computer with:", add ETHERNET PORT and asynch
       terminal lines (ports) to the other items.

       last sentence, "The server does not GENERALLY interpret data entered
       by the user."  It catches break keys, and what ever you might have 
       defined as FORWARDS and BACKWARDS keys.

       Most of this page should either precede 1-39 or be merged with 1-39 &
       1-41 -- much is redundant.

1-43   Any reason the 300 and 700 are lumped with the DECserver 90TL?  And
       why not the 100/200 series?

       Also, please define Low-End, High-End and Fixed-End Servers -- I've
       never heard of 'fixed-end'.

1-44   5th bullet should end with "...or the port is logged out." since port
       data that is SET is lost when logged out.

       Although mentioned later, we might need a mention of the 'SAVE' 
       database here.

       2nd bullet, drop "...in local mode".  Although this is correct for
       the DECserver 100/200 and the like, this is not true for the 500 
       series.  On these the DEFINE command can only be performed from
       TSC (or TSM).

1-45a  What is RPQ??

       Last sentence seems out of place.  It is referring to the student page?

1-45   Middle of page, "If the pattern is not DISPLAYED OR IS NOT consistent..."
 
       We also probably need to upgrade the examples to DECserver 300s...trying
       to stay relatively current.

1-46   Drop the reference to ULTRIX -- adds nothing worthy of note to the 
       student's page.  RSX, RSTS and other operating systems use LATs, so just
       put the additional reference on the instructor's page.

1-47   The LATCP DCL Command Line Interface info should follow the material at 
       the bottom of 1-46, before the specific examples on top of 47.

1-48   This is a sales pitch.  We haven't even discussed TSC (which comes with
       the DECserver 500 software) and we're talking about a layered product.
       Please move to an appendix, the instructor's page or just drop it.

1-49a  need a 3rd bullet, "Is it a terminal server setting?"


More later...

$

(Whew, this chapter is taking its time...)

1-50   1st line, "Obtain a test sheet...", how?  Maybe some tips on the
       instructor's page?  Not all printers give status via a status sheet.

       Show Port display:

         Since we are looking at port #2, which is a REMOTE ACCESS port,
         the command given could not have been typed.  It should probably 
         be -- Local> SHOW PORT 2 CHAR
                                ^
         We need a SHOW PORT 2 *before* it was set up as a printer port
         and then this one to follow.

1-51a  RE: new guide.  I would suggest a sample of DECserver manuals might
       be packaged with the instructor's kit.

       3rd paragraph, "DECserver 500..." should have been mentioned back on
       page 1-44.

       4th paragraph,"TSC", *MUST* be discussed in this material.  This is
       the standard tool to DEFINE DECserver 500 characteristics.  Although
       the 100, 200, 300's are simple because they allow DEFINES at the LOCAL
       prompt, doesn't mean we should skip explaining the TSC utility!

1-51   2nd bullet, if this is the true 'rule' (which is what I subscribe to)
       then your example throughout this module using ZKO1123 breaks this
       rule.  Also, I usually suggest that the server name is the same name
       that you specified in the DECnet database when registering the server
       in DSVCONFIG.

       2 examples on this page using ZKO1123 should be changed to something
       that describes the server.  I usually suggest to my students to name
       the server (and the DECnet name) with either the LAT or DS prefix.
       For example the DECserver 500 might be DS5ENG for the server that I
       place near Engineering.  Or maybe LATATL for the LAT in ATLanta.

       Also, server name should be DEFINEd, as not all servers allow you to 
       SET several attribute, including the Server name.

       You may also want to mention that the server must share at least one
       'group' number for these systems to even talk to each other.

1-52   Try 'make' rather than 'determine'.

       Definition of SET|DEFINE is wrong.  It means that the SYNTAX for this
       command is similar for either the SET or the DEFINE command.  Not all
       commands that can be DEFINEd can be SET.

       Last paragraph is wrong.  DEFINE puts it in the PERMANENT database for
       any server type (DEFINE is typed at the LOCAL> prompt on the low-end
       servers and is typed from the TSC prompt for the high-end servers).

       Last line, wrong.  The SAVE PORT puts the information into the 'SAVE'
       database.  This is a SEMI-permanent database on the 500 series.  It is
       only for PORTS and it can survive ports logging out.  HOWEVER, if the
       server is rebooted, the 'SAVE' settings are gone.  The most useful
       feature of the SAVE PORT command is in setting up printer port info
       that you want to work ONLY as long as the 500 is booted.  We use this 
       feature a lot with guest instructors in Atlanta.  We set up temporary
       printer ports in various classrooms and SAVE the port info.  At the
       end of the week we reboot the server and all the SAVE info is gone.

1-52   1st step.  The name of PORT_2 is a bad example.  This happens to be the
       *default* name for port number 2 on a decserver 100-200-300 series.  If
       you are going to demonstrate changing the name (which I suggest you do)
       then name it something descriptive, such as CLS1PR (an abbreviation for
       the classroom #1 printer).

       #3, all examples on this page show "port 2" as the example, but this 
       has 'n'.

       #4, not all terminal servers have INPUT FLOW and OUTPUT FLOW on the 
       list of available characteristics, such as the DECserver 500.  On these
       you usually remove ALL characteristics.

1-53a  Hmmmm, comments are thin and cryptic. 

1-53   Change port number to CLS1PT (anything but PORT_2!)

       "preferred service" was never mentioned on any of the previous pages.
       we either need info or let's drop it.

       After the high-end server has successfully set up a printer and used
       the SAVE command and the printer queue is verified as functional, then
       we go over to TSC (or TSM) and DEFINE these attributes if we need a
       permanently changed port.

       last example says it is for port 2, but example shows 'n'.  Don't 
       we need to define the port name and the server name here as well? 
       Also, please define/describe the syntax used for these servers, as
       I have never used one.

1-54   1st sentence -- initialized needs a "(booted)"

       2nd sentence, not sure what you are trying to say, but I can access
       any LAT printer from *any* system on the LAN.  Restricting the printer
       to only one cluster is not true.

       LATCP> examples near end of page -- I didn't know we had to CREATE
       *and* SET the port to be a /application port!  I only use it on one 
       of my commands in my LTLOAD routine and all works fine (for years).


More later...

$
  

And the last few pages from the Print module...

1-55a  Another reference to ZKO1123, make CLS4PT or something similar.

1-55   Ditto.  Also the reference to PORT_2.  These both occurred several
       times.

       1st bullet, this can be done only after the baud rate is set at
       the DECserver LOCAL> prompt (or via defined commands).  This might
       be an instructor tip.

       What are we try to tell the people about the 'count'?  Is there
       something magic about 10 or 70?  Are these the defaults?  Wouldn't
       this info fit better on page 1-45?

       Last bullet should read "In VMS, on the node that HAS CREATED THE
       LTAxxx PORT:"  Saying "is to access the printer" can lead you to
       believe that another node in the cluster might now access this
       printer port.

       Also, you *must* have a colon on the LTA####:, other wise the copy
       command will make a file called LTA#### in the current directory.

1-56   This list is really no different that what I'd use for a local
       printer "terminal queue" that I might have hooked up on the terminal
       lines on my printer.

       The parenthesis on bullets 4 and 5 have been true for most (all?) of 
       V4.x and all of V5.x, nothing special about V5.5 here.

1-57a  2nd sentence regarding the SET TERMINAL sounds suspicious!  I can
       use SET TERM on a terminal and it WON'T set the page length to 1,
       regardless of whether I use /PAGE or not.  The LTA devices get their
       default characteristics from the TTY_DEFCHARx params.  I'd suspect
       that the page length will default to 24, but I've never tried it.
       May we should try this one in the lab!

       3rd sentence, try "...otherwise various system broadcast messages will
       be displayed."

       last bullet, remember that all 'other' symbionts aren't strictly
       user written, some might be supplied by the applications.

1-57   2nd bullet, "Specifies various default settings for the terminal line"

       5th bullet, only stops *VMS* messages from being printed, not the
       messages generated by the DECserver itself.

       Also, the output won't necessarily be in the "middle" of the page.
       (Just a small nit.)

1-58a  bullets 1-5, these should probably be on the student page!

       examples in front of last paragraph, what are we trying to say here?

1-58   1st bullet, remember that POSTSCRIPT printers are now popular on the
       LANS.  /PROCESSOR=CPS$SMB is the symbiont for the LN03R, this requires
       extra software.

1-59a  Still reference bad server and port name!

       Large paragraph, "...says: ''Hey all you server...", it only tells or
       asks for this info when working with terminals servers in the same
       'groups'.

1-59   58 pages...now we finally get to the real troubleshooting,

1-61   Add Ethernet as a bullet

1-62a  Item 1, we need to be consistent with "LTA#" or "LTA###", etc.

       Item 5, WHY?

       Item 8, don't forget the appropriate START/QUEUE commands!  SET DEVICE
       by itself is not enough.

1-63   Example doesn't show the "/ALL" qualifier that the top of the page
       suggests.

       I think this should be the FIRST step done, this page should follow
       page 60.

1-64a  How did this info result from page 1-64??  Good stuff, just seems out
       of place.  Stress the importance of putting a VTxxx in the place of the
       printer for testing.

1-64   1st bullet.  Please explain this.  Check also the fuse.

       2nd bullet.  This is *PERFECT*, we should tell them to call 'Service'
       and avoid specifying the specific organizations (since many use self-
       maintenance).

1-65   3rd bullet, NOPE.  Jobs sent in with /AFTER are HOLDING, not PENDING.

1-67   This info is out of place, it belongs back near the previous discussions
       on print forms.

1-68   WIDTH=60 needs a '/'.

1-69   Last bullet.  WHY?  I disagree.  Actually, I don't think I understand
       why we need line feeds instead of form feed.  Please explain?!

1-70   Title of page should be "OUTPUT" not "FILE" format problems.  It has
       really nothing to do with the format of the "FILE".

       Need more meat here.  Specifically ideas like modifying forms, changing
       other printer characteristics, etc.

1-71   HAARGH!  This ends too soon.  How about recovering from a corrupt
       queue file, common FIXES for pending queues.  What does a stalled
       queue mean.  Etc.  There is a lot more on troubleshooting that 
       can be covered (and maybe a little less on basic queue management).

1-73   We didn't (best I can tell) actually use the words "Interprocess
       Communication Facility" anywhere I could find.  Stuff on 1-8 was 
       close, but not exact.

Whew, what a chapter!

$

Generally it looks like the VAXcluster (Hmmmm, didn't it get renamed to 
VMScluster yet?) module is a little short on errors-and-solutions.  Some
material is a little redundant of the Booting module, and too much 'old'
stuff was lifted from the old VAXcluster course (i.e. no mention of FDDI
clusters).


Reviewing...

1-5a   1st sentence has me concerned..."This material is all review
       from the OpenVMS System and Network Management".  If this is the
       case, then let's rewrite it!  The students complain when they see
       the same stuff multiple times in more than one (different) course!

1-5    Different driver for FDDI?  I thought I remembered a different
       driver name for DSSI on the 6000/7000/9000/10000 systems (bullet 3).

1-6    2nd bullet, please define 'higher VMS software'.  Vague.

1-8    nice list at bottom, but how about some definitions, some possible 
       problems and/or solutions.  We have a good opportunity with this page,
       let's use it!

1-9    1st and 2nd bullets are for NI and CI, what about DSSI?  FDDI?

       A note for this page or the instructor's page, this stuff isn't 
       displayed via OPCOM, only the console terminal is the broadcast 
       location.

1-10   What does the parenthesis on the 2nd bullet mean?  Vague.


1-11   2nd bullet, let's either get a current HSC message or move this
       one to the instructor's page.  Maybe something as current as an
       HSC-65?  I'd settle for an HSC-40!

1-12a  This page is cryptic, please expand.

1-12   1st bullet, this whole chapter is about locating cluster problems,
       SETSHO is primarily use to diagnose HSC problems.

1-13   We need a definition of System ID -- not defined in SYSNET string
       or the old VAXcluster course.  We need a small portion of a SHOW ALL
       here, with the full one in the appendix.

1-14a  2nd bullet, it was V4.5c that required this, V5.0 only allowed for
       this to extend a NI environment into the CI environment.

1-15   The commands to get this output is missing from the top of the page.

       Also, does anyone notice that the HW address is 08-00-33-xx-xx-xx?!
       Where did we get "33"?  Shouldn't it be "2B"?

1-16   Missing the commands (again) to get this output!

       Also, why is the QNA-0 set for a cost of 4?  Mine are 3!

1-17a  How about a definition of BUGCHECK on this page?!

Later...

$       

Well, the pilot is over and it went pretty well.  The course lasted a full 4
days.  We had 11 customer from different regions of the US.  The students (and
the instructor) enjoyed the course and felt it met its design goals.  

There are some short-comings to the course, numerous errors and a few typos
that were fixed.  2 chapters have an opportunity to be 'flipped', some of the
material was somewhat of a review, but there are discussions of moving that
material to an appendix.  Given that the 'review' material will be moved to an
appendix, this is a 4-day course.  If Emmalee can get a few other topics
included, as we discussed, it could be a 5-day course.

I apologize (for any others reviewing this material) that I didn't get the last
full chapter's review posted here, but time ran short and it was included
during face-to-face discussions.

  *** NOTE ***  

It is important to know that this course *CAN NOT* be taught successfully
without the instructor notes.  Necessary LAB SETUP information is on these
pages and NOT in the student materials.  Also, numerous tips, hints and
technical references are on these pages.  I normally only use the Instructor's
pages form Prep and I teach from the student materials.  However, it will be
necessary to at least copy pertinent information to your student pages or to
replace your pages from your lecture notes with the appropriate pages from the
instructor's book (specifically the lab pages).
   

Just another comment about the Troubleshooting pilot..

It did go very well.  Buck did an excellent job teaching the material and 
added to the class with his 'real life' stories.  The students said they 
learned valuable information and would be able to use it on the job.

The pilot did take four (full) days.  We are hoping to add some additional
information on the existing topics plus some additional topics like 
installations/upgrades, a little DECnet, and some on logical names.  Even
without this additional information, the students thought the class should
be five days with more time being given for lab.

One major comment that was made was the format of the course.  They felt
rather than doing all lecture then doing lab, that a point should be presented,
then do a case study in class, then let them do a similar lab exercise on 
their own.

One last thing - as Buck said, it is imperative that you get and use the 
Instructor Guide.  It has all the information on setting up the labs plus 
lots of other information to bring up in class.  Hopefully it will also
have some stories you can tell if you don't have some of your own!

  Any instructor's out there planning on teaching this course?  It's been
  very quiet in this topic!
  
  $

  This week is the second time I've taught this course.  It is going well
  and proves to be teachable material (I'm using the Field Test material).
  I've found a few more errors and I have some more ideas on
  reorganization which I'll post later.
  
  I've also determined that several of the labs aren't practical because of
  lack of adequate HW at training centers, insufficient time to set up the
  labs and the lack of 'crash-and-burn' systems.  I've modified them to
  provide the 'intent' of the exercise, but not the exact steps.  I'll
  write these up probably next week, but look the labs over carefully and
  let us know what you decide to do with these when you teach this course.
  
  $

Has anyone besides Buck taught this course lately?

Regards,

Perry

  I think Mark Rine in DC and John Grundhoefer in Atlanta are the only ones
  I know of...there are a few outside contractors that teach this.
  
  $