Conference koolit::vms_curriculum

    I gave Mel some comments, but I want to open a topic for discussion.
    
    When we teach the facilities offered to programmers, we have always
    emphasized the VMS-specific system services & run-time libraries, as
    does this module. I maintain that the VMS-specific approach is a thing
    of the past.
    
    With Digital's current emphasis on open systems, we need to emphasize
    approaches to developing portable code. A programmer taking his/her
    first VMS course needs to be exposed to the existence of NAS; teaching
    the VMS libraries is also necessary but secondary. Digital is
    betting a lot on our customers' acceptance of the "open systems"
    message, and our training needs to be consistent with that message. 
    
    What do you in the field think? Is adherence to the corporate party
    line consistent with teaching programmers what they need to know today
    to get their work done?
    
    Of course we should be addressing this issue in our whole VMS programming
    curriculum, but for now let's just think about this module.
    
    					Val

    Hi Mel
    
    Here are some shredding. 
    
    Lets start by more closely defining our target audience.
    
    In Denmark, programming are more and more often taught on PCs, typically
    using an integrated environment, as Borlands Turbo-Pascal. Anyway
    people that program, are allready educated in the fine art of
    programming when we see them. That means that the part about the
    programming cycle, is a part to skip. However I think it should be used
    in the Advanced application users course, as they may want to know why
    one can not take a program and just change it.
    
    What about the rest? 
    
    Let's assume I am a programmer, and my company has bought a VAX. I have
    been programming PL/1 on a well known typewritermakers biggest
    creation, and I want to get into the VMS-world. I think the same goes
    for the fresh-Turbo-pascal programmer, but he/she does not know it.
    
    What would I like to know (I have seen the editor, and got lost in the
    file system)?
    
    I would like to start from the top. Something about design of VMS, I
    would like to know that is multi-tasking, multi-user and something
    about the client-server. If I came from the PC-world I would have to
    have multitasking explained. Then I would like to have some info about
    reentrancy amd sharability of my programs. If I was a maimframe
    programmer, I would be concerned about how to share data and programs.
    I would probably be asking about TP-monitors and Codasyl-databases (god
    bless them) at this moment. Then I would be interested in the
    development cycle - when will I have to recompile my programs, when
    will I have to relink?? Would I like to know anything about memory??? -
    Only that all memory on a VAX is virtual memory. I mean, if it runs too
    slow it a question for the system gurus, not the programmer!! Modern
    programmers do not have to squeeze programs into 16KB machines, and
    they are usually quite happy about it, so lets keep them that way.  The
    only thing that they have to know is, that there is *enough* memory. It
    is few present that cares if the system uses a black hole, or a
    pagefile to make room. (hmmm Am I being a bit harsh??). 
    
    Anyway I miss a VMS-overview first in the chapter, discussing:
    
    	- Multitasking.
    	- VMS-structure.
    	- Sharebillity, locking, reentrancy.
    	
    I think that a process, should be simply defined as a program with
    ressources, this should take some of the fog out of the part of the
    chapter. Furthermore some illustrations, would remove even more of the
    fog, as it is, the big difference between paging and swopping does not
    come clear. Some of the reasons for "floating look" of the part about
    processes, are that the connections to the rest of the chapter are
    weak, and mainly; a overview to lead into the part is badly needed.
    
    Hope I did not mob you too much
    
    Best
    
    
    JOSS    
    
    
    
    
    
    

    Hi Val 
    
    POSIX and NAS and our adherence to these standard/policies should
    absolutely be mentioned as much as possible. This is a field where we
    have a good profile, that can help to take some of the "What can this
    slow box, with this silly filesystem do, that my old trusty and reliable
    machine could not?"
    
    I am member of the local NAS-promotion team, and are planning to
    integrate a short NAS-presentation in the VMS U&C course that we run at
    the moment.
    
    Best
    
    
    JOSS

    
    Joss!
    
    Thanks for the input!
    
    No I don't feel mobbed at all. I didn't like it myself, but was
    at a loss of what to do otherwise...as I am not a programmer-type
    and that was the outline I had to work with.
    
    I like the suggestions...
    
    Can you send the overview stuff you have about NAS...I will get
    with Val and work something up.
    
    And I like your idea for the VMS overview piece. Great job!
    
    Thanks again.
    
    Mel

    Well...
    
    First thoughts were - if we've got NAS and POSIX (IEEE 1003.%) - can't
    we program how we like?
    
    Second thoughts were - when everyone's fed up with UNIX they'll look
    for a quality production system with masses of tools and ... things...
    and they'll buy a box of VMS...
    
    Anyone writing applications to run on VMS will use system services and
    run-time library routines. With the exception of Ada (thinking of its
    tasking) most languages are more or less inadequate for serious
    applications. Global sections, subprocesses, inter-process comms etc.
    are not features of high-level languages.
    I've done my usual typo/nit pick job on this module. There are some
    comments and observations along the way.
    
    Even for those writing portable software there is no problem
    in isolating hardware specific code. It's supposedly done all
    the time and is a recognised software technique. (That or
    conditional compilation or PRAGMA [Ada]).
    
    I think we should mention some of the basics of the VAX Procedure
    Calling Standard - the call frame and the three methods of passing
    information to foreign routines.
    
    If we could get rid of most of the first day stuff on guckos (sorry
    gucko = Utilizing VMS Features from VAX *) that would give an
    opportunity to get stuck into the doing part of the course properly. 
    (I speak without experience of delivering this course at VMS V5!)
    
    Sorry I've rambled rather...
    
    I'll give some more thought to this module. Thanks for the opportunity
    to pass comment. I found much that was worthwhile in the text.
    
    -- Keith
    
    Page	Observation
    ----        -----------
    
    15-5	Bullet 3: facitlities -> facilities
    
    15-8	Last line: other operating systems to execute?
    		Was this hinting at Digital Standard MUMPS or a hitherto
    		secret project to run an OS on top of VMS?
    
    15-10	Bullet 3: processes can execute -> processes execute
    
    15-11	Third heading: Interdependance -> Interdependence
    
    15-12	Last two bullets: need to distinguish here between
    		what happens when an interrupt occurs and what happens
    		when an exception occurs
    
    15-13	Process States: A process can be in one of several possible
    		states:
    		A process is always in one state
    
    		CUR state: on machines with more than one CPU active
    		there can be two or more CUR processes, can't there?
    		
    15-14	Bullet 3: this virtual address statement is difficult
    		to understand first time through. Needs rephrasing:
    		A process' virtual address space is mapped to physical
    		addresses
    
    15-16	Middle of this page launches into access modes. 
    		Strictly, it talks about the four stack, Kernel,
    		Executive, Supervisor and User.
    		Either we omit mention of specific stacks or we include
    		some non-technical discussion of access modes and
    		their purpose.
    
    15-23a	There are several kinds of record in RMS!
    		We should also mentions vfc and stream or state:
    		"Two of the most common record types are:"
    
    15-24	Line 4: "...types of library:"
    		Bullet 3: "...reads help libraries."
    
    15-26a	and again on 15-28a:
    		End of fifth paragraph needs some supporting text, I think:
    		"...use the /NODEBUG qualifier when you execute the image."
    
    15-28	Bullet 1: The VMS Symbolic Debugger DOES NOT detect
    		logic errors! It helps us mere mortals to detect logic
    		errors
    
    15-30	Instead of saying "login" file let's use something like
    		"debugger initialization" for that is what it is.

       Hi Mel (reply to *.4)

       I there is a problem doing long-distance criticism, as you
       have absolutely no feeling if your stepping in sombodys
       softice, or everybody is cool. Well - you will find out,
       but then it is usually too late. Things like this should
       in reallity be done over a barrel of something drinkable.

       Back to the present -- My NAS overwiev is in Danish!  I
       know that it is a language that is not spoken by a vast
       majority of the worlds population, so I will get the old
       dictionary going and get it translated. I think it is
       strange that it is so, I mean - I learned it in just 1
       year! when I was very young, so I could probably learn it
       even faster today! 

       Best 

       JOSS 

