Re: Binder API...broke or working as designed

[Shmuel Metz (Seymour J.)]

In <2mkk959rl49egrm7msh5j009tv6lou4...@4ax.com>, on 08/30/2009
   at 01:22 PM, Binyamin Dissen  said:

>Such as?

Anything without a PPT entry, for starters.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Leona Baumgart]

Chris is correct in believing that the typical caller of the binder API was
originally envisioned as an ordinary problem program state application
program. We are looking into whether something can be done so that we can
officially support key zero supervisor state callers  - no promises, though.  

As for the other comments from Chris, I am aware that Chris wants (or
wanted) a number of enhancements to the multiple text class program object
architecture.  The great majority of those would require changes to
components other than the binder itself for implementation.  Again, for
anyone who wants that sort of enhancement, using a formal requirement
process would make the desired outcome more likely. 

Leona Baumgart
z/OS Binder development   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Shane]

On Fri, 2009-08-28 at 10:39 -0500, Chris Craddock wrote:

> I believe that the API was written in a completely naieve fashion much like
> any other batch program and certainly without any thought to properly
> handling the nuances presented by a privileged caller in an otherwise
> non-privileged environment.

Hardly a resounding endorsement.

> The real deal-breaker is that the
> multipart class architecture of PM3 (as currently implemented) is unusable
> at all. So even if the binder API were to be refactored at some time in the
> future to behave like any other well formed system service, the result would
> be moot.

Just gets better and better ...

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Binyamin Dissen]

On Fri, 28 Aug 2009 07:14:08 -0400 "Shmuel Metz (Seymour J.)"
 wrote:

:>In , on 08/27/2009
:>   at 09:42 PM, "William H. Blair"  said:

:>>Normally, one does not run in key 0 problem state,

:>Started tasks normally run in problem state even when the key is 0. 

Such as?

:>I'd
:>guess that IBM ships more code that runs key 0 problem state than the do
:>running in supervisor state. 

Depends on how one counts the code.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Chris Craddock]

On Thu, Aug 27, 2009 at 6:29 PM, Peter Relson  wrote:

> There is no subpool that would satisfy both of the following
> -- work for unauthorized callers running in their state and key
> -- work for authorized callers running in their state and key and not come
> out of "low private" (where "low" refers to the user region, not to "below
> 16M")
>
> So it's at least not simply a matter of subpool choice (since "low
> private" is usually a concern for an authorized application).
>
> Yes, of course, an application could at runtime select which subpool to
> use.
>
> This thread had made me think about this a few days ago.
>
> I wonder if they happen to use subpool 0 which might, at least, let a key 0
> invocation work (as it would be translated to subpool 252; I can't remember
> if that also requires supervisor state)


Privileged progams are responsible for making conscious informed choices
about the subpools. The translation to/from SP252 for naieve callers taking
the (SP0) default has been around longer than I have. But I doubt very much
that that would even help in this case. The interface specification for the
API says...

* Enabled for I/O and external interrupts
* Holds no locks
* In task control block (TCB) mode
* With PSW key equal to the job step TCB key  <=== Here's the first clue
something is wrong
* In primary address space mode
* In 31-bit addressing mode
* In either supervisor or problem program state <=== And here's the second
clue
* With no FRRs on the current FRR stack.

The doc goes on to say immediately after that;

"You can call the binder in both problem program and supervisor state and in
any PSW storage key."

The last statement appears to contradict the statement in the interface
definition, nevertheless as you are aware that statement is quite
problematic for privileged programs. The PSW key must match the job step
task's key - I believe that the requirement is specified this way because
load modules and program objects are step level resources and the binder
uses a low private step level subpool during processing.

But they also say the caller can be in supervisor state... and the only way
that could be a safe thing to do would be in an address space with an APF
authorized job step task, or in an address space with a system protection
key specified via PPT. The more prosaic case of a piece of (privileged)
infrastructure code performing a service on behalf of a completely
non-privileged program appears to me to be ruled out on integrity grounds
despite the ambivalence in the wording of the documentation.

I believe that the API was written in a completely naieve fashion much like
any other batch program and certainly without any thought to properly
handling the nuances presented by a privileged caller in an otherwise
non-privileged environment. Given that, we elected not to persevere with
using it. However, just to be crystal clear. These deficiencies of the API
were only the final icing on the cake. The real deal-breaker is that the
multipart class architecture of PM3 (as currently implemented) is unusable
at all. So even if the binder API were to be refactored at some time in the
future to behave like any other well formed system service, the result would
be moot.

CC
-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Shmuel Metz (Seymour J.)]

In ,
on 08/28/2009
   at 12:10 AM, Jim Mulder  said:

>Since MVS/XA:

The conversion of subpool 0 to 252 goes all the way back to OS/360.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Shmuel Metz (Seymour J.)]

In , on 08/27/2009
   at 09:42 PM, "William H. Blair"  said:

>Normally, one does not run in key 0 problem state,

Started tasks normally run in problem state even when the key is 0. I'd
guess that IBM ships more code that runs key 0 problem state than the do
running in supervisor state. 

Peter?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Jim Mulder]

