Thanks all (including someone in POK -- you know who you are -- thank you for
the background on SUBSYS).
I am regrouping. I have gotten the customer to agree to a de-prioritizing of
the problem, so it may be a little while before I tackle this.
I think I understand what is happening. Between my code, SVC 99 and FTP no one
is converting the alias to a true DSN, and so an OBTAIN on the VTOC of course
fails. The solution is presumably for me to recognize that it is an alias and
do the LOCATE (or whatever the right "conversion" macro is) myself.
I "get" that the DSN is just another field for SUBSYS, and that
DSN=MARY.HAD.A.LITTLE.LAMB,SUBSYS=XXXX would pass JCL, assuming only that
subsystem XXXX existed.
Thanks specifically for the CBT references. We will probably use one of those
in our testing so we are not flying totally on guesswork. We will indeed
probably build a simpler testcase.
@Steve, the OBTAIN is issued by LE on behalf of FTP. Why LE thinks
fopen("//DD:SYS00014") implies the need for an OBTAIN is beyond me. There is no
VOLSER in the SVC 99 so they are going to a lot of trouble to get to the
"right" (so to speak) VTOC.
When you are a vendor, there is no "proving you are not part of the problem."
The customer says "it works if we do it without your product, so if you want
the sale ..." In fact, if we (at the customer) allocate the alias and SUBSYS
with JCL DD then FTP works. Same JCL operands as the SVC 99. Go figure.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Smith
Sent: Wednesday, February 19, 2020 8:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to test SUBSYS=
There's also the "Control Card Subsystem (CCSS)" on I believe file 364 of
the CBT. It's about as simple a DD SUBSYS subsystem as you can get. It's
function has been superseded by later developments, but like the other
examples, gives you the infrastructure to start with.
That said, I don't think it will help with the original problem. z/OS does
not do an OBTAIN for a DD SUBSYS file; all it does is pack up whatever DD
operands are present, and pass them on via SSI function calls to the
registered subsystem. If a DSN= is present, it's just another string as
far as z/OS is concerned. Anything besides SUBSYS= must pass syntax
checking, but nothing else. The problem seems to be in the customer's
subsystem, whatever that might be.
I'd concoct a test case that did not use your product, but used JCL, ALLOC,
or bpxwdyn to allocate the file (using SUBSYS=), and see how the FTP goes.
I think it should show your product isn't part of the problem.
My guess is the customer's subsystem is using the SSI functionality to
insert itself into a more-or-less regular I/O path, and doesn't know how to
deal with aliased datasets. I don't know what's issuing the OBTAIN, but it
sure won't work with an alias.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
