Re: CPFA0DB when using CPYTOSTMF

Anytime I see 'Japan', and an error that doesn't occur in other
environments, the first thing I look for is the use of lowercase letters.
In your case you have lowercase scattered through your CL command
parameters.

The item to watch out for with Japan is that there is a CCSID (5026 to be
specific) where lowercase a-z are not encoded at the 'traditional' code
points. Rather than 'q' (as in qsys) being x'98' (as in CCSID 37) the
lowercase 'q' is x'8b' and Japanese Katakana characters are encoded at the
'traditional lowercase code points). Assuming your CL command is in a
program and that your program is compiled with a non-5026 source file then
the system is seeing your q (x'98' from your source encoding) which
corresponds to the Japanese Katakana character letter NU ( ヌ ). And your
full 'qsys' constant is being interpreted by the Integrated File System
commands as being ヌ ヘモヘ. This, as you can seem, is not exactly QSYS!

You have a couple of options:

1. Use uppercase A-Z for your contants (these are encoded the same across
all EBCDIC CCSIDs)
2. Use an API such as iconv within your code to convert all 'constants'
from the compiled CCSID (37 most likely) to the job default CCSID prior to
executing the command
3. If the job CCSID is 5026, change the job CCSID within your program to
the CCSID used to compile your application program. After running the
commands with lowercase a-z change the job CCSID back to it's original
setting. Note that this is the lazy and possibly dangerous solution. If
your program is interrupted and another program run within the job, then
the CCSID is not right for the other program(s)
4. If the job CCSID is 65535 and the job Language ID is JPN then the
Integrated File System is assuming 5026. As with Number 3 you need to
change the job CCSID to your programs CCSID and then change the job CCSID
back to 65535 when done. This has the same pitfalls as Number 3.

Though it's more work, option number 2 is my personal preference. Then
you're covered where ever your application runs, and not just for
lowercase characters. When working with multiple national languages try
to remember that literals/constants are not your friends -- they are just
problems waiting to surface!

Hope this helps,
Bruce Vining







"John" <jallen@xxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
06/05/2007 04:10 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
<MIDRANGE-L@xxxxxxxxxxxx>
cc

Subject
CPFA0DB when using CPYTOSTMF






I have done this many times on other machines but for some
reason whenever I execute the

following CPYTOSTMF on this particular machine (V5R4) I am
getting CPFA0DB



CPYTOSTMF
FROMMBR('/qsys.lib/qtemp.lib/XFWPDF.file/XFWPDF.mbr')

TOSTMF('/DRC/USR01/TestFile.PDF') STMFOPT(*REPLACE)
STMFCODPAG(*PCASCII)



(Note: This file and member does exist in QTEMP, and the
directory /DRC/USR01 does exist and I have all authorities
to it)

Message text for CPFA0DB is not real helpful:



Message . . . . : Object name not a QSYS object.


Cause . . . . . : The operation expected an object in the
QSYS file system.

Object &1 does not result in an object in the QSYS file
system. Possible

causes:


--The object is in a different file system.


--The object name does not start at the root file
system.

--The first component of the path name is not QSYS.LIB.


--The object is on a remote file system.


Recovery . . . : Determine the correct name for the
object. Only local

QSYS file system objects are valid for this operation.
Retry the operation.



Can someone point me to where/what I should be looking to
find the cause of this error?

This machine is in Japan and I am accessing it remotely but
I cannot figure out why that would cause this particular
error.

I have seen many errors in regards to Code page problems
using a machine in Japan, But that does not appear to be the
cause of this error.



Any guidance would be greatly appreciated



John