Couldn't get handle: Failure

[dabills]

We intermittently get the Couldn't get handle: Failure message when trying to 'get all //file.mvs.name' after sending a file to a remote JES2 system.

Here are the commands we issue on the source side:
lzopts servercp=$servercp,clientcp=$clientcp
lzopts mode=binary
ls /+mode=binary
ls /+space=trk.301.301
ls /+dsorg=PS,recfm=FB,lrecl=1024,blksize=6144
Put //SFTP.UNLOAD.D130202.T2042315 \
//SFTP.RELOAD.D130202.T2042315
ls /+space=trk.1.1
ls /+mode=text
cd //-jes.intrdr
ls /+jesjobwait
Put //SFTP.LOADJCL.D130202.T2042315 \
MYJOB
ls -al
cd MYJOB
lzopts mode=text,dsorg=PS,recfm=VB,lrecl=133,blksize=0
get all //SFTP.FTPRPT.D130202.T2042315
quit

Here is the output from the get all command:
cozsftp> get all //SFTP.FTPRPT.D130202.T2042315
Fetching //-JES.INTRDR.MYJOB/all to //SFTP.FTPRPT.D130202.T2042315
Ý23.179¨ Couldn't get handle: Failure

Here are the messages from the remote side at the end of the error.log:
ZosDatasetÝI¨: Opening JES spool dataset -JES.INTRDR.MYJOB.ALL for read
DatasetHandlerÝT¨: -> open()
DatasetHandlerÝT¨: -> openSpoolFile(dsn="
ß.µ.SÛ}
ߢ&.ÿDØ
ìEì", lrecl=16318, recfm=0x00)
DatasetHandlerÝE¨: openSpoolFile svc99() rc=4 error=0x0478, info=0x0000 dsn="
ß.µ.SÛ}
ߢ&.ÿDØ
ìEì"
DatasetHandlerÝT¨: <- openSpoolFile()
DatasetHandlerÝT¨: <- open()
DatasetHandlerÝE¨: Dataset
ß.µ.SÛ}
ߢ&.ÿDØ
ìEì open error: EDC5000I No error occurred. (errno2=0xC4070044)
DatasetHandlerÝE¨: __amrc last_op=604, error=0x5620062, msg=
ZosDatasetÝT¨: <- open()
DatasetHandlerÝT¨: -> close()
DatasetHandlerÝT¨: <- close()
Ý23.179¨ debug3: request 32: sent status 4
Ý23.179¨ sent status Failure
Ý23.186¨ debug1: read eof
Ý23.186¨ session closed for local user .....

Any ideas how to get around the issue?

[dovetail]

There appears to be some system error dynamically allocating the JES Spool dataset:

(S99ERROR = 478
(1144)
Corresponding Message: No corresponding dynamic allocation message
Meaning: Unable to process job entry subsystem request. (dsname
allocation, unallocation)
System Programmer Action: If the problem recurs, search problem
reporting data bases for a fix for the problem. If no fix exists, contact the
IBM Support Center. The S99INFO field may contain an internal
informational code which can be reported to the IBM Support Center.

I have seen this error before, and at that time it had to do with the spool file being in the process of being purged.
You might check syslog to see if this could be the cause.

You might try adding this:

export _BPXK_JOBLOG=STDERR

to cozsftp_server.rc (either in /etc or in ther user's $HOME/.ssh)
This will cause any "joblog" messages to be written to stderr, which end up in the error.log file.

[dabills]

I checked the system log and did not see a purge of the spool file and it's actually still available to look at. I also noticed that the attempt to get the spool file appears to occur 2 seconds after the job actually ends. I was thinking that was related to the /+jesjobwait setting (60.2) but wasn't exactly sure.

I compared the error.log messages for the one that failed and one that worked and it appears the dsn parameter for the openSpoolFile is empty for the one that fails but contains a dataset for the one that works:
DatasetHandlerÝT¨: -> openSpoolFile(dsn="userid.jobname.jobid.D....
as opposed to
DatasetHandlerÝT¨: -> openSpoolFile(dsn="
ß.µ.SÛ}
ߢ&.ÿDØ

I wonder if this is a bug in JES2 or something I should report to IBM support?

We don't normally collect error.log information unless we are debugging an error. If we were to use
export _BPXK_JOBLOG=STDERR

Would we do a 'get /+error.log' instead of the 'get all //SFTP.FTPRPT.D130202.T2042315'?
Would that get command wait for the job to end or for whatever time limit is coded in the jesjobwait settings?

[dovetail]

I agree that something wrong seems to be happening in the code that interfaces with spool files.

If you can reproduce the problem, please try doing so with the following option:

ls /+loglevel=D.SpoolStatus=F
(before your get command)

this will cause some detailed tracing information to be written to the sftp-server log file (/+error.log).
If you are able to capture the failure with this trace on, please forward it to info@dovetail.com and we will take a look.

Thanks for reporting this.

[dabills]

I was able to capture the /+error.log files for a successful transmission and a failed transmission. I sent the log files to the email you posted. Let me know if you need more information.

[atrivino]

I am not experiencing an issue like the one of this post. But what is the requirements for getting a dataset to be in a particular format?
User is uses lzopts recfm=vb,notrim when performing a get from a linux box to the mainframe. It shows up as a Undefined format dataset on the mainframe. Any Insight?

[dovetail]

It sounds like this a a Co:Z SFTP client running in a batch job?

If so, enable tracing before the get and look at the log to see what is happening:

lzopts loglevel=T