2

I am rather new to the whole IBM i (as400), rpgle scene.

I was given the task to export some information into XML format.

I was able to make the output of the information correct, the problem arose when I used CPYTOPCD to copy the information to the XML file.

For some reason I have yet to understand or even find information about, CPYTOPCD only copies a fraction of the data when I use from within my program. When I go to the as400 command line though, it copies the entirety of the data without problem.

The only difference I can see when I do this is that in the command line the CPYTOPCD command all fits within the one row while in the program I must use the '+' and move on to the next row to finish the command.

I have looked on many different sites but I cannot find a similar problem. Perhaps I am not phrasing the problem correctly and that has been my biggest problem.

I apologize if I may not be explaining the situation well enough so please let me know what other information I could supply to make it easier.

Thank you very much for any help you can provide.

edit: I don't know if this is part of the problem or not but I figured I might as well add it in just in case. When I check on the outputted XML, where it ends, which is half way through some tag that it has written before without problem, it puts a small box. From what I have found online I think it is a whitespace character but I am not sure.

edit2: CLP is this multiple times for different files.

CLRPFM FILE(SDIXW4)

CALL PGM(SDI812)

CPYTOPCD FROMFILE(SDIXW4) TOFLR('AUDIT') +
TODOC(RELLOC.XML) REPLACE(*YES) + TRNFMT(*NOTEXT)

edit3: I am going to try the suggestion that Charles gave. Hopefully this bypasses the problem I am getting with CPYTOPCD. I will update this after testing the new form. Thanks again for all your help.

jmarkmurphy
  • 11,030
  • 31
  • 59
RaptorSD
  • 33
  • 4

4 Answers4

2

What version and release are you working with?

As Buck mentioned, CPYTOPCD has been depreciated for a long time. CPYTOSTMF and CPYTOIMPF are better choices.

