Conference koolit::vms_curriculum

    The course specification for VMS System and Network II

    is ready for review. The specification PostScript file 
    is in the location:

             SUPER::ES$REVIEW:[SYSNET_II]SYSNET_II_SPECIFICATION.PS

    Please review the specification. Modules will begin being posted
    shortly. It is important that you review the specification for
    topic location and flow and the modules for informational content.

     
    NOTE: VMS System and Network II (SysNet_II) is a follow-on course to
          VMS System and Network I (SysNet I). The SysNet II course will 
          build on the goals and objectives achieved in SysNet I course.

    First off lets make it clear that I DO NOT teach system management
    courses at any level.
    
    Secondly, this spec has some grotesque duplications from SysNet I's
    spec. I am unable to recommend this to colleagues in the UK
    and have serious reservations on the viability of the course as
    described. Our ability to implement on time must be in doubt.
    
    I was amazed at so much topic lifting from SysNet I.
    I can not believe this spec is the result of a careful design of a
    follow-on course to SysNet I.
    
    The spec has, like that of SysNet I, quietly omitted any entries for:
    
    	Day:
    	Lecture Time: and
    	Lab Time:
    
    My guess is this course, like SysNet I will be too much for a 5-day
    course with practical exercises.    
    
    Comments:
    
    Chapter 2:
    	Logical topics reappear from SysNet I
    
    Chapter 3:
    	Symbols topics reappear from SysNet I
    
    Chapter 5:
    	Command Procedure Flow control reappears from SysNet I
    
    Chapter 9:
    	Maintaining Disks:
    	What on earth is memory management and virtual memory discussion
    	doing in here?
    
    	Rooted directories were discussed in SysNet I
    
    Chapter 10:
    	Incremental Backups were discussed in SysNet I
    
    Chapter 11:
    	Software Installation topics were discussed in SysNet I
    
    Chapter 12:
    	The bulk of these topics have been Cut and Pasted from SysNet I
    
    Chapter 13:
    	Logical Names Tables: Chapter 2 did some of this (and SysNet I)
    
    Chapter 16:
    	The UETP topic appeared at Chapter 12 AND in, yes you've guessed,
    	SysNet I
    
    Chapter 17:
    	System Security: Cut and Pasted from SysNet I chapter 17
    
    Page 32, Table 1: Course media on-lilne too, please.

    As I have mentioned in chapter specific note replies, I am seeing the
    same things that Keith mentioned in .-1.  These courses specified do
    not seem to show the type of design agreed upon at the IPF.  I also
    agree with Keith as far as not being able to recommend these courses to
    my colleages in the Central Region as described in the specifications.
    My biggest concern is that Keith may be wrong in his advice concerning
    a rework.  A rewrite may be the only viable fix.
    
    Mark Thorne
    Chicago Customer Training Center

   
Fred;
  
  I have just completed a review of the "SYSNET_II_SPECIFICATION" and 
  have the following originations about the spec:
  
  1. Page 2, Section 1.9, This section essentially says that one of the
     topics that we are "not" going to talk about in "System and Network
     management II" is DECnet Network Management; there are, however,
     several "Network Management" (and correctly so) topics in the 
     module outlines.
  
  2. Page 14, Section 2.9.5, When you get to the drawings for page tables,
     lets don't show PTE slot 0 maping a physical page as is now done in
     several other courses. As many students never take the "Concepts"
     course, I would like to see much of that material here.
  
  3. Page 19, Section 2.13.5 (b.) The "interactive" process is not mentioned.
     
  4. Page 27, Section 2.17.5 (f.) In the current "Network Management I"
     course there are an excellent pair of flowcharts on "Access Control",
     they may be appropriate here.
  
  5. Page 31, Section 4.1, This hardware list may be suitable for the
     classroom, but is incomplete for labs. At least two nodes are required
     for access control; also, what about bridges, ethernet, clusters,
     and so forth?
  
  6. Page 31, Section 5.2, If you get inadquate instructor feedback, you
     also have inadequate field review.
  
  7. "MAJOR CONCERNS":

     a. There is way to much duplication with "Sysnet I".
  
     b. (If useful labs are included) There is to much material for a five
        day course.
  
     c. Times and coverage are not supplied.  The pilot is scheduled for
        June; can this be done?  Yes I know, much of the material can be
        lifted.

  8. I tend to favor a rewrite, and an extension of the pilot date. 
     Remember the warnings about the "Network Manager II Course" at the
     November 89 IPF?  Lets don't do that again.


  Arnold Tarling.

Some input regarding the Sysnet II course specification.

I've noticed a number of problems with the specification, many of which have
already been mentioned in other replies to this note, especially that of .1.

As it stands the course is going to be far too long to complete in 5 days.  
The same holds true for Sysnet I, but that's another note.  One must remember
that a typical day would allow for about 4 hours of lecture, 2 - 2 1/2 hours
of lab and the rest for breaks and lunch.  It will be very difficult to present
all of the topics without dropping much of the lab time or sounding like an
auctioneer.  That of course is ignoring the attention span of your average
student.  I hope that the length is seriously reconsidered before any further
development takes place.

Here are some of the specifics (aside from the length) that I've noted.  If
some things are replicated from previous replies of others, its only to 
reinforce the fact that they must be reworked/dropped, whatever!

1. Duplication of logical names between Sysnet I and Sysnet II.  The more
advanced stuff regarding the creation of new logical name tables is ok, but
the basics should go.  Leave it to the instructor to decide if any review
is necessary.

I also noted that logicals are repeated again in the System Monitoring 
chapter of Sysnet II.  A very odd spot for them, and a duplication from chapter 
2.

2.  A virtural address discussion in a disk and tape chapter??  I almost
fainted!  Now I may be missing something here, but it sure couldn't be
obvious.  I would like to see this stuff moved just prior to the System
Monitoring chapter.  It would be a good lead in to Show memory, Show system and
the monitor utility.

3.  Most of the info regarding VAXclusters and Networks seems to be lifted (at
least as far as the topics go) from the VAXcluster System Manager course and
the Network Manager I course.  Specific examples:  clusters: startup command
procedures, merging uaf..., backup operations  networks: terminal server stuff,
network monitoring.

It's my understanding that these two courses are still to remain as part of 
the VMS curriculum.  So what's going to happen with duplication between Sysnet
II and the current Network Manager I and VAXcluster Manager courses?

4. Distributed System Services - toss it.  My belief that layered products
don't belong in standard courses except for off-line discussions.  Geez,
it makes me think of System Performance and SPM/VPA...(ugh).

Regards,

Mark Dern
Toronto Training Centre

Good comments.  I am glad to see that the course specifications are under
scrutiny.  The following points need some clarification.


>3.  Most of the info regarding VAXclusters and Networks seems to be lifted (at
>least as far as the topics go) from the VAXcluster System Manager course and
>the Network Manager I course.  Specific examples:  clusters: startup command
>procedures, merging uaf..., backup operations  networks: terminal server stuff,
>network monitoring.
>
>It's my understanding that these two courses are still to remain as part of 
>the VMS curriculum.  So what's going to happen with duplication between Sysnet
>II and the current Network Manager I and VAXcluster Manager courses?
>

The intention of the new curriculum is to combine management of a single system
with management of systems involved in networks and clusters.  The Network
Manager course is expected to go away completely in time.  It will remain in
the curriculum for a time only to allow those students who started their
training on the existing VMS curriculum to finish their courrse of study.  By
that I refer to students who have taken U & C I and System Management I.  

VAXcluster System Manager will also remain as is in the curriculum for several
quarters to allow those following the existing curriculum to finish.  In time
however it will be modified to drop the modules that teach one how to manage a
VAXcluster environment to contain enhanced modules on building a cluster from
scratch.

Other courses expected to go away completely are System Management I (
right away ) and System Management II in 2-3 quarters.

Preliminary Maps  !!!!  ( Note the word preliminary ) have been distributed to
the areas.  Please take the time to study these maps carefully.

By the way, one bonus from this curriculum change is that there will be  a real
incentive for those who have started training to quickly finish the curriculum
before the existing courses are obsoleted or changed.


> 
> 

    Emmalee,
    
    Thanks for the clarification of the curriculum.  I've not been able to
    locate a new curriculum map... Is there some place I can copy it from?
    
    We here in Canada are in the midst of analyzing/preparing for the
    transition to theses new courses.  Since we've been a little lax in
    offering our opinions (plenty of excuses for this of course) but that
    is going to change!
    
    thx,
    
    Mark

    Two more things..
    
    Excuse the English is note .7 - I haven't had a coffee yet this
    morning!
    Any idea on when the modules for sysnet II will be available for
    review?
    
    Mark

    >Any idea on when the modules for sysnet II will be available for
    >review?
    
    Exact schedule is still being pinned down, since pilot dates haven't
    been reset yet. 
    
    Expect a new spec for review first (by this Monday 5/27). Our
    unpublished and very tentative development schedule has us posting
    modules for SysNet II during the period 5/28 - 6/7; they'll be largely
    cut-&-paste from existing courses. If the pilot winds up being any later
    than I expect it to be, I'll push for postponing the review dates so we
    can fine-tune the material a little better.
    
    						Val

The following milestones have been identified for the development of the System
and Network Management Curriculum to help the instructors schedule time for
field review.

Posted Date is the date at which ESDP expects to start posting pointers to the
modules.

Preparation Week is the week the instructor from Bedford will be in ZKO to
review the course materials and consult with the developer.

Pilot is the start of the week in which the Bedford Pilot will be held.


			Posted		Preparation	Pilot
                        ______		___________	_______

Sys Net I		done		done		5-Aug-1991

Sys Net II		28-May		29-July		12-Aug

Sys Net III		12-July		7-Oct		28-Oct

    New Sys/Net II spec is in
    
    	ES$REVIEW:[SYSNET_II]SYSNET_II_SPECIFICATION.PS
    
    See also the Sys/Net III spec in
    
    	ES$REVIEW:[SYSNET_III]SYSNET_III_SPECIFICATION.PS
    
    Sorry for the delay in posting these. It wouldn't have made sense to
    post the spec for II without making the spec for III available at the
    same time, since you really have to look at both.
    
    The topic lists for some of the modules are still evolving, but this
    spec should give you a better idea of what we're up to. 
    
    					Val

I've just looked at the SysNet II spec for the first time (I didn't see the
original version) and wish to pass on my comments.

