BPXWDYN error writing to JES2 intrdr

[dabills]

We are running version 2.0.1 and are not able to submit a file to the JES2 internal reader because of the following error:
BPXWDYN allocation failed RC=-330, keyword number 310 was in error

We are doing the following in the SFTP client:
ls /+mode=text,writer=intrdr,lrecl=80,recfm=f
cd //-jes.intrdr
put //file.name MYJOB1

Do you have any idea what BPXWDYN keyword number 310 is and why it's in error?

Here is a snapshot of the +error.log:
: -> checkCommandWithFileArg(STOR //-JES.INTRDR.MYJOB1)
: <- checkCommandWithFileArg(true (module not available))
pen("//-JES.INTRDR.MYJOB1", 0x0091, 0x01B6)
-> setJobAlias(MYJOB1)
<- setJobAlias()
SYSOUT allocation enabled; DSN= is ignored
-> setDSN(-JES.INTRDR.MYJOB1)
<- setDSN(effectiveDSN=INTRDR)
ing dataset -JES.INTRDR.MYJOB1 for write with options: sysout writer(intrdr) recfm(f) lrecl(80) blksize(0) lrecl(80) recfm(f) writer(INTRDR)
-> open()
BPXWDYN allocation failed RC=-330, keyword number 310 was in error
BPXWDYN command was: "alloc fi(SYS00008) reuse msg(2) sysout writer(intrdr) recfm(f) lrecl(80) blksize(0) lrecl(80) recfm(f) writer(INTRDR)"

[dovetail]

Try submitting your job like this example:
http://dovetail.com/docs/sftp/using.htm ... jes_submit

Also, it appears that your SFTP client is a z/OS Co:Z system? (since your source file on the put command was a dataset?).
If so, then you may also want to add:

lzopts mode=text

So that the client is in text mode to match.

[dabills]

That is the document I already looked at when I built the SFTP which is why I did these commands:
ls /+mode=text,writer=intrdr,lrecl=80,recfm=f
cd //-jes.intrdr
put //file.name MYJOB1

I also am already using lzopt mode=text as well.

Also, I tried the same thing using psftp from a windows machine and I get the exact same BPXWDYN error. I wonder if this is just an issue with V2.0.1?

[dovetail]

I'm not sure what you are referring to.
It is not compatible to use writer=intrdr (which is a sysout keyword) with using the //-jes.intrdr pseudo-directory.
Also, there is a known bug that prevents you from setting lrecl or recfm when submitting jcl to //-jes.intrdr. This will be fixed in a future release. The default is lrecl=80,recfm=f and these can be overridden using the separate settings: jeslrecl and jesrecfm.

But, have you tried this? -

Code: Select all

ls /+mode=text
cd //-jes
put some.local.file MYJOB1

Also, I still don't understand how you are using "//file.name" as your local file name unless you are using a Co:Z SFTP z/OS client to a Co:Z SFTP z/OS server.

[dabills]

I originally was trying to validate using co:z SFTP client to co:z SFTP server, but I am now just trying to validate using the Windows psftp cleint program. That being said, I tried what you suggested and I get the following error now:
-> open("//-JES.MUJOB", 0x0091, 0x01B6)
open failed: "-JES.MUJOB" JES spool file cannot be opened for output

I then tried:
ls /+mode=text
cd //-JES.INTRDR
put sftpjcl.txt MUJOB

and I got the same dynamic allocation errro as before:
ceÝT¨: -> checkCommandWithFileArg(LIST //-JES.INTRDR)
ceÝT¨: <- checkCommandWithFileArg(true (module not available))
open(-JES.INTRDR)
open(true)
ceÝT¨: -> checkCommandWithFileArg(STOR //-JES.INTRDR.MYJOB1)
ceÝT¨: <- checkCommandWithFileArg(true (module not available))
-> open("//-JES.INTRDR.MYJOB1", 0x0091, 0x01B6)
ÝT¨: -> setJobAlias(MYJOB1)
ÝT¨: <- setJobAlias()
ÝT¨: SYSOUT allocation enabled; DSN= is ignored
ÝT¨: -> setDSN(-JES.INTRDR.MYJOB1)
ÝT¨: <- setDSN(effectiveDSN=INTRDR)
Opening dataset -JES.INTRDR.MYJOB1 for write with options: sysout writer(intrdr
ÝT¨: -> open()
ÝE¨: BPXWDYN allocation failed RC=-330, keyword number 310 was in error
ÝE¨: BPXWDYN command was: "alloc fi(SYS00008) reuse msg(2) sysout writer(intrdr)

I am going to try the same thing using the v1.9.0 of Co:Z to see if it works with the older version. Not sure really what else to try at this point because I am not sure what the dynamic allocation keyword is that it's complaining about.

[dabills]

I get the same BPXWDYN error using Co:Z v1.9.0 also. In looking more closely at the BPXWDYN command and the rules associated with the keywords, do you think the issue is because there are duplicate keywords being used on alloc command? Once of the keyword rules is "The ordering of keywords on the request is arbitrary. You cannot specify the same
keys multiple times for one request."

Based on that rule, it appears the alloc request is sending duplicate keywords for lrecl, blksize and recfm. Is there some way to prevent that from occuring?

[dabills]

Ok, so I think I figured out why it's adding the other keywords to BPXWDYN. It will add keywords if we use a default cozsftp_server_config file. When I remove the cozsftp_server_config file before connecting, the put to the JES internal reader works and the BPXWDYN alloc doesn't have extra keywords.

Here is what is in the default cozsftp_server_config file:
# Default section
default:
# Specify default
lrecl=256
blksize=0
recfm=fb
dsorg=ps
space=trk.5.5
conddisp=catlg
mount

With this file, the following keywords get duplicated in the BPXWDYN alloc command: lrecl, recfm and sysout (not really sure why sysout is being duplicated but it is).

[dabills]

Is there some way to keep a default cozsftp_server_config file and not have SFTP insert duplicate keywords?

[dovetail]

As I said before, there is a bug - if you have lrecl or blksize set and try to submit to //-jes.intrdr, then there will be a problem. It doesn't matter whether these options are set interactively or via the configuration file.

We will be fixing this problem in the next release.

As a workaround, you can unset these options using the following command before doing a put to //-jes.intrdr

Code: Select all

ls /+nolrecl,norecfm,noblksize

[dabills]

Adding ls /+nolrecl,norecfm,noblksize prior to the PUT command fixed the issue.

I assume we will not "have" to remove that command once the fix is in place, correct? I'm assuming the fix won't care if we set nolrecl,norecfm,noblksize.

Any idea when or what release the fix might be in? We are planning on upgrading from 2.0.1 to 2.1.1 this fall (November) unless there is a newer relase before then.

[dovetail]

Correct, after we fix this issue you will not need to remove this command.

The new release is planned for sometime in the next 60 days.