Since you mention adding the XML tags yourself, a better choice than the CPYxxx commands would be to simply use the write() function available in the C Runtime library to write directly to the IFS stream file. You can use this function from a ILE C or ILE RPG program. (example code from Scott Klement's XML from RPG presentation

fd = open('/home/scottk/xml/test.xml'
: O_WRONLY+O_CREAT+O_TRUNC+O_CCSID
: M_RDWR
: 819);
xml =
'<?xml version="1.0">'
+ '<CustFile>'
+ ' <CustRec custno="' + %trim(CustNo) + '">'
+ ' <Name>' + %trim(Name) + '</Name>'
+ ' <Address>'
... And so forth ...
callp write(fd: %addr(xml)+2: %len(xml));
callp close(fd);
/end-free

If you happen to be on a recent release (7.1 or 7.2) of IBM i, then you could probably use the XML functions that have been added into DB2 for IBM i.

Charles
  • 21,637
  • 1
  • 20
  • 44
  • Thanks, I will definitely try this, maybe this solves my problem with the CPYTOPCD, and I think I might be on 7.1. – RaptorSD Jul 28 '15 at 15:17
2

I had the same problem some time ago ... CPYTOPCD didn't export all records from my file ... but I called the command through QCMDEXEC at the end of my RPG code but was enough a "close myfile" befor QCMDEXEC to solve it. Do you end your rpg code with a "return" or a "seton LR" ?

  • @Roberto has a good idea. Since your CL runs multiple times for different files, how are you doing that? OVRDBF before each CALL SDI812? Or is there a different RPG program for each XML file? The reason for the question is this: What if you're looking at the output XML from the wrong file? One way to check this is to write a new CL program that only does one conversion. – Buck Calabro Jul 29 '15 at 13:32
  • The CL doesn't call SDI812 multiple times, it calls different RPG programs and each creates their own XML. Also, from Roberto's comment it occurred to me to put Seton LR in one of my programs to test and it somehow fixed the issue. So officially it has been resolved. I tested it by putting it on all the programs and it does work, it is now exporting all the data. Thank you very much. – RaptorSD Jul 29 '15 at 14:28
  • @RaptorSD: The *INLR=*ON will effect an implicit CLOSE; the CLOSE could have been explicit instead, or presumably instead, just the Force End Of Data (FEOD) as an option because BLOCK(*YES) is the default effect for output, and thus the buffered\blocked records that would have been flushed [from the buffer _in the program_ into the file] per [implicit or explicit] CLOSE could instead get flushed explicitly using the FEOD [if there was a reason not to close the output file then; perhaps left to close later]. – CRPence Aug 12 '15 at 17:19
  • @Roberto and TWiMC, the system program name is QCMDEXC, not QCMDEXEC – CRPence Aug 12 '15 at 17:20
0

I assume you're in a source edit session of some sort. That being so, I suggest that rather than typing the plus sign, going to the next line and completing the command ... that you just type CPYTOPCD, then press F4 and then F10, and complete the command prompted. (Use Page keys to see the entire command parameters and options list.) Maybe you'll see the thing you missed before. Another advantage of this approach, is that you can use F1 to get help for any of the parameters in the command.

Dennis
  • 1,071
  • 2
  • 17
  • 38
  • Yeah, I checked through the whole list of parameters, the one that made a big difference was when I filled out TRNFMT with *NOTEXT instead of *TEXT. It copied a lot more of the data, but still not complete. – RaptorSD Jul 28 '15 at 13:40
  • Can you paste your entire command here... and/or give more details about your data? Also, are you ignoring errors (gets SO MANY people into trouble...) such as MONMSG CPF0000, and ignoring the result? If so, stop that! Let's see what errors are presented without that. – Dennis Jul 28 '15 at 13:42
  • CPYTOPCD FROMFILE(SDIXW4) TOFLR('AUDIT') + TODOC(RELLOC.XML) REPLACE(*YES) + TRNFMT(*NOTEXT) I don't believe I am ignoring errors, at least with errors I could search for those. The only errors I have found are the box in the XML file with the whitespace character. The info I found on that one is, go into the file and erase it, doesn't really help on how to avoid it. By the way thank you for your help. edit: The only thing I get is a warning, CPD0792, and that's because the program simply calls others and uses the CPDTOPCD. – RaptorSD Jul 28 '15 at 13:52
  • CPD0792 is a CL compiler diagnostic. Are you using a CL program or an RPG program? – Buck Calabro Jul 28 '15 at 13:58
  • A CLP is calling RPGLE programs, but the CPYTOPCD is being called from a CLP, sorry for that confusion, as I said, I'm new to all of this. – RaptorSD Jul 28 '15 at 14:03
0

CPYTOPCD is very much deprecated. What's more, it doesn't convert / export DB2 to XML, so it seems that your DB2 table already contains XML. CPYTOSTMF is a far better choice to simply move an already-XML table to the Integrated File System (IFS).

EDIT: Check the job log. IBM i commands like CPYTOPCD almost always issue some sort of message if they encounter an error. It's very unusual that one fails without any messages at all. CALL QCMD to get to the naked command line and press F10 to see all messages.

Buck Calabro
  • 7,558
  • 22
  • 25
  • TOFLR() is not to the IFS; it's to PC folders. I'm not sure there is an IFS path to the folders (there may be, but without a system I cannot check). – Dennis Jul 28 '15 at 14:06
  • Thanks, but the table doesn't contain XML, since I am so new to this I manually make it write the Tags. The RPGLE programs reads in the data and I write it out manually writing the tags. I've also tried using CPYTOSTMF since I kept reading that it would be better but I just cannot seem to get it to work. Obviously I am writing the command incorrectly but even with all the examples online I just keep writing something wrong. I believe it has to do with the STMF parameter that I am not properly giving the path. – RaptorSD Jul 28 '15 at 14:07
  • @Dennis There is indeed an IFS path to the folders - it is /QDLS. Try WRKFLR and compare the results to WRKLNK '/QDLS' Using QDLS / folders in 2015 is Not A Good Idea. – Buck Calabro Jul 28 '15 at 14:22
  • Sorry. Memory (and aforementioned lack of system with which to work) got the better of me. – Dennis Jul 28 '15 at 14:31
  • Trying to understand the whole process. Assuminging TABLEA is some transaction file that you want to send to a trading partner. Your CL program runs and does a CALL to an RPG program that reads TABLEA and writes TABLEB, adding XML tags. Then the RPG ends, control goes back to the CL which then does a CPYTOPCD. Is that right? If not, could you describe the process? Also, what version of IBM i are you running? – Buck Calabro Jul 28 '15 at 14:49
  • Nope, you got it pretty much perfect. The version I am told is version 7 – RaptorSD Jul 28 '15 at 14:59
  • I did a call to qcmd, nothing really was sent. Just all the different commands I've written and the changes to the files. Nothing really looked like an error message or something like that. – RaptorSD Jul 28 '15 at 15:38
  • Reviewing the job log is pretty much crucial to working with IBM i programs. When you're in QCMD you should then CALL SDI812 and what / if messages are logged. My best guess (without seeing your job log) is that you're running SDI812 by choosing a menu option and the job gets submitted to batch rather than running interactively. Alternatively, you are running SDI812 in one terminal session and looking at the job log in a different session. – Buck Calabro Jul 28 '15 at 17:43
  • @RaptorSD If "nothing was sent" to the joblog, it's **possible** that some diagnostic or info messages weren't shown. You might need to press F10='Display detailed messages'. Maybe. No matter, though, since CPYTOPCD is pretty special-purpose nowadays. – user2338816 Jul 28 '15 at 22:39