Re: disk2file readback on Mk5
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: <John.Reynolds_at_email.protected>
Date: Fri, 10 Dec 2010 07:35:30 +1100 (EST)
Jon,
>mk5=scan_set=98
>mk5=scan_set=98:03h33m50s:03h33m52s
>mk5=disk2file=/home/oper/data/vx999e_pa_no0005.m5a
Yep that seems to work OK on our Mk5b+ as well.
Cheers,
John R
On Thu, 9 Dec 2010, Jonathan Quick wrote:
>Hi John
>
>Trimming and answering in-line below:
>
>On Thu, December 9, 2010 6:00 am, John Reynolds wrote:
>>Some problems were experienced at Parkes during the recent Oct/Nov session
>>in fringe-checking with the Mk5, using disk2file.
>>
>>o In the original schedule a non-existent target directory
>>/home/oper/data was specified for the data;
>>
>>disk2file=,/home/oper/data/vx999e_pa_no0005.m5a,10h27m49.00s,10h27m50.00s,
>>
>>NB: the above command specifies a *.m5a suffix instead of *.m5b.
>
>I think both of those are configurable in DRUDG, or more specifically in
>the control file /usr2/control/skedf.ctl
>
>>o The original schedule contained commands;
>>
>>disk2file=abort,,
>>?ERROR 5f -308 Parameter after abort must be 'autoftp' or blank.
>>
>>which fs-9.10.0 rejected. The latest fs 9.10.4 (now installed at
>>Parkes)
>>accepts it.
>
>That one was a simple FS bug (now fixed)
>
>>o Specifying start and stop times in a Mk5b disk2file command will
>>invariably fail except on the last recorded scan. For example
>>if there are 98 scans recorded on the active disk module;
>>
>>03:57:26;disk2file=98,,03h33m46s,03h33m47s
>>03:57:42;disk2file=98,,03h33m50s,03h33m52s
>>03:58:49;disk2file=98
>>
>>all works expected, but if I now record a 99th scan the first two
>>commands above now fail;
>>
>>04:01:53;disk2file=98,,03h33m50s,03h33m52s
>>04:01:53?ERROR m5 -900 Probably flawed scan
>>
>>I've raised this 'feature' with Dan Smythe and Ed Himwich.
>>Dan seemed unfazed, remarking pithily;
>>
>>>> You have opened a can of worms.
>>>> 'mk5=disk2file' is known not to work as advertised.
>
>To make something more like fishing bait out of it. I have discovered that
>the following invocation does seem to work (with Mark5A ... you would need
>to confirm with dimino)
>
>mk5=scan_set=98
>mk5=scan_set=98:03h33m50s:03h33m52s
>mk5=disk2file=/home/oper/data/vx999e_pa_no0005.m5a
>
>It is also possible, by using the command "mk5=scan_check?" straight after
>the second "mk5=scan_set", to confirm that the correct region has been
>selected before you trigger the "mk5=disk2file" (which otherwise might
>take ages to complete if the whole scan happened to be selected.)
>
>So it seems that you have to select the whole of the scan first before you
>select a timed subsection, but once that is done, other Mark5 commands
>will use the start and end offsets of that subsection as defaults.
>
>Unless I'm missing something, it should be possible to make the FS hide
>all of this inside its disk2file snap command (a task for Ed :-)
>
>Regards
>Jon
>
>
Received on 2010-12-10 07:35:55
Date: Fri, 10 Dec 2010 07:35:30 +1100 (EST)
Jon,
>mk5=scan_set=98
>mk5=scan_set=98:03h33m50s:03h33m52s
>mk5=disk2file=/home/oper/data/vx999e_pa_no0005.m5a
Yep that seems to work OK on our Mk5b+ as well.
Cheers,
John R
On Thu, 9 Dec 2010, Jonathan Quick wrote:
>Hi John
>
>Trimming and answering in-line below:
>
>On Thu, December 9, 2010 6:00 am, John Reynolds wrote:
>>Some problems were experienced at Parkes during the recent Oct/Nov session
>>in fringe-checking with the Mk5, using disk2file.
>>
>>o In the original schedule a non-existent target directory
>>/home/oper/data was specified for the data;
>>
>>disk2file=,/home/oper/data/vx999e_pa_no0005.m5a,10h27m49.00s,10h27m50.00s,
>>
>>NB: the above command specifies a *.m5a suffix instead of *.m5b.
>
>I think both of those are configurable in DRUDG, or more specifically in
>the control file /usr2/control/skedf.ctl
>
>>o The original schedule contained commands;
>>
>>disk2file=abort,,
>>?ERROR 5f -308 Parameter after abort must be 'autoftp' or blank.
>>
>>which fs-9.10.0 rejected. The latest fs 9.10.4 (now installed at
>>Parkes)
>>accepts it.
>
>That one was a simple FS bug (now fixed)
>
>>o Specifying start and stop times in a Mk5b disk2file command will
>>invariably fail except on the last recorded scan. For example
>>if there are 98 scans recorded on the active disk module;
>>
>>03:57:26;disk2file=98,,03h33m46s,03h33m47s
>>03:57:42;disk2file=98,,03h33m50s,03h33m52s
>>03:58:49;disk2file=98
>>
>>all works expected, but if I now record a 99th scan the first two
>>commands above now fail;
>>
>>04:01:53;disk2file=98,,03h33m50s,03h33m52s
>>04:01:53?ERROR m5 -900 Probably flawed scan
>>
>>I've raised this 'feature' with Dan Smythe and Ed Himwich.
>>Dan seemed unfazed, remarking pithily;
>>
>>>> You have opened a can of worms.
>>>> 'mk5=disk2file' is known not to work as advertised.
>
>To make something more like fishing bait out of it. I have discovered that
>the following invocation does seem to work (with Mark5A ... you would need
>to confirm with dimino)
>
>mk5=scan_set=98
>mk5=scan_set=98:03h33m50s:03h33m52s
>mk5=disk2file=/home/oper/data/vx999e_pa_no0005.m5a
>
>It is also possible, by using the command "mk5=scan_check?" straight after
>the second "mk5=scan_set", to confirm that the correct region has been
>selected before you trigger the "mk5=disk2file" (which otherwise might
>take ages to complete if the whole scan happened to be selected.)
>
>So it seems that you have to select the whole of the scan first before you
>select a timed subsection, but once that is done, other Mark5 commands
>will use the start and end offsets of that subsection as defaults.
>
>Unless I'm missing something, it should be possible to make the FS hide
>all of this inside its disk2file snap command (a task for Ed :-)
>
>Regards
>Jon
>
>
Received on 2010-12-10 07:35:55