Robert Shanbaum

Members
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Robert Shanbaum

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I think if the new requirements are respected - which includes limiting record label length to 16 characters - this is unlikely to be a problem. The problem situations that I've seen (where records exceed 80 characters) have generally been due to excessively long proprietary labels coming from LDS (for transmission, usually, to generators). I suspect that most LMSs have already dealt with this. The kinds of devices that might have issues with long records - I'm thinking of tracers and blockers - are unlikely to be receiving any such records in the first place.
  2. I suppose that it's possible that a use case could exist wherein a set of repeating records might need to be replaced by another set of repeating labels (or, possibly, just one label - an ENGMASK might replace a set of ENGMARKs, for instance). I'm not sure how likely such a case is to obtain.
  3. Yaron, we only send one tracing per packet, ever. And tracings are a special case, because I'm pretty sure that all LMSs can send whatever number-of-points or formats any device might specify in its initialization, without requiring PROC records (or PROCBLK datasets) at all. As I wrote, the standard is not presently explicit when it comes to which records (or datasets) might be repeating, but it seems to me that there's not really much doubt about which ones are, and which aren't. Can anyone name a record for which that is not true? I do not agree with the proposition that the presence of one record in a PROC record implies that another, different record should be changed.
  4. We didn't expressly address in the standard device-specific records that can appear multiple times; but as I wrote, I always figured these would be additive. It may be that we should expressly identify such records ("repeating records") - I can tell you that we have to do that in our software.
  5. It would appear that some elaboration of the definition of PROC records is called for. I think that my own interpretation has been that for records that can appear multiple times in a packet (such as ENGMARK or DRILLE) the operation of a PROC record would be to add the device-specific records to the records sent to the machine. We don't have a way to suppress sending particular records of that kind to a machine, but it's not clear to me that such a feature is necessary (and if it is, it will be challenging to implement in a robust way, requiring matching strings of characters across multiple "device versions" of a record). The more general case - wherein records are "singletons" (that is, only one record having a given label appears in any packet sent to a machine) - the usage is clear, is it not? I don't understand the comment above regarding a "non-optimal workaround"...
  6. But that last idea is not very different from a PROC record, is it? I suppose the presence of a semi-colon in a Record Label would suffice to identify the record as machine-specific. Given that PROCBLK was a form of shorthand for PROC records (and a reasonable way to handle PROC datasets), I don't think this would be a great approach.
  7. Tony is correct - there are very few requirements as to the sequencing of records in a packet out side of "datasets" (such as TRCFMT being followed by R records, and optionally, A, Z, ZA).
  8. Well - we can't describe a Panoptic seg either, or any number of features of various kinds of segments (radius of an Ultex?) .