IBM i Global

I'm sorry to hear that....we once had a bug that was deep down in SLIC related to some temp storage issues we were having; it took roughly 3 years for IBM to resolve. Sometimes, depending on where the issue is and how often / impactful they think the issue is to customers will often dictate the speed in which they can or will resolve an issue. And sometimes, depending on where the problem is, you don't want them to 'rush' thru it......Having said that...during our 3 years for this problem, we met monthly with IBM Managment and Lead Developer responsible for this area of the code to talk about priorities, impact and overall status. I think regular communication and expectation setting is vital with problems like this.  No, this doesn't help get the problem fixed sooner, you're doing all you can per se, but..try asking for ongoing monthly meetings with the dev person/team involved etc. 

Based on my past experience with IBM i since its time of OS/400, some issues can be addressed equally effectively with alternative solution that is not from IBM producing SW fix.  Are you certain that in your case the solution must only be from IBM SW fix?  If you provide sufficient details of your issue, someone may be able to suggest alternative(s) to address the issue without having to wait for IBM's response. 

If you would like to discuss this issue further, you can reach out to me privately with the case number.

Tracy Schramm

Manager, IBM i Global Support Center

Database / Data Access and Language and Utilities Teams

> 376 days...

Don't feel alone ; P mine for ICU (somewhat in the same area of languages and scripts) is 300 day old; but I have received an answer yesterday that apparently they are trying to fix at least the CVEs, so at least some action! (despite I think that the technical debt regarding unicode processing is accumulating badly at this point)... 

Hello, We will continue communication via case updates to TS015414926.

Thank you,

Tracy Schramm

Hello,

IBM has provided their final response, so I'm sharing it.
As some of you may have guessed, the conclusion is “it's by design.”

Reaching this conclusion required 1.8 years (641 days) and significant time and effort, including providing a reproducible environment, coordinating with development, numerous escalations, testing PTFs, and investigating the situation. It's regrettable that the “design” no longer meet IBM i's previous quality standards, but given my age, I simply don't have the time to submit improvement requests to “ideas” to push for changes.

I cannot reprint the specific details of PMR, but for those who are anxious, I will describe the circumstances of its occurrence. 

• Occurs only in DBCS (Japanese) environments.
• Several issues were present, but all but one have been resolved by PTF. (One issue, but the most significant one.)

Until now, even minor bugs—let alone critical failures—were resolved within about six months, so this time really wore me out. I wish everyone in this forum a peaceful IBM i  life.

IBM has provided their final response, so I'm sharing it. 

Thanks for sharing. It's indeed unfortunate that it took so long to reach the conclusion and of your (customer) time, leaving also a bad taste I image with the whole process.

It depends on the issue of course, resources, and their possibility to update and maneuver and how deep the issue is.

