ICONV difference from D3

[eppick77]

I just ran across this and wanted to pass it along.

I have code that uses this structure: IF NOT(NUM(ICONV(AMT,'MR')))
THEN

This works because if some enters F for amount, D3 will return F and
the above logic will work fine.

However, on QM, a null is returned and the code will not perform as
expected.

I had to change my code so that it is IF ICONV(AMT,"MR")="" THEN

I wanted to let you know about this subtle difference.

Eugene

[Martin Phillips]

Hi all,

> I have code that uses this structure: IF NOT(NUM(ICONV(AMT,'MR')))
> THEN
>
> This works because if some enters F for amount, D3 will return F and
> the above logic will work fine.
>
> However, on QM, a null is returned and the code will not perform as
> expected.
>
> I had to change my code so that it is IF ICONV(AMT,"MR")="" THEN

As I have indicated in an off-list response to Eugene, this was changed to
work this way back in 2003 at the request of a user migrating from D3. This
makes me wonder if D3's behaviour has changed or is configurable.

We could always add yet another QM option if necessary.

Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200

[Glen Batchelor]

Normally I would use NUM alone to check for integers or I would use an
MCN conversion to force a test variable to be numeric or null. I'm not
sure what logic Eugene is trying to apply with an MR conversion that
way. MR is implied MR0 which is not the same as MD implied as MD0 for
mask decimal to zero places.

Glen.mobile
RewriteRule ^(garbage|junk)$ /$1 [NC,L]

On Jul 18, 2009, at 9:30 AM, "Martin Phillips" <martinp...@ladybridge.com

[eppick77]

Martin,

That code has worked on R83, AP and D3 for years. I also ported it to
GA, ADDS, Ultimate etc.

I did go back and check what the date and time conversions do and they
are of the format of IF ICONV(DATE,"D")="" THEN structure. It is only
the MR conversion that seems to return the original data instead of a
null.

It might be a good idea to add another QM option but it would be
important that it only change the way that the MR iconv works. The
others work just fine. That would make it easier for those who have
tons of code that assumes the iconv of an MR will fail returning the
original data.

Eugene



On Jul 18, 9:30 am, "Martin Phillips" <martinphill...@ladybridge.com>
wrote:

[Sam Anderson]

I agree with Glen here. In R83 and later, MR and ML are supposed to be just text masks, rather than numeric checks.  Arguably, the iconv function used is redundant for any text in that not(num()) by itself will produce the same results in Pick assuming null is supposed to be treated as a numeric response.

-Sam Anderson

[eppick77]

Glenn,

Yes, doing a MCN conversion would be another way to check for if
something was numeric. I just came up with IF NOT(NUM(ICONV
(FLD,'MR'))) almost 30 years ago and it worked so I never looked
back. I was just surprised when it did not on QM. I immediately
changed my program generator to check for a null.

I simply wanted to let people know about the difference. There are so
many ways of doing the same thing. I suspect that programmers come up
with a way that works for them and then get into the habit of using
the same code.

Eugene

On Jul 18, 11:39 am, Glen Batchelor <batch...@bellsouth.net> wrote:
> Normally I would use NUM alone to check for integers or I would use an  
> MCN conversion to force a test variable to be numeric or null. I'm not  
> sure what logic Eugene is trying to apply with an MR conversion that  
> way. MR is implied MR0 which is not the same as MD implied as MD0 for  
> mask decimal to zero places.
>
> Glen.mobile
> RewriteRule ^(garbage|junk)$ /$1 [NC,L]
>

> On Jul 18, 2009, at 9:30 AM, "Martin Phillips" <martinphill...@ladybridge.com

[eppick77]

Sam,

This is straight from the manual:
Data Conversion Sample Output
12345 mr2 123.45
12345 mr02 123
123456 mr2,$ $1,234.56
123456 mr02,$ $1,235
0 mrz (none)
0 mr2,z$ (none)
123456 mr2,e 1,234.56
123456 mr2,d 1,234.56db
-123456 mr2,e <1,234.56>
-123456 mr2,c 1,234.56cr
-123456 mr2,m 1,234.56-
-123456 mr2,n 1,234.56

On Jul 18, 11:52 am, Sam Anderson <s...@easyco.com> wrote:
> I agree with Glen here. In R83 and later, MR and ML are supposed to be
> just text masks, rather than numeric checks.  Arguably, the iconv
> function used is redundant for any text in that not(num()) by itself
> will produce the same results in Pick assuming null is supposed to be
> treated as a numeric response.
>
> -Sam Anderson
>
> Glen Batchelor wrote:
> > Normally I would use NUM alone to check for integers or I would use an  
> > MCN conversion to force a test variable to be numeric or null. I'm not  
> > sure what logic Eugene is trying to apply with an MR conversion that  
> > way. MR is implied MR0 which is not the same as MD implied as MD0 for  
> > mask decimal to zero places.
>
> > Glen.mobile
> > RewriteRule ^(garbage|junk)$ /$1 [NC,L]
>

> > On Jul 18, 2009, at 9:30 AM, "Martin Phillips" <martinphill...@ladybridge.com

[Tony G]

The original R83 Pick Reference Manual says this in the
discussion of MR:

"If there are some numeric digits at the front of the value, then
these will be taken as the number, and the rest of the value will
be thrown away... If the first character of the specified value
is not numeric, then the value string will be taken without
modification."

This definition was lost in the AP Ref and subsequent revisions
of the D3 Ref but it will be back in there soon.

