C++ <fstream>, <iostream> and z/OS
Charles Mills
subject C++ classes? The words "DD" and "PDS," for example, do not appear
anywhere in "IBM z/OS Standard C++ Library Reference." (Well, "DD" does
appear in the context of date formats.) I don't see one word on the filename
formats supported beyond "const char *". I stumbled into the fact that they
support the DD: syntax by blind luck.
Does anyone know of any PDS(E)-specific support in z/OS C/C++? Anything
analogous to FIND? I know I can dynalloc() with a member name but for
multiple members the performance is extremely poor relative to FIND.
Thanks,
Charles Mills
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Tony Harminc
> Does anyone know of one lick of documentation *specific to z/OS* for the
> subject C++ classes? The words "DD" and "PDS," for example, do not appear
> anywhere in "IBM z/OS Standard C++ Library Reference." (Well, "DD" does
> appear in the context of date formats.) I don't see one word on the filename
> formats supported beyond "const char *". �I stumbled into the fact that they
> support the DD: syntax by blind luck.
Have you looked at the XL C/C++ Programming Guide? It has references
to PDS and DD: in it, though I'm not sure how C++ish they are.
> Does anyone know of any PDS(E)-specific support in z/OS C/C++? Anything
> analogous to FIND? I know I can dynalloc() with a member name but for
> multiple members the performance is extremely poor relative to FIND.
Chapter 10 of the Programming Guide has a section on "Regular and
extended partioned data sets".
Tony H.
Sam Siegel
"industry" standard C++ functions. It does not document (to my examination)
any IBM specific facilities.
Sam
Charles Mills
Yeah. I guess that's what there is. What a hodge-podge. They kind of
cross-reference the C++ classes to the C (non ++) I/O functions. Not the
clearest ever, for something that IBM is supposedly encouraging.
> Chapter 10 of the Programming Guide
Aha! fp = fopen("dd:MYDD(B)","r"); Does anyone know if that does a FIND or
if it SVC 99's an entire new DD and issues OPEN? I suspect something more
like the latter, because it probably has no way of knowing that you already
have MYDD open.
(Again, that's documentation for the C function not the C++ classes, but I
guess the PG is saying "file names that work for fopen() work for the C++
classes.")
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Tony Harminc
Sent: Friday, December 18, 2009 3:37 PM
To: IBM-...@bama.ua.edu
Subject: Re: C++ <fstream>, <iostream> and z/OS
2009/12/18 Charles Mills <char...@mcn.org>:
> Does anyone know of one lick of documentation *specific to z/OS* for the
> subject C++ classes? The words "DD" and "PDS," for example, do not appear
> anywhere in "IBM z/OS Standard C++ Library Reference." (Well, "DD" does
> appear in the context of date formats.) I don't see one word on the
filename
> formats supported beyond "const char *". �I stumbled into the fact that
they
> support the DD: syntax by blind luck.
Have you looked at the XL C/C++ Programming Guide? It has references
to PDS and DD: in it, though I'm not sure how C++ish they are.
> Does anyone know of any PDS(E)-specific support in z/OS C/C++? Anything
> analogous to FIND? I know I can dynalloc() with a member name but for
> multiple members the performance is extremely poor relative to FIND.
has a section on "Regular and
David Stephens
well, but the Run-Time Library Reference is where it all is. Functions
are for both C and C++. It includes some z/OS specific functions like
__cabend (abend a process) and _malloc24 (getmain storage below the
line), but you have to really look for them.
As you've found, fopen() works for z/OS datasets, specifying a DD using
the //DD:ddname format, or a sequential filename using the
//'dataset.name' format. Works for VSAM too. There are also the VSAM
specific flocate() and fupdate() functions.
Unfortunately, I haven't found anything like FIND for searching through
PDSs. An option may be to write an assembler program with FIND, the call
this from your C++ program.
This article may help
http://www.ibm.com/developerworks/aix/library/au-bordercrossing/
David Stephens
Lead Systems Programmer
d...@longpelaexpertise.com.au
www.longpelaexpertise.com.au
<http://www.longpelaexpertise.com.au/images/logo.gif>
Longpela Expertise - System z Mainframe Consultants
Read new expert Mainframe articles every quarter in our LongEx Mainframe
Quarterly <http://www.longpelaexpertise.com.au/ezine>
Bernd Oppolzer
you can open a PDS or PDSE without a member name using fopen ()
in binary mode and read the directory. After having read the member names,
you can fopen the individual members, if you want.
Kind regards
Bernd
David Stephens schrieb:
> There's no doubt that z/OS specific functions aren't documented that
> well, but the Run-Time Library Reference is where it all is. Functions
> are for both C and C++. It includes some z/OS specific functions like
> __cabend (abend a process) and _malloc24 (getmain storage below the
> line), but you have to really look for them.
>
> As you've found, fopen() works for z/OS datasets, specifying a DD
> using the //DD:ddname format, or a sequential filename using the
> //'dataset.name' format. Works for VSAM too. There are also the VSAM
> specific flocate() and fupdate() functions.
>
> Unfortunately, I haven't found anything like FIND for searching
> through PDSs. An option may be to write an assembler program with
> FIND, the call this from your C++ program.
>
----------------------------------------------------------------------
Charles Mills
> After having read the member names, you can fopen the individual members
Thanks! Yes, I have done that in the past in assembler. (I find it really
amusing that IBM "simulated" a PDS directory for a PDSE.) The "member *"
problem is not on the current menu, but it's good to know this works in C.
> some z/OS specific functions
Thanks. Was not aware of all of these. As I said in an earlier post, a
simple list of all of these would be an easy step for IBM and a big help for
developers.
> fopen() works for z/OS datasets, specifying a DD using the //DD:ddname
format
I'm hoping to use the C++ classes, not fopen(), but what works for fopen()
apparently works for .open()
> As you've found ... a sequential filename using the //'dataset.name'
format
Nope! Had not found that! Thanks! That's a help. Nothing you couldn't do in
two steps, the first step being dynalloc(), but that's a big help.
> write an assembler program with FIND, then call this
With FIND ... and NOTE and POINT (and FIND before POINT in case you jumped
concatenations) and do-it-yourself deblocking and below-the-line GETMAINs
and moving "model" blocks into GETMAIN storage and ...
Totally prepared to do this, but would sure love to find (no pun intended)
that IBM had done a lot of this work for me. I am going to try the
"DD:ddname(member)" syntax and see what the overhead is relative to FIND.
There are three ways this might be implemented, in order from best to worst:
- notice that "ddname" is already open and just replicate some control
blocks and do a FIND
- OPEN a new DCB for "ddname" and do a FIND
- SVC 99 a new ddname for ddname->dsname(member) and OPEN a QSAM DCB for
that
I'm hoping for no worse than number two.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Bernd Oppolzer
Sent: Saturday, December 19, 2009 6:17 AM
To: IBM-...@bama.ua.edu
Subject: Re: C++ <fstream>, <iostream> and z/OS
Farley, Peter x23353
> From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
> Behalf Of Charles Mills
> Sent: Saturday, December 19, 2009 8:18 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: C++ <fstream>, <iostream> and z/OS
<Snipped>
> > write an assembler program with FIND, then call this
>
> With FIND ... and NOTE and POINT (and FIND before POINT in case you
jumped
> concatenations) and do-it-yourself deblocking and below-the-line
GETMAINs
> and moving "model" blocks into GETMAIN storage and ...
Or you could use the newer and much more flexible DESERV macro
interface, which will let you deal with PDSE as well as PDS with the
same code. IIRC (it's been a while since I looked at that code) it can
all or almost all be above the line, but don't quote me on that. I've
been known to mis-remember such details before.
Anyway, it's worth a look if you have to go down the assembler road.
HTH
Peter
This message and any attachments are intended only for the use of the addressee and
may contain information that is privileged and confidential. If the reader of the
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
Ted MacNEIL
Why would this be amusing.
PDSE is supposed to be compatable/transparent to applications.
So, how would they do that without simulating a PDS directory?
-
Too busy driving to stop for gas!
Paul Gilmartin
>>I find it really amusing that IBM "simulated" a PDS directory for a PDSE.
>
>Why would this be amusing.
>PDSE is supposed to be compatable/transparent to applications.
>
In that case, any number of readers of this forum can tell you how
widely they missed the mark.
Within the last week, we had a PDSE with an incorrect LRECL. I
attempted to correct it by IEBGENER in a dummy member, overriding
LRECL on the SYSUT2 DD. Would have worked on a PDS; failed on
the PDSE.
For the record, I believe the operation should be prohibited on
PDS (and PS), same as on PDSE, but it remains an incompatibility.
(And before Mr. Imbriale steps in to state the obvious, we
reallocated, IEBCOPYed, and renamed.)
--gil
Charles Mills
reading the 256-byte directory blocks was a supported programming interface,
so if it had gone away I don't think anyone could have screamed "not
compatible." I find it amusing that one can read physical hardware 256-byte
blocks that are not there. But if you are not amused, that's okay too.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Ted MacNEIL
Sent: Saturday, December 19, 2009 9:29 AM
To: IBM-...@bama.ua.edu
Subject: Re: C++ <fstream>, <iostream> and z/OS
>I find it really amusing that IBM "simulated" a PDS directory for a PDSE.
Why would this be amusing.
PDSE is supposed to be compatable/transparent to applications.
So, how would they do that without simulating a PDS directory?
----------------------------------------------------------------------
Charles Mills
macro performs operations on PDS and PDSE directories" and later "The DESERV
macro may be issued in 24- or 31-bit addressing mode. In either case, all
addresses must be valid 31-bit addresses" which would seem to imply that it
may be in 31-bit storage.
Unfortunately, I don't have the problem that DESERV solves (at this moment).
I have a "read lots of explicitly-named members from the same PDS(E) with
C++ code efficiently" problem, not a "member *" problem.
DESERV does nothing about NOTE and POINT and DCB and DCBE and READ and
deblocking and ... (correct me if I'm wrong).
Charles
Paul Gilmartin
>Well, we can debate all day what is or is not amusing, but I am not sure
>reading the 256-byte directory blocks was a supported programming interface,
>so if it had gone away I don't think anyone could have screamed "not
>compatible."
>
My conjecture would be otherwise. I have some programs (Rexx) that
rely on the operation. And Rexx has no API to DESERV. And ISPF
would have needed to be modified to use DESERV rather than reading
directory blocks sequentially. This was likely perceived as a
conditio sine qua non for customer adoption of PDSE.
And it further fails to amuse me that the limited (readonly) BPAM
support for Unix directories provides for neither sequential reding
of simulated directory blocks nor DESERV.
-- gil
Farley, Peter x23353
> From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
> Behalf Of Charles Mills
> Sent: Saturday, December 19, 2009 11:35 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: C++ <fstream>, <iostream> and z/OS
>
DESERV
> macro performs operations on PDS and PDSE directories" and later "The
> DESERV macro may be issued in 24- or 31-bit addressing mode. In either
> case, all addresses must be valid 31-bit addresses" which would seem
to
> imply that it may be in 31-bit storage.
>
> Unfortunately, I don't have the problem that DESERV solves (at this
> moment). I have a "read lots of explicitly-named members from the same
> PDS(E) with C++ code efficiently" problem, not a "member *" problem.
>
> DESERV does nothing about NOTE and POINT and DCB and DCBE and READ and
> deblocking and ... (correct me if I'm wrong).
No, it looks as if you are correct. DESERV will get you the DE (or
SMDE), using which you would still have to issue FIND and then BSAM
READ/deblock's in 24-bit space.
<Small rant> Why oh why didn't they ever write QPAM? Would it really
have been so hard to do? </Small rant>
Water under the bridge, I suppose. Too late now.
CBT might already have good example code for the FIND/READ/deblock stuff
so you don't have to reinvent that wheel. The FM even has an example
using a ring of DECB's for asynchronous READ's in "3.7.6 Retrieving a
Member of a PDS", Figure 121, in the DFSMS Using Datasets manual. That
example uses BLDL instead of DESERV though.
Ted MacNEIL
>In that case, any number of readers of this forum can tell you how widely they missed the mark.
Yes, I've btdt many times.
Especially since the introduction of non-SMS-Managed PDSE's.
My point was:
of course PDSE is going to 'simulate' a PDS directory.
Software issues aside, that was its first intent.
-
Too busy driving to stop for gas!
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
on 12/19/2009
at 12:52 PM, "Farley, Peter x23353" <Peter....@BROADRIDGE.COM> said:
><Small rant> Why oh why didn't they ever write QPAM?
Nobody wrote up a business case that they found compelling. Or internal
politics.
>Would it really have been so hard to do?
It was a bear[1] the last time that I did it. If someone is willing to
upgrade my code for z/OS, I'd be happy to open source it. I last upgraded
the code to support the PL/I "optimizing" compiler under MVS/SP; some or
all of the references to PL/I fields will need to be changed to LE fields
and the SAM-E support must be upgraded.
The code is a PL/I callable interface that allows for native PL/I I/O to
deal with multiple members on a single open.
[1] Not intrinsically hard, but lots of special cases.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)