Re: SMP/E question
I learned the hard way. It was the first upgrade I was part of, I came in in the middle and they were cutting corners applying to the live system. It really breaks when the attempt to apply a PTF to IEBCOPY blows space in LINKLIB and retry attempts to use the partially done copy of IEBCOPY to compress that active LINKLIB. Next time, and everytime since, I apply to a target volume, clone to an operational volume and ipl. I actually never ipl from the SMP/E target libraries. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Edward Jaffe Sent: Saturday, October 06, 2012 6:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E question On 10/6/2012 1:03 PM, Skip Robinson wrote: Would not APPLY CHECK have revealed the missing PTF before any real harm had been done? If not, then never mind. No. The APPLY CHECK would not have helped in that case. Nothing was missing and there was nothing SMP/E could have done differently. Both co-req PTFs were available and were being installed together in the same APPLY but there was an out-of-space space failure on the ZFS at APPLY time. A logic error in the z/OS UNIX install shell script caused it to do the wrong thing such that, after the space issue was resolved, a second APPLY attempt of the PTFs would always result in a deleted JDK. (The script made an invalid assumption that one of the PTFs was already fully installed because it found a build part from that PTF in the target directory.) The fix was to correct the erroneous logic in the z/OS UNIX install shell script. See http://www- 01.ibm.com/support/docview.wss?uid=swg1IV05507 I recognize that, compared to the experience of some of the old-timers on this list, I've been servicing our systems this way for a relatively short time (only about 15 years or so). I'm prepared for the very real possibility that I might come across a pathological situation that will be inconvenient enough to convince me to do things differently. Or perhaps I will retire first, who knows? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Has anyone taken out hardware support for z196 from anyone other than IBM
W dniu 2012-10-04 13:44, Bruno Sugliani pisze: On Thu, 4 Oct 2012 05:16:02 -0500, Mike Schwab mike.a.sch...@gmail.com wrote: I thought it was a 3 year minimum. Its only been out for 2 years. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? Nope ..1 year for CPU and generally 3 or 4 years for DASD Unless it has changed very recently It hasn't changed. 1 year for CPC, expandable to 3 years. IMHO very hard to negotiate longer period. After 3 years extensions are possible, but simply more expensive than new CPC. Because of that having 3 years old machine under IBM support is kind of masochism. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając 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 Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2012 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.410.984 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E question
On 10/7/2012 3:33 AM, Gibney, Dave wrote: I learned the hard way. It was the first upgrade I was part of, I came in in the middle and they were cutting corners applying to the live system. It really breaks when the attempt to apply a PTF to IEBCOPY blows space in LINKLIB and retry attempts to use the partially done copy of IEBCOPY to compress that active LINKLIB. I noticed that, on slide 22 of his SHARE presentation, Ed recommends compressing SYS1.LINKLIB (and a few other key libraries) in advance of actually running the APPLY. That step might be intended to avoid exactly the sort of issue you're describing. ISTR that in the old days IEBCOPY was designed differently than it is now; multiple load modules, perhaps even an overlay structure. Not any more. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com 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: Is there a correspondence between 64-bit IBM mainframes and PoOps editions levels?
On Sun, Oct 7, 2012 at 8:18 AM, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: That doesn't suggest that it wasn't available on a 360/50, just that your installation wasn't aware of it or wasn't willing to pay for it. Nor does it prove it was. What's your point? Oh, right, you don't have one. Plonk. -- 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
Re: SMP/E question
Edward Jaffe edja...@phoenixsoftware.com wrote: As a part-time sysprog, I abbreviate your approach even more. I have no time for pesky 'CHECK' operations. Do you chase down the prereq/coreq chains by hand then? -- Jeremy C B Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a correspondence between 64-bit IBM mainframes and PoOps editions levels?
shmuel+ibm-m...@patriot.net (Shmuel Metz , Seymour J.) writes: Every generation believes that it invented sex. The 4300 may mark MVCIN becoming standard, but the instruction is much older than the 4300. The Technion had it on their 370/165 in 1972, and I believe that it was available on the 360/50. there were lots of special instructions done for 360/50 ... the ibm boston programming center was doing conversational programming system which would include support for new instructions implemented on 360/50. some amount of the work was subcontracted to allen-babcock http://www.bitsavers.org/pdf/allen-babcock/cps/CPS_Progress_Report_may66.pdf lists (new microcode for 360/50): EVAL Evaluate an arithmetic expression CHBone byte item list search operation CHBE CHHtwo byte item list search operation CHHE LDMload multiple floating point STDM store multiple floating point LUMload under mask STUM store under mask TACTable ANDed Characters (extensions of translatetest) TOCTable Ored Characters BS Binary Search ADDFloating decimal instructions SUB COMP MULT DIV ... IBM Boston Programming Center was on 3rd flr of 545 tech sq. When the cp67 group split off from the science center (on the 4th flr) and also started the morph from cp67 to vm370 ... they moved to the 3rd flr and took over the Boston Programming Center (including the CPS people) ... while they were now working on vm370/cms ... they did do a port of CPS to CMS (aka CPS could run on plain 360 w/o the new instructions). The original virtual machine implementation had also been targeted for 360/50 ... (before 360/67 was available standard with virtual memory) ... but since nearly all spare 360/50s were going to the FAA Air Traffic Control effort (which had a whole different set of modifications), the science center had to settle for 360/40 ... where they did the hardware changes to provide virtual memory support ... and implemented virtual machine cp/40 (and lots of early cms development was done in parallel on the bare 360/40). Later when 360/67 was available, cp/40 morphed into cp/67. as the vm370 group on the 3rd flr expanded ... they outgrew the space and moved out to the old SBC building in burlington mall (SBC having been transferred to CSC as part of settling some litigation). also as part of morph of cp67/cms to vm370/cms ... the ability for cms to execute on a real machine was crippled. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zero length records outlawed! (Again.)
In 50706996.8050...@valley.net, on 10/06/2012 at 01:25 PM, Gerhard Postpischil gerh...@valley.net said: Perhaps I'm missing something, but hex 0004 defines a null record in V, VB, and VBS. VBS runs fine without segment descriptor bits. Note that in 20121005215823.eaa21f58...@smtp.patriot.net I wrote SC26-7410-09, the 1.11 version of DFSMS Using Data Sets, still gives the minimum length of an SDW as 5. However, it does not explicitly say whether the RDW or SDW limit applies when the segment control field is 00. and that nobody answered the question. Have you verified that for VBS an SDW with a zero segment control field is treated as an RDW, and thus allowed to specify a zero length? -- 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: Is there a correspondence between 64-bit IBM mainframes and PoOps editions levels?
In CAE1XxDGm_LJqWCaF+b3UKjESDqQ57qYo9BTNJ+eXBCpBmDr=l...@mail.gmail.com, on 10/06/2012 at 04:49 PM, John Gilmore jwgli...@gmail.com said: BIF has come to be the generic term, but the same notion has been given different names in different statement-level procedural languages. COBOL, for example, calls them intrinsic functions. The idea is an important one. None of us wants to use an SLPL in which such constructs as y = sqrt(x) ; or the like are not immediately available. The weasel C term 'library function' is for this reason unfortunate. It leaves open the question who must implement them. (BIF instead makes it clear than they must come with a compiler or interpeter.) Not even close. A BIF is a function that the compiler recognizes; adding a routine to a link or run time library does not make it a BIF. Frequently, but not always[1], the compiler will generate inline code for a BIF. [1] E.g., not for evry BIF or not for every use of a specific BIF. -- 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: Is there a correspondence between 64-bit IBM mainframes and PoOps editions levels?
On Sun, 7 Oct 2012 12:13:29 -0400, Anne Lynn Wheeler wrote: as the vm370 group on the 3rd flr expanded ... they outgrew the space and moved out to the old SBC building in burlington mall (SBC having been transferred to CSC as part of settling some litigation). also as CSC? CDC? part of morph of cp67/cms to vm370/cms ... the ability for cms to execute on a real machine was crippled. Bummer. And I discovered decades ago tnat the CMS PRINT command wouldn't work with an ATTACHed real printer. Bummer. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a correspondence between 64-bit IBM mainframes and PoOps editions levels?
It would be possible to become angry about Shmuel's literalisms, selective quotations, context mixing and switching, and the like. It would even be possible to enter into protracted disputes about them with him, as I used to do too often. I no longer judge it worthwhile to do this. His gadfly posts give him great satisfaction; they are sometimes useful; and even when they are not they are, finally, innocuous. This time, for example, he has, a little opaquely, disentangled the source-language syntactic form of a function reference from its implementation, which may sometimes usefully be in line instead of by library-subroutine call. It is true, for example, that for such PL/I constructs as declare vname character(46) varying, vnl signed binary fixed(15,0), length builtin ; . . . vnl = length(vname) ; IBM and many other PL/I compilers implement the BIF length in line. (There would be scope for C compilers to do similar things in some cases, but I am not aware that any does them.) Still, this distinction between syntactic form and implementation strategy and the option it makes available to compiler writers are important. This case is not an isolated one. It would not be unfair, I think, to characterize Shmuel's posts as a mixture of gratuitous contention and redeeming technical information. --jg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E question
While Ed and I differ on the need for CHECK and on the practice of injecting maintenance directly into the body of a running system, we agree on the pointlessness of chasing down sysmod error chains. SMP/E is designed--at some considerable cost in blood, sweat, and tears--*not* to install any sysmod whose pre- or co-req fails for any reason. All manual labor to Sherlock the labyrinth of sysmod interdependence accomplishes the same result as SMP/E does with no effort on your part. This is not about weighing various outcomes. The outcome will be *the same* whether you code up iteratively more complex EXCLUDE lists or just let SMP/E do the job you're paying it to do. Look at the CAUSER report to learn which sysmods were patient zero in each error chain. Investigate these few if you wish to satisfy yourself that no GA PTF actually exists. Then you're done. A clarification on the practice of 'cloning' environments. As long as you have the modest luxury of keeping a couple of sysres sets around--way cheaper than it used to be in the days of SLED--you can maintain one full set of Target volumes where all maintenance is installed. You clone that set to produce an IPL set. Future maintenance goes against the same Target set, which is updated *only* by SMP/E. The Target set lives on until the next ServerPac creates a new one. Ad infinitum. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Jeremy Nicoll - ls mainframes jn.ls.mfrm...@letterboxes.org To: IBM-MAIN@LISTSERV.UA.EDU Date: 10/07/2012 08:53 AM Subject:Re: SMP/E question Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Edward Jaffe edja...@phoenixsoftware.com wrote: As a part-time sysprog, I abbreviate your approach even more. I have no time for pesky 'CHECK' operations. Do you chase down the prereq/coreq chains by hand then? -- Jeremy C B Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a correspondence between 64-bit IBM mainframes and PoOps editions levels?
C/C++ inlines apparent external functions frequently. You can ask the compiler to inline user-written functions. See the inline keyword. -- Sent from my mobile phone. Please excuse my brevity. Charles John Gilmore jwgli...@gmail.com wrote: It would be possible to become angry about Shmuel's literalisms, selective quotations, context mixing and switching, and the like. It would even be possible to enter into protracted disputes about them with him, as I used to do too often. I no longer judge it worthwhile to do this. His gadfly posts give him great satisfaction; they are sometimes useful; and even when they are not they are, finally, innocuous. This time, for example, he has, a little opaquely, disentangled the source-language syntactic form of a function reference from its implementation, which may sometimes usefully be in line instead of by library-subroutine call. It is true, for example, that for such PL/I constructs as declare vname character(46) varying, vnl signed binary fixed(15,0), length builtin ; . . . vnl = length(vname) ; IBM and many other PL/I compilers implement the BIF length in line. (There would be scope for C compilers to do similar things in some cases, but I am not aware that any does them.) Still, this distinction between syntactic form and implementation strategy and the option it makes available to compiler writers are important. This case is not an isolated one. It would not be unfair, I think, to characterize Shmuel's posts as a mixture of gratuitous contention and redeeming technical information. --jg _ 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: SMP/E question
Skip Robinson jo.skip.robin...@sce.com wrote: While Ed and I differ on the need for CHECK and on the practice of injecting maintenance directly into the body of a running system, we agree on the pointlessness of chasing down sysmod error chains. It's abiut 20 years since I last did this. IIRC there's some operand one can code on an APPLY which will pull in all the missing prereq/coreq PTFs when you specify just the few you know you need. Even if we used that, we did so only on the APPLY CHECK to find out what total set of PTFs were required for the intended stuff to APPLY. And before actually running the APPLY someone would read the cover letters for all the extra PTFs that were going to be applied that weren't the ones we explicitly wanted to apply. Someone had to be aware of areas of the system whose behaviours might be about to change. Are you saying you wouldn't bother doing that? We only applied fixes directly to test systems which would be IPLed multiple times before those systems were cloned into first development and then finally production systems. -- Jeremy C B Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E question
Coincidentally, it's about 20 years since the upgrade I got bit on. Much of the blood, sweat etc that Skip describes happened in those 20 years. I agree with both Skip and Ed that SMP/E will do all the checking for you. Last time I did this, I still did the iterative runs of check until I got a zero, but I run the check as part of the order from network process. Whenever I decide to actually APPLY, I already have the clean exclude list. Unfortunately, I have probably run my last APPLY here. So, I can't say for sure if I would follow Skip's adive next time :( -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jeremy Nicoll - ls mainframes Sent: Sunday, October 07, 2012 11:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E question Skip Robinson jo.skip.robin...@sce.com wrote: While Ed and I differ on the need for CHECK and on the practice of injecting maintenance directly into the body of a running system, we agree on the pointlessness of chasing down sysmod error chains. It's abiut 20 years since I last did this. IIRC there's some operand one can code on an APPLY which will pull in all the missing prereq/coreq PTFs when you specify just the few you know you need. Even if we used that, we did so only on the APPLY CHECK to find out what total set of PTFs were required for the intended stuff to APPLY. And before actually running the APPLY someone would read the cover letters for all the extra PTFs that were going to be applied that weren't the ones we explicitly wanted to apply. Someone had to be aware of areas of the system whose behaviours might be about to change. Are you saying you wouldn't bother doing that? We only applied fixes directly to test systems which would be IPLed multiple times before those systems were cloned into first development and then finally production systems. -- Jeremy C B Nicoll - my opinions are my own. -- 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: SMP/E question
Whether or not you include GOUPEXTEND to pick up additional PTFs to resolve hold errors, I feel strongly that the real APPLY should encompass exactly the same selection of sysmods as the corresponding CHECK. I submit my real APPLY via SDSF SJ with CHECK commented out. As for HOLD data, we have separate groups that support MVS, CICS, DB2, storage, performance, etc. Even separate individuals focus on various components. I print out nontrivial HOLD records and deliver them to the interested parties. (I consider IPL/restart records trivial because we always IPL maintenance from an alternate sysres.) No one here seems much interested in DOC records, which generally describe new and extended function that may be implemented optionally. A change that requires behavioral system adaptation should be covered by some other HOLD record that I distribute to the responsible person(s) . . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Jeremy Nicoll - ls mainframes jn.ls.mfrm...@letterboxes.org To: IBM-MAIN@LISTSERV.UA.EDU Date: 10/07/2012 11:19 AM Subject:Re: SMP/E question Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Skip Robinson jo.skip.robin...@sce.com wrote: While Ed and I differ on the need for CHECK and on the practice of injecting maintenance directly into the body of a running system, we agree on the pointlessness of chasing down sysmod error chains. It's abiut 20 years since I last did this. IIRC there's some operand one can code on an APPLY which will pull in all the missing prereq/coreq PTFs when you specify just the few you know you need. Even if we used that, we did so only on the APPLY CHECK to find out what total set of PTFs were required for the intended stuff to APPLY. And before actually running the APPLY someone would read the cover letters for all the extra PTFs that were going to be applied that weren't the ones we explicitly wanted to apply. Someone had to be aware of areas of the system whose behaviours might be about to change. Are you saying you wouldn't bother doing that? We only applied fixes directly to test systems which would be IPLed multiple times before those systems were cloned into first development and then finally production systems. -- Jeremy C B Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E question
Skip Robinson jo.skip.robin...@sce.com wrote: Whether or not you include GOUPEXTEND to pick up additional PTFs to resolve hold errors, I feel strongly that the real APPLY should encompass exactly the same selection of sysmods as the corresponding CHECK. I submit my real APPLY via SDSF SJ with CHECK commented out. I wasn't a fan of GROUPEXTEND, except perhaps to speed up the original discovery of what PTFs one would actually need to be applying; I tended to explicitly select the PTFs I wished to APPLY. As for HOLD data, we have separate groups that support MVS, CICS, DB2, storage, performance, etc. Even separate individuals focus on various components. Same for us. I print out nontrivial HOLD records and deliver them to the interested parties. Likewise. It did need a reasonably intelligent sysprog to make sure all interested parties did see the relevant details, not always just those in the obvious other teams. Quite often those other depts would wish to do specific testing of the changes concerned too, which could delay the implementation of the primary fixes involved. -- Jeremy C B Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a correspondence between 64-bit IBM mainframes and PoOps editions levels?
Are you familiar with C++ templates? One could define, and some compiler vendor libraries define, functions which work as you describe. -- Sent from my mobile phone. Please excuse my brevity. Charles John Gilmore jwgli...@gmail.com wrote: I am familiar with the inline option. What it does is not what I had in mind. I should have been more specific. I meant independent C implementations. IBM C and IBM PL/I share the same optimizing and code-generation machinery. A [simple] mathematical example will make the appropriate distinctions clearer. Consider declare i signed binary fixed(63,0), ((x, y) real, z complex) decimal float(16), abs builtin ; . . . i = abs(i) ; /* example 1 */ x = abs(x) ; /* example 2 */ y = abs(z) ; /* example 3 */ Example 1 and example 2 are always evaluated by trivial compiled code. They reduce conceptually to a single machine instruction. Example 3 is instead evaluated by a library subroutine. Why? Recall that for complex z = a + bi, abs(z) = sqrt(a**2 + b**2). Here, as usual, generic functions employing syntactically identical constructs are evaluated in datatype- and domain-specific ways. (All this is of course irrelevant for FORTRAN-like C, which does not have generic functions.) 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: Zero length records outlawed! (Again.)
On Sun, 7 Oct 2012 17:10:16 -0400, Gerhard Postpischil wrote: I just ran a series of tests, writing a VB data set, then a VBS data set, with various data lengths from 0 to 20, once with move mode and once with locate. All ran fine. Then I ran analogous tests reading the data sets, and dumping the input; an additional read with BFTEK=A also worked correctly. So the description doesn't match QSAM behavior; is it possible the author was thinking of compiler library code? It's possible that when the specification for RECFM=VB was changed, the doc writer overlooked the corresponding change for RECFM=VBS. The doc and the product ought to be brought into agreement, either by changing the doc or reporting the error. But this is all empirical. It's possible that a programmer writing a utility for IBM or ISV uses BSAM and conscientiously checks for all errors and reports the occurrence of an empty segment in a VBS data set, shich is contrary to spec (do you agree?) as an error. If it's contrary to spec and it breaks you're allowed to keep both pieces. Does BFTEK=A apply to output, or only to input? If an empty segment is allowed as an interior segment, a programmer could inflate a logical record with an arbitrary number of empty segments. Ugh! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IEW2763S
I'm trying to use a UNIX (USS) directory (actually NFS mounted) for Binder input. In some cases it works well; in others where I see no apparent differences other than the pathname I get: IEW2763S DE07 FILE ASSOCIATED WITH DDNAME LIB001 CANNOT BE OPENED BECAUSE THE FILE DOES NOT EXIST OR CANNOT BE CREATED. IEW2302E 1031 THE DATA SET SPECIFIED BY DDNAME LIB001 COULD NOT BE FOUND, AND THUS HAS NOT BEEN INCLUDED. If I reconstruct what I believe to be the full pathname, I can open it and read it after the Binder has failed. LISTALC shows me that LIB001 is allocated to the intended USS directory. There's no additional information in SYSLOG. It would be valuable to have return value and ERRNO from open(1). Binder doesn't tell me. MC hints that IEW2763S corresponds to ENOENT while giving no explanation for the DE07 token appearing in the message. If a file is opened successfully, its pathname appears in DATA SET SUMMARY; if it fails, DATA SET SUMMARY shows nothing. This is quite backward from what the programmer needs for diagnosis. I specified: 1z/OS V1 R12 BINDER 15:52:30 SUNDAY OCTOBER 7, 2012 IEW2278I B352 INVOCATION PARAMETERS - MAP,SIZE=(400K,96K),XREF,REUS,RENT,REFR,LIST=ALL Is there an option that would give me more complete information? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a correspondence between 64-bit IBM mainframes and PoOps editions levels?
I am familiar with C++ templates. I said C, not C++ with all its baggage. But enough! Have fun! Make as many debater's points as you like. Perhaps you can work in the dawn horse, eohippus, too. I shall not comment further. --jg On 10/7/12, Charles Mills charl...@mcn.org wrote: Are you familiar with C++ templates? One could define, and some compiler vendor libraries define, functions which work as you describe. -- Sent from my mobile phone. Please excuse my brevity. Charles John Gilmore jwgli...@gmail.com wrote: I am familiar with the inline option. What it does is not what I had in mind. I should have been more specific. I meant independent C implementations. IBM C and IBM PL/I share the same optimizing and code-generation machinery. A [simple] mathematical example will make the appropriate distinctions clearer. Consider declare i signed binary fixed(63,0), ((x, y) real, z complex) decimal float(16), abs builtin ; . . . i = abs(i) ; /* example 1 */ x = abs(x) ; /* example 2 */ y = abs(z) ; /* example 3 */ Example 1 and example 2 are always evaluated by trivial compiled code. They reduce conceptually to a single machine instruction. Example 3 is instead evaluated by a library subroutine. Why? Recall that for complex z = a + bi, abs(z) = sqrt(a**2 + b**2). Here, as usual, generic functions employing syntactically identical constructs are evaluated in datatype- and domain-specific ways. (All this is of course irrelevant for FORTRAN-like C, which does not have generic functions.) 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
