Mixing C/C++ with LE-conforming IBM HLASM

[Larry Slaten]

I am attempting to use the C/C++ FOPEN function to open a SYSLIB DD
pointing to a concatenation of executable libraries.  Then extract the
DCB address so that I can use it to populate the LOAD and BLDL macro. 
This would make it easier to keep the root program RENT.  I realize that
I can code the DCB in the root assembler program and do what is
necessary to keep the program RENT.  But, using the C/C++ functions
would make it simpler.  I have used the FOPEN function to open the data
set, retrieved the file pointer.  The file pointer points to another
31-bit address. I have dumped the storage around that 31-bit address, it
still doesn't look like a DCB.  I  do see "SYSLIB" at +84 bytes, so I
appear to be close to the answer.  Does anybody know to obtain the DCB
address using the file pointer returned by FOPEN?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN

[Charles Mills]

I played with the approach you suggest and abandoned the effort. Too hard, and too likely to break.

What I did do that worked was code a number of atomic assembler routines that could be passed a DCB that was kept in an area that I malloc or new in C or C++. One of those routines was

int MAKEDCB(void *DCBarea, const int DCBareaLen, const char *DCBtype, const char DDname[8]);

It constructs a DCB in the C/C++ allocated area by moving in a model. DCBtype is, e.g., "BPAM". Other routines are, e.g.,

int OPNDCBIN(void *DCBarea); // OPEN a DCB for input

Charles

[Paul Gilmartin]

On Wed, 14 Jul 2021 09:53:16 -0700, Charles Mills wrote:

>I played with the approach you suggest and abandoned the effort. Too hard, and too likely to break.
>

>What I did do that worked was code a number of atomic assembler routines that could be passed a DCB that was kept in an area that I malloc or new in C or C++. ...
>
I once wrotee a HLASM routine,
o Probably NORENT; certainly not LE
o Called from Rexx with ADDRESS LINKMVS

It took a DDNAME as an argument; OPENed; returned a DCB pointer to use by STORAGE()

My purpose was to determine the undocumented attributes of SYSINs depending on
attributes of thee submitting INTRDR.

Interestingly, JES3 differs from JES2.

It was a one-off. I didn't even bother to CLOSE.

-- gil

[Bernd Oppolzer]

IMHO this is not a good idea, because the C/C++ runtime probably
did more things than simply construct a DCB and open it; IMO it
allocated storage for buffers etc., too.
And if you "steal" the open DCB from it, you will leave the C/C++
runtime in an undefined state,
at best, even if you plan not to use the C/C++ file functions after the
fopen() call;
you will have a storage leak IMO.

And: no, I have no idea how to get the DCB from the C/C++ FILE structure.

(I am a compiler maintainer myself, and I cannot imagine someone
successfully
using the DCBs, which are part of my Pascal File control structures, and
doing I/O using them,
this way "fooling" the Pascal runtime system ... but, who knows).

Kind regards

Bernd

[Charles Mills]

IIRC this technique was fairly common in the old COBOL days. IIRC you could call an assembler routine passing the name of an FD and the program got passed the address of the DCB. I think has not worked in some time -- well, in some number of COBOL versions.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer
Sent: Wednesday, July 14, 2021 1:55 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mixing C/C++ with LE-conforming IBM HLASM

IMHO this is not a good idea, because the C/C++ runtime probably
did more things than simply construct a DCB and open it; IMO it
allocated storage for buffers etc., too.
And if you "steal" the open DCB from it, you will leave the C/C++
runtime in an undefined state,
at best, even if you plan not to use the C/C++ file functions after the
fopen() call;
you will have a storage leak IMO.

And: no, I have no idea how to get the DCB from the C/C++ FILE structure.

(I am a compiler maintainer myself, and I cannot imagine someone
successfully
using the DCBs, which are part of my Pascal File control structures, and
doing I/O using them,
this way "fooling" the Pascal runtime system ... but, who knows).

[Farley, Peter x23353]

IMHO it would be easier (and probably more maintainable) to use MetalC to set up a model BPAM DCB / DCBE and copy it to malloc24 storage (and the DCBE should you need it to malloc31 storage), and return the malloc24'ed DCB address after optionally linking the DCBE to it, if needed/wanted.