I believe that the content is about right (but see below). Previous comments
about the last spec. said there was too much material - it seems to fit now and
follows neatly from SysNet II.  I await to see all the modules though, to
determine the precise content of the course.

I'm unsure about two of the course goals; managing use of main memory and
enhancing security.  The course is aimed at day-to-day management of a
configured system. I don't think these fit into that category. Neither are
really day-to-day events, and a "configured" system will, of course :-), be a
"well-configured" system. A system manager at this level should not start
fiddling with memory parameters or quotas. This can be left to the "support
person" for this novice manager.

All of the "user" modules (1-6) seem OK to me, as do 7 and 8.


Ch 9 - Maintaining terminals and printers.

  There seems much scope for rat-holing here. How many terminals and printers
do we sell?  How many different types will customers have (including 3rd
party)?  They may expect the instructor to (be able to) answer specific
questions about the setup of any - a tall order!

  Since these students are presumably "intelligent" users (system managers),
and that the system has already been configured and presumably in use, then I'd
question the value of including this module in *any* course.  I'd guess that
questions/issues around this area will be small in number and could be handled
"online" by the instructor as necessary.

  Or am I misreading this and the topic covers SET TERM, SET PRINTER et al?


Ch 10 - Maintaining disks

  There doesn't seem much to say here.  I (still) think VAXcluster device names
could be introduced in SysNet I, and the useful info from SHOW DEVICE could be
incorporated into the System Monitoring chapter of SysNet III. SHOW DEVICE will
have been introduced before in SysNet I, anyway.

Ch 11 - Backup

  I'd like this module to include everything about backup that is really needed
for system management (except that which has been met already). Possible
exceptions would be HSC backup and the issues with shadow sets.  Standalone
backup should be included as well as backing up cluster disks.  Issues
regarding the location of disks within a cluster can be ignored for this
module.

Ch 14 - Maintaining system security.

  I think this module goes into far too much detail for this course. I'd like to
see it cut down to the first four bulletted objectives, with all the rest moved
into SysNet III.  Of the topics - keep bullet 1 (points a-f) and the second
bullet (but not LOAD_PWD_POLICY). I think all other topics should be moved to
SN III, but leaving a *very* brief, general discussion of potential security
holes.

Ch 15 - System Monitoring

  I think the flavour of this module should be to introduce various monitoring
tools to the student, rather than put emphasis on managing memory. Any
pointers towards the management of memory can be included in Ch 16, or (better
yet?) SN III.

Ch 16 - Intro to Perf Mgt.

In my earlier review of SN I, Mod 10 - Closer look at environment, I suggested
that the topics on scheduling, working sets, balance sets, swapping etc be
moved to SN II.   I still think that, and Ch 16 is the logical place for them
to be placed.

I'd hope that this chapter is just giving an overview/introduction to all the
concepts listed.  I'd hope also that the instructor will shy away from giving
too much detail.  The "instructional strategy" says it all, but I fear it would
be too easy to get carried away.  I know I would :-)

That's it for SN II,  see note 94.? for SN III comments.

Stephen

    Thanks for looking at the spec so thoroughly, Stephen. Let me make
    some comments on the monitoring/performance area too, since I think
    it needs the most scrutiny & refinement.
    
    We have some constraints, and the spec proposes a possible solution.
    There may be other solutions (got any?) or we may need to remove one or
    more of the constraints. Constraints are:
    
    1) Every topic we teach needs to be task-oriented if possible.
    Information that is conceptual rather than task-oriented still needs to
    support one or more concrete tasks taught in the same course, or students
    won't retain it.
    
    2) There is consensus that we should cover adjusting account quotas in
    week 2. 
    
    3) There is consensus that we should cover "monitoring" in week II,
    though no specific agreement on what that means. 
    
    4) Our overall philosophy is to introduce all areas of system
    management early, then cover them in increasing depth in later courses.
    The bulk of performance should be in week III, but we should introduce
    it in II (obviously no room in I).
    
    Constraints 2 & 3 are somewhat at odds with the task-oriented approach.
    "Setting quotas" is useful only if we can teach them how to choose
    values for particular quotas -- not all of them, but at least some. 
    (It turns out we address this topic in the chapter on layered product
    installation. We'll tell students to read LP documentation for
    recommended account quotas and set them accordingly, and provide an
    example in which they do. Maybe that's all they need on setting account
    quotas.)
    
>   Ch 15 - System Monitoring

>  I think the flavour of this module should be to introduce various monitoring
>tools to the student, rather than put emphasis on managing memory. Any
>pointers towards the management of memory can be included in Ch 16, or (better
>yet?) SN III.

    You agree with constraint 3, but which tools? If we take the ones
    in System Management I (for the sake of argument), they're now
    covered elsewhere in this course except for SHOW MEM and MONITOR.
    
    How well is the SHOW MEM & MONITOR material received today? I seem to
    remember criticism that we show them a bunch of MONITOR screens with no
    practical application, but I suppose it depends on how you present the
    material. If it works well for most of you, we can use it as is --
    please tell us.
    
    If not, our hypothesis is that we can make students a little bit useful
    by teaching them to monitor some aspect of the system (paging activity)
    and giving them something they can do with the information (adjust user
    working set parameters -- we're focusing on those, not the system
    parameters that AUTOGEN takes care of). Of course that hypothesis needs
    to be tested in pilot, unless we get talked out of it now. Hey, if we
    don't really need a separate chapter on "monitoring," so be it.
    
    >Ch 16 - Intro to Perf Mgt.

