Many thanks for your soon answer.

As I said we did two changes in the script. We put a line to evidence what was the last instruction done and we change exit by quit. Our interface is working well now.

Really I don’t know if the solution to the problem was to change exit by quit or to add a line before to quit in order to force the script to do something in the i-series machine when we have stablished the communication or the combination of both instructions working together fixed the problem.

Best regards,

Carlos Leiva

No useful information.

QUIT, EXIT and BYE are given as alternatives, and I can’t find descriptions that distinguish between them. I would use QUIT only because it is a FTP command and EXIT is too easy to confuse with common shell scripting.

I wouldn’t expect it to matter what the remote system is. I don’t think the command itself is sent. AFAIK, sftp signals a close of the connection rather than sends the command.

Tom

Yesterday we did two changes in the script. We put a line to evidence what was the last instruction done and we change exit by quit. Our interface is working well now. Do you have information related with recommendation to use quit instead of exit for V5R4M0 when the i-series machine in connecting using SFTP with a Linux machine?.

Really I don’t know if the solution to the problem was to change exit by quit or to add a line before to quit in order to force the script to do something in the i-series machine when we have stablished the communication or the combination of both instructions working together fixed the problem.

____________________________________________________________

cd datos/OUTBOUND
lcd /home/cltran/
rm TRANSTELCONTROL_20111111090040.TXT
cd BACKUP
put sftp204O.txt TRANSTELCONTROL_20111111090040.TXT
!touch /home/cltran/transtel/DLT_TRANSTELCONTROL_20111111090040.TXT
quit
quit
______________________________________________________________

Best regards,

Carlos

Please see below my answer.

Best Regards,

Carlos
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Visualizar estado PTF
Sistema: SCLSAN21
ID de producto . . . . . . . . . . . : 5733SC1
Origen de IPL . . . . . . . . . . . . : ÑÑMACHÑB
Release de la opción base . . . . . . : V5R4M0

Teclee opciones, pulse Intro.
5=Visualizar detalles de PTF 6=Imprimir carta de presentación
8=Visualizar carta de presentación

ID
de Acción
Opc PTF Estado de IPL
SI28273 Aplicado temporalmente Ninguno
SI25209 Aplicado temporalmente Ninguno
SI21018 Reemplazado Ninguno

Final
F3=Salir F11=Visualizar vista alternativa F17=Situar en F12=Cancelar

That’s a cume package that probably won’t include any PTFs for product 5733-SC1. To see PTFs for that product, run:

DSPPTF 5733SC1

Thanks.

Tom

Many thanks for your soon answer. My answers below in your mail.

Best regards,

Carlos Leiva
——————————————————————–
First question has to be what PTFs have you applied for 5733-SC1 on V5R4?
IBM i5/OS CUMULATIVE PTF
SF99540 Level 11137
PACKAGE ID: C1137540
VERSION 5 RELEASE 4.0

Then there are a couple questions about the script and how it’s run.

Why are you using ‘/QOpenSys/QIBM/ProdData/SC1/OpenSSH/openssh-3.5p1/bin/sftp’ instead of ‘/QOpenSys/usr/bin/sftp’ or even ‘/QOpenSys/bin/sftp’? You shouldn’t be directly going into the QIBM directory for this, although it should work, I suppose. My concern would be whether or not /QOpenSys/usr/bin is set up correctly.
We did that 2 years ago. The application run without problem during 8 months. Our problems started after the change of release.

And why do you have two exit lines in the script? Again, it should work, but you might have a reason that helps pin down the problem.
The second exit is redundant but no one runs neither the first exit or the second.

Also, the name of the file indicates that this is an automated script. You apparently have some programming that generates the script and puts new names into it. Have you compared scripts that work with ones that seem to hang?
Yes we did. We had another script but at the end point we have a Windows server instead a Linux server.

Have you compared them in hex to verify that working and non-working scripts always have the same characteristics?
No, I don’t know how to do it.

