| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 5.1 | Project Feedback | SUPER::REGNELL | Smile!--Payback is a MOTHER! | Wed Nov 28 1990 10:37 | 119 |
|
I think that the ideal situation concerning these basic VMS courses, would be
some kind of
pick-the-bits-I-need-for-this-course-and-get-it-all-printet-in-postscript
affair. I would love to start be able to login to a DW application, and pick the
subjects (in the correct level for the students) I need. Structure (sequence) it
as needed, and get it all out in postscript.
I think that all subject should exist in three levels:
LOW-END:
Just plain How-to-do stuff with some nice pics.
MID-END:
As low-end, but with added background-information.
HIGH-END:
All the tech information we can pack into it!
I may be in the situation, that most of the students come from the same company,
and I know that they are using communications a lot. So I would want to give the
a high-level lecture on comm. and mail, but low-level on programme-development.
And all this in a intro course!
The coursetitles you mentionen could be changed to:
General:
--------
VMS overview
Non-window VMS.
--------------
VMS for end-users
VMS for user service centers
VMS for future systems designers.
Window VMS.
--------------
VMS for end-users.
VMS for user service centers.
VMS for future systems designers.
This is could be the titles in the catalog ( you know we have to sell
something). All this could be based on a common "course-skeleton", where you add
the proper modules in correct level for your taget audience.
I would like the skeleton to be something like this.
DEC CONTEXT
HW/SW overview.
VMS overview.
network overview.
Lan-network
Interfaces in VMS
USING VMS.
Login
Security
DCL
Usercontext
Filesystem.
Filesecurity.
Networking.
Interaction with applications.
PROGRAMMING VMS.
EVE
COM proc.
Programm dev.
KOMMUNICATING IN VMS.
MAIL
network usage.
HOUSE KEEPING IN VMS
Tapes/discs
Queue handling.
This is in fact how my own U&C course looks today. This is a structure were you
very easilly can level on subjects without loosing the overall structure.
Maybe the best way to come up with a bag of subjects is to declare a
brainstorming session, to see what subjects we really miss todaw. Security,
networking are some of them. None of these are included in the couses as they
are today.
It would also enables us to do customer specific courses very easilly, and
thereby enable us to get higher customer satisfaction, and revenue too!
I think that we ought to prepare for at future structure in edu., where CBI will
be more important than it is today. I think the materials, should be adapted to
this.
Regarding Customization, then all the low-level stuff should be easilly
translatable into local language. I do not know what you mean with "LL format",
so pls. explain. I think that the material should be available in revisable
format somewhere somehow, in order to do local emergency surgery. Postscript is
nice, but not too easy to cut & paste in!
Well - this is it for now. Hope that I have not overwhelmed you.
Best
JOS.
|
| 5.2 | Project Feedback | SUPER::REGNELL | Smile!--Payback is a MOTHER! | Wed Nov 28 1990 10:38 | 153 |
| Hi Mel,
At first, I agree with the comments from Rob de Maat, that I
miss the overall curriculum view, especially for the operator
and the system manager. At this moment it is very difficult to
know if the skills in this courses are basic or not.
User Core Materials
===================
In figure 1 User Core Materials, what do you mean with the
words "Additional readings".
Course goals:
Describe the basic hardware of a VMS machine is for a novice
user not necessary to know and especially not on the first
day.
This is the same with the next course goal: "Describe the VMS
process. A novice user want to know how to work with the
machine, and not the technical theory behind it.
This is the same with the goal to describe the difference
between a layered product and the VMS operating system.
To perform a simple backup is for a novice user also not
necessary, because at this moment there are no users who will
make their own backups.
Add:
I miss a course goal in this user core material, namely:
"Communicate with other users and the system operator". This
skill is necessary for every user on the system.
The subjects Rob also mentioned, namely: basic security
aspects, terminal servers, using the terminal effectively.
Remarks:
It is very important to put a lot of lab exercises in this
user core materials, because a user will learn a VAX and VMS
by working with it.
Is it necessary at the moment to learn a new VAX user two
editors? I think that is important to learn a novice VAX user
only the EVE-editor. So put the EDT-editor in an apppendix as
optional stuff.
VMS User/User
=============
Figure 1: Components of USER/USER Course, what do you mean
with with the words "with readings", "from Adv. Comm Proc
project", "Advanced Command Procedures".
This course is for user who will not follow any other VMS
course, so it is an end course.
Course goals:
Same as the goals of the user core materials.
Remove the goals, basic hardware and software components, VMS
process, difference between layered product and operating
system, be able to specify devices and perform a simple
backup.
Add:
I think that it is very important for a user to print files.
So this also must be a course goal.
Remarks:
In the course nongoals you mention the advanced command
procedures techniques, but later on in the module descriptions
I see in the module Command Procedures the subject \s, CALL,
CASE, $STATUS, $SEVERITY, I/O Errors, ON, Error checking, File
I/O, Lexicals, Restarting and Synchronizing.
In the course goals you do not mention the module Program
Development, but in the module descrpition it is mentioned.
Please remove it from the module description, because it is
not a course goal for a user.
Creating a logical name table is much to far for a "novice
user".
Again it is very important to give the student enough lab
exercises to learn how to handle with DCL and the command
procedures.
VMS User/Programmer
===================
What is the reason of compressing the user core materials to
two days.
Course goals:
Same as the goals of the user core materials.
Add the goals: "Understand the VMS process" and "Printing
files".
Remove the goals: "Basic hardware and software components",
"Be able to specify devices", "Perform a simple backup".
VMS User/System Manager
=======================
Is this course to learn the student basic system manegement
skills or to be an experienced system manager.
Please, why don't we look to the German modularisation.
At first I have to know the curriculum view for the system
manager to give a right opinion.
I think it is not possible to put so much theory in one week.
Course goals:
Same as the goals of the user core materials.
Add the goal: "Create user accounts in the UAF (only with
ADDUSER.COM, but a better one as we have at the moment)
Remove the goals: "Monitor system management information", "A
knowledge of basic network manegement skills", "A knowledge
of basic cluster management skills".
Remarks:
Remove the next modules: "System Configuration", "Advanced VMS
Concepts", "Software available for VMS systems", "Software
maintenance", "Managing user processes", "Monitoring system
activity".
After this course it is necessary for a user to do some
experience with some system management tasks and come back for
the next skills, like writing advanced command procedures,
using the AUTHORIZE-utility, to knwo more of system
configurations, VMS concepts, managing user processes,
monitoring the system.
After this course and some experience with the new skills, to
come back to become a very experienced system manager.
Ed Janssen.
|
| 5.3 | Project Feedback | SUPER::REGNELL | Smile!--Payback is a MOTHER! | Wed Nov 28 1990 10:38 | 269 |
| EDITORIAL NOTE FROM THE MODERATOR:
Rob in this note and Ed and Keith in following notes are
replying to an initial brain-storming session that was sent
out to identified reviewers for this project. The original
premis called for CORE materials and four other courses.
Based on thier and other reviewers input,
that origianl pplan has been modified
The core materials still exist but not as a separate entity.
Their comments were very instrumental in the direction that
the new course plans took, however, so I have posted them for
general information and to get discussion moving.
(Mel)
Let me discuss the global context first. I have a number of
observations:
- I miss the overall curriculum view. Okay, so we are going to
modularise the user (i.e. U&C) course AND at the same time split
it up into four streams. What will happen at the next level for
say a programmer? Our concern is that in the past we have taken
the student and really stuffed him with U&C. It was only later
that we started wondering about tasks he had to do. Customers are
getting more and more critical and want to see results after a
first course. Those results should DIRECTLY relate to the job of
the person involved. If I am to comment on subjects being in the
right place and I see only the user level I'm in trouble.
- I am not sure how things relate to what Germany has been doing.
Are we re-inventing the wheel here? What do we think is WRONG with
the German modularisation? At least they have it working since a
couple of years, they should know the major pitfalls.
- Objectives of the courses are still contaminated with what
Digital thinks the student should know. To put it black and
white: if we want to have a maximum performance (in the
customer's point of view) curriculum, we should concentrate on
what the customer wants. To this we add what we think should be
known as well (from a didactical point of view) and that's it.
As an example: We define as an objective for the programmer
course that the student is able to DESCRIBE the file
specification on VMS. The customer who reads this and who has to
make a decision on whether or not to send someone on this course
will think that this is not necessary. Had it said "USE the file
specification effectively" it would have kept his interest.
Sidetrack: When the curriculum managers in Holland this year were
defining next year's catalog they tried to define the function of
the catalog and the course descriptions contained. They came to
the following conclusions:
1-There are two different groups of users. The first group is the
group who BOOKS the course, but does not necessarily understand
its contents, since the student will be someone else. The second
group is the student, who wants to know whether certain subjects
will be taught and to what extent.
2-People who book a course on behalf of someone else usually have
budget responsibility. They therefore want to know what the
benefit is when they book a student on this course. They care
less about whether Logical Name Tables are part of it or not.
What is directly visible is the Course price and the course
length (=days a student is not productive = $$$). This cost MUST
be made back through the benefits of the course.
3-People who want to FOLLOW a course very often need to convince
their boss he has to send them on a course. The course
description should give this person the rigth ammunition to fire
at the boss, since the boss's ammunition is the price and length
of the course.
4-The course descriptions should have the first half dedicated to
what the decision maker wants: benefits, objectives (measurable
results), course length etcerera. The second half should be
technical information: contents, prerequisites, follow-on
training etc.
The resulting course descriptions produced are very interesting.
Every description starts with a 2 or 3 line description of the
benefits of the course. Buzzwords are: effective, time-efficient,
optimise, short, interesting. Following is a set of objectives
which have little or no overlap with the contents description
further down. The remainder of the description is then as usual.
End sidetrack.
- Basically I find the course proposals too full. This is funny
since each time we discuss a tailored course with a customer he
usually wants to throw out about 2/3 of the subjects. There is
always the tension between what we want to do and what the
customer thinks is necessary. I think the basic courses should be
very lean. Let's be brave and build the skeleton and the organs
first. This compares to what a customer usually thinks is
necessary. Then we add the meat (mustles, brains and skin). This
corresponds to what we see as necessary.Then thecourse itself
when being delivered will bring this mass 'alive'. Talking about
Frankenstein!
- I miss a certain amount of stratification. Some subjects are
best taught in about three levels. Level one: overview, level
two: basic usage, level three: advanced usage. This gives a
concentric approach which makes it better from a didactical point
of view. In certain courses levels can be combined, while in
other courses certain subjects are better taught only at one
particular level, the next level in the next course.
Allright, let's now take the project plans one at a time and look
at some more details with the mentioned ideas in mind.
CORE MATERIALS
===================
I like the idea of having a core that everyone needs. I am not
sure the creature can live though. Let's see.
Course goals.
-------------
Describe the basic H/W of a VMS machine. CORE material? Really?
We get quite a number of computer illiterates here that have no
clue what is happening on the system and don't really care! Their
boss certainly doesn't want them to be trained to DESCRIBE a VMS
machine. Perhaps they want to understand some of the basics like
printer, disc, tape, network. That should be the objective. They
can do well without understanding memory, I/O etcetera.
Describe the VMS process. Same comments. This is not necessary
for the 'vanilla' user.
Use DCL to issue simple commands. Should be 'issue commands'. The
fact that they have to use DCL to issue commands is our problem
since we put DCL on the machine. I would rather drop this goal as
a whole and concentrate on what kind of commands they need.
Describe the difference between a layered product and the VMS
operating system. Oy, why would a 'vanilla' user want to know
this? A technical user will, the others certainly not. There are
other things besides LAYERED products, such as products! The
FORTRAN compiler is not a layered product, it is a complete
product.
Describe the file specification for a VMS system. No. USE the
file specification on VMS to get what you want. If I want someone
to describe the file system I am asking him to become an
instructor, god forbid ;-)
Add:
Use the terminal effectively. I mean ^y, ^T, ^C, Hold Screen,
keypad, setup etc.
Find their way through the documentation. Have you ever realised
the problem a novice VMS user is confronted with? It comes as a
10 feet row of grey binders called the documentation set. Things
like Master Index, Index, Guides, Subkits, Manuals, Volumes and
Reference versus Descriptive are never properly taught and are
assumed to be picked up on the way.
Basic Security Aspects. What happens if you leave your terminal
logged in in a public place etcetera.
Terminal Servers. How to use them to get to your target machine.
Break key. Multiple sessions. Locking the port.
Remove:
Perform a simple backup of personal files. I don't see the need
for this subject in the core materials.
USER/USER
I do not agree that the target audience should be "Novice VMS
users". It should be something like "Novice VMS users that will
only make limited use of the VMS system". Rotten definition, but
is shows what I mean. They are non-technical,
non-system_supportive, non-programming users that mess around
with files a bit and basically use the applications installed on
the system. They should be able to use VMS as a tool that
enhances the functionality of the applications on the machine.
They should be able to manipulate the products of the
applications they use, such as files and error messages. They
might also use some of the basic functionality of VMS such as
MAIL and on-line HELP. They will need proper guidance through the
complicated VMS environment since they will easily get lost. The
materials in this course should be VERY close to the CORE
materials, with additional stuff on helping them get rid of their
fear of VMS. I see this course as an end course in VMS training.
If the student is going to be trained further it will be on
application specific subjects.
Course Goals
============
Basic goals should be the same as in the core materials.
Add:
Understanding the roles of programmers, system managers and
operators on the system.
Remove:
None
USER/PROGRAMMER
Course Goals
============
Programmers that have taken this course should be able to start
their work in a VMS program development environment. Most goals
mentioned support that. The ones that I did not like in the core
materials I also do not like here, except for the process
(understand and not describe) and the layered products.
Also here in general avoid "Describe" as a skill.
Add something on making the programmer understand the impact of
running images, compiling on-line versus batch, making sensible
print commands (take size and time into consideration), the
librarian (basic level only).
Remove backup of personal files.
USER/OPERATOR
With this course and the System Manager course I have some more
difficulty since I cannot oversee the rest of the curriculum.
Things depend strongly on the follow-on training that will be
defined.
What I would like is a course of one week that in objectives
comes close to the current Operator course, but with a thorough
cleanup since that course tells too much about VMS.
The goals could also be taken from the survey conducted by
Corporate. I think that nicely describes what the customer thinks
an operator and system manager should do. We should stick to
that. Then if we think we REALLY have to tell them more subjects
or deeper we should add it to the course. Let's not try to think
of subjects first and then see if the customer wants them. This
course and the System Manager course are strongly task oriented.
People (managers and students alike) know very well what they
want.
USER/SYSTEM MANAGER
As said with the OPERATOR course it is difficult to judge this
without a proper curriculum.
In general a system manager having taken this course should be
able to understand the basics of system management: managing
users, queues and peripherals. If he comes back to his work place
he should be able to go along with an experienced System Manager
and understand what he is doing and learn from it. When he comes
back for his follow-on training he should have a thousand
questions on what he has experienced.
The distinction between various levels of depth of a certain
subject is probably needed here the most. Example: level
1-authorizing users concept, plus ADDUSER.COM. Level 2 - Using
Authorize basics. Level 3 - Special cases such as identifiers,
advanced security aspects ...
Rob de Maat
|
| 5.4 | Project feedback | SUPER::REGNELL | Smile!--Payback is a MOTHER! | Wed Nov 28 1990 10:38 | 131 |
|
Mel,
Thanks for the five project plans, duly copied and printed.
This is a first response, having read through all the plans
--------------------
USER MODULARITY - User Core Materials
On page 1 a diagram explaining the Project Terms would have been
useful there. One does pop up in the other project plans but I
didn't find them altogether clear. Sorry to be negative.
Titles - humm (Peanuts-like thinks bubble) - we changed from VMS
Utilities and Commands to VMS User (same 9764 materials) at V5 in
October 1988.
This one will be a hot one during - hopefully not after - the
project. Given the desire for skills-related training these days
I'm inclined to titles like:
- VMS Skills for Users
- VMS Skills for Systems Managers
- VMS Skills for Programmers
- VMS Skills for Operators
There, I've thrown down, if not a whole gauntlet, at least a
finger to get started.
In the problem statement section (1.3) the "[...readings]"
cropped up for the first time. This is indeed an interesting
innovation. Since I started in Edu waaaayy back in January 1984
I have considered additional outside-training-centre prep a
useful adjunct to our courses. I like this.
Andy Sadler would be disappointed if I didn't, at some point in
the discussion, mention an index! Not to be confused with the
table of contents at the front of a document. If the Programmer
and System Manager courses are to include "...further
readings..." in a TBI-like format, do student guides become rather
more than pure guides?
One of the useful things to aid learning/appreciation of DCL
could be a matrix showing, say, file commands down the left hand
column, qualifiers across the top and a tick in the body of the
matrix if that command has that qualifier. There now, I'm
rambling on into course design etc! We should think about using
graphical methods of getting messages across wherever possible
and new ways of presenting knowledge. (The DCL dictionary could,
I believe be a good deal more compact if, for example, the
/OUTPUT qualifier was stated in detail ONCE not ad nauseam).
In the list of topics/objectives I couldn't discern where
password setting and changing would be covered. Am I getting into
detail too soon? Presumably early on, during the logging in
session, there's a little time spent indoctrinating students on
security.
I'd like to see the forwarding of mail messages included in the
mail session, if possible.
There'll be some debate on where EDT sits. (I'm an LSE man but
still use EDT for a quick hack).
Devices might also include virtual devices, if you want to
thoroughly confuse the novice! Seriously, the terms physical,
logical and virtual come up elsewhere (RMS for example) that it
might be worthy of mention at this level.
--------------------
VMS USER/USER
Looking just at the topics here, I realised that DCL key definitions
weren't being covered at either Core level or at this level.
It is stated in the objectives on page 6.
I think Core Materials level should include base key definitions:
$ DEFINE /KEY "SHOW KEY/ALL" PF2 /TERMINATE
for example.
At VMS USER/USER level we might add GOLD, PINK and BLUE states
and so on.
Where does a LOGIN.COM discussion come? Simply at Core level then
the advanced stuff at this level?
--------------------
VMS USER/PROGRAMMER
Again, just looking at the topics.
We appear to have virtual address space twice. Haven't worked out
what the second one is all about.
Presumably concepts like the VAX Procedure Calling Standard get a
mention here even if they don't get into "%REF(Number)" sort of
detail.
(Cheeky but do we get the opportunity to sell the VAXset stuff
along the way in this module?)
--------------------
VMS USER/OPERATOR
I've never been an operator so admit lack of qualifications.
However, the coverage looks logical and wide.
--------------------
VMS USER/SYSTEM MANAGER
Is this built on the results of the System Manager/Network
Manager survey conducted end of calendar year 1989? It seems to
have some of the hallmarks of that survey's findings.
I didn't see security or privileges explicitly. Buried within
topics like "Defining the user environment" ?
That's my lot for the moment. Just to get the ball rolling from
here.
Regards,
Keith
|
| 5.5 | U & C II FOR EMPLOYEES | NEURON::FRANZ | | Tue Jan 29 1991 11:59 | 13 |
| In reading the ESDP_INSTRUCTOR_NOTES notes I came across the remark
that the new U & C II course was going to be a piece of cake to teach
because it is so well done.
It is my understanding that in "EMPLOYEE TRAINING" we do not have a
real U & C II course--folks go on to System Management or something
else after the U & C I class. Here in Colorado Springs there are
many folks that would like to learn more about Utilities and Commands.
Is there any way/idea-in-the-works for employee training to teach such
a course? It is my understanding that only "CUSTOMER TRAINING" teaches
U & C II. If the answer is that we DO have such a class, that would be
good news; just point me in the right direction.
|
| 5.6 | System Management Courses | SUPER::REGNELL | Smile!--Payback is a MOTHER! | Tue Jan 29 1991 20:39 | 25 |
|
Ummmm...
Well, there is no NEW U&C II...because there is no longer
a U&C I.
The new curriculum calls for potential system managers to take
a system management I-type course...which includes U&C information
and enough System Management stuff to get a novice started. That would be
followed by second system management course that would pick up on
VMS concepts and some more detailed system management training.
A third course would then go into more detail and would _probably_
[I am not being specific...just talking in generalities...] get into
the areas covered by U&C II.
This particular curriculum is still under discussion...so if you
want to get more detailed information and have a part in the
discussion, please send mail to:
SUPER::DUFFY
John Duffy...project leader for this group of courses.
Mel
|
| 5.7 | RE: U&C II for employees | SUPER::MATTHEWS | | Wed Jan 30 1991 11:28 | 14 |
| As far as getting the existing U&C II into the Customer Services
curriculum in the meantime... George Stanley is the VMS curriculum
manager for CS and would be the person to answer questions like this.
I forwarded .5 to Todd Nelson (VMS course development manager) and he
said he'd talk to George about making U&C II materials orderable under
a CS part number. It might help if your manager could let George know
there is demand for U&C II at your location.
We definitely need feedback on the new curriculum from CS trainers as
well as customer trainers folks, so please look over the new materials
and let us know what you think.
Val
|
| 5.8 | TITLES: Sys & Net Man courses | DUCK::SHONEK | | Wed Feb 27 1991 10:05 | 49 |
| Following yesterday's meeting here are some suggested titles for the
System and Network Management courses. Some may appear frivolous -
the aim is to fire the imagination of others participating in this
exercise.
Suggested titles stick steadfastly to placing "VMS" at the front. This,
I believe, is highly desirable, if only for consistency's sake! I've
avoided using the noun "VAX". The use of the word "skills" is an
attempt to get away from product training - i.e. just learning VMS.
I'm aiming at the new courses temporarily titled:
VMS System and Network Management * (where * = I, II, III or IV)
Blank lines in the list are purely to ease reading:
VMS Management for Single, Clustered and Networked Systems
VMS Management Skills for Single, Clustered and Networked Systems
VMS Management Skills for Single and Multiple Systems
VMS All-Systems Management Skills
VMS Skills for All-Systems Management
VMS Skills for Managers of Single and Multiple Systems
VMS Skills for Managers of Single, Clustered and Networked Systems
VMS Skills: Managing Single, Clustered and Networked Systems
VMS Skills: Management of Single and Multiple Systems
VMS Management Skills for All System Configurations
VMS System Management: Single and Multiple Configurations
VMS Management Skills in Standalone and Interconnected Environments
One thought occurs: could the titles be devised along the lines of
the VMS Internals courses? Each title containing a flavour of the topic
level for the course:
I VMS Skills - Managing All Configurations: Fundamentals
II VMS Skills - Managing All Configurations: Day-To-Day Tasks
III VMS Skills - Managing All Configurations: Solving Problems
IV VMS Skills - Managing All Configurations: Epilogue
And finally the Monty Python versions:
VMS SinCluNetMan
VMS Clueless Singlet Netting Manager
More later.
-- Keith
|
| 5.9 | More course title suggestions | MINNIE::SOWTON | City to City | Wed Apr 17 1991 10:56 | 20 |
|
More suggestions for titles...
Current: VMS for Programmers
Suggested: VMS Skills for Software Engineers
Current: VMS SYSNET I - IV
Suggested: VMS Skills for Technical Professionals I - IV
Current: VMS for Operators
Suggested: VMS Skills for Operators
Current: VMS for Application Users I - II
Suggested: VMS Skills for Application Users I - II
Cheers,
Bob
|
| 5.10 | TITLES: Application User I & II | DUCK::SHONEK | Keith Shone UK Edu 830-4074 | Fri May 24 1991 04:09 | 37 |
| Some suggestions for titles to replace those of VMS For Applications
Users I and II.
There's a bit of "belt & braces" about it in the sense that I've used a
I and II notation as a second set. This helps both customers and
Digital, I hope, to distinguish which really does come first if the
title doesn't make it plain.
Application User I:
VMS Skills: Getting Started With DCL and Files
VMS Skills: Introduction to DCL and Files
VMS Skills: Simple Commands and File Operations
VMS Skills: Everyday Tools and Commands
VMS Skills: The Essentials For Beginners
VMS Skills I: Getting Started with DCL and Files
VMS Skills I: Introduction to DCL and Files
VMS Skills I: Simple Commands and File Operations
VMS Skills I: Everyday Tools and Commands
VMS Skills I: The Essentials For Beginners
Application User II:
VMS Skills: Customizing The DCL Environment
VMS Skills: Building On Basic Skills
VMS Skills: Extending The Capabilities of DCL
VMS Skills: Greater Efficiency With DCL
VMS Skills: DCL Techniques, Tips and Hints
VMS Skills: Techniques For Time-Saving With DCL
VMS Skills II: Customizing The DCL Environment
VMS Skills II: Building On Basic Skills
VMS Skills II: Extending The Capabilities of DCL
VMS Skills II: Greater Efficiency With DCL
VMS Skills II: DCL Techniques, Tips and Hints
VMS Skills II: Techniques For Time-Saving With DCL
|
| 5.11 | And the winner is... | SUPER::MATTHEWS | | Tue Jul 23 1991 11:01 | 15 |
| The course we've been calling "VMS for Application Users I" is being
published as:
VMS Skills for Users
The course we've been calling "VMS for Application Users II" is on
hold. (The same topics, of course, also appear in the Sys/Net and
Programmer curricula.) The last thing Andy told us is to produce
a text-based version that will replace the existing "Advanced Command
Procedures" TBI.
The "VMS System and Network Management" I - II - III courses are being
published under that title.
Val
|
| 5.12 | VMS User, Oper, Prog - TTT results | MINNIE::SHONE | Keith Shone @RKA 830-4074 | Fri Sep 27 1991 06:54 | 736 |
| This topic gives feedback on a European train-the-trainer event
held here in Reading, UK on 24th and 25th September 1991.
A similar event will be held at Utrecht, Holland on 8/9 October.
Countries represented (with numbers present) were:
- Belgium (1)
- France (3)
- Hungary (1)
- Portugal (1)
- UK (3) (4 started)
The description of this course follows.
Course Number : EY-I991E-L0
Course Delivery : L/L
Duration : 2.00 days
VMS User Curriculum Restructuring Train-the Trainer
Target Audience
This European Train-the-Trainer (TTT) is for designated "key" VMS
instructors who will play a major role in their countries in
delivering the restructured VMS User-level curriculum.
Pre-Requisites
Participants must have sound experience of delivering one or more
of the following courses since VMS V4.0 :
1. Introduction to VMS
2. VMS User Skills
3. VMS User or VMS Utilities and Commands
4. VMS User (Accelerated) or VMS Utilities and Commands (Accelerated)
5. VMS Operator.
Participants must also have read the new course materials for the
three courses included in the new VMS User-level curriculum.
These materials will be supplied to participants at least two
weeks before the start of the TTT.
Objectives
On successful completion of the TTT, participants will be able
to:
1. Explain the restructured VMS User-level curriculum.
2. Understand how the restructured VMS User-level curriculum fits
with the new VMS System and Network Management curriculum.
3. Deliver courses in the VMS User-level curriculum from a skills,
rather than a product, point of view.
4. Implement restrained delivery of course topics.
5. Assist in transferring the above skills to less-experienced
instructors.
Overview
This Train-the-Trainer assumes that attendees will have read the
new course materials for the courses concerned. No new technical
material will be presented. It is assumed that attendees already
possess the technical knowledge to deliver these courses. Strict
control of what is delivered is vital to the success of the new
curriculum. Discussions of course topics will focus on this goal.
Another goal is to change attitudes to training users. Emphasis
will be on a skills approach to training using a "This is how
to..." style.
After completing this Train-the-Trainer, attendees will be
expected by their countries to aid the successful implementation
of the new VMS User-level Curriculum by helping other VMS
instructors to deliver the new courses using the skills approach.
Topics
1. Courses in the Restructured VMS User-level Curriculum
a. VMS Skills for Users
b. VMS Operator
c. VMS for Programmers
2. Topics Common to All User-Level Training
3. Self-Paced Alternatives in the New Curriculum
4. Correct Emphasis for the "Must Knows"
5. Building on Existing and New Skills
6. Eliminating "Might Knows"
7. Increasing the Ratio of Hands-On to Talk - the Forty Minutes Rule
8. "How To" Exercises
9. Problem Solving Exercises
10. Encouraging Exploration and Experimentation
[End of description]
The discussions on each day were as follows.
Day 1
The VMS Curriculum Restructuring Program Plan - dated
1-MAR-1991. Each attendee was given a copy.
European Implementation Plan for the New VMS Curriculum -
dated 17-JUL-1991. Each attendee was given a copy.
Curriculum maps (9 in all) dating from mid-August 1991.
Each attendee was given a copy.
All these items were reviewed reasonably quickly. Attendees
should have seen these materials, with the possible exception of
the curriculum maps, before the course started.
First session after lunch was to see the Corporate video
explaining the rationale for the changes. Although the video is
out of date it was useful for those who hadn't seen it to get the
message "straight from the horses' mouths". (Apologies for the
analogy, Andy and Emmalee.)
The remainder of day 1 was devoted to reviewing the core
topics - modules 1-8 - of VMS Skills for Users. Relevance, content
etc were considered rather than typographical or linguistic style.
(Remember, attendees were expected to have seen these materials
before arriving on the course.)
Day 2
Review of the final core topic - module 9.
The class was then split into two groups. One group considered the
materials specific to the course for Operators. The other group
considered the materials specific to the course for Programmers.
Mid afternoon day 2 each group presented its findings.
Bob Sowton (ECM VMS) was available for consultation for about
half an hour.
The course concluded with further discussions on a
task-orientated approach to the training. Keeping formal lecturing
to short bursts of 40 minutes or less; keeping to the spec for a
topic and not pre-empting further training in the curriculum.
Findings/Observations
Overall impressions first before we get down to nitty gritty
details.
We considered the weakest aspects of these three courses to be
- the exercises
- and the lack of task orientation
Strong point in these courses
- drawing attention to common errors
There are some good individual points that are highlighted at
detail level.
I have prepared a list of topics for the three courses.
This shows which topics belong where and any differences.
The exercise of adding the SysNet I topics to this list has raised
new issues about content and modularity. More later.
One list that stayed on a whiteboard for most of the two days was
the detail from page xxviii of the instructor guide for VMS Skills
for Users. This page provides a "Suggested Teaching Schedule".
The list below omits the course start up time of 45 minutes.
Times are in minutes
Topic Lecture Lab/exercises
1 90 30
2 75 30
3 60 60
4 60 45
5 100 45
6 90 45
7 20 15
8 90 60
9 120 60
Totals 705 390
That's a ratio of 35:65 labs to lecture. For a skills course this
should be 65:35 labs to lecture - or greater. How one spends 90
minutes doing logging in and logging out etc. and 30 minutes on
labs for that is - well let's say "interesting"!
The order of core topics needed some adjustments too.
Day 1
Logging In and Out of a VMS System - NOT the terminal
server stuff
Issuing Commands
Getting Help
Communicating with Other Users - down to the EXTRACT
command
Day 2
Communicating with Other Users - the rest
Logging In and Out of a VMS System - the terminal
server stuff
Naming and Storing Files
Creating Memos, Reports, and Data Files
Manipulating Files - excluding PRINT
Day 3
Manipulating Files - PRINT
Customizing Your Working Environment
Protecting Your Data
Some comments on that reordering.
There seemed no good reason why students shouldn't log in and log
out of the lab system before their first coffee break. Don't
confuse the issue with terminal server details at this stage.
Immediately following coffee another lab doing some SET PASSWORD
basics. (The business of setting a password might be left until
the topic Protecting Your Data - food for discussion there?)
Issuing Commands must come next to be followed by HELP.
The VMS HELP facilities are a largely untapped powerful
teaching/learning/training aid (aide?). Do the piece on HELP and
perhaps leave the bit about documentation for the class to read in
their own time.
To finish the day a short crisp session on VMS MAIL using strong
analogies with the non-computer world of paper mail.
The MAIL utility can be used to drive the labs/exercises on these
and many other courses. This is done by some instructors but it
could/should be more widely adopted.
(The lack of use of electronic mail amongst our customers is
surprising. The world isn't as close to the forefront of
technology as we think!)
Here in Reading all student accounts receive a mail message as
part of cleaning up systems each weekend. The message contains
information about the immediate building and its environment and
services. When students login they have at least this mail message
to read.
Day 2
Finish off the MAIL topics and terminal server stuff. Devote the
rest of the days lectures and labs to files excluding PRINT.
Day 3
PRINT followed by the two remaining topics - Customizing Your
Working Environment and Protecting Your Data. These can be in any
order. Since Customizing... is a fun topic (aren't they all?) get
this in early enough for students to enjoy themselves.
NITTY GRITTY DETAILS - VMS SKILLS FOR USERS
-------------------------------------------
LOGGING IN AND OUT OF A VMS SYSTEM
Instructors should be careful about encouraging too many incorrect
logins. Intrusion/break-in alarms may be enabled and result in
disabled account(s).
A note from the lady from Hungary about characters in usernames
and passwords including accented characters. This is not addressed
in the student guide and not mentioned in instructor notes.
Around about page 1-13 an example of a non-existent connection
would be useful.
Session locking was discussed in the context of forgotten
passwords and problems for the less experienced instructors here.
(I for one would have to seek help for a user who had forgotten
their session password).
NAMING AND STORING FILES
The example file names used in this module were thought
appropriate for the intended audience. Names including words like
report were considered a good feature.
Caution was suggested in the use of node names in file references.
Many default DECnet accounts will reject attempts to access their
User File Directory. Particular commands are, for example:
$ DIRECTORY MINNIE::
Page 3-15 of this module refers to setting default to a
non-existent directory. It was suggested that a way of restoring
ones default to an existing directory should be mentioned. For
example:
$ SET DEFAULT SYS$LOGIN
OK, we haven't done logical names yet but SYS$LOGIN doesn't have
to be introduced as such at this point. A useful back reference
when the logical names session is done.
A note about .DIR files and that they're not easily deleted was
thought appropriate in this module.
CREATING MEMOS, REPORTS, AND DATA FILES
One topic of discussion here. A suitable text file for practice at
using the features of a text editor might include editor
instructions. I explained this to the class and our colleague from
Portugal said he had already implemented such a file. We asked
that he posts it, or a pointer thereto, in this conference.
The idea, briefly, is that the file reads as a series of
instructions. "Try pressing PF3; now press keypad 0; now press the
up-arrow three times" and so on. The file could even contain a
simple keypad diagram accessible from a separate buffer etc.
Page 5-12 should include the /QUEUE qualifier if only because on
page 5-15 there's a reference to SHOW QUEUE.
There was discussion about distinguishing between execution and
generic queues. The discussion extended to whether the PRINT
command and its facilities should be in a separate module.
Lab exercise 3 for this module is about error messages and appears
misplaced.
COMMUNICATING WITH OTHER USERS
No mention of the useful DCL interface to MAIL:
$ MAIL /SUBJECT="Just a test for Corporate" NL: SHONE
$ MAIL /SUBJECT="This is the FORTRAN I mentioned" X.FOR SHONE
The first form I use regularly to remind me next morning of vital
jobs to be done.
Also a fairly general theme on utilities -
- show how to invoke the utility and also include, immediately
after that, how to get out of it
- again, early in the discussion should be the HELP topic for
the utility:
$ HELP MAIL
- general statement that ALL utilities have HELP, EXIT (or
control-Z). We weren't sure if QUIT and control-C
facilities were universal or consistent.
Concern was expressed about the absence of the COMPRESS command.
One might also include the PURGE/RECLAIM feature as well but
COMPRESS is particularly useful.
GETTING HELP
No mention is made of using:
- abbreviated forms - $ HELP SPEC
- wildcards - $ HELP SPEC *
- the /OUTPUT qualifier
On documentation it was felt that a note about layered product
documentation be included. If FORTRAN and Ada were installed, for
example, there would be documentation available about them.
PROTECTING YOUR DATA
No mention of the /SECURITY qualifier to the DIRECTORY command.
CUSTOMIZING YOUR WORKING ENVIRONMENT
We considered LOGIN.COM should appear early in this module.
Indeed, an early mail message to students might include a template
LOGIN.COM.
Some lively discussion on logical names.
Do we need to discuss DEFINE and ASSIGN?
Should we mention logical name tables and discuss the scope of
logical names? Some felt we should.
Page 9-22 - be careful with defining F6 through F14 - these keys
get involved in line-editing etc. (SET TERMINAL /NOLINE_EDITING?)
Keys E1 through E6 can be defined too (those six keys above the
cursor keys on VT200 series keyboards).
Page 9-31. Here it was felt a "standard" line should be included:
$ IF F$MODE() .EQS. "INTERACTIVE" THEN EXIT
The absence of this line can cause horrid problems when the
procedure is activated at the start of batch and network
processing.
Perhaps a cautionary note for instructors about redefining the
DELETE command. Causes irritating messages when defined thus:
$ DEL*ETE == "DELETE /CONFIRM"
and is used in a non-file context like:
$ DELETE /KEY ....
$ DELETE /ENTRY...
$ DELETE /FORM... and so on
NITTY GRITTY DETAILS - VMS FOR OPERATORS
----------------------------------------
NOTE: NO INSTRUCTOR GUIDES WERE AVAILABLE FOR THIS COURSE
General comment - the topic "Understanding the Hardware Environment"
should precede the topic "Understanding the Software Environment".
We thought process creation should precede a discussion on the
types of process.
Page 10-14 - a note about privileges needed to stop processes not
owned by the user issuing the command.
Page 10-19 - Bullet one - the value for the /NAME qualifier needs an
underscore or hyphen:
$ SET PROCESS process-name/NAME=character-string
Page 10-20 - bottom line refers to "concealed root directory"
without definition.
Page 10-21 - refers to CI nodes which is fine if we've done the
hardware BEFORE the software.
It's not obvious to the casual reader that SYSFFFF refers to a
hexadecimal value and not just an unusual file name.
UNDERSTANDING THE HARDWARE ENVIRONMENT
Page 11-7 - bullet two refers to RAM as read and write memory when
its actually Random Access Memory. There's plenty of ROM around
that is RAM too.
Page 11-11 - HSC's - be aware these devices have their own command
language.
STARTING UP AND SHUTTING DOWN THE SYSTEM
Page 12-9 - no mention of BREAK or AUTOBOOT
Page 12-11 - oh dear! a VAX-11/780!
Page 12-12 - a suggestion that the topics here should appear after
shut down. There are no examples of startup output
Page 12-15 - oh dear! a VAX-11/780!
Page 12-17 - oh dear! a VAX-11/780!
Page 12-20 - the heading "Steps to follow:" should be bolder and
not inset as it is.
WORKING WITH QUEUES
Page 13-6 - Bullets three and four were considered inappropriate
for operators.
Page 13-7 - bullet one - delete the words "either batch or print"
Page 13-15 - an awkward layout for this page
Page 13-16 - an awkward layout for this page
Page 13-33 - an awkward layout for this page. The last entry -
orderly shutdown of all queues might include /RESTART since this
was discussed already on page 13-6 (unless we remove that as
unsuitable for operators!)
Page 13-37 - should add the /STOCK qualifier and mention the
problems using /FORM and /STOCK in the exact specification of
strings.
Page 13-43 - this display is for the same instant as the display
on page 13-11 but their contents don't agree! Please change the
times in the headings or someone else will notice.
Page 13-46 - the /WSDEFAULT /WSQUOTA /WSEXTENT /DISABLE_SWAPPING
entry in the table - this was considered beyond the scope of an
operators usual job.
WORKING WITH DISK AND TAPE VOLUMES
Page 14-6 - where is DSA defined?
Page 14-22 - should standalone backup go here instead of
page 14-39?
MONITORING THE SYSTEM
Page 15-10 - is error logging part of an operators task list?
Special privileges are required to run, for example, the ELSE
routines.
The SHOW DEVICE command is useful to see which devices are
generating errors.
NITTY GRITTY DETAILS - VMS FOR PROGRAMMERS
------------------------------------------
Overall - too much time and detail on command procedures and too
little space and time devoted to program development.
On a positive note the labs on writing a command procedure develop
a quite sophisticated procedure by the end of the sequence.
This was a good feature of these labs.
However, the program development exercise was considered poor.
Why don't programmers deserve the basic concepts pages from the
first module?
CUSTOMIZING YOUR WORKING ENVIRONMENT
Page 9-19 - there's a typo on the penultimate line:
apply only o DCL command level
should read:
apply only to DCL command level
Why is this error here when the "master" copy in VMS Skills for
Users (page 9-22) is correct?
HANDLING INPUT AND OUTPUT IN A COMMAND PROCEDURE
Page 10-11 - in the example the second line is incorrect. It
appears thus:
OUTPUT ""
when it should be:
$ WRITE SYS$OUTPUT ""
Page 10-17 - flow control hasn't been done when example 10-8 is
shown. CLOSE isn't done until two pages later.
Page 10-19 - flow control hasn't been done when example 10-10 is
shown.
Page 10-21 - it would be useful to show an example of the
differences between /USER_MODE and the omission of this qualifier.
A common source of error is using/not using this qualifier when
invoking, say, a text editor from a command prcoedure.
MANIPULATING DATA IN COMMAND PROCEDURES
Page 11-9 - a third bullet should be added stating that lexical
functions return a value to the symbol on the left hand side of the
assignment.
Page 11-16 - apostrophes are used before they've been explained
in symbol substitution. Perhaps we should bring symbol
substitution forward.
The distinction between := :== and = == can't be over-emphasized
when it comes to overlays!
Pages 11-18 through 11-22 don't provide any examples.
The Appendix on lexical functions isn't followed up with any labs
on lexical functions.
USING SYMBOLS IN COMMAND PROCEDURES
Pages 12-5 through 12-7 largely repeat material covered elsewhere.
Page 12-6 - penultimate bullet - "Must use := or :== with strings
(local or global)" - is this a rule?
Page 12-8 - much of this material has been covered elsewhere.
Page 12-9 - paras 2, 3 and 4 should be using .EQS. not =
$ IF P1 .EQS. "" THEN...
$ IF P2 .EQS. "" THEN...
$ IF P3 .EQS. "" THEN...
IF hasn't been discussed at this point
Page 12-10 - should this go with page 12-8?
Page 12-15 - do we need this information earlier in the
discussions?
Page 12-17 - heading 2. bullet three - the one and only appearance
of the & operator and no examples of its use.
WRITING COMMAND PROCEDURES
Page 13-8 - some indentations for IF statements would give a
useful guide to layout.
Page 13-10 - the example under the heading "Output from this
command procedure" is confusing with a filename like GOTO.COM
Page 13-19 - we need a separate explanation of the SET MESSAGE
command.
DECIDING HOW TO RUN YOUR COMMAND PROCEDURE
Pages 14-5 through 14-10 discuss process types but we haven't
defined processes at this point.
Page 14-12 - needs an example of ATTACH too. (Recently I had a VMS
user who has been using VMS since V2.0. The guy hadn't heard of
ATTACH let alone used it!)
Page 14-13 - while this use of CTRL/Y is OK why not show a utility
like MAIL with its own SPAWN command instead of/as well?
ADVANCED VMS CONCEPTS
Much of this chapter was considered unhelpful and potentially
ratholed at this stage.
Given the developing discussion over VMS for Programmers II
we have deferred detailed discussions of module 15.
PROGRAM DEVELOPMENT OVERVIEW
Page 16-5 - was considered too brief.
Page 16-7 - heading 2. bullet 3 - the file extension is .OBJ not
.OBS. In the following LINK command CLIB.OPT is referred to but
not commented on. (Perhaps it is in the instrctor guide but we
didn't see instructor guides for this course). Nevertheless the
.OPT file should appear somewhere.
The sequence is:
$ CC ECHO
$ LINK ECHO, SYS$INPUT/OPTIONS
SYS$SHARE:VAXCRTL/SHARE ^Z
$
or:
$ TYPE CLIB.OPT
SYS$SHARE:VAXCRTL/SHARE
$
$ CC ECHO
$ LINK ECHO, CLIB/OPTIONS ! default extension is .OPT
$
Pages 16-9 and pages 16-12 through 16-13 were considered dangerous
and potential ratholes. Stronger language was used about the two
pages on RMS! The list of Run-Time Library facilities on page
16-10 is incomplete.
Page 16-15 - must include use of the logicals LNK$LIBRARY ->
LNK$LIBRARY_999.
Pages 16-17 through 16-21 were considered poor treatment of the
splendid VMS Debugger. Figure 16-2 on page 16-20 must be a true
debugger screen not a mock up.
[End of nitty gritty details]
CORE TOPICS - INCONSISTENCIES/DIFFERENCES
Earlier I mentioned that in listing the core topics for the
courses:
- VMS Skills for Users
- VMS for Operators
- VMS for Programmers
- SysNet I
there were some differences. For example "Logging In and Out
of a VMS System" is titled "Logging In To and Out of a VMS System"
for the SysNet I course.
Ordering of topics differs a little. Something even odder - at
least to me - operators and users get Computer Concepts but not
programmers or Sysnet I attendees. SysNet I will attract as
diverse an audience as any of the other courses. The computer
concepts piece just gets everyone together on the basics, quickly.
Programmers and SysNet I get a module element titled "Chapter Terms".
Programmers get SEARCH and DIFFERENCES. I use SEARCH daily.
(I've used SEARCH more than 10 times today already - once or twice on
this text.) I'm a programmer but I'm also a user! Many users would
relish details of a tool as useful and powerful as SEARCH.
I had thought that topics bearing the same title would have the
same contents. When the programmer course uses the title
"Organizing Files" for the user course topic "Naming and Storing
Files" I guessed they were different, and they are.
Many of the SysNet I course topics that are "core" topics have the
same names as the User course but ARE different.
I'm concerned about these inconsistencies/differences and their
implications for the successful modularization of materials.
I'll use an existing or new topic, as appropriate, to reply on my
thoughts/concerns on modularity.
|
| 5.13 | User TTT in Holland 8/9 Oct 1991 | MINNIE::SHONE | Keith Shone @RKA 830-4074 | Fri Oct 11 1991 08:31 | 198 |
| This topic gives feedback on a European train-the-trainer event
held in Nieuwegein, Holland on 8th and 9th October 1991.
Countries represented (with numbers present) were:
- Ireland (1)
- Spain (1)
- Norway (1)
- Holland (1)
- Italy (1)
These documents were presented:
- VMS Curriculum Restructuring Program Plan - dated
1-MAR-1991. Each attendee was given a copy.
- European Implementation Plan for the New VMS Curriculum -
dated 17-JUL-1991. Each attendee was given a copy.
- Curriculum maps (9 in all) dating from mid-August 1991.
Each attendee was given a copy.
- list of common and uncommon topics in the User
curriculum - user, operator, programmer and SysNet I
Big issues discussed were:
1) Modularity
2) Layout of course materials
3) Translation
4) Hardware requirements - operator course specifically
5) Exercises
MODULARITY
This _was_ a BIG issue.
A large number of countries need to translate materials. Those
countries don't want to translate the present modules only to find
the definition of a module changes.
Rob de Maat gave us some background to modules and the ideas
about "chunks".
There appear to be too many "chunks". We felt that a chunk should
be a deliverable entity - have a heading. Present chunks are too
small and present modules are too large!
The bill of orderable materials should be able to specify modules.
Some countries have too few customers for running VMS for
Programmers as a standalone course. Those countries would need a
mix of modules not unlike the present Utilities & Commands.
Modularity must be sorted soon. Some countries will implement late
if uncertainty about what is/is not a module presists.
LAYOUT OF COURSE MATERIALS
Information Mapping was mentioned and left.
We wouldn welcome a new format, given suitable open
discussion.
One idea suggested was a two column style using icons in lieu of
headings:
+-----------------+-------------------------------+
| ICON | Text |
| | |
| | |
| | |
| | |
| ICON | Text |
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
| ICON | Text |
| | |
| | |
+-----------------+-------------------------------+
Icons would represent HELP, hints, tips, further reading, when
things go wrong and so on.
We did discuss a minimalist approach, cutting out:
- introductions
- objectives
- topics
- references
- summaries
This approach found favour because translation would be easier and
quicker. Students would also get to the meat of the discussion
quicker. A topic like logging in to VMS would take only about one
page. More about minimalism in another topic.
TRANSLATION
This was a BIG issue.
Some of us took this for granted and were taken aback when we
discovered that EY-9764S didn't mean the materials were in
Spanish, for example, or EY-9764N weren't the Norwegian
translations! Indeed several countries deliver American course
materials despite having a local non-English language. One country
will have to translate for one big customer or they'll loose the
job. The ability to translate should be a local choice.
One side issue of modularity and translation. The UK has to
deliver a tailored course to, say, an oil rig in the North Sea.
There are English and Norwegian engineers on the rig. It would be
quite reasonable to expect to supply English AND Norwegian modules
side by side. Wouldn't it? If the customer asks for that mix the
customer must be right? The UK would need access to Norwegian
equivalent modules.
(Remember the open European market. Remember Poland,
Czechoslovakia, Hungary, USSR will be asking for all sorts of
different combinations of language. Remember from where a lot of revenue
comes :-) )
HARDWARE REQUIREMENTS
The operators course needs access to hardware when needed.
Jan Vink showed us an excellent configuration for operators to try
out BACKUP. This comprised:
- MicroVAX 2000
- keyboard
- VDU
- LA75
These VAX systems - there were about six in the set up we saw -
were ideal for operators to work on. Unfortunately there is
maintenance to pay on the systems. That adds to the cost of
providing an ideal solution to the problem. Also it was suggested
that, in asking for redundant hardware - for example MicroVAX 2000
- we need to be careful we don't get off-loaded with VT100s to
accompany them!
Jan showed us other configurations used for doing BACKUP and other
practical operator/system manager tasks.
EXERCISES
These could/should be case orientated.
We don't need exercises on logging in or logging out but we do
need exercises on practical every-day tasks.
It was clear that most countries will do their own thing in this
area. This is plainly a waste of effort and modular course
exercises are a must.
Exercises are better as a separate book. This avoids students
having to keep fingers in pages, flipping back and forth between
course text and exercise text.
EPILOGUE
The term "small country" began to offend by the end of day 1.
I considered that the English speaking countries were displaying a
certain arrogance towards non-English "small countries".
A lot of revenue comes from non-English speaking countries, small
and large.
Can we please use another term for "small country" it _is_
offensive.
While some countries contribute more or less than others if we
"look after the pennies the Pounds/Dollars will look after
themselves". In other words "every little helps". Remember
Poland, Czechoslovakia, Hungary, USSR will be small contributors
at first. Lets not start belittling them with "small country"
tags.
If we must refer to a translation requirement/need lets call it a
need to internationalize. It isn't an issue; we've got to do it!
THANKS
Finally, my thanks to Jan Vink and Rob de Maat for their help and
valuable contributions to the proceedings. Both have busy
schedules and their presence was an asset. Rob could only be
present intermittently but he filled in some of the missing
pieces. Thanks Jan and Rob.
|
| 5.14 | | SIOG::EGRI | | Tue Oct 15 1991 12:28 | 50 |
| Hi, my name is Ted Egri and I was the attendee from Ireland on the TTT
course held in Utrecht.
Just a couple of things to reinforce some of Keith points in the
previous note.
I went throught the three "restructured" courses and saw little that
was "restructured". As far as I'm concerned the courses are much the
same in content with a slight change in layout. I did like the addition
of "things that could go wrong" at the end of each "module".
Looks to me like we are still going to be shipped set courses and that
we have no input into the modules we want and the order in which wee
want them packaged. I often have to teach customized versions of the
set courses, which means I need the facility to pull out specific
modules and then teach them in the order "THE CUSTOMER WANTS THEM TO BE
TAUGHT". I'm not yelling, I'm emphasizing.
I have had to chop and photocopy and Tipp-ex and collate so many times
in the past to produce a course that met the customers requirements. I
saw this restructuring of the curriculum as an end to this. I have to
argument with "default course materials". That is a predefined set of
course modules in a predefine sequence, which is shipped to the
training centre if an alternative has not been specified. But I had
hoped that the modules would have been in some kind of central database
and we could them send details of the specific modules we wanted,
ordered in a sequence appropriate to the wants and needs of the
customers. Or failing that, specific modules put together in a sequence
defined by the instructor since they are the ones who deal with the
materials on a day-to-day basis. Instructors in different countries may
feel their audience would understand the concepts better if the modules
were taught in a different sequence. There's no better way to turn-off
the people you're trying to teach than having them spend 5 days hopping
around the student guide.
I was amazed to hear my colleagues, from non-English speaking
countries, say that they taught the course in their own language with
totally English materials. I just took it for granted that every course
was produced in the language of the country in which it was being
taught unless it was specifically requested that the course be taught
in English.
The restructuring idea is great but from what I heard we don't have the
modularity sorted out yet.
If I can help in any way, I would be more than happy to do so.
Ted Egri (Dublin)
|
| 5.15 | Sorry...it got a bit long... | SUPER::REGNELL | Modularity Maven | Fri Oct 18 1991 22:17 | 102 |
|
First, thanks for the comments! And second, I will take any and
all help offered! [grin]
Third, let me try and share some of the current doings with
'modularity'.
* The term has got to go. Modularity is really not what we
are after or about. It was a great phase 1 goal and we
achieved it...but what we need to head for is reusability
and modular information.
* We need you folks to understand that what you are looking
at in the new courses is the first phase of an incredably
huge undertaking. First phase goals included identifying and
cutting redundancy from over 7000 individual chunked 'object
modules' of information; proving we could really rebuild all the
little beasties back into a course; writing utilities from the
ground up to automate the process; identifying tasks that we
could at least group information under; and delivering courses
somtime before June of 2001. All this done in bits and pieces
by several developers under the gun.
This is not a plea for leniancy...it is a statement of fact.
What you are looking at is the first go-round.
* Modularity. You will be happy to learn that the current
state of definition does exactly what you suggested...it
lands between chapter and chunk. Currently it looks like we
will settle on what amounts to a head and all realted
information for that head as a 'module'. The term actually
being tried on for size is "reusable modular component" RMC.
*Which brings me to reusability. Modularity was never the
end goal of this. Reusability and all the implications that
implies was and is the goal. Modularity was a procedure that
we had to proove we could successfully implement before we
could rip all our courses apart. [grin]
Reusability speaks to modules being orderable from a catalogue;
customization through a user interface into and electronic library
of 'modules'; translation by module so that once a course is
translated once, update need only translate the touched modules...
potential savings of near to 90% on translation costs once
implemented.
* Labs. I vote that all labs be developed by instructors and
stored in the electronic library and world-wide instructors
can build their own labs for any delivery. No, I am not
joking. The best labs I have seen are the ones that Fred Apon
wrote for me for SYSMAN II and I firmly believe that you folks
have a better line into what will and won't work...and what
customers want to see than any developer ever will. You are
preaching to the choir on this one with me...[grin]
* Implementation. I need to say something here. The courses
you are seeing have _capabilities_ to be modularized. They
are not being delivered as modular componants; they are not
being advertized as breakable at the delivery level [breakable =
modular]...they are being advertized as _capabale_. I do not
think the field will see the implementation of 'modularity'
or modular information for some time [Andy...do you want to
guess?]. Why? Because first of all we haven't the resources
to build all the utilities and interfaces that need to be
in place in less time than that...second, we _do_ need to
agree to settle on what modular information is going to mean
to courseware and we are close I think to approaching that...
but not there yet...third, we need to make sure that we haven't
broken anything in this go-round before we make further changes.
We have really made very intrusive changes in how we developed,
published, and delivered these courses...and I agree that
much of that may be invisible to you...but it was traumatic
for us! [grin] We need to consider how we implement the next
stages and we need your input for those deicisions.
Andy...we need you to get the task force you are talking
about moving...please.
* Course outlines. Are probably out of date. If you had
seen current ones, you would have noticed that the order
and content of some of the information in chapters was different
in...for example...SYSNET I and USER. That might have indicated
to you that 'chapter' was not equal to module. Keep in mind that
we were still piloting some of these courses when you were
looking at them...still making changes.
Have I bored everyone to death yet?
We need instructors to be involved with the issues that we are
facing in this on-going effort. Please continue to question,
comment, make suggestions and offer advice! I will try to be much
better at keeping a running commentary in here going about what
is going on at this end.
Meanwhile...I have to go back to writing the TBIs!
Thanks
Mel
|
| 5.16 | from the field .. | MELKOR::HENSLEY | ratbag in training | Mon Oct 21 1991 21:13 | 16 |
| Please help the instructors who want to be involved by funding review
and participation. Otherwise, our time is scheduled as delivery and we
cannot provide the time and quality feedback you want and we wish to
give.
The prevailing question (and one of mis-expecations perhaps) has been
"what modular course? where/how/when can I choose/bookbuild a custom
course from a workstation?" The ability to provide high quality
content and polished looking materials for custom courses is still
missing. Our materials "look and feel" is rough when we have to "cut
and paste" and whether we provide substance is lost in a world where
everyone is a desktop publisher!
my pence.
ih
|
| 5.17 | from the ivory tower :-( | ESMAIL::SADLER | Change for a Flainian Pobble Bead? | Tue Oct 22 1991 21:04 | 58 |
| Re: .16
> Please help the instructors who want to be involved by funding review
> and participation. Otherwise, our time is scheduled as delivery and we
> cannot provide the time and quality feedback you want and we wish to
> give.
>
It's a while since this was raised so here's my reply again...
While I understand the pressures in the field on 'non-platform' time, ( having
been an instructor, a unit manager, and business manager in the Reading Training
Centre) and realising that funding of review would ease this pressure
significantly, the reality of the situation is that my investment budget has
continued to decrease year-on-year and in the current climate there's no
possibility of this changing. Given that, the only way I could fund review would
be to do less maintenance or development.
What should I not do?
Some options:
No updates for V5.5 and Vx.y
No Open VMS courses
No Self-PAced courses
> The prevailing question (and one of mis-expecations perhaps) has been
> "what modular course? where/how/when can I choose/bookbuild a custom
> course from a workstation?" The ability to provide high quality
> content and polished looking materials for custom courses is still
> missing. Our materials "look and feel" is rough when we have to "cut
> and paste" and whether we provide substance is lost in a world where
> everyone is a desktop publisher!
>
We have the ability to custom build courses at the chapter level today, and have
had for the last 2 years. We've done a number of custom handouts over this
period and some of the T/Cs have done similar work themselves.
What we're doing is to change the level of re-usability and granularity WITHIN
the materials. This is not very visible in the final materials - nor should it
be so if we're doing things right!
We're in the process of planning how we transfer the new technology to the field
and will be kicking off a task force to finalise the process within 2 weeks.
Roger Towne and Sherry Butler have benn nominated as the US Area reps on the
team - please make sure they understand your needs.
A question - why " from a workstation"? We're still using VAX DOCUMENT for all
development and will continue to do so at least in the short term, workstations
are not required.
Cheers,
Andy
|
| 5.18 | from the [wheat]field | MELKOR::HENSLEY | ratbag in training | Wed Oct 23 1991 22:55 | 12 |
| Andy,
Thanks for your reply. Last question first: VAX DOCUMENT or another
tool will work - not being familiar with the tools in use I probably
was hoping a viewable psotscript type of facility was near.
We realize that your budget doesn't leave much room for trades. None of
the Training Centers are in much better a position, and we can't turn
down business for a dedicated week or more of review. But "from the
field" isn't any easier now than the last time we had this discussion.
my .02
|
| 5.19 | | NITTY::DIERCKS | Just being is not flaunting! (stolen!) | Fri Oct 25 1991 09:13 | 12 |
|
You want us to review.
We want to be reviewers.
I want to have a life outside of Digital. I'm only willing to give
"just so much". Lately, new courses and platform time have taken
precedence. I realize and understand business issues here, I think.
But, in my way of thinking, until course development comes up with some
cash for funded review time I doubt you'll get the level of instructor
involvement you really desire. Isn't it really that simple?
|
| 5.20 | Flame Alert! Flame Alert! | SWAM1::STERN_TO | Have TK; Will Travel | Tue Oct 29 1991 16:31 | 44 |
| Andy,
We recognize the problems of smaller budgets (all of us are being
told to "row harder"), but at the same time we are in a vicious circle.
1. The material needs to be reviewed before it goes to print. The
instructors need to have time to provide feedback in order for it
to be reviewed.
2. Management wants instructors to teach, thereby earning their keep,
but this removes our time to review.
3. The books end up being finished without proper reviews.
4. The instructors see the books only when they are finished products,
at which time, no matter how horrible (or wonderful) we think they
are, we finally HAVE to give up our evenings in order to prepare
for them; and THEN we start finding the faults they may have.
5. Finding the faults (and being responsible for the entire QA,
including the book), we simultaneously start working around the
weak points and sending off the comments about the books.
6. We also, simultaneously get back comments telling us that the
review period is over, and how can the books be bad when the QA's
don't say so (The fact that we have to tapdance to save ourselves
is another question)?
This week, the pilot of SYSNET I is being taught at our facility (LQO),
and at this point watching a class that has 3.5 days of materials from
U&C I and 3.5 days of material from SYSMAN I, and trying to figure out
how I am going to teach it in a 5-day Lecture lab, I have to put my
concern about the dwindling budgets development may have been given
aside and start worrying more about how I can deliver a quality course
with the materials given.
To be honest, I don't think this course can do it. We either have
to cut out material like crazy, and lose from not covering all of the
stuff, or we have to cut labs, and lose from delivering too much
lecture. If anyone can look at the material and see something other
than a loss, please call me.
tom
|