Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Character-Set This!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Character-Set This!

    ** This thread discusses the article: Character-Set This! **
    ** This thread discusses the Content article: Character-Set This! **
    0

  • #2
    Character-Set This!

    ** This thread discusses the article: Character-Set This! **
    As you mentioned these symbols don't mean the same thing outside the U.S. If you are writing code that will be seen in another country, this will add confusion. Even in England, the # symbol means "hash symbol" If you are trying to put logic in you name with #, it is lost outside the U.S. The $ symbol is not on foreign keyboards. In England the have the pound symbol instead.

    Comment


    • #3
      Character-Set This!

      ** This thread discusses the article: Character-Set This! **
      You go and write this: An invariant or never-changing character is a character that is the same in all character sets. Such characters were once called "code pages" and are now called coded character set ID (CCSID). For example, the letters A and a are invariant characters that are available on keyboards in North and South America, Europe, Africa, and many parts of Asia, regardless of the CCSID used on the machines in those regions. I thought that a CCSID/code page was for a complete set of available characters, but in the sentence above, a CCSID is evidently just a signle character - can this be right??????

      Comment


      • #4
        Character-Set This!

        ** This thread discusses the article: Character-Set This! **
        A codepage is used by the system to encode and interpret string characters. Codepage formats are not the same for each language. The word "set" as in "charaster set" was inadvertantly deleted from the sentenance. "Such characer sets were once called codepages" is how it should have read.

        Comment


        • #5
          Character-Set This!

          ** This thread discusses the article: Character-Set This! **
          Our shop uses these characters to denote "work" fields - fields that do not have a fixed definition in our field reference file. Our shop standards require program documentation to include definitions for work fields used in the modules. By using these characters exclusively for this purpose, we are able to programatically identify all work fields used in a module and check to see that there is a definition for each work field in the module documentation. All use is not related to compile listings.

          Comment


          • #6
            Character-Set This!

            ** This thread discusses the article: Character-Set This! **
            Our department does not have standards on how a programmer codes an individual line. However, I have setup some personal guidelines which are as follows: Mixed case for everything EXCEPT variables coming from outside the program. These include, but not exclusivly, data files, screens, printer files, and data areas. This way when I look at a line of code, I can tell what fields are defined inside the program and which ones are not. This standard seems to work out really good for my programming needs and I would hope that others would pick up on this style within our department, but only time will tell.

            Comment


            • #7
              Character-Set This!

              ** This thread discusses the article: Character-Set This! **
              The last shop I saw using the awkward @#$% signs was Saville Systems which eventually fell on its face by 1998. Part of the reason it used those @#$% signs was due to the RPGIII limitations. Now-a-days shops use the RPGIV's ability for long names and use WK_ prefixes for example.

              Comment


              • #8
                Character-Set This!

                ** This thread discusses the article: Character-Set This! **
                Well, I never in 16 years been tempted by using special characters in field names. Some co-workers did, but I always found this ugly as it chunked the already too short field naming capabilities of RPG/400. So this ended most of the time in senseless field names. Now with enhanced naming capabilities of RPG IV, I rather use influences from Java to name fields by adding a lower case 1 or 2 letters prefix to the field names. As examples: dsCustomerInfo (you sure guessed this "ds" meant a DS), aFoundNames ("a" for array), cTransCode ("c" for constants). This helps making a good reminder of the use of some special fields without going back to the "D" specs, specially when you are not familiar with a piece of code. And making the prefix all lower case doesn't mask the rest of the field name.

                Comment


                • #9
                  Character-Set This!

                  ** This thread discusses the article: Character-Set This! **
                  Our ERP software is rampant with these symbols. Amount fields always end with $ and quantity fields end with # (IHNTU$ and IDSHP#). Since I "learned" RPG by example, I too used this naming convention in my programs and files. The trouble is that if the last character of your field name ends with one of these (or other) symbols, Microsoft ODBC will fail to retrieve records from the file.

                  Comment


                  • #10
                    Character-Set This!

                    ** This thread discusses the article: Character-Set This! **
                    gwilburn1 wrote: Microsoft ODBC will fail to retrieve records from the file. This is not exactly an accurate statement. The ODBC driver for 5250 is provided by IBM if you are using iseries-access. It is not the driver that will not accept the characters, but rather the application. For instance I have no problem accessing files with an embedded dot, or field names with #, or $ if I am using the Crystal Reports application (version 9 or higher). But using the same ODBC driver, the access will fail if using MS Query, MS Access, or any other MS application. It is the application's use of the ODBC data that will fail, not the driver iself. Dave

                    Comment


                    • #11
                      Character-Set This!

                      ** This thread discusses the article: Character-Set This! **
                      I admit to not understanding the full nature and scope of Unicode support on the iSeries. However, I know that the iSeries supports Unicode. It seems to me that these little arguments about symbols are a relic of the past. Unicode is supposed to allow a symbol to be that symbol, a character to be that character, and an accent to be that accent. Use what you like when you code or write. Just make sure you use Unicode and your code and writing will stay intact regardless of the country, culture or geographic locale.

                      Comment


                      • #12
                        Character-Set This!

                        ** This thread discusses the article: Character-Set This! **
                        I started on the S/34, and there/when there were no restrictions from using them. I avoided using them because of how they look, and also because they slow down my typing. You have to make 2 keystrokes on part of the keyboard you don't use as much for every other character for 1 character of code. I don't even like _ for that reason. Subsequently I worked in a shop that had a code generator that used them for internal fields hoping it would not conflict with external fields. What a mess, but it worked. I became more acclimated to them. A problem with most commercial packages is that they are built with those issues. Where I work we are actively taking them out of all code.

                        Comment

                        Working...
                        X