My recommendation would be to ensure that QM behaves to-spec,
regardless of release-specific behaviours in D3.

CRT \"\ : ICONV( "F123", "MR" ) : \"\
CRT \"\ : ICONV( "123F456", "MR" ) : \"\

D3 v7.5 Output (to-spec)
"F123"
"123"
(Unidata and Universe agree. I didn't check others)

QM 2.9-2 Output (not to-spec)
""
"123"

HTH
Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
remove.pleaseNebula-RnD.com/blog
Visit PickWiki.com! Contribute!

[Martin Phillips]

Hi Tony,

 

> My recommendation would be to ensure that QM behaves to-spec,
> regardless of release-specific behaviours in D3.
>
> CRT \"\ : ICONV( "F123", "MR" ) : \"\
> CRT \"\ : ICONV( "123F456", "MR" ) : \"\
>
> D3 v7.5 Output (to-spec)
> "F123"
> "123"
> (Unidata and Universe agree.  I didn't check others)

My UniVerse system certainly does NOT do this. I get the original data returned with ML and MR but a null string with MD. I haven't tried Unidata.

 

To return 123 when the user types 123F456, accidentally inserting a non-numeric character seems crazy. It is an error and in my opinion QM should continute to treat it as such.

 

Way back in September 2003, the late Bruce Nichol said in an email....

 

Don't know if this one's a bug or a feature, but...

We often use a line of code:
   0386:       IF NOT(OCONV(ICONV(INV.DATE,DATE.MASK),DATE.MASK) = INV.DATE) THEN ....

which, in the old days was quick way of ensuring that the input matched the given mask.  Failed ICONVs returned null.

This appears not to work similarly under QM. [QM returned the original data at this error]

Question:    Under vanilla Pick and UniVerse, if an ICONV doesn't work, null is returned. Are you trying to tell me that this is not the case with QM?

 

This is diametrically opposite to what is being suggested by this new thread. As a result of this email, we modified ICONV() to return null for failed conversions. Of course, Bruce's example is with a date conversion, not MR but he does make the general point that failed conversions should return null.

 

So, which is right?

 

Incidentally, QM follows the Information style model where the "correct" way to test whether an ICONV() worked is to check the value of the STATUS() function. A non-zero STATUS() indicates failure.

[eppick77]

Martin,

I have verified on D3 that it works the way Tony describes it. MR is
the only conversion that does not return a null if it fails.

Eugene

On Jul 19, 5:21 am, "Martin Phillips" <martinphill...@ladybridge.com>
wrote:

[Tony G]

 

---

From: Martin Phillips

Hi Tony,

 

> My recommendation would be to ensure that QM behaves to-spec,
> regardless of release-specific behaviours in D3.
>
> CRT \"\ : ICONV( "F123", "MR" ) : \"\
> CRT \"\ : ICONV( "123F456", "MR" ) : \"\
>
> D3 v7.5 Output (to-spec)
> "F123"
> "123"
> (Unidata and Universe agree.  I didn't check others)

My UniVerse system certainly does NOT do this. I get the original data returned with ML and MR but a null string with MD. I haven't tried Unidata. 

 

Back up a sec - for now we're not testing ML and MD, though those should be have the same.  The M processor code is an entry point for the mask functionality.  The R and L simply justify the data, they don't alter the core functionality.  And "D" should be functionally equivalent to "R".   IIRC, the original code was MD as opposed to MC, etc, and MR was only introduced because ML was brought in, and it only made sense to have an R with the L.

 

So - Let's start by finding out what MR does across platforms, and if there are differences with ML and MD, I think these should be addressed separately.  My UV 10.2 and UD 7.2 environments agree with D3.  Maybe there's a flavor setting or other option that alters behaviour, but such a setting should be optional.

 

To return 123 when the user types 123F456, accidentally inserting a non-numeric character seems crazy. It is an error and in my opinion QM should continute to treat it as such. 

 

That's a slippery path.  Is this the line that gets crossed where you disagree with a baseline that was established almost 30 years ago, so you're going to make your platform behave differently - and legacy code (produced but any number of developers) now needs to agree with you, the one individual?  No, I agree that there can be many areas where old rules don't seem to make sense (like modern railway trains maintain the same dimensions as chariots from over two thousand years ago) but you won't be making any productive points by making your platform non-compliant with the defacto reference platform.  This is just another place where you can add an option to allow developers to choose to see things your way, but you shouldn't knowingly force existing code to break based on whims or principles.

 

Way back in September 2003, the late Bruce Nichol said in an email....

 

Don't know if this one's a bug or a feature, but...

We often use a line of code:
   0386:       IF NOT(OCONV(ICONV(INV.DATE,DATE.MASK),DATE.MASK) = INV.DATE) THEN ....

which, in the old days was quick way of ensuring that the input matched the given mask.  Failed ICONVs returned null.

This appears not to work similarly under QM. [QM returned the original data at this error]

Question:    Under vanilla Pick and UniVerse, if an ICONV doesn't work, null is returned. Are you trying to tell me that this is not the case with QM?

 

This is diametrically opposite to what is being suggested by this new thread. As a result of this email, we modified ICONV() to return null for failed conversions. Of course, Bruce's example is with a date conversion, not MR but he does make the general point that failed conversions should return null.

 

So, which is right? 

 

In short, the documentation to which people have been coding for 30 years is "right".  If/when D3 was out of sync with the baseline docs, they were/are compelled to fix their software - and it's my position that you are similarly compelled.

 

While it sounds logical to do so, we can't lump together all similar code and expect it all to behave exactly the same.  The D code has clearly defined functionality.  Yes, a failure to convert to/from internal/external has a null result.  That's the definition of that operation.  I quoted the documentation for the MR code - the data is parsed from left to right and only non-numeric and following data are nulled.  That's a separate definition of a separate operation.  QM should comply for R83-compatibility.

 

We're not SMA here, making decisions about how the platform should behave.  This is about portability of existing code and the potential costs involved if your platform doesn't comply with the documentation of the base reference platform.  You're free to disagree with the standard.  You're free to impose your beliefs into your code.  But be prepared for more people to stumble on this.  The bottom line is that it will cost your customers more money to port to your platform.  That's just wrong.  A new "highly recommended", non-default option can be added, and you can advertise your differentiation as a platform advantage.  But imposing opinions on how the platform should work on existing code is definitely crossing a bad line.

 

 

Incidentally, QM follows the Information style model where the "correct" way to test whether an ICONV() worked is to check the value of the STATUS() function. A non-zero STATUS() indicates failure.

 

That's good news for people migrating from an Information-based platform.  It means nothing to anyone else, especially Pick guys with a ton of code that already works according to long-established standards.  Martin, you get Pick migrations (in large part) because people don't like the way PS/RD/TL does business, because they're trying to cut costs, and because QM is (arguably) the easiest platform for migration.  It doesn't help to start advertising new costly barriers to adoption, where people need to start learning new "correct" ways for things to work.

 

Tony Gravagno

Nebula Research and Development

TG@ remove.pleaseNebula-RnD.com

Nebula R&D sells mv.NET and other Pick/MultiValue products

worldwide, and provides related development services

remove.pleaseNebula-RnD.com/blog

Visit PickWiki.com!  Contribute!

[Kevin Powick]

On Jul 19, 5:21 am, "Martin Phillips" <martinphill...@ladybridge.com>
wrote:

> To return 123 when the user types 123F456, accidentally inserting a non-numeric character seems crazy. It is an error and in my opinion QM should continute to treat it as such.

Agreed. It makes no sense to return only a portion of the data. What
possible use would it be to only have some of the input string
returned?

No platform migration will be 100% painless. People should take
advantage of an issue like this to update their code, as Eugene has.

As Martin already said. One can check the status variable to verify a
correct conversion or, as he said in his very first reply, an option
could be added to emulate R83.

--
Kevin Powick

[Martin Phillips]

Hi Tony,

This sounds like time for another option setting.

Our base reference platform was the Information style model as
implemented in PI/open, not true Pick but we have always said that we
are not a clone of any other system and never will be. Migration will
always require some work though we have many options to enable Pick
style compatibilty that make it easier for users coming from D3/mvBase/
R83/etc. Our users are migrating in roughly equal numbers from
UniVerse and D3.

In my UniVerse system, contrary to your comment, the test program

CRT \"\ : ICONV( "F123", "MR" ) : \"\
CRT \"\ : ICONV( "123F456", "MR" ) : \"\

produces
"F123"
"123F456"
with MR and ML and the STATUS() function returns 0 indicating that
these are not to be treated as errors even though they have returned
the original input data. Using MD returns a null string and a status
code of 1 (data cannot be converted using the supplied conversion
code) so MD is not being treated the same as ML/MR.

One of the key features of the Information style ICONV() is that you
can test the value of STATUS() to determine if the input data was
converted successfully. This makes data validation very easy,
especially for complex items such as monetary values with currency
symbols, thouands separators, etc
$14,355.31
where syntax validation with pattern matching, etc can be difficult
because of format variations.

This doesn't say that an application must test STATUS(), only that it
can do so.

It seems that ML and MR are treated as some sort of special case in
D3's ICONV(). I think that we will need to add an option to give the
Pick style behaviour for non-numeric data. To do this, we need to
understand fully how it behaves in D3. Your quote...

"If there are some numeric digits at the front of the value, then
these will be taken as the number, and the rest of the value will
be thrown away... If the first character of the specified value is not
numeric, then the value string will be taken without
modification."

is confusing. What if there is a currency symbol? This is non-numeric.
What about sign codes such as +, -, trailing cr, etc?

The policy in QM is that, where possible, conversion codes should be
"reversible" such that
ICONV(OCONV(data, code), code)
and
OCONV(ICONV(data, code), code)
should both return the original data if the code is valid.


If we are going to add a new option to QM, it sounds like we need it
to make MR and ML work like D3, leaving the default behaviour as now
so that existing users don't have to change their applications. This
should leave everyone happy.

I don't dispute that D3 behaves as you say but, out of curiosity, why
would I find this behaviour useful in a practical situation?


Martin Phillips, Ladybridge Systems Ltd

[eppick77]

I would agree. In my case, I was using it to determine if the input
was numeric or not. It was fine for me when the input was F123 but I
would not want my program to return the 123 if what was entered was
123F12345.

For me I can not see a reason why to program that way. However, that
does not mean that someone somewhere is using that feature.

I think that the option to make it work just as D3 is fine and for me,
I have changed my code to expect a null if the iconv fails.

Eugene

On Jul 20, 3:25 am, Martin Phillips <MartinPhill...@ladybridge.com>
wrote:

[Tony G]

Snipping quotes to minimize bloat - I can provide all the bloat
we need...

There are two things going on here.
1) Disagreement with the way specific functions work in D3.
2) Keeping D3 migrations easy and low-cost.

Opinions should influence future development, and options can be
added so that people can choose how their code _will_ behave.

You can't stand on principles when it comes to migrations. This
is a very black and white issue. Does the platform support a
competitor's feature? If not, if only in part, or if just
differently, then the answer is "no". The bottom line is: what
will the cost be to VARs and end-users to re-code to make the
software work as it always has? If Ladybridge wants to get more
migrations from D3, the process needs to be as smooth as possible
with as few hidden migration costs as possible. It doesn't
matter if you agree or disagree with R83 functionality. If this
functionality is not replicated, then QM has a known issue which
increases the time=cost of migrations. This has nothing to do
with how a specific feature "should" work.

Is the migration process an opportunity to fix/improve code?
Sure, but anyone faced with the costs of doing a migration just
wants to get it done. They aren't looking for "opportunities"
now, they're looking to get away from their old vendor and to cut
costs. When that process is complete, they can better afford the
luxury of making code changes to suit personal preferences, to
get better performance, new features, or whatever they wish.

As to examples of valid applications for ("123-456" "MR")="123"
(which QM supports BTW), personally I've seen this used in
inventory apps where there are a variable number of digits and
perhaps variable delimiters, but the developer knows that the
first digits represent a part number and the remaining data has
to do with vendor IDs, lot numbers, etc. You have to remember
that part numbers aren't always determined by IT people.

I wanted to see how other platforms interpreted MR/MD/ML codes
and I'm amazed at the disparity in this market for such a
fundamental function. As I look at the results of my tests, I
see QM does something that other platforms don't. It's trying to
be nice by converting data into numbers. From everything I've
seen and read, this is not correct behaviour. When we mask text,
we choose a justification, either right or left. We're masking
text, not numbers. I hope that subtlety doesn't get lost.
Developers will use this as a means of right justifing text to
strip off some number of characters. We do Not want the DBMS to
do us a favor and remove other characters which may be
significant like plus signs, or dollar signs.

As an example, QM converts trailing CR and DB, both to imply
negative numbers (that by itself is arguable). Unidata and Caché
also do this but no other MV DBMS that I tested does. D3 strips
the CR and DB from the back end of the numbers because that is
alpha text. D3 does not interpret that as being a part of the
number. Over the years, developers have written code for
R83/AP/D3 to process data as text, stripping +/- signs, CR/DB,
parentheses, etc. If a different platform starts treating text
like numbers, this parsing code will break. As a perfect
example, D3 sees ("123CR" "MR") as "123", not numeric, but text
with alpha chars truncated. The resulting text will be
interpreted by code as positive number, and some developers will
choose to negate the results. But QM sees the "number" as
negative ("123CR" "MR" = "-123") and ("123DB" "MR" = "-123").
This is a fundamental corruption which can affect accounting
packages.

Any DBMS company that changes functionality like this is simply
expressing an opinion and not setting industry standards or
making the world a better place in any way. Expressing an
opinion that breaks legacy code imposes unwarranted costs in the
market and affects their positioning amongst competitors.

You can download the code I used for testing, and an Excel file
which shows the results of all platforms:
http://drop.io/MultiValueIConv
If you're not familiar with Drop.io, it's a free service for file
sharing. You can add files, comment on the files that are there,
and there are lots of other options. I blogged about it here:
nospamNebula-RnD.com/blog/drop-io/2009/01/dropio-intro.html

Feel free to run the code and comment on the results. Note that
due to Excel tendencies to convert data that looks numeric into
numbers, there are embedded spaces in the data. If you change
the data Excel will render it differently. Let's not get caught
up in Excel nuances.

If you find errors in the data or would like the spreadsheet
updated, I'll be happy to make corrections. Based on responses
here, I'll forward this info to other MV DBMS providers for
comment.

Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com

[Glen Batchelor]

  I agree that for migration sake the functions should behave as expected, but there is a fine line between supporting improperly written code and supporting documented behavior. There are more proper ways to strip characters, extract character groups and verify data types. All of the examples you stated should be done with functions other than output masking. Though, that's just my lone opinion. There are plenty more critical coding conventions in D3 that don't work in QM like opening a file system directory using the OPEN statement. Why is MR raising such a huge stink? If a conversion help guide says you have to use OPENPATH instead of OPEN, then why not state that MR behaves a tad differently and to suggest alternative coding options for typical (not wise) usages?

Glen.mobile

RewriteRule ^(garbage|junk)$ /$1 [NC,L]

[Kevin Powick]

On Jul 20, 5:16 pm, Glen Batchelor <batch...@bellsouth.net> wrote:
>    I agree that for migration sake the functions should behave as  
> expected, but there is a fine line between supporting improperly  
> written code and supporting documented behavior. There are more proper  
> ways to strip characters, extract character groups and verify data  
> types. All of the examples you stated should be done with functions  
> other than output masking. Though, that's just my lone opinion.

+1

--
Kevin Powick

[Tony G]

From: Glen Batchelor

> I agree that for migration sake the functions should
> behave as expected, but there is a fine line between
> supporting improperly written code and supporting
> documented behavior. There are more proper ways to
> strip characters, extract character groups and verify
> data types. All of the examples you stated should be
> done with functions other than output masking.

We're not talking about style here (or shouldn't be anyway). The
real issue is not that Eugene was using MR as a redundant check
for a numeric. I think we can all agree that the specific
example was over-coded. The point is that his example revealed a
fundamental compatibility problem in MR itself, one that can
affect some very well written code.

