Conference koolit::vms_curriculum

    
    In what format will the new VMS courses be offered.Will they be offered
    as lecture/lab courses,self-paced instruction,computer based
    instruction or IVIS.
    How many of the excisting VMS courses will be deleted ?
    
    I hope this is not too early to ask these specific questions.
    
    thanks
    	steve
    

    
    Hi Steve,
    
    The courses that are currently going up for review are all
    lecture/lab. For many reasons they are more easily broken apart and
    they are more apt to be wanted in a customized version.
    
    As we speak, plans call for all the current VMS user type courses
    to be replaced by five courses:
    
    	VMS For Application Users (3-days)
    	VMS For Advanced Application Users (2-days)
    	VMS For Operators (5-days)
    	VMS For Programmers (5-days)
    	VMS For System Managers (5-dyas)
    
    For a detailed run-through of how these areas were chosen, how they
    break out, how they get put back together...see:
    
    	SUPER::ES$REVIEW:[RA0293]RA0293_PLAN.PS
    	SUPER::ES$REVIEW:[RA0294]RA0294_PLAN.PS
    	SUPER::ES$REVIEW:[RA0295]RA0295_PLAN.PS
    	SUPER::ES$REVIEW:[RA0296]RA0296_PLAN.PS
    	SUPER::ES$REVIEW:[RA0286]RA0286_PLAN.PS
    
    Then, if you have specific questions, either post them here or\send me
    mail.
    
    Thanks
    
    Mel
    
    

    
    Thanks Ed, for catching the errors..
    
    RA0294_plan is currently in SUPER::ES$REVIEW:[TEMP] until
    someone with enough priv to fix the directory protection
    gets back in. [grin]
    
    I will keep you all posted on 286...which is the SYSMAN
    plan. We decided to group this course with the SYSMAN string,
    and discussion is still going on about what that string will
    look like. The plan I have is old and outdated based on those
    discussions, so you will have to wait a bit for it.
    
    I will announce it again as soon as we have a new plan.
    
    Sorry...I know enough to look before I type...but I forget now
    and then...[grin]
    
    Mel
    

RE: Note 2.1

>    In what format will the new VMS courses be offered.Will they be offered
>    as lecture/lab courses,self-paced instruction,computer based
>    instruction or IVIS.

As Mel has said the currently existing documents deal only with L/L, but 
it is my intention that we will also produce SPIs that will mirror these
courses. Most of these will be TBI or TBM format.
 
>    How many of the excisting VMS courses will be deleted ?
>    

All of the courses that have been used as input to the process will be
replaced during this process.

Hope this helps, sorry the the delay in replying.

Cheers,

Andy

Hi There.

Moooooan, weeeep #@%&/&� How could you!!!

I have just pulled the source to 'VMS for Application users' from our master
library here in Europa. My intention was to cut some of the chapters, and paste
them into my VMS U&C, so the student could get a proper chapter on EVE and
Terminal servers. 

I got the master and unpacked the saveset. I noticed that all
the text was SDML-files. 'Well' I thought 'I read something about them using
VAXdocument, but no problem - I'll just use a CDA-converter to make a DIFF file
and stuff it all into DECwrite'. Hours later I found out that DECWRITE can only
import SGML-files (and SDML and SGML is not compatible!!) Next idea was trying
to make a SGML file from a SDML file, but this grinded to a abrupt halt, as
the SGML notesconferance informed me that no CDA-converters exist for this.

Now I am wondering, why anybody can state that this restructuring greatly
faciliates the posibilties for localisation and modification, if all is written
in a *non-convertible* documentformat??? Of course I could sit down and learn
VAXdocument, but I do not have the time and energy to learn yet another
antiquated DTP language! 

I would be very delighted if anybody could tell me what to do, or better 
supply me with DDIF-files. 

A dissapointed 


J.O.S. Svendsen ed. serv. @DMO

 

    [I moved 2.5 here since it deals with materials in general.]
    
    I'm afraid we can't be much help... ESDP has been using DOCUMENT since
    before CDA tools were available, and we have no plans to provide the 
    files in DDIF.
    
    Besides, if we did, anyone without a workstation would be unable to
    use them, and there are lots of people out there without workstations.
    
    					Val

Hi There.

