IBM Data Element Descriptor definitions?

[Thomas David Rivers]

Does anyone happen to have a definition
of the current IBM Data Element Descriptors?

I found old ones from 360/370 days but not the newest ones.

- Thanks -
- Dave Rivers -

--
riv...@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

[glen herrmannsfeldt]

Thomas David Rivers <riv...@dignus.com> wrote:
> Does anyone happen to have a definition
> of the current IBM Data Element Descriptors?

> I found old ones from 360/370 days but not the newest ones.

There are some PLMs around for the PL/I Optimizing compiler.

They might still be the same as (F), as changing them would cause
calling assembler programs to fail. Unless they needed to be changed,
why change them?

-- glen

[Thomas David Rivers]

I'm pretty sure they've changed, or perhaps have been enhanced.

For example, the (F) compiler didn't support VARYINGZ...

- Dave R. -

[Peter Flass]

On 3/4/2013 2:29 PM, Thomas David Rivers wrote:
> Does anyone happen to have a definition
> of the current IBM Data Element Descriptors?
>
> I found old ones from 360/370 days but not the newest ones.
>
> - Thanks -
> - Dave Rivers -
>

I believe Enterprise PL/I has changed these completely. Look for a
"Debug Reference" or something similar.

--
Pete

[Thomas David Rivers]

Hi Pete,

Thanks for the pointer - I found the LE debugging information, and it
points
one to the PL/I Programming Guide. The Programming Guide has a section
on locator-descriptors which describes some descriptors (not sure if
its the
same as a Data Element Descriptor or not.) It only seems to describe
String
and Array descriptors and nothing else...

Any idea where other Data Element Descriptor (DED) definitions might be
had?

- Thanks! -
- Dave Rivers -

[Peter J. Seymour]

On 2013-03-04 19:29, Thomas David Rivers wrote:
> Does anyone happen to have a definition
> of the current IBM Data Element Descriptors?
>
> I found old ones from 360/370 days but not the newest ones.
>
> - Thanks -
> - Dave Rivers -
>

In the Optimising Compiler days it was all in the Execution Logic
manual. In those days you might have needed the info because you were
interfacing Assembler routines with PL/I programs.
I'm not sure if you are considered to need as much info these days. It
may be a case of ask your IBM contacts.

[glen herrmannsfeldt]

Peter J. Seymour <Newsg...@pjsey.demon.co.uk> wrote:
> On 2013-03-04 19:29, Thomas David Rivers wrote:
>> Does anyone happen to have a definition
>> of the current IBM Data Element Descriptors?

(snip)

> In the Optimising Compiler days it was all in the Execution Logic
> manual. In those days you might have needed the info because you were
> interfacing Assembler routines with PL/I programs.
> I'm not sure if you are considered to need as much info these days.
> It may be a case of ask your IBM contacts.

I do remember writing one assembler program, well, modifying one,
to do this.

You could usually call Fortran, or Fortran callable assembler programs
by passing the first element of an array, instead of the whole array.

But for CHAR arrays or variables it always passed the descriptor.

I was calling the Calcomp plot routines from PL/I, specifically
the SYMBOL routine that would plot character strings. So I modified
it to accept a PL/I CHAR variable instead of a Fortran array and length.

-- glen

[James J. Weinkam]

Thomas David Rivers wrote:
> Peter Flass wrote:
>
>> On 3/4/2013 2:29 PM, Thomas David Rivers wrote:
>>
>>> Does anyone happen to have a definition
>>> of the current IBM Data Element Descriptors?
>>>
>>> I found old ones from 360/370 days but not the newest ones.
>>>
>>> - Thanks -
>>> - Dave Rivers -
>>>
>>
>> I believe Enterprise PL/I has changed these completely. Look for a "Debug Reference" or something similar.
>>
> Hi Pete,
>
> Thanks for the pointer - I found the LE debugging information, and it points
> one to the PL/I Programming Guide. The Programming Guide has a section
> on locator-descriptors which describes some descriptors (not sure if its the
> same as a Data Element Descriptor or not.)

They are not the same: Locator/descriptors are used in passing arguments to user written procedures and no doubt also
built in functions that are invoked out of line. The descriptor simply provides the values of variable aspects of the
data item such as string length or array bounds. The called routine already knows the data type of the parameter to
which the argument is passed. In contrast DED are needed when the compiler needs to invoke other library routines used
for such things as stream IO where the routine being invoked needs to be told the data type of its argument as well as
any variable aspects. As has already been pointed out, a full description of the DED's for the Optimizing Compiler can
be found in the execution logic manual which is available on line. I seriously doubt such information is available for
later compilers. Your best bet is to compile some simple test programs and study the assembly listing.

