From: <John.Reynolds_at_email.protected>
Date: Thu, 9 Dec 2010 15:00:15 +1100 (EST)

Cormac et al.

Some problems were experienced at Parkes during the recent Oct/Nov session
in fringe-checking with the Mk5, using disk2file. Since then I've looked
into it and have now run a couple of simple tests and have some
confidence it will work OK next time, with a little care.

Some details;

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,

   which I've now created. You could also write to /data on this machine.
   It appears the default directory if not specified is the current
   working directory of 'dimino', which is possibly why the above directory
   was chosen.

   NB: the above command specifies a *.m5a suffix instead of *.m5b.

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.

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

   as also does;
         04:06:54;disk2file=98,,00h00m00s,23h59m59s
         04:06:54?ERROR m5 -900 Probably flawed scan

   This unadvertised restriction on disk2file (Mark5b) contributed
   indirectly to the problems in the last run by creating a
   considerable a distraction.

   It's still possible to copy previous scans in their entirety;

         04:03:22;disk2file=98

   just not not selectively, either with absolute or relative start
   and stop times.

   The obvious consequence of this is that you can't grab a subset of a
   scan for fringe-testing once the next scan has been recorded. This
   shouldn't normally be a problem when running under a schedule.

   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.

Cheers,
John R
Received on 2010-12-09 15:00:46