The Vision Council Posted October 28, 2019 Report Share Posted October 28, 2019 An objection has been raised to including the record length change in the upcoming 3.13 version of the standard. The arguments against including this change have been made in the following thread: http://forums.thevisioncouncil.org/topic/99-field-length-max-size/ Please read that information and then vote in this poll. EDIT: Also, if you vote against the change, please briefly give your reasons. Quote Link to comment Share on other sites More sharing options...
The Vision Council Posted October 28, 2019 Author Report Share Posted October 28, 2019 Dave Wedwick's "no" vote response: Quote I'm voting that if anyone has an issue with it, it should be pushed to a later version. I actually don't care myself - I don't remember who needs it or how soon. My initial thought was that there are many machine manufacturers out there that may have an issue with it as they may not be attending meetings and paying attention. But, now that I think about it, this mainly affects the host programs - if a machine starts wanting to send longer values, the host either takes it or not. So, your main audience may be the host programs, and I as a host program would transparently handle any length (there's never been a length restriction in our software) - that's why I don't care either way. So, that's it - if anyone has a problem with it, maybe it should be postponed. But, the host programs are probably the target audience. Quote Link to comment Share on other sites More sharing options...
tonyleblanc Posted October 28, 2019 Report Share Posted October 28, 2019 Even though Paul didn't ask for comments when voting yes, I'll interject an opinion anyway. I'm voting we include the change because there are already equipment or LDS vendors who send records/label values that exceed the limit, so we are just acknowledging an existing reality. I agree with Dave that this likely affects host systems more than equipment vendors, but LDS vendors could also be impacted, if host systems start sending lengthy records to As with Dave, we've already relaxed our limits, so the acceptance or rejection of the change in the standard won't make any difference to us. Even though we are not an equipment vendor, if I were in that role and was concerned about making sure my equipment would experience no issues with any host system, then I might well decide to honour the 80-character limit for some period of time. I can't see that there is any downside to doing that for an equipment vendor. Quote Link to comment Share on other sites More sharing options...
The Vision Council Posted October 28, 2019 Author Report Share Posted October 28, 2019 Thanks Tony. I was thinking that since a "no" vote at this stage means countering the approval we just did at VEW it would be important to know why people changed their minds. I do appreciate all feedback though. We need more voices on the topic. Quote Link to comment Share on other sites More sharing options...
Robert Shanbaum Posted October 28, 2019 Report Share Posted October 28, 2019 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. Quote Link to comment Share on other sites More sharing options...
The Vision Council Posted October 29, 2019 Author Report Share Posted October 29, 2019 Pretty disappointed at the low turnout. Quote Link to comment Share on other sites More sharing options...
Ronald Carey Posted October 29, 2019 Report Share Posted October 29, 2019 In the same light as Tony, I'm just explaining why I voted yes. I'm OK including it either way so that would include the 3.13 version therefore I would not vote no. Speaking purely from the ELoA Website perspective and pointing out that our actual calculations are conducted in XML, I'm quite certain that even though we do not limit the incoming size of data from the .lds file (we read until the record terminator) we will for now continue to comply with the 80 character limit on the .lms side. I'm hoping we will see other comments posted from our actual calculations folks regarding any equipment data blocks that might contradict my statement. Quote Link to comment Share on other sites More sharing options...
Jill DeLong Posted October 29, 2019 Report Share Posted October 29, 2019 I voted Yes. The only lines that I have experienced so far that exceeded 80 characters were XSTATUS coming from a device to our LMS. I don't believe that we are breaking anything with this new extension. I don't think anyone will start sending 255 character LTYPEs immediately with this new standard version. I think we are merely allowing for newer fields - which existing systems and machines won't be able to handle yet, anyway - to send up to this new limit of characters. Quote Link to comment Share on other sites More sharing options...
Haim Shlomo [Shamir] Posted October 30, 2019 Report Share Posted October 30, 2019 (edited) I also voted yes. I also don't see that as a major change that requires special action from those parties who would like to comply with the new standard. It is just as good to declare you are not able to support 3.13 as to 4.something. Edited August 4, 2020 by Haim Shlomo [Shamir] Quote Link to comment Share on other sites More sharing options...
Yaron [LaserOp] Posted November 1, 2019 Report Share Posted November 1, 2019 (edited) I want to mention again that the options aren't only to go ahead with the increase as-is in 3.13, vs making a newer major version 4.0 . There are some possible modifications to the change that will prevent any breaking behavior, and so make it technically eligible for 3.13. Please check my last comment on the discussion thread, listing some options that occurred to me, including one that came from Paul. I also think a lot of people maybe didn't read the discussion, or notice the details of why I claim it's a breaking change, as for example: On 10/29/2019 at 9:42 PM, Jill DeLong said: I don't believe that we are breaking anything with this new extension.... I think we are merely allowing for newer fields - which existing systems and machines won't be able to handle yet, anyway - to send up to this new limit of characters. So, instead of yet another explanation, an example to illustrate the issue. This will show device->host initialization request, and host->device job data. These are simplified for the purpose, and to make it more readable this handles as if the previous limit was 20. Starting sitatuion, initialization, device to host: Quote DEV=GEN VEN=Foo MODEL=Bar DEF=BLA D=ADD;SVAL;TIND; D=LIND;SBBCIN; D=SBBCUP;ACOAT TRCFMT=1;10;E;B ENDDEF=BLA If the device and host were using DCS 3.07, and the device changed to 3.12, nothing happens. If the host changed to 3.12, nothing happens. Everything keeps working as is. Nobody cares what is the version on the other side, because it shouldn't matter when not using new fields/labels. But if the device changes to 3.13m, this happens automatically: Quote DEV=GEN VEN=Foo MODEL=Bar DEF=BLAD=ADD;SVAL;TIND;LIND;SBBCIN;SBBCUP;ACOAT TRCFMT=1;10;E;B ENDDEF=BLA And now, if the host is not up to 3.13, it's possible for it to either stop with an error because it doesn't have a valid D at all, or to just return ADD, SVAL, TIND, and LIND, completely ignoring the other three labels that the device needs. Most up do date hosts probably support receiving unlimited length anyway, but they don't have to, and not all hosts in all labs are up to date and well maintained. Not being able to process length beyond the official max is entirely 100% fine and in compliance with the DCS. Which is why this is a breaking change. The device was updated, there was no configuration changes, no new labels or new fields are used. But things stop working. From the other side, same thing, assume this is job data: Quote DO=B JOB=1234 ADD=1.75;1.75 SVAL=3.93;3.93 LIND=1.499;1.499 TIND=1.498;1.498 SBBCIN=0;0 SBBCUP=0;0 TRCFMT=1;10;E;R;F R=2595;2600;2604 R=2609;2614;2618 R=2623;2628;2633 R=2638 TRCFMT=1;10;E;L;F R=2595;2600;2604 R=2609;2614;2618 R=2623;2628;2633 R=2638 If the host upgrades from 3.07 to 3.12, nothing happens. If the devices upgrades from 3.07 to 3.12, nothing happens. There wasn't any configuration changes, no new labels and fields are used, all is fine. But if the host changes to 3.13: Quote DO=B JOB=1234 ADD=1.75;1.75 SVAL=3.93;3.93 LIND=1.499;1.499 TIND=1.498;1.498 SBBCIN=0;0 SBBCUP=0;0 TRCFMT=1;10;E;R;FR=2595;2600;2604;2609;2614;2618;2623;2628;2633;2638 TRCFMT=1;10;E;L;FR=2595;2600;2604;2609;2614;2618;2623;2628;2633;2638 And now, if the device isn't 3.13, it's possible for it to stop with an error, because it doesn't have the radius length it needs. So, again, breaking change, because merely updating the host, without any configuration changes, and without trying to use any new labels or fields, can cause some devices to stop working, for jobs and data where they worked perfectly fine with before. As with the host, it's likely that it won't cause any issue with most devices, who may not have a length limit for receiving. But they're allowed to, so some can have a problem with the limit. And no other changes along the way impacted them, at all, but this will automatically cause them to stop working properly. Edited November 1, 2019 by Yaron [LaserOp] Highlighted the 20-char-limit in samples Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.