A problem according to whose spec? Well, Prime Information was a
competitive reverse-engineering product based on Microdata.
Whose fault is it that they didn't read R83 documentation to
create an accurate emulation? (Doing so might have gotten them
sued at the time.) What I want to know is, at what point did
Reality deviate from the Microdata=Pick spec? (See my Excel doc,
Reality doesn't agree with D3 or QM.)

I actually don't care if QM supports documented D3 behaviours or
not - this one or any of them. If you look at the spreadsheet
you'll see other platforms have similar issues. But this is a
competitive market. Failure of any platform to agree to baseline
standards simply costs end-users and developers money.

So, in support of QM and Ladybridge, I hope that Martin creates a
flag that allows QM to interpret MR and other processor codes
just like D3. This can reduce migration costs, thus providing
more incentive for migrations of Pick-like platforms to QM.

If there is no flag, I'm afraid this is just one of those hidden
costs associated with migration that people may discover
(apparently on all MV platforms) after they've already paid their
money. C'est la vie. In support of anyone contemplating
migration, I just hope issues like this are better documented so
that people can find problems and decide what they want to do
before they spend their money.

In the back of my mind, my beef with this whole thing is that
this discussion is at a level far lower than we should ever go.
We shouldn't need to be discussing the nuances of data masking
anymore. We should be discussing how to remain competitive in a
market dominated by other models. Does the phrase "adjusting the
deck chairs on the Titanic" mean anything to anyone here?

T

[Glen B]

Tony G wrote:
> From: Glen Batchelor
>
>> I agree that for migration sake the functions should
>> behave as expected, but there is a fine line between
>> supporting improperly written code and supporting
>> documented behavior. There are more proper ways to
>> strip characters, extract character groups and verify
>> data types. All of the examples you stated should be
>> done with functions other than output masking.
>>
>
> We're not talking about style here (or shouldn't be anyway). The
> real issue is not that Eugene was using MR as a redundant check
> for a numeric. I think we can all agree that the specific
> example was over-coded. The point is that his example revealed a
> fundamental compatibility problem in MR itself, one that can
> affect some very well written code.
>
>

