I was plagued this week by an odd problem on one of our i5 boxes. I was trying to use the CPYFRMIMPF & CPYTOIMPF to pull in data from a new Japanese division that uses nothing but Japanese characters in their data. This of course means UTF-8 / Unicode data, which can be a bit of a pain to set up in a DB2/i5 data table (particularly if someone forgets to make fields something other than CCSID 65535!)
Anyway.... I could get data off the system using the CPYTOIMPF into the IFS no problem at all, DBCS to UNICODE worked like a treat and everything was well with the world ... BUT ... try as I might I could not get CPYFRMIMPF to bring the data back into the DB2 file again.
There was a rather odd CPE3025 message that told me the input file or path did not exist (error code 3025) and yet there is was, I could open it, read it, edit and save it and everything seemed perfect .. but time after time I got the CPE3025 error and no data was transferred. I tried all day with no sucess and eventually went home hoping that a nights sleep would clear the mind and inspiration would come in the morning.
This morning came in an did a CPYTOIMPF which worked fine, did a CPYFRMIMF .. and .. it worked perfectly with no errors
After a bit of experimenting the culprit was discovered to be the fact that I had opened the file using Operations Navigator and even though the file had been closed normally Ops Navigator holds a lock on the file until Ops Nav is closed, the net effect of this is that the file is unavailable for the CPY* command.
Part of this analysis used a rather useful but lesser known API that you can use to track locks on objects in the IFS .. the api is this :
CALL QP0FPTOS PARM(*LSTOBJREF '/ifspath/ifsfile'
*FORMAT2)
You need to have the *SERVICE special authority and the api dumps the locks to a spool file.
Easy when you know how but not an obvious tool for this particular problem
Showing posts with label iSeries. Show all posts
Showing posts with label iSeries. Show all posts
Thursday 22 November 2012
Thursday 25 November 2010
Generating a Random number on an iSeries in CL
This i have to admit is very very esoteric and even the iSeries Geeks out there may not be that interested however if you ever need to get a Random Number in CLP or RPG on an iSeries here is a way to do it.
Neither CLP nor RPG has a Pseudo Random Number generator built in, so we have to kludge it to get it to work. You can link the QLEMF C library and use the CERNAN0 api which is the method I found when I went and Googled it the other day.
The other way which I didnt find is to use the QSH shell to do it. This method generates a random number between 0 - 32767 inside the QSH shell env and then stores the result in a DTAARA so that the calling program can access the value, as there in no native way to return vars from QSH environment
01. CRTDTAAARA MyRand *CHAR 5
02. Insert the following code into your PGM
The Print $RANDOM generates the random number
The | separates the two commands
The datarea -lw MYRAND takes the random number and stores it in the DTAARA
Simples
Neither CLP nor RPG has a Pseudo Random Number generator built in, so we have to kludge it to get it to work. You can link the QLEMF C library and use the CERNAN0 api which is the method I found when I went and Googled it the other day.
The other way which I didnt find is to use the QSH shell to do it. This method generates a random number between 0 - 32767 inside the QSH shell env and then stores the result in a DTAARA so that the calling program can access the value, as there in no native way to return vars from QSH environment
01. CRTDTAAARA MyRand *CHAR 5
02. Insert the following code into your PGM
DCL &CMD *CHAR 40
DCL &MYRAND *CHAR 5
CHGVAR VAR(&CMD) VALUE('print $RANDOM|datarea -lw MYRAND')
QSH CMD(&CMD)
RTVDTAARA DTAARA(SX002A) RTNVAR(&MYRAND)
The Print $RANDOM generates the random number
The | separates the two commands
The datarea -lw MYRAND takes the random number and stores it in the DTAARA
Simples
Labels:
iSeries
Thursday 21 August 2008
Reading a CSV attachment in a server agent on Domino running on an iSeries
Oh Gentle readers here is the solution to a bit of a quandary that hit me the other day.
We have and agent that runs on a windows machine that reads a CSV sent out as an email by another system (non-domino) to a Domino mail-in database. A Server "On arrival of New Mail" agent runs , detaches the file, opens it , reads it and acts on the data inside the file on a record by record basis.
Now this all works a treat on a Windows server, but when we tried to move it to a iSeries the agent just grunted rolled over and went back to sleep, no errors but no data sourced actions performed either.
Now an iSeries is a funny if very reliable beast and what was happening was this. The email arrived in the mail box, the agent triggered and the file was saved to the what is known in the iSeries world as the IFS to the same folder as in Winders world. However the file was saved with the Coded Character Set Id (CCSID) that the AMGR jobs were running with when the save took place. For our iSeries this was 37. I could read the file from the IFS from a 5250 emulation screen. I could even drag and drop it from the iSeries to my PC and it read perfectly but the data that was being returned from the file was garbage. Initally I though it might be pure EBCDIC but not putting it through and EBCDIC convertor returned more of the same sort of garbage.
My chum Julian Robichaux wrote a nifty class that reads CSV files line by line and returns a nice easy to use arrays which needless to say I had used to read in the now detached CSV file. After some twittering and being lead down an interesting tangent by Kerr Raniney about reading the CSV directly from the MIME entity. (an idea I may investigate at a later date .. Thanks Kerr) I noticed in the help a section on what not to do in OS400 and was lead from there to the startling discovery that it was the OPEN statement that was at fault, When it changed it from
We have and agent that runs on a windows machine that reads a CSV sent out as an email by another system (non-domino) to a Domino mail-in database. A Server "On arrival of New Mail" agent runs , detaches the file, opens it , reads it and acts on the data inside the file on a record by record basis.
Now this all works a treat on a Windows server, but when we tried to move it to a iSeries the agent just grunted rolled over and went back to sleep, no errors but no data sourced actions performed either.
Now an iSeries is a funny if very reliable beast and what was happening was this. The email arrived in the mail box, the agent triggered and the file was saved to the what is known in the iSeries world as the IFS to the same folder as in Winders world. However the file was saved with the Coded Character Set Id (CCSID) that the AMGR jobs were running with when the save took place. For our iSeries this was 37. I could read the file from the IFS from a 5250 emulation screen. I could even drag and drop it from the iSeries to my PC and it read perfectly but the data that was being returned from the file was garbage. Initally I though it might be pure EBCDIC but not putting it through and EBCDIC convertor returned more of the same sort of garbage.
My chum Julian Robichaux wrote a nifty class that reads CSV files line by line and returns a nice easy to use arrays which needless to say I had used to read in the now detached CSV file. After some twittering and being lead down an interesting tangent by Kerr Raniney about reading the CSV directly from the MIME entity. (an idea I may investigate at a later date .. Thanks Kerr) I noticed in the help a section on what not to do in OS400 and was lead from there to the startling discovery that it was the OPEN statement that was at fault, When it changed it from
Open csvFileName For Input As csvFile
to
Open csvFileName For Input As csvFile CHARSET='UTF-8"
then everything started to work again!
What was happening according to the help file was that in the absence of an UTF8 or UTF16 BOM
on the file itself OR the CHARSET setting on the OPEN command the iSeries opens the file with the
CCSID tha tis on the file, in this case 37 so the iSeries was basically taking ASCII thinking it was
EBCDIC and forcing it into CCSID=37. The result was basically crap data. However setting the
CHARSET= parameter did the trick!
For all you iSeries Gnomes like me out there this is a fact worth remembering if you want to do
anything "smart" with attachments in agents.
Labels:
iSeries,
Lotusscript
Saturday 24 May 2008
A plug for a nice wee iSeries tool
I don't do this often however I thought I would give a bit of a plug to an iSeries tool we got years and years ago. I actually runs on our Domino server on WinTel but talks directly to all of our iSeries boxes. The tools is called
PDFing
This little gem sits and pretends it is a LPD printer which you can set an iSeries OUTQ to point at just like any other IP printer. When a spool file appears on the OUTQ it is sent to PDFing and is converted to a PDF file which can then be emailed directly to your domino server (or the world in general). It can handle straight reports, IPDS reports and even stuff like barcodes. Oh an it can also convert iSeries reports to M$ ExHell should you be a complete pervert ;-)
We bought this tool 8 years ago and it always has run a treat. As of yesterday it had converted 850,000 iSeries reports to PDF, TXT and ExHell.
Thank you PDFing .. Great Job Keep it up!
PDFing
This little gem sits and pretends it is a LPD printer which you can set an iSeries OUTQ to point at just like any other IP printer. When a spool file appears on the OUTQ it is sent to PDFing and is converted to a PDF file which can then be emailed directly to your domino server (or the world in general). It can handle straight reports, IPDS reports and even stuff like barcodes. Oh an it can also convert iSeries reports to M$ ExHell should you be a complete pervert ;-)
We bought this tool 8 years ago and it always has run a treat. As of yesterday it had converted 850,000 iSeries reports to PDF, TXT and ExHell.
Thank you PDFing .. Great Job Keep it up!
Labels:
iSeries
Subscribe to:
Posts (Atom)