I've done this sort of thing for QSAM DCB/DCBE along with OPEN, CLOSE, GET/PUT MOVE, and GET/PUT LOCATE subroutines, and it works nicely.

But not tested in an LE environment, just standalone stuff with a MetalC main program.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Larry Slaten
Sent: Wednesday, July 14, 2021 10:45 AM
To: IBM-...@LISTSERV.UA.EDU

Subject: Mixing C/C++ with LE-conforming IBM HLASM

I am attempting to use the C/C++ FOPEN function to open a SYSLIB DD pointing to a concatenation of executable libraries.  Then extract the DCB address so that I can use it to populate the LOAD and BLDL macro. This would make it easier to keep the root program RENT.  I realize that I can code the DCB in the root assembler program and do what is necessary to keep the program RENT.  But, using the C/C++ functions would make it simpler.  I have used the FOPEN function to open the data set, retrieved the file pointer.  The file pointer points to another 31-bit address. I have dumped the storage around that 31-bit address, it still doesn't look like a DCB.  I  do see "SYSLIB" at +84 bytes, so I appear to be close to the answer.  Does anybody know to obtain the DCB address using the file pointer returned by FOPEN?

----------------------------------------------------------------------

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.

[Charles Mills]

Correction: you can't use malloc or new to get the area -- they will return 31-bit storage. You might use __malloc24() which does the obvious. Looking at my code, I called out to a GETMAIN LOC=BELOW written in assembler. Can't tell you why I did that rather than use __malloc24().

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Charles Mills
Sent: Wednesday, July 14, 2021 9:53 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mixing C/C++ with LE-conforming IBM HLASM

I played with the approach you suggest and abandoned the effort. Too hard, and too likely to break.

What I did do that worked was code a number of atomic assembler routines that could be passed a DCB that was kept in an area that I malloc or new in C or C++. One of those routines was

int MAKEDCB(void *DCBarea, const int DCBareaLen, const char *DCBtype, const char DDname[8]);

It constructs a DCB in the C/C++ allocated area by moving in a model. DCBtype is, e.g., "BPAM". Other routines are, e.g.,

int OPNDCBIN(void *DCBarea); // OPEN a DCB for input

[Seymour J Metz]

I used to access the DCB for PL/I programs (both F and "optimizing"), but the relevant interfaces are no longer documented and I'm not aware of any mapping macro for, e.g., the FCB.

Can you make a business case for IBM to open up the interface? If so, consider a REQ or SHARE requirement.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Larry Slaten [larry....@COMCAST.NET]
Sent: Wednesday, July 14, 2021 10:44 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Mixing C/C++ with LE-conforming IBM HLASM

[Charles Mills]

I'm in beyond my depth here but could you get to the DCB coming from the
other direction? Run the DEB chain until you got to the right DCB?

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, July 15, 2021 9:21 AM
To: IBM-...@LISTSERV.UA.EDU

Subject: Re: Mixing C/C++ with LE-conforming IBM HLASM

I used to access the DCB for PL/I programs (both F and "optimizing"), but
the relevant interfaces are no longer documented and I'm not aware of any
mapping macro for, e.g., the FCB.

Can you make a business case for IBM to open up the interface? If so,
consider a REQ or SHARE requirement.

[Steve Thompson]

Yes. That is how I implemented SEGMENT support when doing DOS to MVS migrations.

Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks


> On Jul 15, 2021, at 12:57 PM, Charles Mills <char...@mcn.org> wrote:
>
> I'm in beyond my depth here but could you get to the DCB coming from the

[Paul Gilmartin]

On Thu, 15 Jul 2021 16:20:44 +0000, Seymour J Metz wrote:
>
>Can you make a business case for IBM to open up the interface? If so, consider a REQ or SHARE requirement.

>________________________________________
>From: Larry Slaten

>Sent: Wednesday, July 14, 2021 10:44 AM
>

> ... I have dumped the storage around that 31-bit address, it

>still doesn't look like a DCB. I do see "SYSLIB" at +84 bytes, so I
>appear to be close to the answer. Does anybody know to obtain the DCB
>address using the file pointer returned by FOPEN?
>

Note that, with archaic parsimony, OPEN overwrites the DDNAME in the DCB
(and CLOSE restores it.) So the "SYSLIB" you see is probably not the open DCB.

