On 2016-04-29, at 15:06, R.S. wrote: >> >> Works for me. > You are right. Please rerun the job. I bet you'll get SB214 abend. > I know that well. I assumed that since the OP's requirement was to avoid overwriting an existing member, SB214 would meet his need.
I had considered the alternative of ISPEXEC LMCOPY with no REPLACE option. Alas, LMINIT won't accept a DDNAME generated by ISPF API (another silly restriction.) > My description was innacurate (I'm sorry for that!), however I meant MOD as > appending existing memebr. It is not possible. > BTW: simple JCL workaound is to copy member to a PS, append it and then > overwrite the member (overwrite is possible, despite of PDS vs PDSE internal > processing, I mean what enduser see). > Or, copy to a temporary PDS member using JCL DD concatenation; delete, and rename. Very slightly less I/O. I understand the structure of a PDS well enough to know that appending to an existing member is nearly impossible. Since I don't know PDSE internals but I suspect that a member isn't necessarily stored contiguously, I'm unable to infer a reason for prohibiting appending to a PDSE member. Or, use UNIX files, which impose no such silly restriction on appending. > Regarding SDSF, the forbiden DISP and DSORG combination can be result of SDSF > dialog logic, not the access method restriction. > I suspect likewise. > Unfortunately, it is possible to overwrite a member by mistake using the > dialog > So the designers, for unknown reasons, introduced an idiosyncratic syntactic restriction that precludes a conventional means of prudently avoiding overwriting. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
