Ed, please reread my first post!
>If that's the case, then the fault lies with LE and not BCPii. How is LE to know that it runs under an implicit sub=mstr? That is not how your standard Cobol/PL/I program runs. What started this off was our general setting of HEAPCHK(ON) on request of application development. It seems that one LE enclave terminates which (with HEAPCHK on) wants to write a short 'ceedump' to JES2 spool with the heap statistics. When that fails, LE issues a U4087 (I think) and tries an IEATDUMP. >If the allocation for CEEDUMP fails, then the dump should be taken (for >example) with IEATDUMP. *We* have an explicit LE statement DYNDUMP that directs *any* dump to HLQ TDUMP. BCPII has *chosen* to overwrite that setting by specifying part of the LE Default for DYNDUMP, which is the userid of the address space. STC users are not allowed to allocate data sets (RACF audit requirement), hence the general HLQ of TDUMP (instead of userid). Which HWIBCPII has overwritten. Either HWIBCPII is LE-enabled (which I find very questionable for a system address space started via OS abracadabra), then it will have to set/override *all* options that require JES in one way or another or are otherwise harmful and not just a select few that are proudly documented in the books to be overwritten if allowed, *or* the address space should NOT be LE-enabled at all. Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