IBM Mainframe Discussion List  wrote on 08/27/2009 
10:42:25 PM:

> Peter Relson wondered:
> 
> > I can't remember if that also requires supervisor state
> 
> Actually not (or at least it did not used to). Normally, one does
> not run in key 0 problem state, but it's fairly easy to get into
> that state with an APF-authorized job step and the MODESET macro.
> At one point in a test program (I run lots of those just to see 
> what MVS does), when I had intended to get into supervisor state
> first, I didn't. I thus found myself in just key zero. It went
> on to bomb later because I wasn't in supervisor state, but for a
> while it did its best. In any event, it did ask for the default
> subpool (0) in just key 0, and it did get subpool 252, in fact.
> 
> That was not recent, but I have no clue now how long ago it was.
> I'm old enough now not to be embarrassed to say I don't remember.

  Actually yes, at least for the past 30 years.

Since MVS/XA:

  /* TITLE:  Replaces key-zero-supervisor requests for subpool 
0 with subpool 252. */
 IF VSWKKEY=''B/* If caller is system key   @D4M*/
   & VSWKSTAT=SUPERVI  /* and supervisor state  */
   & VSWKEXSP=SPZERO THEN  /* Subpool zero  */
   DO; /* Subpool 252 handling  */
 VSWKSPTT=IGVT0252(1:LENGTH(SPTTENT));/* Move in subpool 252*/
 VSWKTCB=TCBJSTCB; /* Step related storage needs the 
  job step TCB  */
 VSWKSKEY=ZERO;/* 252 has a specific key*/
   END;/* Subpool 252 handling  */
 ELSE  /* Subpool 0 thru 127*/
   VSWKSKEY=TCBPKF;/* Key comes from the owning TCB */

 And yes, the comment is wrong - it should say 
"If caller is key 0", not "If caller is system key".

  And the oldest pre/MVS/XA code I can find (definitely older than 
SP1.1):

 D10JHM1.IEAVGM00.P85.ASM 


 ICRWORK,RBOPSW+C1 GET KEY AND MODE  Y02714
 STC   RWORK,MODE  SAVE IN LDARQSTA  Y02714

...
 
*FIND SUBPOOL QUEUE ELEMENT FOR PROBLEM PROGRAM SUBPOOLS 22540001
*  AND FOR SUBPOOLS 250, 251, AND 252 22560002
* 22580001
 SPACE 1 2261
PGTSPQE  TMMODE,KEY0+SUP   KEY 0 AND SUPERVISOR STATEY02714 
22660002
 BZSUPVPPSPYES 22680001
 
 

SUPVPPSP TMMODE,SUBFRMNSUBPOOL FREEMAIN? 
 BOPGTSPQE1YES 
 LTR   RSPID,RSPID IS THIS SUBPOOL 0 Y02714
 BNZ   PGTSPQE1NO, LEAVE AS IS   Y02714
 LARSPID,C252  CHANGE TO SUBPOOL 252 Y02714
 


 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[William H. Blair]

Peter Relson wondered:

> I can't remember if that also requires supervisor state

Actually not (or at least it did not used to). Normally, one does
not run in key 0 problem state, but it's fairly easy to get into
that state with an APF-authorized job step and the MODESET macro.
At one point in a test program (I run lots of those just to see 
what MVS does), when I had intended to get into supervisor state
first, I didn't. I thus found myself in just key zero. It went
on to bomb later because I wasn't in supervisor state, but for a
while it did its best. In any event, it did ask for the default
subpool (0) in just key 0, and it did get subpool 252, in fact.

That was not recent, but I have no clue now how long ago it was.
I'm old enough now not to be embarrassed to say I don't remember.

--
WB

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Peter Relson]

There is no subpool that would satisfy both of the following
-- work for unauthorized callers running in their state and key
-- work for authorized callers running in their state and key and not come
out of "low private" (where "low" refers to the user region, not to "below
16M")

So it's at least not simply a matter of subpool choice (since "low
private" is usually a concern for an authorized application).

Yes, of course, an application could at runtime select which subpool to
use.

This thread had made me think about this a few days ago.

I wonder if they happen to use subpool 0 which might, at least, let a key 0
invocation work (as it would be translated to subpool 252; I can't remember
if that also requires supervisor state)

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Shmuel Metz (Seymour J.)]

In , on 08/24/2009
   at 10:50 AM, Pinnacle  said:

>Unfortunately, too many people on IBM-Main expect IBM to respond here, 
>instead of either opening a PMR or a requirement. 

Or sending a Reader Comment Form. And, yes, some of the latter do get
acted on appropriately. Sometimes the authors even send me advance co[pies
of the new text.

As for requirements, I know of one case where a Share requirement was
rejected asn subsequently implemented, so I agree, let IBM know through
channels what your issues are.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Leona Baumgart]

The binder API was never intended to be used as a 'full-fledged system service'
in the sense used here and so I believe the binder documentation
will continue to state that the caller must be in TCB key.  That said,
I have reason to believe that the binder API will actually work
with a key zero supervisor state caller.

Leona Baumgart
z/OS Binder development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Chris Craddock]

