Support MC Press - Vist Our Sponsors

 

Forums Sponsor

Popular Forums

POPULAR FORUMS Unable to create java virtual machine on V7R1 (805 views) RUNRMTCMD to Windows Server 2008 R2 (613 views) Fixed header table plugins (578 views) AIRLIB Objects Work on V7R1? (550 views) CL to monitor job queue and release jobs (488 views) PDF Colors and Fonts - Do these changes apply only to Paragraphs? (471 views) Password-Protect PDF in the IFS (371 views) CL to monitor job queue and release jobs (351 views) 35 free gem-quality diamonds (245 views) Print Bar Graph from RPG (243 views)

Forums

 

Search Sponsor

  

Popular Searches

Search

Now that you have the newfound capabilities of mapping network drives to and from the IBM i, as mentioned in my previous tips, you may see some new possibilities by providing alternatives to data transfers. But you will also run into some new challenges, such as authorization issues of unsynchronized user IDs and passwords between the Windows world and the IBM i. This TechTip will provide possible implementation methods for both topics with the copy (cp) and move (mv) utilities in the IBM i UNIX environment Qshell.

Typically, with the utilities available in Qshell, you can type the command with no specified parameters and you will be provided with a list of options. Here are the results for each when you execute the cp and mv commands in Qshell with no parameters:

Command Line Syntax

To copy files in QShell, you can use the standard UNIX command cp.

cp [-r | -R [-H | -L | -P] ] [-fhipt] source_file target_file

cp [-r | -R [-H | -L | -P] ] [-fhipt] source_file ... target_directory

To move files in QShell, you can use the standard UNIX command mv.

mv [-f | -i] source_file target_file

mv [-f | -i] source_file ... target_dir

There are multiple options available for the utilities discussed. To simplify the tip, I have chosen to use the default functionality of the utilities by not specifying any of the available options, but I wanted you to be aware that they exist.

Providing an Alternative to iSeries Access Data Transfer

In the past, one common method for retrieving data from the AS/400 was to install Client Access onto the client's PC and set up a data transfer to download the data. Now that you have the IFS, you can put the data onto the IFS, provide a share to the IFS location, and have the client map a network drive to the share to access the file.

But what about those more difficult clients? What about those older Macintosh computers that require AppleTalk to access network-accessible file systems? Or what about remote sites that have PCs on their network that are permitted only limited access to the network because of security limitations? Or what about the simple consideration of cost? DASD is expensive! I don't want every user under the sun to be storing stuff on and accessing my highly secure and stable iSeries, when such quality is excessive. Here is where the cp and mv utilities save the day.

You can take a relatively inexpensive Windows, Linux, or Macintosh box, set it up with relaxed authorization and all of the specialized access support on the local network, and make it accessible to your IBM i but not provide access from the IBM i. Then you can copy the files from the IBM i to the file server by mapping a network drive from the IBM i to the file server and copying the files to the file server.

Overcoming Authorization Issues

You have valuable data that you do not want to host on your IBM i either because you've opted not to or you simply can't. So you decide to set up an inexpensive server to support this capability and you copy the files from the IBM i to a dedicated server to support this purpose.

Now you may start running into headaches, because if you were to have this functionality triggered interactively by the user, then the copy/move command will be executed by the user that is signed onto the session and you'll need to have access to the target server. This could lead to some undesirable administration to ensure that the multiple systems have synchronized user IDs and passwords.

To overcome this issue, you can have a subset of IBM i users (which may consist of only one user: QSYSOPR) that has access to the remote servers and have the copy/move commands automatically executed on a regular basis by the specified user(s) to refresh the data. Depending upon how dynamic the data being provided is, you could have the copy/move command executed either daily or every minute using an automated process in batch.

The Code

