Rob I had a look at this FFST item only because I sort-of got inveigled into participating in that earlier FFST thread to which I referred. I don't believe I ever used it in earnest with my education hands-on systems in the days when I had such sandboxes available.
I can see that a dump data set identified with a DD-statement name is *not* the same as a dump data set which is dynamically allocated according to what may happen to be specified by an event which may or may not happen and may happen multiple times. Tackling this concern from another angle, if you expect sharing of a data set based on functions which have become available in the last 15 to 20 years, then I'm pretty confident FFST will *not* be supporting those functions. Thus you should expect to have one or one set of data sets for each instance of an FFST address space. I always made it a pragmatic rule of thumb to do just that when setting up address spaces at the time I paid attention to these matters which is up to around 1995. Why, because it just seemed sensible. What is the real concern you have here which has led to this query? If it is just a tidy way to manage these output data sets, you may need to know about/be reminded of the DISP=MOD "trick" - and (I just checked) you don't need to worry about having multiple steps in your FFST (EPWINIT) procedure. Chris Mason On Thu, 26 Jul 2012 00:04:32 -0400, Rob Schramm <[email protected]> wrote: >Chris, > >I read that section of the manual. However, I don't think we are >referencing the same dump data sets. The book is not remotely >specific in regards to the treatment of these DD statements in the >EPWFFST proc. I think that the section you are referencing are >dynamic dumps that are in addition to the ones coded in the proc. >Perhaps I am reading the manual incorrectly. > >But I think the phrase "FFST will dynamically..." indicates that the >dynamic dumps are not related to the DD statements. > >From the book... >When a software probe is executed and the caller chooses to request a >dump, FFST will dynamically allocate a data set and generate an >unformatted dump. The name of the data set will be as >follows:user_name.system_name.applid.DMPxxxxx > >To add to the general weirdness, I have two systems sharing the >FFSTLOGx DD and there are updates from both systems. Which I suppose >is to be expected when using DISP=SHR. I cannot make any definitive >statement as to the general integrity of the contents of the data set. ><VBG> > >Rob Schramm > > >On Wed, Jul 25, 2012 at 9:05 PM, Chris Mason <[email protected]> wrote: >> >> Rob >> >> > Does anyone know if the FFSTCKPT, FFSTLOGx & AND FFSTDUMP data sets must >> > be unique? >> >> I always find this form of posing a question very curious! >> >> The answer is always "Yes" if the product referenced is at the very least >> still being maintained.[1] >> >> I'm sure what you really and simply mean is as follows: >> >> "Must the FFSTCKPT, FFSTLOGx & AND FFSTDUMP data sets be unique?" >> >> Or, more elaborately, as follows: >> >> "Would someone be so kind as to tell me whether or not the FFSTCKPT, >> FFSTLOGx & AND FFSTDUMP data sets must be unique?" >> >> Anyhow the answer for at least the FFSTDUMP data set, as hinted in the sole >> manual covering MVS and VM FFST, is "Yes". >> >> <quote> >> >> xxxxx is a sequence number which makes the dump data set name unique >> >> </quote> >> >> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/EPW1A103/1.2.1 >> >> Perhaps you just need to check the references to FFSTCKPT and FFSTLOGx in >> this sole manual to answer your question regarding the these other data sets. >> >> - >> >> [1] If you search the archives for the thread "What is the point of FFST?" >> from April, 2011, you will find that whether or not FFST is still being >> maintained was under discussion. Mr Zelden even simply considers FFST >> worthless - as one can assume does the "Wizard of Lodz". >> >> - >> >> Chris Mason >> >> On Wed, 25 Jul 2012 13:55:39 -0400, Rob Schramm <[email protected]> >> wrote: >> >> >Does anyone know if the FFSTCKPT, FFSTLOGx & AND FFSTDUMP data sets must be >> >unique? I always thought they must be setup by system... but I can't find >> >anything to confirm or deny whether they are unique or shared. >> > >> >Rob Schramm ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
