IBM i Global

 View Only
  • 1.  Adios SDA, DFU, RLU, etc

    IBM Champion
    Posted Fri May 31, 2024 10:19 AM
    Discontinuance of Support
    Effective on 30 April 2025, IBM will discontinue support for selected IBM i functions
    Among these are:
    Report Layout Utility (RLU)
    Screen Design Aid (SDA)
    File Compare and Merge Utility (FCMU)
    Advanced Printer Function (APF)
    Character Generator Utility (CGU)
    Data File Utility (DFU)
     
    https://www.ibm.com/docs/en/announcements/end-marketing-end-support-i-merlin-10-rdi-96-selected-i-functions?region=US


    ------------------------------
    Robert Berendt IBMChampion
    ------------------------------


  • 2.  RE: Adios SDA, DFU, RLU, etc

    Posted Tue June 04, 2024 04:35 AM

    Thanks for the info.

    Pardon my ignorance, never heard of "Business Graphics Utility". I realize there were so many things wasted in the years trying to circumvent the lack of a proper modern thin client graphical protocol foundation to build upon (....Graphical Data Display Manager , abandoned DDS graphical codes., visual rpg stuffs..) that at the end would have costed much less despite being a lot more organized to evolve and maintain.

    Regarding RLU or SDA I see them still pretty used by folks in the fields. Fast to use, already in the machine, no fat client vs host PTF level disalignment issues or multi gb reinstallations or licencing to waste time on. *nix folks still evolve nano and vi , just to say.

    Regarding the indicated replacement product RDi 9.8 last fix is of January I'm still waiting mid year at this point for critical bugs in 9.8 (iAsp support) to be fixed and "cosmetic" syntax check assist support for the new RPG functions (this part is always not aligned... when a TR comes out, a new version of RDi supporting new RPG syntax should be already available for download BEFORE the PTF availability .... please coordinate the teams! ).



    ------------------------------
    --ft
    ------------------------------



  • 3.  RE: Adios SDA, DFU, RLU, etc

    IBM Champion
    Posted 30 days ago

    Regarding RLU or SDA I see them still pretty used by folks in the fields. Fast to use, already in the machine, no fat client vs host PTF level disalignment issues or multi gb reinstallations or licencing to waste time on. *nix folks still evolve nano and vi , just to say.

    I would like to add CGU. Because of the heavy use of UDC (user-defined characters, aka "gaiji") in Japan, CGU has been widely used since the S/38 era, and when CGU is eliminated, UDC can no longer be added.

    The EBCDIC DBCS character set on the IBM i is almost stuck at the Windows Vista (or Windows 3.1) level, resulting in a lack of characters for names of people, organizations, places, etc. Since Unicode is virtually unusable in current 5250 applications, there is a certain amount of users who are forced to either rewrite all applications or migrate to platforms where Unicode is available. 



    ------------------------------
    矢作 英幸
    ------------------------------



  • 4.  RE: Adios SDA, DFU, RLU, etc

    Posted 29 days ago

    Yes, unicode should be a first class citizen in user interfaces and databases (at least usable), but for example an ILE environment doesn't even have a proper updated ICU library to work on basic string tasks over UTF strings, like common things language transliteration, essential in b2b systems catering to a multitude of people (even the european union has countries that use scripts different than common latin, without going to far east!).

    See: https://community.ibm.com/community/user/power/discussion/icu-qicu-library-on-the-system-is-too-obsolete-despite-being-a-public-user-facing-api?ReturnUrl=%2fcommunity%2fuser%2fpower%2fcommunities%2fcommunity-home%2fdigestviewer%3fcommunitykey%3df0246bc4-08f3-43c5-a7f8-b6a64d387894

    Astonishingly we get more support on free systems regarding unicode processing.



    ------------------------------
    --ft
    ------------------------------



  • 5.  RE: Adios SDA, DFU, RLU, etc

    IBM Champion
    Posted 29 days ago

    "Since Unicode is virtually unusable in current 5250 applications, there is a certain amount of users who are forced to either rewrite all applications or migrate to platforms where Unicode is available. "

    I really don't understand this perspective.  

    If they move to another platform they _have_ to rewrite.

    However, if they modernize their existing IBM i apps, not only is it easier to do in stages, but there is the potential for significant code reuse.

    Modernizing what you have is always (or as close to 100% as possible) the cheaper more successful option.



    ------------------------------
    Jon Paris
    ------------------------------



  • 6.  RE: Adios SDA, DFU, RLU, etc

    Posted 28 days ago
    Edited by ace ace 28 days ago

    Recent RPG language runtime refreshes are indeed equipped to handle variable text encoding tasks, see *NATURAL count and even more idiomatically IMHO than others platforms/languages. RPG allows even easy CCSID conversion of strings between CCSID with a simple variable assignment.

    IBMi has even (I think unique?) concept like CCSID attribute of a text IFS stream file, so the decoding can be deterministic and precise even with multiple CCSID, compared to the inferred encoding schemes sometimes present in other platforms.

    Personally in the DB layer when needed to store unicode I've standardized to UTF16 (CCSID 1200) with *normalize. It allows for 2 byte per char for most business uses covering the whole linguistic case and allows for the odd 4byte encoded char. Most languages (in other systems) use this for internal string encoding too, seems a good store/speed compromise.

    Regarding the 5250 view layer, 5250 does support the setting for an unicode stream, you need DDS display with G graphics fields and a decent fonts... somewhat doable and personally I've done it rarely and if I recall correctly sometimes there were issue with ligatures etc. But is was doable despite I imagine not a common and well supported path.

    Using a dedicated web browser frontend is always fine to due extensive support for multi script in a browser (even a virtual terminal program that emulates the terminal 5250 using the browser via apache and renders DDS G fields can be a fast approach to get/display data in).

    The thing lacking is surprisingly an updated QICU library for specific unicode tasks, though, as per my rant ; | that is quite essential for many tasks (even non unicode related, like removing diacritics/accents before and EDI info serialization, transliteration...).



    ------------------------------
    --ft
    ------------------------------



  • 7.  RE: Adios SDA, DFU, RLU, etc

    IBM Champion
    Posted 28 days ago
    Edited by 矢作 英幸 28 days ago

    > Modernizing what you have is always (or as close to 100% as possible) the cheaper more successful option.

    If it is a "modernization" from EBCDIC to EBCDIC, I agree. I have no experience with "modernization" involving the transition from EBCDIC to UNICODE, and I am aware that a considerable amount of code review is required, as shown in the link below.

    - Enable RPG programs to Handle International Data

    Please understand that Japanese users are forced to use CGU (Gaiji) in order to manage to use similar characters found in Unicode IVS in EBCDIC environment. Any examples of successful modernization of current program assets from Japanese EBCDIC to Unicode would be greatly appreciated.

    > ace ace said : ...5250 does support the setting for an unicode stream...

    As mentioned in a previous post, Unicode support for 5250 screen sessions provided by ACS is limited. (Printing device sessions do not support Unicode).

    - Support only for CCSID 13488 (UCS2), which was deprecated in the 2011 revision.

    - Fixed 2 bytes per character, so fields must be twice as long as before even if only SBCS characters are used.

    - DBCS only supports WorldType fonts corresponding to the code page used by the session. Therefore, whole Unicode characters are not available.


    ------------------------------
    Hideyuki Yahagi
    ------------------------------



  • 8.  RE: Adios SDA, DFU, RLU, etc

    Posted 28 days ago
    Edited by ace ace 28 days ago

    > Unicode support for 5250 screen sessions provided by ACS is limited

    For sure. Especially for decent "japanese script" support (i.e. full kanas, katakana, hiragana, kanji...), where full support is complex (i.e. multi glyphs per single codepoint, variations...) and is covered and solved decently only by a standard like Unicode where the development effort is concentrated.

    Yes, IBM shamefully didn't invested or properly improved the 5250 stream during the years and its system standard view technology DSPF/DDS , a unicode terminal supporting full CCSID 1200 should have been the first reasonably step years ago, and then a full thin protocol investment that would have provided the foundation for many improvements with less money lost than in those projects that tried to circumvent this model with the fat client (thin client model that ironically now is in fashion with the return of cloud systems = centralized with the webbrowser as the thin terminal).

    They apparently even refuse to update an important unicode related ILE library like QICU leaving the customers with an unsupported version on new machines.

    And yes, introduction of unicode in existing systems require, as always, careful consideration and planning. I did only incrementally in new modules when needed (ie. RPG code servicing webservices that then use ICU to transiterate/transform the strings to the subset required by - for example - a carrier/courier).



    ------------------------------
    --ft
    ------------------------------



  • 9.  RE: Adios SDA, DFU, RLU, etc

    Posted 30 days ago
    Edited by Peter Brem 30 days ago

    .