Suppose you have files that are being generated on the IFS and you want to deliver them to a file server on the network. Then, after the files have been delivered, you want to move them into an archive folder so that you can retrieve them if any errors occur (you'll also have them out of the way so the files are not processed again the next time the program is run). Here's the program to do that:

F**********************************************************************                            

F* NOTE: IF YOU ARE RUNNING THIS IN BATCH, YOU NEED TO RUN IT IN A                                 

F*       JOBQ THAT HAS MAXJOBS SET TO *NOMAX TO SUPPORT QSHELL                                     

F*       WHICH SPAWNS MULTIPLE JOBS TO RUN CONCURRENTLY. F**********************************************************************                            

D STRING         S           1000A    

D SOURCE         S           1000A

D TARGET         S           1000A

D*

C/EJECT

C* COPY THE FILES FROM THE IBM I TO A NETWORK ACCESSIBLE FILE SERVER                               

C                   EXSR      CP_NET_DRIVE

C* MOVE THE FILES INTO AN ARCHIVE FOLDER   

C                   EXSR      MV_ARCHIVE

C*

C                   EVAL      *INLR = *ON

C/EJECT

C**********************************************************************                            

C* SUBROUTINE: CP_NET_DRIVE

C* FUNCTION:   EXECUTES HARD-CODED CP COMMANDS IN QSHELL                                            

C*             WILL COPY FILES TO A NETWORK DRIVE

C* THE SOURCE DIRECTORY WILL BE:

C*     THE /Public/input DIRECTORY OFF OF THE ROOT OF THE IFS.                                   

C* THE TARGET DIRECTORY WILL BE:

C*   - THE output DIRECTORY OF THE SHARE ON A WINDOWS SERVER ON THE NETWORK                        

C*   - THIS NETWORK DRIVE MUST BE MAPPED PRIOR TO USAGE WITH 'MKDIR'

C**********************************************************************                            

C     CP_NET_DRIVE  BEGSR

C                   EVAL      SOURCE = '/Public/input/'

C                   EVAL      TARGET = '/QNTC/10.10.10.1/output'

C*  CREATE THE QSHELL COMMAND STRING AND EXECUTE IT

C                   EVAL      STRING = 'STRQSH CMD('

C                                    + '''cp '

C                                    + %TRIM(SOURCE)

C                                    + '* '

C                                    + %TRIM(TARGET)

C                                    + ''')'

C                   Z-ADD     1000          CMDLEN

C                   CALL      'QCMDEXC'

C                   PARM                    STRING

C                   PARM                    CMDLEN           15 5

C                   ENDSR

C/EJECT

C**********************************************************************                            

C* SUBROUTINE: MV_ARCHIVE

C* FUNCTION:   EXECUTES HARD-CODED MV COMMANDS IN QSHELL                                           

C*             WILL MOVE FILES TO AN ARCHIVE FOLDER

C* THE SOURCE DIRECTORY WILL BE:

C*     THE /Public/input DIRECTORY ON THE IFS.                                   

C* THE TARGET DIRECTORY WILL BE:

C*     THE /Public/archive DIRECTORY ON THE IFS.                                   

C**********************************************************************                            

C     MV_ARCHIVE    BEGSR

C                   EVAL      SOURCE = '/Public/input/'

C                   EVAL      TARGET = '/Public/archive/'

C*  CREATE THE QSHELL COMMAND STRING AND EXECUTE IT

C                   EVAL      STRING = 'STRQSH CMD('

C                                    + '''mv '

C                                    + %TRIM(SOURCE)

C                                    + '* '

C                                    + %TRIM(TARGET) + ''')'

C                   Z-ADD     1000          CMDLEN

C                   CALL      'QCMDEXC'

C                   PARM                    STRING

C                   PARM                    CMDLEN           15 5

C                   ENDSR

There a few comments I'd like to make about this program:

•·      If you are going to run it in batch, you must send it to a JOBQ that has the MAXJOBS set > 1. I typically set up a JOBQ with MAXJOBS set to *NOMAX.

•·      You must have the network drive set up from the IBM i to the file server prior to copying the files to it with the MKDIR command.

•·      There may be a timing issue with this program if there are files copied into the input folder between the execution of the cp and the mv commands because the cp command could copy two files to the target and a third file could slide in before the mv command gets executed. Then the three files will be archived using the mv command but never copied to the intended target. You can prevent this by moving the files to an intermediate folder first to provide a snapshot. Then you copy to the network drive and perform the archiving from the intermediate folder. You could also come up with other creative solutions, but I didn't want to complicate the code.

In conclusion, I have talked about some reasons you would not want to use the IFS to support network drives to users. But there are some very logical reasons that you would. When security, archiving, and reliability are paramount, providing IFS access is the solution.