Re: DMKLOG052E ERROR IN CP DIRECTORY

On 27 August 2010 15:21, Mike Stramba <[email protected]> wrote:
>>ACC sure isn't a R/O command when accessing a R/W disk..
>
> Ok, but does ACC actually *write* to a disk  ?

Normally no, but RELease can do so. And of course any command you run
that uses the ACcessed disk can potentially write to it. But I doubt
that your ACCess or Listfile messed up your directory.

>>What's at 231 ?
>
> The sixpack directory:
>
> DIRECTORY 231 3350 VM50-1

Are you sure you understand the general way the directory works? I ask
this both because of this thread, and your earlier question about
whether there's a control block or something that contains a list of
all users. Perhaps you do understand this, but I'll go through it very
briefly just in case. All from memory, so naturally there will be some
glitches, but I am certain the concepts are right...

Basically there is a CMS file containing plain text statements that
define CP users and their attributes, according to a defined syntax.
Then there is a CMS (not CP) command called DIRECT (DIRECT MODULE or
DIRECTXA MODULE in later systems, built from source module DMKDIR),
that compiles this text format file into the internal format used by
CP, and writes it to disk. This CP internal format is not human
readable, and in fact is obfuscated by being XOR'd with some
hard-coded string just so passwords and such don't jump out when seen
in a dump. It is defined by mapping macros with names like DIRBLOK or
the like.

The CP internal format is formatted just like CP page or spool space,
and space for it is identified using the CP format (DMKFMT or
CPFORMAT) command, just the way PAGE or TEMP or whatever kinds of
space are identified in the allocation map on the volume. You can use
CPFMT to list the layout for you without changing it. There is always
a primary (active) and a backup (inactive) directory area. The active
directory area is pointed to by the VOL1 record for the volume. The
DIRECT command always writes its compiled output to the inactive area,
and then changes both the flags for the cylinders, and the VOL1
pointer so as to swap the active and inactive versions. If you have a
crash in the middle of running DIRECT, all should be OK...

The CMS file containing the text statements can live anywhere - it's
up to you how you keep track of it, and you can have as many possibly
conflicting copies as you like, since CP knows nothing of it. It's
just input to the compiler (DIRECT command). You can even keep it on
your Windows machine or the like, since CP has no knowledge of it at
all. (In fact some versions of the VM ADCD for the P/390 machines
actually kept all text directory info in multiple OS/2 files, and
managed the whole thing using OS/2 panels. Experienced VM sysprogs
gagged at this scheme, but it may have made life easier for the new
users IBM was aiming at.)

The CP (compiled) version of the directory is read by routines in
DMKUDR, which in turn use paging system code to do the actual I/O. So
when you logon, or issue a SPOOL PRINT to FRED, or a LINK JANE 191 291
RR command, the CP commands use routines in DMKUDR to find what they
want.

The final link is how the DIRECT command actually writes to the CP
directory space. The CP directory area is not a CMS file system, so it
makes no sense to use a command like ACcess on it. DIRECT uses
standard I/O (I believe via Diagnose if running in a VM, or SIO if
standalone; you can check). But it needs a disk to write to, and
that's why you typically have a minidisk in MAINT's VM that addresses
the CP directory volume in use, and the address is by convention 123.
There is no magic about MAINT in running the DIRECT command, but it is
unwise to have multiple text directories except for backup, so it
makes sense to keep your text file(s) on a minidisk easily accessible
to the userid you plan to run DIRECT from.

There's more, but I'm running late...

Tony H.