I said, for the sake of migration, it should work the same. I'm not
arguing that. However, there are things in D3 that may work "broken" and
people have become accustomed to doing things the wrong way and not know
it. Feature or bug, we've both seen them along the upgrade path from
AP/Pro to 7.5/Linux. Using MR to strip characters, for purposes other
than output display, is a perfect example of using a screw driver to
drive in nails. I've seen it in data update code myself and even learned
the hard way that many things other people do are not the ideal way.
We're on the same page for some of this, but we obviously disagree on
coding convention.being a major factor in what breaks and what doesn't.

> A problem according to whose spec? Well, Prime Information was a
> competitive reverse-engineering product based on Microdata.
> Whose fault is it that they didn't read R83 documentation to
> create an accurate emulation? (Doing so might have gotten them
> sued at the time.) What I want to know is, at what point did
> Reality deviate from the Microdata=Pick spec? (See my Excel doc,
> Reality doesn't agree with D3 or QM.)
>
> I actually don't care if QM supports documented D3 behaviours or
> not - this one or any of them. If you look at the spreadsheet
> you'll see other platforms have similar issues. But this is a
> competitive market. Failure of any platform to agree to baseline
> standards simply costs end-users and developers money.
>
>

And as more and more platforms support the idiosyncrasies that divide
them, where do we all end up? A flavor of MV that doesn't know what
flavor it is until you tell it? We both agree that making it easy to
move the code is better for the developer and customer, right now. How
many developers are going to migrate 30K+ lines of code and then go back
and rewrite the "bad" bits the QM-way? I'm not sure if being a "swiss
army knife" is a great thing or not. It helps sales or I doubt that
Ladybridge would be playing along with this discussion. Are those
migrations really going to take advantage of things like QMOO which can
help change the way applications are thought about, files are designed,
and code is written? It might be better to have an application that can
scan code from a specific flavor of MV and point out known compatibility
problems and recommend alternate code structures for specific lines of
code. If a porting app can change the code for the bulk of those known
problems, then where is harm in making the code more QMBASIC instead of
PickBASIC? I know there is no such thing, but maybe the focus should
really be on the code conversion and not the compiler modes?

> So, in support of QM and Ladybridge, I hope that Martin creates a
> flag that allows QM to interpret MR and other processor codes
> just like D3. This can reduce migration costs, thus providing
> more incentive for migrations of Pick-like platforms to QM.
>
> If there is no flag, I'm afraid this is just one of those hidden
> costs associated with migration that people may discover
> (apparently on all MV platforms) after they've already paid their
> money. C'est la vie. In support of anyone contemplating
> migration, I just hope issues like this are better documented so
> that people can find problems and decide what they want to do
> before they spend their money.
>
>

A code migration scanner would be a nice free download (without the
registration and such!). I would agree that, for the sake of developer
sanity, the conversion masks should operate similarly for various
flavors. I imagine that will be a bit of code work.

> In the back of my mind, my beef with this whole thing is that
> this discussion is at a level far lower than we should ever go.
> We shouldn't need to be discussing the nuances of data masking
> anymore. We should be discussing how to remain competitive in a
> market dominated by other models. Does the phrase "adjusting the
> deck chairs on the Titanic" mean anything to anyone here?
>
> T
>
>
>

Speaking of other models, I'm pondering a QMOO article for Spectrum.
The Apache+FC article for this month's issue is a bit of a stretch for
MV, but I wanted to get the idea of the solution out there. I though
about following up with something more MV-oriented. Should this be
something that has Ladybridge as the author or would it have more impact
if a real-world example was documented in print by a developer with code
demonstration. The open-source dictionary-oriented data access class,
for example, that Gary is expanding and debugging for his ISAM
conversion is a great demonstration of QMOO. Most developers should be
able to grasp the concepts of the methods deployed. I could throw some
classes together and make a solution for the article if there are other
suggestions.

GlenB

[Martin Phillips]

Hi all,

I must agree with the sentiments of those who have posted comments
that our implementation of MR seems more logical than that of D3.
Equally, I accept that migration is easier if we support the semantics
of D3, however wrong we may consider them to be. Ultimately, we need
to reach a compromise between being a clone and providing a cleaner
model.

I would be fascinated to hear (briefly!) what Tony makes of the way
Microsoft keep changing VB. I was astounded recently by the effort
needed to take a tiny VB5 program forwards to VB .Net. Just about
everything has changed right down to the sizes of Integer, Long, etc.
This makes the differences in MR between D3 and QM look trivial.

My thoughts on how to handle MR go two ways. One possibility is to add
yet another option. The danger with this is that we clutter the system
with so many options that it becomes almost impossible to work out
what you need to set and, of course, every time you set one you need
to scan the entire application looking for impacts. And, remember, we
have stated that we will never be a clone.

The other possibility is to leave everything as it is and put the
effort into developing a code scanner that will look for constructs
that must be changed. This is not easy to do thoroughly but it should
be possible to catch the majority of things even if they are just
"please take a look a this" type warnings.

QM is taking multivalue forwards into new areas such as OO
programming. Along the way, we need to drop some of the stranger
nuances of some functions. So long as it is clearly documented and
doesn't require major rewrites to applications, this should be ok.
Tony, no doubt, will disagree.

Re the OO article for Spectrum, Nathan's vendor article rules make it
easier for this to come from a user rather than from us. We would
gladly help with authoring the article.


Martin Phillips, Ladybridge Systems.

[Simon Verona]

with regards to the migration of vb5 to vb.net (presumably framework
3.5?), that's a massive jump... I think probably more that 12 years or
so of technology... Given that Microsoft develop VB onwards and upwards
far faster than Pick/D3 ever has, this is probably the equivalent of
about 20 years of Pick/D3 development. Plus of course, vb.net isn't
really the same language as vb - it shares some syntax, and Microsoft
fooled people by providing an upgrade wizard to update existing code
(using a compatibility library).

To be honest, any useful VB code really ought to be re-written to
migrate it to vb.net... If not, then it could be argued that it's
probably better just leaving it as old vb code!

Though, having said all that, It *is* hard these days to keep up with
all the changes that Microsoft make to both the syntax of vb.net and
also to the framework... At the moment, I'm still developing on
Framework 1.1 - mainly because I can't face the migration! I know I'll
have to bite the bullet one day (probably soon as well).

This isn't quite the same argument though... You aren't Microsoft
migrating existing users forward, you are a competitor trying to steal
users... You need to make this as easy as possible! Microsoft can force
the issue to a degree by teasing people with new features or requiring
them to move forward at the platform moves forward... QM doesn't have
the inertia that Microsoft have to have people "desire" to make the move
forwards!

Another 2p's worth in the pot!

Simon

[Kevin Powick]

On Jul 21, 3:39 am, Martin Phillips <MartinPhill...@ladybridge.com>
wrote:

> I would be fascinated to hear (briefly!) what Tony makes of the way
> Microsoft keep changing VB. I was astounded recently by the effort
> needed to take a tiny VB5 program forwards to VB .Net. Just about
> everything has changed right down to the sizes of Integer, Long, etc.
> This makes the differences in MR between D3 and QM look trivial.

I guess only Tony can answer about what he thinks of the MS decision
(s) in this area, but I think it's fair to say that they are just
plain big enough to say, "Like it or leave it". No doubt that some
left, but I believe MS is doing better than ever in their developer
tools division. It also helps when you own over 90 percent of the OS
deployments out there.

> My thoughts on how to handle MR go two ways. One possibility is to add
> yet another option. The danger with this is that we clutter the system
> with so many options that it becomes almost impossible to work out
> what you need to set

I work with a system that has over 450 options that you can set to
determine behaviour. The biggest problem we see is when someone comes
to us with a question like, "Why did this happen?". You not only have
to consider what the user did, but which one of the myriad of options
might be in effect.

This is the potential problem I see with too many compatibility
switches in QM. Debugging can become difficult if one is not aware of
the switches or how they are set. Even worse, if they get changed.

--
Kevin Powick

[Tony G]

> From: Martin Phillips

> I must agree with the sentiments of those who have
> posted comments that our implementation of MR seems
> more logical than that of D3.

LOL... reminds me of a line from Bill Maher recently: "I agree
with what I said on the Chris Matthews show the other day..."

> I would be fascinated to hear (briefly!) what Tony
> makes of the way Microsoft keep changing VB. I was
> astounded recently by the effort needed to take a tiny
> VB5 program forwards to VB .Net. Just about everything
> has changed right down to the sizes of Integer, Long,
> etc. This makes the differences in MR between D3 and
> QM look trivial.

I'll just echo Simon's comments: VB.NET is a completely different
technology from VB. However, for anyone considering MV
migration, QM is exactly the same as D3 or other platforms. In
Microsoft's case, they have already sold people on the platform
and ongoing evolution - unfortunately, yes, that evolution is
often radical. In your case you're trying to get people to
change platforms, and in order to do this you need to first
facilitate migrations, then you can get them to use your
value-add nuances.

> QM is taking multivalue forwards into new areas such
> as OO programming. Along the way, we need to drop some
> of the stranger nuances of some functions. So long as
> it is clearly documented and doesn't require major
> rewrites to applications, this should be ok. Tony, no
> doubt, will disagree.

IMO, the migration process is simply the wrong venue to wage a
war of wits through forced code re-writes. Get your new clients
migrated and then help them to improve their code. To keep it
fair and easy for everyone I'd be happy if there were just good
documentation (no code parser required) to help people to find
code that will cause their application to behave in a
fundamentally different manner. Now that I think about it, this
thread all by itself should serve nicely as long as newcomers are
referred to it.

T

[Ashley Chapman]

<snip, snip...

IMO, the migration process is simply the wrong venue to wage a
war of wits through forced code re-writes.  Get your new clients
migrated and then help them to improve their code.  To keep it
fair and easy for everyone I'd be happy if there were just good
documentation (no code parser required) to help people to find
code that will cause their application to behave in a
fundamentally different manner.  Now that I think about it, this
thread all by itself should serve nicely as long as newcomers are
referred to it.

Yep.  It'll get lost in the mists of time in this google group.  Unless you can think of some sort of permanent place for it.  Perhaps some sort of collaborative web site where this sort of thing can gradually build.  Something that each migrator can add their own experiences, perhaps?


I'm sure you can think of something that will fit the bill ;-)


 

T

--
Ashley Chapman

[Tony G]

> From: Simon Verona

>
> Though, having said all that, It *is* hard these days
> to keep up with all the changes that Microsoft make to
> both the syntax of vb.net and also to the framework...
> At the moment, I'm still developing on Framework 1.1
> - mainly because I can't face the migration! I know
> I'll have to bite the bullet one day (probably soon as
> well).