Here is my opinion on the "VMS for Programmers" course :

Let me start with explaining what we are doing at the moment in the 
Netherlands with the "Utl. VMS features" course :
We felt that this course has two groups of intended audience :
1. Programmers on VMS who are going to use a 4GL (or e.g. one 
   of our Information Architecture products) language for developing or
   maintaining programs
2. Programmers who are going to write applications using system service and
   run-time library routines.

At the moment the "Utl. VMS features" course is designed for group 2.
Some parts are interesting for group 1 too. This is the reason why in
The Netherlands this course is split up in two parts, where part 1 is for
both groups, part 2 is only for group 1 :

part 1 : "Basic programming on a VMS system" (2 days) contains : 
         1. Program development overview
            - software development tools (positioning of VMS services,
              program development tools, VAX languages, Software Productivity
              Tools and Information Management Products)
            - Program development cycle, incl. the Symbolic Debugger
            - The VMS programming environment (process, image execution,
              paging, swapping)
         2. Calling procedures
            - VMS Procedure Calling Standard (call by value/reference/
              descriptor)
         3. Record Management Services
            - Files, records and fields (file organizations, record formats)
            - RMS utilities
         4. Sharing code and data
            - Libraries
            - Shareable images
         5. System routines overview (overview and positioning of :)
            - VMS System services
            - Run-Time Library
            - Utility routines
            - RMS services
         (By the way, this course contains more or less the items mentioned 
          in .2 and some more)
            

part 2 : "Programming utilizing VMS features" (3 days) contains :
         1. Synchronizing process activity
            - Time and time conversion
            - Local and Common Event flags
            - Asynchronous System Traps
            - Lock Manager
         2. Accessing devices
            - $QIO
            - Out of band AST's
         3. Creating/managing other processes
            - Hibernation/Suspension
            - Create and manage sub- and/or detached processes
         4. Communication between processes
            - Logical names
            - Mailbox
            - Global section
         5. Handling exceptions and exits
            - VMS Condition Handling Facility
            - Exit handlers

For insiders : Part 2 contains the modules 3,4,6,7 and 9 of the
"Utl. VMS features" course, Part 1 contains some material of the other modules, 
but some extra chapters and parts are added.

So, when I see the developments of the VMS for Programmers course, I would
make the following remarks about the additional chapter on 
VMS Programming facilities :


* It contains a lot of overlap with as well the "Utl. VMS features" as the
  "Basic programming on a VMS system" courses

* I think it contains too much for a programmer who is working with VMS
  FOR THE FIRST WEEK !

* In my opinion such a chapter should contain :
  - Program development cycle (pages 15-6 and 15-7), explaining also the 
    possibilty of the VAX Linker to 
    * use more than one object-file 
    * use modules from an object-library
  - Object libraries (pages 15-24 and 15-25)

  That's it !

By the way, I think the intended audience for this VMS for Programmers course
will be that small in the Netherlands, that there will be no special course 
for them. After the courses "VMS for application users" and "VMS for advanced 
application users" these programmers can do the "Basic programming on a VMS 
system" course, followed by 
- "Utl. VMS features from VAX *" for the gucko's (quote from .5, not from 
  myself)
- a programming course in one of our Information Management products


At last my opinion about NAS, POSIX, etc. :
Of course you can mention these. But you have to realise the INFLUENCE of
the knowledge of these items on a programmer on VMS system. In my opinion
the influence is very small. The only thing programmers should care of
is when they have to write portable code. In that case I always tell my
students not to call system-specific routines directly but from within
other routines, which have to be re-written for other systems.
And for the rest it is nice to know and to realize that VMS is developing
in the direction of POSIX (I hope), but it's not that very important for
a programmer. By the way, Joss, I'm really interested in getting a copy
of your (translated, I'm sorry) NAS-presentation.

I didn't mean to be negative, but I hope my remarks will cause a 
discussion leading to a good result !

Bart Aartsen
    

    
    Thank you all!
    
    Don't see anything 'negative' about any of these comments, just
    a lot of really honest and useful discussion.
    
    [Having said that...]
    
    I am putting together a "new" course outline for this piece. Your
    feedback was good enough to make us re-think the whole course. I will
    post it here by next week sometime.
    
    Thanks again.
    
    Melinda
    

    
    Folks,
    
    The instructor reviewing this course has made an interesting
    suggestion. I would like your thoughts on it; I think it might really
    be worthwhile.
    
    He has suggested that given:
    
    	1) By the time you get to chapter 15 you will have little
    	time left to even give the items in that chapter a cursory
    	coverage
    
    	2) A major complaint he has found in classes of beginning
    	programmers is the lightness of coverage of a multitude of
    	topics
    
    That:
    
    1)We make a nice little table of the facilities covered with pointers to
    doucmentation and courses that can give a programmer the detailed view
    on them .
    
    2) We convert the last chapter to a working overview of the debugger.
    
    The reasoning being that we can't cover all the other stuff on day 5
    anyway, and that by really doing a hands-on intro to the debugger we
    can the new programmer a tool they can walk away and use.
    
    What do you all think?
    
    Mel
    

    Mel,
    
    Such a long time since I saw these materials I'd forgotten we were
    doing this course ;-}
    
    The debugger needs, at most, about a quarter hour of overview followed
    by another quarter hour of demo then a half hour of scripted lab.
    
    Something like:
    
    1. Copy from COURSE$LABS the program DEBUG_DEMO for the language of
       your choice - .BAS, .C, .FOR, .MAR, .PAS
    
    2. Compile (or assemble) the program. Hint add /NOOPTIMIZE to the 
       compiler command as well as /DEBUG
    
    3. Link the program using the /DEBUG qualifier to the LINK command
    
    4. Run the program
    
    5. Hit the PF3 key on the keypad
    
    6. Hit KP0 on the keypad
    
    7. etc etc
    
    A run through the basics:
    
    	- EXAMINE
    	- DEPOSIT
    	- displaying and removing the, say, REG display
    	- setting a breakpoint or two
    	- typing some source lines
    	- using a debug log file
    	- resubmitting a log file
    	
    enough?
    
    I agree with .10. Here in the UK we've a saying/cliche - never mind the
    quality feel the width. We could adjust this to:
    
    	never mind the might knows do the must knows
    
    (or never mind the width feel the quality!)
    
    It comes back to a frequent discussion on depth/detail. Instructors
    really MUST know where to stop. Pre-empting further training or other
    courses is bad practice. "Beyond the scope of this course" is perfectly
    valid.
    
    On debugger specifics - you might like to include at least one simple
    subprogram in the demo program. I've found an amazing lack of awareness
    of the DBG> STEP /INTO capability. 
    
    Still do it in an hour? I think so :-)
    
    -- Keith

    In preparing to teach the VMS for PROGRAMMERS I course next quarter
    I have found a few typos and errors in the instructor manual.  I
    have enclosed the ones that I have found to date but I have not
    had a chance to finish reviewing the materials.  It would be helpful
    and also display much better quality to our customers if these problems
    could be fixed ASAP.   They are as follows:
    
                Corrections to VMS Programmer I Student Guide


	1.  Page  7-21 - This module just ends on the instructor page
		         for this module.  It seems that there are
		         several pages from here to the end of the 
		         module missing.

	2.  Page 11-42 - In the second example of F$PARSE the word
		         version should be in "" and read "version"
			 Also the resulting symbol is ";" not the
		         full file spec as shown.

	3.  Page 12-15 - In the first paragraph the last word should
			 read "values" not "alues".

	4.  Page 13-13 - The symbol "C" used in the A.COM command 
		         procedure is described as a global symbol
		         but written as a local symbol.  The command
			 procedure line 5 should read "C == P1 + P2".
    
    
    
    				Pam Henry
    				Washington, D.C. (EKO)

I've posted this elsewhere but am putting it here for those who came
in late...

The "VMS for Programmers" instructor guide (compressed) is in
SUPER::ES$INSTRUCTOR_GUIDES:EY-G992E-IG-0001.PS_LZ.

(It went through final publishing, but Kristin is adding a new chapter on
the debugger; that's up for review in topic 118.)

					Val
    

    Does "final publishing" mean that we are not going to fix errors
    in the materials?  I would hope not.  Those of us that face the
    students week after week are constantly taking the fall for poor
    quality materials.  In addition to the typos and errors mentioned
    in Note 31.12 I have found a few additional errors.  I would hope
    they would get some attention.
    
    Page 9-35 - "edti/tup" should be "edit/tpu"
    
    Page 10-19a - The 3 lines regarding editing a file that was not
                  closed is not correct.  If you try to access a file
                  that was not closed in a command procedure you get
                  a message "file currently locked by another user".
                  You must either close the file or log out and back
                  in again to delete your process and have VMS close
                  the file for you.
    
    Page 15-7 - WSLIM should be WSDEF in the second to last line.
    
    Page 16-7 - Under the $ LINK ECHO it says the file type is ".OBS".
                This should read ".OBJ".
    
    With word processing what it is today these should not be hard things
    to fix.  Most of them are straight substitutions that should in
    no way hurt paging or anything else in the document.  Aren't we
    a leading edge computer company?  Aren't we trying to build a future
    for this company?  If we are we need to be more careful and strive
    for a little higher quality than we "have always done" if we are
    to win out over our competitors.
    
    			-- Pam Henry
                           Washington, D.C. Training Center

    The republished "VMS for Programmers" instructor guide (with the
    debugger chapter) is now in
    
		SUPER::ES$INSTRUCTOR_GUIDES:EY-G992E-IG-0002.PS_LZ

    

    
    Re .14
    
    It is not the editing that is the issue...it is the manufacturing
    that causes the bottle neck. We can make those changes today...
    and you will not see them until Corporate Marketing decides to
    issue a new rev of the course.
    
    We do not control how often courses are re-issued.
    
    Mel

    
    
    Not to be a butthead here, Mel -- but why do such obvious errors make
    it into the materials in the first place?  I think that's the real
    frustration we have as instructors.  What's with the "proofreading",
    etc.  The new materials are SO MUCH better than previous materials, but
    these marketing folks who make the funding decisions seem to sometimes
    forget that we have REAL CUSTOMERS who PAY BIG $'s to take these
    courses and who EXPECT THE MATERIALS TO BE CORRECT THE FIRST TIME.
    
    (Am I yelling???????)    8-)
    
    	Greg