-- gil

[Mario Bezzi]

As far as I know __malloc24 is only available when running in a System
programming C environment, which is an early incarnation of METAL-C and
does not use LE runtime services. Maybe this is the reason?

mario

[Charles Mills]

That would certainly account for it! <g> 100% of my experience is full LE C++.

But are you sure? I don't see any such restriction in the library reference and I know the LE diagnostic storage report shows a below-the-line heap. The library manual says it is supported for C++, which to me would seem to imply "full" support.

[Seymour J Metz]

What if there's more than one DCB with the desired ddname?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


________________________________________

From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> on behalf of Charles Mills <char...@MCN.ORG>
Sent: Thursday, July 15, 2021 12:57 PM

[Mario Bezzi]

Charles, at least that's my understanding reading the doc.

https://www.ibm.com/docs/en/zos/2.4.0?topic=functions-malloc24-allocate-24-bit-storage

"Related information
..See the topic about using the system programming C facilities in z/OS
XL C/C++ Programming Guide. .."

https://www.ibm.com/docs/en/zos/2.4.0?topic=environments-using-system-programming-c-facilities

mario

[Charles Mills]

Dependencies: AMODE 64

Someone explain that one to me. You need to be running 64-bit to allocate 24-bit storage.

That is probably why I did not use it!

[Paul Gilmartin]

On Thu, 15 Jul 2021 22:16:11 +0000, Seymour J Metz wrote:

>What if there's more than one DCB with the desired ddname?
>

"Doctor, it hurts ..."

Can't the programmer control that, perhaps by letting SVC 99
(or BPXWDYN) choose a unique ddname?

(Does the C/C++ RTL allocation support that operation? How does
fopen("//data.set.name") select a ddname to avoid collisions?)

If SYSLIB is a concatenation of UNIX directories, BLDL should work.
LOAD less likely.

________________________________________
From: Charles Mills
Sent: Thursday, July 15, 2021 12:57 PM

I'm in beyond my depth here but could you get to the DCB coming from the
other direction? Run the DEB chain until you got to the right DCB?

-- gil

[David Crayford]

On 16/07/2021 12:20 am, Seymour J Metz wrote:
> I used to access the DCB for PL/I programs (both F and "optimizing"), but the relevant interfaces are no longer documented and I'm not aware of any mapping macro for, e.g., the FCB.
>
> Can you make a business case for IBM to open up the interface? If so, consider a REQ or SHARE requirement.

IBM would never accept a FIT and rightly so. The FILE structure returned
by the fopen() factory function is designed to be opaque, what is called
encapsulation or information hiding in OO languages. fopen() can open
BSAM, QSAM, VSAM, z/OS Unix files and hiperspaces.
The only fields that are exposed are the read/write callback functions,
the buffer and some state information so fget() fput() etc can be
implemented using macros for optimization reasons. I dread to think why
anybody would want to poke around inside the internals of an
Abstract Data Type.

[Charles Mills]

> Can't the programmer control that

Perhaps not. One can come up with hypotheticals where the programmer could not. Or perhaps the programmer's design works best with two files, one DD. But yes, of course, it something of a grasp at straws.

> How does fopen("//data.set.name") select a ddname to avoid collisions?

The same way most do with dynamic allocation: by letting the system "return" a generated DD name. You've seen them: they have the form SYS00001, SYS00002, ... What happens if there are 10,000? I will leave that as an exercise for the class.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Thursday, July 15, 2021 6:51 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mixing C/C++ with LE-conforming IBM HLASM

[Seymour J Metz]

If he's concerned with a concatenation then he won't be using the dsname form.

fopen("//DD:SYSLIB")

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f0781...@LISTSERV.UA.EDU]
Sent: Thursday, July 15, 2021 9:51 PM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mixing C/C++ with LE-conforming IBM HLASM

[Seymour J Metz]

Well, my use case was to do I/O on multiple members of a PDS, using standard PL/I I/O. And, yes, I had to rewrite it between F and "optimizing", but that was a piece of cake.

It's a shame that the MVS developers didn't steal the concept of VPAM from TSS.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of David Crayford [dcra...@GMAIL.COM]
Sent: Friday, July 16, 2021 1:57 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mixing C/C++ with LE-conforming IBM HLASM

