Re: DMKLOG052E ERROR IN CP DIRECTORY

Hmm,  I rebooted my Win XP box and all is working again ;)

Strange thing is that when I IPL'd,  operator and AUTLOG1 ., CPWATCH,
all DID get logged in, but an "interactve" LOGON was failing.   I
guess?? the directory is used differently (not at all ??) for IPL /
autologs, from interactive logon?

*Now* I'll **backup**  ;) and then try it again .. see it happens again

>And don't *assume* ANY program will behave.

Hmm,  I don't *EXPECT*  a  "listfile  * assemble"  to  FORMAT my
minidisk, so how far do you take a "don't expect to behave to mean" ?
;)

I *thought* an   ACC  231 Q   +  LISTDS would be "harmless", but  "OS"
disks in VM are something I know little about (am reading the sysprog
manual now .. and looking through the DMKDIR   ASSEMBLE file.

Are all the folowing comands executed from the OPERATOR machine ?

If so,  /DIRECT (entered from herc console) gives  ?CP DIRECT

> Locate the operator VMBLOK, change the user id to MAINT in real storage (DCP & STCP are your friends there)

Hmm,  hadn't used / known about DCP / STCP .. just looked them up in
the sysprog manual.

DCP seems to only take a hex arg, how would you locate the operator VMBLOK ?

>> - "link * <mdisk> <vcuu> RR" (because you can link to your own minidisk without needing a password) - where <mdisk> is the minidisk holding the CP directory and vcuu is any virtual address..

Hmm, who owns the 231 disk ? ..   a  LINK  maint 231 231 rr read gives
: 231 not linked no read password

"ACC <vcuu> <letter>" and then "DIRECT <dirname> DIRECT <letter>"..
This will ensure the directory is properly written AND that the
allocation table holds the proper flag for the area containing the
"Active Directory".)

On 8/27/10, Ivan Warren <[email protected]> wrote:
> On 8/27/2010 9:21 PM, Mike Stramba wrote:
>>> ACC sure isn't a R/O command when accessing a R/W disk..
>>
>> Ok, but does ACC actually *write* to a disk  ?
>>
>>> What's at 231 ?
>>
>> The sixpack directory:
>>
>> DIRECTORY 231 3350 VM50-1
>>
>
> Ugh!
>
> What a funny idea..
>
> It's been 123 from VM/370 to z/VM 6.1.. This is a 40 year old convention !
>
> And this is NOT an OS disk ! It may look like an OS disk if you access
> it (it will say "<CUU> <letter> - OS" but it is NOT an OS disk !) so
> running LISTDS will not return anything. (The only reason for it to have
> a VTOC is to ensure that if it is accidentally made available by an
> OS/xxx type operating system it shows as being entirely allocated).
>
> And don't *assume* ANY program will behave. If you are MAINT (the VM
> Operating System maintenance user - NOT to be used to run general
> application), and you type a command and DO NOT KNOW what it actually
> does, you are on your own and you may very well break your all installation.
>
> (PS : Happened to me once on a *REAL* production system - and I did
> recover without having to IPL[1].. But it DOES require some careful
> modification of real storage : Locate the operator VMBLOK, change the
> user id to MAINT in real storage (DCP & STCP are your friends there) -
> "link * <mdisk> <vcuu> RR" (because you can link to your own minidisk
> without needing a password) - where <mdisk> is the minidisk holding the
> CP directory and vcuu is any virtual address.. "ACC <vcuu> <letter>" and
> then "DIRECT <dirname> DIRECT <letter>".. This will ensure the directory
> is properly written AND that the allocation table holds the proper flag
> for the area containing the "Active Directory".)
>
> --Ivan
>
> [1] I was Applying a VM/SP5 PUT tape - and wrongly issued "DIRECT" with
> an uplevel version of "DIRECT".. But this should have been performed as
> the VERY LAST STEP before an IPL in this case - not during day time!
>
>