>In my earlier review of SN I, Mod 10 - Closer look at environment, I suggested
>that the topics on scheduling, working sets, balance sets, swapping etc be
>moved to SN II.   I still think that, and Ch 16 is the logical place for them
>to be placed.
    
    Right, the original piece from System Management I should be the basis
    for this material. However, we still needed to introduce those few concepts
    in SN I that system managers tend to bump into early (the paging file, for
    example).

    I've no quibbles with the most recent replies just a few minor nits
    with this spec. Intriguing to find some topics have times and some have
    not...

    Page 1  refers to LanWORKS which is now PATHWORKS

    Page 26 line 4 of text refers to postscript. This should be
	    PostScript - a trademark of Adobe Systems, Inc.

    Page 28 table has two headings and the year for master to funder is
            printed as 1990.

    There are one or two other insignificant typos but life is too short...

    ;-) K

    >If we take the ones
    >in System Management I (for the sake of argument), they're now
    >covered elsewhere in this course except for SHOW MEM and MONITOR.
    
    Let me correct my own error -- we plan to introduce SHOW CLUSTER also
    (which I would have known if I'd looked back at the spec).
    
    					Val

    Re .13
    
>>   Ch 15 - System Monitoring

>>  I think the flavour of this module should be to introduce various monitoring
>>tools to the student, rather than put emphasis on managing memory. Any
>>pointers towards the management of memory can be included in Ch 16, or (better
>>yet?) SN III.
>
>    You agree with constraint 3, but which tools? If we take the ones
>    in System Management I (for the sake of argument), they're now
>    covered elsewhere in this course except for SHOW MEM and MONITOR.
    
    	The kind of thing I had in mind for this module is "keeping an eye
    on the system", so the sort of tools that could be used are SHOW ERROR,
    the operator console/log, SHOW CLUST, SHOW SYSTEM, SHOW DEVICE, SHOW
    MEM.  This is almost a gentle introduction to troubleshooting.  If a
    user says "xyz is/is not happening to me" then the System Manager would
    use tools such as these to investigate. So, the chapter would show the
    capabilities of the tools and give examples of "problem situations"
    which they may encounter,  e.g. a cluster disk in mount verification
    because of errors.
    
    Thinking about it, then MONITOR can be included in this set as well,
    perhaps just limiting to MONI SYSTEM and point out the sort things that
    will be seen on a "bad" system.
    
    I guess all I'm trying to say is that care should be taken about how
    much *tuning* information is given (in Ch 15 or 16). It'll be all too
    easy to discuss the meaning of MONI PAGE screen items for example, and
    either confuse the class (remember it was only a few days ago that they
    learned about command procedure GOTOs, advanced logical name and symbol
    usage!:-) ), or tread on the toes of the Performance course.
    
