| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 302.1 | Internals Guide Has Answers... | WORM::MCCLURE | The Kwisatz Haderach | Tue Sep 02 1986 15:46 | 7 |
| Have you tried "VAX/VMS Internals and Data Structures" manual ? It has an
appendix that explains most of the ones I saw mentioned in your note. I didn't
recognize DYNDEF, but since my copy of the manual is at home, it may indeed
be in there.
Greg.
|
| 302.2 | try extracting them | VAXWRK::NORDLINGER | | Tue Sep 02 1986 16:21 | 6 |
| Also to examine each more closely you may want to do
commands of the following flavor:
$LIB/EXT = $PCBDEF/OUT=file.ext SYS$LIBRARY:LIB.MLB
John
|
| 302.3 | Guide to Device Drivers | 8587::DUTKO | Nestor Dutko | Wed Sep 03 1986 05:09 | 7 |
| re:.0
You may also want to check the GUIDE TO DEVICE DRIVERS. Alot of
the macros are explained with relationship to device drivers and
the like in there.
-- Nestor
|
| 302.4 | First 3 letters often define the structure | SKYLAB::FISHER | Burns Fisher 381-1466, ZKO1-1/D42 | Wed Sep 03 1986 15:52 | 6 |
| Often $xxxDEF macros define the data structure xxx. In particular,
they often define the symbols xxx$* For example,
$PCBDEF defines the PCB (Process Control Block), whose symbols are
named PCB$*.
Burns
|
| 302.5 | Listing Of All Of Them | VAXUUM::DYER | Define `Quality' | Wed Sep 03 1986 16:25 | 5 |
| You can get a complete listing of the modules like so:
$ libr/macro/list SYS$SHARE:STARLET
<_Jym_>
|
| 302.6 | See SYS$LIBRARY:LIB.REQ for comments | LA780::LONGO | Bob Longo | Fri Sep 05 1986 04:07 | 4 |
| Commented descriptions are in SYS$LIBRARY:LIB.REQ. Once you get
to LIB.MLB, the comments are gone.
-Bob
|
| 302.7 | $DYNDEF and macro definitions | MDVAX3::COAR | A wretched hive of bugs and flamers. | Tue Nov 24 1987 00:47 | 32 |
| > $ libr/macro/list SYS$SHARE:STARLET
LIB
STARLET contains the `for public consumption' definitions, which
are reasonably well documented in the various manuals (RMS, System
Services, I/O Abuser's, &c.). LIB contains the VMS structure
definitions, device-driver structures, and so on; the stuff that
of which hacking is made.
$DYNDEF defines different standard structure types. For instance,
the SHOW POOL command in ANALYZE /SYSTEM and ANALYZE /CRASH (SDA,
for you old-timers) uses the field xxx$B_TYPE (e.g., PCB$B_TYPE),
which is *always* at the same offset (i.e., 10 [decimal] bytes from
the start of the structure) to determine what kind of structure
it is currently looking at. PCB$B_TYPE will contain DYN$_PCB.
This is how the FORMAT command knows how to display the mnemonic
offsets; when it complains about
`no "XXX" symbols found to format this block'
it is because it has determined that the TYPE field contains DYN$_XXX,
and you haven't done a READ SYS$SYSTEM:SYSDEF (or wherever XXX symbols
are defined). When it complains about
`invalid block type in specified block'
it is because the byte at that offset contains a value which is
not defined in $DYNDEF.
Cheers!
#ken :-)}
|