On Tue, Aug 25, 2009 at 4:01 PM, Tony Harminc  wrote:

> 2009-08-25 William H. Blair  wrote:
>
> > Until the binder API can function as a full-fledged system
> > service, it can't be used by any code that, itself, has to
> > adhere to the previously-established and long-recognized
> > MVS systems integrity and security guidelines.
>
> TSO TEST/TESTAUTH is a (sometimes) successful system-key caller of the
> Binder API. It has had many problems over the years, but it mostly
> seems to get what it needs. Back in 1997 TEST evidently started using
> IEWBIND for everything, and that was soon pulled out for the normal
> case of running from a PDS, because of appalling performance. But it's
> certainly in there at least for the PDSE case, and seems to work.
>

My (potentially faulty) recollection was that calling the API in supervisor
state and/or with a PSW key other than the job step task's key (almost
always 8) very rapidly got you an abend. The reason for that seemed at the
time to be rather naieve choices of subpools for step level resources. At
the time those looked like pretty simple air-head coding choices that could
have been readily changed to something that would have worked correctly for
both privileged and non-privileged callers. But n. Couldn't do that.

-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Tony Harminc]

2009-08-25 William H. Blair  wrote:

> Until the binder API can function as a full-fledged system
> service, it can't be used by any code that, itself, has to
> adhere to the previously-established and long-recognized
> MVS systems integrity and security guidelines.

TSO TEST/TESTAUTH is a (sometimes) successful system-key caller of the
Binder API. It has had many problems over the years, but it mostly
seems to get what it needs. Back in 1997 TEST evidently started using
IEWBIND for everything, and that was soon pulled out for the normal
case of running from a PDS, because of appalling performance. But it's
certainly in there at least for the PDSE case, and seems to work.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[William H. Blair]

William Blair wrote:

> Until the binder API can function
> as a full-fledged system service, it can't be used by any
> code that, itself, has to adhere to long-established MVS 
> integrity and authority guidelines.  

That could have been better worded, as follows:

Until the binder API can function as a full-fledged system 
service, it can't be used by any code that, itself, has to 
adhere to the previously-established and long-recognized 
MVS systems integrity and security guidelines.  

--
WB

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[William H. Blair]

Leona Baumgart stated: 

>  If LE is not available

Uh ... since LE is part of the BCP, how, exactly, would it ever
be "not available?"  I am not disputing that there is, perhaps,
some test that the binder code makes, but I cannot imagine what
that test is. 

> will re-contact both Chris and William Blair about their list 
> of concerns.

Looking forward to it. But - perhaps to save you some work - you
should be aware that the resolution of most (if not all) of the
issues identified in the past will be of absolutely no value to
us whatsoever unless and until the restriction that the binder
[API] cannot be invoked by a key zero routine in ANY arbitrary
address space (within reason -- we are not expecting to do this
inside of PCAUTH, for example) in a task whose TCB key is _not_
also zero. In other words, unless we can invoke the binder API
in key zero (for the binder API to run in key zero) in a TCB 
whose TCB key is, say, 4, 8, 1, 6, or 7, and possibly even 2,
3, or 5, then any fixes or workarounds for all of the other 
issues would not be of any benefit (except, possibly, to some
others). 

That may be why some of the dialog (in the past) was not 
continued or completed. Until the binder API can function
as a full-fledged system service, it can't be used by any
code that, itself, has to adhere to long-established MVS 
integrity and authority guidelines.  

--
WB

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Thomas David Rivers]

Bill Klein wrote:

*JUST* on the issue of the Binder API requiring the LE run-time, I have a
question for you (WB)

Were your discussions with "STL" done before or after "Metal-C" became
available?  It would seem to me (and I certainly could be ENTIRELY wrong on
this), that a SHARE requirement to provide a "Metal-C" (no LE library
required) version of the Binder API *might* receive a positive IBM response
NOW.  While asking for a "no LE version" of the Binder API *before* Metal-C
was available received a negative response.

As I have said before, I just don't see the "harm" in creating a SHARE
requirement for this (or any other Binder "enhancement").  Occassionally
(not all that often) IBM does provide solutions for SHARE requirements where
"similar" individual site marketting requests get rejected.

"William H. Blair"  wrote in message
news:...


Just to keep from loosing some perspective - Dignus' Systems/C
has been available for some time... one might imagine someone
choosing that for an implementation before Metal-C was available.

Metal-C seems to be adopting many of Systems/C features as it
evolves...

- Dave Rivers -


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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Leona Baumgart]

I just want to add a few comments to Peter Relson's post.  

1. The binder and LE: The binder uses LE only to produce the C++ demangled
name/mangled name cross reference in the listing.  If LE is not available,
the only consequence is that an informational message is issued and the
report is not written.
2. I am working on updating the lengthy note I sent to Chris last October
and will re-contact both Chris and William Blair about their list of concerns.
3. I am also looking into David Day's original complaint. The current
documentation of the behavior is in the SECTION parameter description under
GETD and GETE in the Program Management Advanced Facilities manual. I am
checking its accuracy. At a minimum I think some clarification and
additional words would make it more useful to the API user.  This
investigation could take me a few days to complete.   