Re: .17


>    etc.  The new materials are SO MUCH better than previous materials, but
>    these marketing folks who make the funding decisions seem to sometimes
>    forget that we have REAL CUSTOMERS who PAY BIG $'s to take these
>    courses and who EXPECT THE MATERIALS TO BE CORRECT THE FIRST TIME.

NO I DON'T! 

I expect that the materials will be as good as humanly possible, no
more, no less. My experience leads me to believe that reasonable people have
similar expectations.

Compliments of the Season,

Andy 

     
    Re 31.15; 
     
    Does anyone know a pointer to the course files "EY-G992-KA-0002"?
     
    Thanks,
    Arnold Tarling
    

    Is this the final version of the book for instructor. Where is the
    student guide. Some of our site would like to use it for class as pilot
    run. Please tell me the location for the final version. If this is not
    final version , when it will be released.
    
    Thanks !!!! :-)}
    
    
    Raphael

    
    
    I consider myself a reasonable person -- with a tendency to expect
    perfection of myself.  
    
    I'll say again, I really DO LIKE the materials in their present form. 
    My comments, Andy, about funders, really weren't aimed at you,
    personally.  It has become increasing apparent that quality of
    materials developed by "your group" is far superior to the other groups
    with which I deal.
    
    I apologize for what, I'm sure seemed like, the personal attack.
    
    	GJD

    	{HARDY,SUPER}::ES$MEDIA:[EY-G992E]PRGMR1020.A

    re .20 Yes, this is the final version. The student workbook is in the
    electronic warehouse and can be requested through channels.
    
    					Val

    
    Gregg,
    
    {Would I _ever_ call you a butthead?} [hug]
    
    Anyway, now that you have apologized and lavished us with at
    least oblique compliments....[I am going to cast your note in
    bronze...] Let me add a comment to your original question...
    
    Mistakes get into materials because people [the human kind]
    are basically responsible for the error checking and proofreading.
    They do an unbelievably superior job considering the number of
    pages and courses they are expected to handle...sometimes
    simultaneously...almost always under immediate deadline pressure.
    
    My release engineer [and, yes, you better belive I think of her
    as mine and if any other development group tries to steal her
    I will hire a hit man...] sometimes is handed a 900 page IG to
    proof and final build in less than 48 hours...factor into that
    little equation the FACT that DOCUMENT will take anywhere from
    10-16 hours to actually produce the document...and the FACT that she is
    simultaneously doing the same job to two or three other courses
    in the same time frame...and I think she walks on water!
    
    It is funder's like Andy...who are willing to publicly support
    and recognize these kinds of efforts that result in people like 
    her being willing to work nights and weekends just so we don't miss a
    deadline...this really _is_ a team...
    
    A few weeks ago, when Andy's group was moving, he requested that
    a course be delivered early. [EARLY!@!!!] We went into a tail spin...
    we had a meeting...we [read that me and my boss] we ready to go back
    to Andy and say "Sorry...no way...". The person who stood up at that
    meeting and said "Look, Andy is a good guy and bends over backwards
    to help us out and we should deliver this one favor..."...the person
    who said that...was the release engineer who was going to have to work
    Saturday and Sunday to make it happen. It wasn't a developer who had
    to be in here...
    
    Yes, I know I am soap-boxing. And I know that the issue of errors in
    material will not disappear because of one good-person story...but
    I think it is terribly important to remember that we are mostly all
    [you never know where you may find a robot] people trying our very
    best to deliver quality materials. We _want_ you to like them...
    it doesn't feel good when we get bashed about them...we prefer to
    produce stuff that you like...really. And we are people...mistakes
    will get by. Very few we hope! But a few...probably.
    
    Mel [end-sermon...sorry....]
    
    
   
    

    
    
    Mel,  and  all.
    
    I'm sorry it's taken me so long to reply, but I've been  on the  road 
    for what seems like weeks (before and after  the   holidays).  (And
    I'm writing this  from a terminal with a sticky space bar!)
    
    I've  spent some  time in the  last month  or so starting,  at least,
    to get  ready for the  first teaches  of  SYSNET I,  II and III.   I'm
    more frighted by these new courses  than  by  any other  courses I've
    ever taught.  That fright  IS NOT  because of the quality  of the
    materials.  It's because I'm not  convinced the new  courses  are 
    being  marketed correctly  and that, therefore, students are going to
    have unrealistic expections.  In an ideal world,  all students would
    have read the course descriptions before they ever  get  to class. 
    But, remember that the VAST MAJORITY of our students do not  schedule
    themselves for courses  but are, instead SENT to courses by their own 
    management.   
    
    Think about  it.  You are  a "new"  VMS system  manager.  You are being
    sent to a course called SYSNET I.  Is  it  really  an  unrealistic
    expectation to assume that you will learn at least something  about 
    network management as  a result  of  attending the course?  I don't
    think so.  Let's  face it, SYSNET I is little more than the  old  U&C I
    course  (greatly  cleaned  up) with a module  thrown  in about how to
    run authorize.  The title of the course DOES NOT  reflect the  content 
    of  the course, and that frightens  me.  
    
    Further, after browing through the (finished?) versions of  I, II, and
    III,  it's  my impression that a number  of the very important topics 
    that appeared somewhere  in the old  U&C  I & II, MRG  I &  II, DECnet,
    VAXcluster and performance  courses are  nowhere to be  found.  (I 
    realize  there will be  a "new" performance course, and  maybe that's
    where these topics will end up).  Where's the detailed discussion of
    non-paged pool?   Where's  the detailed discussion  of the lock
    manager?  I'm  concerned  that in the  effort to lessen the number  of
    courses, topics have  been  left out.
    
    Finally (then off my soapbox...), was  it not  the case that at least
    one of  the reasons   for the  new curriculum was to lessen the  number 
    of  courses  students have to take?  I would  claim this  goal has 
    only partially been achieved.   There  is no longer, for example, the 
    great amount of overlap bettwen U&C II and MGR II.  But it appears 
    there will still be five courses  necessary to get the same amount
    of material.
    	
    	SYSNET I, II, III, a "cluster class", and a "performance class"
    
    When Val was in the Chicago training center last quarter I got the
    impression these last two were under consideration?
    
    I  guess my point  is I'm not  sure what this new curriculum buys us,
    the  instructors.  We've taken what were very homogenous  topics and
    spread  them out over several courses instead of leaving them in a one
    week "let's talk about DECnet" or "let's talk about Clusters" course.  
    
    It boils down to this, for me:  I'm not really  concerned about the 
    materials.  I'm concerned about the whole design of the curriculum.
    And, it's  probably too  late to do anything about it.  I really,
    really hope I'm wrong -- and will be the first to admit it if I  am. 
    But, honestly, I have a really, really bad feeling about the whole
    thing.  And, I know I'm not the  only one who feels  this way, but
    maybe am the only one mouthy enough to say something about it.
    
    Regards,
    
       Greg

    In support of .25 and .26 let me add the following from my first experience
    with "VMS for Programmers":
    
    I believe that we may have a mismatch between what is in the course 
    description for "VMS for Programmers", and the students expectations.  
    On page 8 ,of the "Master Series" section, of the current digest we have 
    topics such as:
  
    1. Organizing Files
    2. Working With Files
    3. Protecting Your Data
    4. Customizing Your Working Environment
    5. Handling Input and Output.
   
    To the Utilities and Commands instructor or student these topics are 
    understood to deal with:
  
    1. Placing files into subdirectories.
    2. Most anything
    3. The file protection mask (RWED)
    4. Defining symbols, logical names, and keys
    5. Simple open, read, and write statements in "DCL"
  
    With a course title "VMS for Programmers", I believe, that we create a 
    somewhat different set of expectations.  About a third or more of my 
    class perceived these topics to mean:
  
    1. Dealing with file organization, ie (Sequential, Relative, ISAM)
    2. "Programming" operations with files
    3. More than the simple file protection mask (How do I code this??)
    4. More than symbols, logical names an keypad definitions
    5. Actual "I/O programming" (non DCL)
  
    Couple this with this quote from page 8 (Mastery Skills Section) of the 
    digest:
  
    "Leap from VMS novice to competent VMS application and system software 
    developer - ready to take advantage of the rich facilities of the VMS
    programming enviroment! Because all course participants are programmers,
    you'll quickly cover essential VMS user skills, including the Digital
    Command Language (DCL). You'll then be ready to focus on 
    programmer-specific skills including memory management, the VMS program
    development cycle, system routines..."
  
    This goes on, but the overall impression a student gets from the digest 
    is that VMS programming is going to happen (Not limited to DCL).
  
    My pertinent QA comments (from the 1/6/92 course) are summarized below:
  
    1. "The description in the training guide did not represent the actual
       materials covered in the class. The description of the class made it
       sound like a class more for programmers rather than TOTAL BEGINNERS
       (caps mine)..." "I felt that all this class dealt with was a sales
       pitch for DEC. And a way of trying to enroll one in more classes".
  
    2. "From the description of this course, I, as well as some of the other
       students were disappointed with what was actually taught. Also for the
       price, I can not recommend this course."
  
       The class passed and most students were satisfied, but I do believe 
       that we have a potential problem here.
  
   Arnold.
    

Greetings!

  Just finished the first teach out here of "VMS for Programmers" last week
and for what it's worth here a few observations/comments...

First the audience:

  Initially I had 12 students; however upon opening up the student guide and 
listening to a short (5 minute) synopsis of the topics to be covered 5 of them
(who had taken at least U & C I and SYSMGR I), quickly decided they wouldn't 
learn anything new, (except for the last (optional), chapter on the Debugger).

  Since three of them mostly wanted more on Command Procedures and DCL, I shuf-
fled them over to a U & C II class that had just started.  The other two wanted 
to learn how to program, (but didn't indicate a particular language), and after
explaining to them knowledge of a programming language, (3GL), was a prerequi-
site for this class they too joined the others in the U & C II class.  Now my 
audience is mostly composed of people who at least won't hear U & C I all over 
again with pieces of U & C II/SYSMGR II thrown in.  So far, so good...


  Now of the 7 remaining:

  The first student had been using VMS, (and acting as backup system manager 
occasionally) for over 3 years.  Although he had no formal DEC courses he 
thought he might still benefit by "rounding off some of the rough edges"...
Programming Language(s): none
Programming Background:  none

  The second student had been an operator for DEC on some in-house system(s) 
for over 5 years somewhere back east and wasn't too sure why they were here...
Programming Language(s): none
Programming Background:  none

  The third student only really wanted to learn more about a 4GL I'd never
heard of, didn't program at all in a 3GL, (but did indicate they had taken a
FORTRAN class back in school, (which was a lloooonngg time ago...)).  Registra-
tion had told them that this class would fulfill their needs in "learning how
to program on a VAX...".  The only other expectation stated was to learn a 
little about what you could type at the DCL prompt other than: "RUN mumble" 
or "@mumble".
Programming Language(s): see above
Programming Background:  see above

  The fourth student was fresh out of school, (literally my class was their
"3'rd" day on the job).  Had experience on an IBM system, (didn't specify 
which), and their company was in the process of replacing another vendor's 
system(s) with VAX/VMS system(s).  Indicated that ultimately they would be 
supporting existing applications and/or developing new applications written 
in COBOL.  After reading the course description, and seeing words like 
"Managing Files" and "File I/O"  they assumed they would learn about the file 
system on VAX/VMS and were curious how "indexed" files worked.
Programming Language(s): COBOL
Programming Background:  (academia only)

  The fifth student had been a "system programmer", (their words, not mine), on
a CDC Cyber forever, but all that stuff was being phased out and replaced with
newer, (DEC presumbly), equipment.  From initial statements, this person didn't
want a "keystroke" class at all, but really wanted an "architecture", (prefer-
bly comparing VAX vs CDC), but was told by registration that this class would 
cover the "architecture" of the VAX...
Programming Language(s): BASIC,COBOL, and a "little" FORTRAN
Programming Background:  see above

  The sixth student was told that VMS for Programmers was the same thing basic-
ally as SYSNET I and since they were enrolled for SYSNET II the next week, (and
my training center wasn't doing a SYSNET I class first), figured after talking 
with registration this course would fill the need, (which we know it doesn't 
since NO mention of "Authorize", "System disk directory structure", "Image 
backup's", etc. are made in this class but are assumed in SYSNET II).  Student 
indicated they wanted to learn how to configure and manage DECnet...
Programming Language(s): FORTRAN
Programming Background:  see above

NOTE: I find out this week from the instructor teaching the SYSNET II class
what this student really wanted was how to use the $QIO system service in con-
trolling a custom controller in a "real-time" application for their company...
At this point, two weeks of time/travel/money invested by the student, (from
overseas yet!), hasn't answered any of the issues they were told would be ad-
dressed in the class(es) they had enrolled in...

  The seventh student was a scientist by training and experience but over the
last few years had fallen into the role of backup system manager and wanted to
"fill in the gaps".  They too had been told that this class was "the same thing"
as SYSNET I and hence would provide the prerequisite for SYSNET II...
Programming Language(s): none
Programming Background:  none

----

Now here's my 2 cents worth...

  First a disclaimer; no comment is meant to offend.  I know we all, (instruc-
tors, registrars, developers, etc.), are often given unreasonbly short periods
of time with less then adequate resources to achieve the impossible.  In truth
I know as do most instructors in the field that "we are stuck" with this, so
we all have to make do, and tap-dancing on Monday mornings (and indeed through-
out the week), is why they "pay us the big bucks".  In all fairness to the de-
veloper(s), I can't whine too much about content because (like many of us in 
the field), by the time I'm even aware of course content in detail, the "window
for review/feedback comments" was yesterday... (As I'm sure others have stated,
the instructors I work with only do "review" at nights/weekends/holidays and at
that only after the work we are goaled on is done and the training center is 
ready for "Monday morning").


  Now on to business...

  If this class is targeted for people who "have never seen a VAX" but ARE 
"programmers", something has gone terribly wrong in one or more of the fol-
lowing areas;

		- Student's ability to comprehend course descriptions
		- Student's ability to comprehend course maps
		- Registrar's ability to field questions re: course descriptions
		- Registrar's ability to comprehend course maps

  If this class is NOT a synonym for SYSNET I, then why is registration telling
our customers this?

Solution(s):	Let's get real customers, (students NOT their managers), to-
		gether for a serious critique of our course descriptions.  Is
		"what they perceived we said" equal to "what we meant to say"?
		If not, then let's rewrite the silly thing...
		In general, "we", (i.e. developers, instructors, folks who work
		for DEC), "know" what we said, but "we" are not the ones who
		pay "our" bills.  It never ceases to amaze me how two people,
		(even with "similar" backgrounds), derive totally different 
		meanings from the same piece of paper with the same words on it.

		Let's review exactly what a registrar can and cannot adlib
		when queried by a customer, (make any scripts used by registra-
		tion for this purpose available to the instructors who know
		what will and won't be covered for correctness).  NOTE: The
		lack of "feedback" from the field already prevalent on course 
		material(s) has to be addressed by management both in the field
		and back EAST.  Without recognized and dedicated time devoted 
		to this task, it too will end up "at the bottom of the list of 
		things to do"...

  If this course is for "programmers", then shouldn't all the DCL stuff like
defining keys, lexical functions, command procedures that do file I/O, symbol
overlays, etc.  be left out?  Personally I love this stuff and being both a big
user of DCL and instructor of U & C II when it was still called "Advanced VMS 
Features and Techniques" I'd love to show off, (but NOT to "programmers"). This 
stuff is "nice to know" but it doesn't help a programmer one bit in understand-
ing "how to" develop programs, what system routine(s) are available and how to 
code with them, purpose of and using the "calling standard", how to create and
manage libraries, (especially help, object, and shareable image libraries), from
DCL or within a program.  At best, I believe we should cover just enough DCL 
to let them automate the "compile-link-run" and leave stuff like creating com-
mand procedures that use lots of lexical functions and doing I/O to terminals 
and files for the U & C II class.  While my "programmers" thought these fea-
tures of DCL interesting they pointed out that it didn't really relate to the 
life of a programmer.  One pointed out that a "real programmer" would be insane 
to do file I/O with DCL given the overhead involved of doing this in an inter-
pretive environment like DCL.  In a nutshell they weren't going to (re)write 
complex command procedures developed by others like the system manager and their
jobs required only minimal command procedures (i.e. the LOGIN.COM and the "com-
ile-link-run").  The use of symbols as variables, use of lexical functions,
overlays, (arithmetic or string), didn't apply since they weren't likely to
need/use/develop complex command procedures.  Needless to say the topic of sym-
bol substitution, (which I love!), completely eluded them.  The topic of passing
a parameter, (in order to write the "compile-link-run", was the only thing that
garnered any interest.

Solution(s):	Barring a rewrite of the student guide in the near future un-
		less the majority of my next class really want a "condensed
		U & C II", (where DCL is and should be the focus).  I'm going
		to give short shrift to this material and adlib if necessary
		on things like the I/O sub-system, RMS, the Calling Standard,
		families of and format of the 4 classes of system routines.

		I think more time spent on learning to use an editor in more
		advanced ways would have been very well received.  NOTE: I did
		20 minutes on LSE off the top of my head at mid-week and the im-
		mediate reaction was "This is great! Forget EVE or EDT!  We
		want to buy this!  What's the part number and how much is it?"


  Other than pointing them to the "Intro to System Routines" manual, the "Guide 
to Developing Modular Procedures" manual, the "Intro to System Services" manual 
and giving a "lot" of "please read these sometime" assignments, (which I suspect
they won't do in the future), the students aren't "able to fully exploit the 
power of the programming environment of the VAX"...

Solution(s):	Actual time spent with either the RTL, System Service, RMS, or
		Utility Routines Reference Manual(s) would have proven useful.
		Ideally I'd like a full Programming Subkit for every two stu-
		dents right by their terminals, (I don't know where we'd put
		them!), so maybe...

		Perhaps include a few sample pages from the System Service
		Reference Manual starting with the "table of contents", follow-
		ed by the writeup on 2 or 3 routines, followed by the index
		so they can learn how to "navigate" through the documentation.
		NOTE: Even in "advanced programming" courses, most students
		are hopelessly lost in getting quickly to the appropriate pages
		in the Programming subkit!

  The only modules truly pertinent to (specifically) a programmer, (vs a "user"
or a "manager"), are left to Friday when most of them, (after 14 or 15 modules),
were so burned out I could have stood on my head and they wouldn't have noticed.
Topics that are currently assumed knowledge or at best given a real quick review
by the time a programmer takes one of the "Utilizing ..." class(es) are left out
entirely or left for a couple of hours on the last day of the class.  The one 
module truly specific to just a "programmer", (i.e. the "Debugger"), is OPTIO-
NAL?, (in a "Programming" class???)).  NOTE: This was the only module my 5 ori-
ginal students, (who shuffled over to U & C II on Monday), wanted to come back 
for.

Solution(s):	Again, by dumping, (or paring back a lot), on all the fancy DCL
		stuff the "programming" topics could be introduced before total 
		"burnout" takes over on Friday.

		I think time explaining the Linker would have helped a lot.  An
		explanation of basic steps taken by the Linker to resolve re-
		ferences would be in order.  Explain "PSECT", "ISECT", "Image 
		Header", "Image Body", (which is done nicely in the "Instruc-
		tion Set/MACRO" course on Friday).  An introduction to (at 
		least the concept of), shareable images would definitely
		prove useful before they take "Utilizing VMS ..."

		One thing I know is very well received in the "Instruction Set/
		MACRO" course (and NOT explained in other, (3GL), language 
		course(s) is "Use of listing/map files", (especially as it re-
		lates to troubleshooting).

		By Friday "image", "program", "process", "object module", and
		"library" were getting (more) confused.  It's too late by then
		to back-paddle over material that should have been introduced
		before mid-week but is left off entirely or mentioned only in
		passing on the last day.

  For the students who "had never seen a VAX", but WERE "programmers", it was 
universally concluded by Wednesday that there were too many topics in too little
time with not enough time for labs.  NOTE: If I believe the timings presented in
the Instructor Guide for this class I should have lectured no more that 3 or 3.5
hours a day, in practice I lectured 5 or more hours each day just to cover, 
(and in some areas very superficially in my opinion), the chapters, (all 17 of
them by Friday...)

Solution(s):	Again, this class is for "programmers".  Bombarding them with
		(mostly) a lot of DCL stuff only confuses and doesn't help 
		them in their goal of "learning to program in the VAX/VMS en-
		vironment".

		Much as I hate to just "flip past" pages in the student guide,
		I have to "flip" over 400 of them in under 5 days.  Assuming
		I skip stuff like introductions, objectives, (experience has 
		shown this to be a BAD idea!), summaries, etc., I've got an
		average of 109 seconds to cover each one.  I must confess I
		feel caught in a quandary; "flip pages", (approx 1 every 2 min-
		utes), and the comments are "instructor just flipped foils", on
		the other hand if you develop a discussion on even 50% of them
		that is longer than 4 or 5 minutes, you not going to finish!

  For the students who "had been using a VAX", but were NOT "programmers", the
the first 13 modules bored them out of their skulls.  I personally agreed with
this sentiment, (after all who cares about "what" happens in order to get logged
in, just give me a username, password and a node that's booted).  As users (and
programmers), the topology of terminals, terminal servers, nodes is beyond their
control anyway.   Unless you have never used computers before, "HELP" is hardly 
worth more than a passing "yes we have some...".  Only the briefest, (again the
"yes we have some..." approach to MAIL, (why omit PHONE?), is appropriate.  No-
one understood the idea of an "operator", so "REQUEST" was a waste of time.

  More time spent on managing/protecting files would have been more useful.  I
guess sub-directories really are mysterious.  Ditto for protection codes.  I
like the locally developed lab for U & C I to get idea of (sub)-directorie(s)
across.

  The editor(s) were generally well received by all, but I didn't see any "ad-
vanced editing topics" in my student guide.  Again, if this class is for "pro-
grammers", then at least mention of some/all of the VAXset tools, (especiallly
LSE), would be appropriate.  NOTE: The only mention of section/command files for
use by a TPU based editor, (like EVE), isn't even in the chapter on editing!

  As previously stated, leave out/severely curtail the stuff on lexicals, sym-
bols, (other than as command synonyms in a LOGIN.COM), arithmetic and binary 
overlays, symbol substitution, advanced command procedure topics like terminal
and file I/O. As a possible "command procedure project", maybe have the student 
create the "compile-link-run" procedure if they want to tackle something more 
sophisticated than a linear, monolithic LOGIN.COM.  NOTE: I supplied one I 
developed for my own use years ago and no one looked too confused after reading 
the comments.

  More time spent on logical names/logical name tables, search lists, search 
order might be appropriate.  They need to have access modes explained ala the 
"System Architecture" class before hand though, (especially if they want to 
create logical names/tables under program control when they get to the "Utiliz-
ing VMS..." class(es)!).  I've given up trying to explain "/USER" to people who
invariably ask "as opposed to "/WHAT_ELSE"?" without doing this.

  In conclusion while the class passed, (going by the SOF's), it wasn't what 
the customers expected, nor did it fulfill their needs so that they could 
tackle a "Utilizing..." class with more than lots of DCL skills under their 
belts.  The one comment I got (verbally and by reviewing the SOF's) that I had
NEVER seen before, (I've been teaching the programming curriculum for over 6 
years), is several students would NOT have recommended this class to others.
(A personal first!)


							Tony Swierkowski

    
    Instructors of VMS for Programmers please help!  I am prepping for
    this class and having never taught UC1 or UC2 I am having some trouble.
    I agree with many of the previous comments that the course content
    is not what is advertised and the wrong students are getting signed
    up (I have been sitting in the course and getting input from our
    other instructors locally).  I have however another very important
    question of those of you that have already taught this course. 
    How in the world did you fit all of the topics in?  It looks to
    me like this course is entirely too long and because of that almost
    unteachable.  What are the impressions of others?  Were you able
    to follow the course schedule listed in the book?  Did you find
    something else in the way of schedule or order that maybe worked
    better?  I appreciate any help and suggestions that anyone may offer
    and would like to thank you in advance.
    
    				-- Pam Henry
    				   Washington, D.C. Training Center

     
    Pam; 
      
    You are quite correct when you say the wrong students are getting
    signed-up.  If I have this course on my schedule again - I will
    call each student on the roster before class and determine if
    this class is the one they need.
      
    Now, if you do indeed get students that belong in this class, there is
    not, in my opinion, to much material.  You do, however, need to know
    when to stop talking.  I did all of the modules in the prescribed
    order, with times very close to those recommended in the IG. Lab times
    were more, but then  they are for all of my courses.  Just don't go
    to deep and you will be fine.  You may also have a more advanced group
    which will permit less time in some areas.
      
    Arnold Tarling
    
    

    Arnold,
    
    	Thank you for your reply and the lifting of my confidence in
    the course.  I think your idea of calling the students is a great
    one and I am going to try to do that.  I know that there have been
    many problems with the student pre-requisites and hopefully central
    registration will be made more aware of the problem and help guide
    the students.  Thanks again.
    
    			-- Pam Henry

    	In prepping this week to teach this course I have updated a
    file that I am keeping of typographical errors.  If the student
    guide goes through a revision, hopefully these items could be
    corrected.  Some of the items are repeated from before but I am
    keeping track of them in one file.
    
    
    				-- Pam Henry
    			           Washington, D.C. Training Center
    
                    Corrections to VMS Programmer I Student Guide


 	Page  9-35 - "eve/tpu" should be "edit/tpu"
	
	Page 10-11 - OUTPUT "" should be WRITE SYS$OUTPUT ""

	Page 10-14 - The command procedure is written and the description
		     states there will be a blank line before the DCL
		     prompt is returned and yet the example does not
		     show the blank line.

	Page 12-15 - In the first paragraph the last word should read 
		     "values" not "alues".

	Page 13-6  - The command "SET NO CONTROL=Y" should read
                     "SET NOCONTROL=Y".

	Page 13-13 - Also the parameters have to be in single quotes in 
		     order to obtain the numeric result of 10.  The 
		     command procedure line 5 should read 
		     "C == 'P1' + 'P2'".

	Page 13-16 - The command $SET NO CONTROL=Y should not have a 
		     space between NO and CONTROL and should read
		     $SET NOCONTROL=Y.

	Page 15-7  - WSLIM should be WSDEF in the second to last line.

	Page 16-7  - Under the $ LINK ECHO it says the file type is .OBS.
		     This should read ".OBJ".

	Page 16-8  - Instead of saying "System services provide..." it
	             would be better to say "System resources provide..."
    

    
    
    	I would like to add one more item to my list in the previous
    	note.  On Page 4-12 there is an example of a directory which
    	has been split apart into sub-directories.  The problem is that
    	there are no .DIR files in the top level directory for the
    	sub-directories and there are .DIR files in one of the
        sub-directories with no directories shown below them.  I think
    	this could be very confusing for a student.
    
    				-- Pam Henry
    				   Washington, D.C.

    I must apologize for the fragmented style of my messages on errors
    in the book but it is much easier for me to keep them together in
    one file myself.  Some of the errors which follow are repeats of
    Note 31.31 but in my first teach of the class, I and my students
    found several more problems.  I have included them below.
    
    				-- Pam Henry
    				   Washington, D.C.
    
                Corrections to VMS Programmer I Student Guide


	Page  4-12 - The subdirectory example does not show any of the
		     .DIR files in the top level directory.

 	Page  9-35 - "eve/tpu" should be "edit/tpu"
	
	Page 10-11 - OUTPUT "" should be WRITE SYS$OUTPUT ""

	Page 10-14 - The command procedure is written and the description
		     states there will be a blank line before the DCL
		     prompt is returned and yet the example does not
		     show the blank line.

	Page 12-7  - INPUT_FILE is a logical name not a symbol as described.

	Page 12-15 - In the first paragraph the last word should read 
		     "values" not "alues".

	Page 13-6  - The command "SET NO CONTROL=Y" should read
                     "SET NOCONTROL=Y".

	Page 13-13 - Also the parameters have to be in single quotes in 
		     order to obtain the numeric result of 10.  The 
		     command procedure line 5 should read 
		     "C == 'P1' + 'P2'".

	Page 13-15 - The example of "NESTING" is not of nesting at all
	             but another example of iteration or the description
		     associated with NESTING does not match the example
		     on the next page.

	Page 13-16 - The command $SET NO CONTROL=Y should not have a 
		     space between NO and CONTROL and should read
		     $SET NOCONTROL=Y.

	Page 15-7  - WSLIM should be WSDEF in the second to last line.

	Page 16-7  - Under the $ LINK ECHO it says the file type is .OBS.
		     This should read ".OBJ".

	Page 16-8  - Instead of saying "System services provide..." it
	             would be better to say "System resources provide..."
		     in order to refer to all system services, Run-Time
		     Library routines and program development tools.

	Page 19-69 - The $ TYPE SYS$INPUT with a blank line following
		     does not clear the screen but simply inserts a blank
		     line.  It would be better to use $ TYPE/PAGE NL:.

	Page 19-89 - The RUN command has the wrong program name.  It should
		     read "$ RUN GRADES_FOR_MAIN".
    

    
    Thanks, Pam. We have caught and noted most of these...but I really
    appreciate you taking the time to enter them. Some of them were "new".
    
    Mel