[Paul Gilmartin]

On Fri, 16 Jul 2021 13:26:51 +0000, Seymour J Metz wrote:

>If he's concerned with a concatenation then he won't be using the dsname form.
>
>fopen("//DD:SYSLIB")
>

If SYSLIB is a concatenation of PDS[E] (and possibly UNIX directories), what
subsequent operations on the returned (FILE *) object are supported by the
C/C++ RTTL?

BTW, what's VPAM? I found a Bitsavers document that doesn't make it obvious
why it's better than BPAM.

Some programmers wish for QPAM, supporting BLDL, GET, NOTE, etc.

-- gil

[Seymour J Metz]

Virtual Partitioned Access Method. See <http://bitsavers.org/pdf/ibm/360/tss/GC28-2056-2_Time_Sharing_System_Data_Management_Facilities_Dec77.pdf#page=21> and <http://bitsavers.org/pdf/ibm/360/tss/GC28-2004-6_Time_Sharing_System_Assembler_User_Macro_Instructions_Nov79.pdf#page=14>

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f0781...@LISTSERV.UA.EDU]
Sent: Friday, July 16, 2021 2:41 PM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mixing C/C++ with LE-conforming IBM HLASM

[Paul Gilmartin]

On Fri, 16 Jul 2021 20:30:46 +0000, Seymour J Metz wrote:

>Virtual Partitioned Access Method. See <http://bitsavers.org/pdf/ibm/360/tss/GC28-2056-2_Time_Sharing_System_Data_Management_Facilities_Dec77.pdf#page=21> and <http://bitsavers.org/pdf/ibm/360/tss/GC28-2004-6_Time_Sharing_System_Assembler_User_Macro_Instructions_Nov79.pdf#page=14>
>

Gee. Sounds like grandfather of PDSE. If PDSE supported multiple volumes.
Different serialization runes; less like LUW. BPAM had bad design in requiring
deferring naming of members. Is that perhaps optional with VPAM?

It says supported macros are FIND and STOW. What about GET, PUT, NOTE, and POINT?

Thanks,

[Paul Gilmartin]

On Fri, 16 Jul 2021 22:28:47 +0000, Seymour J Metz wrote:

>Except that PDSE doesn't allow me to open a QSAM DCB and do FIND and STOW for multiple members.
>
OK. It requires multiple DCBs.

>I'm not sure what you mean by deferring naming of members.
>
A member is not named when it is created, but only at the point of STOW.
This opens serialization hazards which ISPF Edid covers with ENQ EXC SPFEDIT.
Of course the programmer can code this explicitly, but it should be in the
access method.

ISPF LMPUT allows multiple concurrent PDSE member creation. If multiple tasks
attempt to create the same member name, the last STOW (LMCLOSE) one wins.
Only within a single job because LMPUT requires ENQ EXC SYSDSN, needlessly
because PDSE does its own serialization With PDS, data may be corrupted.

>You can use any macro appropriate for the type of member. GET and PUT, but NOTE and POINT are only for BSAM.
>
Bummer. BPAM shoud support GET and PUT.

-- gil

[Larry Slaten]

Thanks to everyone for their input.  Since I was already using C/C++ I/0
functions to access a card file I thought that it would be simple enough
to setup the DD:SYSLIB and that it would actually point me to a DCB
address that I could use in my BLDL and LOAD macro(s).  I ended up
defining the DCB in my assembler program and did all of the right stuff
to maintain re-entrant code.  It would have been nice if the DCB address
would have been easily accessible.

[Seymour J Metz]

> OK. It requires multiple DCBs.

Yes, and if I'm doing something with every member of a PDS then I really don't want all of those OPENs.

> A member is not named when it is created, but only at the point of STOW

Thanks. Yes, the same issue exists with VPAM.

> BPAM shoud support GET and PUT.

Why? BSAM is for dealing with blocks. Although it would be nice if QSAM had equivalents to equivalents to NOTE and POINT.

In TSS, you use SETL to point to a logical VPAM record. Check the references I gave you.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


________________________________________
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> on behalf of Paul Gilmartin <0000000433f0781...@LISTSERV.UA.EDU>

Sent: Friday, July 16, 2021 7:32 PM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mixing C/C++ with LE-conforming IBM HLASM

