ISPF option 3.4, doing a "z" on a PDS to compress it will result in a DISP=OLD type allocation. This is the only thing that _I_ know of which does this. Of course doing a TSO ALLOCATE command in a REXX program, CLIST, or using the TSO command option (option 6), the user can directly do it directly.
As a curiosity answer, ISPF has three possible resource names used with the qname of SPFEDIT. For the member of a PDS, it is 52 bytes long consisting of the DSN, padded with blanks to 44 characters followed by the member name, padded to 8 characters by blanks. For a sequential DSN, or a PDS when actually saving a member, it is the 44 character, blank padded, DSN. For a UNIX file, it is 12 bytes consisting of a 4 byte inode number, 4 byte device number, and 4 bytes "sysplex indicator" value (x'00000000' - no UNIX sysplex, x'00000020' - UNIX sysplex file sharing active). The above isn't relevant to the question, but I felt like running off at the keyboard. On Thu, Apr 3, 2014 at 12:41 PM, Chase, John <[email protected]> wrote: > Hi, List, > > z/OS 1.13 at RSU1312. The other day, a user "did something" in ISPF that > caused allocation of a Production JCL library to his TSO session with > DISP=OLD instead of DISP=SHR, causing a "hiccup" in batch processing when > the scheduler was "locked out" for a few seconds. So far, we have not been > able to replicate "locking out" another user at the dataset level via any > combination of manipulations using (primarily) ISPF EDIT. > > Here's a SMF14 record formatted by DAF (Thank you, Michael J. Cleary!!): > > 014 VOL=volser DD=ISP15297 OPE=15.30.06.51 CRTDT=02045 EXPDT=00000 > DISP=Old > BUFNO=16 DSORG=PO RECFM=FB BLKSIZE=7520 LRECL=80 NVOL=1 CTRI=CYL > SQTY=50 > NTU=00582800 NTA=6000 VOL=OPER9A DEVTYPE=3390 NEX=1 EXCP=4001 > STEP=tsoproc > PGM=IKJEFT01 14XF1=192 14CIS=18090271 14TKL=58051 > > The SMF 42-006 that immediately follows: > > 042 006 JDCOD=Close DSTYP=PDS DSFL1=Non-VSAM_fixed_length_records > VOL=volser DSDEV=ccuu > DSBSZ=256 DSIOR=9 DSIOC=7 DSIOP=1 DSION=256 DSSEQ=256 DSMXR=58 > DSMXS=57 > AMSRB=4000 AMSRR=2562 > > The timestamps on those two records are identical down to hundredths of a > second, so maybe the user was running a SuperC search? We can't tell from > evidence available to us today. > > We've tried every combination we can think of with multiple users ISPF > EDITing the same dataset, and the only time we get any "conflict" is if a > second user tries to open a MEMBER for EDIT that is already opened for EDIT > by another user; and we believe that "lockout" at the member level is > accomplished via an ENQ named SPFEDIT.membername or something like that. > IOW, we have been unable to cause a dataset (PDS or PDSE) to be > dynamically allocated with DISP=OLD using any variant of ISPF EDIT. > > Is there any other way within ISPF that an existing dataset can be > dynamically allocated with DISP=OLD? If there is, we apparently have never > encountered it before. > > TIA, > > -jc- > > ********************************************************************** > Information contained in this e-mail message and in any attachments > thereto is confidential. If you are not the intended recipient, please > destroy this message, delete any copies held on your systems, notify the > sender immediately, and refrain from using or disclosing all or any part of > its content to any other person. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