Side note which I'll share with our colleagues: You're not alone,
Simon. I'm still working with .NET 2.0 and I was a late adopter
from 1.1. IMO, the biggest benefit is generics, and I can't code
without them now. I've worked on books for .NET 3 and 3.5
(nospamNebula-RnD.com/articles/index.htm) but I still haven't
made the jump to use the latest release for my own development.
It's getting tougher every day to not use the latest tools.
Maybe after I do jump I'll say something like "I dunno how I
could ever code without LINQ or Lambdas or anonymous methods",
but right now I see some of that as being just "change", not
"improvement". And now we have C#4, MVC, Mesh, Azure, and other
stuff in play - I might just skip a generation, jump to VS2010,
and get on the bleeding edge. Yes, it's sometimes tough to keep
up with Microsoft, but at least they're evolving. I think
Microsoft moves too fast for my Pick-nik preferences, but the MV
market moves way too slow. YMMV

Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com

Nebula R&D sells mv.NET worldwide

[Simon Verona]

I think it's known as a "wiki" :)

Simon

---------------------------------
Simon Verona
Director
Dealer Management Services Ltd

Sent from my iPhone

[Steve Bush]

I think it is generally accepted now that the way to reconcile the need for
both official documentation AND user contribution documentation is to have a
comments submission page on the bottom of every documentation page and the
comments to show there too. Widely different groups such as Microsoft, php
and postgres use this trick but with different kinks in the implementation
largely related to how old messages are keep/discarded. I suspect it would
put this long running gripe to bed once and for all and get everybody
pulling in the same direction.
B Regards, Steve Bush

