| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 116.1 | UK first pass - some thoughts | MINNIE::SHONE | Keith Shone @RKA 830-4074 | Tue Aug 27 1991 07:04 | 177 |
| This is a first pass - that means I may change my mind later on ;-)
The topics would appear more interesting if they had titles like:
How to use VMS Help from a program
How to call a system service
How to share code and data
and so on...
(We should also be aware of the "Why should I use...from a
program" questions.)
Why isn't there a topic on the Message utility?
If users wish to produce software that has the feel of VMS - for
example, using the CDU - they will probably wish to use the modularity
of the Message utility.
Presumably issues of performance are relegated to VMS System
Performance Management training?
There doesn't appear to be much time available for hands-on work.
Good quality coded examples will help here.
Some topic-by-topic comments:
Chapter 1:
Is this a quick half hour session to revise what we should know
from Programmer I? Does it include DECset in the discussion on tools?
Chapter 2:
Will this chapter demonstrate a call from each of the main classes
of routine - SYS$, LIB$, MTH$, OTS$ etc. ?
Chapter 3:
I don't like this topic being in here. We have a Corporate 5-day
course on RMS. Won't students know about files, records and fields by
this stage? Granted a review is desirable but how far would the RMS
utilities session go. I used to spend an afternoon on RMS during the
Utilizing VMS Features course. An afternoon for one topic in a three-day
course is a non-starter for me. Just a simple demo of EDIT/FDL kills
half an hour :-}
Chapter 4:
Again, my concern is how far we go here. Is it the old
Communicating Between Processes topic?.
Chapter 5:
I don't think we need to distinguish between system services and
RMS services - VAX LSE doesn't. Indeed I wonder if we should
categorize routines this way at all. How about adopting a functional
division:
o date and time functions
o process manipulation routines
o process communication routines
o maths functions
o synchronization facilities
o text editor routines
o screen manipulation routines
and so on without creating monolithic chapters on major headings
like communication, synchronization and so on.
Then, for example, LIB$DATE_TIME could be included in a discussion
with SYS$NUMTIM, SYS$GETTIM and so on. One question I am asked
frequently is "...when should I use a SYS$ and when should I choose a
LIB$..."? A standard response went along the lines of "...if the LIB$
provides the answer you want then use it. If the extra programming
effort isn't critical then use a SYS$. The latter often presents greater
opportunities to get it wrong when it comes to passing mechanisms!"
If we wish to adopt a skills approach to lecture-based training
then topics like "How to get the date out of VMS" or "How to pass
information to another process" are what programmers want to know.
Not "Here's a system service that creates a process" then half an hour
later also tell them about LIB$SPAWN because its in the LIB$ session!
If the student materials are partitioned by SYS$ and LIB$ etc., then
it will be difficult, if not impossible, for instructors to use a
functional approach.
Chapter 6:
Good to see this in. I used to do this on the Friday of the
Utilizing course although it wasn't in the UK spec for delivery.
Always went down well because students hadn't realised how easy and
powerful it was.
Chapter 7:
As for Chapter 6
Chapter 8:
These topics look suspiciously vague! Are we to discuss the use of
four-byte arguments and function return values? When to use a procedure
and when to use a function? Will the discussion be in terms of
generic structured analysis, design and programming tools?
Chapter 9:
This a language-specific topic and shouldn't be in here! All the
topics hitherto are manageable by a large number of existing Utilizing
VMS Features instructors. Having VAXTPU-specific material in this
generic course will push the demand for prep time. (I wouldn't expect
official prep for a course with chapters 1-8 in it).
My course list of modules, with _tentative_ subtopics, in delivery order,
would be:
o How to Develop Software on VMS - revision
- compiling, linking and running
- use of logical names (e.g. LNK$LIBRARY)
- object libraries
- debugging
- bundled and layered tools
o How to Call Software Written in Other Languages
- VMS procedure calling standard
- examples of calling LIB$, SYS$ etc. routines
o How VMS System Software is Organized
- System Services
- Run-Time Library - this includes:
o DNS$, DTK$, LIB$, MTH$, OTS$, PPL$, SMG$, STR$ as well
as the existence of BAS$, FOR$, PAS$ etc.
- functional groupings - time, process, data sharing etc.
- using VMS Help for details on routines
o How to Make the Best Use of VMS Modularity
- modular programming standard
- characteristics of procedures and functions
o How to Turn a Program into a DCL Command
- the Command Definition Utility
- creating a DCL definition
- using DCL routines from user-written software
o How to Use Application-Specific Help with User-Written Software
- creating Help text
- creating a Help library
- using logical names with Help libraries
- getting user-written help from a Help library
o How to Use DCL-Like Messages from User-Written Software
- using the Message utility
- writing a message file
- using a compiled message file and its contents with
user-written software
o How to Share Data and Code
- using libraries
- data charing techniques
- sharing executable code
It's probably not difficult to write an application of a few thousand
lines that combines several of these features:
o DCL
o HELP
o MESSAGE Utility
o shared data
One that comes to mind and that would be a useful application is a
calendar program I used, to demonstrate the first three in this list.
The sort of thing a user could do from DCL was:
$ DATE /WEEK=NEXT
.
.
$ DATE /DAYS_BETWEEN TODAY 25-DEC-1991
.
.
$ DATE /HELP
Suitable user-defined error messages were emitted when parameters were
wrong etc.
That's my immediate 2 cents worth.
I'll give all the help and support I can to the successful
implementation of this course.
Thank you for giving me the opportunity to comment on your proposals.
-- Keith
|
| 116.2 | Revised topic outline | SUPER::ROUNDS | Kristin Rounds, DTN 381-1066 | Fri Sep 13 1991 16:12 | 137 |
| The following is a revised topic outline for the course. It supersedes
the one posted in note 116.0.
Please post your comments by Friday, September 20.
Thanks...
Kristin
VMS FOR PROGRAMMERS II
Purpose of The purpose of this course is three-fold:
this course
- To teach programmers how to use the most commonly used
software development features of the VMS operating system.
- To provide an awareness of the tools and system routines
that can be used to develop applications on a VMS system.
- To provide information that will help programmers to decide
which tools are appropriate for a project.
Topic list The following major topics have been identified:
- Developing software in a VMS environment
- VMS system routines and callable utilities
- Calling procedures
- Using the features of the command language interpreter
- Providing application-specific help
- Overview of other tools for programmers (need snappier title)
DEVELOPING SOFTWARE IN A VMS ENVIRONMENT
Purpose of Review program development steps, show ways to use the Linker,
this chapter present the concept of a library and show how to use an object
library, describe the use of shareable images, and teach
fundamentals of using the VAX Debugger.
Chapter topics The following topics have been identified for this chapter:
- Review of program development steps: compile, link, run
- How to use object libraries
. Linking multiple objects
. Linking against an object library (what is a library?)
. Using logical names to refer to object libraries
. Creating and manipulating an object library
- Creating modules (determining what should be a module)
- Using shareable images
. What is a shareable image
. Shareable image libraries
(What they are, creating, linking against)
. Linker options files
. Using the Install utility
- Using the VAX Debugger
. Get in and out
. Set up environment (windows, display, etc.)
. Get help
. Observe and control execution
. Examine and change variables
VMS SYSTEM ROUTINES AND CALLABLE UTILITIES
Purpose of Present the concept of system service and run-time library
this chapter routines, describe the functional groupings of these
routines, and explain how to decide what to use when more
than one routine will perform a particular function.
Chapter topics The following topics have been identified for this chapter:
- Overview of system routines (system service and run-time library routine)
- Functions performed by system routines (date/time, communication, etc.)
- Callable utilities
(Present VMS concepts as needed)
CALLING PROCEDURES
Purpose of Teach the student the procedure for calling the system
this chapter routines described in the previous chapter.
Chapter topics The following topics have been identified for this chapter:
- Passing arguments to a system routine
. Passing mechanisms
. How to determine what mechanism is required
. How you should document your procedures so others will know
what mechanisms to use in passing arguments to them
- How to use the status value returned by a system routine
(service-specific versus service-independent)
Idea for written exercise: give sample(s) from our
documentation and ask questions about them.
USING THE FEATURES OF THE COMMAND LANGUAGE INTERPRETER
Purpose of Teach students how to have DCL process input for a program
this chapter so the program doesn't have to prompt for values and check
their validity.
Chapter topics The following topics have been identified for this chapter:
- Creating a command definition file
- Coding an image to be invoked by the command
- Adding the command to the DCL table
PROVIDING APPLICATION-SPECIFIC HELP
Purpose of Teach students how to set up an application-specific help
this chapter library and code programs to access it.
Chapter topics The following topics have been identified for this chapter:
- Creating a help text file
- Creating and manipulating a help library
- How programs can retrieve information from a help library
- Using logical names with help libraries
OVERVIEW OF OTHER TOOLS FOR PROGRAMMERS
Purpose of Give an overview of bundled tools and layered products
this chapter that programmers may use in developing applications, and
provide information to help decide which tools to use with
a particular project.
Chapter topics The following topics have been identified for this chapter:
- Definitions: "bundled" versus "layered"
- General categories of tools, with comparisons of tools in
each grouping
VAXset, TPU programming (what can be done, not how to do it)
and EDIT/FDL (ditto).
|
| 116.3 | Programmer II | DLO10::TARLING | | Mon Sep 16 1991 10:40 | 15 |
|
Kristin;
Some originations regarding the "Programmer II"
> VAXset, TPU programming (what can be done, not how to do it)
> and EDIT/FDL (ditto).
I believe that students would prefer "how to do it", as opposed to
"what can be done". Leave TPU, and EDIT/FDL out or include some
basic examples. Also EDIT/FDL is already in the RMS course.
All things considered, it looks pretty good.
Arnold.
|
| 116.4 | some questions/comments | TEACH::SHERRY | Sherry Butler - DTN 341-6330 | Mon Sep 16 1991 15:10 | 29 |
| Here is message I recieved from one of our instructors.
Looking at the 3 day outline for VMS for Programmers 2,
I have the following comments and questions:
- How do these topics fit in with the Utilizing
class? Many are overlaps.
- What is the depth of coverage on each topic?
- Will there be examples and labs in any language?
Which, and how will the instructor cope with
mixed language students?
- Detailed debugger information belongs in Programmer 1.
- Does module 8 attempt to teach programming
design theory? I don't think this is suitable.
- Most of my students use LSE. Is module 9 going
to apply?
Other than CDU, TPU and HELP libraries, this sounds like a
watered down, language independent Utilizing class. Much
of the material came from old U&C II where non-programmers
could be exposed to additional utilities; however, this
audience will consist of programmers who will most likely
also take the Utilizing VMS Features course.
|
| 116.5 | Putting this course on the map | SUPER::MATTHEWS | | Mon Sep 16 1991 17:10 | 42 |
| Let's provide more positioning info on this course. Andy/Bill/Kristin,
correct me if I misstate anything.
As Kristin said in .0, we don't expect Utilizing to remain in its
present form. When we remove overlaps with Programmer II, what remains
is information on how to use specific system services and RTL routines.
The Programmer II + new Utilizing combo is roughly equivalent to
today's Utilizing. (The curriculum in the Netherlands already has this
structure; see SUPER::UTL_VMS_FEATURES.)
Programmer II also serves as prereq for the POSIX programming course,
which will appear on the map parallel to Utilizing II. Programmer II
should also be attractive to students intending to take other
programming courses (DECnet, ACMS, Rdb, etc. etc.) but who don't need
to call system services.
Splitting up Utilizing is a strategic move in a changing world. While
we expect the VMS system to remain an important software-development
platform, we expect the code developed on it to make increasing use of
OS-independent routines (POSIX, Motif, SQL, etc.) and decreasing use of
proprietary VMS system routines.
Therefore we need to separate VMS programming aids from VMS callable
routines, and put the former in Programmer II and the latter in the new
Utilizing. In Programmer II we do not assume that (as stated in .1),
"users wish to produce software that has the feel of VMS" -- we
save that assumption for Utilizing.
(The new Utilizing will also be more geared to HLL programmers, and
emphasize RTL routines over the equivalent system services in cases
where the RTL is more easily callable from an HLL.)
To answer another of Keith's questions ("Presumably issues of
performance are relegated to VMS System Performance Management
training?") No, actually we don't have a course today that addresses
application performance (we address bits of it in places like Utilizing
II and the RMS course, but not all in one place). With these new
courses we still don't. I think we need one; does anyone else?
I hope this clarifies things.
Val
|
| 116.6 | | CECV03::SADLER | Change for a Flainian Pobble Bead? | Wed Sep 18 1991 00:40 | 17 |
| Re: -1
Thanks for saving me a job Val! Your description sums up my currnet thinking
well. I tested this with the European CRT last month and they agree with the
concept. I've also talked to a few people in the US and GIA and again the
concept seems OK.
Next stop is to publish and get feedback on the proposed new programmer map and
the outlines, hope to do this within a couple of weeks.
Let's have your feedback on the concept now!!!!
Thanks,
Andy
|
| 116.7 | If it's not broken ... | TEACH::ABBY | | Wed Sep 18 1991 15:24 | 151 |
|
Andy, Val, Kristin and fellow instructors:
I would like to supply some input on the proposed plan for
the programmer 2 class. I'm not sure that I can. From Val's
note 116.5, I get the feeling that the programming curriculum
is supposed to be clear to me, but it is not. I would like
to see a detailed list of topics from old course modules and
where those topics will be covered under the new plan such as
I saw when reviewing the SYSNET curriculum. It is difficult
to evaluate a proposal (as indeed it must be to write it) if
the entire educational plan is not made clear at one time.
Meanwhile, I will make my comments on the information available.
It is my understanding that reworking our programmer training
is being undertaken in order to meet the needs of some specific
audiences:
Programmers who will be programming with layered products
and need to understand the calling standards and a bit
about the VMS system environment are currently required
to take a five day, very technical class in order to get
the few details they need to prepare them for interfacing
with their end products.
Programmers who will be using standard, non-proprietary
calls will be working on VMS machines as development
machines, but will not be calling any VMS specific routines
from their applications.
The European training centers teach a language independent
Utilizing course and would like to see the official class
as generic as possible.
My concerns fall into two categories. One is, do topics proposed
in note 116.2 really accomplish their intended goals, and the other is,
will the current US audience for Utilizing Features suffer in the
attempt to generalize. Specific issues follow:
It seems that some of the intended topics already violate
the idea that the class not address VMS specific routines.
The topic VMS System Routines and Callable Utilities, the
discussion of status values returned by system routines,
and how programs can retrieve information from a help
library would be inappropriate. In addition, would the
CDU really merit a module if the target program could
not call any CLI routines? These topics represent 40 to
50% of the topics listed.
What would the lab be like? The only mention of a lab in
the outline is a written exercise that "gives samples
from our documentation and asks questions." Interesting
labs that demonstrate the topics without using specific
languages will need to be developed in order to present
the course as a lecture/lab offering.
At the DC training center, we offer Utilizing classes in
Ada, C, COBOL, FORTRAN, and FORTRAN/Macro. Enrollment
is excellent, and they are very successful. All of the
instructors who teach the classes find that it is a very
full week (4 days for COBOL) and that the topics are
extremely apropos to the customers' needs. I cannot
imagine that the proposed course flow, a three day generic,
non-technical, non-language specific class followed by a
two day language and routine specific course, will be able
to meet the needs of this existing group of programmers.
- The details of a language's passing mechanisms,
data types, status checking, specifics of
routines, and lab cannot be covered in two
days.
- Examples of a concept should be presented at the
time the concept is learned initially.
- This existing customer base may find that their
specifics needs are not addressed until
much later in the curriculum.
- Customers may have additional expenses in order
to attend the two classes replacing
Utilizing.
- Scheduling instructors to teach 2 day language
classes might be a management nightmare
and may hurt instructors' platform time
measurement.
Overall, I was disappointed that the Programmer 1 class was not
more oriented towards programmers. My assumption about the
restructuring was that VMS for Programmers would be a combination
of what I now find to be Programmer 1 and the proposed Programmer 2.
It really should only take 3 days to expose an experienced programmer
to enough file organization information, protection, DCL concepts,
syntax, tailoring, and editing to allow him/her to be comfortable
with the environment. The subsequent 2 days could cover the
debugger, linking, libraries, shareable images, calling standards,
a system overview, and an introduction to the available realm
of routines and documentation in the generic manner that the
proposed Programmer 2 intends. I feel strongly that this would
better serve all our programming customers by providing a concise
week-long class that would represent their complete preparation for
product/system specific training.
If it comes to pass that course development proceeds with the
course division as currently described, I think that the programmer
2 class, perhaps under a more specific title, could be offered
as a course roughly as proposed, but not as the replacement
for Utilizing Features of VAX/VMS, rather as a substitute course
for those customers who will not be using VMS RTL and system routines.
For the audience continuing on to VMS system programming, the
follow-up class to Programmer 1 should continue to be a technical,
detailed, five day, language specific Utilizing Features of
VAX/VMS. [Adding more stress on RTL's rather than System Service
is immaterial to the course restructuring issue.]
Whether or not Digital's Utilizing class should be tailored to
specific languages or become generic as in Europe has long
been an issue among instructors. It has been my experience that
our customers want a class which goes though as many specifics
as possible in their target language, and would not be willing
or perhaps have the wherewithal to do the extra research on
their own. There is no doubt in my mind that the background of
both students and instructors in the US and Europe is quite
different, and I therefore think that it's reasonable for the
two environments to present the materials in different manners.
I think that the current "generic" student guide and language
specific guide fill both needs adequately.
Without seeing the entire game plan, I am at a loss trying
to see the restructuring of our programming courses as a positive
event. Training programmers with programming related topics
is a great idea, yet, for example, Programming 1 doesn't hit
the debugger until module 17 of 17 (if it hasn't changed in its
final format) and barely touches on it at that. Why should a
student need to enroll in two supposedly programmer targeted
classes in order to learn (and without language specific
examples even then) the fundamentals of the most important
programming tool available? Keeping up with programming in
new environments is vital, but adding new training is not in
contradiction with keeping classes that continue to have
a large audience.
I am concerned that the goals of this restructuring are unclear,
and that in the rush of attempting something good we are going
to produce something bad.
Abby Renfroe, DC Training center
|
| 116.8 | UK offers 7 Util VMS Feat | CRISPY::SHONEK | Keith Shone UK Edu 830-4074 | Thu Sep 19 1991 04:26 | 26 |
| Just a few comments/observations on Note 116.7...
>> The European training centers teach a language independent
>> Utilizing course and would like to see the official class
>> as generic as possible.
Here in the UK we don't offer a language-independent version of the
Utilizing VMS Features course to external customers. We do offer: Ada,
BASIC, C, COBOL, FORTRAN, VAX MACRO and Pascal.
[ UK was in Europe when I left home this morning ;-) ]
>> - The details of a language's passing mechanisms,
>> data types, status checking, specifics of
>> routines, and lab cannot be covered in two
>> days.
I wouldn't take two days. One morning for the chat and one afternoon
for any consolidating labs, at most.
>> - Scheduling instructors to teach 2 day language
>> classes might be a management nightmare
>> and may hurt instructors' platform time
>> measurement.
Ah, but what do our customers want/need? They don't want to know about
our problems. We're here to fix their problems.
|
| 116.9 | Former customer point of view | TEACH::HENRY | Pam Henry | Thu Sep 19 1991 09:27 | 70 |
| September 19, 1991
I am an instructor of the current Utilizing VMS Features
course for both Fortran and C. Prior to coming to Digital
however, I was a process control engineer (and a Digital
customer) for 10 years. Many of my comments on the course
outline for VMS FOR PROGRAMMERS II come from my experience
using VMS and not necessarily as much from my teaching.
An overall general comment is that the Utilizing Features
course has much of what the student needs and wants. Our
customers would suffer a disservice if we start taking out
topics or watering them down into such generalities that
we really give them nothing to take back to their jobs
with.
Let me now comment on specific items in the course outline.
DEVELOPING SOFTWARE IN A VMS ENVIRONMENT
The topic of "creating modules (determining what should be a module)"
should be taken out. Programmers coming to this course already have
a good deal of programming experience and education and we should
not be trying to teach style in this course. Also, many customers
have their own standards for software design and we would be "stepping
on toes" if we tried to impose our philosophy on them. Perhaps we
could create a course (or seminar) on structured programming so that
those attended would know what they were getting.
VMS SYSTEM ROUTINES AND CALLABLE UTILITIES
All of the topics listed here are far too general and vague. If the
course content is as vague and general as the course outline, there
will be nothing useful for the students. These students need to
know how to write the code using the system services. They need
examples. Most of these students are on extremely tight delivery
schedules and are looking for nuts and bolts and cookbook procedures
to take back with them so they can immediately dive into there
software development.
CALLING PROCEDURES
Again in this module the topic of "how you should document your
procedures..." should be removed. My previous comment regarding
structured programming applies here as well. Many customers have
their own standards and requirements for documentation and this would
not be at all helpful to them and may in fact hurt Digital's
reputation. We need to keep the programming topics separate from
the style topics.
OVERVIEW OF OTHER TOOLS FOR PROGRAMMERS
Again this module is way too general to be of any use to the student.
The topics sound like a sales pitch and not instructional. These
students need to know how things work and how to use the products,
not what you can do. We will insult many customers if they pay to
attend our class, we tell them they have all of this great capability
on their systems but we are not going to tell them how to use it.
Again let me reiterate that my comments come more from my background
as Digital's customer but after all, those are the needs we must
address if we are going to compete "strategically in a changing world".
-- Pam Henry
DTN: 341-6300
EKO
|
| 116.10 | Have we asked our CUSTOMERS? | TEACH::MARYJO | Mary Jo Bader, EKO/Ed.Srvc., 341-6327 | Thu Sep 19 1991 09:57 | 26 |
| Since this is such a hot topic and I manage the programming instructors
here in DC, I feel that I must put in my comments as well. I happen
to agree with my instructors interpretation of the situation. Our
current utilizing courses are running with amazing enrollments,
in fact I can't seem to offer enough Utilizing with Fortran classes
right now. And all of them are running with phenomenal QA results.
So my question is this, have we actually gone to our CUSTOMERS here
in the U.S. and asked them what they need/want? Or are we making
assumptions? And I don't mean asking upper level management at
our customers, but actually asking the programmers who come to our
classes whether we are hitting the mark or not. I totally agree
that we need to do what is "right" for them regardless of how it
affects us and our problems. But is that what we are actually doing?
If such a survey has taken place, I would be very interested in
knowing the results. If it hasn't, I would like to offer my training
center (since we seem to do the bulk of the Utilizing training lately)
as a site for a special survey to be handed to our students at the
end of each Utilizing class to get comments on content of the course
and any unmet needs. If fact, as a manager I would even offer to
do "End of Course Conferences" on each and every Utilizing course
session that we run for a period of time to solicit input.
If this is a valid way to go and such a survey of customer needs
has not taken place, then let's slow things down some and actually
talk to our customers to make sure that we are meeting THEIR needs.
|
| 116.11 | customer instructor point of view | DOOZER::RUSSELL | Hazel, RKA, 830-6214 | Thu Sep 19 1991 12:40 | 61 |
| I too am concerned about the topics and structure of the proposed
course. I teach the Utilizing course from COBOL, and from FORTRAN
and from BASIC and the only non-satisified customers I have had
are those that haven't read the course description and think that
the course being offered is an advanced programming course in whatever
language it is. The other customers are more than happy, and we
do have end of course reviews here, where we ask whether the course
content is what they want. Many of the customers are people coming
from companies who have sent many of their employees on the course,
and obviously feel that they are getting what is required for their
job, otherwise they would not keep sending their employees.
I am concerned that the 3 day course is going to be VERY theoretical
- OK, the customer will be able to run programs and see the effect
of ,say, setting event flags, but it isn't going to truly reinforce
the learning until they write it in their own language. If that
is left until the 2 day add-on, the connection between the two things
will be lost.
As far as the generic aspect of the course goes, we did teach employees
this way in the UK with the instructor I gather very much leaving
it to the individual to work out for himself/herself how their language
dealt with passing mechanisms, itemlists, building structures required
for input-output status blocks etc. The current exercises also
tend to be constructed in such a way that the customer is not likely
to make the kinds of mistakes one typically makes when writing calls
to system services as a beginner. In customer training we teach
the language based courses, such that we can go through examples
in detail, teach how to create itemlists etc., in other words give
the customer the building blocks which he/she will need in order
to be able to apply what they have learnt in the week to calling
any other RTL or system service routine or callable routine. (i.e.
teach them how to read the manual!) To this end I do not always
use the provided exercises, so that mistakes will be made, and so
that students learn from those mistakes. The exercises are therefore
being used not only to reinforce the VMS concepts.
If the course content does stay as described in 116.2, I have further
concerns:
1) Chapter 2 - system routines and callable routines - it says VMS
concepts as needed - how much detail is going to be need here to
make some of the routines make sense?
2) Chapter 6 - other tools - is TPU programming used by most customers?
Without explaining RMS concepts, which have now been taken out of
the course description, how can you effectively teach FDL? The
prompts are going to be meaningless.
In 116.2 Utilizing II is mentioned - is this the current Utilizing
II or a new one?
I also feel that RTL should not be overemphasised in relation to
system services - once you conquered itemlists, system services
are not difficult, and can lead to more flexibility and better
performance.
I would also like to see the topics that are going to be included
in the courses in comparison with what we now have.
|
| 116.12 | Prog II not for me... | UKEDU::HARMER | Geoff Harmer U.K. Edu (830) 6229 | Thu Sep 19 1991 12:43 | 301 |
| Sorry but Prog II is not for me :-(
Management summary
------------------
There is no need for Programmer II. Feed from Prog I via a language
course ( if needed) to either Utilizing I ("GUCKO") or POSIX programming.
Put effort into keeping Utilizing I up to date and using good
programming practices in each of the languages. Track new features in the
languages and modify Utilizing I examples to show good practice.
Utilizing is popular, revenue generating and prereq for Decnet
programming.
You will lose revenue as Customers will attend Prog II for 3 days,
rather than Utilizing I for 5 days.
Geoff
----------------------------------------------------------------------------
Here are my comments on Val's justification in reply .5
and to the revised course description from .2
================================================================================
Note 116.5 Programmer II coming 5 of 10
SUPER::MATTHEWS 42 lines 16-SEP-1991 16:10
-< Putting this course on the map >-
--------------------------------------------------------------------------------
Let's provide more positioning info on this course. Andy/Bill/Kristin,
correct me if I misstate anything.
As Kristin said in .0, we don't expect Utilizing to remain in its
present form. When we remove overlaps with Programmer II, what remains
is information on how to use specific system services and RTL routines.
The Programmer II + new Utilizing combo is roughly equivalent to
today's Utilizing. (The curriculum in the Netherlands already has this
structure; see SUPER::UTL_VMS_FEATURES.)
> I entirely support the views in .10. Utilizing is a highly successful
> course here in UK...we do separate courses for each language...at V3
> VMS time the idea of dual languages was abandandoned as unworkable
> you may remember. You give no justification for destroying a very
> profitable and excellent series of courses that are clearly meeting our
> customer's needs. Why not keep Utilizing. POSIX programming day 1 can
> include VMS development techniques ( and I doubt if that is needed if a User
> course (prog I or Ultrix user) has been attended.
> Students need to ACTUALLY code examples in THEIR language in order
> to learn this material. Each language has its own special ways of
> doing things (like obtaining SS$symbols,building itemlists,using ASTs)
> The approach to the subject is entirely dependent on the language...
> e.g FORTRAN,PASCAL programmers want lots of QIO and interproc comm.
> COBOL programmers aren't interested in those aspects but want to know
> about using EDIT/FDL and file design.
> Some languages have language features that mean you don't need to
> use "system routines" e.g error handling in BASIC.
>*** Whatever change you make you MUST keep it language specific ***
> In summary I see no need to have this course at all.
Programmer II also serves as prereq for the POSIX programming course,
which will appear on the map parallel to Utilizing II. Programmer II
should also be attractive to students intending to take other
programming courses (DECnet, ACMS, Rdb, etc. etc.) but who don't need
to call system services.
>
> Why does anyone need VMS Programming to do POSIX programming. ?
> POSIX programming is a variant of ULtrix programming.
> There should be a course in POSIX programming that is independent
> of platform.
> Decnet programming requires that the student has good knowledge of EF,
> AST,mailboxes, QIO. He won't get it from attending Prog II.
> DECmessageQ programming ( possible High Level replacement for DECnet prog
> only requires aknowledge of ASTs.
> I can't comment on ACMS,RdB etc.
Splitting up Utilizing is a strategic move in a changing world. While
we expect the VMS system to remain an important software-development
platform, we expect the code developed on it to make increasing use of
OS-independent routines (POSIX, Motif, SQL, etc.) and decreasing use of
proprietary VMS system routines.
> Agree entirely. But Programmer I gives all that's needed as
> prerequisite for these topics... Program development/libraries/debugger.
> and intro to System routines.
Therefore we need to separate VMS programming aids from VMS callable
routines, and put the former in Programmer II and the latter in the new
Utilizing. In Programmer II we do not assume that (as stated in .1),
"users wish to produce software that has the feel of VMS" -- we
save that assumption for Utilizing.
> But some of the VMS programming aids you have in the course are hardly
> used by our customers...TPU programming,CDU.
> The Debugger has already been covered in Prog I
> Others like DECset depend on whether the customer has bought them.
(The new Utilizing will also be more geared to HLL programmers, and
emphasize RTL routines over the equivalent system services in cases
where the RTL is more easily callable from an HLL.)
> And what about performance ???
> You should encourage good performance practice.
To answer another of Keith's questions ("Presumably issues of
performance are relegated to VMS System Performance Management
training?") No, actually we don't have a course today that addresses
application performance (we address bits of it in places like Utilizing
II and the RMS course, but not all in one place). With these new
courses we still don't. I think we need one; does anyone else?
> Teach good practice in Utilizing...thats what the instructors who
> teach it emphasise.
> Geoff
I hope this clarifies things.
Val
--------------------------------------------------------------------------
Here are my comments on the revised topic outline for Prog II.
Geoff
<<< SUPER::WORK4:[NOTES$LIBRARY]VMS_CURRICULUM.NOTE;1 >>>
-< VMS Curriculum >-
================================================================================
Note 116.2 Programmer II coming 2 of 10
SUPER::ROUNDS "Kristin Rounds, DTN 381-1066" 137 lines 13-SEP-1991 15:12
-< Revised topic outline >-
--------------------------------------------------------------------------------
The following is a revised topic outline for the course. It supersedes
the one posted in note 116.0.
Please post your comments by Friday, September 20.
Thanks...
Kristin
VMS FOR PROGRAMMERS II
Purpose of The purpose of this course is three-fold:
this course
- To teach programmers how to use the most commonly used
software development features of the VMS operating system.
> Good
- To provide an awareness of the tools and system routines
that can be used to develop applications on a VMS system.
> What relevance to POSIX programmer ?
- To provide information that will help programmers to decide
which tools are appropriate for a project.
> So long as they are for both VMS and POSIX.
Topic list The following major topics have been identified:
- Developing software in a VMS environment
- VMS system routines and callable utilities
- Calling procedures
- Using the features of the command language interpreter
- Providing application-specific help
- Overview of other tools for programmers (need snappier title)
DEVELOPING SOFTWARE IN A VMS ENVIRONMENT
Purpose of Review program development steps, show ways to use the Linker,
this chapter present the concept of a library and show how to use an object
library, describe the use of shareable images, and teach
fundamentals of using the VAX Debugger.
> An important module.
> But much was covered on Prog I
Chapter topics The following topics have been identified for this chapter:
- Review of program development steps: compile, link, run
- How to use object libraries
. Linking multiple objects
. Linking against an object library (what is a library?)
. Using logical names to refer to object libraries
. Creating and manipulating an object library
- Creating modules (determining what should be a module)
- Using shareable images
. What is a shareable image
. Shareable image libraries
(What they are, creating, linking against)
. Linker options files
. Using the Install utility
- Using the VAX Debugger
. Get in and out
. Set up environment (windows, display, etc.)
. Get help
. Observe and control execution
. Examine and change variables
> OK
VMS SYSTEM ROUTINES AND CALLABLE UTILITIES
Purpose of Present the concept of system service and run-time library
this chapter routines, describe the functional groupings of these
routines, and explain how to decide what to use when more
than one routine will perform a particular function.
> Why does a POSIX programmer want this ?
> Useful for VMS system service/rtl programmer.
Chapter topics The following topics have been identified for this chapter:
- Overview of system routines (system service and run-time library routine)
- Functions performed by system routines (date/time, communication, etc.)
- Callable utilities
(Present VMS concepts as needed)
> A lot of this is language specific. Some languages can do
> this stuff from the language; others need VMS routines.
> I'm not happy about generic stuff at all.
> There seems to be no mention of multi-process applications
> or real-time work...this is very important for FORTRAN,MACRO
> PASCAL, ADA and C .
CALLING PROCEDURES
Purpose of Teach the student the procedure for calling the system
this chapter routines described in the previous chapter.
Chapter topics The following topics have been identified for this chapter:
- Passing arguments to a system routine
. Passing mechanisms
. How to determine what mechanism is required
> This is language dependent.
> Is it relevant to POSIX ?
. How you should document your procedures so others will know
what mechanisms to use in passing arguments to them
> Probably best to leave this to Customer standards...most
> seem to have their own conventions.
- How to use the status value returned by a system routine
(service-specific versus service-independent)
> Language dependent.
Idea for written exercise: give sample(s) from our
documentation and ask questions about them.
> Or use exaples from Utilizing.
USING THE FEATURES OF THE COMMAND LANGUAGE INTERPRETER
Purpose of Teach students how to have DCL process input for a program
this chapter so the program doesn't have to prompt for values and check
their validity.
Chapter topics The following topics have been identified for this chapter:
- Creating a command definition file
- Coding an image to be invoked by the command
- Adding the command to the DCL table
> This is bad for performance...should we be encouraging
> it ? In my experience most application writers do not
> want to make their applic into a DCL command with params
> and qualifiers, instead they provide an interface inside the
> application itself.
PROVIDING APPLICATION-SPECIFIC HELP
Purpose of Teach students how to set up an application-specific help
this chapter library and code programs to access it.
Chapter topics The following topics have been identified for this chapter:
- Creating a help text file
- Creating and manipulating a help library
- How programs can retrieve information from a help library
- Using logical names with help libraries
> Good. Quite popular with customers
OVERVIEW OF OTHER TOOLS FOR PROGRAMMERS
Purpose of Give an overview of bundled tools and layered products
this chapter that programmers may use in developing applications, and
provide information to help decide which tools to use with
a particular project.
Chapter topics The following topics have been identified for this chapter:
- Definitions: "bundled" versus "layered"
- General categories of tools, with comparisons of tools in
each grouping
VAXset, TPU programming (what can be done, not how to do it)
and EDIT/FDL (ditto).
> I don't like the idea of just overviwing the tools. This
> is just marketing. Either do it properly with labs or
> not at all.
> Generally I'd want to see lots of PROGRAMMING lab work. You can't learn
> programming techniques unless you actually code the calls.
|
| 116.13 | Many problems | NITTY::SORKIN | Earth Day...only the beginning! | Thu Sep 19 1991 16:23 | 75 |
| I teach Utilizing VMS Features from FORTRAN (and also a
FORTRAN/Macro combination) in the Chicago training center.
I have been doing this for a number of years. I am very
concerned about the proposed course: VMS for Programmers II.
Problem: Separating concepts from language-specific examples
------------------------------------------------------------
The idea of a 3-day generic course (followed by 2-days of language
specific information) does not fit in with programming classes
in general. The current format of "Utilizing VMS from ..." starts
with a concept and then immediately reinforces the concept with
a language-specific example. The customer gets additional
reinforcement by doing the associated lab exercises on the same
day. With a generic course, the customer will be waiting
approximately 3 days to see the language-specific programs.
It also means that the customers would be trying to do all
their lab exercises in 2 days (and probably 1 day if the
2nd day of the language-specific class is on a Friday -- customers
are typically not inclined to work on lab exercises on Friday
afternoons). That does not make sense from an educational standpoint.
Problem: Quantity of topics vs. time
-------------------------------------
As for the topics, we currently can barely fit all the information
into 5 days (and allow for adequate lab time). I see a number of
topics that do not appear to be essential (and have not been
requested by the customers that I have taught). A list of these
NON-essential topics follows:
- debugger
- CDU and adding commands to DCL
- creating and accessing HELP libraries
- VAXset
- TPU programming
Some of the above topics were part of "Utilizing VMS from ..."
in student guides years ago, but were thankfully eliminated.
Problem: Understanding the course and topic flow
------------------------------------------------
As stated in other replies, the course and topic flow is not
clear. The time allotment of topics within the proposed courses
is not clear. The positioning of VMS-specific vs. POSIX specific
information is not clear. If instructors are confused by the
proposal, where does that leave the customers?
Problem: Scheduling
-------------------
I'm not a unit manager, but I definitely expect that there are
going to be major scheduling problems if a variety of 2-day
language-specific courses need to be offered directly after the
generic course. Reply .9 stated:
"Ah, but what do our customers want/need? They don't want to know about
our problems. We're here to fix their problems."
Scheduling problems would mean that we probably could not offer
this programming course combination as frequently as "Utiltizing
VMS from ..." course are currently offered. In that case, "our
problems" would limit the customers scheduling choices (and therefore
"our problems" would become "customer problems".
Problem: We currently have a good format
----------------------------------------
Last, but not least, the current Utlizing courses are successful.
I agree with Reply .7 . If it's not broken, please don't fix it.
Marshall
|
| 116.14 | another response | NITTY::FALLAHEE | Department of Redundancy Department | Thu Sep 19 1991 18:26 | 20 |
| I am an instructor of the current Utilizing VMS Features course for
COBOL and have an interest and concern in the proposed couse.
My major concern is that a generic 3-day class will not allow the
customer practice of the covered topics within a reasonable time.
The way the course is taught now, language specific, works very
well. The topic is introduced and can be immediately followed
with an example for reinforcement.
My second concern is with some of the proposed topics. I do not
beleive them to be essential. These are:
TPU programming (no one has ever asked me for information)
CDU and adding commands to DCL (ditto above)
Lastly, as others have already stated, our customers are really more
interested in "how to", as opposed to "what".
Other than the above, the rest sounds good.
Mary
|
| 116.15 | for what it's worth ... | GOONS::GOODWIN | Really Mario Tribello | Fri Sep 20 1991 06:29 | 15 |
| From the replies in this note, it would appear to me that the proposed
revamp of this curriculum is not welcome in the field. The general
feeling in Customer Training in the UK is that the old format of
language specific courses is tried and tested, and popular with our
customers; as an ex-deliverer of these courses, I can vouchsafe that.
I will need to be very convinced that any changes are for the better
and if this conviction is not forthcoming, I can see Training Centres
"going their own way" with locally produced curricula in this space.
This would be a great pity as there is obviously a lot of effort being
put into the new course development; put into the right direction, this
effort could enhance an already very successful curriculum.
Mario Tribello
|
| 116.16 | Reality in the Classroom | TEACH::VICKI | | Fri Sep 20 1991 15:48 | 35 |
| Monday Morning - Generic three day class:
"Good Morning and welcome. During this class we'll be discussing
VMS programming aids. There will be discussions on calling procedures
and lots of other VMS features, but we won't actually show you how to
do this in your specific language. If you want to try this in lab,
you will need to "borrow" the book that discusses this, figure it out,
and work on it in lab yourself. I probably won't be able to answer
questions, unless you use the language I know. Also, please don't hog
the books so others can use them."
"Now, if you want to learn how to call VMS Features from a particular
language, you can attend the 2 day language specific course. Please
take real good notes so you can remember what we talk about here,
since it could be quite some time until you take that class, and we
won't have time to review information."
MONDAY, TUESDAY, WEDNESDAY or THURSDAY morning of the 2 day class:
"It's nice to see so many of you return for the language specific
class... Oh, some of you have not taken the pre-requisite? We
will definitely not have time to do any review if we're going to have
time to cover lecture and have time for lab. Please don't expect to
leave early on the second day, either."
"If you didn't take the pre-requisite and want to come back another
time, please see the registrar... You're from out of town and paid for
travel? Gee, I'm sorry. And I really can't help it if your sales rep
told you about this class and you didn't check the pre-req. That's
why we have the Unlimited Training Subscription. You can take lots
of courses to get the job done at an affordable rate, and you get a
training plan."
|
| 116.17 | Please, think about customer satisfaction!!! | NITTY::DIERCKS | But 'ch are, Blanche! | Fri Sep 20 1991 17:52 | 36 |
|
I can see nothing good coming from this course. Several things
especially come to mind.
1. When teaching a programming oriented course, it is a SURE customer
dissatisfaction issue to separate the dicussion of the "concepts"
from the discussion of "examples".
2. Do you realize how difficult it will be for the training centers
to schedule this course? They'll have one instructor teaching
the generic course on Monday, Tuesday, and Wednesday. Then,
depending on how many languages a particular training center
deals with they may have to have MANY instructors teach the
Thursday-Friday class. Even if an instructor teaches features
from several languages, they can only do it in one language
at a time. (Please, please don't tell me that the expectation
is that the T-F class be conducted teaching several languages
at the same time!)
3. Do you have any idea how difficult it will be to accurately
market this class to our customers?
This is a prime example of "fixing what ain't broke".
If this course flies, I will personally recommend to my manager that we
NOT offer it and instead continue to offer the courses in their present
format, even if it means we write our own materials.
************************
Please, abandon this plan NOW and spend the $'s on something more
worthwhile, like rewriting the C-Features handout so that the programs
look like "real" C and not just FORTRAN converted to C. 8-)
Greg
|
| 116.18 | RMS out, other topics in....... | NITTY::DIERCKS | But 'ch are, Blanche! | Fri Sep 20 1991 17:56 | 19 |
|
And, please, DON'T add the "optional" layered product discussion
(VAXset) into the course. It only opens a can of worms. The course is
already quite full. And, not all features instructors (like me) also
teach the VAXset products.
Personally, I'd also vote for the complete removal of the RMS topics
for the current course, also. The material present is only just enough
to either completely confuse the students are get them interested
enough to start asking for the material which is really a part of the
RMS Structures and Utilities Course. I'd vote, instead for putting
some of the "old" topics back into the course. Topics such as "help"
and the message facility are important. I'd venture many instructors
already deal with these topics by providing the students
handouts/examples. Other topics of interest might be additional info
on $BRTHRU and $SNDOPR.
Greg
|
| 116.19 | Programmer II et al | DLO10::TARLING | | Sat Sep 21 1991 12:48 | 11 |
| Greg makes an excellent point in .18. I also leave out the RMS stuff
from the current utilizing, and add copies of the old course (help,
message, and some SMG).
I do believe that the Programmer II "CAN" be done, and that (as I said
in .3) the outline looks pretty good. The question is, why are we
doing this?? We already have essentially the same course (the utilizing
lecture guide, and the language specific workbook).
Arnold.
|
| 116.20 | Home thoughts from abroad... | CECV03::SADLER | Change for a Flainian Pobble Bead? | Wed Sep 25 1991 05:50 | 41 |
| Hmmm, seem to have opened a can of worms with this one...
OK, time out, let's start again with a statement of the problems as I see them,
and you can all suggest solutions...
1. Posix for VMS comes out soon - programmers using it will need to be able to
make calls to the Posix routines (at least that's what I was told - tel me if
it's not true!) and won't be happy if we tell them to take a 5 day course on the
proprietary features of VMS as a pre-req.
2. VMS for Programmers I replaces both U&C I and U&C II, so we'll potentailly
lose some revenue from U&C II. The idea was to try to attract large numbers of
programmers to 2 courses (PI and PII) even if it means some losses on Utilizing
courses, as the upside gain on PII should balance this out (the penetration rate
of Utilizing attendance into the U&C programmer audience is small)
3. A lot of other programmer courses specify Utilizing as pre-req when all they
really need is the ability to make calls to system-supplied routines.
4. The move to Open VMS will in all likelyhood cause our customers to shy away
from use of the Proprieary features of the system.
OK... let's hear your solutions...
Cheers,
Andy
PS For all the "don't fix it if it isn't broken" afficianados...
You're driving straight at a wall, you start to turn the wheel and your
p[assenger says, "Why are you doing that? We haven't hit the wall!"
|
| 116.21 | If you build it, will they come? | TEACH::ABBY | | Wed Sep 25 1991 18:56 | 52 |
| "You're driving straight at a wall, you start to turn the wheel and your
passenger says, "Why are you doing that? We haven't hit the wall!""
Good grief, Andy. Before we face brick walls, could you please
fill us in on the information you have access to which makes
you so sure that Utilizing will not be a necessary class much
longer? Enrollment is good, classes are successful,
satisfaction is high, and surely our customers would
be aware of any harbingers of VMS doom and would also start
moving to other platforms. We in the field don't seem
to see it at this point in time.
1. Posix for VMS comes out soon - ... won't be happy if we tell
them to take a 5 day course on the proprietary features of VMS as a pre-req.
So don't tell them that. Either make the necessary information
on VMS part of the POSIX class or create a short class for
programmers using VMS but not to call proprietary features.
In either case, Utilizing would remain as a separate class
and would not be a prerequisite for the POSIX folks.
2. VMS for Programmers I replaces both U&C I and U&C II, ...
lose some revenue from U&C II...
Our training is already so expensive that we need unlimited
training programs to make it affordable again. If a change
is made to our curriculum, it has to be for a better reason
than the above.
3. A lot of other programmer courses specify Utilizing as pre-req when all they
really need is the ability to make calls to system-supplied routines.
Stop specifying Utilizing as a prerequisite and either include
the calling standard in the "other programmer courses" or
include the calling standard in programmer I.
4. The move to Open VMS will in all likelihood cause our customers to shy away
from use of the Proprietary features of the system.
Is your "likelihood" strong enough and soon enough to do
away with Utilizing now? Is seems that if and when our
customers stop wanting Utilizing, we will respond by
cutting down the offerings.
It is clear to me that there are two issues here. One is, do we need a
new programmer oriented class, and I am willing to take the analysts'
word that the answer is yes. The other is, should Utilizing go away,
and certainly from the field, the answer is a resounding no. I
don't understand the political/corporate reasoning that is preventing
these from being addressed independently.
A. Renfroe
|
| 116.22 | | NITTY::DIERCKS | But 'ch are, Blanche! | Wed Sep 25 1991 18:58 | 31 |
|
Andy, I just read and re-read your last note and don't quite understand
what I'm supposed to offer you as suggestions, but this is my go at it.
I realize that "things" are changing with the advent of POSIX, etc.
But (BUT!!!!!!) it will surely be the case (won't it?) that many, many
of our customers that run in pure VMS shops WILL NOT be writing "open"
applications. They need the course as it is, perhaps cleaned up some.
Those people who WILL be writing open applications WILL need some VMS
architectural background. It seems like the "generic lecture guide" of
the current features class will offer most of that background (again,
cleaned up some). Why not leave the current features curriculum alone
for the benefit standard VMS users. (PLEASE!!!!!!!!!) And, write the
new course for posix users. I don't know the posix interface, but I
understand it is non-trivial and WILL involve a considerable retrain --
a five day class will probably be in order.
I seriously think the logistics of the "new course" haven't been
thought our thoroughly enough. I'll ask some questions (which have
been asked before).
Have customers been talked to about this class? What do they say?
If no customer surveys have been performed, why not?
I'm very concerned here, and don't at all feel good about these
possible changes.
Greg
|
| 116.23 | They Say It Very Well | DLO10::TARLING | | Thu Sep 26 1991 10:41 | 15 |
|
Andy et all;
Abby and Greg (.21, .22) have said it very well.
Utilizing may indeed decrease in popularity in the future. That
will be evident "when" it happens, and reduced offerings or an
outright cancellation is not hard to do.
Some generic VMS will be needed for POSIX - How about "Utilizing
VMS Features from POSIX"?
Regards,
Arnold Tarling
|
| 116.24 | More dittos | TEACH::HENRY | Pam Henry | Fri Sep 27 1991 14:29 | 21 |
|
All of the previous comments and responses are right on track.
I just finished teaching Utilizing VMS features from C and once
again I got comments from EVERY student in my class that said the
course really helped them and they felt anxious to get right back
to their jobs to incorporate what they have learned. With a customer
satisfaction level like that do you honestly think we are headed
in a wrong direction?
Let me restate my position of providing what the customer needs
and wants rather than what is good for our books. As stated in
my previous response, our customers get immediate "bang for their
buck" in the present Utilizing course and after all every company
in corporate America is looking for that. If we could focus our
emphasis and our course revamping toward our customers, the additional
revenue will definitly be seen. I realize change is necessary
if we are to survive and I also fully agree we must be thinking
ahead toward POSIX but we will never financially survive if we
do not continue to address the needs of ALL of our CUSTOMERS.
-- Pam Henry
|
| 116.25 | My tuppence... | GOONS::BAKER | What does "ignorant" mean? | Mon Sep 30 1991 07:12 | 28 |
| I agree with comments that the Utilizing course should remain in the
format in which it runs today. I feel sure that there are many
customers (both external and internal) who need this info now and for
some time in the future. I view these courses as a natural extension to
the language programming courses and any real :-) programmer will want
to make use of O/S (proprietry or otherwise) features which overcome
language limitations (e.g. interprocess communication) or
improve/standardize the "feel" of applications by incorporating things
like HELP and CDU in line with the VMS way of doing things.
I could ramble more about the benefits of system calls etc. but I'm
sure I don't need to. What I will say is that I think students should
attend the course knowing how to drive VMS (VMS for Programmers),
knowing the language of their choice, and how to use the debugger.
They can then concentrate on all things VMS-y, and come away after a
week feeling happy about using VMS features from their language. It
seems that this is exactly where we are today.
The advent of VMS POSIX doesn't mean that everyone is necessarily going
to start using POSIX calls. I feel that the POSIX need is entirely
separate and we should offer a distinct course called "Utilizing POSIX
features". This should (and can) be O/S INdependant and should
possibly form part of an "Open Systems" training curriculum. As far as
a POSIX user and programmer cares, there is _nothing_ VMS-specific about
POSIX - that's the whole point of it.
Until the next time,
Stephen
|
| 116.26 | Programmer I may be broken already | CRISPY::SHONEK | Keith Shone UK Edu 830-4074 | Tue Oct 01 1991 04:10 | 21 |
| VMS for Programmers is "stealing" some of the introductory material
from "Utilizing VMS Features..." (gucko) courses.
If gucko isn't broken and we aren't fixing it then VMS for Programmers
is broken. Unless we use the first few hours of gucko to revise?
Last week's two-day train-the-trainer (here in Reading - note 5
reports) for the restructured VMS User curriculum, found VMS for
Programmers not readily deliverable.
We need to get away from product training and more into skills
training and the gucko courses are no exception.
These courses should be in a more workshop style. Enabling not
preaching, practical not theoretical, hands-on not brain-numbing,
exciting not boring.
There is a great need for "How to..." not "This is how VMS does..."
or "By the way VMS has this..."
Thanks for listening.
|
| 116.27 | | NITTY::DIERCKS | But 'ch are, Blanche! | Tue Oct 01 1991 11:23 | 7 |
|
ummm, may I ask what a "gucko" course is? Actually, I'm kind of
skeeeered as to what the answer might be! 8-)
Greg
|
| 116.28 | Gucko is UK born - links with gecko? | CRISPY::SHONEK | Keith Shone UK Edu 830-4074 | Wed Oct 02 1991 04:20 | 16 |
| Gucko originated in the UK. (I taught my first gucko in 1984 and I
believe the term was in use then.)
Andy Sadler probably knows more of its origins than I.
These days the term seems to replace the words "Utilizing VMS Features
from". So we have gucko C, gucko Ada, gucko FORTRAN - you get the
drift?
It just saves a mouthful of words before the critical language word
comes out.
Not to be confused with the similar-sounding gecko. This is a small
lizard that will detach its tail - left as a wriggling decoy - while
the body and brains run off to safety. (On the other hand the parallel
with a gucko instructor is indeed quite striking!)
|
| 116.29 | Surely you don't have other things to do? 8-) | NITTY::DIERCKS | Just being is not flaunting! (stolen!) | Thu Oct 03 1991 13:29 | 8 |
|
Those of us that are concerned anxiously await the official
reply/reaction to the continued displays of concern.
What's the scoop?
Greg
|
| 116.30 | Our customer satisfaction is our business success! | TEACH::HENRY | Pam Henry | Fri Oct 04 1991 10:12 | 33 |
|
In response to the comment in .26 let me restate (again from a
former customer point of view having worked in both a very large
and a very small software shop) that we must be extremely careful
when developing courses that are "skills" courses. Structured
programming takes on quite a range of adaptations even today and
I feel very strongly that we will lose more business than we will
gain by replacing the current Utilizing courses with "How to..."
courses. Larger software shops have generally developed their
own "standards" for software development. Those standards vary
with contractual agreements with various customers. Small shops
don't usally want to "waste their time" in the kind of steps
the structured programming purists take because it is just not
needed.
I teach Utilizing at least twice a month and at least 50% of my
customers are there not because they are writing new software and
necessarily want to use system services, but they have inherited
code laidened with system service calls and they are assigned the
task of maintaining the code and/or making small enhancements.
These individuals have no time or need for a course on how to
document code or any special style technique training.
If you want to offer technique courses and "How to..." courses that
is fine. But do not eliminate the courses that are still in demand
and very much needed by our customers. Are not our customers the
future of our company? And if we offer technique courses we better
make sure they are advertised appropriately such that no student
arrives and is surprised by the course content.
Pam Henry
Instructor, Washington D.C. Training Center
|
| 116.31 | Regarding reply #29... | SUPER::ROUNDS | Kristin Rounds | Fri Oct 04 1991 11:22 | 6 |
| You're not being ignored, Greg. Bill Simcox and I have been talking
about these issues and doing some research, but Andy has been out of
the country and we are waiting for him to come back so we can continue
the discussion with him.
Kristin
|
| 116.32 | | NITTY::DIERCKS | Just being is not flaunting! (stolen!) | Fri Oct 04 1991 12:13 | 7 |
|
Fab!
Thanks!
Greg
|
| 116.33 | Programer II _not_ coming | SUPER::ROUNDS | Kristin Rounds | Fri Oct 11 1991 11:52 | 8 |
| After lengthy discussion about where this course would fit in
the curriculum, and considerable review of the replies to this
note, the funders have decided not to proceed with Programmer
II at this time.
Coverage of the Debugger in Programmer I will be increased.
K.
|
| 116.34 | | NITTY::DIERCKS | Just being is not flaunting! (stolen!) | Mon Oct 14 1991 14:46 | 5 |
|
Bravo! Thanks! I really do think the decision made is a wise one!
GJD
|
| 116.35 | Programmer II on indefinite hold. | CECV03::SADLER | Change for a Flainian Pobble Bead? | Mon Oct 14 1991 15:22 | 31 |
| So now I'm back...
Here's the scoop.
Having weighed the arguments on both sides, I've decided to put development of
the "Programmer II" course on indefinite hold.
We'll be doing some market research and a task- and skills- analysis with our
world-wide customer base, starting as soon as I can find the resources to do it.
When we see the results we'll take another look the Programmer curriculum and
will publish a "whitepaper".
My expectation is that we can do this by the end of this fiscal.
In the meantime I'd like to hear from people as to their ideas as to what is
needed.
CAUTION: Before you submit ideas - please make sure you understand what POSIX is
and how DIGITAL is positioning VMS POSIX! The US Sales Update that will go out
on Oct 26 will have the announcment if you can't find out before then.
OPEN VMS is critical to Digital's survival at its present size. Please don't
dismiss it as marketing hype. Please take the time to understand what it means
to us in Customer Training.
Cheers,
Andy
|
| 116.36 | Too much in Programmer I | TEACH::HENRY | Pam Henry | Tue Oct 15 1991 09:28 | 26 |
| I really don't think anyone suggested not to have a Programmer II
course. Programmer I already has too much in it. My goodness,
we take 27 pages in Programmer I just to tell them how to log in.
It would help students in the Utilizing classes if they came in
understanding the Debugger, Linker and Librarian already. That
way more time could be spent on the meaty subjects. Programmer
II could still work with those topics as well as the style topics.
I have asked my customers in my Utilizing classes if they would
be interested in a style class and they were much more positive
than I would have thought. I am still hesitant to offer style classes
because I think managers may look at that and not want to pay for
that type of course. I think having a Programmer II class with
topics on Linker, Debugger and Librarian would still fit in as
a pre-requisite to a POSIX course. You may even want to introduce
the students to what POSIX is all about in the course but reserve
the POSIX calling standard for the (I don't know Utilizing POSIX?)
course.
The bottom line here is please DO NOT add more to Programmer I without
taking a serious look at scaling DOWN other material in Prog. I.
The course has too much in it now.
-- Pam Henry
Instructor, Washington D.C.
|
| 116.37 | | NITTY::DIERCKS | Just being is not flaunting! (stolen!) | Tue Oct 15 1991 10:46 | 13 |
|
I agree HEARTILY with the previous reply!!!
Also, even though POSIX is surely going to be VERY important to
DIGITAL's future, I think we're kidding ourselves if we don't recognize
that there will be a significant percentage of our customer base that
will NEVER need to take advantage of the open-system concept because
they either are a small shop or an all-VMS shop. We must continue to
provide training for those customers that DOES NOT deal with issues
that don't affec them, i.e., POSIX.
Greg
|
| 116.38 | more thoughts | MELKOR::HENSLEY | ratbag in training | Mon Oct 21 1991 21:19 | 8 |
| Also (as pointed out by my more "Unix-literate collegue"), wouldn't a
customer taking the "Utilizing Ultrix features from <language>" be
getting essentially the same POSIX information? If they can program
Unix, a 1-2 day seminar could cover the differences between Unix per se
and the POSIX course.
(just a typist passing this important thought on!!)
ih
|
| 116.39 | Debugger material | HARDY::ROUNDS | Kristin Rounds | Wed Oct 30 1991 09:44 | 4 |
| Please see note 118.0 for information/discussion about the expanded
coverage of the Debugger in the Programmer course.
Kristin
|
| 116.40 | Maintenance payments ? | UKEDU::HARMER | Geoff Harmer U.K. Edu (830) 6229 | Tue Nov 05 1991 17:00 | 9 |
| It pleases me to see that as a result of the unprecedented response to
this note that things are being put on hold.
It saddens me that no funding for maintenance of the existing materials
has been mentioned...they ARE good but they can be made even better
with more "language features" being used in the examples.
Geoff
|
| 116.41 | What do our customers need? | SUPER::MATTHEWS | | Mon Oct 05 1992 12:50 | 129 |
| Last Thursday, Bill Simcox held a conference call to discuss a new
proposal for Programmer II. (Attendees: Gene Magera, Arnold Tarling,
Marshall Sorkin, Sherry Butler, Clair Garman, Pam Henry, Denise
Borgert, Abby Renfroe, Val Matthews, Mel Regnell, Howard Fletcher, Dave
Killelea)
The consensus was that before building another course, we need to
conduct a survey of VMS for Programmers students to find out what
further training needs they have.
We're conducting a discussion here about what questions to ask them.
I'm proposing some questions (below) to start the discussion. Please
tear it apart or give us a proposal of your own.
Val
I think the survey of VMS for Programmers students should be simple. Note
that the questions are not specific to VMS. Of course Bill would like to be
able to build a successful VMS-specific course, but I think we need a sense
of where VMS lies among our customers' priorities.
1. Other than the features you learned this week, what features
of Digital's software would you like to be trained in?
2. Of the features you learned this week, would you like
to be trained in more detail on any of them? Which?
3. Which other programming courses would you like to take?
[make sure they have the catalog or the latest Digest]
4. Is there a course you would like to take that Digital does not
currently offer? Describe it briefly.
Bill made the point that students don't always know what they need to know,
so ideally we need to get at their managers or project leaders to ask
similar questions.
If it turns out there is demand for a follow-on to VMS for Programmers
(other than the present Utilizing courses), we need to find out what
features are being used today by experienced VMS programmers. We need to
ask a detailed set of questions about their existing applications,
including:
o What systems do you develop applications to run on?
- OpenVMS only?
- OpenVMS and other systems (which?)
(The task analysis contains a partial list of target systems)
o Do you consider your application to have any of these characteristics?
- Transaction processing
- Distributed
- Client/server
- Compute-intensive
- I/O-intensive
- Real-time
- Fault-tolerant
o List the programming language(s) you use.
- If more than one language, give the approximate percentage of each.
- Do you have code in one language that calls routines written
in another language? Which languages?
- Do you write complex command procedures in DCL?
o Do you use:
- VMS debugger? Character-cell or DECwindows version?
- CASE tools?
- (etc. -- the task analysis contains a good list of tools)
o Does your code call:
- System services (which? from which language?)
If $QIO, to what types of devices?
- Run-time library routines (which? from which language?)
- Record management services (RMS) routines (which? from which language?)
- OSF/Motif (DECwindows) routines (which? from which language?)
- Callable utilities (which? from which language?)
- POSIX routines (which? from which language?)
- OpenVMS layered products such as:
DECtp
ACMS
TDMS
DBMS
Rdb
(do I have these right? any others?)
o Do you create:
- Object libraries?
- Shareable images?
- Shareable image libraries?
- Command language definitions? (.CLD files)
- Message files? (Message Utility)
- Site-specific help libraries?
- Site-specific logical name tables?
- VMSINSTAL kits?
o Does your application use any of these mechanisms:
- Parallel processing (FORTRAN, C, or PPL?)
- Vector processing (which language?)
- Interprocess communication in a VAXcluster system?
- DECnet task-to-task communication?
- TCP/IP communication?
- File I/O:
To sequential files?
To indexed files?
Using VMS block I/O?
o Do you write:
- System services?
- Device drivers?
- Print symbionts:
User-written?
User-modified?
|
| 116.42 | | SUPER::MATTHEWS | | Tue Oct 06 1992 14:40 | 1 |
| re .41 Please respond by 10/16.
|
| 116.43 | Comments on 116.41 | TEACH::ABBY | | Thu Oct 08 1992 17:35 | 40 |
| The topics in 116.41 look pretty good to me. However, they seem
to target only programmers on VMS, and I thought we agreed to
also pass out this questionnaire in the C class to cover the POSIX
users who might be targeting platforms other than OpenVMS. In that
case, perhaps the questionnare could contain two parts divided where
Val's note divides.
I also don't think that the students I have had in the VMS for
programmers class could have answered any of the in-depth questions
about the features their code will require. If the idea is to see
if customers use things like block i/o or user-modified symbionts,
the Utilizing and Internals students would be more savy and would
still tell us how popular these features are.
A few additions:
o CASE tools also need to be divided into character cell vs. windows
interface
o include PATHWORKS with TCP/IP
Some possible questions:
o Is your code required to be portable?
o Would you attend programming classes at
DEC that cover software products created by other vendors?
o What percentage of the programmers at your site receive
basic level operating system specific training
general language training
technical level operating system specific training
technical level product specific training
o How many training classes do you attend annually?
o How many DEC training classes do you attend annually?
Abby.
|
| 116.44 | | SUPER::MATTHEWS | | Fri Oct 09 1992 12:55 | 13 |
| I meant in .41 to imply that the detailed questions (the ones beyond
the first four) are not for "VMS for Programmers" students but for more
advanced programmers. Sorry it wasn't clear. Right, the first four plus
Abby's can go to the C programmers too; I forgot to think about them.
If we want to use a student population, right, Utilizing or Internals
students should get the advanced questions. I really think we should
get at a more general population, such as whatever population we would
have used to validate the programming task analysis.
Val
|
| 116.45 | Excellent Start | DLO10::TARLING | | Mon Oct 12 1992 12:20 | 10 |
| Val;
This is an excellent start.
If the "VMS for Programmers" student population is to small during the
sample period recent attendees could be surveyed by phone. Also, as
you mention, the survey need not be limited to students attending VMS
for Programmers.
Arnold
|
| 116.46 | | NITTY::DIERCKS | We will have Peace! We must!!!! | Tue Oct 13 1992 13:07 | 15 |
|
As I read the list of questions a few notes back, I couldn't help but
notice that many of the "answers" to those questions would be covered
in the current Features course.
PLEASE, PLEASE, PLEASE, PLEASE, PLEASE do not duplicate the material
from other courses in the (I feel) unneeded course. Let's spend the
time and $'s getting the other courses up to snuff. Good grief, we
haven't hardly got enough customers to fill the current courses, let
alone MORE.
Please be realistic.....................
GJD
|
| 116.47 | How to listen to your clients | NWGEDU::WIERSMA | Drive a BENTLEY or walk... | Tue Oct 13 1992 14:12 | 39 |
| Hello Andy, Val, Kirsti and many others,
I'm an instructor in Holland and do also a lot consultancy work for
clients. At the moment I'm working on a teleselling project.
I'm reading this discussion. And some of you are wondering if this is what our
customers need. Why didn't you asked them.
In answer to Mary Jo (116.10). If you have a problem with the number of students
in the classroom, perhaps the following is a solution.
In Holland we generated with 3 people in 1 week 160.000 guilders (140.000
dollars) and still we haven't finished our list of customers.
What did we do?
We looked were our number of students was far below the number of the forecast.
After we find out were the problem was. We got focus on 4 strings in the
curriculum.
Then we generated 4 listings from the particular courses. For example: I looked
through (FOBS front office booking system) of VMS Beheer I, II and III (related
to the Sysnet I,II,III courses. So I got a good view which students did not
took the next courses in the curriculum. Then I phoned them or there booking
responsible and asked if there was some interest in a particular course and if
not, what was your experience with the followed course.
Then I asked: "do you have any problems or things you wanted to learn"
Sometimes I could advise a regular course, but I had also the opportunity to
arrange a special made course for this customer. Another solution was the "on
the job" training. Which we deliver on a consultancy based price.
I could also a very good view on what the customers need. Because they told me
there problems and there needs. This information is put into a teleselling
database.
And from this database we collect very useful information for a next training
course. So that if we had a particular course, we know which client is
interested. The customer is very pleased with the way of doing business.
And we don't have problems: like phoning your customer too often etc.
If you're interested, you can mail me.
VAXMAIL : NWGEDU::WIERSMA
ALL-IN-1 : Arjen Wiersma @UTO
With kindly regards,
Arjen Wiersma, DS Holland.
|
| 116.48 | | SUPER::MATTHEWS | | Tue Feb 16 1993 10:59 | 1 |
| See topics 162 and 163 for further discussion of the questionnaires.
|