Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Using rtopcb and listfile in batch file to automate data transfer

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Using rtopcb and listfile in batch file to automate data transfer

    Sorry, I forgot my HTML code. The listfile.txt is as follows: s:as400file1.tto s:as400file2.tto s:as400file3.tto s:as400file4.tto s:as400file5.tto s:as400file6.tto s:as400file7.tto s:as400file8.tto s:as400file9.tto

  • #2
    Using rtopcb and listfile in batch file to automate data transfer

    Another thing is that not only are these files ASCII but they are also fixed width. The default detail for ASCII files is to truncate spaces from end of records. Could this be the reason that the fields seem to be switched in file1? the field the file ends with is an amount field that always ends in the correct position. File2, file3 and file4 are the exact same layout as file1.

    Comment


    • #3
      Using rtopcb and listfile in batch file to automate data transfer

      Tracy, This sounds like a PTF problem. Are you on the latest Service Pack for your release? I would recommend converting them to the new transfer request as well. Bill Tracy Peters wrote: > Another thing is that not only are these files ASCII but they are > also fixed width. The default detail for ASCII files is to truncate > spaces from end of records. Could this be the reason that the fields > seem to be switched in file1? the field the file ends with is an > amount field that always ends in the correct position. > > File2, file3 and file4 are the exact same layout as file1.

      Comment


      • #4
        Using rtopcb and listfile in batch file to automate data transfer

        This is a different question than EDIguru has. I do not have CL access and will never have. For over a year we have been using the following batch file to automatically transfer several files daily with no problems. These files are all simple ASCII text files. This was on an NT 4.0 workstation with Client Access for 95/NT: call "s:as400logonu.bat" c: cdprogra~1ibmclient~1 rtopcb /s /f s:as400listfile.txt The listfile.txt is as follows: s:as400file1.tto s:as400file2.tto s:as400file3.tto s:as400file4.tto s:as400file5.tto s:as400file6.tto s:as400file7.tto s:as400file8.tto s:as400file9.tto We upgraded the NT workstation to Client Access Express V4R5M0. Everything ran fine for a while. Lately, sometimes but not always, the file1 is corrupted in that the fields are not in proper order. All other files are fine. It seemed that if you transfered the file1 again, it was fine. I changed the order of the listfile so that file1 transfered after file2 and file3. It worked for only a couple days. I then added file1 to transfer both first in the list and also fourth in the list. It worked for only a few days. Lately if the file1 is corrupted then we need to power off and then on the computer (a restart doesn't work). The transfer then works fine. My thought is that I will need to change all the .tto files to .dtf. Do you think it is as simple as that?

        Comment


        • #5
          Using rtopcb and listfile in batch file to automate data transfer

          Thanks Bill, I applied the latest SP and changed the .tto files to .dtf files. We'll see what happens. Which leads to another question. How does the version and SP level on the PC need to compare to what is on the AS/400? Express, check service level does not compare to the AS/400 like the 95/NT version did.

          Comment


          • #6
            Using rtopcb and listfile in batch file to automate data transfer

            Tracy Peters wrote: > Which leads to another question. How does the version and SP level on > the PC need to compare to what is on the AS/400? Express, check > service level does not compare to the AS/400 like the 95/NT version > did. Well, the old logic used to be that the CA release corresponded to the minimum release that could be installed on the 400. This meant you could install V5R1 onto your PC even if your 400 was still on V4R5. I believe this logic still holds, I just wouldn't want to work with different releases between my PC and 400. Bill

            Comment

            Working...
            X