>    If not, our hypothesis is that we can make students a little bit useful
>    by teaching them to monitor some aspect of the system (paging activity)
>    and giving them something they can do with the information (adjust user
>    working set parameters -- we're focusing on those, not the system
    
       If you pick on paging activity, then you could just as easily pick on 
    disk I/O rates - they're a big problem as well, arguably the biggest in a
    cluster.  Again, this is my point - where do you draw the line so that
    the information *is* useful to the majority. Not all students will have
    memory problems, but they may have I/O or cpu problems instead.
    
    
 >   How well is the SHOW MEM & MONITOR material received today?
    
       Well, I'll leave it to other to comment on this since I'm not "in
    current Sysman-teaching practice".  However my students *love* it when
    I show them, but then that's during the Performance class :-)
    
    
    Stephen

    I agree with Stephen in .16. It is important not to go to deep into
    tuning or performance issues. An overall look at what a good system
    and a bad system look like. For example, in "MONITOR SYSTEM" we might
    point out the 5-6 COM processes indicates a saturated CPU. We just want
    to discuss the rough spots. 
      
    Arnold.
    

    I've seen a couple of times the comment that "clusters aren't until
    Sys/Net III" so we should avoid cluster topics.
    
    Our aim now is to introduce clusters early, since most customers have
    them. Unlike the old curriculum's approach, in which students learned
    to build a cluster and then to manage it, we're aiming to teach the
    cluster-management tasks alongside the single-system tasks in Sys/Net I
    and II, and then building (single-node and cluster) in III.
    
    As long as students are introduced early to the concept that a cluster
    is a bunch of nodes, they should be able to do basic managing and
    monitoring. The "what-is-a-cluster" stuff is in Sys/Net I; it's not
    much different from what was there before, but maybe the instructor
    needs to call more attention to it. 
    
    Is there something wrong with this approach? Is the introduction to
    clusters in Sys/Net I inadequate to support this approach?
    
    					Val

     I suppose I have said several times that clusters are'nt until
    sysnet III.  I agree that clusters should be introduced early, but
    I'm not sure the students may all have the right background for
    some of the cluster topics I feel are pre-mature.  I know over 85%
    of our customers have clusters, but that does not mean they understand
    anything about them when they take a course. I think for some of
    the cluster material you would already have to have a basic
    understanding of clusters to understand.
    
         I get people  who are clueless at the beginning
    of the week, and lost at the end of the week  right now in System
    Manager I.  These are people who just got their Vax last week, or
    are expected to have it ship 3 months from now.  For those type
    of people, and we do get them, a standalone system is confusing
    enough and here are clusters thrown upon them in bits and
    pieces.  I dont know if that will work and I geuss I won't know
    until I teach the courses for the first time.  I hope it does though.
                                                 
    
    Wendy Mullenhoff

The directory ES$REVIEW:[SYSNET_II] now contains revised drafts of all
chapters of the course (except for the written exercises, which are
forthcoming). These are the versions that will be used in the course pilot
on August 12.
    
If you have any further comments, please get them to us by August 16 so that
we can look at incorporating them in the post-pilot revision pass.
    
A million thanks to those who have posted or sent comments so far.
       
    					Val


SYSNETII_CHAP1.PS  Preparing Data For Use In a Command Procedure
SYSNETII_CHAP10.PS Introduction to System Customization
SYSNETII_CHAP11.PS Layered Product Installation
SYSNETII_CHAP12.PS Maintaining System Security
SYSNETII_CHAP13.PS Reporting on User Activity
SYSNETII_CHAP14.PS System Monitoring
SYSNETII_CHAP15.PS Introduction to Performance Management
SYSNETII_CHAP1A.PS Using Logical Name Tables
SYSNETII_CHAP2.PS  Handling Input & Output In a Command Procedure
SYSNETII_CHAP3.PS  Manipulating Data in Command Procedures
SYSNETII_CHAP4.PS  Using Symbols in Command Procedures
SYSNETII_CHAP5.PS  Writing Command Procedures
SYSNETII_CHAP6.PS  Using VMS Processes
SYSNETII_CHAP7.PS  Maintaining Disks
SYSNETII_CHAP8.PS  Queue Management
SYSNETII_CHAP9.PS  Performing Backups and Restores
SYSNETII_LABS.PS   Sys/Net II Labs

    Here's our proposal for major revisions based on the pilot results. It
    does not reflect minor additions and bug fixes, which we're also doing.
    Please comment by the end of this week, 9/6. (Sorry for the short
    review period.)
    
    - Move chapter 1 (Preparing Data) to Sys/Net I, placing SORT/MERGE in an
      appendix. (This is already being done.)
    
    - Condense chapters 3-7 and move to the end of the course. Remove the labs
      on generic DCL programming and include more labs specific to system
      management (by adapting the System Management II labs). Topics to 
      remove include:
    
    	- File I/O
    	- Much of the Manipulating Data chapter
    	- CALL/GOSUB
    	- Nested, iterative, and recursive procedures
    	- Error handling
    
    - Move the Monitor Utility material and the chapter on Performance to 
      Sys/Net III. (The course is too full, and something else had to go.)
    
    - Add a small chapter on day-to-day network management, to include:
    	- Simple monitoring with NCP commands, including TELL command
    	- Adding/removing a remote node to/from the local database
    
    					Val
    

The directory ES$REVIEW:[SYSNET_II] now contains a copy of the Instructor
Work Book and the Student Work Book. These are the versions that will be used 
in the course pilot on November 4th.
    
If you have any further comments, please get them to us by November 8 so that
we can look at incorporating them in the post-pilot revision pass.
    
A million thanks to those who have posted or sent comments so far.
       
    			Bonnie


Instructor Work Book:

	ES$REVIEW:[SYSNET_II]SYSNETII_IPROFILE.PS

Student Work Book:

	ES$REVIEW:[SYSNET_II]SYSNETII_SPROFILE.PS
	

    The final instructor guide for Sys/Net II is in:
    
    	SUPER::ES$INSTRUCTOR_GUIDES:EY-G987E-IG-0001.PS_LZ
    
    					Val

    p. s. the lab files are still in ES$REVIEW:[SYSNET_II] until we get
    around to putting them under ES$MEDIA.

    I just looked in ES$REVIEW:[SYSNET_II] and ES$MEDIA for the SYSNET
    II lab files and didn't find them.  Are they somewhere else?
    
    Thanks,
    Sherry

Sherry,

You can find the individual lab files 
Directory ES$REVIEW:[SYSNET_II]

DATA.COM;1                3   2-JUN-1988 10:44:33.00   9-DEC-1991 11:15:35.21
ENTRY.EXE;1               5  26-FEB-1988 13:50:27.00   9-DEC-1991 11:15:35.37
HARMLESS_AUTOGEN.COM;1
                        219  25-MAY-1988 17:49:07.00   9-DEC-1991 11:15:35.49
HARMLESS_AUTOGEN_V54.COM;2
                        247  16-OCT-1991 16:49:11.22   9-DEC-1991 11:15:35.63
REMOVEISSUECMD.COM;1
                         18   3-JUL-1991 13:32:54.00   9-DEC-1991 11:15:35.76
SYSMGT_LOGICALS.COM;1
                          2  10-JUL-1990 13:58:47.00   9-DEC-1991 11:15:35.89

							Paul

    Paul,
    
    I miss a saveset to install in conherent with a license and modifying
    some quota's in the file SYSUAF.DAT
    When you want to teach task-oriented you need a lab exercise with 
    installing a layered product (dummy layered product).
    
    Ed Janssen.

    re .27  Developing a "dummy" product kit has been on our list of
    possible things to do, but sorry, it wasn't done this time around. Our
    recommendation is still to give students a relatively simple product
    (such as a compiler) to install.
    
    					Val
    

Val,
	

	I have deveoped a dummy VMSINSTAL kit called SYSNET054.A. Let me
know where you want me to copy it to. The installation is very simple.

	Basically it asks the student for the disks and directory location
to place a file (FIREWORKS.TXT). After verifing (sp?) that we have
legit locations we move the file and run and IVP. The ivp checks to
make sure the file exists and asks the user if they want to view the 
file. Also it places the release notes in sys$help.

	Yes I know FIREWORKS.TXT how cute. Cest La Vie.
	I have tested it and it seems to work. We are teaching SYSNET II
this week and will be using the saveset as a lab. Will see if the students
can find any problems.

Todd

    Thanks, Todd! SYSNET054.A is now in {SUPER,HARDY}::ES$MEDIA:[EY-G987E].
    I put the other Sys/Net II files there too.
    
    					Val

>                            -< Dummy VMSINSTAL kit >-

Todd,

Great stuff!!!!!!

You win the 1992 Spiny Norman Award for Initiative and Labour!

The award consists of this message, and an wide-topped glass container of the
beverage of your choice next time we're both in a suitable establishment!

Bring this message to claim the award! 

Cheers,

Andy




Val, 

I'd like to get the benefit of this to all the training centres, even those too
'busy' to read this conference - please can you send the notice out to the
world.

Thanks,

Andy

	Digging through my old MGR course directory I came across
a fake PAK that I was givin a long time ago. It still works (V5.4-3).
I do not remember where I got it from though. It may be of help
as a lab especially if the students create private licence file and
then use the /database qualifier to add this PAK to them.

Todd (S.N.A.I.L. Award Winner) 

P.S. What is a Spiny Norman?



  
$ !
$ !		      FOR DIGITAL INTERNAL USE ONLY
$ !
$ !		     Issuer: DEC
$ !    Authorization Number: SQM003058
$ !	       Product Name: ED_SERV_FORTRAN
$ !		      Units: 500
$ !    Product Release Date: 
$ !	   Termination Date: 
$ !		    Version: 1.0
$ ! Availability Table Code: 
$ !	Activity Table Code: 
$ !	    License Options: 
$ !	      Product Token: 
$ !             Hardware Id: 
$ !		   Checksum: 1-PAOI-MJNP-NCJL-DEKP
$ !
$ ! REGISTER the license
$ !
$ LICENSE REGISTER "ED_SERV_FORTRAN" -
/ISSUER="DEC" -
/AUTHORIZATION=SQM003058 -
/PRODUCER=DEC -
/UNITS=500 -
/VERSION=1.0 -
/CHECKSUM=1-PAOI-MJNP-NCJL-DEKP 
$ LICENSE LOAD ED_SERV_FORTRAN

	Hello colleges,

	In Holland we have the following solution.
	We have a LAB exercise about installing several products.
	So the students learn how to install a layered product.
	I/we think this is one of the basic function of a system manager.
Therefore it is not enough to tell them how to do it, but let them do it during
a practical session. The reaction of the students is very enthusiastic.
	What they do is using VMSINSTAL to installated there products. We have
8 products available. 
	For instant one of them is receiving the product COMPUTE. He/she is
getting a saveset called COMPUTE010.A which exits of 4 files.
		COMPUTE.CLD
		COMPUTE.EXE
		COMPUTE.HLP
		KITINSTAL.COM
	
	The saveset can be find on location:
		NWGEDU::NWGEDU$DUA1:[NETCOP]PAKKET.BCK

	There are two problems. The product with the name DRUK is similar with
the English PRINT. The product with the name VERVANG is similar with the
English REPLACE. The DCL commands PRINT and REPLY are in conflict here. So
that's why we changed it into Dutch. Otherwise your DCL-table will be different
after you have finished this exercise.
	 So you can choose. I think that now we are promoting the new VMS 
Curriculum, this is a very good exercise.
	If you need further information, please let me know. Mailing address:

		NWGEDU::WIERSMA    (VAXmail)
		Arjen Wiersma @UTO (ALL-IN-1)

	With kindly regards,

	   Arjen Wiersma.


	
    

    re .32 Great idea! You can now find the ED_SERV_FORTRAN PAK in the lab
    exercises for Sys/Net II -- see exercise 6-2. (Who says we're
    unresponsive :-) 
    
    					Val

>P.S. What is a Spiny Norman?
>

Ask any Monty Python fan!

>>P.S. What is a Spiny Norman?
>>
>
>Ask any Monty Python fan!

But don't ask too loudly...you DON'T want to attract Spiny Norman's attention...

    Hi Todd,
    
    Does this VMSINSTAL kit SYSNET054.A have a license to register, because
    if we want to work task oriented we need to create a laboratory
    exercise that is close to the reality. After registering and
    installing, the student has to run the product. If no license was
    registered the product has to give the message no license loaded. 
    Maybe it is also possible simulate that if a user should run this
    product he should have enough quota's in SYSUAF.DAT.  If not the
    student has to modify it.
    
    If we can include all these things in the product, we have a product
    close to the reality.
    
    Regards,
      Ed Janssen 
                                                                     

Ed,

	As it is built now that SYSNET054.A saveset does not require 
a PAK. Though I have included a PAK into this conference for labs.
I could change the install procedure to ask about a license, and the
change would not be very difficuly. I do see one problem though.
We only have one PAK, and seeing as the LMF$LICENSE.LDB is a common
file you probably don't want each student registering the PAK on 
the same system. The only work-around I can come up with is having
the students create a private, basically useless, LMF file in there
home directories. Then let them experiment with licensing on this file.
	I do understand the concern. That the vmsinstal lab is a bit
contrived, but I am not sure there is an easy work around. The way I 
am going to handle it, is just to explain what the normal sequence
of events are and then have the students play with the PAK and VMSINSTAL
as seperate labs. 
	Let me know what you think. If there is enough interest I can 
add the commands to the SYSNET054.A to do the checking.

Todd

Dinsdale, on the other hand, is lovely feller! A real gentleman is Mr Dinsdale!
Why only the other day he...

    Hi Todd,
    
    >	Let me know what you think. If there is enough interest I can 
    >   add the commands to the SYSNET054.A to do the checking.
    
    I think it's a good idea to implement the PAK and the commands in
    SYSNET054.A saveset
    
    In Holland we have a few �VAX 2000 systems during the course to 
    install the saveset, so the problem of one PAK is not really a 
    problem for us.
    
    Regards,
      Ed Janssen

I just completed my first Teach of SYSNET II on 28-FEB.  My overall impression
of the course; I will give at the end of the note. (Don't go to the end YET!!)
From the outset,  I have never agreed with the name VMS SYSTEM @ NETWORK
MANAGEMENT, it can, and in most cases is misleading. 

The class was a mix:

	2 - Communication/Network (Of course they enrolled to get more than 1
	    module of Network information)

	1 - MIS Manager (Experience in VMS/Wanted to fill in the Gaps)
	
	1 - All-IN-1 Manager (Was prep. to backup System Mgr.)

	7 - All had taken previous VMS Courses (Expected to get more specific
	    information about their configuration/and better understanding of
            VMS.
		* 1 Had 5 previous Courses
		* 1 Had 10 previous Courses

No sense in going into the details of what's not right in the manual. (****
SEE WENDY NOTES, I AGREE WITH HER.)  My attitude about that is, If we find
something wrong in the manual, it should be corrected before the next class is
tought!  But from my understanding that will not happen.  So, I make the
adjustments as I go along.  Can someone please explain to me the JIT process.
I mean, I am sitting here typing this memo.  If I save all the information,
print it, hand a copy out to 100 people.  Someone calls me to tell me I made a
typo.  I tell everyone to take the memo (PLACE IT IN THE ***RECYCLE*** BIN). I
Go back modify and redistribute.  Does developement/JIT produce 1,000 copies
because we are projected to deliver the course to that many students!!! So the
cost factor to modify and reproduce is too great in the time to get it out?? 

I agree, it does take someone who knows, SYSMAN, NETWORK, @ CLUSTERS.  Atleast
someone who has an understanding of each.  If you are getting ready to teach
be sure you know the material in the above courses.  A sit in performance,
and Sysnet III could not hurt here either!!.

My first teach of the course was good,  but I had to go beyond the scope
of the course in every module!! I had to go back to what one of my students
conveyed (We are still in the generic que, trying to get to the execution que).
Needless to say, I had to spend time explaining generic, execution and what
happens after the execution stage.  Again all of it was not in the scope of
the course, BUT IT WAS WHAT THE CUSTOMERS WANTED.  There even was an incident
where one student got frustrated and expressed in front of the entire class
he was not satisfied with me or any other DEC courses he had taken.  And he
had a valid gripe because he had not taken SYSNET I and did not get his
Bridge material until the Monday morning of SYSNET II.  But , he also had
taken U&C I, SYSTEM MGR I, VAXCLUSTER MGR. This was one situation where I had
to sit down with him after class to explain step by step of setting up a que. 
Once that happened he said "And you are going to tell me it is that simple" I
said "NO, YOU JUST TOLD ME THAT."  Just needed individual attention. I thought
for sure I was going to lose his Q.A.  His was one of the best! 

My overall impression of the course is mixed.  This course for me had to be
taught as Lecture/practical lab while I lectured. The next time I teach it I
will use this same format. Which does mean that we will not have much time to
do the lab excercises in the back of the book. I had 2 students who (N) the
practical/lab time 1 (NA)/2 who was not satisfied with the systems (We lost a
System Disk).  So, until I teach it again and gather more information to sway
me from the middle, I'll continue to teach the course using the above format (I
will stay away from the recommended way, I probably would not do as good if I
followed the recommended format because I would have to constantly tell the
students, "That Topic is not in the content of this course, or that was covered
in another course and from my experience "STUDENTS HATE TO HEAR THOSE WORDS).
Yes, I do point them to the right course for the topic. 

So to all remember, 

			TELL ME, I FORGET
			SHOW ME, I REMEMBER
			INVOLVE ME, I UNDERSTAND

				Ancient Chinese Proverb
Kenny....

About JIT...someone who knows more about this might correct my blunders...

The way our system works now, a course is developed, goes through an editing 
cycle, and then through a release cycle. At the end of the release cycle the 
master PostScript file is made available to the JIT folks.

JIT is tied in to the course registration system. They receive notice three or
four days in advance of a teach about how many students are enrolled. They then
print the appropriate material in the specified quantity and  drop ship it 
directly to the teaching facility.

Schedules and budgets make it not possible for course developement to be this
flexible. Even if we had the people to make corrections on the fly, it
would eat up two or three days just for a minor fix...certainly not a
cost-effective solution.

With modular courses we should be able to update or correct individual chunks
of information (one paragraph or on header level or whatever), and make the
updated files available to JIT. The JIT folks would build a fresh
PostScript master when they detected that a change had been made (through a
makefile-like mechanism). This way the field would always receive the most
current version of a course.

I think we're a few years away from fully implementing this kind of flexibility,
and I don't even know if we'll go in this direction. It makes sense to *me*, but
I don't have to do all of the work to get it going...

Perry

    
>>Schedules and budgets make it not possible for course developement to be this
>>flexible. Even if we had the people to make corrections on the fly, it
>>would eat up two or three days just for a minor fix...certainly not a
>>cost-effective solution.
    
    Help me understand more fully, please, why it is that making a minor
    fix to a set of materials will take 2-3 days.  Isn't it just a matter
    of editing the source file and running it through DOCUMENT again?
    And, then, making the new "source" available (supposedly, on-line) to
    JIT.
    
    Is it actually the case the 100's (1000's?) of copies of the materials
    are pre-printed and stockpiled?  If so -- it would seem that it's the
    real culpit here.  With the highspeed copiers/printers available, why
    not just print on an as-needed basis.  
    
    Serious questions -- thanks for your time and consideration.
    
       GJD

    
    Greg,
    
    Let's break it down:
    
    	If the course has been released...we no longer 'own' the
    	source files...they have been delivered to the funding
    	organization. We need to get them back from that organization.
    	That will take anywhere from a few minutes to several hours
    	depending on sun spots et al.
    
    	We then make the changes. Ta-da!...Oh let's say an hour.
    
    	We then re-cook the offending chapter and fix all the page breaks 
    	that got broke because we fixed something [it happens..DOCUMENT
    	is not a forgiving beastie...]
    
    	We then cook it again...ok...ready. Let's say that for a normal
    	day with 16 other developers hitting the system with their
    	chapters to build also...ti takes a day to make the changes
    	and check that they are correct.
    
    	Then we do the BIGGIE...we build the book. On our system with
    	load it handles...several large volumes building a day...we
    	can easily take a day to build the course. That's nobody's 'fault'
    	just a reality of our load, software amd hardware.
    
    	Then...we are REQUIRED to pass the course by a Release Engineer
    	to insure that no trademaks have been violated etc. Even when
    	told that only pages such and such have been changed...they are
    	still LEGALLY required to check every page...[counted the pages
    	in a book lately]? That takes another day.
    
    	I think I am up to 3?...Multiple this out for everytime someone
    	finds something they think needs changing and you could employ
    	a full-time developer just to monitor courses and rebuild them.
    
    	In addition to doing this...the developer who is doing what
    	you request is probably writing chapters for one or two other
    	courses...and building those....that's reality.
    
    Mel
    

 >   Is it actually the case the 100's (1000's?) of copies of the materials
 >   are pre-printed and stockpiled?  If so -- it would seem that it's the
 >   real culpit here.  With the highspeed copiers/printers available, why
 >   not just print on an as-needed basis.  
 
