IBM Mainframe Forum

Hello,

thank you, I think this was a good idea.

If I simply print out lines of the tape into the SYSOUT within my Java program, it works... So the more I try I think that the problem has something to do with the TSO-command "allocate" that I am using to define the SORTIN of DFSort in Java.

I found out, that the allocation of the tape with my actual used command never works, whatever I try...

I tried:




I cannot find anything about the syntax, I even do not know, if this is possible at all...
The error message I always get is:

Regards,

Oliver

What error codes/messages were you getting from the ALLOC? In general TSO does not allow one to allocate tape datasets but maybe your setup is different. One place to check is your TSO, or whatever, support group.

I have to agree with NicC and others. Most shops do not allow an online TSO session to "mount" (that's the official term) a tape. You do have other options.

• You can ask your shops management to allow "mount" authority for your ID. The exact mechanism depends on the security system used in your shop. This will probably not be granted.
• Another option that probably won't be allowed (and I'm not sure it would work in any event) is for operations to pre mount the tape volume using the MOUNT operator command before you run your Java application. This may not be possible if the dataset is located on a "virtual" tape volume.
• You can run your Java application through a TSO session in batch or by some other mechanism to run it in batch.
• If the tape dataset is not so large you can copy it to a regular disk dataset before you run your application. Of the multiple option I just proposed, this may be the simplest, at least to test your application.
• Run the sort program as a batch application with the SORTOUT defining a regular disk dataset, and do not perform the sort in your Java application. This solution reminds me of the shop where I worked through most of the 1970s. They had been a big 7080 (that's a high end 2nd generation mainframe) shop and were running a lot of their 7080 applications using the 7080 emulator in the IBM 370/165. The OS/360 sort program was so much better than the 7080 sort program they would break their 7080 job stream before the sort, run the sort using the OS/360 sort, and then resume the 7080 job stream using the sorted data. FWIW (and this if very off topic) the Syncsort product started by the OS/360 sort program as its base and improved it.

Hello,

I thank you all for you replies.
I will now simply use Java-based programming and not use DFSort for this project. I will ask our computing center for informations about authority matters.

But the problem I have regarding mounting with the ALLOC command does not (exclusively) have something to do with tape datasets.
The direct connection between a DD-statement and my Java DFSort does not work. If I use normal datasets I can only mount them when I resolve their "true" name.

If somebody knows the correct syntax for this, I would be very happy. If not, I simply avoid this problem and use another way.
So what I need:
JCL:

Allocated with ALLOC-Command:

where ????????? is some command like da(DATASET), not using the actual filename...

Thank you very much!

Regards,

Oliver

You are not making a whole lot of sense. would be allocated as and instead you are using SORTIN for some reason.

Second, if you don't provide the data set name, how do you expect the system to know which file you want to allocate? A typical mainframe system may have several hundred thousand data sets on disk and tape, and they are almost invariably referenced by the data set name. This is why the data set name is in the catalog. There are a few exceptions (BLP processing for a tape, for example) but they are almost always very closely controlled by sites since they allow for security problems if misused.

You could attempt dynamic allocation, but again for it you MUST know the data set name before you can allocate the data set.

A statement like

alloc fi(dataset) dsn(userid.example) shr

or

alloc file(dataset) dataset('userid.example') shr

is dynamic allocation. I've long thought one of the biggest goofs in TSO is the use of FILE(ddname) in the ALLOCATE command. I grant TSO now allows DDNAME(ddname) as an alternate for FILE(ddname). This was done long ago, possibly in OS/VS2 Release 1, but the use of FILE(ddname) continues to be used. I don't know if BPXWDYN (which is used to process the allocation in the initial posts) can use DDNAME(ddname) as an alternate for FILE(ddname). If it doesn't, it should. (After looking up the documentation in this link I see it takes DD(ddname)).

This is why I never use "file" as an alias for "dataset." A dataset has organization and attributes, where a file in Unix or a PC is just a glob of something.

no wonder that <it does not work>
where did You get the funny idea that

would result in a correct allocation
unless something has changed lately msg is not a valid ALLOC keyword/parameter/token

since You did not care to check the allocation return code, and just kept on
it is more than natural for SORT(or any invoked program) to complain for SORTIN(or any needed ddname) dd statement missing
a proper process would have checked the allocation return code, issued some message and exited nicely.

it would be useful for You to read and meditate on the manuals starting from
http://publibz.boulder.ibm.com/cgi-bin/ ... s/IKJ4BK90
not the latest ones but more than enough to get You acquainted with the ALLOC syntax and gotchas

I am not getting much answers in this forum regarding questions about java,

in this specific case the issue is not JAVA related
it is just a wrong understanding and parametrization of the ALLOC command

to let You concentrate better on JAVA issues
here is a link to the relevant page of the 1.12 tso/e manuals dealing with ALLOC
http://publibz.boulder.ibm.com/cgi-bin/ ... 4437&CASE=

Hello Enrico,

please do not think that I did not try to find the answers in the manuals you posted here. Unfortunately the documents did not help me.

The msg parameter was written in the Javadoc of the Java Dfsort classes.

Regards,

Oliver

after all it was You who said

So the more I try I think that the problem has something to do with the TSO-command "allocate" that I am using to define the SORTIN of DFSort in Java.

I was following Your hint in looking at the TSO ALLOCATION SYNTAX
You could have spared us some research if You had let us know that

available here
ftp://ftp.software.ibm.com/s390/zos/too ... xwdyn.html

under BPXWDIN the token MSG(2) is valid and it refers to a FILE DESCRIPTOR ...
the content of file descriptor 2, will tell why and if the allocation failed

if You are running a batch process and You are not able to identify the FD 2
use MSG(WTP) it will write the same to the job log!

anyway You have issues with Your allocation,
but since You have not posted the allocation errors we cannot tell anything about them

I TESTED under TSO
with MSG(2) the allocation messages are ethered
with MSG(WTP) the allocation messages appear on the log

but You get the messages only for real allocation mishaps
I just checked with a wrongly built command and all You get is a negative return code

still I ask... did You check the return code after the allocation ???
the code snippet You posted just seems ( repeat seems) to show that You did not

JAVA might suffer of the c/c++ stupidity syndromes,
but I guess that it should be able to provide return code handling