On Sat, 25 Oct 2025 20:58:21 +0000, Peter Relson <[email protected]> wrote:

>> first obj does the I/O and presents it to the second obj
>> I can use test to debug obj’s

>I remain clueless of why you want to use the binder other 

Ignoring the fluff in the OP's statements (see above), it becomes clear that 
the op believes testing his 2 objects is impossible because TSO TEST that only 
allows 1 dataset to be specified. As I mentioned before, there are multiple 
supported solutions (e.g. bundle the objects together in a single member or as 
a single load module). Maybe he is using LINK in obj1 to call obj2, which in 
that case would require obj2 be linked (if TEST LOAD subcommand doesn't support 
objects). 

>>If I make a perm obj I can load it via IEWBIND 

The OP doesn't understand that calling IEWBIND from within TSO TEST won't solve 
his problem nor is recommended for use in TSO TEST. TSO TEST calls the binder 
internally and he should be using one of the supported binder facilities (e.g. 
DSN parm of test command, TEST LINK subcommand, TEST LOAD subcommand or ???).

>>The second is a temp data set from syslin &&amp;obj

The OP mentions DSN &&amp;OBJ which begs many more questions.

>>This scenario makes it hard to debug outside of wto’s
>>If I make a perm obj I can load it via IEWBIND 

This scenario is not harder to debug using TSO TEST. I believe TSO TEST uses 
the BINDER under the covers to load load-modules and objects into unprotected 
storage. Why not bind the objects outside of TSO TEST after assembly?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to