Sorry to be persistant, but DDIF is just the right format for this.
Our library of CDA-converters, gives users on VT's, PCs, MACintoshes the 
posibility to modify the source. This is (rightly so) an important 
part of our 'OPEN ADVANTAGE' strategy. Furthermore DDIF is a concept in de-
velopment, as audio and video are to be included in the standard. 
The usage of DDIF would be a future-proof concept, and usable in
a standard way by all interested. 

I can understand that you probably have a zillion pages of old 
course materials, that you do not want to use too much manpower
in converting to DDIF. But I can not see any arguments for using
SDML-format in the *new* course materials.

Please note that I am not arguing agains the usage of VAXdocument,
but more against the usage of a non-standardized, non-convertible
text format. Feel free to use VAXdocument, but pls. deliver the
sources in a format I can put into my nice WYSIWYG DECwrite, as
I (and probably others as well) do not feel to motivated to
learn VAXdocument, in order to change the order of two chapters.

The purpose of delivering the sources, should be to enable easy modifi-
cations of the materials, according to the current needs, or am I
mistaken?

The Best

J.O.S. Svendsen  
 

RE: 2.7

Hi Jens! How are you over there in Denmark?

Well, you have hit a problem right head on in your comments.
Good question...Let me give it a try...

But before I do:

	Our business group has just appointed a senior consultant
	[the ink is hardly dry!] to handle implementation strategies
	just such the one you mention.

	His name is Bill Walker. He receives mail at:

		WAGON::WALKER

	And he is one of the people who should really field
	this question.

	Unfortunately, not only has he just hit the ground running
	on this project, but he is also on vacation until sometime
	after the beginning of September. I will make sure that
	he gets his feet wet in the conference once he gets back.

In the meantime, here are _my_ thoughts on your comments...with the
caveat that they are _just_ my thoughts. OK?

>This is (rightly so) an important 
>part of our 'OPEN ADVANTAGE' strategy. 

	Yes, I can see that. And don't think that we
	are not equally eager and aware of such a strategy.
	We hear you, honest.

>Furthermore DDIF is a concept in de-
>velopment, as audio and video are to be included in the standard. 
>The usage of DDIF would be a future-proof concept, and usable in
>a standard way by all interested. 

	I agree with your intent. I do not necessarily agree that
	DDIF is the _only_ future-proof strategy. But I agree with
	the necessity you imply and our implementation plans
	are being driven by that need, as well as others.

>I can understand that you probably have a zillion pages of old 
>course materials, that you do not want to use too much manpower
>in converting to DDIF. But I can not see any arguments for using
>SDML-format in the *new* course materials.

	Well, sort of. [grin]

	The problem is not manpower really, or even conversion 
	[we work for a computer company...we could write a program
	to do that...{chuckle}]. The problem is to decide _what_
	move to make so you don't have to _unmake_ any of them.

	Currently, it is most cost effective to get all materials
	in a _SINGLE_ format that can be manipulated in a flexible
	way. The reason for this includes such strategies as
	using material from other organizations rather than re-developing	
	it ourselves; producing multiple format documents from
	single source files. 

	That is not to say that the format we are in will be the
	format of the future. It probably won't. But if we
	standardize the format that we currently have, it won't
	take exorbitant manpower to then _reformat_ it to any
	other format. That is the point we are at today.

>Please note that I am not arguing against the usage of VAXdocument,
>but more against the usage of a non-standardized, non-convertible
>text format. 

	Again, I agree with the sentiment, but we are doing just that.
	I think you just don't like the chosen standard. DOCUMENT is
	capable of producing a straight ASCII text file of any document
	we publish...that's about as convertible as you get.

	And there is nothing to say that DOCUMENT couldn't be
	adjusted to provide DDIF output, either. But that is
	a business decision that goes far beyond the scope of
	modularizing the VMS curricula.

	We are aware of these issues, and we are doing our best
	to work them. And we need your input. With the appointment
	of Bill Walker, we now have a person in place to coordinate
	all the input from various places and start to consolidate
	it into a viable implementation plan. Just keep in mind
	that real implementation in an orderly fashion takes
	some time to be put together.

