Tips and Techniques: Using LIKEDS

[MCWebsite.Staff]

** This thread discusses the article: Tips and Techniques: Using LIKEDS **
** This thread discusses the Content article: Tips and Techniques: Using LIKEDS0

[Guest.Visitor]

** This thread discusses the article: Tips and Techniques: Using LIKEDS **
Please, never use @-Sign for field names in your sources! It's not international! We have always troubles getting sources from USA. We have to replace @ through § which is a valid sign for our sources in Germany. Birgitta

[Guest.Visitor]

** This thread discusses the article: Tips and Techniques: Using LIKEDS **
Must be tough to send an internet email without using the @ sign! chuck Opinions expressed are not necessarily those of my employer. wrote in message news:6ae7f517.0@WebX.WawyahGHajS... > Please, never use @-Sign for field names in your sources! It's not international! > > We have always troubles getting sources from USA. > We have to replace @ through § which is a valid sign for our sources in Germany. > > Birgitta

[Guest.Visitor]

** This thread discusses the article: Tips and Techniques: Using LIKEDS **
Why is @ not a valid source character in Germany? What other special characters are verboten? Thanks. Tom.

[buck.calabro@commsoft.net]

** This thread discusses the article: Tips and Techniques: Using LIKEDS **
> Why is @ not a valid source character in Germany? > What other special characters are verboten? The problem is that the US 037 EBCDIC code point (hex value) for commercial at '@' maps to a completely different character in the German EBCDIC code page. For ASCII like email, it's not a problem, since there's only one ASCII code page. The nationalisation manulas have more information on the special character issue, but generally speaking, you can rely on letters and numbers only. There are only a handful of non-alphabetic characters which map correctly to ALL other EBCDIC code pages. --buck

[R.Cozzi]

** This thread discusses the article: Tips and Techniques: Using LIKEDS **
You are correct, and I started the blue ribbon campaign against @ # $ in field names. I used the @ in this example for brevity. I would assume (hope) people would validate the code before assuming it compiles in all codepages. On the other hand, I could use p_NULL in the future for such things. Thanks for the reminder!

[J.Pluta]

** This thread discusses the article: Tips and Techniques: Using LIKEDS **
Well, alphabetic, numeric and punctuation characters generally translate, but the three baddies, at-sign, pound-sign and dollar-sign, were always a problem. Try finding the dollar-sign on an AZERTY keyboard. At SSA in 1992, we removed variant characters from ALL of BPCS. That included DDS, RPG and AS/SET code. The AS/SET repository was particularly troublesome. We ended up with some interesting results. For example, one program had DAYS, #DAYS, @DAYS and #@DAYS. We went with the concept of removing the variant characters and then appending characters to avoid duplicates. In this case, we'd get DAYS, DAYSX, DAYSY and DAYSZ. Not pretty, but it worked. Unfortunately, just removing the variants occasionally created politically incorrect field names, and so we had to add a second pass to take care of those . Joe

[Absolutely_Nobody]

** This thread discusses the article: Tips and Techniques: Using LIKEDS **
"The BASED keyword causes the compiler to avoid declaring any storage for the field or data structure that uses it." Does this mean that no memory is allocated for the fields in the data structure that the BASED keyword is used ? So, for example I use the code below to include all of the fields from the field reference file to be used universally in every program so that the fields can be used on the LIKE and the program will not take a memory hit ? Or, does memory get allocated for this DS and not for the subsequent DS that gets created BASED on this one ?

---

Code