[Jeff Green]

I have been following this and have read some good arguments on all sides of
the issue. I have not done a QM conversion, but have done others, the
largest being McD to D3.

I think Kevin's quote put in my mind what seems the best in my mind. Rather
than have all these switches, fully documenting the "nuances" of differences
would go a long way. Rather than make a switch, fully document the needed
application code change. All of these switches just seem like a disaster
looming. If a new QM coder came in to an unknown system, how much time (and
potential errors) would be induced by having to check and verify what each
switch does. If the new coder came from a McD world, but the switches were
D3, would he even fully understand the usage? Or a D3 guy looking at
Universe switches. I think you get my point.

I believe having "standard" QM code would be the easiest in the long run,
and the added time in the conversion would outweigh the potential future
problems.

Just my 2 cents.

Jeff

[Tony G]

What a concept. If something like that did exist, everyone would
be able to contribute to it. Perhaps it could be located at a
URL something like this:
http://www.pickwiki.com/cgi-bin/wiki.pl?MigrateD3toQM
And that might link to a MigratePickToPick index page.
Hey, if there were a whole wiki site, we could even link to that
from a home page so that people could easily find migration info.

.......Nah......

T

> From: Simon Verona
> I think it's known as a "wiki" :)

[eppick77]

Jeff,

I can understand your position on this. However, if I had to work the
the total default system of QM which would be VERY Information
oriented, I would never had looked at QM. I like what Martin has done
with QM and it is honestly my favorite version.