No, they print only what they need when they need it, hence JIT. I toured the 
JIT facility at DDD a few months ago. It's amazing...hundreds of empty warehouse
shelves (we're talking 20 foot-tall shelving) where they used to stockpile
materials.

They're saving the company millions of dollars each year in stocking, 
control, and waste costs.

Mel is correct, our process has a lot of time built in to it. Some is needed;
we really do require publishing and release functions, especially
now that modularity is becoming a reality. There are definitely some places
where we can cut steps or reduce time without affecting the quality of
the product, and we're right now analyzing how we work in order to reduce
our 'fat'.

We basically know how things work today, and we have a fair idea of how things
*should* work. The difficult bit is reworking our traditional methods to
fit into a more efficient process.

Perry

    
    
    Wow.................................
    
    It kinda seems like the process is getting in the way of progress.
    
    I understand much more clearly now -- thanks.
    
        GJD
    
    

    Suggestion,
    
    Would it cost too much for Developement to plan a revision period after a 
    release.  Because, I guarantee you after a first teach of a course you
    see a lot more Typos and mistakes than you do when you are reviewing or
    prepping the course!! Maybe somebody out there might agree with me?
    
    
    Kenny "B"
    

    Moderator speaking again...
    
    If this conference gets filled up with general beefs about the
    development process, it will be that much more trouble for us to find
    the course-specific comments when it comes time to update the courses. 
    
    I'm temporarily write-locking this topic and moving this string to
    ESDP_INSTRUCTOR_NOTES.
    
    					Val