|
1) I later alluded to the misspelling. 2) Glad you found a more long term solution. As I later said, IBM has a habit of only supporting data area fixes for a release or two just to get you some more time to do it right. 3) This affects CPYTOIMPF/CPYFRMIMPF more than it affects CPYTOSTMF/CPYFRMSTMF. Why? Because CPYTOIMPF/CPYFRMIMPF use the underlying DB2 engine and IBM's getting really picky starting in V5R3 about getting your CCSID correct. Just yesterday a fix I suggested to a colleague here was to use CPYTOSTMF instead of CPYTOIMPF. They were using none of the functions CPYTOIMPF has over CPYTOSTMF so it was a perfect fit. In fact, in previous releases I think IBM used to do a CPYTOSTMF then a CPYTOIMPF when you did a CPYTOIMPF. Breaking it down into two tasks is a another perversion that has shown some success. However getting the CCSID right is the best bet. It's when you do stuff like creating a temporary file in QTEMP that some utility requires NOT be externally defined (CRTPF ... RCDLEN(###) type of file) that makes it tough. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com "Steve Landess" <sjl_abc@xxxxxxxxxxx> Sent by: midrange-l-bounces@xxxxxxxxxxxx 12/09/2004 05:12 PM Please respond to Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> To "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx> cc Subject Re: CPYTOIMPF problems on V5R3 > Rob Berendt wrote: > http://archive.midrange.com/midrange-l/200412/msg00307.html > or > http://publib.boulder.ibm.com/iseries/v5r3/ic2924/info/rzaq9.pdf > and search for CPYFRMIMPF Rob - In the first url you supplied above, as someone else indicated, CPYTOIMPF was misspelled as CPYTOIMP in the Dec 6 thread. That's why my Midrange-L search was unfruitful. In the second url you supplied - In the "Memo to Users" PDF, changes to CPYFRMIMPF are discussed, but it _doesn't_ tell you the name of the data area to create - only a reference to an APAR. Now I know that I should have used Google to search on CPYTOIMPF and CRTDTAARA or CPYFRMIMPF and CRTDTAARA, because when I did this search the _first_ link returned was: http://www-912.ibm.com/s_dir/slkbase.nsf/0/2b92592e8b597ca586256eb6004d2405?OpenDocument Which, by the way, says that creating the QCPFRIMPF data area in QSYS will _not_ have any effect on the CPYTOIMPF command, so I'm back to square one... But that's a good thing, because I just figured out the problem! I have custom JDE physical file named F57400 that is defined like this: A R I57400 A TEXT('Address Book Extract + A ') A EX$JRT R REFFLD($JRT F98FRF$ ) A CCSID(65535) A EX$JSS R REFFLD($JSS F98FRF$ ) A CCSID(65535) A EX$JCU R REFFLD($JCU F98FRF$ ) A CCSID(00037) A EX$JCN R REFFLD($JCN F98FRF$ ) A CCSID(00037) A EX$JCS R REFFLD($JCS F98FRF$ ) A CCSID(00037) A EX$JA1 R REFFLD($JA1 F98FRF$ ) A CCSID(00037) A EX$JA2 R REFFLD($JA2 F98FRF$ ) A CCSID(00037) A EX$JA3 R REFFLD($JA3 F98FRF$ ) A CCSID(00037) As you can see, the first two fields are defined as CCSID(65535). *** This was a mistake ***. JDE's File Design Aid _always_ defaults the CCSID to 65535, and you have to change it back to 00037 with SEU after making any DDS changes (a real pain in the A$$!). We just migrated to a new i5 box running V5R3. The following command worked just fine under V5R1 and V5R2. When the job ran, the data in the stream file was created properly: CPYTOIMPF FROMFILE(F57400) TOSTMF(&FILENAME) MBROPT(*REPLACE) STMFCODPAG(*PCASCII) RCDDLM(*CRLF) DTAFMT(*FIXED) But, under V5R3, the first two fields in the IFS file get hosed up by CPYTOIMPF. Here is a sample of the F57400 data: CAJ100001-800 EMER CAJ100001-816 Fish CAJ100001-3001 ABF Here is a sample of the IFS data generated by V5R3 CPYTOIMPF: ÃÁÑ100001-800 EMER ÃÁÑ100001-816 Fish ÃÁÑ100001-3001 ABF It appears that the two fields that were mistakenly coded as CCSID(65535) are now being converted improperly. It appears that the correct way to fix the problem is to change the CCSID of the first two fields to 00037. HOWEVER, to me the bigger issue is that it appears that in V5R3 IBM broke something that _was_ working just fine in previous releases. Regards, Steve Landess Austin, Texas (512) 423-0935 ----- Original Message ----- From: "Steve Landess" <sjl_abc@xxxxxxxxxxx> To: <midrange-l@xxxxxxxxxxxx> Sent: Thursday, December 09, 2004 2:13 PM Subject: CPYTOIMPF problems on V5R3 I am going insane...someone please put me out of my misery! I have seen numerous postings in various groups about how IBM "broke" CPYTOIMPF in V5R3. You can add me to the list of those who are frustrated by the changes that were made to this command. However, I KNOW that I saw posted recently that you could create a data area that would make V5R3 CPYTOIMPF behave the same as V5R2 version. I have searched for the last two hours for this information, to no avail....on ibm.com, google groups, midrange.com, and on the internet generally... I did find this little gem on ibm's web site: http://www-912.ibm.com/n_dir/nas4apar.NSF/1be1a5b61b213a6c86256c23007048f4/163781d90553447a86256f3b003c8cef?OpenDocument&Highlight=0,cpytoimpf but it doesn't give the name of the data area that needs to be created under V5R3... Arrrrgggghhh, Steve -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
