Re: DMKLOG052E ERROR IN CP DIRECTORY

Mike Stramba wrote:
> 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.
> 

OS disk are treated as read-only by VM so you shouldn't break anything.

> Are all the folowing comands executed from the OPERATOR machine ?
> 
> If so,  /DIRECT (entered from herc console) gives  ?CP DIRECT
> 

DIRECT is normally executed from MAINT

>> 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!
>>
>>
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 
>