Re: SMF record 62 and SMF62MC1 byte meaning.
Hi John, it's the same for me. Sometimes I get the right behaviour and other times no ! The COBOL program does the OPEN I-O and the SMF64 states the step did both READ and UPDATE (the flag in the SMF64 is coherently incoherent). Look at the SMF64 record below. In my understanding, if at CLOSE Time the statistic field SMF64DRE is greater then 0 then the program made some GETS so why the MC1 flag states no Input ? I'm sure (the source program's got only one OPEN for the DD and it's I-O). I verified that all the programs LOADED in that step are not performing any operation about that DD. How about it ? I think I'm going to ask IBM to better understand and verify if my meaning is correct or not even though any further news from you will be really appreciated. Thanks a lot for you support. Massimo POSN12345678901234567890123456789012345678901234567890 1 CHAR . ..f.MVSAJTIMAN19...SSYSPROD ..ICFUCAT.AP ZONE 1*4*00800102DEECDECDCDFF007E0102EEEDDDC4*8**A*CCCECCE4CD NUMR E*0*0469143F4521139415190482143F28279640*0**0*9364313B17 +-+-+-+-+-+ 51 CHAR PLJP0 JTIP.VSBW0M.APPO ZONE F4DECD4EECEFD4CDDD NUMR 7317001397B522604B1776 +-+-+-+-+-+ 101 CHAR GGIO.TITOLIXX.DATA LRPRD3 ZONE CCCD4ECEDDCEE4CCEC44B00104000400CF NUMR 7796B39363977B413107C00A0600060E397943 +-+-+-+-+-+ 151 CHAR .. ZONE 12003320*0003*00B000 NUMR 630F*0014*00010001078000 +-+-+-+-+-+ 201 CHAR .d..Q. ZONE 06***0001**001E**0018*FFD0 NUMR 030003*0001**000*9*000C**0014*FF84 +-+-+-+-+-+ 251 CHAR ..TITAR02U..JTIP.VSBW0M.AP ZONE *0003*000500ECECDFFE02DECD4EECEFD4CD NUMR *001A*004000430E39319024121397B522604B17 251 CHAR ..TITAR02U..JTIP.VSBW0M.AP ZONE 0003000500ECECDFFE02DECD4EECEFD4CD NUMR 001A004000430E39319024121397B522604B17 +-+-+-+-+-+ 301 CHAR POGGIO.TITOLIXX ZONE DDCCCD4ECEDDCEE44400*9*00043 NUMR 767796B393639771*A*00040 +-+-+-+-+-+ 351 CHAR .. ZONE 00 NUMR 00 +-+-+-+-+-+ 401 CHAR =6 ZONE 7F0102 NUMR 0004E6143F +-+-+-+-+-+ 451 CHAR ZONE NUMR +-+-+-+-+-+ SMF64RIN=x'80' 1000 Component Closed and the Extended Area is present SMF64DTY=x'A0' 1010 It's teh Data Component and the Format is Extended SMF64SLN=x'0134' 308 Length of Statistic Section (start of) SMF64DDE=x'0001' 1 Record Deleted SMF64DIN=x'0019' 25 records Inserted SMF64DUP=x'10EC' 4332 Records Updated SMF64DRE=x'1184' 4484 Records Retrieved SMF64DEP=x'013A' 314 EXCP SMF64MC1=x'9A' 1001 1010 1 = Record is identified by a KEY (it matches with Organization is indexed from Cobol) 0 = RBA access NO 0 = CI access NO 1 = Sequential Processing (Access mode in Dynamic from Cobol) 1 = Direct Processing (Access mode in Dynamic from Cobol) 0 = Input Processing NO (???) 1 = Output Processing YES 0 = User Supplied Buffer Space NO 2014-02-13 20:14 GMT+01:00 John Gilmore jwgli...@gmail.com: Massimo, I have not been able to reproduce your problem, but I am almost certainly not doing exactly what you are doing. When I open a COBOL 2.1 [INDEXED DYNAMIC] file for input, I get input processing 1, output processing 0; when I open it for output, I get input processing 0, output processing 1; and when I open it for update I get input processing 1, output processing 1. What kind of processing had been done on this file when the SMP record you show was cut? John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff
Re: SMF record 62 and SMF62MC1 byte meaning.
On Thu, 13 Feb 2014 10:55:27 +0100, Massimo Biancucci wrote: Hi all, we started analyzing SMF62 to trace which A.S. use VSAM datasets and their intent (Read or Update). To do the task we analyze the SMF62MC1 flag (zOS 1.13). So, a Cobol program does the following: .. SELECT ARCAPPU ASSIGN TOTITAR02U ORGANIZATION IS INDEXED ACCESS MODE IS DYNAMIC RECORD KEY IS APP-KEY FILE STATUS IS STATUS-ARCAPPU. .. OPEN I-OARCAPPU. .. Here the SMF62: 1 2 3 4 5 POSN12345678901234567890123456789012345678901234567890 1 CHAR =}MVSAJTIMAN19...SSYSPROD h...ICFUCAT. ZONE 13007D0102DEECDECDCDFF007E0102EEEDDDC48000CCCECCE4 NUMR EE04E0143F4521139415190482143F2827964080009364313B +-+-+-+-+-+ 51 CHAR APPLJP0 SCATF1JTIP.VSB ZONE CDF4ECCECFDECD4EEC NUMR 177317002313611397B522 +-+-+-+-+-+ 101 CHAR W0M.APPOGGIO.TITOLIXX ..LRPRD3PA ZONE EFD4CDDDCCCD4ECEDDCEE44400CF3320DC NUMR 604B17767796B393639771397943000F71 +-+-+-+-+-+ 151 CHAR XXBW01PAPRBW01UEFVS000..=. ZONE EECEFFDCDDCEFFECCEEFFF007B0102*9*000 NUMR 77260171792601456524EF143F*A*000 +-+-+-+-+-+ So the SMF62MC1 is x'9A' = 1001 1010 in binary. According to the manual: 1 = Record is identified by a KEY (it matches with Organization is indexed from Cobol) 0 = RBA access NO 0 = CI access NO 1 = Sequential Processing (Access mode in Dynamic from Cobol) 1 = Direct Processing (Access mode in Dynamic from Cobol) 0 = Input Processing NO (???) 1 = Output Processing YES 0 = User Supplied Buffer Space NO The program does all of READ, START, WRITE and REWRITE. So, about the Input Processing flag, I'm not able to pair the SMF record with the behaviour (SMF64 states the read and update were done) of the program. In the past, if I well remember, I did some tests and at the I-O OPEN the flags seemed to be OK. What's wrong in my understanding ? Thanks a lot for your support. Massimo The program can do a READ even though the MACRF=IN bit is not set. In the description of the MACRF option of the ACB macro in DFSMS Macro Instructions for Data Sets, it says: If you specify OUT and want merely to retrieve some records and also update, delete, or insert others, you need not also specify IN. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D580/1.2.4 Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF record 62 and SMF62MC1 byte meaning.
Is this [SMF record] flags byte recording behavior? Or is it recording [only] open option(s) specified? If the latter, should not opening for update set both the IN and the OUT bits? How otherwise is the specification of update reflected in this byte? I think Massimo has an adequate basis for consulting IBM, and I should myself be interested in its explanation of this behavior. There may be some simple rationale for what is being observed here, but the implementation of this byte appears to me to have been botched. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF record 62 and SMF62MC1 byte meaning.
On Fri, 14 Feb 2014 07:39:24 -0500, John Gilmore wrote: Is this [SMF record] flags byte recording behavior? Or is it recording [only] open option(s) specified? If the latter, should not opening for update set both the IN and the OUT bits? How otherwise is the specification of update reflected in this byte? I think Massimo has an adequate basis for consulting IBM, and I should myself be interested in its explanation of this behavior. There may be some simple rationale for what is being observed here, but the implementation of this byte appears to me to have been botched. The mapping macro for the SMF record has the comment ACBMACR1 MACR FIELD on the line for SMF62MC1. The ACBMACR1 field is defined in the IFGACB macro, as are the bits within it. The bits are set by the ACB macro, or by MODCB before OPEN. I've never heard of any MACRF bits ever being changed during or after OPEN. I'd expect such behavior to be extremely rare, if it exists. I don't think there is any way to distinguish between output and update in this byte or in the type 62 record, and it might not matter to the OP, who says he wants to check for Read or Update intent. The bit for MACRF=OUT might be enough to go by. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF record 62 and SMF62MC1 byte meaning.
Thanks to Bill for his update. I agree with John that IBM should better explain the meaning of the byte and, furthermore, the Cobol behaviour. In my opinion, from version to version (or single PTF) the Cobol Behaviour could had been changing. Puzzling ! Thanks to everybody, of course I'll give you details as soon as I will receive news from IBM. Massimo 2014-02-14 13:39 GMT+01:00 John Gilmore jwgli...@gmail.com: Is this [SMF record] flags byte recording behavior? Or is it recording [only] open option(s) specified? If the latter, should not opening for update set both the IN and the OUT bits? How otherwise is the specification of update reflected in this byte? I think Massimo has an adequate basis for consulting IBM, and I should myself be interested in its explanation of this behavior. There may be some simple rationale for what is being observed here, but the implementation of this byte appears to me to have been botched. John Gilmore, Ashland, MA 01721 - USA -- 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: SMF record 62 and SMF62MC1 byte meaning.
It's SMF 64 which gives you a clue as to what actually HAPPENED - with Read, Update, Insert and Delete counters, plus the CI / CA Split counts, level changes etc. No 62. 64 is CLOSE, 62 is OPEN. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Bill Godfrey yak36...@yahoo.com To: IBM-MAIN@listserv.ua.edu Date: 14/02/2014 13:36 Subject:Re: SMF record 62 and SMF62MC1 byte meaning. Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu On Fri, 14 Feb 2014 07:39:24 -0500, John Gilmore wrote: Is this [SMF record] flags byte recording behavior? Or is it recording [only] open option(s) specified? If the latter, should not opening for update set both the IN and the OUT bits? How otherwise is the specification of update reflected in this byte? I think Massimo has an adequate basis for consulting IBM, and I should myself be interested in its explanation of this behavior. There may be some simple rationale for what is being observed here, but the implementation of this byte appears to me to have been botched. The mapping macro for the SMF record has the comment ACBMACR1 MACR FIELD on the line for SMF62MC1. The ACBMACR1 field is defined in the IFGACB macro, as are the bits within it. The bits are set by the ACB macro, or by MODCB before OPEN. I've never heard of any MACRF bits ever being changed during or after OPEN. I'd expect such behavior to be extremely rare, if it exists. I don't think there is any way to distinguish between output and update in this byte or in the type 62 record, and it might not matter to the OP, who says he wants to check for Read or Update intent. The bit for MACRF=OUT might be enough to go by. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF record 62 and SMF62MC1 byte meaning.
Bill, I value your contributions here. They are always appropriately informed, as was your last post in this thread. That said, it seems clear to me beyond argument that the appropriate way to record an open-for-update macro instruction is to set BOTH the in and the out bits, which is not being done. Now that I understand that this byte is intended to reflect just in-effect open options, I conclude that its implementation was indeed botched. In this OCO era I cannot look at the source code to be certain, but it seems very likely that these bit settings can also be fixed readily (without raising the spectre of compatibility breaches). John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF record 62 and SMF62MC1 byte meaning.
On Fri, 14 Feb 2014 09:43:28 -0500, John Gilmore jwgli...@gmail.com wrote: Bill, I value your contributions here. They are always appropriately informed, as was your last post in this thread. That said, it seems clear to me beyond argument that the appropriate way to record an open-for-update macro instruction is to set BOTH the in and the out bits, which is not being done. Now that I understand that this byte is intended to reflect just in-effect open options, I conclude that its implementation was indeed botched. In this OCO era I cannot look at the source code to be certain, but it seems very likely that these bit settings can also be fixed readily (without raising the spectre of compatibility breaches). Are you saying that the IN bit should be set for updates, and not for writing new records, as a way of distinguishing between the two? I presume you are not saying the IN bit should be required to be set in the ACB prior to OPEN, if updates are to be done, as that would introduce a compatibility problem. Are you saying that even if the IN bit is not set in the ACB, it should be set in the SMF record? If so, the SMF record ceases to reflect the actual state of the ACB. The issue becomes what is the purpose of SMF record 62? At OPEN time, when record 62 is written, it is not possible for OPEN to determine whether records will be updated or inserted or both. There is no OUTPUT or UPDAT option on the OPEN macro for VSAM ACBs. All that is known is that if the OUT bit is set, updates and insertions are allowed. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF record 62 and SMF62MC1 byte meaning.
Bill Godfrey wrote: Are you saying that the IN bit should be set for updates, and not for writing new records, as a way of distinguishing between the two? [... snipped ...] I think the documentation about those SMF records are somewhat not clear. I really wish someone from IBM Storage would comment on this thread about SMF 62 and 64. 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: SMF record 62 and SMF62MC1 byte meaning.
Bill, The 'compatibility problem' you mention is not obvious to me. Currently--I have tested all of the permutations---either the IN bit is set or the OUT bit is set. Both are never set. My view is, yes, that both the IN bit and the OUT bit should be set in the ACB at open time when the file is opened for update and, of course, only in this case. Currently, usage for update is indistinguishable from [admittedly already impure] usage for output. I now suspect that if this were done the SMF flag-bytes problem would be fixed too as a byproduct. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF record 62 and SMF62MC1 byte meaning.
On Fri, 14 Feb 2014 14:33:03 -0500, John Gilmore jwgli...@gmail.com wrote: Bill, The 'compatibility problem' you mention is not obvious to me. Currently--I have tested all of the permutations---either the IN bit is set or the OUT bit is set. Both are never set. My view is, yes, that both the IN bit and the OUT bit should be set in the ACB at open time when the file is opened for update and, of course, only in this case. Currently, usage for update is indistinguishable from [admittedly already impure] usage for output. I now suspect that if this were done the SMF flag-bytes problem would be fixed too as a byproduct. John, When you say should be set in the ACB at open time I'm not sure if you mean it should be set by OPEN or that it should be set prior to OPEN, using the MACRF operand of ACB. I think you mean the former. If the former, there is nothing for OPEN to check to see if the program will be updating records. You say when the file is opened for update but there is no open for update with ACBs. If the latter (both IN and OUT bits must be set prior to OPEN if updates are to be allowed) then compatibility would be a problem because of all the existing code that does updates with the IN bit off. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF record 62 and SMF62MC1 byte meaning.
Does this existing code do updates only after checking to ensure that the In bit is not set (off)? I doubt that. Compatibility arguments are certainly not dismissible; some, even many, of them are substantive; but they are too often advanced as a convenient, not at all substantive rationale for doing nothing. However that may be, I have now devoted more time to this issue than it perhaps deserves. Enough! John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF record 62 and SMF62MC1 byte meaning.
On Fri, 14 Feb 2014 22:36:37 -0500, John Gilmore wrote: Does this existing code do updates only after checking to ensure that the In bit is not set (off)? I doubt that. Compatibility arguments are certainly not dismissible; some, even many, of them are substantive; but they are too often advanced as a convenient, not at all substantive rationale for doing nothing. However that may be, I have now devoted more time to this issue than it perhaps deserves. Enough! Existing code would only be affected if a new requirement was introduced that the MACRF IN bit be turned on prior to OPEN when updates were intended. In the other scenario, in which the MACRF IN bit is turned on within OPEN, I said nothing about a compatibility issue. The problem with that approach is that there is no open for update or anything else by which OPEN can determine if updates to existing records are intended, rather than changes that don't require reading records first. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMF record 62 and SMF62MC1 byte meaning.
Hi all, we started analyzing SMF62 to trace which A.S. use VSAM datasets and their intent (Read or Update). To do the task we analyze the SMF62MC1 flag (zOS 1.13). So, a Cobol program does the following: .. SELECT ARCAPPU ASSIGN TOTITAR02U ORGANIZATION IS INDEXED ACCESS MODE IS DYNAMIC RECORD KEY IS APP-KEY FILE STATUS IS STATUS-ARCAPPU. .. OPEN I-OARCAPPU. .. Here the SMF62: 1 2 3 4 5 POSN12345678901234567890123456789012345678901234567890 1 CHAR =}MVSAJTIMAN19...SSYSPROD h...ICFUCAT. ZONE 13007D0102DEECDECDCDFF007E0102EEEDDDC48000CCCECCE4 NUMR EE04E0143F4521139415190482143F2827964080009364313B +-+-+-+-+-+ 51 CHAR APPLJP0 SCATF1JTIP.VSB ZONE CDF4ECCECFDECD4EEC NUMR 177317002313611397B522 +-+-+-+-+-+ 101 CHAR W0M.APPOGGIO.TITOLIXX ..LRPRD3PA ZONE EFD4CDDDCCCD4ECEDDCEE44400CF3320DC NUMR 604B17767796B393639771397943000F71 +-+-+-+-+-+ 151 CHAR XXBW01PAPRBW01UEFVS000..=. ZONE EECEFFDCDDCEFFECCEEFFF007B0102*9*000 NUMR 77260171792601456524EF143F*A*000 +-+-+-+-+-+ So the SMF62MC1 is x'9A' = 1001 1010 in binary. According to the manual: 1 = Record is identified by a KEY (it matches with Organization is indexed from Cobol) 0 = RBA access NO 0 = CI access NO 1 = Sequential Processing (Access mode in Dynamic from Cobol) 1 = Direct Processing (Access mode in Dynamic from Cobol) 0 = Input Processing NO (???) 1 = Output Processing YES 0 = User Supplied Buffer Space NO The program does all of READ, START, WRITE and REWRITE. So, about the Input Processing flag, I'm not able to pair the SMF record with the behaviour (SMF64 states the read and update were done) of the program. In the past, if I well remember, I did some tests and at the I-O OPEN the flags seemed to be OK. What's wrong in my understanding ? Thanks a lot for your support. Massimo -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF record 62 and SMF62MC1 byte meaning.
Massimo, I have not been able to reproduce your problem, but I am almost certainly not doing exactly what you are doing. When I open a COBOL 2.1 [INDEXED DYNAMIC] file for input, I get input processing 1, output processing 0; when I open it for output, I get input processing 0, output processing 1; and when I open it for update I get input processing 1, output processing 1. What kind of processing had been done on this file when the SMP record you show was cut? John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF record 62 and SMF62MC1 byte meaning.
The COBOL is Enterprise Version 5 under z/OS 2.1. My apologies for appearing to confound operating system and compiler version numbers. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