I agree with Peter that SHARE requirements would be very useful in getting
prioity for new functions.

Leona Baumgart
z/OS Binder Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Peter Relson]

Given the rather violent discussion on this topic, I urge folks to step
back. Especially given that the thread now is going down a path that is
based on incorrect assertions, namely that the binder uses LE even if no
C/C++ code is involved. I asked, and they said that it does not, except to
resolve things such as mangled names that are related to use of C/C++ and
LE.

Several of the posts seem to be based on a premise that the poster's use is
the only way one would want to use a function, so when that is not
available, therefore the function is useless. It's obviously not as useful
as one would want but that can be a far distance from useless.

If there are functions that are hard to use, is it because of poor
documentation? I fully believe that there is always lots of room for
improvement of our documentation, and specific suggestions are usually
well-taken to heart, as opposed to something like "improve the
documentation".

If there are functions that are not available or do not do what you want,
then I suggest that you submit suitable requirements, and the more backing
you can get for them, naturally, the better. A requirement from Share is
going to get more weight than a requirement from an individual.

Note to CC: Leona attempted to have a dialog with you last year about your
concerns and got no response from you, so presumed you were no longer
interested in the topic. Perhaps the note got lost...

The binder team will surely get in contact with those who care to have a
forward-going dialog.

As to David Day's initial post of this thread: I don't know what to
'expect' but apparently the behavior is documented, for what that's worth.
I actually looked at the output posted and thought "maybe they do it in
alphabetical order".  That's what it appeared like from the small sample,
but that's not the answer either.

Peter Relson
z/OS Core Technology Design
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Fw: Fw: Binder API...broke or working as designed

[Chris Craddock]

There you go thinking logically again Pat...

On Mon, Aug 24, 2009 at 5:45 PM, Patrick O'Keefe wrote:

> On Mon, 24 Aug 2009 14:56:05 -0500, William H. Blair
>  wrote:
>
> >...   The problem for us
> >was that we could not invoke the binder API as we assumed we
> >would be able to, and the reason had to do with restrictions
> >that originate in LE.  For our application, that was a pretty
> >clear-cut issue ... "You can't do that."
> >...
>
> Warning:  The following comment is based on total ignorance.
>
> It seems like better (but MUCH longer term) goal would be to have
> the restrictions in LE relaxed ot removed.  If IBM is going to use LE
> functions as general purpose subroutines these functions work where
> needed and expected.
>
> Since I don't know what functions and restrictions are involved, I may
> be suggesting that fundimental laws of the universe be changed.
> But since the whole excercise may be tilting at windmills, this is just
> a probably just a bigger windmill.
>

ROTFLMAO! It would be easier to redefine the speed of light or the fine
structure constant of the universe than get a do-over on LE. Without going
into gory details, the LE runtime is written in such a way as to be
completely unusable by privileged programs, or indeed even by programs that
are ephemeral (like exits) and only briefly need a runtime to provide
working storage and perhaps recovery.

The existence of Metal C is tacit acknowledgement of that fact.

-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Fw: Fw: Binder API...broke or working as designed