Without knowing how the script is created, I can’t guess what extra hex characters might be in there nor what they might do.

Also, you start with {cd datos/OUTBOUND} and then you remove a file from it. Then you switch to {cd BACKUP} and put a new file there. What if there is already a file with that name there?
The file is overwritten.

None of the lines in the script do any error testing (although sftp scripts are limited in what they can do; basically just decide whether to continue or not).

Finally, what does the CL do after returning from QP2TERM? Does it do any testing to see if there were problems? The job return code should be tested.
The CL tests the result of QP2SHELL but the problem is QP2SHELL sometimes doesn’t end.

That’s enough questions for now. The biggest one is simply about what PTFs have been applied for the product. None of the others are very important, just asked in case more info is available.

Tom

Then there are a couple questions about the script and how it’s run.

Why are you using ‘/QOpenSys/QIBM/ProdData/SC1/OpenSSH/openssh-3.5p1/bin/sftp’ instead of ‘/QOpenSys/usr/bin/sftp’ or even ‘/QOpenSys/bin/sftp’? You shouldn’t be directly going into the QIBM directory for this, although it should work, I suppose. My concern would be whether or not /QOpenSys/usr/bin is set up correctly.

And why do you have two exit lines in the script? Again, it should work, but you might have a reason that helps pin down the problem.

Also, the name of the file indicates that this is an automated script. You apparently have some programming that generates the script and puts new names into it. Have you compared scripts that work with ones that seem to hang? Have you compared them in hex to verify that working and non-working scripts always have the same characteristics? Without knowing how the script is created, I can’t guess what extra hex characters might be in there nor what they might do.

Also, you start with {cd datos/OUTBOUND} and then you remove a file from it. Then you switch to {cd BACKUP} and put a new file there. What if there is already a file with that name there? None of the lines in the script do any error testing (although sftp scripts are limited in what they can do; basically just decide whether to continue or not).

Finally, what does the CL do after returning from QP2TERM? Does it do any testing to see if there were problems? The job return code should be tested.

That’s enough questions for now. The biggest one is simply about what PTFs have been applied for the product. None of the others are very important, just asked in case more info is available.

Tom

Many thanks for your soon answers.

Our application worked during 8 months in V5R3M0. Nowadays we are in V5R4M0 and the application sometimes hangs and never ends. The application hungs in average three times a day.

The exact line that we are using in a CL program is:

CALL PGM(QP2SHELL) PARM(‘/QOpenSys/QIBM/ProdData/SC1/OpenSSH/ope-
nssh-3.5p1/bin/sftp’ ‘-b’ ‘/home/cltran/sftp204I.txt’ –
‘ftpshell@64.76.162.87′)

where sftp204I.txt is the script to be run. For example:

cd datos/OUTBOUND
lcd /home/cltran/
rm TRANSTELCONTROL_20111108184117.TXT
cd BACKUP
put sftp204O.txt TRANSTELCONTROL_20111108184117.TXT
exit
exit

The statement:

put sftp204O.txt TRANSTELCONTROL_20111108184117.TXT

is done but the application hungs and then the

exit

is never run.

Any help is welcome.

Best Regards,

Carlos Leiva

Please clarify if you are really using SFTP or if you are using sftp (or perhaps FTPS). They are all very different protocols (though many people nowadays will write “SFTP” for “sftp”, so that it’s almost taken over).

What exactly is the protocol?

Also, is this problem always happening now? Or does it sometimes work? If it always fails, I’d probably start by verifying that the CCSIDs are set appropriately for the system and for the script. Upgrading from V5R3 to V5R4 often requires correction of CCSIDs.

Tom

Maybe you were transferring your files in passive mode and now with the new iSeries version this transfer modes has changed.

Tell us more about the scenario to provide you more useful tips.
Here is a good article about ftp active and passive mode.

Regards.