Eugene

[Jeff Green]

Eugene,

Good point. I might not have tried QM either if not for high D3
compatibility.

Your response makes me re-evaluate my prior thoughts. This thread has
obviously moved from ICONV to how to handle flavor differences found in the
future.

QM makes a lot of sense with a switch that changes the system to closely
emulate another. When thinking about Kevin's point of numerous switches, one
has to wonder where it will stop, or IF it should stop. I just wonder about
his debugging question along with my other programmer scenario and Martin's
need to check each switch on each core change.

Another concern would be a person using a combination of switches from
multiple flavors... ICONV works like D3, but LOCATE works like Universe, but
INSERT works line McD.

Just more to think about going forward.

Jeff

> -----Original Message-----
> From: Ope...@googlegroups.com [mailto:Ope...@googlegroups.com] On
> Behalf Of eppick77
> Sent: Tuesday, July 21, 2009 9:50 PM
> To: OpenQM
> Subject: Re: ICONV difference from D3
>
>

[JeffC]

Martin,

As one who has been on the fence for longer than I would like to admit
I vote in favor of a code scanner.

What has kept me on the fence? Simply the time it would take to
convert the applications and the unknown.

The scanner would reduce both issues by exposing the scope of the
proejct.

Please consider this.
Jeff

> The other possibility is to leave everything as it is and put the
> effort into developing a code scanner that will  look for constructs
> that must be changed. This is not easy to do thoroughly but it should
> be possible to catch the majority of things even if they are just
> "please take a look a this" type warnings.