[Patrick O'Keefe]

On Mon, 24 Aug 2009 14:56:05 -0500, William H. Blair 
 wrote:

>...   The problem for us
>was that we could not invoke the binder API as we assumed we
>would be able to, and the reason had to do with restrictions
>that originate in LE.  For our application, that was a pretty
>clear-cut issue ... "You can't do that."
>...

Warning:  The following comment is based on total ignorance.

It seems like better (but MUCH longer term) goal would be to have
the restrictions in LE relaxed ot removed.  If IBM is going to use LE
functions as general purpose subroutines these functions work where
needed and expected.  

Since I don't know what functions and restrictions are involved, I may
be suggesting that fundimental laws of the universe be changed.
But since the whole excercise may be tilting at windmills, this is just
a probably just a bigger windmill.

Pat O'Keefe  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[William H. Blair]

> Were your discussions with "STL" done before or after 
> "Metal-C" became available?

Yes: before AND after. I had to examine my archives and files 
to answer your question. They took place around these dates:

  Most weeks every month during:

   o February through August 2001
   o March through June 2002
   o August through November 2002
   o July 2008

 and scattered days in-between.

I consider the February 2001 through November 2002 extended
conversation the "first engagement." The second one was held
in July 2008 when IBM came to us (and another customer) for
explanation.  Basically, we just re-sent the same emails we 
had sent to IBM before in 2001-2002 to the new point person 
du month for the issue -- with newly-written cover letters 
and more patient explanations attached.  

> As I have said before, I just don't see the "harm" in 
> creating a SHARE requirement for this

There would obviously be no extraordinary harm in doing so.

Since Dave Day has a head start, let's see how far he gets
with his problem. But I suspect he isn't going to get into any 
issue that resulted in our abandoning the use of the binder API
at this end. He observed something odd and unexpected that very
much surprised him. Now, will IBM consider what he has found to
be a bug (this time)? I have a prediction: No. It will be a WAD.
We shall see (if we're lucky).

--
WB 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Binder API...broke or working as designed

[Bill Klein]

*JUST* on the issue of the Binder API requiring the LE run-time, I have a
question for you (WB)

Were your discussions with "STL" done before or after "Metal-C" became
available?  It would seem to me (and I certainly could be ENTIRELY wrong on
this), that a SHARE requirement to provide a "Metal-C" (no LE library
required) version of the Binder API *might* receive a positive IBM response
NOW.  While asking for a "no LE version" of the Binder API *before* Metal-C
was available received a negative response.

As I have said before, I just don't see the "harm" in creating a SHARE
requirement for this (or any other Binder "enhancement").  Occassionally
(not all that often) IBM does provide solutions for SHARE requirements where
"similar" individual site marketting requests get rejected.

"William H. Blair"  wrote in message
news:...
> Paul Gilmartin asks:
> 
> > In what language is the binder written?
> 
> As far as I know, PL/X. But the binder itself is not actually
> the problem. It's the C/C++ / LE-dependent routines that the
> binder [API] invokes; they are the cause of the entanglements
> that the binder [API] suffers from, apparently. At least that
> is IBM's explanation. We just took them at their word on this.
> Note that these routines are involved even if one doesn't have
> a line of C/C++ code. The binder uses (what they call) C/C++
> functions to perform some of _its_ functions. Very entangled.
> Very surprising (to us, and some other customers as well).
> 
> I have no interest in a semantic discussion. If the binder API
> requires LE, then does the binder require LE? For the purposes
> of our (then-intended) application, the answer was in fact yes.
> 
> But you can argue the point if you wish. The problem for us 
> was that we could not invoke the binder API as we assumed we
> would be able to, and the reason had to do with restrictions
> that originate in LE.  For our application, that was a pretty
> clear-cut issue ... "You can't do that."
> 
> "Why not?" "It's not our fault. It's an LE restriction. And,
> if anyone is going to document it, then it should be LE, not
> us [the binder]." "But you don't document anywhere that you
> use LE, so how would we know that, prior to invoking the 
> binder API, we should look up all these LE restrictions?"
> "OK, we'll document that you can't invoke the binder in that
> manner." And they did. And so, that ETR was closed with WAD: 
> not a binder problem.
>  
> > I would have imagined PL/S.  And I would have imagined that 
> > PL/S didn't require LE.
> 
> You are so right. So ... IF the binder [API] DID require LE,
> YOU would be astonished ...  right?  Well, we were.
> 
> > Why do you so strongly advocate Assemble as opposed to, say,
> > PL/S or Metal C, which ought not to require LE?
> 
> I consider PL/X equivalent to Assembler for the issues that
> are under discussion (there's no "runtime" involved). Besides, 
> I didn't "strongly advocate" Assembler. I just suggested it 
> as one implementation approach that, if adhered to, would 
> [obviously, like other things] avoid any LE entanglements.
> 
> I think you're reading far too much into what I have said.
> The binder suffers from LE restrictions. That surprised us,
> and I think it violates the principle of least astonishment. 
> 
> There are other ways in which the binder [API] violates the
> principle of least astonishment. The scuttlebutt from some
> IBM contact at SHARE is that "Well, this might be a bug."
> OK, so what? It's worked that way since PM2 (at least), so
> if it's a bug, then it's an old, old bug. But my point was
> that it obviously astonished Dave Day, just as it astonished
> us, and I attempted to inform him that other astonishments
> could be around the corner -- that's the way the binder is.
> 
> I never said that it was not a bug (in fact, I don't know),
> or that it should not be APARed, or that a SHARE requirement
> should not be written to address it. I just said that it was
> astonishing, like so much else (like nearly everything else
> we tried) with the binder [API]. That's all. 
> 
> But I did say it was BAD (broken as designed). In our world,
> IBM does not always consider that to be a bug to be fixed.
> 
> --
> WB

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Dave Day]

Dave Day wrote:
> Tom,
> Thanks for taking the time to talk with him.  If you would, get his email 
> address, name, or some way for me to contact him, and send it to me.

Are you same Dave Day I know from TDMs in Poughkeepsie? If so, you 
should already are familiar with Barry Lichtenstein. His email is on his 
presentations and also available via http://whois.ibm.com.

-- 
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318




Ed,
Thanks.  I didn't have a  name or contact within IBM for the Binder.   Now 
I do.  And yes, tis me whom you know from the TDM in Poughkeepsie.  I didn't 
remember a presentation on the Binder, but there was a lot at the last TDM that 
my brain just threw into the bit bucket.   

--Dave

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Fw: Fw: Binder API...broke or working as designed

[William H. Blair]

Paul Gilmartin asks:

> In what language is the binder written?

As far as I know, PL/X. But the binder itself is not actually
the problem. It's the C/C++ / LE-dependent routines that the
binder [API] invokes; they are the cause of the entanglements
that the binder [API] suffers from, apparently. At least that
is IBM's explanation. We just took them at their word on this.
Note that these routines are involved even if one doesn't have
a line of C/C++ code. The binder uses (what they call) C/C++
functions to perform some of _its_ functions. Very entangled.
Very surprising (to us, and some other customers as well).

I have no interest in a semantic discussion. If the binder API
requires LE, then does the binder require LE? For the purposes
of our (then-intended) application, the answer was in fact yes.

But you can argue the point if you wish. The problem for us 
was that we could not invoke the binder API as we assumed we
would be able to, and the reason had to do with restrictions
that originate in LE.  For our application, that was a pretty
clear-cut issue ... "You can't do that."

"Why not?" "It's not our fault. It's an LE restriction. And,
if anyone is going to document it, then it should be LE, not
us [the binder]." "But you don't document anywhere that you
use LE, so how would we know that, prior to invoking the 
binder API, we should look up all these LE restrictions?"
"OK, we'll document that you can't invoke the binder in that
manner." And they did. And so, that ETR was closed with WAD: 
not a binder problem.
 
> I would have imagined PL/S.  And I would have imagined that 
> PL/S didn't require LE.

You are so right. So ... IF the binder [API] DID require LE,
YOU would be astonished ...  right?  Well, we were.

> Why do you so strongly advocate Assemble as opposed to, say,
> PL/S or Metal C, which ought not to require LE?

I consider PL/X equivalent to Assembler for the issues that
are under discussion (there's no "runtime" involved). Besides, 
I didn't "strongly advocate" Assembler. I just suggested it 
as one implementation approach that, if adhered to, would 
[obviously, like other things] avoid any LE entanglements.

I think you're reading far too much into what I have said.
The binder suffers from LE restrictions. That surprised us,
and I think it violates the principle of least astonishment. 

There are other ways in which the binder [API] violates the
principle of least astonishment. The scuttlebutt from some
IBM contact at SHARE is that "Well, this might be a bug."
OK, so what? It's worked that way since PM2 (at least), so
if it's a bug, then it's an old, old bug. But my point was
that it obviously astonished Dave Day, just as it astonished
us, and I attempted to inform him that other astonishments
could be around the corner -- that's the way the binder is.

I never said that it was not a bug (in fact, I don't know),
or that it should not be APARed, or that a SHARE requirement
should not be written to address it. I just said that it was
astonishing, like so much else (like nearly everything else
we tried) with the binder [API]. That's all. 

But I did say it was BAD (broken as designed). In our world,
IBM does not always consider that to be a bug to be fixed.

--
WB

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[William H. Blair]

Tom Conley offered this:

> You should only be allowed to complain after your PMR is closed 
> WAD. 

Been there, done that, got the T-shirt. That's what started the 
various (and ultimately not fruitful) technical dialogs with STL. 
We actually had two of them. Another customer was involved the
second time.  Neither one went anywhere (to our satisfaction). 

The only difference was that the second time we knew in advance 
that it was likely to be a water haul. But some different folks
in IBM were involved the second time, so we gave it the college
try. But in the end, the result was the same: sorry, but that's 
just the way it works.

The problem is that while one can't APAR a violation of the 
principle of least astonishment, IBM themselves can and does
sometimes document that that is how certain things work.

--
WB

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Edward Jaffe]

Dave Day wrote:

Tom,
Thanks for taking the time to talk with him.  If you would, get his email 
address, name, or some way for me to contact him, and send it to me.


Are you same Dave Day I know from TDMs in Poughkeepsie? If so, you 
should already are familiar with Barry Lichtenstein. His email is on his 
presentations and also available via http://whois.ibm.com.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Dave Day]

Dave,

Had a long talk with the Binder API developer here at SHARE.  Unlike what 
other posters have said here, he is very willing to hear what you have to 
say.  But he can't address bugs or requirements in this forum.  It's 
possible that what you're seeing is a bug, so he'd like you to open a PMR to 
see exactly what you're doing, and maybe he can help.  After that, as Bill 
Klein says, perhaps a requirement should be opened.



Tom,
Thanks for taking the time to talk with him.  If you would, get his email 
address, name, or some way for me to contact him, and send it to me.  It is a 
customer load module that is doing this, sent to me to try to get to the bottom 
of a problem.  I don't know what restrictions I am working under vis-a-vis a 
NDA with the customer.  Would seem to me this shouldn't make any difference to 
them, but I don't know for sure, and will check.

--Dave

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[Pinnacle]

- Original Message - 
From: "Dave Day" 

Newsgroups: bit.listserv.ibm-main
Sent: Friday, August 21, 2009 4:17 PM
Subject: Binder API...broke or working as designed


I'm using the Binder API to read ESD records for a Program Object.  The 
sequence of the records returned are not in the order the csects are in, 
in the object.


What I'm seeing is this:

Class Offset for csect AA 1CCA4A   Element Offset 52
Class Offset for csect BB 1CF6BC   Element Offset 2CC4
Class Offset for csect CC 1CCAA0   Element Offset A8

I would have expected csect BB to be in the ESD buffer at it's relative 
position as far as Class and Element Offset.  I did not expect these 
entries to be in the buffer in non ascending order.  I'll change my code 
to check and place them in the internal map in correct order, but this 
sure seems broke to me.


   --Dave Day



Dave,

Had a long talk with the Binder API developer here at SHARE.  Unlike what 
other posters have said here, he is very willing to hear what you have to 
say.  But he can't address bugs or requirements in this forum.  It's 
possible that what you're seeing is a bug, so he'd like you to open a PMR to 
see exactly what you're doing, and maybe he can help.  After that, as Bill 
Klein says, perhaps a requirement should be opened.



Unfortunately, too many people on IBM-Main expect IBM to respond here, 
instead of either opening a PMR or a requirement.  There are a number of 
individuals who constantly complain about how badly things are implemented 
by IBM, but those same individuals haven't submitted a single requirement to 
fix them.  You should only be allowed to complain after your PMR is closed 
WAD or your requirement is closed SUG or REJ.



Regards,
Tom Conley 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Fw: Fw: Binder API...broke or working as designed

[Paul Gilmartin]

On Sun, 23 Aug 2009 16:00:22 -0500, William H. Blair wrote:
>
>
>Now, granted, the binder could be rewritten in another
>language that did not require LE, such as (dare I say
>it?!) Assembler. That, along with a better functional
>interface, could make it truly useful, even amazing.
>
In what language is the binder written?  I would have imagined
PL/S.  And I would have imagined that PL/S didn't require LE.

Why do you so strongly advocate Assemble as opposed to, say,
PL/S or Metal C, which ought not to require LE?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Fw: Fw: Binder API...broke or working as designed

[William H. Blair]

Bill Klein reminds us:

> ... but I *do* repeat that unless/until the SHARE
> requirement process is "tried" for such things, it 
> seems wrong to me to assume that it will NEVER work.

No "assumptions" are involved. A higher authority has
already been appealed to. IBM STL was, itself, at one
point, (seemingly) embarrassed by the limitations of the
API and came, hat in hand, asking for more details with
the right attitude and a genuine interest in getting it
right. The issues were (again) explained, and, while we
were hopeful that a satisfying outcome might result, it
soon became clear that nothing would ever happen, and
nothing __could__ _ever_ happen to address any of them.
It ended up with IBM tucking their tail between their 
legs. The most we  got out of the whole exercise was 
SRL changes that said, basically, "you can't do that."

While the minor irritations in the interface might be
able to be addressed a short number of miles South of
the Almaden Valley, the big ones are out of their hands.
NO amount of hand-wringing, requirement-accepting, or
code-writing is going to help, because the problems are 
not in any part of the code that they have any ability 
to change. Many of the binder API's limitations are due
to restrictions that originate in the shortcomings of
LE itself. And the binder depends on LE. Which means
that the binder has all the restrictions of LE, which
means that it can't effectively be used as a system
interface by privileged code. It's a house of cards.

Now, granted, the binder could be rewritten in another 
language that did not require LE, such as (dare I say
it?!) Assembler. That, along with a better functional
interface, could make it truly useful, even amazing. 

As Chris indicated, "the chances of such a requirement 
being delivered within the expected lifetime of the 
universe is pretty slim." But in this instance, he is
being just a bit optimistic (in my humble opinion). 
 
I bet I have been tilting at windmills longer than you
have, so I know as well as you should that IBM doesn't
have the resources -- much less the will -- to rewrite
the binder in Assembler to remove any such dependence.

It was one of those minor miracles that we got program
objects and the binder to begin with, but nonetheless
unfortunate that major portions of it were stillborn. 

--
WB 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Fw: Fw: Binder API...broke or working as designed

[Bill Klein]

"Chris Craddock"  wrote in message
news:...
> On Fri, Aug 21, 2009 at 11:29 PM, Bill Klein 
wrote:
> 

> Bill K... this is a can of worms best left unopened. Suffice to say Bill
> Blair's commentary is not actually a rant at all, but is based entirely on
> his own (and my own) direct personal experience with said component. He
does
> not need any help composing a SHARE requirement and in any case, as he
> indicated obliquely the chances of such a requirement being delivered
within
> the expected lifetime of the universe is pretty slim. I have promised my
> friends in IBM that I won't keep picking on the binder in public every
time
> the subject comes up, so I will just bite my tongue. You might want to as
> well.
> 
I am sorry that your experience has been "so bad".  However, I will keep
"harping" on the fact that IBM has indicated that they will process "binder"
requirements in the ASM project of SHARE.

As I say, I certainly can't guarantee what will be "accepted" and when such
will be implemented, but I *do* repeat that unless/until the SHARE
requirement process is "tried" for such things, it seems wrong to me to
assume that it will NEVER work.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Fw: Binder API...broke or working as designed

[Dave Day]

Thanks for the responses.  After reading the manual, and writing the code to 
use the API's, I have to say it is(at least for me) one of the more obtuse 
pieces of code and manual I have ever come in contact with.  I've adjusted the 
code to handle the situation, and will move on.  

--Dave Day

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Fw: Binder API...broke or working as designed

[Chris Craddock]

On Fri, Aug 21, 2009 at 11:29 PM, Bill Klein  wrote:

> I know that ranting on IBM-MAIN is always a good way to spend your time,
> but
> 
>
> Are you aware that the "ASM" project at SHARE accepts and processes
> requirements against the Binder?  If anyone who participates in SHARE needs
> assistance in creating a "binder" requirement, please feel free to contact
> me "off-list".
>
> Obviously, I can't say that IBM will respond "as you want them to" but it
> does have a SLIGHTLY better chance than ranting on IBM-MAIN - in getting
> the
> "desired" fix to the binder.
>
> "William H. Blair"  wrote in message
> news:...
>  > Dave Day expressed his genuine surprise (how novel!)
> > regarding the behavior of the Binder API, thusly:
> 
>


Bill K... this is a can of worms best left unopened. Suffice to say Bill
Blair's commentary is not actually a rant at all, but is based entirely on
his own (and my own) direct personal experience with said component. He does
not need any help composing a SHARE requirement and in any case, as he
indicated obliquely the chances of such a requirement being delivered within
the expected lifetime of the universe is pretty slim. I have promised my
friends in IBM that I won't keep picking on the binder in public every time
the subject comes up, so I will just bite my tongue. You might want to as
well.

-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Fw: Binder API...broke or working as designed

[Bill Klein]

I know that ranting on IBM-MAIN is always a good way to spend your time, but


Are you aware that the "ASM" project at SHARE accepts and processes
requirements against the Binder?  If anyone who participates in SHARE needs
assistance in creating a "binder" requirement, please feel free to contact
me "off-list".

Obviously, I can't say that IBM will respond "as you want them to" but it
does have a SLIGHTLY better chance than ranting on IBM-MAIN - in getting the
"desired" fix to the binder.

"William H. Blair"  wrote in message
news:...
> Dave Day expressed his genuine surprise (how novel!) 
> regarding the behavior of the Binder API, thusly:
> 
> > I did not expect these entries to be in the buffer 
> > in non ascending order.  I'll change my code to 
> > check and place them in the internal map in correct 
> > order, but this sure seems broke to me.
> 
> I will add your name to my list of folks who, quite
> irrationally, insist on thinking rationally. Welcome
> to the club. Miss Manners (should she ever understand
> computer science) would surely chide you regarding 
> this faux pas. But while others might admire you for
> your persistence, I will just politely suggest that 
> you never do it again (at least in public, that is). 
> 
> The Binder API is without exception the most blatant
> violator of the principle of least astonishment that 
> has ever been implemented in any piece of software by
> any software company or by any programmer on Earth. 
> 
> Even after reading its obtuse documentation, this so-
> called API failed at literally EVERYTHING I expected 
> it to be able to do. These issues were appropriately
> (if incredibly) noted by various IBMers but the only
> thing that was ever done was (if anything) to update
> the documentation to say "Oh! But you can't do this!"
> 
> Like many frail facilities offered proudly by IBM as
> "the answer to all of our stated requirements," this
> one just does what it does and no more. Any thought
> that it might actually be straightforward or simple
> to use is inconsistent with reality. You didn't really
> expect the binder to sort the entries presented prior
> to returning them to you, did you? How presumptuous. 
> 
> So yes, it's BAD broke -- broken as designed (BAD).
> 
> My condolences.
> 
> --
> WB

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Binder API...broke or working as designed

[William H. Blair]

Dave Day expressed his genuine surprise (how novel!) 
regarding the behavior of the Binder API, thusly:

> I did not expect these entries to be in the buffer 
> in non ascending order.  I'll change my code to 
> check and place them in the internal map in correct 
> order, but this sure seems broke to me.

I will add your name to my list of folks who, quite
irrationally, insist on thinking rationally. Welcome
to the club. Miss Manners (should she ever understand
computer science) would surely chide you regarding 
this faux pas. But while others might admire you for
your persistence, I will just politely suggest that 
you never do it again (at least in public, that is). 

The Binder API is without exception the most blatant
violator of the principle of least astonishment that 
has ever been implemented in any piece of software by
any software company or by any programmer on Earth. 

Even after reading its obtuse documentation, this so-
called API failed at literally EVERYTHING I expected 
it to be able to do. These issues were appropriately
(if incredibly) noted by various IBMers but the only
thing that was ever done was (if anything) to update
the documentation to say "Oh! But you can't do this!"

Like many frail facilities offered proudly by IBM as
"the answer to all of our stated requirements," this
one just does what it does and no more. Any thought
that it might actually be straightforward or simple
to use is inconsistent with reality. You didn't really
expect the binder to sort the entries presented prior
to returning them to you, did you? How presumptuous. 

So yes, it's BAD broke -- broken as designed (BAD).

My condolences.

--
WB

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Binder API...broke or working as designed

[Dave Day]

I'm using the Binder API to read ESD records for a Program Object.  The 
sequence of the records returned are not in the order the csects are in, in the 
object.

What I'm seeing is this:

Class Offset for csect AA 1CCA4A   Element Offset 52
Class Offset for csect BB 1CF6BC   Element Offset 2CC4
Class Offset for csect CC 1CCAA0   Element Offset A8

I would have expected csect BB to be in the ESD buffer at it's relative 
position as far as Class and Element Offset.  I did not expect these entries to 
be in the buffer in non ascending order.  I'll change my code to check and 
place them in the internal map in correct order, but this sure seems broke to 
me.

--Dave Day

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html