[Paul Gilmartin]

On Mon, 19 Jul 2021 19:43:23 +0000, Seymour J Metz wrote:

>> OK. It requires multiple DCBs.

>Yes, and if I'm doing something with every member of a PDS then I really don't want all of those OPENs.
>

If I'm doing something with multiple members, e.g. comparing two members, I consider
it good design to use one DDNAME, two DCBs and two OPENs. Isn't the alternative an
nightmare of ping-ponging NOTEs and POINTs? What would ISRSUPC do?

Writing multiple members of a PDSE (not PDS) concurrently should probably
be done with multiple DCBs.

"doing something with every member of a PDS" is probably better done serially than concurrently.

>> A member is not named when it is created, but only at the point of STOW

>Thanks. Yes, the same issue exists with VPAM.

>> BPAM shoud support GET and PUT.

>Why? BSAM is for dealing with blocks. Although it would be nice if QSAM had equivalents to equivalents to NOTE and POINT.
>

Too often, "is for" is a feckless apologia, paraphrasing "can only ... although it would be nice ..."

>In TSS, you use SETL to point to a logical VPAM record. Check the references I gave you.
>

I got information overload. Thanks for filtering for me. Was there a similar analogue
for NOTE? Did the TSS assembler(?) use those?

(What became of the tradition of ">" quotation marks? I faked them.)

Thanks again,

[Seymour J Metz]

> Writing multiple members of a PDSE (not PDS) concurrently

Who said anything about concurrently? Consider a program to create sequence numbers in every member (or remove them).

> Too often, "is for" is a feckless apologia, paraphrasing "can only ... although it would be nice ..."

The problem isn't that BSAM doesn't handle logical records, the problem is that QSAM doesn't handle repositioning. The distinction between READ and GET is a legitimate one.

> Was there a similar analogue for NOTE?

Sort of, with limitations.

> Did the TSS assembler(?) use those?

I believe that all of the compilers, including ASM (F), supported reading source from VISAM with sequence numbers as keys.

> (What became of the tradition of ">" quotation marks? I faked them.)

I'm using a brain-dead e-mail client. I have to handle quoting by hand.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f0781...@LISTSERV.UA.EDU]

Sent: Monday, July 19, 2021 7:21 PM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mixing C/C++ with LE-conforming IBM HLASM

[Paul Gilmartin]

On Tue, 20 Jul 2021 01:51:32 +0000, Seymour J Metz wrote:

>> Writing multiple members of a PDSE (not PDS) concurrently
>Who said anything about concurrently? Consider a program to create sequence numbers in every member (or remove them).
>

I did: On Fri, 16 Jul 2021 18:32:51 -0500, Paul Gilmartin ...

>> Too often, "is for" is a feckless apologia, paraphrasing "can only ... although it would be nice ..."
>
>The problem isn't that BSAM doesn't handle logical records, the problem is that QSAM doesn't handle repositioning. The distinction between READ and GET is a legitimate one.
>

There ought to be a synthesis of their two capabilities.

>> Was there a similar analogue for NOTE?
>Sort of, with limitations.
>

For VISAM, it might suffice to record the sequence number.

>> Did the TSS assembler(?) use those?
>I believe that all of the compilers, including ASM (F), supported reading source from VISAM with sequence numbers as keys.
>

An irritant to modern languages such as Rexx and C which prefer
RECFM=VB, unnumbered.

>> (What became of the tradition of ">" quotation marks? I faked them.)
>I'm using a brain-dead e-mail client. I have to handle quoting by hand.
>

At times I circumvent such problems by posting from the Web interface.

-- gil

[Seymour J Metz]

The brain-dead e-mail client to which I referred is a web interface. Or did you mean the listserv web site, which I have not yet investigated?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f0781...@LISTSERV.UA.EDU]

Sent: Monday, July 19, 2021 11:54 PM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mixing C/C++ with LE-conforming IBM HLASM

[Kirk Wolf]

Sorry for joining this thread late.

You are correct Larry - the z/OS C library has very little help for PDS
processing.   I wrote an RFE in 2015, but I don't expect to want it
anymore if/when IBM responds :-)
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=80811

We recently released two new shell command utilities in Co:Z which have
all sorts of options for loading/unloading PDS/PDSEs to/from zFS files.