>Feel free to use VAXdocument, but pls. deliver the
>sources in a format I can put into my nice WYSIWYG DECwrite, as
>I (and probably others as well) do not feel to motivated to
>learn VAXdocument, in order to change the order of two chapters.

	Finally. The real issue.

	1) Delivery of sources is a business issue that your
	management needs to address with the funding organizations.
	[Andy! Where are you when I need you?]

	2) Is your business need to A) reorder chapters or topics
	in courses to produce a customized course _OR_ B) to
	be able to monkey with the code of a source file?

		If it is _A_, then I can hold some real hope
		out for you. Our intention is to develop a series
		of utilities that will enable you to select
		parts of a course and build it. You will not
		need to know any formatting language to do this,
		as the utility will 'code' the customized
		course for you. This is not going to happen
		next week. But we are actively pursuing this
		business need.

		If it is _B_, then I think you are going
		to find yourself in a territory fight over
		who owns what files. And that was a great
		simplification of the business issues involved.


>The purpose of delivering the sources, should be to enable easy modifi-
>cations of the materials, according to the current needs, or am I
>mistaken?

 	I think you _NOT_ mistaken. But I also think that there
	are several ways to address that purpose, and we are
	addressing it. Please do not assume that just because
	we are attacking the problem from a different vantage
	point, that we are not making progress.

	I realise that lack of communication is an issue here.

	I would ask the favor of holding off for another little
	while until Bill has a chance to get on board. We do hear
	your concerns and we all need to work together to meet
	the business needs of training development and training
	delivery.

	Thanks

	Melinda

Sorry not to have replied before - I've been travelling...

Anyway, I hear the request, and I believe that Mel has expressed our position on
this very well - we have a standard, and the standard defines VAX DOCUMENT as
the tool of choice. The standard was not unilaterally chosen, the decision was
taken involving all the interested parties, including all the geographies, and I
believe that the decision was right then and continues to be correct now. It
interesting to note that CUIP also have DOCUMENT as their standard for a lot of
the same reasons as us.

On the subject of using a new tool for new courses... this sounds fine till you
realise that we're not reworking all the courses now, and that we will want to
tailor together new and old, without the seam showing...!


Having said that, I agree with Mel that we will almost certainly move to a
different standard at some time and that this might well be DDIF (assuming that
DDIF becomes the industry standard). When that discussion comes up I'll make
sure that this input is represented.

On the question of having to learn DOCUMENT to move chapters around...

Be assured that we will be designing tools and processes to ensure that the
level of expertise required to tailor materials is as low as possible. The
'design centre' I have specified is that for chapter level tailoring, any
non-specialist should be able to do the tailoring after AT MOST 1 day's
training. Mel assures me that they can easily meet this criterion.

Tailoring at below the chapter level will require somewhat more expertise, but
again the design centre is that this shouls be achievable by a non-specialist
with minimal training.

I'm forming a modularity implemetation task force to ensure that Geograpy needs
are met. Anyone who feels a particular need to take part should contact their
geography rep:

Europe - Bob Sowton
USA - Roger Towne
GIA - Nancy Giddens

OK?

