× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Even if it is good in the end, I think it was poorly implemented.

The prior tool allowed you to save without the BOM.

It wouldn't be as much of a problem if you could just set the encoding yourself.
The most annoying aspect is that the encoding is hidden and only revealed when you open the script with another editor.

We had not realized there was a difference until the scripts saved out of the new tool started to fail the RUNSQLSTM command.

No one wants to have to save a file on the IFS, and then go into another tool to make sure it's CCSID is setup properly.
Access to the iNav is tedious and slow because of the number of tabs you have to navigate through just to get to the IFS.
And using WRKLNK requires some knowledge of the iSeries itself.

And even if there are 100k characters that are different between 1252 and 1208, for most SQL statements the differences do not matter.
For us, the majority of the characters our SQL uses are between x'20' and x'7D', which are the same in 1208 and 1252.
Which is the entire point of the tool, to run SQL.

If the CCSID does matter for you're shop, then you probably already have standard practices for handling CCSID issues.


Chris Hiebert
Senior Programmer/Analyst
Disclaimer: Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Tuesday, March 14, 2017 3:42 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: ACS Run SQL Scripts saves files as UTF-8 BOM

Charles,

The best solution, here, is for the python process to be fixed to understand UTF-8 with a BOM.

What Chris describes is a GOOD thing (even if he doesn't see it that
way!) The scripts are UTF-8, but his upload process is marking the file as CCSID 1252. That means the system will interpret the file as 1252 -- and that's NOT okay. There are nearly 100000 characters that are different in 1208 vs 1252. So the fact that it is failing and forcing
him to change the CCSID to 1208 is a GOOD THING. (It would be even
better if the file transfer process detected the BOM and automatically made it 1208... but that is not ACS's problem. Sounds like he's using NetServer, I would consider asking IBM to change NetServer to detect the BOM and set the CCSID correctly. (Which would be impossible if ACS didn't put the BOM in there... so, again, it is a GOOD thing)

Furthermore, consider what happens if you open your SQL script in Windows software where there are no CCSIDs... if it sees the BOM, it treats it as UTF-8, if not most software will treat it as "ANSI" (ASCII) even though it is really UTF-8. Notepad++ is an exception to that rule
-- but almost nothing else I've seen will treat it as UTF-8 unless you provide a BOM.

It is a good thing. It is progress... there might be growing pains
while we get other software to upgrade their code, but it is a step in the right direction.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.