https://www.dovetail.com/docs/zos-utilities/dsp-ref_getpds.html
https://dovetail.com/docs/zos-utilities/dsp-ref_putpds.html

The code is 98% C++, with bpam/bsam assembler routines.   Our C++ is
31-bit LE with XPLINK  (IMO the only rational linkage for C++ at
scale).  Our assembler code is quite small and uses  XPLINK linkage
macros (EDCXPRLG, EDCXEPLG) and also the XPLINK stack local data.  This
is *so* much nicer than the old way of writing reentrant code.    All of
the BSAM fancies (DECB/buffer queue, record blocking, etc) is done in
C++.  Only one DCB (BPAM/BSAM).

The performance of loading/unloading a large PDS/PDSE is great - like
two orders of magnitude faster than /bin/cp which opens the dataset for
each and every member :-)
We also support ISPF-style ENQs with DISP=SHR, which is really handy for
many use cases, like devops.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

[Paul Gilmartin]

On Sat, 24 Jul 2021 12:01:09 -0500, Kirk Wolf wrote:

>Sorry for joining this thread late.
>
>You are correct Larry - the z/OS C library has very little help for PDS
>processing.   I wrote an RFE in 2015, but I don't expect to want it
>anymore if/when IBM responds :-)
>https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=80811
>
>We recently released two new shell command utilities in Co:Z which have
>all sorts of options for loading/unloading PDS/PDSEs to/from zFS files.
>

Nice.

Why is the "//" required? It might be presumed. But it leaves syntactic
leeway for future extension to UNIX<->UNIX copy.

>https://www.dovetail.com/docs/zos-utilities/dsp-ref_getpds.html

There's no "-l record" option. That format, provided by allocation is
seldom used, but needed to support files containing a line-separator
as data. (Is this "l4", not mentioned in the list of option values?)

>https://dovetail.com/docs/zos-utilities/dsp-ref_putpds.html
>
is -i l4 or FILE DATA(RECORD) supported?

If the -l or -s option is omitted, are the tag values of the source files
individually respected? (pax does some of this, however poorly.)
JCL respects the FILEDATA of a tagged source file (undocumented)

How are UNICODE conversion errors treated/reported?

Thanks,
gil

[Kirk Wolf]

Gil,

Are your questions because you want to use the utilities, or just
pedagogical?  :-)


-l l4 is compatible with FILEDATA=RECORD, and I think predates it.   It
sounds like your issue is that we didn't use the IBM terminology?

Unicode conversion errors (UTF-8) print an error to stderr and exits <> 0

support for tagging is currently limited to what is documented: getpds
has an option for tagging output zFS files.   Adding a processing option
to putpds to respect tags is a reasonable thing to want.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

[David Crayford]

On 25/07/2021 1:01 am, Kirk Wolf wrote:
> We recently released two new shell command utilities in Co:Z which
> have all sorts of options for loading/unloading PDS/PDSEs to/from zFS
> files.
>
> https://www.dovetail.com/docs/zos-utilities/dsp-ref_getpds.html
> https://dovetail.com/docs/zos-utilities/dsp-ref_putpds.html
>
> The code is 98% C++, with bpam/bsam assembler routines.   Our C++ is
> 31-bit LE with XPLINK  (IMO the only rational linkage for C++ at
> scale).  Our assembler code is quite small and uses  XPLINK linkage
> macros (EDCXPRLG, EDCXEPLG) and also the XPLINK stack local data. 
> This is *so* much nicer than the old way of writing reentrant code.   
> All of the BSAM fancies (DECB/buffer queue, record blocking, etc) is
> done in C++.  Only one DCB (BPAM/BSAM).
>
> The performance of loading/unloading a large PDS/PDSE is great - like
> two orders of magnitude faster than /bin/cp which opens the dataset
> for each and every member :-)
> We also support ISPF-style ENQs with DISP=SHR, which is really handy
> for many use cases, like devops.

We're using getpds/putpds for new DevOps tooling to sync files to/from
the file system to data sets. Not only is the performance superb (cp
taking 2 minds to move a large PDS as opposed to 3 seconds) the ability
to write to a PDS with DISP=SHR is a game changer as we only want to
stage using optimistic locking.

This is top notch software engineering!