Andy

   In my reply 12 to Note 5 of this conference I promised some comment
   on modularity.

   In the context of the restructured VMS User curriculum and its
   core topics:

	1  Logging In and Out of a VMS System
	2  Issuing Commands
	3  Naming and Storing Files
	4  Creating Memos, Reports and Data Files
	5  Manipulating Files
	6  Communicating with Other Users
	7  Getting Help
	8  Protecting Your Data
	9  Customizing Your Working Environment

   I have split out what _I_ consider to be workable modules on the
   simple basis of:

	a)  software engineering cohesion principles
	b)  software engineering coupling principles
	c)  less than 40 minutes lecture
	d)  maintainability
   

   a) COHESION in the context of a text module
   
   Cohesion is defined by Yourdon and Constantine as:
	"the degree of functional relatedness of processing elements
	 within a single module"

   (from "Structured Design - Fundamentals of a Discipline of
   Computer Program and Systems Design" by Edward Yourdon and
   Larry L. Constantine. Prentice-Hall Inc., Englewood Cliffs, N.J.
   1979)

   In terms of software it means a square root function does just that
   and no more.
   
   In terms of a text module we can understand cohesion to mean the
   singular purpose of a topic. For example the module "Logging In and
   Out of a VMS System". Currently the module includes:

	- logging in
	- logging out
	- logging in through a terminal server 
	- logging in remotely
	- locking a terminal session
	- changing a password
	- computer concepts

   Clearly this one is a maintenance headache. Logging in hasn't
   changed since c. 1978. There is an infinity of login messages so we
   can ignore those. Logging in needs a username and (usually) a
   password.
   
   Changing a password is only indirectly related to logging in. Sure
   one might have to change one's password to login.

   
   b) COUPLING in the context of a text module

   Coupling is defined by Yourdon and Constantine as:
	"a measure of the strength of interconnection between one
         module and another"

   In terms of software, closely coupled routines have effects on
   another. In maintaining one routine, a software engineer may find
   that one or more other routines now require change. Perhaps an
   argument type has changed or an argument has been added/removed or
   a data structure has been redefined. Loose coupling is preferred.

   This suggests that if we change, say, the materials on the
   command SET PASSWORD we affect the contents of a module talking
   about the SET PASSWORD /GENERATE command. That module relies on
   knowing the internal make-up of the SET PASSWORD topic.

   In other words we would have be aware of back and forward
   references. Do not make backward and forward references?
   Well we could do it by using techniques like "we already know how
   to set a password" rather than "in chapter 5 we saw how to set a
   password..." or "in figure 12-6 we saw how DCL....". In the latter
   case just show the picture _again_ !

   The "output" from "doing" a module is a tangible skill.
   
   c) The 40 minutes rule

   By limiting verbal presentations and demos to 40 minutes or less:

	- an audience is less likely to become bored
	- an audience is less like to lose concentration
   	- hands-on can be readily and regularly mixed with
	  talk 'n chalk
		
   This is more feasible with small, cohesive modules, loosely
   coupled. Small, cohesive modules, loosely coupled should also
   permit greater freedom of presentation. For example SET PASSWORD
   might come under the heading of Protecting Data. Isn't a password
   doing that in a sense?

   One habit I observe in myself attending lecture-based courses.
   When the instructor starts a new module I flip ahead through the
   pages to see what the last page number is. From that I can guess
   how long I'm going to be sitting waiting for my next
   coffee/exercise session! I've seen customers doing the same thing.

   If the last page number of a module is, for example, 7-4, _I_ feel
   more optimistic of a shorter, crisper session.

   With large modules I inform students that I'm going down to
   page x-y and then break for coffee and/or practical. Setting
   expectations like that is fine but one must stick to them.
   
   d) Maintenance

   This is obviously greatly eased by having small cohesive modules.
   We shouldn't have been maintaining a login module since 1978!
   The same might be said of the logout module and many more presented
   on the list of core topics.

   There are other benefits of small cohesive modules.

    1) easier to check and proof read
    2) easier to design and layout - how often have you
       wrestled with tables/text/figures to keep/get them on
       the page you wanted?
    3) can more readily be omitted from a customized course

   Here's how I cut up the existing nine core modules in to smaller,
   more cohesive modules.

   1. LOGGING IN AND OUT OF A VMS SYSTEM

    a) How the computer components are named and related
    b) How to log in to a VMS system
    c) How to log in to a VMS system through a terminal server
    d) How to set up multiple terminal sessions
    e) How to log in to a remote VMS system
    f) How to change your password
    g) How to lock a terminal session
    h) How to get VMS to generate a password for you
    i) How to log out of a VMS system

   Of these only topics a), b) and i) are needed on day 1

   2. ISSUING COMMANDS

    a) How to create a DCL command
    b) How to enter a DCL command
    c) How to use convenience features of DCL
    d) How to set your terminal
    e) How to edit DCL commands
    f) How to use control keys
    g) How to read system messages

   3. NAMING AND STORING FILES

    a) How to name a file on a VMS system
    b) How to use wildcards with files
    c) How to use directories
    d) How to use defaults with files
    e) How to list and find files

   4. CREATING MEMOS, REPORTS, AND DATA FILES

    a) How to start using the EVE editor
    b) How to interpret the EVE screen display
    c) How to enter EVE commands
    d) How to enter text in EVE
    e) How to replace text in EVE
    f) How to move around a document in EVE
    g) How to finish using EVE
    h) How to get help from EVE
    i) How to use some special features of EVE
   
   5. MANIPULATING FILES

    a) How to copy a file
    b) How to see what's in a file
    c) How to print a file
    d) How to rename a file
    e) How to remove a file
    f) How to remove old versions of a file

   6. COMMUNICATING WITH OTHER USERS
   
   
    a) How to use the MAIL command
    b) How to see what mail you have
    c) How to read a new mail message
    d) How to read an old mail message
    e) How to send a mail message
    f) How to forward a mail message
    g) How to reply to a mail message
    h) How to send a mail message to a list of users
    i) How to organize mail messages
    j) How to delete mail messages
    k) How to print mail messages
    l) How to put a message into a file
    m) How to use help in mail
    n) How to customize your mail facilities
   
   7. GETTING HELP

    a) How to use the HELP command
    b) How to put help text in a file
    c) How to use wildcards with HELP
    d) How to use VMS documentation

   8. PROTECTING YOUR DATA

    a) How to use basic file protection
    b) How to set default file protection
    c) How to see protection on files
    d) How to erase files
    e) How to check files are backed up

   9. CUSTOMIZING YOUR WORKING ENVIRONMENT

    a) How to use a logical name with a file
    b) How to use a logical name with MAIL
    c) How to see the definition of a logical name
    d) How to delete a logical name
    e) How to see what logical names the system provides
    f) How to use DCL symbols
    g) How to simplify commands with DCL symbols
    h) How to see what symbols you've defined
    i) How to remove symbols
    j) How to define keys
    k) How to see what keys are defined
    l) How to delete a key definition
    m) How to develop a command procedure
    n) How to develop a LOGIN.COM
    o) How to identify common errors in LOGIN.COM

   That's just over 70 modules - we could probably refine them
   further!
   
   The goal isn't quantity its maintainability.

   Of course this all couples cohesively with a minimalist approach to
   documentation. But that's another story!
    

