Maximo

 View Only

 Cron is giving error while reading XML while same can be imported through External System

Anil Raghuvanshi's profile image
Anil Raghuvanshi posted Fri April 10, 2026 08:09 AM

Hello Everyone,

We have recently moved to MAS 9.1 from Maximo 7.6.1.x. We have an XML file-based integration where we get GL component and Chart of Accounts related data in XMLs. To read these files separately we are having two Cron tasks. Both of these Cron tasks are not working. They are throwing below error 

 BMXAA5596E - An XML parsing error occurred when the XML structure was being converted to a flat structure. The processing exception is identified in document 0.
BMXAA1306E - The XML file cannot be parsed because the XML is not well-formed. Correct the XML and resubmit the document for processing.
ParseError at [row,col]:[-1,-1]
Message: An invalid XML character (Unicode: 0x62) was found in the prolog of the document.
Interesting thing is, when I try to import these files using Data Import functionality from External System, it is working. Even, same files are getting processed in other environments.
I checked below in working and non-working environment and everything is same.
  • File path
  • File permission
  • Encoding
  • File locking

I tried by inactivate/activate, reload and even creating new instance but no luck.

Few other such Cron tasks are working fine except these two.

Has anyone faced such an issue with MAS 9.1? What could be the reason for this behavior?

Thanks in advance.

Mark Robbins's profile image
Mark Robbins IBM Champion posted Mon April 13, 2026 03:21 AM

It would be worth opening the text file in a tool like Notepad ++

Unicode 0x62 - it looks like this is not part of the character set that the parser is expecting.

The message suggests that there is an unexpected character that is not included in the standard ASCII set that the system is ready.

You say that same files have been processed in other environments.
have you taken a copy of both files and compared them to ensure that there were no issues during the transfer solution?
have you confirmed that the PODs have the same configuration e.g. the locale settings that the JVM is using?

Anil Raghuvanshi's profile image
Anil Raghuvanshi posted Mon April 13, 2026 05:31 AM

Hi Mark,

Thanks for your response.

I have already compared files from lower environment and the environment I am facing issue; they both are same. All files are getting process in working environment while none of them are working in non-working environment.  Yes, PODs are having same locale.

Jason Uppenborn's profile image
Jason Uppenborn posted Tue April 14, 2026 10:23 AM

Because the error says the offending character is in the prolog of the document, it's not a problem with the data but a problem before the data. 0x62 is the letter 'b' (lower case b). Is the first character in the file a b instead of a < ? An out of place b sounds like something you would have noticed already, but something's wrong somewhere, so go back to asking questions you think you know the answer to.

Anil Raghuvanshi's profile image
Anil Raghuvanshi posted Wed April 15, 2026 02:18 AM

Hi Jason,

Thanks for your response.

I read about 0x62 code, followed few online articles. I checked the XMLs using the editor (notepad++) but could not find the character small b before the <xml tag. I would say I couldn't find the single b anywhere in the file.

Also, as I mentioned same files is getting processed successfully in other environments. 

Could you please suggest any other way to find this character in XML?

Thanks.

Jason Uppenborn's profile image
Jason Uppenborn posted Wed April 15, 2026 10:27 AM

You say you opened it in Notepad++, but Maximo runs on Linux. Can you use vi or cat or head from a terminal on a pod and see what the file looks like? And the ParseError at [row,col]: [-1,-1] is another pointer to the beginning of the file, before the beginning of the XML document... which as others have said feels like a character set or encoding issue -- like the file is not in UTF-8 or something.

Hafilat Balance's profile image
Hafilat Balance posted Thu May 14, 2026 08:58 AM

This honestly feels more like a file-reading or encoding problem after the move to IBM Maximo Application Suite 9.1, not a bad XML itself.

The biggest clue is that the same XML imports fine through External System and also works in other environments. Usually that means the Cron task is reading some extra character/bytes before the XML starts.

I’ve seen this happen from BOM/encoding issues, partial file writes, or the Cron picking up the file before it’s fully written to the folder. MAS/OpenShift storage timing can behave a bit differently compared to older 7.6 setups.

Since only these two Cron tasks fail, I’d compare their file polling and encoding settings against one of the working Cron tasks very closely.

Ava Grace's profile image
Ava Grace posted Thu May 14, 2026 09:20 AM

Hey Anil!

I ran into something very similar when we upgraded to MAS 9.1, usually points to a hidden character or an encoding mismatch that the Cron task is chokeing on, even if the manual Data Import handles it fine.

Since you've already checked permissions and paths, I'd double-check the File Encoding setting specifically within the Cron task parameters. Sometimes the Cron environment in MAS 9.1 defaults to a different character set (like UTF-8 vs Latin-1) compared to the manual import tool, causing it to misread the very first byte of the file.

Quick tip: Try opening one of those failing XMLs in a hex editor to see if there's a Byte Order Mark (BOM) or a stray character at the start that shouldn't be there. 

Does the issue happen with every single file, or just certain ones?

Related Content