It took a lot of time also for a particular case of mine regarding ICU to reach basically no conclusion (in this case "by design" answer wasn't realistically available).

But talking about my experience for other cases, like a critical RPG compiler bug that I found, and a OS bug that crashed the whole machine in production, I must say that they (IBM) provided a fix quickly, in say a week.

At the moment I think the biggest urgency in IBMi world is to update the ILE C/C++ compilers (or provide a ILE backend or similar to existing compilers) to recent language revisions and support, not doing that increase technical debt dramatically and existing code accessibility (ICU being a part of this) and in any case just lead to resource and time waste in other areas (such cost externalities are great) and an impediment to sustainability.

Thank you for your reply.

> But talking about my experience for other cases, like a critical RPG compiler bug that I found, and a OS bug that crashed the whole machine in production, I must say that they (IBM) provided a fix quickly, in say a week.

Yes, in my experience this is a rare case; most issues are resolved within a month.

> At the moment I think the biggest urgency in IBMi world is to update the ILE C/C++ compilers ...

I too am concerned that the core components of IBM i have not been updated for many years. Interoperability between IBM i native environments and PASE environments is cumbersome, but at worst, if the latest C/C++ is required, you may have no choice but to use gcc.

For example, native FTP still cannot use characters other than Latin characters tough most FTP servers running on UNIX, Windows, and other platforms support RFC 2640 (Internationalization of the File Transfer Protocol), published in 1999, and can utilize UTF-8. Even now, sftp can correctly display files containing non-Latin characters as below.

(IBM i Native FTP)

  331 ENTER PASSWORD.
  230 PGMR40 LOGGED ON.
   OS/400 IS THE REMOTE OPERATING SYSTEM. THE TCP/IP VERSION IS "V7R5M0".
  250  NOW USING NAMING FORMAT "0".
  257 "QGPL" IS CURRENT LIBRARY.
> ls /tmp/PCDOC/*.pdf
  229 ENTERING EXTENDED PASSIVE MODE (|||26967|).
  125 LIST STARTED.
  /tmp/PCDOC/POB03011USEN.pdf
  /tmp/PCDOC/impact of SQL on iSeries 08-01-04.pdf
  /tmp/PCDOC/Indexing and statistics strategies for DB2 UDB for iSeries.pdf
  /tmp/PCDOC/Using AS400 Database Monitor and Visual Explain.pdf
  /tmp/PCDOC/Using AS400 Database Monitor To Identify and Tune SQL Queries.pdf
  /tmp/PCDOC/      j K       N       u ]   e   }  Query   5      - rzajqmst.pdf
  /tmp/PCDOC/    P09    SQL  U   *   n k     p ] B     p .pdf
  /tmp/PCDOC/Chart Version of Indexing Strategies(HintsForSQL).pdf
  /tmp/PCDOC/DB2 UDB for iSeries     u V   N       u ]   -<  h n k     p ] B  (2004  - 4  / 20    ).pdf
  /tmp/PCDOC/    g   {    (DBCS     v ).pdf
  250 LIST COMPLETED.

(PASE sftp)

Porting open-source software is a great thing, but I believe IBM should focus more on modernizing its native features.

> I too am concerned that the core components of IBM i have not been updated for many years. Interoperability between IBM i native environments and PASE environments is cumbersome, but at worst, if the latest C/C++ is required

having PASE and an AIX-like kernel is very useful and flexible; still, having tight ILE integration and TIMI is one of the fundamental reasons and properties that differentiate the ibmi from other systems, forgoing that and not investing in improving that is problematic and risky to say the least, it is the fuondation.

I think I still have (and surely use) your SAVF compilation of ZLIB lib in service program, downloaded from your tool site (if that is you, unfortunately the tool site seems now not up anymore).

I don't know if the current and latest ZLIB on the public site is today still compilabile or needs some patch work...

> I think I still have (and surely use) your SAVF compilation of ZLIB lib in service program, downloaded from your tool site (if that is you, unfortunately the tool site seems now not up anymore).

> I don't know if the current and latest ZLIB on the public site is today still compilabile or needs some patch work...

The zlib version published on my site is 1.2.3, so for security reasons, it would be preferable to port the latest zlib (1.3.1). IBM i's ILE-C/C++ and POSIX are implemented in compliance with industry standards, ensuring high compatibility. Consequently, the portability of straightforwardly written programs is exceptionally high. For reference, the number of modifications for each tool I ported was approximately as shown in the table below. 

Since we've strayed from the original post's topic, I'll wrap things up here.

Thanks for the updated link, useful, and sorry for the slight off topic.

Regarding IFS, yes, many tools don't even use  Qlg_Path_Name_T  to represent the path.

I've personally seen even some third party "modernization" web view components on ibmi having difficulties with different ccsid handling IFS files and even sometimes assuming in their software 1 byte = 1 character identity... I don't even want to imagine native terminal tools like FTP (but your first screenshot is from 5250 I think, the other from a windows client interfacing via sftp).

Native ACS IFS java tool can browse and treat those files name ok.

In any case the native FTP was always somewhat clunky to be automated.

For such programmatic file exchanges with external parties over standard internet protocols, I've resorted to call from ILE into PASE (passing parameters via environment variables) and then leveraging CLI php or python, to have better error handling and db integrated logging.

My personal opinion on this is that IBM is wasting a lot of resources on for example creating an SQL function for almost everything... while these are functionalities that can be developed by every decent programmer as in 99% of the cases the API's exists for doing so.  I won't say that these SQL functions are useless or not nice to have, but leave that to open source and/or commercial projects.

On the other hand we lack features and functionalities for which no API's exist, no tools exist, ... to be short for which there's no plan B and that is unacceptable.

My personal opinion..

Kind of agree with your assessment. Yes having sql service wrappers to functionality is nice to have, having some lipstick over APIs to ease querying, flexibility and servicing is good , but yes are a sort of low hanging fruit at this moment... there are much important things to chase, like to get the C  ILE compilers up to modern standards, and update critical components like the ICU issue quoted above that basically handle foundational aspects like unicode...

I don't agree with the resentment of the SQL services. The platform has to evolve - and to survive it has to embrace new and younger developers. 

So if we say, "we have APIs that we always used since ..." - it's not the signal, that we want to send out to young developers. 

And above that, I think it's a real unique feature of IBM i, that the RDBMS is fully integrated into the operating system - and with IBM i SQL services, the operating system gets integrated into the RDBMS. I don't know of any other platform, that has similar features.

For the original question - I submitted 6 tickets in the last 18 months - there were

• an RPG compiler error
• an error of the SQL/RPG precompiler
• two errors in the RDBMS 
• ...

And all those tickets were resolved in times ranging from 2 weeks to 4 week, until we had a test-PTF available.

Of course, your mileage may vary, because it depends on how complicated the problem is to replicate, and how many customers are affected.

Just my 2cts

Daniel