Re: Determining 3390 Model
The DVOL and PDS commands use the DCE (returned from UCBSCAN) to determine the 3390 model number. Until EAV, any volumes larger than a model 9 were identified as model 9. The DCE model number for EAV DASD is A. There is a SHARE requirement to document the DCE in MACLIB. Regards, John K -IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote: - To: IBM-MAIN@listserv.ua.edu From: Edward Jaffe Sent by: IBM Mainframe Discussion List Date: 02/15/2013 07:19PM Subject: Re: Determining 3390 Model On 2/15/2013 4:19 PM, Dale McCart wrote: Any thing larger than a Mod 1 is listed as Mod 3 if not larger than a 3 Any thing larger than a Mod 3 is listed as Mod 9. Not true. If not Mod1, Mod2, Mod3 or Mod9, it is reported as ModA. This is true for both DS8xxx HMC and z/OS displays. DS P,8339 IEE459I 17.08.42 DEVSERV PATHS 648 UNIT DTYPE M CNT VOLSER CHPID=PATH STATUS RTYPE SSID CFW TC DFW PIN DC-STATE CCA DDC CYL CU-TYPE 08339,3390A ,A,041,MVSEV0,12=+ 2E=+ 2107 8003 Y YY. YY. N SIMPLEX 39 39 262668 2107 SYMBOL DEFINITIONS A = ALLOCATED + = PATH AVAILABLE Note this volume is listed as 3390A aka ModA. (Mod9 would be listed as 33909.) Since the volume has 262,668 cylinders, it would be listed as Mod236 using the technique suggested earlier in this thread. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining 3390 Model
Thanks for all replies. Our SPACE command also uses DCE to determine model number. Two points: 1. The reason I'd like to display a 'meaningful' model number is not for ordinary allocation but for volume-to-volume activities like copy (ADRDSSU) or mirroring. In such cases, it's important that the target volume match the source volume. Of course total capacity is the key, but an eyeball indicator would be helpful. We've had cases where a mismatched 'Mod-9' was incorrectly selected as target for a full-volume operation. For such purposes, all Mod-9s are not equal. 2. I tried DS P on one of our 'Mod27' volumes. It's reported as a Mod-9 rather than Mod-A: UNIT DTYPE M CNT VOLSER CHPID=PATH STATUS RTYPE SSID CFW TC DFW PIN DC-STATE CCA DDC CYL CU-TYPE 0149E,33909 ,A,000,R13DLB,A0=+ BF=+ C3=+ AE=+ A5=+ B7=+ C0=+ C4=+ 2107 1400 Y YY. YY. N SIMPLEX 9E 9E 30051 2107 SYMBOL DEFINITIONS This volume has a capacity of 3,0050 cylinders. But it's not EAV. 3. The SPACE command is very handy for day to day operations. As a TSO command, it can be issued at READY or anywhere a command line is available. No special authorization or environment is required. . . JO.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: Edward Jaffe edja...@phoenixsoftware.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 02/16/2013 08:26 AM Subject:Re: Determining 3390 Model Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On 2/16/2013 6:14 AM, John P Kalinich wrote: The DVOL and PDS commands use the DCE (returned from UCBSCAN) to determine the 3390 model number. Until EAV, any volumes larger than a model 9 were identified as model 9. The DCE model number for EAV DASD is A. As Dale McCart points out, a Mod6 volume (smaller than Mod9) is also shown as Mod9 by the DS,P command: IEE459I 08.20.48 DEVSERV PATHS 206 UNIT DTYPE M CNT VOLSER CHPID=PATH STATUS RTYPE SSID CFW TC DFW PIN DC-STATE CCA DDC CYL CU-TYPE 08110,33909 ,O,000,T4RES1,12=+ 2E=+ 2107 8001 Y YY. YY. N SIMPLEX 10 10 6678 2107 SYMBOL DEFINITIONS O = ONLINE + = PATH AVAILABLE There is a SHARE requirement to document the DCE in MACLIB. Cheryl Watson looked this up for me in the SHARE requirements system. The SHARE requirement number is SSMVSS12002. It contains the following. Don't shoot the messenger. :\ Response Code: RJ-Rejected Date: 2012-10-26 by Response: IBM does not intend to provide a solution to this request for the following reason: Reject Reason : Technical Reject Explanation : The DCE is not intended to be an external API. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Article for the boss: COBOL will outlive us all
On 16 February 2013 07:55, Timothy Sipples sipp...@sg.ibm.com wrote: For comparison -- and far worse when you think about it -- most automobiles have at least two ways of checking the oil level. One way is a binary readout, located on the dashboard. If the light is not illuminated, you have enough oil. If the light is illuminated, you don't. (I'm ignoring possible instrument failures.) The other way is to pull the hood (bonnet) release lever usually located inside the car, go to the front of the car (for front engine vehicles), pull the external hood release bar (which I can never remember how to do), lift the hood, unscrew the oil cap, remove the dipstick, clean the dipstick, insert the dipstick, remove the dipstick, and read the oil level That oil light (or gauge, if you have an old or very upscale new car) is measuring/displaying oil *pressure*, not level. They are related, to be sure, but not in a simple way. Interestingly, each can be reliably measured only under conditions where the other can't. And of course neither is what you really want to know about; both are proxies for something of actual importance. Now back to our regular COBOL, uh, programming. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining 3390 Model
On 2/16/2013 8:29 AM, Skip Robinson wrote: 2. I tried DS P on one of our 'Mod27' volumes. It's reported as a Mod-9 rather than Mod-A: We have various odd-sized volumes, so I did some experimentation. A Mod-51 shows as Mod9. A Mod-81 shows as ModA. I don't have a Mod-54 or Mod-55 to see for sure where the device number changes, but I suspect Mod-54 and lower is shown as Mod9 and Mod-55 and higher is shown as ModA. Does anyone have empirical evidence to confirm this? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining 3390 Model
A is when you get to EAVs with Cylinder Allocations. 9 is non-EAV without Cylinder Allocation areas. On Sat, Feb 16, 2013 at 12:57 PM, Edward Jaffe edja...@phoenixsoftware.com wrote: On 2/16/2013 8:29 AM, Skip Robinson wrote: 2. I tried DS P on one of our 'Mod27' volumes. It's reported as a Mod-9 rather than Mod-A: We have various odd-sized volumes, so I did some experimentation. A Mod-51 shows as Mod9. A Mod-81 shows as ModA. I don't have a Mod-54 or Mod-55 to see for sure where the device number changes, but I suspect Mod-54 and lower is shown as Mod9 and Mod-55 and higher is shown as ModA. Does anyone have empirical evidence to confirm this? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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: Load To Global with PC_cp
I presume that your SS entries are not working either and the whole load-to-global is a red herring. How did you setup the AX and AT? On Sat, 16 Feb 2013 16:15:14 GMT esst...@juno.com esst...@juno.com wrote: :Load To Global with PC_cp : :It is/was my understanding that a Service Provider Address Space :could issue a Load To Global for a program *and* use that program :as a Non Space Switching PC routine (PC_cp). : :Is my understanding incorrect ? : :In My Service Provider Address Space I issued the following Macro :R7 Has the Address Of The Name of the Program To Load... :* : LOAD EPLOC=(R7), : GLOBAL=(YES,P),ERRET=ZERR14,EOM=YES : :* : STM R15,R1,SVLOADZ Save Registers From Load :* :* :I follow the previous macro with a SETDEF macro as follows: : LRR2,R0 Address Of Loaded Module :* : ETDEF TYPE=SET,ETEADR=ETD2,ROUTINE=(2),RAMODE=31, : STATE=SUPERVISOR,PC=STACKING,SSWITCH=NO, : SASN=NEW,ASCMODE=PRIMARY, : PKM=OR, : AKM=(0:15),EKM=(0:15) : : :The Program Call Number for this routine is X'DD04'. :Routines DD00 thru DD03 are space switching routines. : :When My user program executes, It issues a PC instruction to call the Non Space Switching PC routine. The user program Abends with a x'0D6' and interrupt code of x'22'. Register 14 did in fact have the right PC# DD04 : :This appears to be a Linkage Translation Exception :A linkage index (LX) translation exception occurred; the program interruption code is X'22' : :So I said To Myself - Self, What is a Linkage Translation Exception ? :Looking At Principals Of Operation (POP) I see that a Linkage Translation Exception can occur under two conditions. :1)The linkage-table entry designated by the linkage-index part of the PC : number is beyond the end of the linkage table as designated by the : linkage-table designation used. : :2)Bit 0 of the linkage-table entry is not zero. : : :For the first condition The Linkage-Index is 00DD00. :And I have invoked PC# DD00 thru DD03 as space switching routines PC_ss. : :My Non Space Swithcing routine is associated with PC# DD04. :So I ruled that condition out. : :The second condition refers to a Non Zero Bit In the Linkage Table. :Im not understanding how my Cross Memory Setup would affect the Linkage Table in this way. :Actually I am really courious to know How I affected The Linkage Table. : : :So ... Can some one Explaing why I am Abending with a 0D6 - 22 :For A Non Space Switching Routine PC_cp that was loaded to common storage :via a Load To Global ? : :Im not understanding this. : :Should I be able to issue a Load To Global and expect it to be the :target of a Non Space Switching PC Routine from Other users. : : :SYSTEM COMPLETION CODE=0D6 REASON CODE=0022 : TIME=22.58.35 SEQ=04217 CPU= ASID=0024 : PSW AT TIME OF ERROR 078D 9DC00F6A ILC 4 INTC 22 : ACTIVE LOAD MODULE ADDRESS=1DC003E8 OFFSET=0B82 : NAME=XMSDRIVP : DATA AT PSW 1DC00F64 - 58E0 C3B0B218 E000D203 : GR 0: 1: 1DC008E4 : 2: 1DC008E4 3: 1DC008E4 : 4: 006D09B0 5: 006FF438 : 6: 1DC00E80 7: 1DC00958 : 8: 006E2EC8 9: 006FF6F8 : A: B: 006FF438 : C: 1DC003E8 D: 1DC006D4 : E: DD04 F: : END OF SYMPTOM DUMP : : : :Thank You :Paul D'Angelo :--- : :-- :For IBM-MAIN subscribe / signoff / archive access instructions, :send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems,
Re: Load To Global with PC_cp
It is/was my understanding that a Service Provider Address Space could issue a Load To Global for a program *and* use that program as a Non Space Switching PC routine (PC_cp). Is my understanding incorrect ? In My Service Provider Address Space I issued the following Macro R7 Has the Address Of The Name of the Program To Load... * LOAD EPLOC=(R7), GLOBAL=(YES,P),ERRET=ZERR14,EOM=YES * STM R15,R1,SVLOADZ Save Registers From Load * * I follow the previous macro with a SETDEF macro as follows: LRR2,R0 Address Of Loaded Module * ETDEF TYPE=SET,ETEADR=ETD2,ROUTINE=(2),RAMODE=31, STATE=SUPERVISOR,PC=STACKING,SSWITCH=NO, SASN=NEW,ASCMODE=PRIMARY, PKM=OR, AKM=(0:15),EKM=(0:15) The Program Call Number for this routine is X'DD04'. Routines DD00 thru DD03 are space switching routines. When My user program executes, It issues a PC instruction to call the Non Space Switching PC routine. The user program Abends with a x'0D6' and interrupt code of x'22'. Register 14 did in fact have the right PC# DD04 This appears to be a Linkage Translation Exception A linkage index (LX) translation exception occurred; the program interruption code is X'22' So I said To Myself - Self, What is a Linkage Translation Exception ? Looking At Principals Of Operation (POP) I see that a Linkage Translation Exception can occur under two conditions. 1)The linkage-table entry designated by the linkage-index part of the PC number is beyond the end of the linkage table as designated by the linkage-table designation used. 2)Bit 0 of the linkage-table entry is not zero. For the first condition The Linkage-Index is 00DD00. And I have invoked PC# DD00 thru DD03 as space switching routines PC_ss. My Non Space Swithcing routine is associated with PC# DD04. So I ruled that condition out. The second condition refers to a Non Zero Bit In the Linkage Table. Im not understanding how my Cross Memory Setup would affect the Linkage Table in this way. Actually I am really courious to know How I affected The Linkage Table. So ... Can some one Explaing why I am Abending with a 0D6 - 22 For A Non Space Switching Routine PC_cp that was loaded to common storage via a Load To Global ? Im not understanding this. Should I be able to issue a Load To Global and expect it to be the target of a Non Space Switching PC Routine from Other users. We recommend agianst using Load To Global. CSVDYLPA is the preferred method. However, that has nothing to do with your problem. ETDEF simply helps you create the data to pass to ETCON. The Linkage Table is modified by ETCON. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Article for the boss: COBOL will outlive us all
Tony H wrote | Now back to our regular COBOL, uh, programming. thus alluding to how many of us view of the language. Over a now long career I never took COBOL seriously. I was aware of it, and I even learned to write it by helping COBOL programmers with their problems. It is a verbose but finally very simple language. That said, I could not, and did not, think much of a language without real storage management, strings, pointers, booleans, etc., etc. It was move-oriented, compile-time bound, and synchronous, and I find these characteristics despicable. Recently, however, it has been greatly improved, making, for example, usable pointers and LIFO, local, i.e., 'automatic', storage available. It is now often possible to write something the way one wishes to write it in COBOL. These new facilities are not yet much used. Some shops indeed interdict their use as 'unnecessary'. Their availability does nonetheless make it possible to update a COBOL application using appropriate, adult technology; and this is important because many COBOL applications are so large that jettisoning them is, at least in the short term, economically impractical. Able but naif people often radically underestimate the resources and time that will be required to convert a COBOL application to, say, C/C++; and in the upshot they fail in their attempts to do so. I know of shops in which there have been four (sic) such failed attempts. New CIOs often launch a new one, the smartest of them going on to greener pastures before its failure too becomes obvious. It is, however, possible to refurbish and extend COBOL systems in COBOL. The trick in doing so is to use able programmers trained in a different tradition whom you bribe to learn COBOL, avoiding [most] experienced COBOL programmers as plague carriers or, better, using the best of them only as consultants about how an application currently works. 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: Article for the boss: COBOL will outlive us all
On 2/16/2013 12:25 PM, John Gilmore wrote: Tony H wrote | Now back to our regular COBOL, uh, programming. thus alluding to how many of us view of the language. Over a now long career I never took COBOL seriously. I was aware of it, and I even learned to write it by helping COBOL programmers with their problems. It is a verbose but finally very simple language. That said, I could not, and did not, think much of a language without real storage management, strings, pointers, booleans, etc., etc. It was move-oriented, compile-time bound, and synchronous, and I find these characteristics despicable. Recently, however, it has been greatly improved, making, for example, usable pointers and LIFO, local, i.e., 'automatic', storage available. It is now often possible to write something the way one wishes to write it in COBOL. These new facilities are not yet much used. Some shops indeed interdict their use as 'unnecessary'. Their availability does nonetheless make it possible to update a COBOL application using appropriate, adult technology; and this is important because many COBOL applications are so large that jettisoning them is, at least in the short term, economically impractical. Able but naif people often radically underestimate the resources and time that will be required to convert a COBOL application to, say, C/C++; and in the upshot they fail in their attempts to do so. I know of shops in which there have been four (sic) such failed attempts. New CIOs often launch a new one, the smartest of them going on to greener pastures before its failure too becomes obvious. It is, however, possible to refurbish and extend COBOL systems in COBOL. The trick in doing so is to use able programmers trained in a different tradition whom you bribe to learn COBOL, avoiding [most] experienced COBOL programmers as plague carriers or, better, using the best of them only as consultants about how an application currently works. John Gilmore, Ashland, MA 01721 - USA John, We have been fighting that battle for, oh, twelve years or more. We have courses that teach COBOL programmers how to use the latest facilities in general and then courses that teach specifics (especially handling XML, working with Unicode, using LE services where appropriate, coding and using DLLs, coding and running using z/OS UNIX services, coding CGIs in COBOL, and more). But we don't see much interest or enlightenment. Very frustrating. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining 3390 Model
It depends upon what is in the table or how a set of nested if-then-else statements were written. Such code is easy to replace. Consider mdlfind: procedure(MDLTABp, cyls) returns(character(6) varying) reorder ; /* uses lub-seeking binary search to find the subscript i of the element MDLTAB.tab.ncyl(i) for which MDLTAB.tab.ncyl = cyls is a minimum, i.e., min(i | MDLTAB.tab.ncyl = cyls) If such a lub is found the return code is set to 0 and the nickname of the corresponding pseudo-3390 model is returned as the value of this function. If instead no lub is found the return code is set to 1 and a null string is returned as the value of this function. */ /* parameters */ declare (MDLTABp /* - MDLTAB */ pointer, cyls /* cylinders */ binary fixed(31,0)) nonassignable ; /* table template */ declare 1 MDLTAB based(MDLTABp), 2 eye character(8) /* eyecatcher: 'MDLTAB ' */ 2 nmd/* number of models */ signed binary fixed(31,0), 2 tab(1 refer(MDLTAB.nmd), 3 ncyl /* number of cylinders */ signed binary fixed(31,0), 3 nick /* nickname */ character(6) varying ; /* LIFO scratch storage */ declare (lo, mi, hi, retcode) signed binary fixed(31,0) ; declare (again, bounded, search_higher) aligned bit ; declare nickout character(6) varying ; /* named constants, BIF used */ declare (F0 initial(0b), F1 initial(1b), F2 initial(10b)) signed binary fixed(31,0) ; declare pliretc builtin ; lo = F1 ; hi = MDLTAB.nmd ; do again = (lo = hi) repeat(lo = hi) while(again) ; mi = lo + (hi - lo)/F2 ; search_higher = (cyls MDLTAB.tab.ncyl) ; if search_higher then lo = mi + F1 ; else hi = mi - F1 ; end ; bounded = (hi = MDLTAB.nmd) ; if bounded then do ; retcode = F0 ; nickout = MDLTAB.tab.nick(hi) ; end ; else do ; retcode = F1 ; nickout = '' ; end ; call pliretc(retcode) ; return ; end mdlfind ; This is PL/I, but it could serve as a template for another implementation. One in assembly language would be easy; one in C would be possible. The merits of such an approach are that it consistently produces a least upper bound on a cylinders value and is easily changed/extended by changing only the external table it uses. 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
SV: Article for the boss: COBOL will outlive us all
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] För John Gilmore Skickat: den 16 februari 2013 20:25 Till: IBM-MAIN@LISTSERV.UA.EDU Ämne: Re: Article for the boss: COBOL will outlive us all Tony H wrote | Now back to our regular COBOL, uh, programming. thus alluding to how many of us view of the language. Over a now long career I never took COBOL seriously. I was aware of it, and I even learned to write it by helping COBOL programmers with their problems. It is a verbose but finally very simple language. That said, I could not, and did not, think much of a language without real storage management, strings, pointers, booleans, etc., etc. It was move-oriented, compile-time bound, and synchronous, and I find these characteristics despicable. COBOL is certainly not a programmers language. It's very restricted by its syntax and functionality and is often very clumsy to use. But that is also a feature: it's hard to obfuscate - which can be seen as an asset from the point of maintenance and security. (Which do not mean that you can't make unintelligible programs - I have seen many - but not at the lowest level.) It's also helpful when you need to understand the underlying data structure the program is based on. Regards Thomas Berg Thomas Berg Specialist z/OS/IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Article for the boss: COBOL will outlive us all
Steve, I too have taught courses in 'modern COBOL' in client shops. I have stopped doing so. What I accomplished was to turn the brightest younger programmers into disaffected employees because their managers were unsupportive. Some of them were, I suspect, already disaffected; but I was blamed for their departures when they sought more interesting employment. The approach I suggested is, I think, a better one. Teach COBOL to some established, competent C or assembly-language programmers. This can be done in three weeks iff, to use a wonderful word I recently encountered, they are properly 'incentivated'. It does need a different approach. With such programmers, one need only provide answers to the classic three questions: o What are the data types? o What operations can be performed on them? o How is the path of control among these operations specified? emphasizing branch tables, iteration, and recursion, all of which are now possible in COBOL, in answering this last question. Then one provides a lot of competitive, ruthlessly criticized practice in writing COBOL subroutines for which you have test bed/drivers in place. The culture of most COBOL shops is so complacent that disruptive technology is very hard to teach in them. It is not, I am sure, impossible; but it is almost certainly uneconomic. . 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: SV: Article for the boss: COBOL will outlive us all
Thomas, I don't follow, writing in several languages , what awkward to do in cobol, supervisory stuff yes for sure. Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Feb 16, 2013, at 2:53 PM, Thomas Berg thomas.b...@swedbank.se wrote: -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] För John Gilmore Skickat: den 16 februari 2013 20:25 Till: IBM-MAIN@LISTSERV.UA.EDU Ämne: Re: Article for the boss: COBOL will outlive us all Tony H wrote | Now back to our regular COBOL, uh, programming. thus alluding to how many of us view of the language. Over a now long career I never took COBOL seriously. I was aware of it, and I even learned to write it by helping COBOL programmers with their problems. It is a verbose but finally very simple language. That said, I could not, and did not, think much of a language without real storage management, strings, pointers, booleans, etc., etc. It was move-oriented, compile-time bound, and synchronous, and I find these characteristics despicable. COBOL is certainly not a programmers language. It's very restricted by its syntax and functionality and is often very clumsy to use. But that is also a feature: it's hard to obfuscate - which can be seen as an asset from the point of maintenance and security. (Which do not mean that you can't make unintelligible programs - I have seen many - but not at the lowest level.) It's also helpful when you need to understand the underlying data structure the program is based on. Regards Thomas Berg Thomas Berg Specialist z/OS/IT Delivery SWEDBANK AB (Publ) -- 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: JES Extended Status (SSI 80)
Working now. I set the macro version incorrectly. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Austin Sent: 15 February 2013 15:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: JES Extended Status (SSI 80) Hello, With JES2 on Z/OS 1.13 this works when I specify STATTERS or STATOUTT, but for STATVRBO, STATOUTV and STATDLST I get a SSOBRETN of X'0C' and a STATREAS of X'00'. For all the requests I'm setting statsjb1, statshld, statsnhl, statsshl and statssnh; statjbil and statjbih contain the same job number. Any idea why the verbose requests are failing? Thanks Steve This e-mail message has been scanned and cleared by Postini / Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail message has been scanned and cleared by Postini / Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SV: Article for the boss: COBOL will outlive us all
On Sat, Feb 16, 2013 at 3:26 PM, Scott Ford scott_j_f...@yahoo.com wrote: Thomas, I don't follow, writing in several languages , what awkward to do in cobol, supervisory stuff yes for sure. Yoda? Is that you? :-) If this was supposed to be asking What is it that's awkward to do in COBOL?, try calculating the offset between two data elements. For one. I know that every time I go to write something in it, I run up against You just can't do that in this language and my response is Seriously? Wow. (OK, or I write an assembler function to enable what I need...) Admittedly, COBOL isn't as bad as I'd been led to believe by three decades of avoiding it -- but as the saying goes, You can write your program in pick a language, or you can write a story about your program in COBOL. -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ARC0126I Type inconsistent at DFHSM start-up
Hello, I've on ARCCMDxx the following add cmd: ADDVOL CCAT01 UNIT(3390) PRIMARY - (NOAUTOMIGRATION - NOAUTOBACKUP - AUTODUMP(MENSAL)) however at dfhsm start-up I get: ARC0126I ADDVOL CCAT01 REJECTED - TYPE INCONSISTENT 170 170 ARC0126I (CONT.) WITH DFSMSHSM CDS, RC=20 After doing f dfhsm,list mvol, I've noticed that unit type has 3380 instead of 3390. What can I do to set the correct unit type ?? Do a full volume dump, init and restore ??? I'm on z/os V1.10 Any hint is welcome. Many thx, A.CEcilio. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SV: Article for the boss: COBOL will outlive us all
Ba zing ...ok zMan, I agree I write Assembler, C ...on the MF ..I agree ..multi-tasking is a bit rough Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Feb 16, 2013, at 4:14 PM, zMan zedgarhoo...@gmail.com wrote: On Sat, Feb 16, 2013 at 3:26 PM, Scott Ford scott_j_f...@yahoo.com wrote: Thomas, I don't follow, writing in several languages , what awkward to do in cobol, supervisory stuff yes for sure. Yoda? Is that you? :-) If this was supposed to be asking What is it that's awkward to do in COBOL?, try calculating the offset between two data elements. For one. I know that every time I go to write something in it, I run up against You just can't do that in this language and my response is Seriously? Wow. (OK, or I write an assembler function to enable what I need...) Admittedly, COBOL isn't as bad as I'd been led to believe by three decades of avoiding it -- but as the saying goes, You can write your program in pick a language, or you can write a story about your program in COBOL. -- zMan -- I've got a mainframe and I'm not afraid to use it -- 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: Determining 3390 Model
On 2/16/2013 11:04 AM, Mike Schwab wrote: A is when you get to EAVs with Cylinder Allocations. 9 is non-EAV without Cylinder Allocation areas. The problem with this theory is that EAV is a z/OS software concept only. It does not apply to other operating systems. More to the point, the hardware doesn't know about track-managed space, cylinder-managed space, break-point values, etc; it knows only about the size of the volume in cylinders (or Mod1 multiples). Yet, the DS8100 (2107) hardware console--whose display I would paste in if IBM-MAIN allowed anything other than plain text--shows 3390-9 as the model number for the Mod-51 volume and shows 3390-A as the model number for the Mod-81 volume. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SV: Article for the boss: COBOL will outlive us all
zMan, But there are manglers , aka managers who say Assembler ode is hard to maintain because of te skillset required. Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Feb 16, 2013, at 4:35 PM, Scott Ford scott_j_f...@yahoo.com wrote: Ba zing ...ok zMan, I agree I write Assembler, C ...on the MF ..I agree ..multi-tasking is a bit rough Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Feb 16, 2013, at 4:14 PM, zMan zedgarhoo...@gmail.com wrote: On Sat, Feb 16, 2013 at 3:26 PM, Scott Ford scott_j_f...@yahoo.com wrote: Thomas, I don't follow, writing in several languages , what awkward to do in cobol, supervisory stuff yes for sure. Yoda? Is that you? :-) If this was supposed to be asking What is it that's awkward to do in COBOL?, try calculating the offset between two data elements. For one. I know that every time I go to write something in it, I run up against You just can't do that in this language and my response is Seriously? Wow. (OK, or I write an assembler function to enable what I need...) Admittedly, COBOL isn't as bad as I'd been led to believe by three decades of avoiding it -- but as the saying goes, You can write your program in pick a language, or you can write a story about your program in COBOL. -- zMan -- I've got a mainframe and I'm not afraid to use it -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining 3390 Model
On Sat, Feb 16, 2013 at 3:35 PM, Edward Jaffe edja...@phoenixsoftware.com wrote: On 2/16/2013 11:04 AM, Mike Schwab wrote: A is when you get to EAVs with Cylinder Allocations. 9 is non-EAV without Cylinder Allocation areas. The problem with this theory is that EAV is a z/OS software concept only. It does not apply to other operating systems. More to the point, the hardware doesn't know about track-managed space, cylinder-managed space, break-point values, etc; it knows only about the size of the volume in cylinders (or Mod1 multiples). Yet, the DS8100 (2107) hardware console--whose display I would paste in if IBM-MAIN allowed anything other than plain text--shows 3390-9 as the model number for the Mod-51 volume and shows 3390-A as the model number for the Mod-81 volume. -- Edward E Jaffe But they did code into the DS8### the number of cylinders for the Mod 3, Mod 9, 32K cylinders, 64K cylinders, the 2 bit EAV limit, and now the 4 bit EAV value. -- 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: ARC0126I Type inconsistent at DFHSM start-up
Does it contain any ML1 output ? since if it was not having any data than delvol/init addvol should work... If there's a data you may like to follow Case 8: Damaged ML1 Volumes in DFSMSHsm data recovery scenario. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Article for the boss: COBOL will outlive us all
On Feb 16, 2013, at 2:15 PM, John Gilmore wrote: --- SNIP-- The culture of most COBOL shops is so complacent that disruptive technology is very hard to teach in them. It is not, I am sure, impossible; but it is almost certainly uneconomic. . John (and Steve), I suspect COBOL programmers want to lean how to basically code COBOL programs and how to debug them PERIOD. I would suggest that any advanced facilities be taught in a separate class only for programmers that want to be adventerous. COBOL programmers are under the gun to be (if you must) work horses and nothing else. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ARC0126I Type inconsistent at DFHSM start-up
I think the first step should be to find out what the device really is. It doesn't matter what HSM thinks it he is wrong. What does the system command D U,VOL=CCAT01 show? Why are you adding CCAT01 as a primary volume but attempting to display it with a LIST MVOL command which deals only with migration volumes? Why does the volume even appear in the response? Which type of volume is it (or should it be)? If it is in fact a migration volume, I suggest FREEVOL would be the logical first step and then perhaps DELVOL. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of af dc :: Sent: Saturday, February 16, 2013 1:26 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: ARC0126I Type inconsistent at DFHSM start-up :: :: Hello, :: I've on ARCCMDxx the following add cmd: :: :: ADDVOL CCAT01 UNIT(3390) PRIMARY - :: (NOAUTOMIGRATION - :: NOAUTOBACKUP - :: AUTODUMP(MENSAL)) :: :: however at dfhsm start-up I get: :: ARC0126I ADDVOL CCAT01 REJECTED - TYPE INCONSISTENT 170 ::170 ARC0126I (CONT.) WITH DFSMSHSM CDS, RC=20 :: :: :: After doing f dfhsm,list mvol, I've noticed that unit type has 3380 :: instead of 3390. :: What can I do to set the correct unit type ?? Do a full volume dump, :: init :: and restore ??? :: :: I'm on z/os V1.10 :: :: Any hint is welcome. :: Many thx, A.CEcilio. :: :: -- :: 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
