Re: [Simh] Overwrite last track and set badblocks

[Will Senn]

On 1/21/16 9:48 AM, Mark Pizzolato wrote:

Hi Will,

On Thursday, January 21, 2016 at 7:01 AM, Will Senn wrote:

A quick couple of questions...

1. Why does SimH prompt to overwrite the last track on some images every
time it runs, even if I let it, it will ask on the next run.

2. What is a use case for setting bad blocks and is it a one shot deal or does 
it
need to stay in the .ini?

DEC shipped disk devices which were formatted at the factory.  Almost all
disk media had a very small percentage of the media which didn't perfectly
store data.  Certain modern, disk devices (MSCP) had spare sectors built into
the internal format information on the drives and they presented a full disk
of clean blocks to the system.  Older disks shipped with factory with a defect
table written in the last track of the device.  When an operating system
initially wrote file system data structures on a disk volume, it would allocate
the defective sectors to a BADBLOCK file on the disk and therefore those
sectors would be avoided for normal user data.  During the life of the disk
some areas might subsequently become bad.  If the OS detected these
later the newly identified areas would also be allocated to the BADBLOCK
disk file and the rest of the disk could still be used.

Thanks for the explanation.

So, back to your original question.  The prompt about "overwriting the last
track" is intended to create an essentially empty list of defective sectors
for a newly created disk image (for the disk types which actually had this
'feature').  The intention is that you should be prompted for this (or could
provide a -Y switch on the attach command) ONLY when you are creating
a new disk image.  If you are being prompted with this question each
time you attach an existing disk image then there could be a bug.  Please
identify the simulator and the specific commands which generate this
prompt.


OK. I figured some of this out...

In RT-11v5.3 if I have the following ini section for a disk:
set rl1 writeenabled
attach rl1 storage.dsk

And I say no initially to the prompt:
Overwrite last track? [N]N

When I try to initialize the disk in RT-11, I get an error:
.initialize dl1:
DL1:/Initialize; Are you sure? Y
?DUP-F-Bad block in system area DL1:

But, if I answer Y:
Overwrite last track? [N]Y

All is good in the world. I get no errors initializing and I no longer 
get prompted at startup:

.initialize dl1:
DL1:/Initialize; Are you sure? Y

.dir vol:

0 Files, 0 Blocks
10172 Free blocks

This being the case, it appears that set badblock does not appear to be 
required. For the sake of discussion, if there is a case when it is 
required, is it a one-shot deal where the command is run in simh and 
then left out of the ini file after the bad block is created?


Thanks,

Will


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Overwrite last track and set badblocks

[Paul Koning]

> On Jan 22, 2016, at 10:29 AM, Will Senn  wrote:
> 
> ...
> OK. I figured some of this out...
> 
> In RT-11v5.3 if I have the following ini section for a disk:
> set rl1 writeenabled
> attach rl1 storage.dsk
> 
> And I say no initially to the prompt:
> Overwrite last track? [N]N
> 
> When I try to initialize the disk in RT-11, I get an error:
> .initialize dl1:
> DL1:/Initialize; Are you sure? Y
> ?DUP-F-Bad block in system area DL1:
> 
> But, if I answer Y:
> Overwrite last track? [N]Y
> 
> All is good in the world. I get no errors initializing and I no longer get 
> prompted at startup:
> .initialize dl1:
> DL1:/Initialize; Are you sure? Y
> 
> .dir vol:
> 
> 0 Files, 0 Blocks
> 10172 Free blocks

That all makes sense.  Since you were initialing an RL01 or RL02, the system 
expects a DEC Std 144 bad block table.  In the first try, it wasn't there.  
What may have happened is that initialize used what it found and mistook it for 
valid, and ended up believing it was told that block 0 is bad.  That would 
certainly make initialize unhappy.

