Re: PDSE member profile
When I say 'explainable', I just mean that the road from the past to here can be explained, but I don't mean to say that it is justifiable. I agree, it should have been lifted higher up in the platform somewhere in the 80's. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, June 27, 2014 18:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDSE member profile On Fri, 27 Jun 2014 13:51:51 +, Vernooij, CP (SPLXM) - KLM wrote: Yes!. In our group, we all have activated an 'initial macro' that sets for certain datasets some of the attributes we require, like STATS, AUTOSAVE OFF PROMPT (to avoid PF3's unintentionally saving modifications). And I suppose it can even be project-sensitive, implied by certain data sets. About what you call IBM chaos: if you look at the history of these features, it is explainable how things grew this way. No, it's not explainable unless you tolerate irresponsibility. It could have been done right when the decision was made to do it at all. The function should have been provided in Allocation so it would be available alike to ISPF, SVC99, TSO ALLOCATE, BPXWDYN, and Batch JCL. Then we got problems with batch updating PDS's that were in use constantly by ISPF users, which was solved by batch updating the PDS with DISP=SHR, which corrupted a PDS once in every 1000 to 100 times. Really!? Shocking! When I confronted the problem, with a naive caution I resorted to invoking ISPF LM services in batch IKJEFT01 to preserve integrity. Then PDSMAN intercepted disp=shr batch by adding the SPFEDIT enq and the linkage editor was doing likewise. And even ISPF and linkage editor don't use the same ENQ. (I believe ISPF uses both if RECFM=U.) Alas, PDSMAN appears to be an ISV product, and can't be relied on to be available in every customer shop. And we, as an ISV, may be compelled to test twice, once for compatibility with PDSMAN, and once for integrity absent PDSMAN. Now we have come to the chaos you describe and yes, someone with a supervising view could have stopped this trend and decided to do this at platform level, but this did not happen. It's never too late. It is like a couple of guys developing a communication protocol for their computer connections that suited their needs, but now it is used as 'internet' and the total world economy depends on it, it should have been developed differently. At least, unlike allocation/ENQ which is chaotic even within a single OS from a single vendor, TCP/IP is uniform across all vendors (unless you regard SNA as a viable competitor). (couple of guys seems to be devaluing DoD ARPA and NSF.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
On 6/27/2014 5:44 AM, Buckton, T. (Theo) wrote: Hi There, Which process determines the profile of a member in a PDSE (Library) data set. Better question: What determines the profile ...; there is no 'process'. There are some default profiles provided with the system. Generally, the low level qualifier of the dataset name (sequential, PDS, PDSE) is chosen as the profile name. If this name is not known, the general default profile attributes are copied to the profile and when you exit from edit, the new profile is saved. You can change the attributes of the current profile by issuing commands, usually the same as the attribute names, e.g.: == number off or == num off == recovery on or == rec on and so on. If the profile is unlocked, when you exit the edit, the new attributes for this profile are saved. If the profile is locked, first issue == profile unlock and go on from there. Kind regards, -Steve Comstock When one browses the PDSE, views the member and enter PROFILE on the command line of the member, it brings up some attributes. How are these attributes determined: Eg. DECKS (FIXED - 80)RECOVERY OFF WARNNUMBER OFF... CAPS ONHEX OFFNULLS ON STDTABS OFF.. AUTOSAVE ONAUTONUM OFFAUTOLIST OFFSTATS ON.. PROFILE UNLOCKIMACRO NONEPACK OFFNOTE ON HILITE OFF CURSOR FIND.. Regards Theo Buckton Nedbank Limited Reg No 1951/09/06. The following link displays the names of the Nedbank Board of Directors and Company Secretary. [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is confidential and is intended for the addressee only. The following link will take you to Nedbank's legal notice. [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
Buckton, T. (Theo) wrote: Which process determines the profile of a member in a PDSE (Library) data set. When one browses the PDSE, views the member and enter PROFILE on the command line of the member, it brings up some attributes. How are these attributes determined: These attributes came from different sources: ISPF defaults, ISPF configuration table, your own profiles, your usage of edit macros (before edit or during logon) and the of course your own commands as issued by you. DECKS (FIXED - 80)RECOVERY OFF WARNNUMBER OFF... CAPS ONHEX OFFNULLS ON STDTABS OFF.. AUTOSAVE ONAUTONUM OFFAUTOLIST OFFSTATS ON.. PROFILE UNLOCKIMACRO NONEPACK OFFNOTE ON HILITE OFF CURSOR FIND.. Note some attributes may be overridden/locked by your ISPF configuration table. For example, I have overridden site wide these attributes: RECOVERY (make it ON) and STATS (FORCE it ON). Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
I am going to add my $0.02 to the other responses already posted. 1. When it is stated Lowlevel qualifier that is the last part of the data set name, in this case, DECKS. So any data set that ends in DECKS, e.g.; WALA.WALA.DING.DONG.DECKS, ONE.TWO.THREE.DECKS, or MUCKA.MUCKA.MUCKA.DECKS(ABCDEFG), could use this profile, if it also has #2. 2. The data set has a FIXED length LRECL of 80 (BLKSIZE is not used). If the data set ended in DECKS, but was a VARIABLE length record file, then a different profile would be used. Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Buckton, T. (Theo) Sent: Friday, June 27, 2014 7:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PDSE member profile Hi There, Which process determines the profile of a member in a PDSE (Library) data set. When one browses the PDSE, views the member and enter PROFILE on the command line of the member, it brings up some attributes. How are these attributes determined: Eg. DECKS (FIXED - 80)RECOVERY OFF WARNNUMBER OFF... CAPS ONHEX OFFNULLS ON STDTABS OFF.. AUTOSAVE ONAUTONUM OFFAUTOLIST OFFSTATS ON.. PROFILE UNLOCKIMACRO NONEPACK OFFNOTE ON HILITE OFF CURSOR FIND.. Regards Theo Buckton Nedbank Limited Reg No 1951/09/06. The following link displays the names of the Nedbank Board of Directors and Company Secretary. [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is confidential and is intended for the addressee only. The following link will take you to Nedbank's legal notice. [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
On Fri, 27 Jun 2014 07:11:19 -0500, Elardus Engelbrecht wrote: Note some attributes may be overridden/locked by your ISPF configuration table. For example, I have overridden site wide these attributes: RECOVERY (make it ON) and STATS (FORCE it ON). NFS and FTP follow ISPF conventions for member ENQ, and NFS at least (I haven't tested FTP) provides member statistics. Do they likewise respect the DSN profile setting of STATS? Hmmm. Do these facilities use common ISPF LM services, or do they roll their own? And touch via NFS does not update the stats time stamp. I suppose I should just be glad it doesn't OPEN, STOW, and CLOSE an empty member. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
Paul Gilmartin wrote: NFS and FTP follow ISPF conventions for member ENQ, and NFS at least (I haven't tested FTP) provides member statistics. Do they likewise respect the DSN profile setting of STATS? Excellent questions! I have now tested FTP by uploading a text file to a PDS member which was last updated in 2002. The stats were indeed updated by the FTP. I don't know about 'respect'. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
I doubt it, the profiles are an internal ISPF thing and their definitions saved in the user's personal profile dataset. Which/whose settings should FTP use? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Friday, June 27, 2014 15:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDSE member profile Paul Gilmartin wrote: NFS and FTP follow ISPF conventions for member ENQ, and NFS at least (I haven't tested FTP) provides member statistics. Do they likewise respect the DSN profile setting of STATS? Excellent questions! I have now tested FTP by uploading a text file to a PDS member which was last updated in 2002. The stats were indeed updated by the FTP. I don't know about 'respect'. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
On Fri, 27 Jun 2014 08:13:39 -0500, Elardus Engelbrecht wrote: NFS and FTP follow ISPF conventions for member ENQ, and NFS at least (I haven't tested FTP) provides member statistics. Do they likewise respect the DSN profile setting of STATS? Excellent questions! I have now tested FTP by uploading a text file to a PDS member which was last updated in 2002. The stats were indeed updated by the FTP. I don't know about 'respect'. This is another case of IBM's chaotically implementing a valuable function in the wrong layer. Updating member stats should be built in to STOW, not implemented haphazardly or redundantly by various utilities. Several years ago, NFS stored incorrect member dates during leap year. I was unable to reproduce the problem in 2012. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
On 06/27/2014 07:11 AM, Elardus Engelbrecht wrote: Buckton, T. (Theo) wrote: Which process determines the profile of a member in a PDSE (Library) data set. When one browses the PDSE, views the member and enter PROFILE on the command line of the member, it brings up some attributes. How are these attributes determined: These attributes came from different sources: ISPF defaults, ISPF configuration table, your own profiles, your usage of edit macros (before edit or during logon) and the of course your own commands as issued by you. DECKS (FIXED - 80)RECOVERY OFF WARNNUMBER OFF... CAPS ONHEX OFFNULLS ON STDTABS OFF.. AUTOSAVE ONAUTONUM OFFAUTOLIST OFFSTATS ON.. PROFILE UNLOCKIMACRO NONEPACK OFFNOTE ON HILITE OFF CURSOR FIND.. Note some attributes may be overridden/locked by your ISPF configuration table. For example, I have overridden site wide these attributes: RECOVERY (make it ON) and STATS (FORCE it ON). Groete / Greetings Elardus Engelbrecht More explcitly, the default choice of profile used by EDIT is based on the data set Low-level qualifier and to a minor extent by the RECFM (VB vs. FB) The number of different profiles that will be saved for a user for ISPF edit is an installation-defined value; and if saving a new profile would exceed that limit, I believe the oldest UNLOCKed user profile is lost. If a new LLQ is encountered in a user edit session, session edit profile attributes are assigned based on installation default profile or ISPF defaults, and when the edit session is normally terminated a modified or new profile will be saved and associated with that LLQ for that user. To help enforce installation standards an installation can set up an installation ISPF table member with default profiles for LLQ's of interest and LOCK those profiles, so even if attributes are changed they are not unintentionally re-saved by users in their own profile data set with the new values. If the user does not have his own profile copy for a LLQ, then an installation defined profile for that LLQ will be used, if it exists. Installations can also define a default installation Initial Macro that will be invoked when ISPF EDIT starts that can either alter the Edit profile used or override some of the profile attributes to counter the effects of users that deliberately UNLOCK a locked installation edit profile and modify it in unacceptable ways (like storing PACKed members in a PDS that everyone else expects to be unpacked). In the worst case scenario each user editing a shared PDS could have their own customized copy of an Edit profile that applied to their edit session on the PDS, and some of their attributes could conflict with other user's usage. You can't eliminate such conflicts, but with proper installation defaults and controls you can at least reduce the likelihood of conflicts happening by accident and reduce the likelihood that temporary EDIT attribute changes are unintentionally preserved. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
On 2014-06-27, at 07:21, Vernooij, CP (SPLXM) - KLM wrote: I doubt it, the profiles are an internal ISPF thing and their definitions saved in the user's personal profile dataset. Which/whose settings should FTP use? Are you saying that if multiple users have write access to a PDS for purposes of team development (ISPF supports this operation (I used to believe well)), they may follow inconsistent conventions with respect to NUMBER, STATS, RECOVERY, ...? Ouch! In case of team development, such a profile should belong to the library, not to the individual developer(s). Hmmm... Suppose one developer's edit session crashes, but RECOVERY is on. Can editing that member be resumed and recovered by another team member? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
Vernooij, CP wrote: I doubt it, the profiles are an internal ISPF thing and their definitions saved in the user's personal profile dataset. Which/whose settings should FTP use? Yes, you are right. I'm not sure what settings FTP is using, but at least when a member is updated the stats are updated too. Perhaps I should stated, the member statistics were updated by FTP, not the *member profile details* as used in an edit session. Ok, I must admit that Paul and I drifted somewhat in this thread. Thanks for your comments. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
Yes!. In our group, we all have activated an 'initial macro' that sets for certain datasets some of the attributes we require, like STATS, AUTOSAVE OFF PROMPT (to avoid PF3's unintentionally saving modifications). About what you call IBM chaos: if you look at the history of these features, it is explainable how things grew this way. First there was no (I)SPF, but there were member statistics as save by the linkage editor etc. Then came (I)SPF and they at some point in time found it useful to save statistics, for ISPF use only. Then they developed their own enq's (SPFEDIT) for editing several members in a PDS while holding the PDS with DISP=SHR. Then we got problems with batch updating PDS's that were in use constantly by ISPF users, which was solved by batch updating the PDS with DISP=SHR, which corrupted a PDS once in every 1000 to 100 times. Then PDSMAN intercepted disp=shr batch by adding the SPFEDIT enq and the linkage editor was doing likewise. Now we have come to the chaos you describe and yes, someone with a supervising view could have stopped this trend and decided to do this at platform level, but this did not happen. It is like a couple of guys developing a communication protocol for their computer connections that suited their needs, but now it is used as 'internet' and the total world economy depends on it, it should have been developed differently. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, June 27, 2014 15:37 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDSE member profile On 2014-06-27, at 07:21, Vernooij, CP (SPLXM) - KLM wrote: I doubt it, the profiles are an internal ISPF thing and their definitions saved in the user's personal profile dataset. Which/whose settings should FTP use? Are you saying that if multiple users have write access to a PDS for purposes of team development (ISPF supports this operation (I used to believe well)), they may follow inconsistent conventions with respect to NUMBER, STATS, RECOVERY, ...? Ouch! In case of team development, such a profile should belong to the library, not to the individual developer(s). Hmmm... Suppose one developer's edit session crashes, but RECOVERY is on. Can editing that member be resumed and recovered by another team member? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
Kees is correct. FTP doesn't support ISPF profiles. It was specifically modified to handle user data area for the member in the PDS directory. ISPF editor is just an editor. Why the OUCH when every other editor (including UNIX) allows you to change the edit settings? If you want a dev environment, then you install a dev environment (e.g. SCLM, Changeman, Endeavour, CVS, ...). As for edit recovery, it is associated with the user and that is the correct choice. In z/OS dev environments, we have member locking which would make shared recovery viable. Outside that environment, member lock has been lost once the edit terminates for the member. Allowing recovery in this situation can lead to confusion or failures. Would you trust automatic recovery of a SYS1.PARMLIB member? Jon Perryman.. On Friday, June 27, 2014 6:37 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: On 2014-06-27, at 07:21, Vernooij, CP (SPLXM) - KLM wrote: I doubt it, the profiles are an internal ISPF thing and their definitions saved in the user's personal profile dataset. Which/whose settings should FTP use? Are you saying that if multiple users have write access to a PDS for purposes of team development (ISPF supports this operation (I used to believe well)), they may follow inconsistent conventions with respect to NUMBER, STATS, RECOVERY, ...? Ouch! In case of team development, such a profile should belong to the library, not to the individual developer(s). Hmmm... Suppose one developer's edit session crashes, but RECOVERY is on. Can editing that member be resumed and recovered by another team member? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
I hate to give a sloppy response, but 'at one time' an installation could create a default ISPF profile called in whenever a user edited a data set that did not already have a matching LLQ in the personal profile. This default profile would be stored somewhere in the ISPTLIB concatenation with some name and used initially. Default options like RECOVERY and AUTOSAVE would be honored. That may all be handled by the ISPF setup process now, but the point is that the installation can give the user an initial profile, which the user can change if desired. Sorry for the fuzz. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Vernooij, CP (SPLXM) - KLM kees.verno...@klm.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 06/27/2014 06:52 AM Subject:Re: PDSE member profile Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Yes!. In our group, we all have activated an 'initial macro' that sets for certain datasets some of the attributes we require, like STATS, AUTOSAVE OFF PROMPT (to avoid PF3's unintentionally saving modifications). About what you call IBM chaos: if you look at the history of these features, it is explainable how things grew this way. First there was no (I)SPF, but there were member statistics as save by the linkage editor etc. Then came (I)SPF and they at some point in time found it useful to save statistics, for ISPF use only. Then they developed their own enq's (SPFEDIT) for editing several members in a PDS while holding the PDS with DISP=SHR. Then we got problems with batch updating PDS's that were in use constantly by ISPF users, which was solved by batch updating the PDS with DISP=SHR, which corrupted a PDS once in every 1000 to 100 times. Then PDSMAN intercepted disp=shr batch by adding the SPFEDIT enq and the linkage editor was doing likewise. Now we have come to the chaos you describe and yes, someone with a supervising view could have stopped this trend and decided to do this at platform level, but this did not happen. It is like a couple of guys developing a communication protocol for their computer connections that suited their needs, but now it is used as 'internet' and the total world economy depends on it, it should have been developed differently. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, June 27, 2014 15:37 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDSE member profile On 2014-06-27, at 07:21, Vernooij, CP (SPLXM) - KLM wrote: I doubt it, the profiles are an internal ISPF thing and their definitions saved in the user's personal profile dataset. Which/whose settings should FTP use? Are you saying that if multiple users have write access to a PDS for purposes of team development (ISPF supports this operation (I used to believe well)), they may follow inconsistent conventions with respect to NUMBER, STATS, RECOVERY, ...? Ouch! In case of team development, such a profile should belong to the library, not to the individual developer(s). Hmmm... Suppose one developer's edit session crashes, but RECOVERY is on. Can editing that member be resumed and recovered by another team member? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
On Fri, 27 Jun 2014 13:51:51 +, Vernooij, CP (SPLXM) - KLM wrote: Yes!. In our group, we all have activated an 'initial macro' that sets for certain datasets some of the attributes we require, like STATS, AUTOSAVE OFF PROMPT (to avoid PF3's unintentionally saving modifications). And I suppose it can even be project-sensitive, implied by certain data sets. About what you call IBM chaos: if you look at the history of these features, it is explainable how things grew this way. No, it's not explainable unless you tolerate irresponsibility. It could have been done right when the decision was made to do it at all. The function should have been provided in Allocation so it would be available alike to ISPF, SVC99, TSO ALLOCATE, BPXWDYN, and Batch JCL. Then we got problems with batch updating PDS's that were in use constantly by ISPF users, which was solved by batch updating the PDS with DISP=SHR, which corrupted a PDS once in every 1000 to 100 times. Really!? Shocking! When I confronted the problem, with a naive caution I resorted to invoking ISPF LM services in batch IKJEFT01 to preserve integrity. Then PDSMAN intercepted disp=shr batch by adding the SPFEDIT enq and the linkage editor was doing likewise. And even ISPF and linkage editor don't use the same ENQ. (I believe ISPF uses both if RECFM=U.) Alas, PDSMAN appears to be an ISV product, and can't be relied on to be available in every customer shop. And we, as an ISV, may be compelled to test twice, once for compatibility with PDSMAN, and once for integrity absent PDSMAN. Now we have come to the chaos you describe and yes, someone with a supervising view could have stopped this trend and decided to do this at platform level, but this did not happen. It's never too late. It is like a couple of guys developing a communication protocol for their computer connections that suited their needs, but now it is used as 'internet' and the total world economy depends on it, it should have been developed differently. At least, unlike allocation/ENQ which is chaotic even within a single OS from a single vendor, TCP/IP is uniform across all vendors (unless you regard SNA as a viable competitor). (couple of guys seems to be devaluing DoD ARPA and NSF.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
No. The recovery dataset is under the original user's prefix. - -teD - Original Message From: Paul Gilmartin Sent: Friday, June 27, 2014 09:37 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: PDSE member profile On 2014-06-27, at 07:21, Vernooij, CP (SPLXM) - KLM wrote: I doubt it, the profiles are an internal ISPF thing and their definitions saved in the user's personal profile dataset. Which/whose settings should FTP use? Are you saying that if multiple users have write access to a PDS for purposes of team development (ISPF supports this operation (I used to believe well)), they may follow inconsistent conventions with respect to NUMBER, STATS, RECOVERY, ...? Ouch! In case of team development, such a profile should belong to the library, not to the individual developer(s). Hmmm... Suppose one developer's edit session crashes, but RECOVERY is on. Can editing that member be resumed and recovered by another team member? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
Your recollection is correct. Specifically, the profile is named ZDEFAULT. On Fri, Jun 27, 2014 at 12:45 PM, Skip Robinson jo.skip.robin...@sce.com wrote: I hate to give a sloppy response, but 'at one time' an installation could create a default ISPF profile called in whenever a user edited a data set that did not already have a matching LLQ in the personal profile. This default profile would be stored somewhere in the ISPTLIB concatenation with some name and used initially. Default options like RECOVERY and AUTOSAVE would be honored. That may all be handled by the ISPF setup process now, but the point is that the installation can give the user an initial profile, which the user can change if desired. Sorry for the fuzz. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Vernooij, CP (SPLXM) - KLM kees.verno...@klm.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 06/27/2014 06:52 AM Subject:Re: PDSE member profile Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Yes!. In our group, we all have activated an 'initial macro' that sets for certain datasets some of the attributes we require, like STATS, AUTOSAVE OFF PROMPT (to avoid PF3's unintentionally saving modifications). About what you call IBM chaos: if you look at the history of these features, it is explainable how things grew this way. First there was no (I)SPF, but there were member statistics as save by the linkage editor etc. Then came (I)SPF and they at some point in time found it useful to save statistics, for ISPF use only. Then they developed their own enq's (SPFEDIT) for editing several members in a PDS while holding the PDS with DISP=SHR. Then we got problems with batch updating PDS's that were in use constantly by ISPF users, which was solved by batch updating the PDS with DISP=SHR, which corrupted a PDS once in every 1000 to 100 times. Then PDSMAN intercepted disp=shr batch by adding the SPFEDIT enq and the linkage editor was doing likewise. Now we have come to the chaos you describe and yes, someone with a supervising view could have stopped this trend and decided to do this at platform level, but this did not happen. It is like a couple of guys developing a communication protocol for their computer connections that suited their needs, but now it is used as 'internet' and the total world economy depends on it, it should have been developed differently. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, June 27, 2014 15:37 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDSE member profile On 2014-06-27, at 07:21, Vernooij, CP (SPLXM) - KLM wrote: I doubt it, the profiles are an internal ISPF thing and their definitions saved in the user's personal profile dataset. Which/whose settings should FTP use? Are you saying that if multiple users have write access to a PDS for purposes of team development (ISPF supports this operation (I used to believe well)), they may follow inconsistent conventions with respect to NUMBER, STATS, RECOVERY, ...? Ouch! In case of team development, such a profile should belong to the library, not to the individual developer(s). Hmmm... Suppose one developer's edit session crashes, but RECOVERY is on. Can editing that member be resumed and recovered by another team member? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE member profile
Ah yes, ZDEFAULT. The 'setup process' I referred to is the ISPF Configuration Utility, which allows the installation to control all sorts of options. That dialog is a more recent mechanism than ZDEFAULT, and much more powerful. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Don Imbriale don.imbri...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 06/27/2014 03:32 PM Subject:Re: PDSE member profile Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Your recollection is correct. Specifically, the profile is named ZDEFAULT. On Fri, Jun 27, 2014 at 12:45 PM, Skip Robinson jo.skip.robin...@sce.com wrote: I hate to give a sloppy response, but 'at one time' an installation could create a default ISPF profile called in whenever a user edited a data set that did not already have a matching LLQ in the personal profile. This default profile would be stored somewhere in the ISPTLIB concatenation with some name and used initially. Default options like RECOVERY and AUTOSAVE would be honored. That may all be handled by the ISPF setup process now, but the point is that the installation can give the user an initial profile, which the user can change if desired. Sorry for the fuzz. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Vernooij, CP (SPLXM) - KLM kees.verno...@klm.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 06/27/2014 06:52 AM Subject:Re: PDSE member profile Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Yes!. In our group, we all have activated an 'initial macro' that sets for certain datasets some of the attributes we require, like STATS, AUTOSAVE OFF PROMPT (to avoid PF3's unintentionally saving modifications). About what you call IBM chaos: if you look at the history of these features, it is explainable how things grew this way. First there was no (I)SPF, but there were member statistics as save by the linkage editor etc. Then came (I)SPF and they at some point in time found it useful to save statistics, for ISPF use only. Then they developed their own enq's (SPFEDIT) for editing several members in a PDS while holding the PDS with DISP=SHR. Then we got problems with batch updating PDS's that were in use constantly by ISPF users, which was solved by batch updating the PDS with DISP=SHR, which corrupted a PDS once in every 1000 to 100 times. Then PDSMAN intercepted disp=shr batch by adding the SPFEDIT enq and the linkage editor was doing likewise. Now we have come to the chaos you describe and yes, someone with a supervising view could have stopped this trend and decided to do this at platform level, but this did not happen. It is like a couple of guys developing a communication protocol for their computer connections that suited their needs, but now it is used as 'internet' and the total world economy depends on it, it should have been developed differently. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, June 27, 2014 15:37 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDSE member profile On 2014-06-27, at 07:21, Vernooij, CP (SPLXM) - KLM wrote: I doubt it, the profiles are an internal ISPF thing and their definitions saved in the user's personal profile dataset. Which/whose settings should FTP use? Are you saying that if multiple users have write access to a PDS for purposes of team development (ISPF supports this operation (I used to believe well)), they may follow inconsistent conventions with respect to NUMBER, STATS, RECOVERY, ...? Ouch! In case of team development, such a profile should belong to the library, not to the individual developer(s). Hmmm... Suppose one developer's edit session crashes, but RECOVERY is on. Can editing that member be resumed and recovered by another team member? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
