Re: Auditors Don't Know Squat!
Ed Gould wrote: ...we had to write a program that converted DJDE records the the format of the 3800 records (its been ages (4a?) ) Gosh! I totally forgot about that DJDE records! My, oh my, how the time flies! That was interesting technology, but now not in use these days... I remember the fun when I had to deal with them too... we were not even sure we could do it and they were there on the floor staring at us. I feel your pain... I know how it feel when 'they' say 'fix this and hurry up, the customers are already mad!' [1] ;-D ... Although this time he got caught with his hands in the vendors pocket and he got fired. Uh oh... Was he also part of the team who needs to decide who should be assigned as 'vendor'? Groete / Greetings Elardus Engelbrecht [1] - My boss once tried out to change a proc for VTAM. He changed the REGION and asked the ops to IPL, unscheduled of course. Of course VTAM refused to come up and ops and the same boss just looked at me... It was those days when DASDs are not shared, so that proc is out of my reach... Thats how I learned to use 'S VTAM,keyword=option'. ;-D -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using NOTE and POINT simulation macros on CMS?
On Thu, 2 Aug 2012 17:00:02 -0400, Thomas David Rivers riv...@dignus.com wrote: I'm having some issues with using the OS Simulation macros NOTE and POINT under VM/CMS. I've been scouring documentation to try and discover just what the CMS differences are... But, at the moment, I'm trying to simply do a BSAM OPEN (for READ)... Then, a NOTE to record the starting TTR of the file... Then - reading the file to the end (with regular BSAM READ+CHECK) Then, a POINT to return to the beginning of the file, using the TTR retrieved from just after the OPEN (with +1 added because the NOTE occurs after OPEN but before any READ.) Then - try and READ the blocks again... What I'm seeing is that the NOTE returns something that looks like a TTR. Then, the READs+CHECKs occur that read the file. The POINT supposedly returns us to the begining, but the next READ gets EOD. Clearly - the POINT hasn't worked. And, as you might expect - this approach works just great on z/OS. Does anyone know of any vagaries with the OS simulation of NOTE/POINT? I did see that you can't code TYPE=REL (or TYPE=anything for that matter.) But, I don't really care what the block address is... just that it is the valid block address for the beginning of the file. Thanks for any pointers! First pointer: We welcome your CMS questions over on IBMVM! ;-) Sorry I haven't been watching IBM-MAIN as closely as I should, but the TTR isn't. It's the CMS file system record number of the record that was just read (shifted left 8 bits) i.e. rr00. At OPEN, no records have been read, so the record number is zero. You NOTEd the zero value and added 1. Then you POINTed to 0x01, but that low-order byte isn't used, so you are effectively pointing to record zero.When a zero is passed to the lower-level CMS filesystem interfaces (FSREAD/FSWRITE), it means read or write next record. To increment the record number by one, add 256 to the TTR. To explicitly position to record 1, POINT to TTR 0x0100 Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Auditors Don't Know Squat!
W dniu 2012-08-08 03:20, Robert A. Rosenberg pisze: At 10:17 + on 08/07/2012, Pearce, Colin E wrote about Re: Auditors Don't Know Squat!: Ask the Auditors if they will help you fill out all the APARs and collect the supporting documents IMO: Any Auditor who wants to tell me how to do my job (as opposed to just critiquing how I do it) is not qualified to do so UNLESS he can do my job in the first place. IMO I can't play a violin, but I can tell you if you play horribly. I can't brick lay, but I can assess if your wall is askew. Etc, etc. Of course the above does not mean the auditor can be totally ignorant and can demand anything he think it makes sense. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Auditors Don't Know Squat!
At 09:40 +0200 on 08/08/2012, R.S. wrote about Re: Auditors Don't Know Squat!: W dniu 2012-08-08 03:20, Robert A. Rosenberg pisze: At 10:17 + on 08/07/2012, Pearce, Colin E wrote about Re: Auditors Don't Know Squat!: Ask the Auditors if they will help you fill out all the APARs and collect the supporting documents IMO: Any Auditor who wants to tell me how to do my job (as opposed to just critiquing how I do it) is not qualified to do so UNLESS he can do my job in the first place. IMO I can't play a violin, but I can tell you if you play horribly. I can't brick lay, but I can assess if your wall is askew. Etc, etc. Of course the above does not mean the auditor can be totally ignorant and can demand anything he think it makes sense. You are basically agreeing with me and saying the same thing as I did. All of your examples are critiquing the performance of the task NOT saying HOW TO PERFORM it. Telling how to do something falls under the heading of being an instructor/teacher. That role, IMO, requires that you have done what you are instructing others how to do. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Space Allocation In Bytes
Hi, I am probably asking a very simple Question but I am unable to interpret Properly. I tried allocating a PS file with space Unit=Bytes, Primary as 1,RECFM=FB,LRECL=80, but when I view the Dataset Information shows the primary Extent is occupied with *55840 bytes* : General Data Current Allocation Management class . . : **None**Allocated bytes . . : 55,840 Storage class . . . : STANDARDAllocated extents . : 1 Volume serial . . . : MTWK06 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : PS Current Utilization Record format . . . : FB Used bytes . . . . : 0 Record length . . . : 80 Used extents . . . : 0 Block size . . . . : 27920 1st extent bytes . : *55840* Secondary bytes . . : 0 Dates Data set name type : Creation date . . . : 2012/08/08 SMS Compressible. . : NO Referenced date . . : ***None*** Expiration date . . : ***None*** Could anyone please enlighten me how does the Primary Value gets generated as 55840 bytes ? Does it mean it is treating the Primary extent as 2 Blocks on a Track which would be 55,840 bytes ? Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using NOTE and POINT simulation macros on CMS?
On Aug 8, 2012, at 01:04, Alan Altmark wrote: First pointer: We welcome your CMS questions over on IBMVM! ;-) Sorry I haven't been watching IBM-MAIN as closely as I should, but the TTR isn't. It's the CMS file system record number of the record that was just read (shifted left 8 bits) i.e. rr00. At OPEN, no records have been read, so the record number is zero. You NOTEd the zero value and added 1. Then you POINTed to 0x01, but that low-order byte isn't used, so you are effectively pointing to record zero. ... IIRC, there's an OS convention that setting the lowest byte (Z) of the TTRZ to '01'x causes reading of the block following thenone POINTed to by the TTR. Does CMS respect this? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
Jake, Minimum allocation for a file on DASD is one track. Richard -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson Sent: 08 August 2012 01:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Space Allocation In Bytes Hi, I am probably asking a very simple Question but I am unable to interpret Properly. I tried allocating a PS file with space Unit=Bytes, Primary as 1,RECFM=FB,LRECL=80, but when I view the Dataset Information shows the primary Extent is occupied with *55840 bytes* : General Data Current Allocation Management class . . : **None**Allocated bytes . . : 55,840 Storage class . . . : STANDARDAllocated extents . : 1 Volume serial . . . : MTWK06 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : PS Current Utilization Record format . . . : FB Used bytes . . . . : 0 Record length . . . : 80 Used extents . . . : 0 Block size . . . . : 27920 1st extent bytes . : *55840* Secondary bytes . . : 0 Dates Data set name type : Creation date . . . : 2012/08/08 SMS Compressible. . : NO Referenced date . . : ***None*** Expiration date . . : ***None*** Could anyone please enlighten me how does the Primary Value gets generated as 55840 bytes ? Does it mean it is treating the Primary extent as 2 Blocks on a Track which would be 55,840 bytes ? Jake -- 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: Space Allocation In Bytes
W dniu 2012-08-08 13:40, Jake anderson pisze: Hi, I am probably asking a very simple Question but I am unable to interpret Properly. I tried allocating a PS file with space Unit=Bytes, Primary as 1,RECFM=FB,LRECL=80, but when I view the Dataset Information shows the primary Extent is occupied with *55840 bytes* : General Data Current Allocation Management class . . : **None**Allocated bytes . . : 55,840 Storage class . . . : STANDARDAllocated extents . : 1 Volume serial . . . : MTWK06 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : PS Current Utilization Record format . . . : FB Used bytes . . . . : 0 Record length . . . : 80 Used extents . . . : 0 Block size . . . . : 27920 1st extent bytes . : *55840* Secondary bytes . . : 0 Dates Data set name type : Creation date . . . : 2012/08/08 SMS Compressible. . : NO Referenced date . . : ***None*** Expiration date . . : ***None*** Could anyone please enlighten me how does the Primary Value gets generated as 55840 bytes ? Does it mean it is treating the Primary extent as 2 Blocks on a Track which would be 55,840 bytes ? 1. Assuming we are NOT talking about EAV, allocation is being done in whole tracks. So, you can specify bytes, kilobytes, records, but the smallest physical chunk of disk space is always track. In your case you requested very small amount of space, so you got single track minus some technical areas. BTW: your allocation request was illogical - you wanted to have 80-byte records and requested 1 byte. Such request has to be re-interpreted or canceled. ;-) 2. Track is 56664 bytes BRUTTO. There are gaps, HA, R0, which causes your track is not 100% utilized. In any case it won't be 100% utilized. System determined blocksize (SDB) for FB 80 is 29720, two blocks on the track. So, for space 1 byte, 1 track or 1000 tracks, you will have two blocks per track, 2x29720. Caution: last block can be shorter, but just after dataset is created, there are not data inside. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS QUESTION - FILTERDD
esmie moo wrote: I am trying to use more than 1 FILTERDD while attempting to backup several dsns using DFDSS. I keep getting the error message : ADR126E (001)-RI01 (01), RIGHT PARENTHESIS MISSING AFTER 'INDSNS01 ' Is this because I am using more than 1 FILTERDD Yes. After I have RTFM, I see this syntax diagram: --FILterdd--(ddn)--- --FDD(ddn)--- (Above was slightly modified for posting here on IBM-MAIN) Try concatenate INDSNS01 and INDSNS02 in your JCL to overcome that limit. HTH! 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: Space Allocation In Bytes
On Aug 8, 2012, at 06:06, R.S. wrote: BTW: your allocation request was illogical - you wanted to have 80-byte records and requested 1 byte. Such request has to be re-interpreted or canceled. ;-) I believe the block specification is an average. As such, it's not required to be a multiple of LRECL. If half the blocks are 80 bytes and half are 160, an average of 120 is possible. Granted, 1 can never occur, not even as an average. I suppose allocation simply calculates the tracks necessary to hold the requested number of 1-byte blocks plus gaps. It might be a courtesy for allocation to issue a warning, but how much validity checking should it be expected to perform? What about RECFM=VB? What's the smallest valid block? 9? 8? 4? (That would be a BDW with no records.) Does Using Data Sets allow this? I bet I could write one with BSAM; I wonder how QSAM would handle reading it? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS QUESTION - FILTERDD
Yes, it is because you are filtering on more than one DD name. Instead, just concatenating the two DSNs onto the first DD name should work. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Wednesday, August 08, 2012 8:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFDSS QUESTION - FILTERDD Good Morining Gentle Readers, I am trying to use more than 1 FILTERDD while attempting to backup several dsns using DFDSS. I keep getting the error message : ADR126E (001)-RI01 (01), RIGHT PARENTHESIS MISSING AFTER 'INDSNS01 ' Is this because I am using more than 1 FILTERDD Below is my job: DUMP - DATASET(FILTERDD(INDSNS01 - INDSNS02)) - OUTDDNAME(ONSITE) - SHARE - SPHERE - VALIDATE Thanks in advance. -- 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: Space Allocation In Bytes
W dniu 2012-08-08 16:00, Paul Gilmartin pisze: On Aug 8, 2012, at 06:06, R.S. wrote: BTW: your allocation request was illogical - you wanted to have 80-byte records and requested 1 byte. Such request has to be re-interpreted or canceled. ;-) I believe the block specification is an average. As such, it's not required to be a multiple of LRECL. If half the blocks are 80 bytes and half are 160, an average of 120 is possible. Granted, 1 can never occur, not even as an average. I suppose allocation simply calculates the tracks necessary to hold the requested number of 1-byte blocks plus gaps. It might be a courtesy for allocation to issue a warning, but how much validity checking should it be expected to perform? What about RECFM=VB? What's the smallest valid block? 9? 8? 4? (That would be a BDW with no records.) Does Using Data Sets allow this? I bet I could write one with BSAM; I wonder how QSAM would handle reading it? In this case there is nothing to consider: 1 byte of disk space cannot hold any 80-byte record. It's not issue of AVG or even blocksize as multiplication of record size. Again: we talt about PRIMARY ALLOCATION OF ONE BYTE. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
A zero byte VB record is expanded to 1 blank x'40' so the minimum is a block of 9 bytes including block size and record size field. I tried to allocate a FB 6 0 to hold a list of volsers for a table, LRL under 10 would not work. On Wed, Aug 8, 2012 at 9:00 AM, Paul Gilmartin paulgboul...@aim.com wrote: deleted What about RECFM=VB? What's the smallest valid block? 9? 8? 4? (That would be a BDW with no records.) Does Using Data Sets allow this? I bet I could write one with BSAM; I wonder how QSAM would handle reading it? -- gil -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
On Aug 8, 2012, at 09:11, Mike Schwab wrote: A zero byte VB record is expanded to 1 blank x'40' so the minimum is a block of 9 bytes including block size and record size field. ??? No. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d490/3.1.3.1.2 Title: z/OS V1R12 DFSMS Using Data Sets Document Number: SC26-7410-10 3.1.3.1.2 Record Descriptor Word (RDW) A variable-length logical record consists of a record descriptor word (RDW) followed by the data. The record descriptor word is a 4 byte field describing the record. The first 2 bytes contain the length (LL) of the logical record (including the 4 byte RDW). The length can be from 4 to 32 760. All bits of the third and fourth bytes must be 0, because other values are used for spanned records. A length of 4 implies zero bytes of data; no blank. It's easy to create such records with EXECIO, FTP, or vi. I do not find a stated minimum for the BDW. Absent firm information, I'll assume 4-byte blocks (nothing but BDW) are permissible. I tried to allocate a FB 6 0 to hold a list of volsers for a table, LRL under 10 would not work. I had no such problem: Data Set Information More: + Data Set Name . . . . : user.SHORT.BLOCKS General Data Current Allocation Management class . . : **None**Allocated blocks . : 86 Storage class . . . : **None**Allocated extents . : 1 Volume serial . . . : TSO005 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : PS Current Utilization Record format . . . : F Used blocks . . . . : 3 Record length . . . : 6 Used extents . . . : 1 Block size . . . . : 6 Command === F1=HelpF3=Exit F12=Cancel . . . . . . . . . . . . . . . . . . . . . . . . . . . File Edit Edit_Settings Menu Utilities Compilers Test Help ——— VIEW user.SHORT.BLOCKS Columns 1 6 ** * Top of Data ** =PROF BLOCKS (FIXED - 6)RECOVERY OFF WARNNUMBER OFF... 01 these 02 are 03 recrds ** Bottom of Data -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS QUESTION - FILTERDD
Thanks for the advice. From: Elardus Engelbrecht elardus.engelbre...@sita.co.za To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, August 8, 2012 9:58:04 AM Subject: Re: DFDSS QUESTION - FILTERDD esmie moo wrote: I am trying to use more than 1 FILTERDD while attempting to backup several dsns using DFDSS. I keep getting the error message : ADR126E (001)-RI01 (01), RIGHT PARENTHESIS MISSING AFTER 'INDSNS01 ' Is this because I am using more than 1 FILTERDD Yes. After I have RTFM, I see this syntax diagram: --FILterdd--(ddn)--- --FDD(ddn)--- (Above was slightly modified for posting here on IBM-MAIN) Try concatenate INDSNS01 and INDSNS02 in your JCL to overcome that limit. HTH! 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 IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using NOTE and POINT simulation macros on CMS?
In 8082333213958528.wa.alanaltmarkus.ibm@listserv.ua.edu, on 08/08/2012 at 02:04 AM, Alan Altmark alan_altm...@us.ibm.com said: Sorry I haven't been watching IBM-MAIN as closely as I should, but the TTR isn't. It's the CMS file system record number of the record that was just read (shifted left 8 bits) i.e. rr00. The TTR is shifted left 8 bits in z/OS as well; bit 31 serves as a next record indicator. That goes back to OS/360, so I would regard it as a bug if the OS simulation can't handle it. To increment the record number by one, add 256 to the TTR. ITYM add 256 to the TTRz. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
W dniu 2012-08-08 17:11, Mike Schwab pisze: A zero byte VB record is expanded to 1 blank x'40' so the minimum is a block of 9 bytes including block size and record size field. I tried to allocate a FB 6 0 to hold a list of volsers for a table, LRL under 10 would not work. Do you mean LRECL=6? It does work. Even RECFM=FB,LRECL=1 does work. However I've never tried shorter records ;-))) -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
In 0fdb46cc-7d2e-4887-9f5c-fc29d9c2b...@aim.com, on 08/08/2012 at 09:45 AM, Paul Gilmartin paulgboul...@aim.com said: I do not find a stated minimum for the BDW. Absent firm information, I'll assume 4-byte blocks (nothing but BDW) are permissible. No, the minimum ios 8; see 3.2.3.1 Block Size (BLKSIZE) Minimum block size: If you specify a block size other than zero, there is no minimum requirement for block size except that format-V blocks have a minimum block size of 8. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
In CAJTOO58735VUTbFZ-GL2hvGg5=p=zoaf0271gsclbqt0y4j...@mail.gmail.com, on 08/08/2012 at 10:11 AM, Mike Schwab mike.a.sch...@gmail.com said: A zero byte VB record is expanded to 1 blank x'40' so the minimum is a block of 9 bytes including block size and record size field. Are you sure didn't specify A or M? From z/OS DFSMS Using Data Sets, SC26-7410-09: 3.2.3.1 Block Size (BLKSIZE) Minimum block size: If you specify a block size other than zero, there is no minimum requirement for block size except that format-V blocks have a minimum block size of 8. Note also: 3.1.3.1.2 Record Descriptor Word (RDW) A variable-length logical record consists of a record descriptor word (RDW) followed by the data. The record descriptor word is a 4 byte field describing the record. The first 2 bytes contain the length (LL) of the logical record (including the 4 byte RDW). The length can be from 4 to 32 760. 3.1.6.3 Using Magnetic Tape ... When you create a tape data set with variable-length record format-V or format-D, the control program pads any data block shorter than 18 bytes. For format-V records, it pads to the right with binary zeros so that the data block length equals 18 bytes. For format-D (ASCII) records, the padding consists of ASCII circumflex characters, which are equivalent to X'5E's. I tried to allocate a FB 6 0 to hold a list of volsers for a table, LRL under 10 would not work. What happened when you tried? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: File Processing
It wasn't easy. It was a Macro CICS shop on top of that, we were doIng a lot of CICS transactions and swore it was our code/IBM's. Later it was pretty funny. I never mind ppl not knowing that's not a big issue, but blaming without knowing or thinking you know well..what can I say ... Scott ford www.identityforge.com On Aug 7, 2012, at 9:57 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 39235829-1d9d-411b-bb12-6b739e1c2...@yahoo.com, on 08/07/2012 at 08:12 PM, Scott Ford scott_j_f...@yahoo.com said: I love it .I had a COBOL programmer bet me that our DOS/VSE system on our 4381 was causing her abend. She bet me a dinner, well I collected, brought her in and did a instruction trace pointed right to her code How did you get her to understand it and to admit to understanding it? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Message Flooding Problem
Barbara, Just curious you don't use dsitbl01 anymore or am I dating myself .lol Scott ford www.identityforge.com On Aug 8, 2012, at 1:08 AM, Barbara Nitz nitz-...@gmx.net wrote: Mark, No we don't, and that was one of the options I was looking at yesterday. use this one. You will need to change the name of the netview console(s) according to your naming conventions. You will also have to decide if you want to suppress them from hardcopy and joblog, just remove the statements. *Purpose: *Suppress messages completely from hardcopy log *Suppress messages being sent to a NetView *console from both hardcopy log and joblog *CTXTCNME: Consname to which msg is being routed * MPFEXIT1 START MPFEXIT1 AMODE 31 MPFEXIT1 RMODE ANY USING MPFEXIT1,R12 BAKR R14,0 LRR12,R15 B WORK DCC'MPFEXIT1-SYSDATE-SYSTIME' WORK L R5,0(R1)ADRESS PARAMETER-LIST USING CTXT,R5 L R6,CTXTCNMP get Console Name Pointer OICTXTSFB1,CTXTSNHC no hardcopy OICTXTRFB2,CTXTRNHC force no hardcopy OICTXTPFB2,CTXTPNHC force no hardcopy USING CTXTCNME,R6 maps console name CLI CTXTCNME,C'N' NETVIEW-CONSOLE ? BNE NOSUPP no, so no suppression OICTXTRFB2,CTXTRNHC force no hardcopy OICTXTERF3,CTXTESJL suppress from joblog DROP R5 DROP R6 NOSUPP PR LTORG IEZVX100 Installation Exit Parm List R1 EQU 1 R5 EQU 5 R6 EQU 6 R12 EQU 12 R14 EQU 14 R15 EQU 15 END Barbara -- 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: Space Allocation In Bytes
On Wed, Aug 8, 2012 at 1:43 PM, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In CAJTOO58735VUTbFZ-GL2hvGg5=p=zoaf0271gsclbqt0y4j...@mail.gmail.com, on 08/08/2012 at 10:11 AM, Mike Schwab mike.a.sch...@gmail.com said: deleted I tried to allocate a FB 6 0 to hold a list of volsers for a table, LRL under 10 would not work. What happened when you tried? On TSO ISPF 3.2, it failed with record length too short so I kept adding 1 to the LRECL until 10 worked. This was about 9 years ago. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using NOTE and POINT simulation macros on CMS?
On Wed, 8 Aug 2012 09:18:35 -0400, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: To increment the record number by one, add 256 to the TTR. ITYM add 256 to the TTRz. Does this work when you cross a track boundary? I might expect it to work less well for TTRz than for relative block number. And, in Using Data Sets: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d490/3.8.7.8 3.8.7.8 Using the POINT Macro to Position to a Block ... If the current record spans blocks, setting the z byte of the TTRz field to one lets you access the next record (not the next segment). Does this mean that if the current record spans several blocks, setting the z byte causes enough intervening blocks containing enough segments to be skipped that the block read contains the first segment of the next record? Wow! Does this apply to RECFM=VBS only? Does CMS support setting the z byte? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using NOTE and POINT simulation macros on CMS?
No, and a track boundary is not a multiple of 256. You have to compare the new record number to the maximum number of records that will fit on the track. Or, even more fun, if your records are variable-length, then you get to play with the track balance service to see if there is enough room left on the track for your next record regardless of its record number. When you cross a track boundary for whatever reason, the next sequential record number will be 1 and the track number will be one higher than the TT part of the previous TTR. Unless, of course, you have spanned records, and then it really gets fun. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane • Franklin, TN 37069-2526 • USA t: +1.617.614.4503 • e: bfairch...@rocketsoftware.com • w: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, August 08, 2012 3:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Using NOTE and POINT simulation macros on CMS? On Wed, 8 Aug 2012 09:18:35 -0400, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: To increment the record number by one, add 256 to the TTR. ITYM add 256 to the TTRz. Does this work when you cross a track boundary? I might expect it to work less well for TTRz than for relative block number. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Decouple Accenture's Install-1 from CICS
On Aug 8, 2012, at 1:56 PM, George, William@FTB wrote: - SNIP -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Scott Thanks for the info. I'm currently checking with our system's folks and management to see if there was ever any conversation's with Foundation regarding your question. There has been a tremendous amount of turnover over the years and at this point there is only a hodge podge of broken tid bits of information. Thanks again Bill Bill, Just a small opinion here. Sometimes its better to bite the bullet and do a clean install. That is now you got a good base to play with. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
no book manager files for db2 v10 so here is a lookat macro
Hello, We have used the bookmanager function with sdsf for years... but alas with version 10 of db2 no more book manager. Here is my attempt at a macro for the vista3270 emulator which calls lookat if you highlight the text and press the macro button .. I imagine it could be recoded for reflection, or any other emulator with macro functions. I would be interested if there are web functions for other 3rd party software .. ie ca? that could be added .. just a thought. I've had vista for at least 10 years and have never used the macro function until now! I was amazed at how powerful it is .. and all for $30! so here is my contribution .. * * This Macro calls IBM's LookAt * * this is a vista 3270 macro * *debug(startrow) *debug(startcol) *debug(endrow) *debug(endcol) *debug(selectboxactive) if selectboxactive = 0 msgx = EditBox(Enter the message id,error message,10); else lng = endcol - startcol + 1 msgx = screen(startrow,startcol,lng) *debug(msgx) endif WinExec(C:\Program Files\mozilla firefox\firefox.exe http://publibz.boulder.ibm.com/cgi-bin/zoslib/lookat?required=release=ZOS/V1R12msgid=+msgx); -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: File Processing
On Aug 7, 2012, at 7:12 PM, Scott Ford wrote: I love it .I had a COBOL programmer bet me that our DOS/VSE system on our 4381 was causing her abend. She bet me a dinner, well I collected, brought her in and did a instruction trace pointed right to her code Scott ford www.identityforge.com On Aug 7, 2012, at 3:27 PM, McKown, John john.mck...@healthmarkets.com wrote: Oh, wow. We must have had the same person working in the late 1970s at my first job. System abend is a System problem, FIX IT! was his first statement on an S0C7. I explained that System abend meant system detected problem. And I showed him how to find the statement which abended in his COBOL listing. He went away. And came back two days later with the same, unsolved, problem. I threw him out. The people on the other side of the print shop (next to my *office*, I had an office back then!) heard me. The only thing I learned from the DI was how to project. We had DOS/VS at that time. The DOS person said that DOS would occasionally kill his programs as well. With the words USER REQUESTED TERMINATION. The programmer screamed at the DOS person to show him where in his COBOL, it said PERFORM TERMINATION. He finally left IT and went to work for the water department. John: It could have been one of my boss's in later life. He was a former meter reader and his mental facilities worked well in that department. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Auditors Don't Know Squat!
Amen bro I am a mainframe believer for long time Scott ford www.identityforge.com On Aug 8, 2012, at 12:19 AM, Thomas Kern tlk_sysp...@yahoo.com wrote: On 8/7/2012 21:20, Robert A. Rosenberg wrote: At 10:17 + on 08/07/2012, Pearce, Colin E wrote about Re: Auditors Don't Know Squat!: Ask the Auditors if they will help you fill out all the APARs and collect the supporting documents IMO: Any Auditor who wants to tell me how to do my job (as opposed to just critiquing how I do it) is not qualified to do so UNLESS he can do my job in the first place. The worst part about all of these auditors, is that most of us who are being edged out of jobs because of declining mainframe usage can be better auditors than all of those that have visited me in my 36 years of mainframe work, BUT our bosses and the auditors' bosses just don't think mainframe dinosaurs know anything about computing, data integrity, information security. Some one who has never touched anything more than a windows workstation always knows more than we do. /Tom Kern -- 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: Decouple Accenture's Install-1 from CICS
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Wednesday, August 08, 2012 1:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Decouple Accenture's Install-1 from CICS On Aug 8, 2012, at 1:56 PM, George, William@FTB wrote: - SNIP -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Scott Thanks for the info. I'm currently checking with our system's folks and management to see if there was ever any conversation's with Foundation regarding your question. There has been a tremendous amount of turnover over the years and at this point there is only a hodge podge of broken tid bits of information. Thanks again Bill Bill, Just a small opinion here. Sometimes its better to bite the bullet and do a clean install. That is now you got a good base to play with. Ed Ed Nothing really to clean install that I can think of. If we remove Design\1 and Install\1 from CiCS we'll have hundreds of programs to rework to do the navigation logic and CICS calls that Install\1 was (is) doing in its black box. Not to mention the building of the BMS map source for the hundreds of maps. Install\1 keeps the map source hidden within its box also so we would have to use DFHBMSUP to recreate them which will be a piece of work as the utility does not carry over all the field names and give them generic names. Hence, my inquiry to anyone that may have gone through this and hoping for a better way. Thanks Bill __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RMM conversion to Common Time Support (UTC GMT)
Greetings, We are going to have to change one our SYSPLEX members from MST to CEST. To do this we will need to convert DFSMSRMM to Common Time Support. I'm just putting a feeler out there to see if anyone has done this and if so were there any unexpected issues or was the EDGUTIL utility with UPDATE UTC(YES) flawless with no fall out. Any feedback would be much appreciated. Regards, jeff -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Decouple Accenture's Install-1 from CICS
George: Find who hired them and let them have a free reign and fire them. Ed On Aug 8, 2012, at 4:28 PM, George, William@FTB wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Ed Gould Sent: Wednesday, August 08, 2012 1:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Decouple Accenture's Install-1 from CICS On Aug 8, 2012, at 1:56 PM, George, William@FTB wrote: - SNIP -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Scott Thanks for the info. I'm currently checking with our system's folks and management to see if there was ever any conversation's with Foundation regarding your question. There has been a tremendous amount of turnover over the years and at this point there is only a hodge podge of broken tid bits of information. Thanks again Bill Bill, Just a small opinion here. Sometimes its better to bite the bullet and do a clean install. That is now you got a good base to play with. Ed Ed Nothing really to clean install that I can think of. If we remove Design\1 and Install\1 from CiCS we'll have hundreds of programs to rework to do the navigation logic and CICS calls that Install\1 was (is) doing in its black box. Not to mention the building of the BMS map source for the hundreds of maps. Install\1 keeps the map source hidden within its box also so we would have to use DFHBMSUP to recreate them which will be a piece of work as the utility does not carry over all the field names and give them generic names. Hence, my inquiry to anyone that may have gone through this and hoping for a better way. Thanks Bill __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- 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: Space Allocation In Bytes
In CAJTOO5-_jCQt3_wepucjBcEqhu7sNFbv7TcE=4vabeyj5mv...@mail.gmail.com, on 08/08/2012 at 02:15 PM, Mike Schwab mike.a.sch...@gmail.com said: On TSO ISPF 3.2, it failed with record length too short so I kept adding 1 to the LRECL until 10 worked. This was about 9 years ago. Well, ISPF has its own rules, but I'd try to APAR it if it still does that. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