Re: .10

Keith,

We have a problem of nomenclature here...

>   
>   In terms of a text module we can understand cohesion to mean the
>   singular purpose of a topic. For example the module "Logging In and
>   Out of a VMS System". Currently the module includes:
>
>        - logging in
>        - logging out
>        - logging in through a terminal server 
>        - logging in remotely
>        - locking a terminal session
>        - changing a password
>        - computer concepts


"Logging In and Out of a VMS System" is NOT a module - it's a Chapter! The
reason we've renamed the OLD 'modules' to 'chapters' is precisely to try to
avoid this confusion - didn't work obviously :-(

This CHAPTER is built from many smaller pieces which do exhibit the cohesion and
coupling you discuss - these can be called modules (although we currently
don't!)

So in this case: WYGINWYS (or possibly WYSINRWYS)

We'll be trying to make the underlying structure more visible as part of the
Modularity taskforce whenever I manage to get that off the ground.

OK?

Andy

    Andy,
    
    Thanks for your comments.
    
    Unfortunately the instructor guide for "VMS Skills for Users" shows both
    terms:
    
    Page 1-3: 	"This module..."
    
    Page 2-3a:	"This chapter..."  Page 2-3: "This module..."
    
    Page 3-3:   "This module..."
    
    mais la creme de la creme est:
    
    Page 4-3a  "...material in this module...you can go through the chapter..."
    
    Perhaps a cease fire? (of the Yugoslavian variety)  8-}  +  ;-)

    
    Let me jump in here...[grin]
    
    As to the mention of "module" in the course...that is a mistake...
    pure and simple. All references to the 'things' that we have nine of
    in "VMS Skills for Users" should be _chapter_ not module. Sorry...I
    really thought our editors caught them all! [egg on face]
    
    Second...Keith...the 'modules' that we are talking about maintaining
    are at a level at least three levels under the chapter level. Every
    head in the course is a separate 'module'. This allows us to update
    the five modules that comprise the changes in User information for
    V5.5 and 'push' a button to rebuild the course.
    
    For example, every code_example in the course is a separate 'module'
    as is every table...every figure...every list under a head. Each of
    these is maintained separately. And yes...we do have to maintain
    references to all modules that are related.
    
    Part of the reason that we have been dragging our feet to publicise
    some of this is because we need a user interface before we can expand
    the use of this beyond the handful of developers who have struggled
    with it in the last 18 months...at this point it is just too volatile
    to allow much usage. As we move forward with plans for an interface,
    we can be more proactive about the capabilities.
    
    Does any of this help...or am I just confusing the issue?
    
    Mel
    

    I would be very interested (as I am sure most others are!!!) in the
    ability to "push a button" and frankly don't expect it to be that
    simple.  If these documents have hot links for update, this sounds
    exactly like the right direction, and maybe it is time to toot your own
    horn. 
    
    Of course I would be thrilled to try it ASAP!!!~  
    
    irene

    
    Well, we don't have a prototype with live links yet, but that
    is where we are headed. Our first go-round will automate the
    process of searching electronic storage...fetching into a
    'profile' and building the little beasties...
    
    We have [thanks to Kristin Rounds] the basis for our utilities
    in place, and we have a plan [vision?]
    
    We [Bill Walker and I] will be in Toronto next week talking to
    instructos in Canada about this and the NEW VMS Curriculum...
    [Train the Trainer] and the documents from that will be posted
    by Nov 15. [Or, you could invite us to come to local theater?!? {grin}]
    
    Anyway...we are actively seeking input.
    
    I will see what I can do about suggesting some sort of forum...
    or [egad not another!] questionnaire ... or something to get
    out to instructors in areas where we are not scheduled or who
    have not seen any of this yet.
    
    Let me know what you would like to see? Here...or send mail...
    or carrier pidgeons...even paper airplanes happily accepted.
    
    Wishes [fast trains to Texas?] are OKOKOKOK! If you don't ask,
    we won't know what you want...you never know...we might be
    thinking that nobody wants what you want...and we might be able
    to say YES. PLEASE tell us what you need to better work with
    our materials...how you need to be able to shuffle contents
    for on-sites...whatever is important to you.
    
    We will work the technical issues and let Andy work the 
    business ones...Deal Andy?
    
    Thanks
    
    Mel
    

    re .15
    
    Thanks for responding - we are colliding!
    
    You are closer to my issue regarding customizing on-sites: one-time
    business doesn't afford the luxury of coming to Andy and requesting
    such custom handouts - the time turnaround and lack of special $$
    likely means this has to be possible AT THE INSTRUCTOR LEVEL.  LOCAL. 
    That's all I am trying to get across. 
    
    ih

