Re: DMKLOG052E ERROR IN CP DIRECTORY

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!