|
On
the best method to GET large stream files with FTP from a UNIX
system to an iSeries system,
Marilyn, from Connecticut
wrote:I
have a problem where I'm trying to do a GET from a UNIX machine >
to an AS400 machine. The UNIX only supports file structure.
The
file far exceeds the AS400 limitation for a physical file.
I've
tried the STRUCT
R command
but the UNIX doesn't implement it. I've tried the LOCSITE
LRECL=80 command
and it won't accept that either. Answer:In
the V4R4 release of OS/400, the Integrated File System (IFS)
provides 64-bit versions of its UNIX-type commands. With the new
64-bit mapping, sizes, offsets, and lengths are represented as
64-bit integers, which eliminates the 2 GB limit. With this
change, iSeries users can now store and manipulate large files up
to 256 GB in the QSHELL Root (/) or any user-created subdirectory
in that environment.Instead of trying to FTP your file into a
conventional physical file, you will need to FTP it to the IFS
(Integrated File System).
What
this means is that instead of getting your file into a
MYLIB/MYFILE.MEMBER
format, you would get it into a
file format such as
/QSYS.LIB/libname.LIB/filename.FILE/mbrname.MBR
your
FTP command will look like
GET
remote_path/remote_file
/QSYS.LIB/libname.LIB/filename.FILE/mbrname.MBR
Once
you have this file imported in your IFS, you can then use the
CPYFRMIMPF
command to parse the records out
to a conventional, regular physical file. CPYFRMIMPF
will even parse fields, if you
have delimiters in your incoming data (i.e. data in .csv format).
The command would look something like
CPYFRMIMPF
FROMSTMF('/QSYS.LIB/libname.LIB/filename.FILE/mbrname.MBR')
TOFILE(REGULARLIB/REG_FILE)
MBROPT(*REPLACE)
RCDDLM(*ALL)
Here
are the actual commands that were used to resolve this question.
Note the NAMEFMT
1 command
which tells the operating system to look for the IFS file naming
convention:
In FTP:
MODE
BINARY
NAMEFMT 1
GET remote_path/remote_file
/QSYS.LIB/libname.LIB/filename.FILE/mbrname.MBR
From
the Command Line:
CPYFRMIMPF
FROMSTMF('/QSYS.LIB/libname.LIB/filename.FILE/mbrname.MBR')
TOFILE(REGULARLIB/REG_FILE)
MBROPT(*REPLACE)
RCDDLM(*ALL)
Note
that this entire stream can be automated using the techniques
explained in Practical
Programming for AS/400 iSeries FTP Automated Interfaces
A
good article in the IFS file-size change can be found in
MCPressOnline. It is titled "V4R4
APIs Expand AS/400 IFS File Sizes to 256 GB"
Go
Back to the Top
|
|
On
CPYFRMIMPF not accepting nulls when importing a comma-delimited
file
Wayne from Vancouver wrote: I
am trying to import data from a Microsoft XL sheet converted to
Comma-delimited format (.csv) using the AS/400 (release v4r4)
CPYFRMIMPF
command. I and running into
trouble when empty cells, represented by two commas with nothing
in between (, ,) are interpreted by CPYFRMIMPF
as being NULL. Is there any way
to circumvent this problem? Answer:
There
are two patches available for the iSeries which address this
problem: The V4R4 patch adds a parameter - RPLNULLVAL(*FLDDFT)
- which controls the action of
CPYFROMIMPF
when it encounters a field which
contains a null value. Basically, it puts in a default value so
that the import can continue. If the field is numeric, the default
is a zero, if the field is alpha, the default is blanks. The V4R4
PTF numbers are: SF61859 & SF61937
In V4R5 this feature is
already there, except for the earlier releases of V4R5. For
systems in that situation, the V4R5 PTF SF62142 will do the trick.
These are very small PTFs to download through the ECS modem. They
can be installed without having to IPL the system and are
effective immediately after applying the patch.
Go
Back to the Top
|
|
On
transmitting special characters, such as square brackets from an
RS/6000 UNIX box to an iSeries
John,
from Toronto wrote: Hi,
I was on your site recently and was wondering if you could assist
me with this problem. We currently FTP text files from our RS6000
to our AS/400 IFS root file system ..eg. /home/user..and need
those files to be in codepage 37. It seems to work if we type
ebcdic before the put command, however, special
characters like [ (left square bracket) and ] (right square
bracket) DON'T get translated properly.
I read your suggestion to one user about using translation tables,
but in this case the FTP is taking place FROM the RS6000 NOT the
AS/400. Does AIX have any special subcommands I could you to get
it in the right codepage? Any suggestions? Answer:
This
is the answer, which John found by himself: Hi, I figured it
out... You need to change the FTP server attributes on the AS/400
side. You can do this in one of two ways: 1) GO
CFGTCP to get
to the Configure TCP/IP menu. Then select option 20 Configure
TCP/IP applications, option 10 Change FTP Attributes..you will see
Server Mapping tables keywords for incoming and outgoing. Change
the incoming to a mapping table that has those 4 characters
remapped to the right hex codes. Press Enter and restart the FTP
server jobs. 2) The second and easier way is through Operations
Navigator: Open the system you want to change and click on
Network, Servers, TCP/IP. In the right window, right click on the
FTP job, click Properties, click Mappings tab, check Use specified
mapping tables, click on Tables, check Use incoming mapping table,
type in the table name and library and click OK twice. Restart the
FTP server by right clicking on FTP, stop, wait a couple of
minutes, then right click again and click Start. Now, if you FTP
from the Unix side to the AS/400 (an IFS file), you don't need to
specify EBCDIC as the type. If you still want files in ASCII code,
try using type binary.
Go
Back to the Top
|
|
On
Preserving UNIX Record Structure when FTPing a file from UNIX to
an iSeries Physical File,
Sylvan,
from Toronto wrote: I
am having an issue regarding FTP that I was hoping you may be able
to give me a hand with.
I am trying to GET
a file from an FTP site on a
UNIX box (Type: L8) directly via scripting from the AS/400.
Everything seems to work fine as far as the transfer of data,
however when I look at the file which I am receiving from, the
carriage returns appear to have been ignore and all records have
been concatenated into one long record.
I have tried issuing a
STRUCT
R, but
the system replies with a "202
'STRU' : Command not implemented, superfluous at this site."
I
have tried defining the receiving file with the exact record
length, but this has only allowed the first record to transmit and
truncates any others. Do you have any intuition as to what I may
be able to do to correct this? Any help is appreciated
greatly.Response:
I suspect the file on your
UNIX box is a simple stream file, which does not have any carriage
return characters, thus the difficulties you are
experiencing.Answer:
This
is the answer, which Sylvan found by himself: The original file
did contain carriage returns but no line feeds. This did not work.
The record structure was not carried to the AS/400 file. We've now
tested the FTP process with the same file containing line feeds as
well as carriage returns and it now FTP overs to the 400 just
fine. I know it sounds odd that a line feed was required since a
carriage return already existed, but there were no other changes.
Thanks greatly for your time on this problem. I have also tested
the FTP process with the file containing only line feeds as record
delimiters. This works like a charm--all results now come in
record-by-record without issue. Other
Explanations:
Here
are some further explanations on this, credit to
http://www.dantobias.com/ for this information. When uploading or
downloading HTML files using an FTP (File Transfer Protocol)
program, always use ASCII mode rather than BINARY. The reason for
this is that different operating systems vary in how they
represent line breaks. MS-DOS and Windows systems use a carriage
return followed by a linefeed (ASCII characters #13 and #10) at
each line break, which is the traditional standard dating back to
1960s Teletypes which needed both characters to get the terminal
to both move the carriage to the left margin and move down a line.
Developers of some operating systems have decided that this is
wasteful and a single character would suffice, but unfortunately
they weren't consistent: UNIX ended up using a linefeed (#10)
alone (which Unix developers refer to as a "newline"
character), while Apple computers (both the old Apple II line and
the Macintosh) chose the opposite course of using a carriage
return (#13) by itself. The result is that there are three
different ways of denoting the end of a line, and software can
fail if faced with a file that is delimited in a manner different
from your operating system's convention. To avoid these problems,
the FTP protocol was developed with an "ASCII mode" that
converts line breaks to the appropriate style for the destination
system. When you're sending from a UNIX server to a Windows PC, it
adds a carriage return before each linefeed. Transferring the
other way, it strips the carriage return. Transferring from UNIX
to a Mac, it converts the linefeeds to carriage returns. Thus, the
integrity of the file is maintained no matter what systems it's
transferred between
Go
Back to the Top
|
|
Regarding
Translation Tables,
Hany
El Moualed, from Saudi Arabia wrote:
I am trying to ftp file from
AS400 machine to RS6000 one. The text is mixed Arabic and
English.
I have no problems regarding English text, but
the Arabic one is completly rubbish.
Do you have any clue
about the case of this.
Appreciate your help
Mr. El Moualed can be reached at
elmowald@yahoo.com Response:
I suggested to Hany that the
translation table for the double-byte characters that are the base
of the Arabic language on the AS/400 may be the problem. Resolving
this turned out to be a relatively simple matter, although it took
some time to find it. Hany
found himself the way to do this. He resolved the problem in the
following steps: 1)
Retrieve
the source of
the QASCII
translation table, using
RTVTBLSRC.
This takes the contents of the translation table and dumps them
into a regular source file. 2)
Modify
the newly retrieved translation table,
using values that would meet the specific requirements of the
transfer. Note: this table contains only the translation, for
example, in QASCII,
EBCDIC Hex 04 translates
to ASCII Hex
9C. In the
translation table, only 9C
will show. An easy way to see this
type of table is to use the Work with Tables (WRKTBL)
command. Pick the table you want to see and put a 5 in front of
it. This will display the values inside the table. I have
also suggested to Hany to look at the following website:
ftp://ftp.unicode.org/Public/UNIDATA/
which contains a number of hex tables for foreign languages.
3) Re-Create
the translation table using
CRTTBL.
Note that the table type is *CVT. Note, it is a good idea not to
override a standard IBM table, like QASCII
or QEBCDIC.
Rather, create your own version of a new table, say "XASCII"
or "XEBCDIC"
for example. 4) When
starting
an FTP session,
automated or manual, you will use the FTP command. This command is
promptable. If you hit F4, you will only get the remote system
parameter, but if you hit F10 after that, you will get a new set
of parameters, amongst which there is the name of the incoming and
outgoing ASCII/EBCDIC
tables to use. At this point, you
can enter your own customized version of the translation table, as
in "XASCII"
or "XEBCDIC"
for example. 5) Test
your new setup with FTP transmissions
of data sets that will allow you to reliably verify the desired
results.
Go
Back to the Top
|
|
Regarding
Retrieving MGET Results,
Amanda, from Ohio, wrote:
I am trying to do a multiple
get from a novell network to an as400 using ftp. I want to get all
exe files from the network and store them in an as400 folder for
backup purposes. I thought I could use the mget command but when I
try this, the files go the the qgpl library instead of the folder.
This is not where I want them!! What am I doing wrong?? Any help
you can give is appreciated. Also, thanks for your article about
automating FTP ... It was a HUGE help to me!! Thanks. Amanda I am
using mget *.exe /qdls/plant trying to get it to copy to the plant
folder. Response:
If you do a HELP
MGET in your
FTP environment in the AS/400, you will get detailed help on using
this command. The key here is that MGET
places the results into your
current library. If you do not have a current library specified
for your environment, OS/400 deems QGPL to be the default. If you
issue with your CL the following command, CHGCURLIB
CURLIB(XYZ) then
XYZ
will become your current library
and MGET
will bring
back anything you tell it to and place it in XYZ.
You should be able to get away with mget
*.exe alone
(provided you are in the right directory) and that only would be
enough to bring back your files to XYZ
or what ever current library you
specify for your job.
See also the question below, from
Mike from Wisconsin:
Go
Back to the Top
|
|
Regarding
Targetting library-specific files on AS/400,
Mike, from
Wisconsin, wrote: I
was wondering if Amanda (see question above) solved her problem by
looking in the help. It looked to me like she may have needed to
change name formats and then change directories. For
example:
namefmt
1
lcd /qdls/plantResponse:
Following your comment, I have
done some digging on the namefmt command. Here for the readers of
this website is the short story on namefmt
and lcd.
I do agree, this combination of commands enable a more precise
targetting of libraries and file system within FTP without having
to affect the current library and thus the entire job. NAMEFMT
(Select File Naming Format)namefmt 1 is
the default iSeries format.
With
it, one can use file notation such as
libname/filename.mbrname
namefmt
2 is the a
naming format for all file systems supported by FTP.
With it,
one can use file notation such as
/QSYS.LIB/libname.LIB/filename.FILE/mbrname.MBR
LCD
(Change Working Library or Folder)The
LCD subcommand has the same function on the client system as the
CD subcommand has on the server system. To change the default
library, folder, or directory to which file transfer commands
apply on the local system, use the LCD subcommand as follows: lcd
pathnameNotes:
1. The current library is not changed by the LCD subcommand.
Therefore, you can place files where you want them without
changing the current directory.
2. When using the LCD FTP
command to change from one file system to another file system, the
"root" directory must be specified. For example, /QDLS
or /QOPT.
Go
Back to the Top
|
|
Regarding
the Type of File Necessary to Store an FTP Script,
Lance, from
Washington wrote:What
type of file should be used to store the FTP Script? Response:
The "INPUT" file that
will contain the FTP script should be a one-field file.
My
easy short-cut technique for creating a prototype involves
creating a file with the following
source:-----------------------------------------------------------------------------------
A
R REC24 TEXT('Import Record Fmt')
A SRCDTA 80A TEXT('Source
Data Field')
-----------------------------------------------------------------------------------
What
you can then do is create a source file where you enter your FTP
script.
All source files have three fields, the sequence
number, the date and the source data. All you have to do once you
have used PDM to create your script in your source file member is
to do a CPYF
to send the content of your newly
populated source file member to your FTP script source file.
Since you are copying from a source file to a regular file,
you have to use the convert source (*CVTSRC)
format option.CPYF
FROMFILE(CATDA7/QSRC) TOFILE(CATDA7/FTPINPUT) FROMMBR(FTPINST)
TOMBR(*FIRST) MBROPT(*REPLACE) FMTOPT(*CVTSRC)
Go
Back to the Top
|
|
Regarding
the PASV Command on the AS/400,
Woody, from
Georgia, wrote: Thibault,
I saw a recent discussion on your site about a problem in
exchanging files between an AS/400 and a PC. The solution to the
problem that the gentleman reported (Jeff) was simply turning off
the "pasv"
command.Some customers are
exchanging data with us from the AS/400 platform using FTP. Most
of the time everything works very well but some of them are
reporting an occasional disconnect. We have analyzed this
situation and found that they always occur on the "pasv"
command. Their client
automatically issues the "pasv"
as a sub command when they
perform a "put"
or "get".
The disconnects always occur when they do not get an ack
back from
the first "pasv".
The client reissues the command then you see both the client and
our server issue disconnects. We are not sure why the packets get
lost because we do see the ack
going
back.The "pasv"
command is not essential for us
but the one client that we have worked with on this is saying that
they cannot turn it off. I now know that they can. We are not an
AS/400 shop so can you tell me how this command can be turned
off?WoodyPS. I have been to your city and the surrounding area a
couple of times and your view is better than the one I have in
Atlanta as well.Response:
Hi Woody, Thanks for your
question. You want to tell your customer to use the SENDPAsv
command. Here is the syntax and some explanation of how to use
this command:SENDPASV
(Specify Whether to send a PASV
Subcommand) is an FTP Client Subcommand used to specify whether or
not to send a PASV subcommand to the FTP server when doing a data
transfer or issuing the DIR and LS subcommands.
To use
this instruction, enter the SENDPASV
FTP client subcommand: SENDPASV
[0|1] If
there is no parameter SENDPASV
works like a toggle switch.The
SENDPASV
value toggles from 1 (ON) to 0
(OFF) or from 0 to 1. When there is a parameter, the valid values
are:
0
Do not send a PASV subcommand
1
Send a PASV
subcommand. This is the default.
AS/400 system default (on) is to send the PASV
subcommand.
When SENDPASV
is off, then the server does not
send the PASV
subcommand.Additional Notes:
1)
For a graphic illustration of Active/Passive FTP, go to Active
FTP vs. Passive FTP, a Definitive Explanation.
This is an excellent page, explaining exactly how FTP behaves in
Active mode vs. Passive mode.
2) The iSeries FTP client
defaults to passive mode. The default however can be changed to
Port mode by using the following command to create a data area
which alters the behavior of FTP on OS/400:
CRTDTAARAA
DTAARA(QUSRSYS/QTMFTPPASV) TYPE(*LGL) AUT*USE
This
technique, along with a clear text explanation of passive vs.
active mode can be found in the IBM document titled
"Behavior
of FTP Passive Mode".
Go
Back to the Top
|
|
Regarding
Techniques to Monitor PING Messages,
Stephen, from
Ontario, wrote: Thibault,
I've a CL which monitor the PING, if it failed, the program will
not perform FTP immediately. However, the MONMSG
of TCP3206/TCP3202/TCP3213
are not working at all. Can you
help?Here is the
code:PGM
/* Verify connection to Host before attempting Transfer */
PING RMTSYS('128.2.2.66')
MONMSG MSGID(TCP3202 TCP3206)
EXEC(SNDPGMMSG + MSG('Ping to remote not successful'))
ENDPGMHere
are the results I got::Verifying
connection to host system 128.2.2.66.
No response from host
within 1 seconds for connection verification 1.
No response
from host within 1 seconds for connection verification 2.
No
response from host within 1 seconds for connection verification 3.
No response from host within 1 seconds for connection
verification 4.
No response from host within 1 seconds for
connection verification 5.
Connection verification statistics:
0 of 5 successful (0 %).Response:
Hi Stephen,
I tried what you
did. I found I got identical results to yours if I use a numeric
IP address (128.2.2.66
for example) instead of a IP table
configured system name (SYSTEMR
for example).
The remedy
for your problem is to configure a proper IP system name and use
that name in your program rather than a numeric IP address.Here is
the test code I have used to try this:PGM
DCL
VAR(&LOCATION) TYPE(*CHAR) LEN(10) VALUE(SYSTEM1)
PING
RMTSYS(&LOCATION)
MONMSG MSGID(TCP3202)
EXEC(SNDPGMMSG
MSG('Ping to remote location does not work'))
ENDPGM
Go
Back to the Top
|
|
Regarding
Line Wrapping in FTP Source Commands,
Jim, from California
wrote: Hi.
I'm running FTP on an AS/400 in batch mode, PUTting
a file with a very long name,
to another very long name & I'm running up against the source
file (script file) record length wall. Is
there a way to continue the FTP command across multiple
lines/records?Response:
The response is actually from our
local IBM rep, Hadi Kilani: Thibault, FTP
command line wraping is not supported in OS/400.
That is not a common problem with
our users. I did research IBM reported user Q&A database with
no questions like that.
Go
Back to the Top
|
|
Regarding
Line Wrapping in FTP Source Commands,
Jane, from Florida wrote:
"I
am sending a 108 byte file to a UNIX box. The last 26 bytes are
blank so when they get to the unix box they get lost. The customer
wants it to be the full 108 bytes so I null filled the file and
they complained because they want it blank and nulls are equal to
a numeric. So my question is will STRUCT
R keep my
length of the file at 108 even though the last 26 bytes are blank.
I have already been through asking to send a carriage return at
109 but they refused. Would using "STRUCT
R" resolve
my problem?"Response:
This user actually solved the
problem without help by using a combination of two FTP
subcommands: LOCSITE
TRIM 0
ASCII The
LOCSITE
FTP
subcommand specifies whether or not to transfer the trailing
blanks in a database file to the remote server. The command can be
used in three ways:
TRIM
0
Set Trim option to OFF. Trailing
blanks of database records are sent.
TRIM
1 Set
Trim option to ON. Trailing blanks of database records
are NOT sent. This is the default setting.
TRIM
Displays the current setting of
the Trim option. Conversely, a client doing a get instruction
targetted at an iSeries can use the following instructions to
ensure the system will send trailing blanks: QUOTE
SITE TRIM 0
Go
Back to the Top
|
|
Regarding
how to transfer Libraries or Save Files using FTP,
Ibrahim
Shareef, from Saudi Arabia wrote: How
can I FTP the contents of an entire library from one AS/400 to
another AS/400?Response:
Transferring AS/400 Objects or
complete libraries with FTP can be done with the help of Save File
(files of type *SAVF)A SAVF type file is a physical file with
records 528 characters long. Here is how to transfer the contents
of a SAVF from one AS/400 to an other:
- Create a Save
File (CRTSAVF)
on the source machine
- Save objects in the SAVF
- Create
a Save file (CRTSAVF)
on the target machine
- FTP to Remote AS/400 mode
BINARY
PUT
FROMLIB/SAVEFILE TOLIB/SAVEFILE
-
For Automated Procedures (the SAVF does not have to be on the
target AS/400: mode
BINARY
put
/qsys.lib/catda7.lib/fromsavf.savf
/qsys.lib/catda7.lib/tosavf.savf
Go
Back to the Top
|
|
The
best method to unpack fields in a physical file before an FTP
TransmissionThis
is a tip that I presented at the Pacific Midrange Systems
Association: Response:
Use the Copy to Import File
command: CPYTOIMPFExample
of CPYTOIMPF
: CPYTOIMPF
FROMFILE(DB2FILE)
TOFILE(EXPFILE)
FLDDLM(';') RCDDLM(X'07')All
records of externally described file DB2FILE
will be copied to import file
EXPFILE.
Fields in the import file will be delimited by a semi-colon
(;)
character.
Each record in the
import file will be delimited by a hexadecimal '07'
character.
Go
Back to the Top
|
|
Signon
via FTP does not update the USRPRF profile with the date and time
last accessed.
Jim, from Vermont asks: Any
time we sign on to the AS/400 via FTP it does not update the user
profile with the date and time last accessed.We have users that
will only be accessing the AS/400 via FTP.
Since we also have
a program that deletes user profiles after 60 day's this will
cause a problem.We do not want to set the password expiry date to
*NOMAX
for security reasons. Is there
any way you know of to force as FTP signon to trigger an update to
the user profile automatically for the last access date? Response:
I have discussed the situation you
inquired about with my colleague Mark Whiteside, of Shell Canada
Limited. The response that follows is the result of our
conversation: 1) I have tried myself and verified what you have
said about the "Previous Signon" date and time. Signing
on via FTP does not update these values for the user profile used.
The problem is that when you signon via FTP, your session
is handled by some special FTP server job rather than through a
normal QINTER signon session. From all we know, you cannot force
FTP signon to trigger an update to the user profile automatically
for the last access date.
2) There are two ways to solve the
security exposure that is at the heart of your question: a) If you
want a home-grown solution, we advise the following:
It is our
joint opinion that the best way to handle this situation is to use
an FTP Exit Program to capture the FTP signon event. Based on this
event, use the Exit Program to write or update physical file
record containing the user profile and the date & time of
signon. Your automatic user profile delete program should then
check two places instead of one: the user profile last used date
and time and the last access date and time in the file you wrote
to or update to with the FTP exit program.FTP Exit programs will
accept and return the the following parameters:
- Application
ID (FTP Client for example)
- Operation ID (Sending a file for
examle)
- User Profile
- Remote IP address
- Length of
remote IP address
- Operation
- Length of operation
-
Allow Operation (this value when returned, will determine if the
operation will be allowed or not) A good example of an exit
program, written by Alex Garrison, can be found on this site in
the Downloads
area of this website.- WRKREGINF
displays a list of the various
system exit points- The exit point for FTP is QIBMQTMF_SVR_LOGON.
This is where you specify a user-built program that is called
every time a user tries to logon to your AS/400 via FTP. Note: there
is a API on the system that will allow a change to
the signon date and time to current. It is QSYCHGPR.
This API can be called from the exit program or imbedded in the
QUOTE
RCMD command
command if you are executing one within FTP. Thanks for your help,
Jim
Go
Back to the Top
|
|
Regarding
an FTP QUOTE operation to a target system which works from one
location but not from the other,
Ricky from Arkansas asks:I
am trying to help an associate figure out why he can't issue the
QUOTE subcommand from an ftp session on his AS/400 when I can do
it from my AS/400.
The problem goes like this: I, in Arkansas,
can FTP a file to a client in Kentucky and then issue "QUOTE
RCMD CALL LIBNAME/PGMNAME" and
have it execute successfully.
When my associate, in New
Jersey, FTP's a file to the same client in Kentucky (logged in
with the same user name as me) his QUOTE
statement
always fails.
The log file always lists reply code 500
"Syntax error; command unrecognized."
Any suggestions you might have
into this matter will be greatly appreciated. Response:
My first observation is that since
you use the same user profile, the only difference between you and
your New Jersey colleague is the origin from which you come do
enter your Kentucky client's system. You obviously connect from
different IP addresses.If anything is right, your client probably
has (at least, one does not exclude an other) one of the following
3 IP protection tools running on their network:
- an external
firewall
- an AS/400 IP security software system, such as
PowerTech PowerLock
- an AS/400 home-grown exit program I
cannot talk about all firewalls, but certainly, I can tell you
about what AS/400 FTP exit programs can do. These exit programs
can accept 7 different parameters to decide if they want to block
a command. Conceivably, they can block an FTP command such as
QUOTE, based on, amongst other things, the remote IP address. FTP
Exit programs will accept and return the the following
parameters:FTP Exit programs will accept and return the the
following parameters:
- Application ID (FTP Client for example)
- Operation ID (Sending a file for example)
- User Profile
- Remote IP address
- Length of remote IP address
-
Operation
- Length of operation
- Allow Operation (this
value when returned, will determine if the operation will be
allowed or not) Knowing this, it is conceivable that your client
has opened up your Kansas Location FTP access in either their
firewall or their AS/400 controls with some rules based on remote
IP address. I suspect strongly that they have not granted the
EXACT SAME privileges to your New Jersey colleague as they have to
you in Arkansas. This would explain why the New Jersey requests
are rejected. They are rejected on the basis of "where does
the command come from?".
The error message, saying
"Syntax error; command unrecognized." to me is a bit of
a red herring. AS/400 FTP error messages, in my experience, are
not always meaningful and sometimes they are downright misleading.
I would ask your client's network administrator and AS/400 TCP/IP
administrator what actions they took to open their system to
you-in-Arkansas, and how they would differ with how they opened
the connection to you-in-New-Jersey. They may say the openings are
identical, but I would question that, based on what you told me.
Give me some news on this if you are successful, this is a very
interesting problem. Thanks, Thibault. Confirmation
from Ricky: Thank
you for your quick reply and thoughts. You were correct in the
suggestion that a firewall was involved, however the problem
wasn't at Kentucky but at New Jersey. Within the software on New
Jersey's LAN server, you had to specifically enter in acceptable
FTP subcommands that were allowed and of course the QUOTE command
wasn't there. Once added, everything fell into place. Thanks again
for your help.
Yours truly, Ricky
Go
Back to the Top
|
|
On
how to override the FTP default port of communication on
iSeries,
Monlisa,
of Toronto, asks: I
have a HK partner giving me the IP address as '111.222.133.114'
. When
using a standard FTP command on the iSeries, it will automatically
routes the transmission to through port
21.
Our
partner however, asked me to use port
2888 rather
than port
21.
How
can I redirect FTP to use an other port?
Can I specify during
the initial ftp command ? Response:
I did not find the answer to this
question, but Monlisa did get it from IBM's Technical Services.
The answer is YES to both questions above. The
solution : The
solution is to FTP to either an IP address, or a named server,
followed by a blank character and then by the port number.
Here
is an example of the command and the resulting response from an
FTP example where the FTP client who is issuing the command wants
to communicate on Port 2888:
FTP request from the local
system:
FTP
RMTSYS('111.222.133.114 2888')
FTP
response from the remote system:
Connecting
to remote host 111.222.133.114 using port 2888.
220 hksvr005
Microsoft FTP Service (Version 4.0).Note:
The example above shows an IP address, a www address can be used
also, if it is an FTP host. The command would then look like:
FTP
RMTSYS('www.example.net 1777')
Go
Back to the Top
|
|
On
how to export an iSeries type DB2 file to Microsoft Excel,
Sylvia,
of Calgary, asks: I
have a file with a mixture of character, packed and zoned fields,
some with positive, some with negative values. What would be the
most efficient way to export these to a Microsoft Excel
spreadsheet?Response:
The
first challenge in this situation is to unpack the numeric data so
that it can be translated from EBCDIC to ASCII, and to keep the
signs also.
The second challenge is to insert some type of
delimiter between each field, so that EXCEL can see the boundaries
between fields when it does the import.
The
solution :
One
little known command on the standard iSeries operating system can
do this for you in one pass: CPYTOIMPFHere
is an example of how to use this command: CPYTOIMPF
FROMFILE(DB2FILE) TOFILE(IMPFILE) FLDDLM(';') RCDDLM(X'07')
In the example above, All records
of externally described file DB2FILE will be copied to import file
EXPFILE.
The packed fields will be unpacked, the zone fields will remain
zoned, and each field will be delimited by a ';'
character and
the record delimiter will be a X'07'.
Once you have the EXPFILE
created, you can conveniently FTP
it to a PC or to a Local Area Network drive as a
.txt
file, such as
IMPFILE.TXT.
From there, in its new unpacked, delimited and translated to ASCII
format, the resulting file (IMPFILE.TXT
in this example) can be
comfortably imported into an EXCEL sheet.
Go
Back to the Top
|
|
On
how to execute a command on a remote AS/400 using FTP,
Yvon,
of Montreal, asks: I
am trying to send command to my AS400 using the FTP.
I can do
CLRPFM
and other
IBM commands but when I do a CALL
RPG_PGM passing
with it a parameter, it does not do anything.
I have entered
the following command:
quote
rcmd call ftptestpgm 'testingparm'
Any
suggestions? The
solution : Regarding
your question on FTP, the rule of thumb is to write the command as
it will be understood by the AS/400. When you type
call
ftptestpgm 'testingparm'
on
a command line, it is actually parsed and formatted out into
something the system can understand:
CALL
PGM(FTPTESTPGM) PARM('testingparm')
This
parsing and formatting does not occur when you enter your command
on the FTP
QUOTE RCMD function.
To help you find what should be typed exactly, use the F4
function on the AS/400 command line, then use the F14 function key
to display the command string.
Copy and paste the string into
your FTP session and it should always be successful. The command
line in your script file would thus look like QUOTE
RCMD CALL PGM(FTPTESTPGM) PARM('TESTINGPARM')Note:
the FTP instructions and the call instructions are not
case-sensitive. The parameter, however is case-sensitive and
should be sent with the case formatting the program is expecting.
Go
Back to the Top
|
|
On
how to dynamically FTP Documents to iSeries Active Users
Will,
from Utah, wrote: "Do
you know of any way to dynamically retrieve the IP address of a
user's local PC in order to do an FTP to a local drive without
requiring the user to do the transfer manually, utilizing the FTP
program of the emulation software?
I would like to somehow
get the IP address and feed it as a parameter to a CL program
where I could then download a file to the PC which has been
previously created on the AS400. "Response:
1) Call the qusrjobi
API to retrieve the IP address of
your customer. If the job is
still active (the API does tell
you if that is the case or not)
2) Using that information,
you can use an RPG or COBOL or C program to
customize an INPUT
file where it would connect to the IP address just found.
3)
You run that INPUT file (see FTP Automation
article example and technique to use for batch FTP) and monitor
for results. Note:
The QUSRJOBI
API program,
"Retrieve Job Information", part of iSeries's WORK
MANAGEMENT APIs, can retreive the Client IP address in its
JOBI0600 format. (search for "API finder" in the IBM
iSeries Information Center to get the specs).
Go
Back to the Top
|
|
Regarding
Reliable FTP CLIENT on PC SERVER,
Jeff, from
Chicago, wrote: I'm
wondering if you could point me in the right direction on a
problem I'm currently having with the AS/400 FTP client? I
am using the WAR FTP Daemon on my PC. Using the AS/400 FTP
client, I can GET files from my PC to the 400, but when I try to
PUT a file, nothing happens. An empty shell of the file is created
on the PC, but no data transfer takes place. The
WAR FTP Daemon responds with: 227
Entering Passive Mode (nn,n,n,nnn,n,nn)
125 Ready
to receive "my-file-name" . Mode Stream Type Ascii
This is all that happens - no
data gets transferred. Ultimately, my goal is to automate PUTting
Domino/Notes
files from the AS/400 to my Network. Can you help me?
Response:
As far as WAR
FTP, did you study
the possible settings in the manual (assumed) supplied with the
software? Perhaps the answer is simpler than you would think.
I had very reliable and consistent
success with an FTP software package for Windows called WS_FTP
Server, by IPswitch. IPswitch has
a website at http://www.ipswitch.com/.
You can order the product and download the manuals on-line.
Jeff wrote:
Thanks for your help -- I found my
problem. It was with the PASV
subcommand. I needed to turn
it off. Everything seems to be working now.
I am writing
from a suburb of Chicago.Additional Note: For best understanding
of Active/Passive FTP, go to Active
FTP vs. Passive FTP, a Definitive Explanation.
This is an excellent page, explaining exactly how FTP behaves in
Active mode vs. Passive mode.
Go
Back to the Top
|
|
On
ways to use FTP to connect to a remote server with the intention
to manipulate data, Daniel from Orange County, California wrote: I
work with for a company who owns several systems, amongst which
there are AS/400. I can FTP from/to these systems but no DDM is
allowed. Would there be a way to manipulate data on a remote
system using FTP? Answer:One
other indirect way to do manipulate data in batch, may be to use
the FTP instruction "QUOTE", which lets you run a
program remotely on the remote box you are communicating with. If
for example, you are on AS400A, and you have program AAAAA on that
box, but you would want to run it on AS400_B. The steps to follow
to do this with FTP would be:
1) Use SAVOBJ to save your
program into a save file (SAVF)
2) Use FTP to send it in
binary mode to AS400B (there are examples of that in the Tylogix
FTP FAQ)
3) Run program AAAAA on AS400B, while you are on
AS400A, using FTP instruction "QUOTE" to send the
instruction to run the program remotely. As an other solution, if
you have an ODBC access to these remote boxes, you may be able to
connect with an ODBC-enabled software (even Microsoft XL will do
that) and retrieve data that way. I do not know of any iSeries
equivalent
of Oracle's TOAD (available on the Internet at
www.toadsoft.com/)
to do that more directly. A third solution would be to use SQL
directly. With SQL on AS/400, you can actually connect to a remote
system on your network and issue SQL commands that will be
executed directly on the remote database (see "How to
maipulate data on a remote system" in the Tylogix
SQL Page page.
Go
Back to the Top
|
|
On
ways to secure FTP transmissions, John, from Massachusetts, wrote:
Is it
possible to do Secure FTP connections using RPG on an AS/400?
If
so, do you have any web resources with RPG programming
info?Answer:The
best article on this topic, currently on the Web (as of September
2003) is at
V5R2
FTP Security Enhancements, by Andrew Borts.
Go
Back to the Top
|
|
On
how to transmit data in a stream format, Eddie, from Georgia
asked:I
have a problem that I cannot find the answer to. I
have a file on the AS/400 that I FTP to our server for EDI. The
EDI data is then sent to a large customer. Our customer said they
are receiving it "blocked" and NOT a continuous stream
of data. I tried the STRUCT F when sending the file to the FTP
server but it still shows up in the same format as it was stored
on the AS/400 ie. record, record, record etc. Is there any way to
send a file FROM the AS/400 that will arrive and appear in the
folder as one contiguous stream of data? Answer:The
trick is to first copy your data file into the IFS (Integrated
File System)
CRTDIR
DIR(transmitdirectory) /* Create Directory on the IFS */CPYTOIMPF
FROMFILE(MYLIB/MYFILE)
+
TOSTMF('/TRANSMITDIRECTORY/CUSTOMERFILE.TXT')
/* Copy file to IFS */
MBROPT(*REPLACE)
RCDDLM(*CR) DTAFMT(*FIXED) Note:
***
The command parameter RCDDLM(*CR)
to define a carriage return
***
The command parameter DTAFMT(*FIXED)
is necessary to compress out the
blanks trailing the actual field data. In the FTP command set, you
then need to use NAMEFMT 1 to tell FTP on the iSeries to address
the IFS: NAMEFMT
1
ASCII
PUT
/transmitdirectory/customerfile.txt
/remotedirectory/customerfile.txt
QUIT
Go
Back to the Top
|
|
On
how to transmit database files which happen to have NULL values,
Steve, from Alberta asked:I
have a problem that I cannot find the answer to. I
have a file on the AS/400 that I FTP to our server for EDI. The
EDI data is then sent to a large customer. Our customer said they
are receiving it "blocked" and NOT a continuous stream
of data. I tried the STRUCT F when sending the file to the FTP
server but it still shows up in the same format as it was stored
on the AS/400 ie. record, record, record etc. Is there any way to
send a file FROM the AS/400 that will arrive and appear in the
folder as one contiguous stream of data? Answer:
Use the
NULLFLDS FTP keyword. It can instruct FTP to allow or not allow
transmission of database files containing NULL fields.here is the
syntax:
NULLFLDS [ 0 | 1 ]
When you
enter a parameter the valid values are:
0 Do not allow
transfer of database files that contain NULL fields. This is the
default.
1 Allow transfer of database files that contain NULL
fields.
Go
Back to the Top
|
|
On
how to receive stream files using FTP on iSeries, Ann, from
Germany asked:
Is there a way to process/cut
endless stream files received via FTP because we can only process
files with specific length example 80 characters?
Is
there any way to send a file FROM the AS/400 that will arrive and
appear in the folder as one contiguous stream of data? Ann
found the answer herself and graciously shares it :
1. Our partner sends endless
stream files. (that's default, we can't do anything against this
unless they will put carriage return as delimiter)
2. We fetch
it and save in the directory in AS/400 and NOT to a normal
physical file. (CRTDIR to create directory)
3. Then from the
directory, we used CPYFRMSTMF command to copy the records to a
source physical file having the length we prefer (example 225
characters).
4. From that source pf, we copy the records to the
NORMAL physical file (with fields) and convert it to data.
5.
Then, the data/records are ready for processing. (Finish..)
It's
easy now since we have so many possibilities in AS/400 and that's
the good thing in this.
Go
Back to the Top
|
|
On
how to monitor TCP/IP traffic at a low level
Is there a way to see the exact
FTP traffic at a low level?
Answer:
There
are several free TCP/IP packet sniffers available for download on
the Internet. They can be used to effectively monitor traffic
between two points in a network.
A
number of packet sniffers can be found at this address
http://www.tech-faq.com/packet-sniffer.shtml
Go
Back to the Top
|
|
On
how to monitor launch a job on a remote system from the iSeries
Bob asked: Is it possible to
issue a command from the AS/400 that would invoke a script or
batch file on a remote system?
Answer:
There
I have two methods that you may want to look at:
1) Using
FTP, you can create a script that will do
USER
user
PASSWORD
password
QUOTE
command
to call
QUIT
and
you can monitor for the results.
2)
You may want to try the following command:
RUNRMTCMD
CMD('D:\batfiles\runyourjob.bat')
RMTLOCNAME('111.111.111.111
' *IP)
RMTUSER
(yourusername)
RMTPWD
('Your_remote_Password')
A number of
packet sniffers can be found at this address
http://www.tech-faq.com/packet-sniffer.shtml
Go
Back to the Top
|
|
On
how to access the IFS:
The easiest way to access the
contents of the IFS is
dspf '/'
to display the IFS root
path
WRKLNK IFS
to explore the IFS
Go
Back to the Top
|
|
On how
to launch a process on a remote system:
This
is a relatively simple command, but one has to know. Using the IP
address, the user profile and the password for the remote server,
one can launch a process very easily, provided the firewall and
privileges are configured to allow this type of action.
RUNRMTCMD
CMD('c:\ftpbatfiles\run_procedure.bat')
RMTLOCNAME('122.121.123.321' *IP) RMTUSER(USERNAME)
RMTPWD('PASSWORD')
Go
Back to the Top
|