>================================================================================
>Note 2.16                          MODULARITY                           16 of 16
>MELKOR::HENSLEY "ratbag in training"                 11 lines  23-OCT-1991 22:00
>--------------------------------------------------------------------------------
>             -< local mods have to be possible (maybe overnight) >-
>
>    re .15
>    
>    Thanks for responding - we are colliding!
>    
>    You are closer to my issue regarding customizing on-sites: one-time
>    business doesn't afford the luxury of coming to Andy and requesting
>    such custom handouts - the time turnaround and lack of special $$
>    likely means this has to be possible AT THE INSTRUCTOR LEVEL.  LOCAL. 
>    That's all I am trying to get across. 
>    
>    ih
>

    On the subject of modularity...  How about if the Instructor guides and
    student guides were posted in standalone chapters.  When I want to
    print a piece of an instructor guide, I have no way to do it and the
    entire document takes so long to print that you have others waiting for
    the printer and getting angry.  Also, when updates to the material come
    out, I like to replace just one module (Chapter) at a time and I don't
    really want to try to figure out where in the world I can put this
    great big instructor guide until I don't need it anymore.  Can you help
    out here by placing the chapters to the courses in individual files so
    we can print them out one at a time??
    
    							Raoul

    
    Ummm...
    
    Let me think...I know there must be reason why this sounds like
    a difficult idea...
    
    We can certainly cook the chapters separately...we can even set
    the chapter number so it will be correct. 
    
    I think the 'no' part of this answer is a business/political one.
    Andy? Is there a reason not to do this?
    
    I do think that if we were to do it...the separate chapters should be
    available through the Library/Warehouse...not from a public directory
    on SUPER...there would be too much chance of getting chapters that
    are out of synch with the rest of the development cycle...
    
    I am probably missing some big objection here....[grin]
    
    Mel
    

>    I think the 'no' part of this answer is a business/political one.
>    Andy? Is there a reason not to do this?


It sounds like a good idea to me - no reason not to do it that I can think of.

>    
>    I do think that if we were to do it...the separate chapters should be
>    available through the Library/Warehouse...not from a public directory
>    on SUPER...there would be too much chance of getting chapters that
>    are out of synch with the rest of the development cycle...
>    

I agree - let's build it into the plan.

Cheers,

Andy