Is there some reason that you need to know the format of the DEDs? As far as I know they are never visible to user
written code.

[Peter Flass]

On 3/4/2013 11:15 PM, James J. Weinkam wrote:
>
> Is there some reason that you need to know the format of the DEDs? As
> far as I know they are never visible to user written code.

Unless you're calling assembler or some other language where you need to
know string lengths, etc.

Dave - somewhere I recall seeing the formats, whether for Enterprise
PL/I or for OS/2 PL/I, which should be similar. I don't write much IBM
PL/I any more and I try to keep away from dependence on internals these
days. If all else fails you could reverse-engineer the information -
just code a program with the types of calls you want and see what is
generated for the descriptors. It shouldn't be *too* hard.

--
Pete

[Thomas David Rivers]

HI Pete,

Hmm - I don't have the OS/2 PL/I manuals and can't seem to find them
on-line...

I guess 1995 was too long ago...

- Thanks! -
- Dave Rivers -

[James J. Weinkam]

Peter Flass wrote:
> On 3/4/2013 11:15 PM, James J. Weinkam wrote:
>>
>> Is there some reason that you need to know the format of the DEDs? As
>> far as I know they are never visible to user written code.
>
> Unless you're calling assembler or some other language where you need to know string lengths, etc.

If I understand the interlanguage facility correctly, specification of the ASSEMBLER option prevents the passing of
descriptors. If you want the descriptor to be passed to an assembly language routine you have to let the compiler think
is is calling a PL/I routine and know how to process the argument list including any descriptors. However, the
descriptors passed in CALL statements and function references are not Data Element Descriptors. As I stated in my
previous post, DED's encode the data type and are needed for compiler generated calls to run time library routines that
are able to process data whose type is not known until the time of invocation. For example, in EDIT directed io, both
the EDIT list and the format list allow looping constructions that can depend on variables whose value are not known
until run time and can vary from one execution to another of the same statement. There is no way in general for the
compiler to match up data list entries with format list transmitting items. The simplest way for the compiler to deal
with this is to generate a data coroutine and a format coroutine. The data coroutine executes until it has a data item
ready for conversion and transmission and then resumes the format coroutine leaving pointers to the value and a DED in
known locations. The format coroutine executes from where it previously left off until it reaches a data transmitting
item; it then uses the DED to find out how to intrepret the data identified by the pointer and convert it according to
the format item in the case of output or to convert the input stream item and store it in the specified location in the
case of input; it then resumes the data coroutine. This continues until the data coroutine ends.

The DED tells the called routine the data type; in the case of ordinary procedures the data type of the parameter is
known, e.g., three dimensional array of bin float(21) or varying length character string, all the descriptor does is
provide the subscript bounds or current and maximum string lengths.

[Shmuel Metz]

In <kh2vq1$nb9$1...@speranza.aioe.org>, on 03/04/2013

at 08:22 PM, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:

>There are some PLMs around for the PL/I Optimizing compiler.

>They might still be the same as (F),

They are not.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Shmuel Metz]

In <kh2sqa$dr6$1...@speranza.aioe.org>, on 03/04/2013

at 02:29 PM, Thomas David Rivers <riv...@dignus.com> said:

>Does anyone happen to have a definition
>of the current IBM Data Element Descriptors?

I've been looking for decades. I have some assembler code that accepts
a PL/I file parameter and is very much dependent on the relevant PL/I
control blocks. For PL/1 (F) and PL/I "Optimizing" compiler the
information that I need is in the logic manuals and mapping macros,
but I haven't been able to find them for anything more recent.

[Robin Vowels]

On Mar 5, 6:29 am, Thomas David Rivers <riv...@dignus.com> wrote:
> Does anyone happen to have a definition
> of the current IBM Data Element Descriptors?
>
> I found old ones from 360/370 days but not the newest ones.

IBM's current Programming Guide is available on-line.

[Peter J. Seymour]

I am "retired" now, but when I had use of my employers equipment I
sometimes printed off a manual if I did not have a paper copy available.
I much prefer to work from paper copies of manuals. Modern printer
drivers are more versatile than old ones and my approach is to print
manuals 2-up and duplex which minimises paper usage while preserving
readability. Even so, it can involve a significant wodge of paper. At
one time, IBM were very generous with printed manuals, but I suppose
times change.

[John W Kennedy]

Yeah, I remember the rather large free library I built up as a student
in the 60s just by walking into the nearest branch office.

--
John W Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"