> > Martin Phillips, Ladybridge Systems.

[Kevin Powick]

On Jul 21, 12:53 pm, "Tony G" <wosclx...@sneakemail.com> wrote:

> Get your new clients
> migrated and then help them to improve their code.

Except that after migration, this will never happen. Extremely rare
is the company that will pay to have code that already works re-
written -- Especially if you're just making changes so that you can
later flip a switch or two back to a QM default.

I think Jeff G. made a good point about where does adding
compatibility switches end?

--
Kevin Powick

[Martin Phillips]

Hi all,

Time to rethink my arguments....

Eugene has discovered that QM actually already behaves like D3 with
regard to MR and non-numeric data. This came as a big surprise to
everyone, not least me! I suspect that it was purely by accident (aka
poor coding).

So, how to we satisfy both the need for D3 compatibility (which we
seem to have) and the ability to use ICONV() to validate the data too?
I think that the answer is to leave the conversion working exactly as
now and add code to return a non-zero STATUS() if the conversion
stopped at a non-numeric character.


Martin Phillips, Ladybridge Systems.

[Dave Taylor]

I agree with Kevin and Jeff, with the following thoughts:

There are different type of database incompatibilites - those that require
some degree of rewrite of the source software just to function on the new
database, and those that require a rewrite of source software to function
the same way on the new database as it does on the old database.

Changes in the source code just to function at all can be resolved at a much
lower cost to the end-user by asking Martin to add an option. This shifts
the expense of compatibility from the end-user to Martin, and makes sense to
Martin if the cost to him is minor, but does not make sense to him if it
requires an entire rewrite of QM.

And Martin is extremely cooperative in finding ways to add these options.

Reducing the cost to the end-user makes it easier for the consultant to sell
the conversion to the end-user and to thereby render a greater value-add to
the end-user, which also adds value to QM and to Ladybridge Systems.

Additions or changes to the source code to provide comparable functionality
to the source database (eg a generic Pick print spooler rather than the QM
print spooler) has to be evaluated based on the cost of the
additions/changes and the cost of the alternative.

And the cost of not providing comparable functionality is often expressed in
less tangible forms, like broad changes in business process and operating
procedures, additions/changes to hardware and network architecture,
retraining of personnel, rejection or acceptance of the new database and
general employee morale.

These indirect costs have little or no impact on the consultant but often
take a substantial toll on the business and its employees.

As technical consultants, we sometimes forget that our recommendations also
have business implications and that we are also business consultants to the
extent that those business implications have a positive or negative impact
on our customer.

just my .02,

Dave

Dave Taylor
Sysmark Information Systems, Inc.
Authorized IBM Business Partner
49 Aspen Way
Rolling Hills Estates, CA 90274
(O) 800-SYSMARK (800-797-6275)
(F) 310-377-3550
(C) 310-561-5200
www.sysmarkinfo.com

----- Original Message -----
From: "Kevin Powick" <kpo...@gmail.com>
To: "OpenQM" <Ope...@googlegroups.com>
Sent: Wednesday, July 22, 2009 10:05 AM
Subject: Re: ICONV difference from D3

[Tony G]

Since votes are being cast, personally I'd much rather see some
unique enhancements that I know Martin is working on, rather than
asking him to write code that scans for problems.

However, one not-so-painful way to do this just occurred to me:
Modify the compiler so that when a specific flag is used and
specific tokens are generated, a log is written if the code
relates to known trouble spots. Parsing source code is a real
pain but the compiler already does it. This should also be added
to the runtime, again, where a log is written only if the code is
run with a specific mode/option active.

Why do it like that? Consider this:
MASK="MR"
IVAL = ICONV(OVAL,MASK)
Code that scans the source wouldn't be able to catch that, and
neither could the compiler (without warning you that every ICONV
in the system could be a trouble spot), but the runtime should be
able to catch the problem (depends on how BASIC passes info to
the conversion processor). So anyone migrating needs to port
their code, run through all possible code paths, then check the
log.

This would be a great initiative for the FOSS project... Oh
well...

T

[eppick77]

Martin,

I agree that would be a good idea. I can add additional logic to my
program generator to add another statement to check the status.

Eugene


On Jul 22, 1:40 pm, Martin Phillips <MartinPhill...@ladybridge.com>
wrote: