| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 8.1 | Draft ready for review | SUPER::ROUNDS | Kristin Rounds, DTN 381-1066 | Fri Dec 07 1990 11:58 | 7 |
| A draft of this module is available for review in:
SUPER::ES$REVIEW:[RA0293]RA0293_CHAP_1_PROFILE.PS
The module does not contain anything about auto-login. If you want
that topic to be included, please reply to this note, telling me what
information you want it to contain.
|
| 8.2 | Reading, UK - first pass | UKEDU::SHONE | Keith Shone @RKA 830-4074 | Thu Dec 13 1990 10:17 | 26 |
| I found the flow of this chapter OK.
My nits, typos and other observations are below.
NOTE: These are my feelings etc. not of the UK as a whole.
I comment on typos etc on instructor pages as well as customer pages.
Instructors deserve to have unambiguous, correctly spelled and
technically accurate information too! :-)
Page Observation
---- -----------
1-4 Bullet 1 states "...login procedure..." - this
might be confused with LOGIN.COM. Suggest
"Use the login sequence..." or similar
1-9a Bullet 7 suggests CTRL/X as undefined but it is
used for clearing type-ahead buffers etc!
1-13a Typo - Sesssion -> Session
1-13 Bullet 1 couple of typos - sucessfully -> successfully
username -> user name
1-21a Last line - don't like the word system-crashers.
how about "those attempting system break-in"?
|
| 8.3 | More comments | COPCLU::SVENDSEN | | Fri Jan 04 1991 07:31 | 82 |
| Hi There.
This is a collection of my observations/comments in unsorted
unpriorited sequence.
My reviewprocess is bottom-up, that means that I take a look at the
chapter in the proper sequence first, and takes the topdown approach
after that.
I will regard structure and pragmatic aspects higher, than typos and
small mistakes, as the last is far more easier to correct than the
former.
-------------------------------------------------------------------
REGARDING LOG-IN.
It should be explained - why we have to login! I mean - you just
switch a PC on, then why all this login stuff??
Can we asume that the student know what a file is? I think not. It
would be better if the explanation was more abstract. They do not have
to know that something called UAF exists at all.
It is highly possible that they get logged in to their application
directly, so the talk about DCL (should be explained) must be modified.
There should be a overview/figure of a terminal<->computer connection, so the
student can understand things like why you have to press return in
order to get the login prompt.
It should be explained - why a terminal server is used at all!
The terminal server commenad table is nice, but should be organised in
following subsections.
- Establishing connection to the computer.
- Checking the connecting.
- Breaking connections
- resuming connections
- Stopping communication to the computer.
SHOW SESSION should be explained as well.
It should be explained that you can have more than one session on a
terminal, in the section about terminal servers.
I have a theory that dial-in connections are much more used in the US,
than i Europe, as all the modem stuff feels a little to much. I would
put it in a appendix.
The part about disconnected processes should not be marked as a DIAL-IN
problem only.
The difference between accessing remote VMS system and dial-in should
be explained.
The advantages of establishing multiple sessions should be explained.
the Break-key? -- European keyboards!
The multiple session example is too complicated - Why use all this
forward switch stuff at all - this is beginners.
Nice section about passwords - but I missed something about the
choosing of a password. Some guidelines would be nice.
What about the password historics function in VMS 5.4?
----------------------------------------------------------------------
I think that this chapter should focus more on "why we do
this-and-that". One of the things that helps
beginners a lot is the posibility to use a structure as "learning
skeleton".
Best
JOSS
|
| 8.4 | New version available | SUPER::ROUNDS | Kristin Rounds, DTN 381-1066 | Tue Apr 30 1991 07:40 | 3 |
| A new version of this chapter is in:
ES$REVIEW:[RA0293]RA0293_CHAP_1_LOGIN.PS
|
| 8.5 | Watch those dates; Terminal server - too much? | DUCK::SHONEK | Keith Shone UK Edu 830-4074 | Wed May 01 1991 08:35 | 53 |
| The section on terminal servers and sessions seems to be too dominant
but this may just be the impression *I* get.
One of the crosses one bears with dated materials is the need, every
year or revision if sooner, to bring dates and versions to some more
contemporary value.
Page 1-7 of these revised materials have dates in 1990 which must be
1991 before we start using the course as **NEW**.
This updating isn't always as straightforward as a global editor
substitution as we all know. This particular example may need to be
re-run. Other characteristics of the display may have changed with
evolution of the software. (SHOW USERS is a recent classic example of a
significant change to output).
If this seems like nitpicking, believe me students notice these things!
Just as they notice references to 700 series VAX computer systems.
Feeling argumentative ;-) I took issue with page 1-8. It refers to
a terminal not being connected directly to a computer system. A
terminal server IS a computer system (using a reasonably loose
definition).
Page 1-17 needs dates updating - global substitute won't work
because 13th November 1991 is a Wednesday!
Page 1-21 similar comments
Page 1-23 A password greater than six characters on my current
server produces this response:
Local -741- Illegal password
A server expert confirms that not all servers permit
such verbose password limits.
Page 1-25 One might add to this page that some higher security
sites don't issue a logout message or one in abbreviated form
For example, when user ROUNDS logs out the message might
appear thus:
$ LOGOUT
logged out at 1-MAY-1991 12:25:05.87
This is usually achieved by a system management-maintained
procedure that does something like:
WRITE SYS$OUTPUT " logged out at ", F$TIME()
STOP /ID=0
-- Keith
|
| 8.6 | Ouch!...Need some thought on dates... | SUPER::REGNELL | Smile!--Payback is a MOTHER! | Wed May 01 1991 19:13 | 22 |
|
Keith,
Great point...about dates...but...here is our dilemma:
Our guarantee is that the course will be at VMS 5.4...a
milestone that has nothing to do with real dates. These
examples were all generated under 5.4...so in our eyes
they do not need updating.
I understand exactly what you are saying...but is there some
whay around the _year_ date 'thingy'...and a way to stress the VMS
_version_ 'thingy'...which is how we identify material that needs
updating?
This is sort of elemental to our 'modular' approach...which
relies on small topic modules being updated to current
VMS versions...not tied to day-month-year biases.
Help us out here? Any thoughts or creative solutions?
Mel
|
| 8.7 | CMS & SEARCH + modularity all help | DUCK::SHONEK | Keith Shone UK Edu 830-4074 | Thu May 02 1991 04:22 | 40 |
| Mel,
Date sensitivity is probably greater than version sensitivity.
However, any piece of text that has date sensitive elements
would be in a CMS GROUP titled DATE_SENSITIVE as well as being
in a CMS GROUP for CODE_EXAMPLES or OUTPUT_EXAMPLES etc.
+----------VMS_APPLICATION_I----------+
| |
| +-----CODE_EXAMPLES-----+ |
| | | |
| | +----DATE_SENSITIVE----+ |
| | | | |
| | | LOGIN.SDML | |
| | | . . | |
| | +---------------+------+ |
| | | |
| +-----------------------+ |
| |
+-------------------------------------+
CMS supports almost infinite grouping capabilities so text elements
could, quite reasonably, be expected to appear in several different
groups.
The updating (pun intended) of dated output examples need only be done
once a year or revision. VMS SEARCH can help in assessing the size of
the problem and would run through all the N-thousand modules in the VMS
curriculum, rapidly.
A course I delivered a couple of weeks ago was brought up to date
during March and April. Students commented on how fresh the materials
were and with examples from the latest versions too. (Most of those
attending were .1 or .2 releases older than our up-to-date cluster
version). This should be a desirable side-effect of modularising
materials.
You folks need not worry, those of us reviewing the text will pick up
the antique versions and dates - in time ;-)
|
| 8.8 | Yet another subroutine...[grin] | SUPER::REGNELL | Smile!--Payback is a MOTHER! | Thu May 02 1991 09:49 | 30 |
|
Hmmm...well [grin]
We are only going to be using CMS as a storage facility in the
real implementation...Rdb databases will hold pointer records and
'objects' will be searched in that manner by attribute.
That, of course does nothing to argue the validity of your
schematic. _Our_ schematic calls for modularity to also release
us from _constant_ updating syndrome so we can spend quality time
on other educational/instructional work...like customizing courses
on the fly...etc.
That is not to say that we will not incorporate an update schedule
for material with dates if the instructor world at large thinks that
is important. We could make 'dated' as an attribute and have the
user interface automaticall spew us out a list every December
of examples that need to be re-generated. It _is_ one more complication
to a model that was striving to be 'simple' and therefore automated.
What do the rest of you think about dates in examples?
And would you all like a posting in here of the modularity
development schematic? It is probably almost at a point where I can
put it down in general terms so you folks can see how we are
trying to respond to your needs?
Thanks, Keith
Mel
|
| 8.9 | DATE ISSUE | DLO10::TARLING | | Thu May 02 1991 10:31 | 7 |
| Hi;
The date "thingy", in my opinion, is a NON-ISSUE. How about a glossary
of terms used in student guide?
Arnold Tarling.
|
| 8.10 | We are in violent agreement! | HARDY::ROUNDS | Kristin Rounds, DTN 381-1066 | Thu May 02 1991 11:09 | 9 |
| Thanks for your comments, Keith. I find them very helpful!
Having been an instructor and listened to student mutterings about "stale"
dates, I agree with your concern about dates that are too far in the past.
I'll stay out of the discussion for now, though, and just watch the fur fly.
I added your note about more secure logout messages to instructor page 25.
Kristin
|
| 8.11 | Yes, keep dates current | SWAM1::ENRIGHT_RA | | Wed May 15 1991 21:22 | 19 |
| I think "fresh" dates and version numbers are very important. I have
to painfully endure the slings and arrows of customers who point this
out to me. It is especially painful with INSTRUCTION SET / MACRO which
has numerous errors, typos, misplaced pages and hasn't been
revised since 1984! Is Big Brother preventing this update? Yes, I
know instruction set hasn't changed much but neither have the numerous
errors. Also, seven year old dates give customers the impression that
we don't update our materials especially if it's one of their first
courses. That impression may discourage further training purchases.
I think it is important to remember that if customers get negative
first impressions they may not come back. Our first priority should
be to give them first-class material and training. If they say we
should print the materials on blue paper we should do it and not
consult a psychologist nor an interior decorator. Remember the comment
by Tom Peters about the customer noticing the coffee stains on their
airline tray table and making the unfair conclusion about sloppy engine
maintenance.
|
| 8.12 | The dates have it... | SUPER::REGNELL | Modularity Maven | Wed May 15 1991 22:46 | 9 |
|
I think the date=current group is winning this. We will re-do the dates
for delivery and we will see what we can come up with for a revision
policy that will keep us closer.
Thanks for the input.
Melinda
|
| 8.13 | Someday... | CECV03::SADLER | Change for a Flainian Pobble Bead? | Thu May 23 1991 16:07 | 19 |
| > I think "fresh" dates and version numbers are very important. I have
> to painfully endure the slings and arrows of customers who point this
> out to me. It is especially painful with INSTRUCTION SET / MACRO which
> has numerous errors, typos, misplaced pages and hasn't been
> revised since 1984! Is Big Brother preventing this update?
Do I detect a burning in my ears? Sounds like another 'big bad funder'
comment!
In fact, I've been trying to get a revision to the Instruction Set/MACRO course
done for the past 2 years, as I want to add sme references to the Vector
instructions and generally tidy up the materials, but budget cuts and priorities
have prevented it. It's still on my list of 'nice to do' projects but ROI
considerations put it a fair way down on the list.
I'll get it done one day, maybe even next year...
ANdy
|