> This being the case, it appears that set badblock does not appear to be 
> required. For the sake of discussion, if there is a case when it is required, 
> is it a one-shot deal where the command is run in simh and then left out of 
> the ini file after the bad block is created?

The bad block table lives on the disk, i.e., in the disk image file.  Unless 
it's overwritten, or you recreate the file, it will persist.  So yes, it is a 
one-shot deal.

paul

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Overwrite last track and set badblocks

[Mark Pizzolato]

Hi Will,

On Thursday, January 21, 2016 at 7:01 AM, Will Senn wrote:
> A quick couple of questions...
> 
> 1. Why does SimH prompt to overwrite the last track on some images every
> time it runs, even if I let it, it will ask on the next run.
> 
> 2. What is a use case for setting bad blocks and is it a one shot deal or 
> does it
> need to stay in the .ini?

DEC shipped disk devices which were formatted at the factory.  Almost all
disk media had a very small percentage of the media which didn't perfectly 
store data.  Certain modern, disk devices (MSCP) had spare sectors built into 
the internal format information on the drives and they presented a full disk 
of clean blocks to the system.  Older disks shipped with factory with a defect
table written in the last track of the device.  When an operating system 
initially wrote file system data structures on a disk volume, it would allocate
the defective sectors to a BADBLOCK file on the disk and therefore those 
sectors would be avoided for normal user data.  During the life of the disk
some areas might subsequently become bad.  If the OS detected these 
later the newly identified areas would also be allocated to the BADBLOCK
disk file and the rest of the disk could still be used.

So, back to your original question.  The prompt about "overwriting the last 
track" is intended to create an essentially empty list of defective sectors 
for a newly created disk image (for the disk types which actually had this
'feature').  The intention is that you should be prompted for this (or could 
provide a -Y switch on the attach command) ONLY when you are creating
a new disk image.  If you are being prompted with this question each 
time you attach an existing disk image then there could be a bug.  Please 
identify the simulator and the specific commands which generate this 
prompt.

Thanks.

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] Overwrite last track and set badblocks

[Will Senn]

Hi,

A quick couple of questions...

1. Why does SimH prompt to overwrite the last track on some images every time 
it runs, even if I let it, it will ask on the next run.

2. What is a use case for setting bad blocks and is it a one shot deal or does 
it need to stay in the .ini?

Thanks,

Will

Sent from my iPhone
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Overwrite last track and set badblocks

[Paul Koning]

> On Jan 21, 2016, at 10:48 AM, Mark Pizzolato  wrote:
> 
> Hi Will,
> 
> On Thursday, January 21, 2016 at 7:01 AM, Will Senn wrote:
>> A quick couple of questions...
>> 
>> 1. Why does SimH prompt to overwrite the last track on some images every
>> time it runs, even if I let it, it will ask on the next run.
>> 
>> 2. What is a use case for setting bad blocks and is it a one shot deal or 
>> does it
>> need to stay in the .ini?
> 
> DEC shipped disk devices which were formatted at the factory.  Almost all
> disk media had a very small percentage of the media which didn't perfectly 
> store data.  Certain modern, disk devices (MSCP) had spare sectors built into 
> the internal format information on the drives and they presented a full disk 
> of clean blocks to the system.  Older disks shipped with factory with a defect
> table written in the last track of the device.  

This is sometimes referred to as the "DEC Std 144" format.  That's a DEC 
internal standard that describes the format of the table in question.  It 
applies to many but not all pre-MSCP drives.  Some drives (RK05, RP03) predate 
this standard; these would normally be shipped from the factory as flaw free 
packs.  Judging by some tables in the RSTS disk formatting code, RK06/07 and 
RL01/02 have DEC Std 144 tables; RP07, RM02/03/05 also (but not RP04/5/6).

I saw this message recently, and it repeated itself when I told it no.  When I 
said yes, the next time the message did not appear.  It might be that you get 
it repeatedly if your host OS overwrites the table.  DEC OSs should not do so. 

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh