Trailing-Edge
-
PDP-10 Archives
-
bb-bt99h-bb
-
mon703.d14
There are no other files named mon703.d14 in the archive.
MCO: 12776 Name: KBY Date: 3-Feb-86:15:25:52
[Symptom]
Inefficiency in creating ABZ pages where section map
creations are required.
[Diagnosis]
We never allocated any pages since we thought we were creating
ABZ pages and therefore didn't need any.
[Cure]
Allocate pages if maps are required so we don't swap out because
we think we didn't allocate any section map pages because there
weren't any.
[Keywords]
ABZ inefficiency
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
PCO required
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 VMSER CHGPG4,CHGP10
704
[End of MCO 12776]
MCO: 12782 Name: JAD Date: 6-Feb-86:14:03:59
[Symptom]
After DISMOUNTing a structure on an RA60 drive subsequent attempts
to use the drive after mounting a new disk pack fail with "Problem
on device RAxxxx" and "Disk off-line" messages.
[Diagnosis]
RAXKON is trying to avoid giving FILSER a free interrupt if the
unit's logical name word (UNILOG) is zero. We expect MDA will try
to read the home blocks when it receives the "attached" message.
MDA tries, but fails, since we never got the unit out of "O2COD".
[Cure]
Always give FILSER a free interrupt. This will make sure the unit's
status is set correctly so the drive is usable.
[Keywords]
RA60
DISMOUNT STRUCTURE
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 RAXKON GIVINT
704
[End of MCO 12782]
MCO: 12795 Name: JAD Date: 17-Feb-86:08:24:15
[Symptom]
RAXDIE stopcode if we run out of credits.
[Diagnosis]
SCASER returns .SCNEC when a send would exceed the connection's
credit limit. RAXKON checks the error code for .SCFNC. Why
I coded two different symbols for the same error is beyond me.
[Cure]
Have RAXKON check for .SCNEC and delete .SCFNC from SCAPRM.
[Keywords]
SCA
NOT ENOUGH CREDITS
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 RAXKON RAXDGO
SCAPRM .SCFNC,.SCFWS
SCASER ETC
704
[End of MCO 12795]
MCO: 12801 Name: JAD Date: 18-Feb-86:13:43:27
[Symptom]
Stopcode EUE, IME, etc., following UN5 stopcode.
[Diagnosis]
Using a packet buffer we've already returned.
[Cure]
Get another buffer.
[Keywords]
UN5
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 RAXKON RAXUO3
704
[End of MCO 12801]
MCO: 12802 Name: JAD Date: 19-Feb-86:13:45:48
[Symptom]
Stopcode IME from AUTCON when a disk is brought online for the
first time. The new disk must not be unit number 7, and unit
number 7 must previously exist.
[Diagnosis]
Calling FSTMA3 with an expired AOBJN pointer simply returns
without changing any AC's. This causes FSTLS3 to call FSTMA3
repeatedly, with FSTMA3 bumping the AOBJN pointer to the KDB's
unit table in T1 each call. Eventually the AOBJN pointer goes
from positive to negative and we reference off into the boonies.
[Cure]
Clear T3 before each call to FSTMA3 so FSTMA3 exits such
that further calls will do the right thing.
[Keywords]
AUTCON
NEWDSK
FSTMA3
IME
[Related MCOs]
None
[Related SPRs]
868834
[MCO status]
Checked
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 AUTCON FSTLS3
704
[End of MCO 12802]
MCO: 12804 Name: JAD Date: 20-Feb-86:12:50:01
[Symptom]
None observed, may cause good blocks to be marked in the BAT
when a file with a bad block is closed.
[Diagnosis]
TSTBAD reads each block to determine the extent of the bad
region. It tests error bits in T3 returned by MONRDU. Odd
thing is, though, it tests for MONRDU##+IODERR. Lots of fun
bits get tested inadvertently this way.
[Cure]
Fix the test to be IODTER+IODERR.
[Keywords]
TSTBAD
BAD BLOCKS
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 FILUUO TSTBD2
704
[End of MCO 12804]
MCO: 12810 Name: JAD Date: 24-Feb-86:10:26:27
[Symptom]
IPA devices (CI, NI) only get started the first time a CPU is
started. If a CPU is started more than once (removed, then
added back, restarted after a CPU stopcode, etc.) the devices
don't get started automatically.
[Diagnosis]
Code to delay starting drivers until after BOOT CPU requests
it (via call to SPRIPA) doesn't handle CPU restarts. The
bit in .CPRUN which says to start the IPA devices only gets
set once so the devices only get started once.
[Cure]
Light the bit when we return from calling AUTCON at SPRIN2.
This will guarantee IPA devices always get started when a CPU
is (re)started.
[Keywords]
DITTO
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 COMMON SPRIN2
704
[End of MCO 12810]
MCO: 12821 Name: CJA Date: 28-Feb-86:10:37:29
[Symptom]
DECnet confused about the difference between a
source and a destination of a logical link. SYSDPY
display shows bogus information.
[Diagnosis]
In several places in SCLINK, we use the "source"
field when we should use the "destination" field, and vice-versa.
SYSDPY displays these fields containing wrong info.
[Cure]
Use correct fields. For a passive link, the "source" is
the object number of the thing connecting to us, and "destination"
is our own object number. For an active link, the "source"
is our own object number, and the "destination" is the object
number which we want to connect to.
[Keywords]
DECNET
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
PCO required
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 SCLINK SEVERA
704
[End of MCO 12821]
MCO: 12822 Name: CJA Date: 28-Feb-86:11:12:10
[Symptom]
Can't RENAME a file "in your behalf" if it is open
for update or append. Bogus "file not found" errors as a result.
[Diagnosis]
If the file is open for update or append, we
call CLOSE1 twice to close the file. Unfortunately, the
first call clears the "in your behalf" PPN, and when we
get around to the second close, we may not have privs
to do the RENAME.
[Cure]
PUSH/PUSHJ/POP
[Keywords]
InYourBehalf
Rename
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
PCO required
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 FILUUO RENAM2
704
[End of MCO 12822]
MCO: 12823 Name: JAD Date: 28-Feb-86:13:20:01
[Symptom]
1026 won't run if all CPUs are started during ONCE.
[Diagnosis]
A flaky TM02 is interrupting in the middle of CHKT22. However,
since no one has set up the IVI yet the RH20 tries to execute
offset zero in the EPT (containing a zero) and winds up getting
a UIL stopcode. If the CPU is started after the system is up
and running everything happens "sort of" correctly (the cruddy
TM02 gets marked offline, which may be an improvement).
[Cure]
One would wonder why we are bothering to check for 18-bit channels
since there is no way TOPS-10 would run with one nowdays. Since
this is true, there is really no reason for TEST22 to exist other
than for it to set CP.22B in the CHN. Therefore, remove TEST22
entirely and teach AUTCON to light CP.22B when it builds the CHN
in the first place.
[Keywords]
BAD HARDWARE
ZERO IVI
BUY TU70'S
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 AUTCON SEVERA
ONCMOD TEST22,CHKD22,CHKT22
704
[End of MCO 12823]
MCO: 12830 Name: JAD Date: 11-Mar-86:17:57:09
[Symptom]
CI disk failover clunks the SYSDET chain.
[Diagnosis]
Entry point ATTMX into ATTDSK doesn't take care of
unlinking the UDB being attached from the SYSDET chain,
nor does it link the UDB onto the SYSUNI chain.
[Cure]
Fix up the links in ATTMX. Split off the code which fixes
the links, make it a subroutine, and call it from ATTDSK and
ATTMX.
[Keywords]
FAILUNDER
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 FILIO ATTMX
704
[End of MCO 12830]
MCO: 12835 Name: JAD Date: 18-Mar-86:12:51:15
[Symptom]
Multiple CPU system doesn't run as well as it can if an MCA25
is not installed on every CPU.
[Diagnosis]
When ONCMAP creates pages it lights PM.KPM only if the CPU which
called ONCMAP has an MCA25. Other CPUs might have an MCA25 but
the pages involved never get "kept".
[Cure]
Always light PM.KPM when ONCMAP creates pages. Make sure PM.KPM
is off in the section pointer (as the bits get ANDed together)
if the CPU doesn't have an MCA25.
[Keywords]
PM.KPM
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
New development MCO
KL10 only
Multi CPU only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 ONCE ALCSMP
SYSINI ONCMAP
VMSER STMAPE
704
[End of MCO 12835]
MCO: 12836 Name: JAD Date: 18-Mar-86:13:10:05
[Symptom]
A DEVTYP or DEVCHR UUO with an argument of "-1" will return bits
saying you specified a disk device if you have an old-style LIB:.
[Diagnosis]
An old-style LIB: has a name of "-1" in the pathological name
entry (don't ask me why). LNMTST matches the "-1" argument with
the "-1" name and merrily tells you a disk was specified.
[Cure]
Disallow "-1" in LNMTST.
[Keywords]
Old-style LIB:
LNMTST
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
New development MCO
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 FILUUO LNMTST
704
[End of MCO 12836]
MCO: 12837 Name: JAD Date: 19-Mar-86:08:38:38
[Symptom]
LINKing the monitor takes forever (and a day...).
[Diagnosis]
A purported bug in LINK required the use of a PSECT name for
the high segment other than the usual ".HIGH.". This caused
LINK the expense of maintaining a single paging file for the
.LOW., HIGH, and SKY PSECTs, which in turn caused a lot more
overhead paging through the file.
[Cure]
Since the bug in LINK has (apparently) been fixed, go back
to using ".HIGH." for the high segment PSECT name. This will
enable LINK to use two paging files which substantially cuts
the amount of time (real and CPU) required to link the monitor.
[Keywords]
PSECTS
.HIGH.
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
New development MCO
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 S PSECTS
704
[End of MCO 12837]
MCO: 12838 Name: JAD Date: 24-Mar-86:11:54:44
[Symptom]
Code reading bug.
[Diagnosis]
CFDMP tests for I/O via an internal channel by checking for
either CP.RH2 or CP.MX. CP.MX doesn't really mean an internal
channel, it just means a channel which can do multiple simul-
taneous transfers. If some customer ever got clever and wrote
a driver for some funny device which could do multiple transfers
(SA10 anyone?) FILIO would get confused on cache integrity.
[Cure]
Test CP.KLP rather than CP.MX.
[Keywords]
MULTIPLE TRANSFERS
INTERNAL CHANNELS
KLIPA
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
New development MCO
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 FILIO CFDMP
704
[End of MCO 12838]
MCO: 12839 Name: JAD Date: 24-Mar-86:17:22:46
[Symptom]
Disk I/O on the KS during ONCE may not be correct with respect
to the (hardware) cache.
[Diagnosis]
Cache is enabled on the KS from the time the pager is turned
on (how do you turn on a pager?). Since I/O into memory will
not invalidate the cache, data fetched from the buffer may be
an old copy left in cache and not the newest data.
Normally you would expect FILIO to do the right thing in this
case and invalidate the cache. However, it doesn't do this
during ONCE (calls to CFDMP are no-ops during ONCE). We're
left with potentially stale data in cache.
[Cure]
Conditionalize the test on DINITF in CFDMP so it only asembles
for the KL. This will cause ONCE disk I/O on the KS to correctly
invalidate the cache when reading.
[Keywords]
CACHE
KS
ONCE-ONLY DISK I/O
BOOTABLE TAPE
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
KS10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 FILIO CFDMP
704
[End of MCO 12839]
MCO: 12840 Name: JAD Date: 25-Mar-86:09:57:33
[Symptom]
A bit of a hassle trying to bring up a system without CI or NI
when debugging.
[Diagnosis]
IPAPCB (the table of PCB size, etc.) is in the high seg so
you have to get to HIGHIN before you can zap out the entries
for the CI and/or NI.
[Cure]
Move IPAPCB to the low seg.
[Keywords]
DEBUGGING
CI
NI
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 AUTCON IPAPCB
704
[End of MCO 12840]
MCO: 12841 Name: JAD Date: 26-Mar-86:10:58:23
[Symptom]
RHN stopcode (re-read home block count negative) begets another.
[Diagnosis]
SOSGE followed by a stopcode never resets the count to something
which is reasonable (i.e., zero).
[Cure]
Re-arrange the code slightly and add a SETZM after the stopcode.
[Keywords]
RHN
STOPCODE LIMIT EXCEEDED
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
New development MCO
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 FILIO SETID3
704
[End of MCO 12841]
MCO: 12845 Name: JAD Date: 27-Mar-86:09:33:38
[Symptom]
UNIGEN can match a random zero in location 62.
[Diagnosis]
If U contains zero when checking DEVGEN versus UNIGEN, and
DEVGEN contains zero (structure has never been dismounted),
CHEKU will believe the generation numbers match, when in fact
they don't.
[Cure]
Assign monotonically increasing UNIGEN's when creating UDBs in
AUTCON or in ONCMOD (under IFE FTAUTC) to make it easier to catch
such instances. Doesn't solve the underlying problem but at least
makes it easier to notice.
[Keywords]
UNIGEN
DEVGEN
SYSGEN
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
New development MCO
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 AUTCON UDB4
ONCMOD SCNUNI
704
[End of MCO 12845]
MCO: 12846 Name: JMF Date: 28-Mar-86:10:42:43
[Symptom]
1022SA gets ill uuo at user 140 when doing a RUN UUO on LINK.
[Diagnosis]
1022SA has a starting vector which says start at 140. It doesn't
get cleared on the RUN UUO.
[Cure]
Remove LDB, CAIN over the SETZM .USUSA.
[Keywords]
Entry vector
RUN UUO
[Related MCOs]
None
[Related QARs]
None
[MCO status]
None
[MCO attributes]
New development MCO
QAR answer
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 COMCON URUN1A
704
[End of MCO 12846]
MCO: 12847 Name: JMF Date: 28-Mar-86:10:48:05
[Symptom]
?No start address when SPEAR does a RUN UUO on SPRRET on the KS.
[Diagnosis]
KCOREV is zeroing -10(P) which happens to be the flags which say
which segment we want to get on the RUN UUO.
[Cure]
SETZM -10(P) => SETZM -5(P).
[Keywords]
[Related MCOs]
None
[Related QARs]
None
[MCO status]
None
[MCO attributes]
New development MCO
KS10 only
QAR answer
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 VMSER KCOREV
704
[End of MCO 12847]
MCO: 12848 Name: JAD Date: 28-Mar-86:11:10:09
[Symptom]
RENAME after CLOSE fails for a disk which has been mounted on
a drive which previously contained a disk mounted when the system
was first brought up.
[Diagnosis]
Even though RENAME after CLOSE isn't really legal, FILUUO tries
to allow simple cases of RENAME in the UFD to still succeed. In
this case DEVUNI will contain zero. When RENAM3 calls CHEKU with
U containing zero DEVGEN(F) may match location UNIGEN in the monitor
(offset 62 in a UDB if U doesn't contain zero) and allow the RENAME
to succeed. If the disk is subsequently dismounted DEVGEN wouldn't
contain zero so the test on location 62 in the monitor fails causing
the RENAME to fail.
[Cure]
Recognize that DEVUNI containing zero here is a semi-legitimate
case and add a JUMPE U around the call to CHEKU.
[Keywords]
RENAME FAILURE AFTER CLOSE
CLOSE
CHEKU
[Related MCOs]
12845
[Related SPRs]
868979
[MCO status]
Checked
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 FILUUO RENAM3
704
[End of MCO 12848]
MCO: 12851 Name: DPM Date: 1-Apr-86:02:20:23
[Symptom]
A LOOKUP UUO will fail on a labeled magtape if the next filename
on the tape contains non-standard characters.
[Diagnosis]
The intent of the labeled LOOKUP code was to provide programs
with the ability to do simple file structure-oriented UUOs on magtapes
in cases where those tapes contained files with normal filenames. If
the LOOKUP UUO argument block contains a zero for the filename, then
the next file on the tape is supposed to be returned. If that file
contains non-standard characters, the file is skipped. If every file
on the tape has non-standard characters, then every file will be
skipped over and "file not found" error code returned. The code at
TPMLK4 is supposed to accept all files and try to fill in the LOOKUP
block appropriately. It's not doing that.
[Cure]
Fix the code at TPMLK4 to accept all files. Also add "-" to the
list of legal characters in a filename. This is for compatibility
with SCAN and filespecs produced by other Digital operating systems.
If, however, the tape contains non-standard characters in the
filename, the returned filename and extension may not accurately
reflect what is on tape. This behavior is acceptable since the LOOKUP
UUO attempts to translate 17 character ANSI ASCII filenames into a
TOPS-10 sixbit filename and extension format. There is no guarantee
the two are compatible.
[Keywords]
MAGTAPE
[Related MCOs]
None
[Related SPRs]
35264
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 TAPUUO TPMLK4,SIXINP
704
[End of MCO 12851]
MCO: 12852 Name: JAD Date: 3-Apr-86:15:27:05
[Symptom]
[Insert random stopcode name.]
[Diagnosis]
Somehow DEVUNI contains zero when a USETI is done. Odds
are good the world will end shortly.
[Cure]
Test for U containing zero and produce a "UDBAIZ" stopcode (UDB
Address Is Zero).
[Keywords]
CHEKU
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
New development MCO
Documentation change
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 FILIO CHEKU
704
[End of MCO 12852]
MCO: 12853 Name: JAD Date: 3-Apr-86:15:34:26
[Symptom]
UNIGEN of newly-created disk DDBs can match random zero in memory.
[Diagnosis]
MCO 12845 didn't go quite far enough. We should initialize
the prototype disk/swapper DDBs with an invalid UNIGEN (-1).
[Cure]
Fix up prototype DDBs.
[Keywords]
None
[Related MCOs]
12845
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
New development MCO
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 COMMOD DSKDDB
704
[End of MCO 12853]
MCO: 12856 Name: JAD Date: 7-Apr-86:08:53:19
[Symptom]
Files appended in simultaneous update mode have contiguous
clusters allocated but have separate pointers for each cluster,
leading to extended RIBs.
[Diagnosis]
If there is more than one writer to the file this is just a
fact of life for simultaneous update. However, a bug in FILIO
causes the case of a single writer to fail a call to CHKADD so
FILIO adds another retrieval pointer to the file, even though
the block(s) it just allocated may be contiguous to the last
retrieval pointer.
[Cure]
Load T2 before calling CHKADD.
[Keywords]
SIMULTANEOUS UPDATE
EXTENDED RIBS
[Related MCOs]
None
[Related SPRs]
32687
[MCO status]
Checked
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 FILIO USET13
704
[End of MCO 12856]
MCO: 12858 Name: JAD Date: 7-Apr-86:09:46:02
[Symptom]
Size of last block in a simultaneous update file can be wrong.
[Diagnosis]
If we get to CLOSOU in FILUUO via RESET, M contains 400000
as set by IOALL. If CLOSOU takes a branch to CLSRI5 in the
case of simultaneous update, M never gets set up like CLSRI5
expects it. 400000 in M indicates a directory to CLSRI5, so
the last block size gets set to 128. words.
[Cure]
Clear the bit in M before branching to CLSRI5, and move the
set up of M in IOALL down one line so it is re-initialized to
the correct value for each channel.
[Keywords]
SIMULTANEOUS UPDATE
[Related MCOs]
None
[Related SPRs]
33898
[MCO status]
Checked
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 FILUUO CLSOU4
UUOCON IOALL0
704
[End of MCO 12858]
MCO: 12859 Name: JAD Date: 8-Apr-86:08:11:36
[Symptom]
Regular LOOKUP/ENTER/RENAME UUOs can page fail because the argument
block crosses into an inaccessible page. This might cause the
job to wind up restarting the UUO while still holding a FILSER
resource (CB, AU, etc.).
[Diagnosis]
ARGCHK, the routine which checks the argument blocks for
these UUOs, only checks for a 4-word block. An extended block
will not be address checked properly.
[Cure]
Teach ARGCHK to call FCLERB (routine FILOP. UUO uses to address
check a LOOKUP/ENTER/RENAME block) since FCLERB already has the
smarts to deal with regular or extended argument blocks.
[Keywords]
ARGCHK
AOC
PAGE FAILS
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 UUOCON ARGCHK
704
[End of MCO 12859]
MCO: 12861 Name: JAD Date: 8-Apr-86:12:21:41
[Symptom]
Extended RIBs are not "correctly" formatted.
[Diagnosis]
RIBs are "supposed" to begin with a change of unit pointer.
Extended RIBs don't follow this convention. This doesn't cause
any problems but does make it a bit of a pain for disk damage
assessment programs when checking the validity of a supposed
RIB block.
[Cure]
Make extended RIBs begin with a change of unit pointer.
Costs one retrieval pointer slot per extended RIB; big deal.
[Keywords]
Extended RIBs
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 303 FILIO EXTRB1
704
[End of MCO 12861]
MCO: 12864 Name: JAD Date: 9-Apr-86:14:41:25
[Symptom]
KLIPA failures are not easily diagnosible.
[Diagnosis]
We don't get a dump of the KLIPA DRAM when it halts.
This could contain useful information.
[Cure]
Dump the KLIPA DRAM to the system error file on a KLIPA
failure. Maybe someday I'll figure out what to do with
a KLIPA dump.
[Keywords]
KLIPA DUMP
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
Deferred
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 303 ICHPRM BITS
KLPSER KLPDMP
704
[End of MCO 12864]
MCO: 12865 Name: JAD Date: 10-Apr-86:13:25:05
[Symptom]
Garbage entries in UFDs. MCO 12824 prevented the problem by
using nitroglycerin.
[Diagnosis]
Redundant RIBs wind up in the monitor I/O cache. This
is probably a waste of the cache since FILSER never reads a
redundant RIB. In addition, it is a contributing cause to
the problem MCO 12824 addressed with a 20-pound sledge.
[Cure]
Call MONWRU instead of MONWRT when writing redundant RIBs.
[Keywords]
UFD CORRUPTION
[Related MCOs]
12824, 12863
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
New development MCO
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 303 FILUUO ALLPT5
FILUUO UFDALX
704
[End of MCO 12865]
MCO: 12866 Name: JAD Date: 10-Apr-86:15:41:06
[Symptom]
DSKCHR UUO on "RAG2" which happens to be on the SYSDET chain
today returns information for "RAG23" which happens to have
DSKB mounted on it.
[Diagnosis]
User supplied 4 characters in the argument; SRUNA decides
to match on 4 characters since ALIASD created a mask for 4
characters.
[Cure]
If the last gasp attempt to match the user's argument fails,
if the user has specified more than 3 characters in the argument
then reset the mask for 6 characters before calling SRUNA.
[Keywords]
DSKCHR
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
New development MCO
Documentation change
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 303 FILFND LOCSRU
704
[End of MCO 12866]
MCO: 12867 Name: DPM Date: 11-Apr-86:03:02:38
[Symptom]
The MTSKF. UUO behaves differently when used with an MDA
controlled tape than with a BYPASS labels tape. Previously, the
sequence IN, MTSKF., IN worked correctly. Now, under MDA, the second
IN UUO appears to fail due to the EOF condition set by the skip file
function.
[Diagnosis]
All positioning operations handled by the monitor turn on the
"need additional labeler processing" bit (LBLNED). TAPUUO is probably
trying to insure that PULSAR is called on the next first input or
output. Other code already exists to handle this case.
[Cure]
Always clear LBLNED when processing interrupts at the end of
spacing operations. If PULSAR processes the positioning request
itself, then it is responsible for setting the termination code, which
in turn, causes the appropriate bits in DEVIOS to be set. If PULSAR
lets the monitor finish the request, then there is no need for
additional interaction.
[Keywords]
TAPE POSITIONING
[Related MCOs]
None
[Related SPRs]
34506
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 303 TAPUUO TPMISP,TPMFSF,TPMBSF
704
[End of MCO 12867]
MCO: 12868 Name: KBY Date: 11-Apr-86:08:04:30
[Symptom]
Stopcode PSF (others possible) locking on the KS.
[Diagnosis]
PAGFRE forgot that PAGTAB doesn't live at section-relative 0 in an
IFE FTXMON monitor.
[Cure]
Add appropriate offset in for IFE FTXMON. Clean up the IFN FTXMON case
as well.
[Keywords]
SNOOPY
[Related MCOs]
None
[Related SPRs]
869036
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 303 LOKCON PAGFRE
704
[End of MCO 12868]
MCO: 12870 Name: JAD Date: 11-Apr-86:11:24:53
[Symptom]
System performance while deleting a long file is, ahem, somewhat
less than ideal.
[Diagnosis]
MCO 12824 added a call to CSDELR in GIVBLK to fix a problem
which prevented 7.03 from shipping. While the solution in the
MCO was correct, it was a bit heavy-handed. Further inspection
reveals a better strategy for flushing data from the monitor I/O
cache when deleting (or truncating) directories.
[Cure]
Have UPDGV2 call CSDELR if deleting (or truncating) a directory
to flush the returned blocks from the directory.
[Keywords]
UFD CORRUPTION
GIVBLK
CSDELR
[Related MCOs]
12824, 12863, 12865
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
New development MCO
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 303 FILIO GIVBLK
FILUUO UPDGV3
704
[End of MCO 12870]
MCO: 12871 Name: RCB Date: 11-Apr-86:12:37:21
[Symptom]
Jobs stuck in TI when the requested input is available.
[Diagnosis]
Race between checking for character mode input and going into TIOWQ
for it.
Lost acks of TTDINT's messages on RSX20F lines (this usually causes TO
hangs).
[Cure]
Check again for input after lighting IOW & IOACT, and clear them by hand
if no need for going into TI.
Invent a slow (6-second) Irma timer for RSX20F lines, and restart them
if they've been waiting for an ack on an active CPU that long.
[Keywords]
TI hang
TO hang
^C-only state
RSX20F lines
[Related MCOs]
None
[Related SPRs]
34544, 33530
[MCO status]
Checked
[MCO attributes]
New development MCO
PCO required
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 303 SCNSER RECIN3,RECINA,RECIN6,TWAITC,LDBTTD,LDPTDT,SCNSIL
704 TTDINT TTDPST,TTDDW1,PRCACK,DLSAAL,TTDSIN
[End of MCO 12871]
MCO: 12876 Name: RCB Date: 15-Apr-86:15:35:10
[Symptom]
^A doesn't work as expected on terminals which are not under MIC control.
This has most often been complained about when trying to type ^A (=^C) at
an OPSER subjob.
[Diagnosis]
Doing things for MIC even when it isn't interested in the terminal.
[Cure]
SKIPE LDBMIC(U).
[Keywords]
MIC ABORT
^A to wrong subjob
[Related MCOs]
None
[Related QARs]
868759
[MCO status]
None
[MCO attributes]
New development MCO
QAR answer
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 304 SCNSER RICA
704
[End of MCO 12876]
MCO: 12877 Name: JAD Date: 16-Apr-86:09:03:53
[Symptom]
No way to obtain the names of all physical disk units in the
system configuration.
[Diagnosis]
Since we added a chain of detached units the only way to
get the names of those units is to PEEK their UDBs. JMF feels
(and I agree) this is not the way it should really be done.
[Cure]
Fix up the SYSPHY UUO so it will follow both the "regular" and
"detached" unit chains. This will result in behaviour which is
identical to that of 7.02 and prior monitors.
[Keywords]
SYSPHY
DETACHED UNITS
SYSDET
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 304 FILFND SYSPHY
704
[End of MCO 12877]
MCO: 12879 Name: DPM Date: 17-Apr-86:03:27:12
[Symptom]
Reel switches across tape controllers on different CPUs does not
work. Jobs get stuck in IO or EW states for the tape controller.
[Diagnosis]
The routine to swap magtape DDBs exchanges all necessary data
between the previous and new DDBs except DEVCPU.
[Cure]
Swap the DEVCPU word between the two DDBs.
[Keywords]
REEL SWITCH
[Related MCOs]
None
[Related SPRs]
35461
[MCO status]
None
[MCO attributes]
Documentation change
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 304 TAPUUO TPLSU1
704
[End of MCO 12879]
MCO: 12880 Name: DPM Date: 17-Apr-86:07:24:11
[Symptom]
Stopcode IME in IPCSER.
[Diagnosis]
The address of start of the job's packet chain contains minus
one. Attempts to index off this value will yeild an IME stopcode. In
several places in IPCSER, the count of outstanding sends is
decremented. Special care is taken to avoid decrementing the count
below zero. If the count is already zero, the discrepancy is ignored
and the monitor continues with no apparent problems. In a couple of
places, however, no check is made for a send count of zero before
decrementing the quantity. The count is stored in the high order 9
bits of a right half word in memory (.EPIPC/.PDIPC) and gets
decremented by loading -1000 in an AC and doing an ADDM. The left
half word contains the packet chain address. If the count is already
zero, the ADDM will store -1,,777000 into .EPIPC/.PDIPC.
[Cure]
Move the code to decrement the send count into one subroutine
that correctly checks for field underflow before decrementing the
count. Make the appropriate changes to call this routine in all
places that need to adjust the send count.
[Keywords]
IPCF SEND
[Related MCOs]
None
[Related SPRs]
35238
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 304 IPCSER IPCF12,IPCF3,DECSND,TURNQ1,TURNQ4
704
[End of MCO 12880]
MCO: 12881 Name: KBY Date: 17-Apr-86:10:41:48
[Symptom]
Job incorrectly woken by stale clock request.
[Diagnosis]
We leave a dangling clock request in the queue if a job
HIBERs with a time and a condition, and the condition is satisfied
before the clock request is satisfied.
[Cure]
Clear out the clock queue entry upon continuation from the HIBER
and the clock request is still active.
[Keywords]
clock request
[Related MCOs]
None
[Related SPRs]
33609
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 304 CLOCK1 CLKCHG,SETHBR
704
[End of MCO 12881]
MCO: 12882 Name: ERS/DAS Date: 18-Apr-86:14:57:28
[Symptom]
Attaching to an attached device yields a poor error message.
[Diagnosis]
yes.
[Cure]
Instead of typing "?ATTACH FOO?" type "?Wasn't detached".
[Keywords]
ATTACH
[Related MCOs]
None
[Related SPRs]
31489
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
701B COMCON ATT8
702A
703A 304
704
[End of MCO 12882]
MCO: 12883 Name: KBY Date: 21-Apr-86:14:53:53
[Symptom]
User at his physical, but not virtual limit get undeserved
duplicate page error if he tries to receive some page which is either
on a queue or in core.
[Diagnosis]
Code is stupid.
[Cure]
If the page is on a queue, leave it there. If it isn't, put
it on the fast IN queue.
[Keywords]
virtual
IPCF
[Related MCOs]
None
[Related SPRs]
32505
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 304 VMSER IPCINS
704
[End of MCO 12883]
MCO: 12884 Name: RDH Date: 21-Apr-86:23:22:55
[Symptom]
1) If TSK. "Enter Active" / "Enter Passive" was used to initialize
an ANF TSK-to-TSK link, a subsequent CLOSE monitor call will not
necessarily flush out any not-yet-output buffered data.
2) TSK. "Input" will not necessarily read all data previously output
from the "remote" TSK after the remote has disconnected the TSK
channel, even though the monitor has received the TSK data.
3) SET WATCH FILE show incorrect error code for extended-format TSK
device FILOP/LOOKUP/ENTER/RENAME/etc. errors
[Diagnosis]
1) When TSK. was originally implemented, it wasn't really meant to
be used interchangeably with the "normal" IN/OUT/CLOSE monitor
calls (wherein the user did a LOOKUP/ENTER sequence to set up the
TSK link), so all associated I/O flags never got set.
2) Code tries to be clever, and outsmarts itself.
3) Error-stuffer routine tries to be nice and preserve "M" for the
caller, but the caller's caller really wants the "trashed" M
address.
[Cure]
1) On successful TSK. "Input" or "Output" operations, light the
"LOOKB" or "ENTRB" flags respectively, so that CLOSE will know
how to deal with the buffer rings (actually, there is nothing
really to do with "Input", but I made it symmetrical, just for
esthetics).
2) Stupidize the code, so it is more "event" driven. The error
return will then be forced at the appropriate time by having
exhausted all the input data, and falling into the error rou-
tine to see why. This guarantees that all data output by the
remote side prior to the disconnect will be synchronously in-
put before EOF/TKILS% error return is taken.
3) Leave "M" trashed.
[Keywords]
TSK
SET WATCH FILE
[Related MCOs]
None
[Related SPRs]
32555, 32676, 32776
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 304 TSKSER TSKIN,TSKOU,TSKEI,T.STOF,RTNLEE
704
[End of MCO 12884]
MCO: 12885 Name: KBY Date: 22-Apr-86:07:58:29
[Symptom]
It's another day...time to make IPCSER know what error codes VMSER
found out about at IPCINS.
[Diagnosis]
The current returns are T1=0 (some limit exceeded or duplicate
page) and T1=/=0 (paging I/O error).
[Cure]
Allow VMSER to return the IPCxx% error code in T1 which IPCSER will
conveniently store in the AC. This means the relevant codes must
be global-ized. Since there are no error codes for no physical or
virtual room, invent them (IPCRP% and IPCRV%).
[Keywords]
IPCSER
[Related MCOs]
None
[Related SPRs]
32505
[MCO status]
None
[MCO attributes]
Documentation change
UUOSYM change
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 304 VMSER IPCINS
704 IPCSER IPCPI%,IPCUP%,IPFR6
[End of MCO 12885]
MCO: 12887 Name: JAD Date: 22-Apr-86:15:14:34
[Symptom]
Adding a CPU sometimes doesn't give free attaches on the disks
attached to that CPU.
[Diagnosis]
ATTCPD (called by SPRINI during CPU start-up) calls ONCPUs to
get on the "right" CPU to call KONCPY. ONCPUS checks the sign
bit of .CPRUN for that (this) CPU (the "don't run jobs on this
CPU flag", aka :SET RUN NO CPUx), and if set, takes the error
return, causing ATTCPD to skip over the unit.
Secondly, detached units (on the SYSDET chain) which were put
there when the CPU was REMOVEd won't get attached for free.
[Cure]
In ATTCPD, don't call ONCPUS or friends if called at interrupt
level (SPRINI).
In SPRINI, look at the SYSDET chain as well as the SYSUNI chain.
[Keywords]
CONFIG
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 305 COMMON SPRIN7
FILIO ATTCPD
704
[End of MCO 12887]
MCO: 12890 Name: DPM Date: 24-Apr-86:01:54:39
[Symptom]
Downline loading of ANF remote stations does not always work in
configurations containing DUP11s. The following configuration is
known not to work:
KL --- (DTE) DN20 (DUP) --- (DQ) DN80
[Diagnosis]
The DUP driver is being told to send synchs without a BCC character.
This is normal since you only checksum actual data. When this is done,
the downline load fails (the DN20 never sees the boot request from the
DN80). If instead, you send the synchs as a checksummed data, then the
downline load succeeds. The net result should be the same, although
it's not obvious why one case works and the other doesn't.
[Cure]
Transmit the syncs as a counted string along with a BCC character.
[Keywords]
DUP11
BOOT
[Related MCOs]
None
[Related SPRs]
34834
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
704 305 DNDCMP DDCI21
703A
[End of MCO 12890]
MCO: 12891 Name: DPM Date: 24-Apr-86:02:42:36
[Symptom]
The DDCMP driver does not conform to the DDCMP specification.
Out of sequence ACKs cause the line to be declared down and restarted.
Also, the REP timer default of one second is too short for 4800 baud
lines.
[Diagnosis]
When out of sequence ACKs are detected, they should be ignored
and not cause a line restart. A one second REP timer does not allow
enough time to receive an ACK if the remote node begins sending a full
full length packet.
[Cure]
Ignore out of sequence ACKs and increase the default REP timer to
three seconds.
[Keywords]
DDCMP
[Related MCOs]
None
[Related SPRs]
33785
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
704 305 DNCNFG NRPSEC
DNCDMC DMCTMR
DNDCMP DDRESP
703A
[End of MCO 12891]
MCO: 12892 Name: JAD Date: 24-Apr-86:14:40:59
[Symptom]
Unrecoverable overruns (32 retries) when monitor runs out of
channel 4-word core.
[Diagnosis]
If FILIO's first call to MAPIO for this transfer succeeds
SETLST/SETDMP will call PUNT(B/D) if a subsequent call to
MAPIO for this transfer fails. PUNT figures out how many
words are described in the I/O list and uses that number
of words for the length of the transfer. Unfortunately,
it is kind of hard to tell a disk drive you're going to
transfer n and a fraction blocks. FILIO computes the
transfer size of n blocks, but tells the channel to do
n*200 plus a few words. The channel will give an error
when the transfer fails (long word count error, usually).
FILIO will retry the same transfer until the retry count
is exhausted. The retry will never succeed since FILIO
keeps using the same incorrect I/O list.
[Cure]
Teach PUNT(B/D) how to back off IOWDs as needed so the
transfer will be an integral multiple of the block size.
For buffered mode, also light IOSPBF and stuff the count
into the buffer header (finish up like SETLS7 does) so
we can resume the transfer later.
[Keywords]
PUNTB
PUNTD
OVERRUN
[Related MCOs]
None
[Related SPRs]
35463
[MCO status]
Checked
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 305 FILIO SETDM2,SETDM3,PUNTB,PUNTD
704
[End of MCO 12892]
MCO: 12893 Name: JAD Date: 24-Apr-86:16:11:58
[Symptom]
Can't use the "Return CPU accessibility mask" function of the
RECON. UUO to find out which CPU owns a terminal.
[Diagnosis]
Yeah, I know, terminals (DDBs) are generically owned by the
BOOT CPU. However, hardwired terminals (-20F lines, etc.)
really ARE owned by the CPU to which they are connected.
When that CPU gets removed CONFIG would like to be able to
warn the Operator that the job is losing its terminal.
RCNCPU uses DEYCPF to get the owning CPU when it should be
getting the CPU number from the LDB.
[Cure]
Make RCNCPU a bit more clever so that it uses LDPCPU for
the owning CPU when checking an attached TTY DDB.
[Keywords]
CONFIG
.RCCPU
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 305 UUOCON RCNCP2
704
[End of MCO 12893]
MCO: 12894 Name: DPM Date: 25-Apr-86:08:03:02
[Symptom]
Stopcodes WEM (pre-7.03) or ANFCLA following an NXM error.
[Diagnosis]
If a user job is running at the time of a stopcode, parity, or a
NXM error, ZAPUSR will be called to release all I/O channels that are
currently open. If a passive task was not connected, but it had an
SLA assigned, a WEM/ANFCLA would result because routine CLNNET expects
the SLA to be zero.
[Cure]
In the routine ZAPUSR, set a flag for NETSER which indicates a
catastrophic error has occured. ZAPNET will then zero out the SLA and
DLA for any DDB when this flag is set, prior to calling CLNNET.
[Keywords]
STOPCODE
PARITY
NXM
[Related MCOs]
None
[Related SPRs]
35271
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
704 305 COMNET NETZAP
ERRCON ZAPUSC
NETSER ZAPNET
703A
[End of MCO 12894]
MCO: 12895 Name: JMF Date: 28-Apr-86:09:42:35
[Symptom]
MONGEN won't allow special devices to be put on CPU's other than CPU0.
[Diagnosis]
When MONGEN asks the question:
TYPE "DEVICE-MNEMONIC,PI-CHANNEL" FOR SPECIAL DEVICES ...
It expects and answer in the form of DEV,PI#. It checks that the PI number
is less than or equal to 7. If a customer wishes to put a device on PI level
3 on CPU1, the correct response is 13. MONGEN doesn't allow this.
[Cure]
Condition the legal answers based on the number of CPU's.
[Keywords]
[Related MCOs]
None
[Related SPRs]
35381
[MCO status]
None
[MCO attributes]
New development MCO
Documentation change
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 305 MONGEN ASKDPE
COMMON M.GEN
704
[End of MCO 12895]
MCO: 12897 Name: JAD Date: 29-Apr-86:13:17:12
[Symptom]
Possible DMA NXMs and memory overruns using RP07s on a system
with a CI or NI.
[Diagnosis]
CI and NI PCB interlocking by KLPSER and KNISER doesn't use
the "new" scheme of interlocking. The routines don't use an
AOSE/JRST .-1 loop exactly (a few CAIx/AOJA between AOSE's)
but they might potentially tie up memory.
[Cure]
Change PUTQUE and REMQUE in KLPSER and KNISER to use the "new"
scheme (SKIPGE before the AOS).
[Keywords]
OVERRUNS
[Related MCOs]
12695
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 306 KLPSER PUTQUE,REMQUE
KNISER PUTQUE,REMQUE
704
[End of MCO 12897]
MCO: 12898 Name: JAD Date: 29-Apr-86:14:44:58
[Symptom]
Stopcode BEC when reloading a KL with CI disks.
[Diagnosis]
It appears the HSC-50 disk server isn't releasing his
connection properly when the virtual circuit to the KL
goes away when the KL crashes. When the CI disk driver
in the KL tries to sniff at a CI disk the HSC-50 sends
apparent garbage in response.
[Cure]
Initialize connect ID's to a random value (based on
CRSDTM since that's about the only random number which
is available) during SC.INI rather than initializing
them to the same value each and every reload.
[Keywords]
BEC
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 306 SCASER SC.INI
704
[End of MCO 12898]
MCO: 12900 Name: DPM Date: 1-May-86:04:59:00
[Symptom]
The monitor doesn't support the soon-to-be supported mail program.
[Diagnosis]
No standard command to invoke MS.
[Cure]
Make it MAIL. Also equate (via IFNDEF) M.MAIL to the sixbit name of
the mail program for those customers who want to use an alternate mail
system instead of the distributed one.
[Keywords]
MAIL
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
New development MCO
Documentation change
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
704 306 COMCON RUNMAI
COMMON M.MAIL,NAMES
703A
[End of MCO 12900]
MCO: 12901 Name: JAD Date: 1-May-86:13:52:07
[Symptom]
Problems with the code in USETO which zero fills unused blocks.
[Diagnosis]
1) If an I/O error occurs while doing the zero fill FILIO just
ignores the error. Subsequent I/O operations may fail due
to stale error bits left over in S/DEVIOS.
2) POSERR refuses to deal with errors during a channel skip
(RH20 way if writing zeroed blocks).
3) ACCWRT, etc., may be wrong if a write isn't done after a
USETO which allocates extra blocks at the end of the file.
[Cure]
1) Check S for error bits and quit right away on an I/O error,
unless we were doing a channel skip.
2) POSERR is right, it's too hard to retry a channel skip. A
better approach is to have the USETO code just retry the
operation, but actually write single blocks until we have
isolated the error, then let FILIO's normal retry/recovery
code deal with the error.
3) Remember how many blocks were actually written and update
ACCWRT and friends accordingly.
[Keywords]
USETO
ZERO FILL
CHANNEL SKIP
[Related MCOs]
None
[Related SPRs]
34874, 35028, 35148, 35429
[MCO status]
Checked
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 306 FILIO USETO6,USETO7,USETO8,USETO9
704
[End of MCO 12901]
MCO: 12902 Name: JMF Date: 2-May-86:06:57:59
[Symptom]
MONPFH is too big, too slow, and too ugly. It can also wipe out the virtual
time interval setup by the user program.
[Diagnosis]
1) There are a couple of places where it clears the entire paging memory when
clearing it only for the page in question would do just fine.
2) Even though symbolic stack offsets are defined for the range check locations
on the stack, PFHTIM uses hard coded numeric offsets.
3) If the first fault time is zero, it sets .PDTMI to 60 tics. Thus, a user
program can only setup the value for .PDTMI after the first page fault.
[Cure]
1) CLRPGT => EXCTUU <CLRPT uva>
2) Use defined stack offsets. Saves about five words as well since PUSHs can
be replaced by DMOVEMs.
3) Only store in .PDTMI if its already zero.
[Keywords]
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
New development MCO
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
704 MONPFH PFHTM4,PFHTM5,PFHAAF
703A 306
[End of MCO 12902]
MCO: 12906 Name: KBY Date: 8-May-86:11:17:42
[Symptom]
Stopcode BAC on LOGOUT trying to return free core at address 0.
[Diagnosis]
Code in CTXSER assumes there's always at least one block to return,
even if the count says there aren't. Technically, there always should be one
block to return, but this is the *REAL WORLD*.
[Cure]
If the count says there aren't any, just go away.
[Keywords]
PFHJOB complex
[Related MCOs]
11102
[Related QARs]
None
[MCO status]
None
[MCO attributes]
QAR answer
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 307 CTXSER CTXLGO
704
[End of MCO 12906]
MCO: 12907 Name: KBY Date: 8-May-86:11:22:30
[Symptom]
Stopcode PFHJOB; also possible IME or DI hang latter symptoms
on SMP only).
Job hung in NAp state forever at LOGOUT.
[Diagnosis]
If a user has no context blocks, .CPJCH gets set to zero when
the job runs. This can cause us to put a job number of 0 in a DDB (causing
the PFHJOB, IME, or DI hang), or, if we go through the SLEEP code, to enter
a clock request for job 0 which never wakes us up.
[Cure]
Set .CPJCH to .CPJOB if there aren't any context blocks (i.e. CTXJCJ
gives the error return).
[Keywords]
PFHJOB complex.
[Related MCOs]
11102, 12906
[Related QARs]
None
[MCO status]
None
[MCO attributes]
QAR answer
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 307 CLOCK1 CIP70
704
[End of MCO 12907]
MCO: 12908 Name: KBY Date: 8-May-86:11:28:12
[Symptom]
User manages to ^C out at an inopportune time; this can lead to
all sorts of problems (like the "legitimate" case mentioned in MCO 12905).
[Diagnosis]
Nothing to stop him from getting out.
[Cure]
Invent new JBT table (overlapped as left half of JBTSG2, so that
we don't chew up any more address space; note that JBYSG2 moves to the
right hand 5 bits of the word) JBTCCC which contains the negative (easier
to check) count of routines who do not want the user ^Cable even though he
may be in a ^Cable state (from the point of SIMCHK). The particular
case in question was at STMAPE, so use the count there. This count
is checked by SIMCHK.
[Keywords]
PFHJOB complex
[Related MCOs]
12095
[Related QARs]
None
[MCO status]
None
[MCO attributes]
Documentation change
QAR answer
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 307 CLOCK1 SIMCHK
704 CPNSER UNCACC
COMMON JBTSG2,PSG2LH
[End of MCO 12908]
MCO: 12914 Name: KBY/RCB Date: 13-May-86:08:17:58
[Symptom]
Asynchronous TTY output can hang if the program is virtual.
[Diagnosis]
We will only get to TTYFLT from the asynch output routine
(TTMORE) if the PC is in user mode; this may or may not be the
case at the times when the PC is checked (at clock level before
dismissing to the job). Even if we get to TTYFLT, since PFH is
quite solidly bent on restarting the user in user mode, he can thrash
out the page TTYFLT pulled in by the time we get to TTMORE again (next
clock tick at the earliest).
[Cure]
Get rid of TTYFLT. Move TTMORE to running always at UUO level.
When dismissing to the job, if the PC is in exec mode, let it
be caught at UUO exit. If it is in user mode, initialize a UUO level
stack, put the continuation PC as the return PC, and act as if we were
returning from a UUO (thus going through TTMORE).
Use PFHGWD which will fault in the page and continue in exec mode
if a buffer is paged out. Give an addressing error if it fails. The PC
given will probably reflect the continuation PC; this can be fixed later
although I don't think the right PC is really available anywhere.
[Keywords]
virtual
asynch TTY output
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 307 VMSER TTYFLT
704 CLOCK1 CIP8
UUOCON USRXNT
SCNSER MORE50
[End of MCO 12914]
MCO: 12915 Name: DPM Date: 14-May-86:03:21:24
[Symptom]
Customers with unsupported ANF-10 remote devices such as plotters
cannot MONGEN their monitors with those devices.
[Diagnosis]
The questions in MONGEN are REPEAT zeroed out instead of being
available if the appropriate unsupported features are selected with
MUNGEN.
[Cure]
Make remote PTPs, PTRs, and PLTs available in MUNGEN.
[Keywords]
ANF-10 REMOTE DEVICES
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
704 310 MONGEN ANFNNM
703A
[End of MCO 12915]
MCO: 12917 Name: KBY Date: 15-May-86:23:05:29
[Symptom]
After fixing up the callers last week so user PFHs should work, things
are worse than before.
[Diagnosis]
Too many 1 1/2 word PCs around, including the one word PC USRFLT
gets called with which it tries to find out whether or not the page fault was
incurred in a non-zero section (by checking the flags as a section number) so
it can bomb out the user. Code to jump into the user PFH is equally shaky,
causing IMEs.
Unfortunately fixing USRFLT to accomodate double word PCs entails
fixing all its callers to give it double word PCs, which spills over into the
arithmetic/floating overflow code, and other APRENB related things.
Arithmetic/floating overflows occuring in non-zero sections where
the user tried to use APRENB to trap them drop the user into section 0 at
his trap routine but can't store a double word PC to tell him where the fault
was incurred.
[Cure]
Change all these things to accomodate double word PCs. If the user
is trapping for arithmetic/floating overflow with APRENB and the exception
in incurred in a non-zero section, bomb the user with
?Arithmetic overflow at extended user PC xxxxxxx
[Keywords]
overflow
APRENB
user PFHs.
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
Documentation change
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 VMSER USRFLT
704 KLSER SEILM,SUILM,SAROVF
KSSER SEILM,SUILM,SAROVF
COMMON CTUUO
ERRCON APRILM
[End of MCO 12917]
MCO: 12918 Name: KBY Date: 15-May-86:23:10:51
[Symptom]
We were a little hasty in making it so users can't get a PFH merged
into their image. It turns out there are actually three things that can happen
anyway, so use them to cause three different actions:
.JBPFH contains 0: user default (monitor's PFH). This case used
to merge in SYS:PFH; it now users the interal PFH.
.JBPFH=end,,start of user PFH: use user's PFH included in currently
running image.
.JBPFH=non-zero,,0: Used to mean user turkeyed .JBPFH, and thus
merge in SYS:PFH. Now grants an ?Ill mem ref. Use it to mean merge
in SYS:PFH.
[Diagnosis]
Because it's there.
[Cure]
Why not?
[Keywords]
PFH
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
Documentation change
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 VMSER GETPFH
704
[End of MCO 12918]
MCO: 12920 Name: KBY Date: 15-May-86:23:21:04
[Symptom]
Wasted CPU cycles.
[Diagnosis]
If a job is blocks for a sharable resource, then we notice
it's available in the schedular, we check if the job is being forced
out by the swapper, and, if not, give it the resource. We then check
other reasons that the job might not be runnable and reject it if it doesn't
pass (for example, not runnable wrt cache). Unfortunately, we've already
given this job the resource so that if anyone else wanted it they can't
run until this job can.
[Cure]
Don't give job the resource until we're sure it's runnable.
[Keywords]
sharable resource waits
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 SCHED1 SCHEDA,SCHEDC,SCHDC2
704
[End of MCO 12920]
MCO: 12921 Name: KBY Date: 16-May-86:09:20:25
[Symptom]
Monitor won't run with FTMPFH off.
[Diagnosis]
Hopeless case.
[Cure]
Turn it on permanently.
[Keywords]
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 301 VMSER
704 UUOCON
COMMON
FGEN
[End of MCO 12921]
MCO: 12922 Name: JAD Date: 19-May-86:11:06:21
[Symptom]
In an SMP configuration, adding a CPU which was never started or
which had been REMOVEd may cause the CI disks to go offline.
[Diagnosis]
KONCAM gets set when the virtual circuit to the HSC50 is opened.
However, the disks aren't actually brought online for some time
afterward, so there is a window in which FILSER thinks it can
start I/O to a disk when RAXKON won't accept it.
[Cure]
Duplicate KONCAM in the UDB (UNICAM) and make FILSER and friends
test UNICAM rather than KONCAM. Actually speeds up I/O somewhat
since we don't need to fetch the KDB address to get the bit map.
KONCAM remains for cases where the KDB might exist but no units
were ever detected (I think this only can happen for RP20 or CI
disks), and also for simplistic loops in the DIAG. UUO code.
Also, replace references to the LH of UNIALT with references to
the RH of UNICAM.
[Keywords]
CI DISKS
KONCAM
OFFLINE
ADP
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 310 AUTCON
COMMOD
COMMON
CPNSER
FILFND
FILIO
ONCMOD
RAXKON
SYSINI
VMSER
704
[End of MCO 12922]
MCO: 12926 Name: DPM Date: 20-May-86:07:42:24
[Symptom]
AUTCON may configure TU7x tape drives on a DX10 with incorrect
densities or tracks. Sometimes, drives that were usable become
unusable.
[Diagnosis]
The behavior of certain types of DX10 failures is not fully
understood. Occasionally, the CONI to read the drive sense bytes
suceeds but returns incorrect data. While this failure is part of a
much larger problem, the can defend against stale sense byte data and
making usable drives unusable.
[Cure]
Before reading the sense bytes, clear out the storage area. This
will cause the monitor to ignore drives when the DX10 fails to fill in
the sense data block, thus preventing illegal conbinations of density
and tracking information to be stored in the UDBs. Also, if the unit
has already been configured, don't do it again. Although the CONI to
read the sense bytes should return identical data each time, this will
prevent drive characteristics from being changed by a DX10 failure.
This patch only really addresses the symptoms and not the
problems themselves. It should, however, make the real problem more
tollerable until a complete solution is found.
[Keywords]
DX10 AUTOCONFIGURE
[Related MCOs]
None
[Related SPRs]
35070, 35414
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
704 310 TX1KON TX1CF1
703A
[End of MCO 12926]
MCO: 12928 Name: JAD Date: 20-May-86:12:16:23
[Symptom]
Characters output from MIC can be lost when the MIC master
job is running in a high priority queue.
[Diagnosis]
MICWAK in SCNSER calls WAKJOB in UUOCON which eventually
steps on T3 (the character being output).
[Cure]
Have MICWAK save/restore T3 around the call to WAKJOB.
[Keywords]
MIC
[Related MCOs]
None
[Related SPRs]
35366
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 SCNSER MICWAK
704
[End of MCO 12928]
MCO: 12929 Name: JAD Date: 21-May-86:11:52:02
[Symptom]
The message printed when a disk drops off line is not of the
highest quality.
[Diagnosis]
The operator is told "Please power the unit down and turn
it on again", which is not recommended for RP07s. It also
can cause a KAF stopcode if the drive is dual-ported and
some other CPU tries to start I/O on it.
[Cure]
As a first pass, change the wording of the message, to wit:
Operator intervention is required for this unit.
[Keywords]
TELOPR
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
Documentation change
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 FILIO TELOPR
704
[End of MCO 12929]
MCO: 12932 Name: JAD Date: 21-May-86:15:37:29
[Symptom]
Adding a REMOVEd KLIPA usually results in KLPNMG events. At
the very least the KLIPA probably won't be usable after it
is ADDed. Forcibly loading the KLIPA ucode doesn't cause
open virtual circuits to get closed in a timely fashion.
[Diagnosis]
Not calling the right subroutines in these cases.
[Cure]
Yes
[Keywords]
KLIPA RELOAD
CONFIG
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 KLPSER DIALOD,DIADM1
704
[End of MCO 12932]
MCO: 12933 Name: JAD Date: 21-May-86:17:17:48
[Symptom]
Internal clustering of the TOPS-10 machines will require some
way to keep disks on the HSC50 from being mounted to "foreign"
systems.
[Diagnosis]
Gee, I remember some guy invented a whizzy feature called the
Uncommon File System (disk sets) a while back. Maybe we should
turn it on and see what it does for us ...
[Cure]
Edit FGEN to turn on FTSETS for KLFULL and KSFULL.
[Keywords]
DISK SETS
UNCOMMON FILE SYSTEM
[Related MCOs]
11898
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
New development MCO
Documentation change
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 FGEN FTSETS
704
[End of MCO 12933]
MCO: 12934 Name: JAD Date: 22-May-86:12:38:16
[Symptom]
One must edit LATSER to change the maximum number of simultaneous
circuits which will be allowed. If we ever stop shipping the source
to LATSER some customers which have lots of DECSERVER-100's will be
up a creek.
[Diagnosis]
Hardcoded values in COMDEV and LATSER should have been defined
via the MONGEN dialogue.
[Cure]
Add two questions to MONGEN if LATSER is included:
# of simultaneous LAT circuits(20,1-*)
# of LAT connections(1,1-*)
Maxima are, respectively, 100 and 512 (decimal).
[Keywords]
LATSER
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
New development MCO
Documentation change
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 COMDEV NTTLAH
LATSER MAXCIR
MONGEN ASKLAT
704
[End of MCO 12934]
MCO: 12935 Name: WXD Date: 22-May-86:14:12:35
[Symptom]
DECnet stops working correctly. The -10 sees all the nodes
on the ethernet, but isn't seen by any of the nodes.
[Diagnosis]
The -10 has stopped sending ethernet hello messages. This
is caused by the -10 getting an overflow when calculating the DECnet
time (milliseconds of uptime), which is then used to determine when
to send the next message. The algorithm is:
MOVE T1,SYSUPT
IMULI T1,1000.
IDIVI T1,JIFSEC
This overflows at 159 hours, 4 minutes, 22 seconds, and 19. ticks (60hz).
[Cure]
Change IMULI -> MULI, and IDIVI -> DIVI
This algorithm won't overflow until 9544 hours of uptime (395+ days).
[Keywords]
DECnet
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
Checked
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 D36COM DNGTIM
704
[End of MCO 12935]
MCO: 12937 Name: KBY Date: 23-May-86:10:23:21
[Symptom]
Can't merge a program (like VMDDT) into a core image
(in an empty section) if there isn't a free page in section 0
(like in a dump) to read the .EXE directory into.
[Diagnosis]
There are actually 2 problems:
1. No page for the directory.
2. Code thinks it needs to diddle around with page 0 and needs
another free page in order to do that.
[Cure]
1. Use whizzy routine that temporarily removes a page from
the core image to free a page for the directory and puts it back
when done (if not overwritten).
2. If merging into a non-zero section, just read page zero of the
.EXE file into page zero of that section.
[Keywords]
MERGE
HUGE
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 SEGCON GETEXE,GTLOOP,GETFI4
704 COMCON SAV2,RELDX3
[End of MCO 12937]
MCO: 12940 Name: KBY Date: 23-May-86:10:30:58
[Symptom]
IME seen, other scenarios possible.
[Diagnosis]
Although it appears possible to get to UNLOCK at clock
level, it assumes it's at UUO level and attempts to fix .CPADR.
[Cure]
Don't change .CPADR unless the job in question (in J) matches
.CPJOB. Potentially, we ought to fix .CPADR on any CPU running the job,
but it appears that the only time we get here at clock level with the
job possibly running is when we're going to clobber it anyway
(NXM, memory parity error), so it seems only important to NOT clobber
.CPADR when it refers to some other job.
[Keywords]
unlock
[Related MCOs]
None
[Related SPRs]
31340
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 LOKCON FRELK2
704
[End of MCO 12940]
MCO: 12942 Name: JAD/WXD Date: 23-May-86:15:28:07
[Symptom]
The orange toad turned into an orange pig in 7.03.
[Diagnosis]
An alternate monitor context was invented on the 2020 in 7.03 so DECnet
could consume loads of address space. The address space was really
only needed to hold the name/address mapping information for the 1000's
of nodes in the engineering network. In the real world all the new
features in 7.03 would have fit without forcing customers to accept an
expensive solution to OUR problem.
[Cure]
Accept the fact the 2020 doesn't support multiple sections. Remove the
alternate monitor context. Use unmapped physical pages to hold the name/
address mapping information. Gain back the "overhead" involved in doing
all those page refills when switching between monitor contexts.
[Keywords]
PERFORMANCE
ORANGE PIG
TOPS-20 EMULATION MODE
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
Documentation change
KS10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 CLOCK1
COMMON
COMNET
D36PAR
KSSER
NRTSER
S
SCLINK
SCMUUO
SYSINI
UUOCON
VMSER
704
[End of MCO 12942]
MCO: 12943 Name: JMF Date: 27-May-86:07:04:15
[Symptom]
Poor SMP performance (jobs waiting for MM more than necessary).
[Diagnosis]
SHARE unconditionally gives up the MM and then goes to see if we
are putting the segment in a non-zero section (which we normally aren't) and
then gets the MM back.
[Cure]
Have CRESP0 call REMMM iff we have to create a section.
[Keywords]
Performance
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
New development MCO
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 SEGCON SHARE,CRESP0
704
[End of MCO 12943]
MCO: 12944 Name: KBY Date: 27-May-86:07:26:53
[Symptom]
Buffers output in the wrong order on EVM devices.
[Diagnosis]
IADCKL now has three returns; the EVM code to handle the
three cases doesn't match the non-EVM code.
[Cure]
Make code match; to whit, the "page not in core" return needs to
update the pointer to the next buffer (in DEVEVM) before stopping the
I/O. This needs to be done for INPUT as well (DECtapes and card readers).
[Keywords]
LPTSPL
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 UUOCON ADVBFF,ADVBFE
704
[End of MCO 12944]
MCO: 12945 Name: KBY Date: 27-May-86:07:34:23
[Symptom]
Jobs ^Cable when they really shouldn't be, potentially leading
to problems of the BAC/PFHJOB complex.
[Diagnosis]
If JERR is on when we get to JOBKL, the job becomes ^Cable
even though it's in a resource wait, running in the monitor, etc.
[Cure]
Turn off JERR before calling CTXLGO; be sure it stays off while
calling CTXLGO.
[Keywords]
[Related MCOs]
11102
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 302 CTXSER SWTCT2
704 COMCON JOBKL
[End of MCO 12945]
MCO: 12949 Name: JAD Date: 30-May-86:15:26:06
[Symptom]
Access to the CI20 and NIA20 queues takes a long time.
[Diagnosis]
The queues contain physical addresses. Each reference
requires a call to a routine to temporarily make the address
accessible via a virtual address. This is a big lose when a
lot of queue shuffling takes place.
[Cure]
Use the physical MOVE/MOVEM instructions in KL microcode
version 436 or later. Bit 4 of the APRID word indicates if
the microcode supports this feature. Reduces the cost of
physical memory reference from 37 instructions plus two
CLRPGT's to 4 instructions.
[Keywords]
PHYSICAL MOVE/MOVEM
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
New development MCO
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 303 COMMON .CPPMV
DATMAN PMOVE,PMOVEM
KLPSER SOME
KNISER MORE
S ID.PMV
704
[End of MCO 12949]
MCO: 12955 Name: JAD Date: 4-Jun-86:11:38:20
[Symptom]
Problem with MCO 12934.
[Diagnosis]
LAT terminals come out of the network LDB pool. Asking
a separate question about the number of LAT terminals in
the network section of MONGEN is misleading.
[Cure]
Until we get daring and have all the network LDB users
have their own pool (HAH!) remove the question about the
number of LAT terminals. Still leave the question about
the maximum number of circuits in MONGEN.
[Keywords]
LAT
[Related MCOs]
12934
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
Documentation change
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 303 COMDEV NTTLAH
MONGEN ASKLAT
704
[End of MCO 12955]
MCO: 12958 Name: TL Date: 7-Jun-86:23:20:41
[Symptom]
Sore elbows.
[Diagnosis]
People end up standing on their elbows to create their own system-specific
MONGEN.MIC/MONGEN.CTL files.
Elbows weren't meant for standing on. Most people have trouble trying.
[Cure]
Teach MONGEN to output MONGEN.MIC, a file which will re-construct
the user's responses to the MONGEN dialogs. MONGEN.MIC obeys the following
slightly weird rules:
1. In 7.03 A, there is a MUNGEN feature, "MICGEN", which enables the question:
Write MONGEN.MIC(Y,N)[etc...]:
If answered N, the file will not be written.
2. In 7.04 and beyond, the MICGEN option goes away, and the question will
always be asked.
3. MONGEN refuses to supersede a previously existing MONGEN.MIC file.
Therefore, one would usually .RENAME <anyname.mic>=MONGEN.MIC
4. MONGEN.MIC contains, as comments, the /HELP:PROMPT level of each question.
5. Erroneous input is duly recorded, but the question appears only once.
This enables one to go back and easily find one's mistakes.
6. A couple of questions with peculiar prompts (eg: "SYMBOL,VALUE")
are not currently logged as comments, although the responses are.
[Keywords]
MONGEN
MUNGEN
MICGEN
ELBOWS
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
Beware file entry required
Documentation change
[BEWARE text]
MONGEN now has the latent capability of producing a .MIC/.CTL
format typescript of your session. See MCO 12958 for details. MONGEN
will announce when it does NOT write such a file. The error is a
warning ("%") error, but could break some control files.
To enable the capability, Use the MUNGEN INCLUDE MICGEN command.
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A MONGEN MICXXX
704
[End of MCO 12958]
MCO: 12961 Name: KBY Date: 12-Jun-86:15:08:59
[Symptom]
Possible confusion if an interrupt occurs on the policy CPU while
it is in the progress of LOCKing a job physically contiguous in core, and
the page the UPT needs to occupy is also part of the job which is LOCKing.
[Diagnosis]
If we take an interrupt after the UPT data has been exchanged
with the data page, and before we've fixed up the SPT and JBTUPM, and
the page with which the UPT was exchanged with contains an "interesting"
number in relative location .UPJOB, SVEUB does the wrong thing.
[Cure]
Turn off the PIs on the executing (policy) CPU while things
are in transition. Note that since the job is not runnable AND we are
on the policy CPU, the job should not be mapped any place else nor should
any interrupt occur for it on another CPU, so turning off the PIs on the
executing CPU only should be sufficient. We are running on the NULPDL so
there should also be no problems with inadvertant references to data
residing in the UPT.
[Keywords]
LOCKing.
[Related MCOs]
None
[Related SPRs]
35459
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 303 LOKCON LOCK13
704
[End of MCO 12961]
MCO: 12963 Name: JAD Date: 13-Jun-86:10:47:36
[Symptom]
Long wait while ONCE checks if all CPUs are running.
[Diagnosis]
ONCCPU tries to circumvent the wait by substituting a short
time for the wait time. However, there is another wait loop
in CPUXCT, which waits for the CPU to start processing the
request. The time for this wait loop never gets changed, so
we wait longer than ONCCPU wanted us to.
[Cure]
Add another flag to the XCTCPU macro, XC.SHT, which indicates
the caller desires a short wait time.
[Keywords]
XCTCPU
Long wait
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 304 ONCMOD CPUXCT
704
[End of MCO 12963]
MCO: 12964 Name: JAD Date: 13-Jun-86:19:44:15
[Symptom]
Stopcode KAF, others likely, when removing a CPU or a KLIPA.
[Diagnosis]
STPKLP puts the KLIPA in the disabled state, but never resets
the port. It appears the KLIPA can interrupt while disabled.
Even if it can't, we should really stomp on the critter when
stopping it.
[Cure]
Add a JFCL after calling DISKLP so we do a CONO KLP,CO.CPT.
[Keywords]
KLIPA
PPDRMV
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 304 KLPSER STPKLP
704
[End of MCO 12964]
MCO: 12968 Name: KBY Date: 19-Jun-86:13:19:34
[Symptom]
?Swap read error on fragmented swap on the KS
[Diagnosis]
One more stack entry used on the KS
[Cure]
-10(P)-->-10-IFN FTKS10,<1>(P)
[Keywords]
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
KS10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 305 VMSER THIS
704
[End of MCO 12968]
MCO: 12970 Name: JAD Date: 23-Jun-86:14:44:46
[Symptom]
BOOTing 7.04 will be a real hassle.
[Diagnosis]
BOOT, for historical reasons, always loads high segments
immediately following low segments. This is a real pain if
the monitor contains several PSECTs, since where ONCE thinks
the monitor was loaded may not necessarily be correct.
[Cure]
Always load .EXE files into the physical pages specified
in the .EXE directory. This makes it simple for ONCE to move
pages around to set up the final monitor mapping. Remove the
code in ONCE which checked for the "old" case.
[Keywords]
BOOT
HIGH SEGMENTS
PSECTS
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
None
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 305 ONCE ONCE4C
704
[End of MCO 12970]
MCO: 12971 Name: JAD Date: 23-Jun-86:22:17:37
[Symptom]
CPUx gets a KLPSWO event for CPUy's CI node number when CPUy
is ADDed after it had been REMOVEd via CONFIG.
[Diagnosis]
CPUx gets a no response error back from the ID request it
sent to CPUy. It then lights some status bits and does nothing.
[Cure]
If both paths are no response status, close any open virtual
circuit.
[Keywords]
KLPSWO
[Related MCOs]
None
[Related SPRs]
None
[MCO status]
None
[MCO attributes]
KL10 only
[Validity]
Monitor Load Module Tags
------- ------ ------ ------
703A 305 KLPSER RIDERR
704
[End of MCO 12971]