editting testing COBOL code
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of McKown, John Sent: Tuesday, December 01, 2009 9:20 AM To: IBM-MAIN@bama.ua.edu Subject: editting testing COBOL code (was:Now is time for banks to replace core system according to Accenture) much snippage I have been playing around with Eclipse myself lately (for java, not COBOL), but the sticking point for COBOL under RDz or any other workstation-based technology is whether or not there is a workstation-based COBOL compiler available. For RDz, the answer is NO, they only have eclipse-based syntax editing available. MORESNIPPAGE You have something set up VERY strangely if you think RDz doesn't come with a full blown COBOL compiler. It does, and although it isn't there primary target, IBM fully documents that RDz (and its IBM COBOL for Windows component CAN be used to develop Workstation applications. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
Clark Morris cfmpub...@ns.sympatico.ca wrote in message news:mq7tc51ajbefs2n1tc5e769m2gb2aep...@4ax.com... On 8 Oct 2009 14:08:24 -0700, in bit.listserv.ibm-main you wrote: snip It could be done much snippage For those in IBM-MAIN who don't follow such things. Clark has had long running desires of how it would like to see IBM COBOL development prioritize things. When voted upon by SHARE (LNGC project) members, many of the things that Clark wants are things that current IBM customers also want. HOWEVER, in most cases, those enhancements that IBM has delivered in recent releases and versions of Enterprise COBOL have received HIGHER priorities from customers (in and out of SHARE) that those things that Clark has asked for. I suspect that many (Possibly even most) existing IBM COBOL customers would like it if IBM COBOL development had unlimited resources for enhancements - ASSUMING that the cost of COBOL to their shops did not increase and that all future COBOL environments were %100 per cent upwardly (and downwardly) compatible. This isn't true and is unlike to ever be true. Therefore, similar to other specific IBM-MAIN participants who hate such things as LE, his repeated posts ranting bout specific issues (such as 64-bit COBOL and *non* decimal IEEE floating point) provide little service. OBVIOUSLY, if any other IBM-MAIN participant belongs to SHARE and wants to see some new/different enhancement request for Enterprise COBOL processed, I would encourage you to use the SHARE requirement process and/or marketing REQUEST procedures. I can certainly help you with the SHARE requirement process if you are interested in such. If you are interested in specific things that have already been voted upon by LNGC (such as 64-bit COBOL and/or IEEE binary Floating-Point), then I would be more than happy to provide you with information on the existing requirements and you submit a marketing REQUEST that references them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
When it comes specifically to 64-bit COBOL, the biggest issue (IMHO) is mixing of 31-(and/or 24-)bit COBOL with 64-bit COBOL. It is my impression (and I do NOT speak for IBM) that IBM is aware of the desire for 64-bit COBOL, but that (given the LE, not z/OS restriction on mixed 31-/64-bit) code, that they are looking at a foreseeable but not immediate 64-bit COBOL that will work A) in a 64-bit only environment (and maybe) B) will have some mechanism (NOT traditional COBOL run-unit and CALL statements) for communicating between 31-bit and 64-bit COBOL programs. My personal guess is that either or both of these will be nice to have but will get very little actual user-community use. COBOL shops (and applications) are just too used to transparent inter program communication. However, when/if such are available, it may (or may not) give IBM additional information on how to proceed from there and actually meet paying customer demands and expectations. When there was a recent SHARE LNGC vote on IBM providing such a solution (even if it were a transition step to a future more mixed environment), the LNGC project gave this sufficiently LOW priority that the requirement never even got sent to IBM. If any shop (with readers in IBM-MAIN) thinks that such a 64-bit COBOL product *would* meet their needs, please feel free to contact me off-list and I can give you the rejected by user requirement information so that you can submit it as a marketing REQUEST. NOTE: If your shop is interested in IBM providing a 64-bit COBOL solution with an explicit statement of direction (or actual implementation) of mixed 31-/64-bit COBOL programs in a single run-unit, then you can also contact me off-list and I will provide you information on that requirement and you can do a marketing REQUEST for that too. I wouldn't be very optimistic about how IBM would respond, but it can still be communicated to them. Timothy Sipples timothy.sipp...@us.ibm.com wrote in message news:of79a78257.faa461e9-on4925764a.001ddf83-4925764a.001f5...@us.ibm.com. .. This COBOL discussion feels like deja vu. :-) As a reminder, I am not speaking for IBM. There have been and are lots of discussions about future COBOL innovations, both within IBM and with our customers. One of the big ones is how (and consequently when) to get to 64-bit. I have my own (strong) views on that question, which I express as often as I can. (And I know I'm right. :-)) But, in all seriousness, there is a rather complex set of factors that have to be considered on how, and ultimately the relevant voices are customers'. They decide the right answer. So, I'll say it again: tell IBM what you want and how you want it -- and what you value most. In particular, there is a tension between innovation and potential risk. Do you want zero or near-zero risk? Well, then, maybe IBM shouldn't be so aggressive in innovating. (I'm oversimplifying, but that's the idea.) Said another way, COBOL (and PL/I) really do run the mission-critical world, while some of these other languages don't. :-) Now, I happen to think my recommended approach perfectly combines maximum innovation with zero or near-zero risk. (I have a have your cake and eat it too idea.) But I don't get to decide these things. You do, subject to the technical constraints of course. So please speak up, through the proper channels. Much appreciated. Thanks. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
Lots of good performance improvement comments snipped One more time, Have you created either a SHARE requirement or a marketing REQUEST for any of the specific compiler changes to get performance improvements in Enterprise COBOL (specifically those using higher ALS instructions)? If not, why not? I suppose you might think that IBM should constantly be looking at the generated object code from the compiler looking for performance improvements. Again, this might be nice, but it is highly unlikely to happen. If, on the other hand, you have specific suggestions and you submit them to IBM via any of the numerous ways of making such suggestions, then they MIGHT get into the development stream. Especially, when you include wording (like that snipped) that included, this might be worth paying for a version upgrade P.S. Just because it was in part of the snipped notes, IBM has given a positive response to the SHARE requirement for adding DFP support to COBOL. They have, however, rejected adding BFP support. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
I am a COBOL person not an Assembler person. Don't the grande instructions require a specific architecture level set? If so, that might be why (as others in the thread have indicated), COBOL does NOT do what you are asking about. It would seem a reasonable SHARE requirement for something like - when using *ALL* COMP-5 sending and receiving fields, (and possibly also when using all binary fields with TRUNC(OPT)) then binary, not packed-decimal arithmetic should be used. When such arithmetic is using large binary fields, then grande instructions should be used. This assumes, however, that this would actually provide a demonstrable advantage to IBM COBOL customers. Farley, Peter x23353 peter.far...@broadridge.com wrote in message news:053f2631ec9c584883847c8b4970a228050da...@josqems1.jsq.bsg.ad.adp.com. .. I did not see anything about it in the updates page in the language reference nor the programmer's guide, but I'm wondering if anyone here knows if the newest release of the Enterprise COBOL compiler will generate grande arithmetic instructions for COBOL binary fields (e.g. will it generate an AG or AGR instruction for adding two PIC S9(18) BINARY fields?). TIA for any info you can provide. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
COBDFSYM With COBOL 410 - ((attn Frank Yeager??))
USER BEWARE I have NOT tried it, but the thing that I expect WILL impact COBDFSYM is the fact that Enterprise COBOL V4R2 (not V4R1) *DOES* allow for underscores in user-defined words - even as the last character of the user-defined word. Consider (in particular) a (valid in Enterprise COBOL V4R2) 01-level of 01 Group1. 05 A-B Pic X. 05 A_B Pic 9. 05 XYZ_ Pic 99 Comp-5 I have NOT tried it, but I do think that COBDFSYM may well have problems with such a record layout. NOTE: I have already sent in an RCF that the Enterprise COBOL V4R2 Migration Guide (and/or programming guide) needs more (ANY!!!) information on use of the underscore and its inter-action with other software. Andy Robertson andy_robert...@johnlewis.co.uk wrote in message news:ofec1d40c0.48c86a44-on80257635.00570fcb-80257635.00570...@johnlewis.co .uk... We are trying to use COBDFSYM to convert COBOL copybooks to SYMPARMS input for ICETOOL COBDFSYM is in the dfsort tricks pdf at http://www-01.ibm.com/support/docview.wss?uid=isg3T794 The copybook is compiled and the output analysed by COBDFSYM to create SYMPARMS input With COBOL 410 input we seem to be getting fields in the listing which have new offsets the current COBDFSYM cannot handle eg: 89 *-* parse pull line LineID PL SL +-*A-1-B--+2+3+4+- ference 90 *-* end 88 *-* do until substr(line,2,16) = ' LineID PL SL ' V LineID PL SL +-*A-1-B--+2+3+4+-- erence L2 L16 F LineID PL SL L LineID PL SL O0 89 *-* parse pull line 0 01 IDENTIFICATION DIVISION. 90 *-* end 88 *-* do until substr(line,2,16) = ' LineID PL SL ' V0 01 IDENTIFICATION DIVISION. L2 L16 F 01 L LineID PL SL O0 89 *-* parse pull line I'm quite happy to plunge in and start debugging, but Id like to ask first if there is a version adapted for 410 available already Andy Robertson ** This email is confidential and may contain copyright material of the John Lewis Partnership. If you are not the intended recipient, please notify us immediately and delete all copies of this message. (Please note that it is your responsibility to scan this message for viruses). Email to and from the John Lewis Partnership is automatically monitored for operational and lawful business reasons. ** John Lewis plc Registered in England 233462 Registered office 171 Victoria Street London SW1E 5NN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
RCF - SC23-8528-01 - Enterprise COBOL V4R2 LRM
(RCF - to IBM, CC to IBM-MAIN) Title: Enterprise COBOL for z/OS V4.2 Language Reference Document Number: SC23-8528-01 Build Date: 08/21/09 08:10:20 At: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3lr50/6.1.8.9.1 It states, for a file status of 97 in the column Meaning For VSAM only: OPEN statement execution successful: File integrity verified That text makes Enterprise COBOL NON-conforming to the current (and past) ANSI/ISO Standard. It was my understanding (and historically, I thought that this was documented), that the IBM position on file status 97 was a meaning of: For VSAM only: OPEN statement unsuccessful but execution continues as if it were successful: File integrity verified HOWEVER, even with this documentation change, it should be confirmed that when a file status of 97 is set to exist, if a DECLARATIVE for the file exists, that execution does transfer to that declarative. If execution (after *ANY* 9x file status is set) does not go to a relevant declarative, then the compiler/run-time is in violation (as I understand it) of the current and past ANSI/ISO Standards. The Standard explicitly allows the vendor to do whatever they want after any unsuccessful file status (9x or otherwise) *IF* no declarative exists. However, when a declarative exists and ANY unsuccessful file status is set to exist, that declarative must be reached. See (for example) page IX-40 of the '85 ANSI (or ISO) Standard which states, in part (for indexed files) in General Rule 5, The procedures associated with a USE statement are executed by the input-output control sys tern after completion of the standard input-output exception routine upon the unsuccessful execution of an input-output operation unless an AT END or INVALID KEY phrase takes precedence. Assuming that Enterprise COBOL *does* reach the relevant Declarative when a file status of 97 is set to exist, then it is fully conforming as I understand it (even if misleading in the current documentation). If the appropriate declarative is NOT reached, then a conformance issue exists and should be fixed or documented in the LPS and PG where other restrictions on ANSI/ISO conformance are documented. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
file integrity verified - do I care?
previous comments in this thread snipped For any (all) of you who dislike the file status 97 - especially anyone involved in a VSE to MVS conversion (where this seems to be a medium-high priority problem), please consider submitting a Marketing Request to IBM and reference the existing SHARE requirement: SSLNGC0413615 Optional (ISO 2002) 0x file-status code for current 97 (current status of this requirement is RECOGNIZED) That requirement asks for an enhancement that could be selected by compiler or run-time option to automatically turn a 97 into a 0x file status. (Obviously, run-time would have the advantage of no recompile required while compile-time would have the advantage of NOT impacting existing programs - without an explicit selection of the feature). * * * To respond to one part of this thread, YES, the Standard (all past and present one) DOES explicitly state that an implementor defined 9x file status *MUST* be considered unsuccessful. The way that IBM gets away with what they do on a 97, is that the standard does NOT define what must happen on an unsuccessful I/O - when no declarative or file status checking is done. * * * * As always, doing a marketing requirement does NOT guaranteed to do anything more than the existing SHARE requirement does. However, it does tell IBM that this is really impacting existing customers and lets IBM judge how serious the impact it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Enterprise Cobol 4.2
For those who want a PDF version of the Announcement see: http://www-01.ibm.com/common/ssi/rep_ca/4/897/ENUS209-244/ENUS209-244.PDF Of possible special interest to some sites, you may want to notice that there is NO drop date for support for V3.4 (V3.3 and earlier already have support dropped). Having said that, I would certainly start looking at upgrading to a V4.x release of Enterprise COBOL - sooner than later. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Binder API...broke or working as designed
*JUST* on the issue of the Binder API requiring the LE run-time, I have a question for you (WB) Were your discussions with STL done before or after Metal-C became available? It would seem to me (and I certainly could be ENTIRELY wrong on this), that a SHARE requirement to provide a Metal-C (no LE library required) version of the Binder API *might* receive a positive IBM response NOW. While asking for a no LE version of the Binder API *before* Metal-C was available received a negative response. As I have said before, I just don't see the harm in creating a SHARE requirement for this (or any other Binder enhancement). Occassionally (not all that often) IBM does provide solutions for SHARE requirements where similar individual site marketting requests get rejected. William H. Blair wmhbl...@comcast.net wrote in message news:hdemimhlcnkiedehaemeaegaadac.wmhbl...@comcast.net... Paul Gilmartin asks: In what language is the binder written? As far as I know, PL/X. But the binder itself is not actually the problem. It's the C/C++ / LE-dependent routines that the binder [API] invokes; they are the cause of the entanglements that the binder [API] suffers from, apparently. At least that is IBM's explanation. We just took them at their word on this. Note that these routines are involved even if one doesn't have a line of C/C++ code. The binder uses (what they call) C/C++ functions to perform some of _its_ functions. Very entangled. Very surprising (to us, and some other customers as well). I have no interest in a semantic discussion. If the binder API requires LE, then does the binder require LE? For the purposes of our (then-intended) application, the answer was in fact yes. But you can argue the point if you wish. The problem for us was that we could not invoke the binder API as we assumed we would be able to, and the reason had to do with restrictions that originate in LE. For our application, that was a pretty clear-cut issue ... You can't do that. Why not? It's not our fault. It's an LE restriction. And, if anyone is going to document it, then it should be LE, not us [the binder]. But you don't document anywhere that you use LE, so how would we know that, prior to invoking the binder API, we should look up all these LE restrictions? OK, we'll document that you can't invoke the binder in that manner. And they did. And so, that ETR was closed with WAD: not a binder problem. I would have imagined PL/S. And I would have imagined that PL/S didn't require LE. You are so right. So ... IF the binder [API] DID require LE, YOU would be astonished ... right? Well, we were. Why do you so strongly advocate Assemble as opposed to, say, PL/S or Metal C, which ought not to require LE? I consider PL/X equivalent to Assembler for the issues that are under discussion (there's no runtime involved). Besides, I didn't strongly advocate Assembler. I just suggested it as one implementation approach that, if adhered to, would [obviously, like other things] avoid any LE entanglements. I think you're reading far too much into what I have said. The binder suffers from LE restrictions. That surprised us, and I think it violates the principle of least astonishment. There are other ways in which the binder [API] violates the principle of least astonishment. The scuttlebutt from some IBM contact at SHARE is that Well, this might be a bug. OK, so what? It's worked that way since PM2 (at least), so if it's a bug, then it's an old, old bug. But my point was that it obviously astonished Dave Day, just as it astonished us, and I attempted to inform him that other astonishments could be around the corner -- that's the way the binder is. I never said that it was not a bug (in fact, I don't know), or that it should not be APARed, or that a SHARE requirement should not be written to address it. I just said that it was astonishing, like so much else (like nearly everything else we tried) with the binder [API]. That's all. But I did say it was BAD (broken as designed). In our world, IBM does not always consider that to be a bug to be fixed. -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Fw: Binder API...broke or working as designed
Chris Craddock crashlu...@gmail.com wrote in message news:b0c6f15b0908212236g510fd9cbq661ae41f9627e...@mail.gmail.com... On Fri, Aug 21, 2009 at 11:29 PM, Bill Klein wmkl...@ix.netcom.com wrote: snip Bill K... this is a can of worms best left unopened. Suffice to say Bill Blair's commentary is not actually a rant at all, but is based entirely on his own (and my own) direct personal experience with said component. He does not need any help composing a SHARE requirement and in any case, as he indicated obliquely the chances of such a requirement being delivered within the expected lifetime of the universe is pretty slim. I have promised my friends in IBM that I won't keep picking on the binder in public every time the subject comes up, so I will just bite my tongue. You might want to as well. I am sorry that your experience has been so bad. However, I will keep harping on the fact that IBM has indicated that they will process binder requirements in the ASM project of SHARE. As I say, I certainly can't guarantee what will be accepted and when such will be implemented, but I *do* repeat that unless/until the SHARE requirement process is tried for such things, it seems wrong to me to assume that it will NEVER work. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Binder API...broke or working as designed
I know that ranting on IBM-MAIN is always a good way to spend your time, but Are you aware that the ASM project at SHARE accepts and processes requirements against the Binder? If anyone who participates in SHARE needs assistance in creating a binder requirement, please feel free to contact me off-list. Obviously, I can't say that IBM will respond as you want them to but it does have a SLIGHTLY better chance than ranting on IBM-MAIN - in getting the desired fix to the binder. William H. Blair wmhbl...@comcast.net wrote in message news:hdemimhlcnkiedehaemecelpacac.wmhbl...@comcast.net... Dave Day expressed his genuine surprise (how novel!) regarding the behavior of the Binder API, thusly: I did not expect these entries to be in the buffer in non ascending order. I'll change my code to check and place them in the internal map in correct order, but this sure seems broke to me. I will add your name to my list of folks who, quite irrationally, insist on thinking rationally. Welcome to the club. Miss Manners (should she ever understand computer science) would surely chide you regarding this faux pas. But while others might admire you for your persistence, I will just politely suggest that you never do it again (at least in public, that is). The Binder API is without exception the most blatant violator of the principle of least astonishment that has ever been implemented in any piece of software by any software company or by any programmer on Earth. Even after reading its obtuse documentation, this so- called API failed at literally EVERYTHING I expected it to be able to do. These issues were appropriately (if incredibly) noted by various IBMers but the only thing that was ever done was (if anything) to update the documentation to say Oh! But you can't do this! Like many frail facilities offered proudly by IBM as the answer to all of our stated requirements, this one just does what it does and no more. Any thought that it might actually be straightforward or simple to use is inconsistent with reality. You didn't really expect the binder to sort the entries presented prior to returning them to you, did you? How presumptuous. So yes, it's BAD broke -- broken as designed (BAD). My condolences. -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: z10 and overlapping/destructive moves
Out of curiosity, were you compiling with the OPT compiler option? If not, does changing to that generate the same instructions? Farley, Peter x23353 peter.far...@broadridge.com wrote in message news:053f2631ec9c584883847c8b4970a22804998...@josqems1.jsq.bsg.ad.adp.com. .. I am in the midst of a CPU optimization exercise for a COBOL program and ran across the following code sequence generated by the compiler: MVI 254(3),X'40' MVC 255(119,3),254(3) This code is generated in response to a simple COBOL MOVE SPACES TO variable instruction, where the variable is 120 bytes long. Did I or did I not see some discussion here or perhaps in a SHARE presentation that on a z10 machine overlapping/destructive moves wreck the pipeline and take *much* longer to execute as a result? Or am I imagining that? The reason I ask is that Strobe highlights this place in the code as a high-usage point, and I am struggling to understand why. TIA for any info you can provide. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: IMS and POSIX(ON)
Did you see, http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea3190/2.2.5.69 .1 which says (in part), z/OS UNIX considerations--IMS supports only applications that use the POSIX(ON) run-time option from a single thread. You don't say, but I *assume* you are not running under USS. In which case, the statement at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea3190/1.2.44.1 that says, You can specify POSIX(ON) for both DB2R and IMS applications. probably prevails. P S zosw...@gmail.com wrote in message news:67954f200907240856p5abee351ub4149455c4545...@mail.gmail.com... In reading various LE and IMS documentation, I've come to the [conc][de]lusion that invoking a set of C functions that require POSIX(ON) won't be that hard under IMS (as opposed to, say, CICS, where it basically doesn't work without a lot of undocumented environmental setup). Anyone done this? Any surprises/gotchas you can share? I see that specifying the POSIX(ON) is different for IMS, but that's documented. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
LE options
Frank, As others have pointed out, there are still other ways to do set LE options. One difference between the old ways (e.g. CEEDCOPT) and the new ways (PARMLIB) is that the old ways allowed for fixed options, i.e. system defaults that could NOT be overridden by the programmer or later methods of setting options. For some people, this is/was a good thing and for others it was not. Certainly the IBM direction (as seen with more recent options) is AWAY from fixed options. OBVIOUSLY, get used to how the RPTOPTS shows options in effect and where they were/are sent. See, for example http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea1190/1.1.2.1 Frank Swarbrick frank.swarbr...@efirstbank.com wrote in message news:4a6097e6.6f0f.008...@efirstbank.com... There appears to be (at least) two ways to change LE runtime options system wide. There's the assember macro table way (CEEDOPT for batch and CEECOPT for CICS) and there's the PARMLIB(CEEPRM00) way. Is one preferred over the other? Does one offer something the other does not? I am thinking that the PARMLIB way allows for multiple systems to share the same LE libraries and still have different LE options, if desired. Is this the reason for is its existence? If we use the PARMLIB way is there anything that has to be done with the macros and can't be done with the PARMLIB? Honestly, there are so many ways to change LE options that it's hard to keep them all straight! Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation Lakewood, CO USA P: 303-235-1403 F: 303-235-2075 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
EZASOKET (was: Odd Behavior in PL/I Assignment Statement
I am just replying to change the subject of this thread. I may be mistaken, but I don't think this part has anything to do with assignments in PL/I - but that someone just replied rather than starting a new thread. Williams, Pereto pereto.willi...@firstdata.com wrote in message news:1add33e3f502164c8e76ce0019939de102b86...@wmerhapxmasrv02.1dc.com... Sorry I did not.. I called it from a Cobol module Thank You Pereto F. Williams Integrated Dispute Systems (IDS) First Data Commercial Services O (954) 845-4723 M (954) 464-4852 F (954) 845-4400 firstdata.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Schwarz, Barry A Sent: Friday, July 10, 2009 5:47 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Odd Behavior in PL/I Assignment Statement Did you actually code a call to EZASOKET in PL/I? If so, you need to show us the code. -Original Message- From: Williams, Pereto Sent: Friday, July 10, 2009 1:11 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Odd Behavior in PL/I Assignment Statement Need assistance to resolve EZASOKET failure with ERRNO 54 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Question about REUS=NONE
Others may have given you most of the answers that you want, but you should check out: Handling COBOL limitations with multithreading at: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/4.4.6 and THREAD at http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/2.4.54 and Comparison of WORKING-STORAGE and LOCAL-STORAGE at http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/1.1.3.2 and Sharing data in recursive or multithreaded programs at http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/1.1.3.3.3 * * * * * * In general, I think that when you convert (upgrade) to Enterprise COBOL, you will find that (as long as you keep using an Assembler driver to start the threads), that you can have supported COBOL applications that do what you want. Michael Knigge michael.kni...@set-software.de wrote in message news:4a531f8e.6060...@set-software.de... All, once upon the time, we had to write an application (in VS COBOL II) that uses subtasks. Because this old COBOL release did not support subtasks, we did a trick: We've attached from an ASM driver a little ASM stub that did just one thing: call the wanted COBOL prog. We had to link all COBOL-Modules statically to get all this stuff working. The COBOL progs are also using some ASM Subs for some special things (i. e. doing a GETMAIN, FREEMAIN, STIMERM and so on). They are also statically linked. So the initial ATTACH attaches a really big thing... Now we are just about 13 years later and I have to convert this application. We want to use Enterprise COBOL and dynamic CALLs. Now. I guess all the COBOL-Stuff will work pretty well (I guess that the WOKING-STORAGE gets getmained for every new copy of the COBOL-Prog within each subtask). But I wonder how to migrate the ASM-Subs nearly painless I could rewrite all this ASM-Subs and use dynamic Saveareas but I wonder if just using REUS=NONE would do the same job... So bring it to a question: What is the scope of the REUS-Option? (Sub)Task-Level? Then using REUS=NONE would bring up a new copy of the ASM-Stubs for every Subtask - just what I need I don't care for the wasted memory because the ASM-Subs are mostly rather small (and well, today they are all statically linked together with some really big COBOL-Subs) Thank you for hints Bye, Michael -- Mit freundlichen Grüßen Michael Knigge Entwicklung S.E.T. Software GmbH Lister Straße 15 30163 Hannover Tel. +49 511/3 97 80-23 Fax +49 511/3 97 80-65 michael.kni...@set-software.de Handelsregister: HRB52778 Amtsgericht Hannover Geschäftsführer: Till Dammermann, Klaus Stöhr -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: COBOL: Getting calling modules name etc. - LE services ?
I think that the facility that you are looking for would be met when/if IBM actually provides the enhancement in the existing SHARE requirement: SSLNGC0313587 New LE Callable Service to get (various) Program Names Described as: A new LE callable service (with capabilities well beyond CEE3GRN) should be created to obtain various program names. This should include options to obtain: - The currently executing program's name - The name of the program that activated (Called, Invoked, whatever) the currently executing program - The name of the program at the top of the current LE enclave - The name of the program at the top of the current LE thread For each of these, sub-options may be required to provide information such as - Any alias by with the program was entered - Any long-name (with mixed characters) as supported by the Binder - Any Entry-point name when other than the modules name Finally, although not necessarily a part of this callable service, it would also be desirable to be able to obtain the data set name (HFS, PDS, PDSE, LPA member, or whatever) from which each of these entities was obtained. * * * * The current IBM response is RECOGNIZE. You may want to submit a marketing REQUEST and reference this SHARE requirement. Thomas Berg thomas.b...@swedbank.se wrote in message news:e46b4df55a5e8746855078ae31f1b1802db71f3...@fspas01ev010.fspa.myntet.se ... Hi, Does anyone know a way to get the actual calling modules name in a COBOL program ? Also other details about the calling module would be interesting. I looked through LE Programming Reference for callable services buth didn't find any (obvious) such function. Any hints ? Regards, Thomas Berg __ Thomas Berg Specialist IT-U SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Enterprise COBOL for z/OS V4
Not just for Enterprise COBOL, but for all languages that use an LE run-time, it is now and has been for as long as I can remember CRITICAL that the run-time on all systems be at the highest level *before* you start rolling out object code created by higher-level compilers. This goes all the way back to the old PL/I RESIDENT (or was it TRANSIENT) library. If this means that you keep the old compiler - even in your development systems UNTIL LE is upgraded on all production systems, then this is what I would recommend (and I think IBM does). The old RTLS support *tried* to provide a solution for this, but having up-level LE on all production systems is simply the way to go before beginning compiler upgrades. Skip Robinson jo.skip.robin...@sce.com wrote in message news:ofb655e56a.1ceab469-on882575df.f3c8-882575df.00019...@sce.com... In the course of rolling out new level of z/OS, there can be a (perhaps extended) period where Dev(elopment) runs at the new higher level even while Prod(uction) continues at the old lower level until it catches up. I'm a little concerned about this transition phase in which application folks implicitly use the new compiler but 'move' load modules to the old LE environment. I think this migration path is pretty common for most shops. And chances are that the Apps people don't even realize the difference in environments. . . 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 Tom Ross tmr...@stlvm20.v NET.IBM.COM To Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List ibm-m...@bama.ua Subject .edu Re: Enterprise COBOL for z/OS V4 06/23/2009 02:22 PM Please respond to IBM Mainframe Discussion List ibm-m...@bama.ua .edu 1) XMLPARSE(XMLSS) is not compatible with XMLSS(COMPAT), as described in the COBOL Migration GUide. They are 2 completely different parsers! The changes are minor, but must be looked at when migrating from XMLPARSE(COMPAT) to XMLPARSE(XMLSS). Cheers, TomR COBOL is the Language of the Future! Hi Tom, We currently have Enterprise Cobol for z/OS V4 and z/OS V1R10 on our test systems. Will there be any problems at run time for programs using XML and compiled with XMLPARSE(XMLSS) when they are run on our production systems which are z/os V1R9 ? Sorry for the late answer, was on vacation until yesterday... Ent COBOL V4.1 code can run on z/OS R7 and above, so as long as you have the PTFs required for COBOL V4.1 on the R9 system, and any PTFs needed for XMLSS, you should be OK. (Note: the required LE updates for 4.1 are in the base for z/OS R10) We have discovered that many customers install the LE PTFs required for new compilers in only one system, instead of on all systems where COBOL programs might run. Since the compiler is separate frmo the run-time library, all new releases of COBOL will require PTFs for LE, and on all systems where COBOL would run. (Same for PL/I) If all of your sustems have the PTFs you are good to go! Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Language Environment runtime options and system dumps
I would check with any vendor as to whether this is still true (that they can't handle LE dumps). Current software should work with LE and should not need non-normal dumps. If your vendor requires something else, then ask THEM what LE options they expect to be in effect when the dump in THEIR product occurs. If they can't tell you, then I would refer them to one of the IBM 'vendor support teams. In this day and age, vendors who don't understand LE are (thankfully) few and far between. I won't say they don't exist, but I think they are the exception and not the rule. For those who are have a problem with LE, I suggest that you consider this in your next contract renewal with that vendor. Steven Conway steven_con...@freddiemac.com wrote in message news:ofb34441e3.b9f4c6b1-on852575d6.00453223-852575d6.00454...@freddiemac.c om... Bill Klein says: sometimes, using the user friendly debugging tools at hand can make the need for a system dump of the original abend unnecessary. Tell that to vendor support teams. . . Cheers,,,Steve Steve Conway Lead Systems Programmer Information Systems Services Division Computer Network Operations Phone: (703) 450-3156 Fax:(703) 450-3197 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Language Environment runtime options and system dumps
Jim, Has anyone asked (yet) WHY you want this? I know that in IBM-MAIN, historically people (often systems programmers) don't like debugging tools that get in the way of original dump information. However, depending on what is causing the S0C4, it is possible that more - not less - LE assistance might be the answer. For COBOL only applications, for example, using SSRANGE (compile and run-time) often finds the cause of S0C4 ABENDs and does so in a manner that the application programmer can find the cause quickly and easily. Of course, if this is NOT a COBOL application - or you can't recompile (if the program was originally compiled with NOSSR) then this particular aid won't help. My point is simply that sometimes, using the user friendly debugging tools at hand can make the need for a system dump of the original abend unnecessary. Jim McAlpine jim.mcalp...@gmail.com wrote in message news:21d1f8c20906120723s12d0fc19v19493cbc3d786...@mail.gmail.com... Is there any combination of LE runtime options that will give a system dump of the original abend and an LE message. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Language Environment runtime options and system dumps
Also, if you use any variation of TRAP(OFF), don't expect COBOL programs to always confirm to the documented behavior - when unusual things happen. Don Poitras sas...@sas.com wrote in message news:4a32a3dd.5...@sas.com... Ramiro Camposagrado wrote: On Fri, 12 Jun 2009 15:23:39 +0100, Jim McAlpine jim.mcalp...@gmail.com wrote: Is there any combination of LE runtime options that will give a system dump of the original abend and an LE message. Jim McAlpine Using TRAP(OFF,NOSPIE) should give you the original ABEND. I;m not so sure about the LE messages though. If you turn off the LE ESTAE, then you're not going to get the happy LE traceback and messages. But in most cases, the dump still contains the original abend info. Just don't use IP SUMM FORMAT to get the info. Instead, use IP VERBX LEDATA 'CM' (without the double quotes.) This gives you PSW and regs at the time of original ABEND. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Wait under CICS
ILBOWAT0 should not be used under CICS (but unfortunately will work - if LE is in the LPA). HOWEVER, CEE3DLY is available. See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA3190/2.2.5.5. 1 Edward Jaffe edja...@phoenixsoftware.com wrote in message news:4a2bb7f4.3040...@phoenixsoftware.com... Andy Robertson wrote: [snip] ILBOWAT0 and BPX1SLP are AFAIK not useable under CICS, nor are things like STIMER WAIT If a CICS PROGRAM entry specifies OPENAPI, indicating the program is threadsafe, then implied WAITs should have no ill effects. It's only code that runs on the old, single QR (Quasi-Rent) TCB that can't safely WAIT. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IMS..IMS..Gotta love IMS. Why is my PCB failing?
When you are running this with BTS, are you ALSO using an interactive
language-specific debugger, e.g. Xpediter, Debug-Tool, or similar. (They all
have ways of running with BTS). If so, then I would trace when/how those
fields are getting correctly filled in under BTS in the program logic - and
figure out why the code is NOT getting to that place online.
Without knowing a WHOLE LOT MORE, my first guess is that your application is
not checking for a bad status on a preceding call to DL/I and that you are
assuming some of the PCB fields are already filled in (which they are when
things go well) but that are not filled in when something previously failed.
However, that is just a guess.
As I say, stepping thru the source code and monitoring or watching those
fields under BTS, should get you started on where the logic problem is.
David Logan loga3...@comcast.net wrote in message
news:035801c9dec0$8089a040$819ce0...@net...
I have yet another mystifying situation. When I run my transaction online,
I
get a U0476. When I run it under BTS, is happily blows right by the same
code (crashes later, but Ill work on that later.)
It crashes on this:
CALL CEETDLI USING GHU - and yes, I have tried CBLTDLI, no
difference
G1CPCOM-PCB
TYPE-SEG-LTQA
LTERM-QSSA
TYPE-SSA
Under online IMS, my PCB looks like this. This is the one that fails:
3 PAÍQUEUESEGDJLOGAN 2.70COMMDBPX
4F44DC444075DECECECC44414440CDDDCCD4F4FFCDDDCCDE444044
030071000150845452570003413671502B7036444277000F00
Under BTS, the above call works, and my PCB looks like this:
G1CPCOM 03 PA {QUEUESEGIOPCB 2.70COMM u
CFCDCDD4FF44DC44000CDECECECC0001CDDCC444F4FFCDDD000A00
71373640030071000F60845452570003967320002B7036440F940F
It appears that there are various fields that have EBCDIC spaces that
shouldn't in the online PCB. So I spent a lot of time reviewing the LANG=
on
the PSBGEN at the recommendation of the messages manual. But, as it turns
out, LANG=, LANG=ASSEM and LANG=COBOL all generate the same PCB value, so
that's not it.
So what is it? Where do I need to be looking?
Thanks!
David Logan
(p.s. Perhaps somebody also knows how to reload a program in IMS after a
relink without cycling IMS. In CICS, you can issue a NEWCOPY. What do I
need to do in IMS to use a new load module?)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Enterprise COBOL for z/OS V4
Abso-tutely G Check out http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/IGY3PG40/2.4.58 and http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/5.1 John McKown joa...@swbell.net wrote in message news:listserv%200905220933575322.0...@bama.ua.edu... On Fri, 22 May 2009 08:23:32 -0600, Steve Comstock st...@trainersfriend.com wrote: snip Main benefits: snip * XML processing has improved functionality (namespaces, attributes, encoding, parse on record basis instead of document basis) Doesn't it now, optionally, use the System XML in z/OS. Which means that it could do its XML processing on a zAAP (or is it zIIP?) instead of a CP? Cons: Well, the compiler option SIVMRD is no longer supported (simulate variable length RRDSs using KSDSs, or something like that) Which should be no big deal since VSAM not implements the VRRDS natively. Kind regards, -Steve Comstock -- John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Enterprise COBOL for z/OS V4
Especially for those using either the CICS or DB2 integrated coprocessor, using SIZE(MAX) is a *bad* idea. Making it a non-modifiable compiler option is a REALLY bad idea. See: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3cg40/2.53 and http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/2.4.46 IBM's recommendation seems to be SIZE(4000K). If that causes problems, then increase it but do NOT use (MAX) - at least for CICS or DB2 programs. Jousma, David david.jou...@53.com wrote in message news:a90766b5039c59409110c92d47216f590...@s1flokydce2k322.dm0001.info53 .com... In my defaults, SIZE(*MAX) is coded, which means you cannot override it. If you are coding it in your run JCL, that may be why. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Schumacher, Otto Sent: Friday, May 22, 2009 1:55 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Enterprise COBOL for z/OS V4 I am getting the option SIZE(MAX) flagged. The error is only a warning does anyone know what the option should be set to? Regards Otto Schumacher Technical Support, CICS EDS, an HP Company Ahold Account 2000 Wade Hampton Blvd. LC1-302 Greenville, South Carolina, 29615 Tel: 864 987-1417 Fax: 864 987-4500 E-mail: otto.schumac...@eds.com We deliver on our commitments so you can deliver on yours. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jousma, David Sent: Friday, May 22, 2009 1:48 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Enterprise COBOL for z/OS V4 XMLSS actually broke one of our application's programs. They had to re-compile to change it to COMPAT for that program to make the application work properly. Also, in COBOL 3.4, we used to specify TEST=(NONE,NOSYM). There is no equivalent in 4.1 other than to specify TEST=NO. Anything else, you get the full debug symbol table buried in your load module, bloating it severely. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Steve Comstock Sent: Friday, May 22, 2009 10:24 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Enterprise COBOL for z/OS V4 John P Kalinich wrote: What are the pros and cons of going to the new version of Enterprise COBOL? Regards, John K Main benefits: * compiler options can now be in a file instead of in JCL or PROCESS statements (or in addition to) * XML processing has improved functionality (namespaces, attributes, encoding, parse on record basis instead of document basis) Cons: Well, the compiler option SIVMRD is no longer supported (simulate variable length RRDSs using KSDSs, or something like that) Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.html== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive
Enterprise COBOL for z/OS V4
For a discussion of the simplified TEST compiler option with Enterprise COBOL V4.1, see: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3mg40/5.5.5 Steve Comstock st...@trainersfriend.com wrote in message news:4a16ea01.5010...@trainersfriend.com... Jousma, David wrote: XMLSS actually broke one of our application's programs. They had to re-compile to change it to COMPAT for that program to make the application work properly. Also, in COBOL 3.4, we used to specify TEST=(NONE,NOSYM). There is no equivalent in 4.1 other than to specify TEST=NO. Anything else, you get the full debug symbol table buried in your load module, bloating it severely. Hmmm. The XML problem / bug should be reported if you haven't already. As far as TEST, yes, the syntax changed a bit. Consider this: TEST(NOHOOK,SEPARATE) on a PROCESS statement this will save your symbol table in an external file at compile time; you need to supply a compile-time DD statement named SYSDEBUG that points to where you want to store the symbol table; the name of the file will be stored in your object code, so it has practically no impact on the size of your load module; if your program abends, the symbol table will be dynamically allocated in order to provide a formatted dump of the data division. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.html== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Enterprise COBOL for z/OS V4
Ted, I don't know if you were kidding or not, but if you weren't, Both the Customization Guide (for the installer) and the Programming Guide (for the programmer) tell what IBM recommends for this. See the URL's in my previous post. Ted MacNEIL eamacn...@yahoo.ca wrote in message news:1770709423-1243019073-cardhu_decombobulator_blackberry.rim.net-1850278 0...@bxe1305.bisx.prod.on.blackberry... Especially for those using either the CICS or DB2 integrated coprocessor, using SIZE(MAX) is a *bad* idea. Making it a non-modifiable compiler option is a REALLY bad idea. Yes. But, that's not a guideline. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Question:
The first think you need to do is to understand that you should post messages via the List-Server and *not* via the Usenet newsgroup. For subscription information, check the bottom of any post (such as this one) that WAS sent via the list-server. Mark mtt...@gmail.com wrote in message news:a6a6be40-0b3f-475f-9de7-fbe20ffca...@y6g2000prf.googlegroups.com... If a company has a product relevant to mainframe systems is it considered okay for the company to post on this list asking for beta testers? Thanks, Mark -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
CEDF type of ability in IMS??
The usual testing tool that corresponds to CEDF for IBM, is BTS (Batch Terminal Simulator) that does NOT actually run in the IMS region. (It can be set to work interactively with IBM's Debug Tool, Xpediter, or many other interactive debugging tools) I don't know if it will give you what you want - but it might. As far as starting your transactions, do your application programmers just enter transaction name or do they enter /FOR first-screen-transaction-name I think the latter is what usually works (for MPR transactions). David Logan loga3...@comcast.net wrote in message news:011c01c9d954$90d99a70$b28ccf...@net... Thanks all to those who helped me get through step one in IMS. It's pain in the butt, a lot of stupid little pieces and parts and steps, but it's not that hard once you know what the pieces and parts and steps are. I got one of my two transactions working. However, the other one still isn't, and I see no obvious reason. No messages or anything. So my question is this: Is there some type of debug/log ability in IMS (perhaps similar to CEDF in CICS)? Is there an easy way for me to tell that it may be trying to access a DBD that doesn't have a file or something? I don't know why it just ignores me when I type the transaction in. As a secondary question, now that I'm thinking about it. My developers appear to be used to logging onto IMS, signing in, then just typing the transaction. Currently, I have to do a /SET TRANSACTION XXX before I can type in XXX. What is the magic to not have to do the /SET first? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
COBOL - BLOCK CONAINS - IBM Marketting Request (more info)
I just wanted to add (for both comp.lang.cobol and IBM-MAIN) that if you DO submit a (new) IBM Marketing REQUEST to ask for an enhancement compiler option for Enterprise COBOL (or follow-on product) to make an omitted BLOCK CONTAINS clause to work the same as the existing (IBM extension) BLOCK CONTAIN 0 variation, that you should include two references to the existing requests: 1) The SHARE requirement number is - SSLNGC03003 2) The existing (related to the SHARE requirement) MR number is - MR1216031447 If you include both these in any new marketing REQUESTS, I think that will have the most beneficial impact. -- Bill Klein wmklein at ix.netcom.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
BLOCK CONTAINS
Actually, I don't think the Standard has much opinion on the entire BLOCK CONTAINS clause. The fact is that MOST existing conforming COBOL compilers run in environments where blocking doesn't exist any more. For most conforming compilers, this phrase is documented as syntax checked but has no effect on application behavior - or something similar. I suspect that if one asked (via an official interpretation request) what happens when the BLOCK CONTAINS clause is omitted - and you are in an environment where blocking MAY exist, then the answer would be whatever the hardware and/or OS says will happen, happens. However, this is only my opinion of the current status. I strongly doubt that the would find the IBM behavior non-conforming. However, if anyone actually wants to find out, please contact me off-list and I can tell you how to submit an interpretation request. Of possible interest is the fact that the '85 COBOL Standard is no longer an official ANSI or ISO Standard. The current version is the 2002 ISO (or ANSI) Standard - and IBM does NOT even claim to conform to that. Alternatively, you might want to ask about this (as it relates to the Standard) via the Standards Forum section of the IBM COBOL Cafe. See: http://www-949.ibm.com/software/rational/cafe/community/cobol/standard?view= discussions Paul Gilmartin paulgboul...@aim.com wrote in message news:listserv%200905190056357954.0...@bama.ua.edu... On Mon, 18 May 2009 22:56:05 -0500, Bill Klein wrote: The actual phrasing of the current Standard is, 1) This clause is required except when one or more of the following conditions exist: ... c) The number of records or characters contained in a block is specified in the operating environment I think that leaving it out to get unblocked MAY be considered an extension. I think a reasonable person can conclude that for z/OS, specified in the operating environment means either as BLKSIZE on the JCL DD statement or available from SDB, and it is the intent of the Standard that when the BLOCK CONTAINS clause is omitted, that externally specified (by DD or SDB) value should prevail. And thus that z/OS COBOL deviates from the Standard on this matter. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Submitting a Marketing REQUEST (was: BLOCK CONTAINS
Frank Swarbrick fswarbr...@gmail.com wrote in message news:listserv%200905191643164240.0...@bama.ua.edu... snip By the way, any pointers on how to submit a marketing requirement? VSE actually has a submit a requirement web page (https://www- 03.ibm.com/servers/eserver/zseries/zvse/contact/requirement.html). Does z/OS have anything similar? Thanks! Frank As the saying goes, I have good news and I have bad news G The good news is The procedure for submitting a Marketing REQUEST is easy. Just contact your IBM Marketing Representative and explain what you want THEM to submit. The bad news is, Try finding out who your IBM marketing rep is. In many cases this is QUITE difficult - it is even hard for many customers to figure out who (how to contact) their local IBM branch. Once you find your local branch and/or your IBM marketing rep, then getting a REQUEST submitted should be a piece of cake. If your IBM Marketing Rep does not know how to submit a REQUEST, then come back to us here (and someone should be able to get your marketing rep in contact with someone who can help them) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: vse to z/os migration
To expand on Howard's note: 1) Do you have existing VSE and existing z/OS applications (and in-house expertise)? 2) Is this a single app that you need to migrate - while maintaining the existing VSE environment, or is this a shop migration? 3) Are you migrating CICS, Batch, DL/I, DB2, or some combination of these? 4) Are you migrating Assembler - or COBOL, PL/I, or other? If one of the HLL languages, are you running a CURRENT (e.g. COBOL for VSE with LE/VSE) in the VSE environment - or are you using an older (currently unsupported) compiler such as VS COBOL II or even DOS/VS COBOL? (Similar questions for PL/I) * * * * * * * As Howard indicated, if you are migrating a single COBOL (batch) program from VSE (with a current compiler) to MVS, then the program migration should be (relatively) simple, but the JCL (and tuning) may be difficult. If, however, you are converting a single CICS COBOL application (for example) from an existing (current compiler under VSE) to CICS/COBOL under z/OS, then JCL won't be much of an issue and only a few EXEC CICS implications become important. As I recall DL/I to IMS is more of a challenge while DB2 is less of a challenge. If you are actually doing a full shop migration from VSE to a (new to your shop) z/OS environment, then there is LOTS AND LOTS that you have to think about (and learn). Howard Rifkind ibm_m...@yahoo.com wrote in message news:283683.92748...@web33108.mail.mud.yahoo.com... Ron, First, do you have a z/OS (1.7 - 1/10) running? You didn't mention that. Second. If you do and it's a Cobol APP and you have the source code just take the program and re compile it using the O/S Cobol compiler. Correct any syntax errors correct the run JCL (from VSE to MVS) then move the data with something like FDR or DFDSS. Also, check with the z/OS Cobol syntax manual before you start. Still having problems??? Check back here for specific help, this is a great place to ask questions, someone is always around to pull you out of the fire. Good Luck. --- On Mon, 5/18/09, Ron Thomas ron5...@gmail.com wrote: From: Ron Thomas ron5...@gmail.com Subject: vse to z/os migration To: IBM-MAIN@bama.ua.edu Date: Monday, May 18, 2009, 2:15 AM Hi, We have got a requirement to migrate the application from vse environment to z/os, could some one please let me know the technical process involved in migrating systems from VSE to Z/OS also any documents that i can refer for the same Regards, Ron -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
vse to z/os migration
Kevin, Why do you say that you MUST remove STOP RUN statements from (COBOL) source in a VSE to z/OS conversion. There may be times and environments that you may want to do this - and using GOBACK will never hurt, but I seriously question the universal MUST remove statement. If you are talking about CICS (not batch), the current restrictions (that do NOT include STOP RUN) are listed at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg32/3.1.1 Again, for CICS, you may be interested in the discussion (that includes GOBACK and STOP RUN) in the CICS TS V4.1 beta documentation at (long URL): https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/topic/com.ibm.cics.ts. applicationprogramming.doc/topics/dfhp3_cobol_subprog_flow.html?resultof=%22 %67%6f%62%61%63%6b%22%20 Clark, Kevin kevin.cl...@bcbsde.com wrote in message news:3e469783d18ce74893d7a50dadb294410f714...@email01.server.bcbsde.net... Ron, If it's just a single application, we may need more specific such as hom many programs, language, files (VSAM, BDAM, ETC.) But converting the Core Image Library to a PDS Load library can be done via a PUNCH method and relinked under MVS id you don't have source. You will need to remove any STOP RUN from the COBOL source. Kevin -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Thomas Sent: Monday, May 18, 2009 2:15 AM To: IBM-MAIN@bama.ua.edu Subject: vse to z/os migration Hi, We have got a requirement to migrate the application from vse environment to z/os, could some one please let me know the technical process involved in migrating systems from VSE to Z/OS also any documents that i can refer for the same Regards, Ron -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail message and any attachments transmitted with it are confidential and are intended solely for the use of its authorized recipient(s). If you are not an intended or authorized recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the information contained in this e-mail is prohibited. If you have received this message in error or are not authorized to receive it, please immediately notify the sender and delete the original message and all copies of it from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: BLOCK CONTAINS
I may (a while ago - in the past) have mislead Clark. There is DEFINITELY a difference between coding Block Contains 1 versus omitting the Block CONTAINS clause (for output files) The former creates a RECFM=FB/BM file (with one record per block) while the latter produces a RECFM=F/V file Personally, neither are USUALLY the desired results, but they are different. howard.bra...@cusys.edu wrote in message news:jps215p3ha8d7g7qvn2j1cigaqq8939...@4ax.com... On 15 May 2009 18:08:22 -0700, cfmpub...@ns.sympatico.ca (Clark Morris) wrote: I checked the reference you gave and for QSAM files, if the BLOCK CONTAINS clause is omitted, BLOCK 1 RECORD is assumed. This stupidity has aggravated me for years. The whole idea of (IBM mainframe) CoBOL still caring about blocksize is irritating. The fix of making BLOCK CONTAINS 0 is IMHO, not the way fixes should be. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: BLOCK CONTAINS
I don't know about Clark submitting a requirement in the 90's, but there is an existing SHARE requirement: SSLNGC03003 Compiler option to make BLOCK CONTAINS clause SMS sensitive (Part of the Description) The current default for when the BLOCK CONTAINS x RECORDS clause is omitted is for unblocked files. If this default is taken, the result is an unblocked file with very poor I/O performance. This may not be obvious since the JCL may be correctly coded, but any JCL BLKSIZE specification will be ignored without notification. Coding BLOCK CONTAINS 0 RECORDS is the preferred solution, since it allows DFSMS to pick blocking with the optimal BLKSIZE. This requirement requests a compiler option that would allow the default for when the BLOCK CONTAINS clause is omitted to be set to the same processing as the current handling of BLOCK CONTAINS 0 RECORDS instead of creating/reading unblocked files. * * * * * This was submitted in 2003 and in 2004, IBM responded with ACCEPT. There is currently a push within the comp.lang.cobol group to get AS MANY AS POSSIBLE of existing Enterprise COBOL sites to submit a Marketing REQUEST that references this SHARE requirement and asking for implementation sooner than later. I would suggest that ALL of those in IBM-MAIN who are interested in seeing this enhancement, should also contact their IBM marketing representative and have such a REQUEST submitted from your site. (And no, don't ask ME how to find an IBM marketing representative) Gilbert Saint-Flour usenet5...@yahoo.com wrote in message news:200905181748.44799.usenet5...@yahoo.com... On Friday 15 May 2009 04:47, Clark Morris wrote: I submitted a SHARE requirement back in the 1990's to have a compile option that the default be BLOCK 0. Great idea, and I wish IBM added that option to the compiler. What a stupid necessity that programmers have to code BLOCK CONTAINS 0 ! -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: BLOCK CONTAINS
John, What happens if you run the exact same test, but instead of having the JCL for your output as: // RECFM=FB,LRECL=80,BLKSIZE=0,DSORG=PS you instead JUST coded // DSORG=PS i.e. you leave out the JCL (overrides) for RECCFM, LRECL, and BLKSIZE) - I think that this is when/where the different BLOCK CONTAINS clauses make a difference. John McKown joa...@swbell.net wrote in message news:listserv%200905181308288278.0...@bama.ua.edu... I just ran a quick test using Enterprise COBOL 3.4.1. I had one input FD and three output FDs. The output FDs were: (1) No BLOCK CONTAINS at all; (2) BLOCK CONTAINS 0 RECORDS; and (3) BLOCK CONTAINS 1 RECORDS. I directed each to a separate SMS managed disk dataset. On the JCL for each output file, I specified: // RECFM=FB,LRECL=80,BLKSIZE=0,DSORG=PS I then dumped the records using IDCAMS, but with the JCL looking like: //JS010EXEC PGM=IDCAMS, // REGION=20M //SYSPRINT DD SYSOUT=* //I1 DD DISP=SHR,DSN=TSH009.MYCOPY.BLOCK0,RECFM=U,BLKSIZE=32760 //I2 DD DISP=SHR,DSN=TSH009.MYCOPY.BLOCK1,RECFM=U,BLKSIZE=32760 //I3 DD DISP=SHR,DSN=TSH009.MYCOPY.NOBLOCK,RECFM=U,BLKSIZE=32760 //SYSINDD * PRINT INFILE(I1) DUMP COUNT(30) PRINT INFILE(I2) DUMP COUNT(30) PRINT INFILE(I3) DUMP COUNT(30) // All three outputs were IDENTICAL and showed that each file was identically blocked. That is: the BLOCK CONTAINS 1 RECORDS did not result in an unblock file! This was run on z/OS 1.10. Oh, for fun, I also put the output onto non-SMS managed DASD with the same result. -- John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: BLOCK CONTAINS
Paul Gilmartin paulgboul...@aim.com wrote in message news:listserv%200905181607125082.0...@bama.ua.edu... On Mon, 18 May 2009 18:18:20 +0200, Gilbert Saint-Flour wrote: snip Is default unblocked an ANSI Standard requirement? (Of course this doesn't preclude an extension implemented via compiler option.) The actual phrasing of the current Standard is, 1) This clause is required except when one or more of the following conditions exist: a) A physical record contains one and only one complete logical record. b) The hardware device assigned to the file has one and only one physical record size. c) The number of records or characters contained in a block is specified in the operating environment I think that leaving it out to get unblocked MAY be considered an extension. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
BLOCK CONTAINS
Ted, The issue that I think you are missing is that this entire conversation started with a site trying to do a VSE to z/OS conversion. For this site, this is a major concern. Certainly not the only one, but it is important to understand exactly does happen/when/how under z/OS - so the requirements for the conversion are resourced and met. As I have said previously, I do think that having Block Contains 0 is the best solution - as it gives desirable results when the phrase is used and doesn't hurt when it isn't used. Ted MacNEIL eamacn...@yahoo.ca wrote in message news:1311180719-1242704268-cardhu_decombobulator_blackberry.rim.net-1990313 5...@bxe1305.bisx.prod.on.blackberry... We have 45 years of baggage. Woulda, coulda, shoulda. Most people/shops have templates with these things already specified. Copy, and move on. Whenever I hear this diachronic rationale for some deficiency of z/OS, I think of the political unrest in the U.S. in the 1960's when bumper stickers: America: Love it or leave it! were countered with: America: Change it or lose it! C 'America' 'z/OS' ALL You missed my point(s): 1. The existance of templates can/does handle the requirement for BLOCK CONTAINS. 2. Some things are way to trivial to lose sleep over. 3. There are more important things to worry about than something that has been around for so long, and we have a solution for. 4. Copy and move on! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: BLOCK CONTAINS
Frank Swarbrick fswarbr...@gmail.com wrote in message news:listserv%200905151108397984.0...@bama.ua.edu... On Fri, 15 May 2009 09:27:42 -0400, Thompson, Steve steve_thomp...@stercomm.com wrote: snip It depends on if the file is pre-defined. If it is not, and I don't include DCB stuff on the DD, then it does what Cobol tells it to do (because there is no other place to get that information!). However if the file *is* predefined then *that* information appears (for blocking only, not for RECFM (V vs B) or LRECL) to override what Cobol states. Examples... If I predefine a file as RECFM=VB, BLKSIZE=1, LRECL=4004 then 1) If Cobol says BLOCK CONTAINS 1 it works (of course). 2) If Cobol says BLOCK CONTAINS 0 it works. 3) If Cobol says BLOCK CONTAINS 12345 it works (!!!) 4) If Cobol does not have a BLOCK CONTAINS clause it works (!!!) This is the case no matter if I am reading from the file or writing to it. I am glad it works no matter what. But the documentation seems to me to indicate that conditions 3 and 4 should not work, even though they do. That is where I am getting confused. snip Frank, (Some private email also sent on this), I think that the current COBOL documentation *ASSUMES* (possibly erroneously) that for OUTPUT files A) For QSAM, that they are NOT pre-defined and that the combination of the COBOL FD information and the JCL information will CREATE the file B) For VSAM (KSDS, ESDS, *and* RRDS) that the file IS predefined (e.g. IDCAMS). The statement at: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/1.9.4.3.2 that says, If your COBOL program writes records to a new file that will be made available before the program runs, ensure that the file attributes in the DD statement, the environment variable, or the allocation do not conflict with the attributes in the program. seems to be saying that if you do predefine QSAM files that you should make certain that the attributes match. The UNSTATED implication (or my inference) is that your case 3 and 4 may work today and it may work tomorrow, but there is no GUARANTEE that they will work with the next release or even service level. My guess is that they will, but I certainly do not see any place in the existing COBOL documentation that guarantees this. From my experience (and as a personal opinion), I would NOT pre-allocate QSAM files - but instead would use BLOCK CONTAINS 0 in the COBOL program. I can't think of when this would ever hurt and I can certainly see lots of times that it would help. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IMS - how do I run an interactive transaction?
Are there any IMS systems programmers or even application programmers at your shop? It seems to me that you are starting out of your depth. any way, you may want to look at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dfsisdf9/4.8.1 for JCL to start a MPR. If you are actually trying to test an application program, then I would strongly suggest starting with something like BTS - rather than trying to start your own control region and MPR. Can you tell us the actual task you are trying to accomplish as well as what existing IMS personnel there is at your shop? It has been a LONG time since I had to do much of this, but as I recall, almost NOTHING that you should be doing needs (or should be) done from the master console - which seems to be where you are doing almost everything. David Logan loga3...@comcast.net wrote in message news:001001c9d1bb$d89ac140$89d043...@net... OK, yes, I am remembering now. Man, I hate IMS :) I really need to get better versed in it. Anyway, what's happening is that IMS isn't automatically starting any of my MPP regions. When I try to start them with /START REGION xxx, I get a whole bunch of MPP regions that all say: DFS690A IMS91M11.REGION.IMS91M11 - CTL PGM NOT ACTIVE, REPLY 'WAIT', 'CANCEL' OR 'ALT-ID' And yet again, the message manual explains the obvious (such as if a control region is going to come up soon, reply wait.) It doesn't explain what I should be doing to figure out why it's not seeing a control region that is *supposed* to be running. So what are the MPP regions looking for that it doesn't have? The IMS ID seems to be fine. The MPP regions have IMSID=IMS1, and the IMS control region has IMS1 in it's operator reply, so it *looks* like the IMS IDs match. David Logan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jim Thomas Sent: Sunday, May 10, 2009 11:30 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IMS - how do I run an interactive transaction? Not into IMS either but ... I think you'd need an MPR / MPP available first... (start an MPR / MPP and then issue a /DIS A) First off ... assuming that the transaction was call TEST01, clear your screen and key in TEST01_ where the '_' is meant to be a space. If that does not work, you're likely missing an /ASS TRANS TEST01 CLASS ?? where the '??' would be class available on the MPR / MPP and defined to the TEST01 transaction. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Logan Sent: Sunday, May 10, 2009 11:52 AM To: IBM-MAIN@bama.ua.edu Subject: FW: IMS - how do I run an interactive transaction? Hi guys. Sorry, but I am not very well versed in IMS, and I sure am missing something. I want to run an IMS transaction, but no matter what I do, all I get is: DFS064 11:46:46 DESTINATION CAN NOT BE FOUND OR CREATED I've looked this message up in various places, but I have found nothing at all useful to resolving it. What am I missing? This is IMS V9 under z/OS 1.8. It's got default security, which means it won't let me do hardly anything via terminal commands, I have to do everything via message replies on the master console. I have done a /START DC, although I don't know how to tell if it was successful. OK, I've provided the information I can think of to provide. Any suggestions? Thanks! David Logan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.325 / Virus Database: 270.12.23/2106 - Release Date: 05/10/09 07:02:00 No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 8.5.325 / Virus Database: 270.12.23/2106 - Release Date: 05/10/09 07:02:00 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Metal C and CICS
The original question came while I was working with the CICS dox people on the (originally problematic) CICS TS V4.1 beta page at: https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/topic/com.ibm.cics.ts. whatsnew.doc/regular_topics/hll_support.html as well as erroneous information in the actual CICS TS V4.1 announcement letter (soon to be corrected, I have been told). My expertise told me that both the COBOL and PL/I information was wrong on that page and HLASM was missing entirely. I have been working with some IBM contacts to get THAT information corrected. While doing that, I noticed that for C/C++, the page states, Run time support - Provided by Language Environment which, to me, raised the question of whether NOMETAL was (or was not) required for CICS. This lead me to searching the manuals, and discovering that the current Metal C documentation seems totally silent on the issue. You mentioned the environment and I had looked at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CCRUG110/1.1 and it doesn't say that you cannNOT use __cinit() under CICS. I tried contacting some people from IBM off-list but couldn't get a definitive answer, so I posted here (and on the CICS list). As for WHY one *might* one to do this, if you have a small/targeted CICS region that currently using ONLY non-LE enabled command-level CICS HLASM, you might want to convert it to Metal C (or some of the programs) withOUT introducing the (CICS) LE run-time library into the region. Other than that, I can't (personally) think of many (any?) reason to do it, but that doesn't mean that some customer somewhere doesn't have a good reason to do so. David Crayford dcrayf...@gmail.com wrote in message news:4a03e6c6.6090...@gmail.com... Bill Klein wrote: (to IBM-MAIN and CICS lists), I have asked this off-list but so far can't find an answer. Can anyone tell me if Metal C is supported with (works under) CICS or not? I can imagine that it would be pretty unusual to want this, but as HLASM (both LE-enabled and not) works with CICS, I was thinking that Metal C may as well (withOUT the LE CICS run-time libraries). Metal C will run under CICS with some caveats. Because Metal C generates HLASM code it can run anywhere HLASM runs (everywhere). The problem will be if you want to use a Metal/C environment, which will attempt to allocate storage with a GETMAIN. CICS will obviously choke when that happens. Some Metal C runtime functions require an environment, for example sprintf(). I would suggest asking z/OS C/C++ questions in the new cafe http://www-949.ibm.com/software/rational/cafe/community/ccpp. BTW, out of interest why would you want to run a Metal C program in CICS when LE C does the job just fine? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Metal C and CICS
(to IBM-MAIN and CICS lists), I have asked this off-list but so far can't find an answer. Can anyone tell me if Metal C is supported with (works under) CICS or not? I can imagine that it would be pretty unusual to want this, but as HLASM (both LE-enabled and not) works with CICS, I was thinking that Metal C may as well (withOUT the LE CICS run-time libraries). Places that I have looked are: - z/OS V1R10.0 XL C/C++ User's Guide http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CBCUG170/CONTENTS and - z/OS V1R10.0 Metal C Programming Guide and Reference http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CCRUG110/CONTENTS In particular, I would have THOUGHT there might be information on this at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CBCUG170/4.30 or http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CBCUG170/4.76 but neither of those places (or anywhere else that I can see) specifically says yes or no. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
METAL C: CodeGen defeciency?
I received the following note concerning the CodeGen problem in IBM-MAIN a
while ago.
Can someone in IBM-MAIN, please create a PMR for this?
Bill,
I apologize for the late reply.
Yes. please make a suggestion for a customer PMR in the IBM-MAIN list.
Again, thanks for your help.
Compiler Development
IBM Canada Lab.
(
Subject
RE: Fw: METAL C: CodeGen defeciency?
Would a customer PMR help? I can suggest it in the IBM-MAIN list - but won't
unless you think it would be useful.
Bill,
I won't say it was intentional. The same thing exists in non-Metal C
produced code too. And my digging shows that it has been in the compiler
since the z/OS V1R5 release. I'll have a chat with the compiler people here
to see how we want to deal with it.
Thnaks for bringing this to our attention.
Compiler Development
IBM Canada Lab.
Subject:
Fw: METAL C: CodeGen defeciency?
See this post in IBM-MAIN.
Is this something that someone should create a PMR about - or is this
intentional? (I certainly don't know enough C to know the answer)
Johnny Luo johnny.xingkui@gmail.com wrote in message
news:ae3908060904220711r536e0bd1nb1b881eef154e...@mail.gmail.com...
Hi,
I was trying new METAL option of XL C and the following is the HLASM code
generated :
* {
*char a[20]=12345;
MVC 88(6,13),0(11)
MVI @74a+6,0
MVC @74a+7(13),@74a+6
MVI @74a+6,0
MVC @74a+7(13),@74a+6
* return;
* }
It initialized the buffer twice! I cannot think of why. Is it normal?
--
Best Regards,
Johnny Luo
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Assembler and ECBL conversion issues
Absolutely doing static-link below the line should be your LAST choice. Consider: 1) Change static calls to CALL identifier for 24-bit code (Don't change DYNAM/NODYNAM compiler option) and use DATA(24). 2) As others have suggested, see if you need the assembler routines at all. If they are primarily I/O modules, check out the COBOL EXTERNAL attribute and see if you can't (easily) convert them to COBOL. One thing to be VERY careful of when doing batch conversions is to make certain you are aware of performance issues. I have seen VS COBOL II to Enterprise COBOL conversions that died because inadequate time was allocated for performance tuning (especially for LE run-time options and COBOL compiler options). My guess is that your Assembler is NOT LE-enabled which is an entire other area for consideration. If you have any Assembler drivers (rather than subroutines) this becomes a HUGE issue in such a conversion. Leslie Wagner wagn...@finance.nyc.gov wrote in message news:listserv%200905040909091182.0...@bama.ua.edu... I am the original poster of this on bit.listserv.ibm-main. PJ Farley ccd it here - thanks Pete! These assembler modules all do I/O against VSAM and QSAM files. Open, close, gencb, modcb, acb macros mostly that I've seen so far. I'm still going thru them. Some of them were upgraded from older DOS assembler code 37 years ago or so. I think we want to take the path of least resistance here, but also wanted to know just what we might be losing by taking that path. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Enterprise COBOL code generation question
I will defer to Rick Arellanes (who has already replied) on this (and most performance questions). HOWEVER, I do want to re-iterate that *if* performance is of concern to you, the best general rule is to compile with TRUNC(OPT) and use COMP-5 for specific fields that MAY have values larger than their PICTURE clause allows. As to the why does IBM produce the code that it does for TRUNC(BIN) - when this is by definition non-Standard conforming, this is an old argument. Although there have been some performance enhancements over the years (particularly in the early years) for TRUNC(BIN), IBM does make some odd choices for an environment that should not be bothered by the PICTURE clause. In the '02 COBOL Standard, there were a number of true binary data USAGEs introduced and there are existing SHARE requirements asking for IBM to include support for them. When/If IBM does ever support these, one can only hope that they would be introduced in a performance-sensitive manner. Farley, Peter x23353 peter.far...@broadridge.com wrote in message news:053f2631ec9c584883847c8b4970a22803ce6...@josqems1.jsq.bsg.ad.adp.com. .. I am failing to understand something about the code generation that the Enterprise COBOL compiler (V3.4.1) performs. For a WORKING-STORAGE variable defined like this: 77 WORK-WORD9 PIC S9(09) BINARY. with TRUNC(BIN) and OPTIMIZE(STD) in effect, this IF statement: IF (WORK-WORD9 -1) OR (WORK-WORD9 +256) Generates a bunch of code to convert WORK-WORD9 to packed decimal in temporary storage (and it does it *twice* no less!) to then do compare-packed for each of the literal values. How or why is it that the compiler does not just use binary constants for such a pair of comparisons? It just does not make any sense to me for the compiler to convert a fullword binary variable to packed in this case, and to do it twice for goodness sake. And secondly, if it really *has* to do the conversion, doesn't the optimizer realize it already did it already? The description of OPTIMIZE(FULL) doesn't sound like it will help here, though I will try it. OPTIMIZE(FULL) says it eliminates unreferenced WORKING-STORAGE but says nothing about better code optimization. Confused, Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
METAL C: CodeGen defeciency?
It looks as if Kelly posted this directly to the newsgroup and didn't send it to the list. See IBM response below. Kelly Arrey kelly.ar...@gmail.com wrote in message news:179d3e62-69d2-482c-99f1-0b74a830f...@g19g2000vbi.googlegroups.com... Hi Johnny, We're investigating - it looks like a compiler bug. And yes, as David pointed out earlier, the optimizer optimizes it away. Thanks for bringing this to our attention. Kelly Arrey IBM z/OS XL C/C++ Compilers Visit our IBM C/C++ Café at http://www-949.ibm.com/software/rational/cafe/community/ccpp -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
I have snipped all the content from this IBM-MAIN thread *and* have sent this note to both IBM-MAIN and the Assembler list. The question has been asked as to whether there is consolidated information anywhere on IBM performance advice related to HLASM coding for best pipeline performance. The answer seems to be that, NO, no such consolidated information exists, but that some individual hints are spread out in the PoP (or at least implied there). This seems like a good time to remind both lists that the ASM project of SHARE is still accepting requirements *AND* that requests for documentation (or improved documentation) is definitely within the scope of such requirements. (No recent requirements have been submitted, but I do keep an eye out for when/if they are.) If you are a SHARE member organization and already registered to participate in the ASM project requirements process, please feel free to submit such a requirement (or any OTHER requirement that you might have for either HLASM or the binder). If you are a SHARE participant but not currently registered for the ASM project requirements process, please consider joining. If you need any additional information on this, please contact me off-list. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
QSAM - Blocking logic defect for VB file?
Please do report back to the group when you get answers from your PMR. One thing that you haven't mentioned is whether or not your are programs are compiled with the COBOL AWO (or NOAWO) compiler option. This has SIGNIFICANT impact on the processing of VB files. A change from what was used for 10 years) for this setting could certainly cause a change in results - but should NOT result in a corrupted RDW. Johnny Luo johnny.xingkui@gmail.com wrote in message news:ae3908060904130920x786a3668h2be1b4f5ccea0...@mail.gmail.com... Hi, One of our customers had a problem in their production batch jobs. One COBOL program writes variable length records to a VB PS data set and after smoothly running for ten years the program begun to generate VB files with invalid RDWs as reported by DFSORT which is used to copy the files. We are at z/OS 1.9. I first wrote a program to read the physical blocks and parsed each block using BDW/RDW mechanism. It shows that there are 97 blocks which contain invalid RDW(RDW4 or RDWLRECL)?No problem found in BDW. They just match the physical length of corresponding block. To find the real problem I decided to parse the blocks in a different way. The COBOL program builds the records as following: 1. After RDW each record contains a 8-byte identifier string 'BGLGLGP '; 2. 120 bytes from identifier string is a two-bytes length field which contains the length of the variable data of the record; 3. Then comes the variable length part. So I use the string ''BGLGLGP ' as delimiter to separate each record and then find its 'real' RDW value in the 4-byte area just before the identifier string. I also use the two-byte length field set by user program to calculate the supposed RDW value. This time the result is more enlightening. All 97 'bad' blocks are in the same pattern: (the following is simplified just to illustrate) - | BDW | RDW1 | REC1 | RDW2 | REC2 | - 1. BDW matches the actual length of the block; 2. RDW1 and RDW2 all match the 'should-be' RDW value calculated from length field set by application program; The problem lies in the actual record length. For REC1, its actual length is shorter or longer than RDW1 indicates! When DFSORT or other application like ISPF tries to parse the block via RDW, it found no problem with record1 cause the value of RDW1 is valid. But it will get the wrong start address of record2 via RDW1 cause the actual length of REC1 is not as RDW1 indicates. That's means it will select the wrong area as RDW2 and its value is unpredictable. Thus the so-called 'invalid rdw'. How does this happen? I can only think of one situation, that is, when QSAM is building the block. After moving record1 into the block, record2 should be placed right after record1. If for some reason QSAM failed to do so, record2 will overlay part of record1 or be placed far behind record1. That will generate a 'bad' block exactly as what we saw in this case. To make things more complicated, the customer found one of their channel paths could not be vary online when they tried to re-IPL the system. So they temporarily discard the use of that path and then suddenly the problem disappears. Now the customer believe the problem is caused by that channel path and they have reported the problem to IBM. For me it's hard to accept it cause I cannot see the relationship. Write operation does involve the interacion with channel subsystem but from my limited knowledge after QSAM finished the building of the block all the left operations are at block level and will not touch the inner structure of the block. It's nearly impossible for them to generate a 'bad' block exactly as we saw in this specific case even if truncating or overlay occurs. So I still believe the cause of the problem is that QSAM somehow failed to build the block right. Any one can give me some hints? -- Best Regards, Johnny Luo -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
FW: SYSOUT dynamic allocation in COBOL
I may be missing something, but if you know at compile-time (when you can set an environment variable) that you want the output to go to SYSOUT, why are you using files (with OPEN, WRITE, etc) and not just doing a DISPLAY statement? Either that or call CEEMSG. I think those are more normal ways in COBOL to send output to SYSOUT. David Speake david.spe...@bcbssc.com wrote in message news:listserv%200903152048381559.0...@bama.ua.edu... I have used dynamic allocation via the environmental variables in COBOL. Thanks to Steve Comstock and others for getting me started. But I see nothing about SYSOUT and it says a DSN is required. My need is for a //X DD SYSOUT=(B,SMTP) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IBM Mainframe, Mixed COBOL and PL/I - SHARE members
to: comp.lang.pl1, comp.lang.cobol, and IBM-MAIN I don't know how many SHARE members who have mixed COBOL and PL/I applications participate in and/or watch each of these groups, but if you fit into this category, you may want to check out a new SHARE (LNGC project) requirement that would (according to some) make maintenance easier by providing a common method of defining the MAIN program in mixed COBOL and PL/I load modules. If you are a SHARE member and are already registered to participate in the LNGC project, just look at the requirements Open for Voting. If you are a SHARE member and not currently registered for participating in the LNGC project, then follow the directions under the Member tab of the main SHARE website. Let me know (Off-Line) if you have any problems with doing this. -- Bill Klein wmklein at ix.netcom.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: MLE Option Support
Call me confused, If by MLE you are referring to Millennium Language Extensions, then I don't know why you think this has ANYTHING to do with the level of z/OS (or even LE) in use. This is a language specific feature and is dependent upon the COMPILER (COBOL or PL/I) in use and NOT what release/version of the operating system you are using. As far as future support, I find it very difficult (if not impossible) to believe that either COBOL or PL/I will drop support for this feature - especially without a VERY SIGNIFICANT warning periods. At lest for COBOL, the feature allows for absolute or relative windowing, so either won't be impacted by a change from 2009 to 2010 in the current year. What am I missing that makes you think that this MIGHT change? George Rodriguez rodrigu...@palmbeach.k12.fl.us wrote in message news:b8556c7c0999d4479a3f7944ac47e98303804...@pbmail5.palmbeach.k12.fl.us. .. I'm currently running z/OS v1.4 and I've been asked if the MLE option will work beyond 2010. My plans are to first go to v1.7 then to 1.9. I will need to know if the MLE will work on those environments as well. Thanks in advance... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
FW: Cobol: Maximum number of FD Statements
Gee, a problem with the EXIT compiler option. It is almost as if I had written in this forum on March 2nd, here is, however, one other option that you should check in your listing. See if you have any EXIT compiler options specified. See: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/APPENDIX1.5 and, of course never heard back that the EXIT compiler option was in use. (I also never heard back about the SIZE compiler option in effect) NOTE: if you are using RW exits, my best guess is that you have the report-Writer add-on product. If you are getting S0C1 with that, then I suggest that you contact SPC systems (if you haven't already). Going to NOPRTEXIT *may* cause your problems if you actually do have Report Writer programs to be compiled. -Original Message- From: Bill Klein [mailto:wmkl...@ix.netcom.com] Sent: Monday, March 02, 2009 1:03 PM To: IBM-MAIN (IBM-MAIN@BAMA.UA.EDU) Subject: Fw: Cobol: Maximum number of FD Statements The Enterprise COBOL compiler (usually) does not quietly S0C1 with no messages if the region is too small. The one thing that I would check is whether you have the compiler option SIZE(MAX) either explicitly or implicitly specified. Check out http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/2.4.46 and notice the warning (especially if you are using the SQL or CICS compiler options). If you get a S0C1 when using IGYCRCTL *and* you are using vanilla compiler options, then you definitely should be working with IBM support. There is, however, one other option that you should check in your listing. See if you have any EXIT compiler options specified. See: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/APPENDIX1.5 If you are using any of those (and CA might want you to), then this MIGHT result in a S0C1. If you are using that, then try compiling with NOEXIT and see if that gets rid of the S0C1. NOTE: If you actually reversed your report on what was happening and compiling with IGYCRCTL gets a clean compile and compiling with a pgm=C??? gets the S0C1, then that is something you should check with CA. Gibney, Dave gib...@wsu.edu wrote in message news:edfbe8a9b39ed541ba3c8177c32ff0c8945...@exchangevs-02.ad.wsu.edu... Damn small for this day and age. I'd bet that the complier got bigger and pushed you past some limit. I'd suggest at least 64M. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of frederick.verw...@hrsdc-rhdsc.gc.ca Sent: Monday, March 02, 2009 10:10 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Cobol: Maximum number of FD Statements The region was defined by the cataloged procedure at 4096K. It didn't change with the upgrade to z/OS. I agree with Dennis that it's likely a compiler issue. Thanks for all the ideas folks! Regards, Eric Verwijs Programmer Analyst | Programmeur-analyste CPP/ OAS/ IA Production Support Team | Équipe de soutien à la production RPC / SV / IA frederick.verw...@hrsdc-rhdsc.gc.ca Telephone | Téléphone 613-941-7492 Facsimile | Télécopieur 613-941-4234 National Headquarters | Administration Centrale Human Resources and Skills Development Canada | Ressources humaines et Développement des compétences Canada Government of Canada | Gouvernement du Canada -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gibney, Dave Sent: 2009-03-02 12:52 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Cobol: Maximum number of FD Statements What's the REGION on the Compile step? Also check the SIZE options. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Roach, Dennis (N-GHG) Sent: Monday, March 02, 2009 9:41 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Cobol: Maximum number of FD Statements Sounds more like a compiler problem than a compile problem. It could be a table overflow or anything. IBM, or the owner of the compiler, should be contacted. I doubt that this group will be of much help. Dennis Roach GHG Corporation Lockheed Martin Mission Services Flight Design and Operations Contract Address: 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Mail: P.O. Box 58487 Mail Code H4C Houston, Texas 77258 Phone: Voice: (281)336-5027 Cell: (713)591-1059 Fax:(281)336-5410 E-Mail: dennis.ro...@lmco.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning
Fw: Cobol: Maximum number of FD Statements
The Enterprise COBOL compiler (usually) does not quietly S0C1 with no messages if the region is too small. The one thing that I would check is whether you have the compiler option SIZE(MAX) either explicitly or implicitly specified. Check out http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/2.4.46 and notice the warning (especially if you are using the SQL or CICS compiler options). If you get a S0C1 when using IGYCRCTL *and* you are using vanilla compiler options, then you definitely should be working with IBM support. There is, however, one other option that you should check in your listing. See if you have any EXIT compiler options specified. See: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/APPENDIX1.5 If you are using any of those (and CA might want you to), then this MIGHT result in a S0C1. If you are using that, then try compiling with NOEXIT and see if that gets rid of the S0C1. NOTE: If you actually reversed your report on what was happening and compiling with IGYCRCTL gets a clean compile and compiling with a pgm=C??? gets the S0C1, then that is something you should check with CA. Gibney, Dave gib...@wsu.edu wrote in message news:edfbe8a9b39ed541ba3c8177c32ff0c8945...@exchangevs-02.ad.wsu.edu... Damn small for this day and age. I'd bet that the complier got bigger and pushed you past some limit. I'd suggest at least 64M. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of frederick.verw...@hrsdc-rhdsc.gc.ca Sent: Monday, March 02, 2009 10:10 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Cobol: Maximum number of FD Statements The region was defined by the cataloged procedure at 4096K. It didn't change with the upgrade to z/OS. I agree with Dennis that it's likely a compiler issue. Thanks for all the ideas folks! Regards, Eric Verwijs Programmer Analyst | Programmeur-analyste CPP/ OAS/ IA Production Support Team | Équipe de soutien à la production RPC / SV / IA frederick.verw...@hrsdc-rhdsc.gc.ca Telephone | Téléphone 613-941-7492 Facsimile | Télécopieur 613-941-4234 National Headquarters | Administration Centrale Human Resources and Skills Development Canada | Ressources humaines et Développement des compétences Canada Government of Canada | Gouvernement du Canada -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gibney, Dave Sent: 2009-03-02 12:52 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Cobol: Maximum number of FD Statements What's the REGION on the Compile step? Also check the SIZE options. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Roach, Dennis (N-GHG) Sent: Monday, March 02, 2009 9:41 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Cobol: Maximum number of FD Statements Sounds more like a compiler problem than a compile problem. It could be a table overflow or anything. IBM, or the owner of the compiler, should be contacted. I doubt that this group will be of much help. Dennis Roach GHG Corporation Lockheed Martin Mission Services Flight Design and Operations Contract Address: 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Mail: P.O. Box 58487 Mail Code H4C Houston, Texas 77258 Phone: Voice: (281)336-5027 Cell: (713)591-1059 Fax:(281)336-5410 E-Mail: dennis.ro...@lmco.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of frederick.verw...@hrsdc-rhdsc.gc.ca Sent: Monday, March 02, 2009 6:56 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Cobol: Maximum number of FD Statements No error. We just upgraded to z/OS 1.8 and one of the programs that compiled before the upgrade no longer compiled after it. It was just a shot in the dark to figure out why it wasn't compiling since it has an awful lot of reports. An even more irritating thing is that a previous version of the offending program still compiles and all the programmer did in the new version (afaik) is add a bunch of new reports. It's a strange compile error too, S0C1 and and doesn't even point to a statement in the program. No real compile listing either. We use CA Workbench to do compiles (I usually just grab the JCL and don't
Fw: Cobol: Maximum number of FD Statements
That actually raises an interesting question. As the limit of FD's is larger than the limit of DD's allowed in a job step *AND* COBOL now supports dynamic allocation, I wonder how COBOL would do if you did try to have more than 3273 files opened at the same time? I certainly wouldn't want to consider maintaining or running a program that DID this, but it does seem interesting to me G Ken Porowski ken.porow...@cit.com wrote in message news:b192ab50f9a86f438aa3a8528934355e0e0d8...@crplivexc52.citnet.cit.com.. . 65535 Language Reference Appendix B. Compiler Limits -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of frederick.verw...@hrsdc-rhdsc.gc.ca Sent: Friday, February 27, 2009 2:01 PM To: IBM-MAIN@bama.ua.edu Subject: [IBM-MAIN] Cobol: Maximum number of FD Statements Hello everybody, Our installation is running z/OS 1.8, IBM Enterprise COBOL for z/OS 3.4.1. If I'm missing something here, let me know. I've looked in our Cobol language reference and the programming guide and of course, searched the web. If the answer's there, I've not found it. How many FD/SD statements can a Cobol program have? According to my System 390 JCL manual, a job step can have 3273 DD statements. So, I expect a Cobol program could not have more than that. Perhaps there is no defined maximum other than the maximum Cobol program size, whatever that is. Can anybody tell me? Regards, Eric Verwijs Programmer Analyst | Programmeur-analyste CPP/ OAS/ IA Production Support Team | Équipe de soutien à la production RPC / SV / IA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
COBOL question - NOTE
FYI, The NOTE statement actually was impacted by the LANGLVL compiler option. Therefore, if you are converting OS/VS COBOL (or DOS/VS COBOL) code to a currently supported compiler, you probably want to look this up - to make certain that you comment the correct lines. John P Kalinich jkali...@csc.com wrote in message news:of135dfabb.ddd9c523-on85257552.006ac756-86257552.006af...@csc.com... John Mckown of the IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 02/03/2009 01:11:50 PM: It seems to me that I remember a COBOL version which had a NOTE verb. It definitely is not in Enterprise COBOL. Am I once again confused, or did that disappear in some primeval version? 4.2.6 Miscellaneous Unsupported OS/VS COBOL Language Elements NOTE Statement OS/VS COBOL accepts the NOTE statement. VS COBOL II does not accept the NOTE statement. Regards, John K -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
AMODE(64) COBOL - SHARE requirement
Given the recent discussions in IBM-MAIN and given the fact that the 2004 LNGC requirement asked for multiple things (including 64-bit COBOL), I have created a new SHARE LNGC requirement: SSLNGC09001 AMODE(64) COBOL that works with AMODE(31) COBOL If you are a current LNGC project requirement participant, you should have received a note indicating that it is now available for voting. If you are a SHARE member but do not currently participate in the LNGC project and this issue is important to you, please register for the LNGC project and let IBM know what you think (PRO *or* CON). If you belong to one of the other user groups and are interested in submitting a similar requirement, please contact me off-list and I will be happy to send you the wording of this requirement. If you do NOT already participate in SHARE or any other IBM user group, Why not? G If this issue is important to you, you may still submit a marketing requirement to IBM. If you want to see the wording of my requirement, please contact me off-list and I will send it to you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
64-bit COBOL
(New but follow-on thread), There are now and have been ever since the question was first raised at least three different issues (IMHO). 1) The one that Clark and others have TRIED to communicate to IBM, but which seems hard to convey - or at least difficult to hear that IBM understands is the MESSAGE conveyed to upper management by the fact that there are 64-bit C/C++, Java, and Assembler but not COBOL. What MANAGEMENT hears is that COBOL IS NOT STRATEGIC (to IBM) and now is the time to try and limit new development and move to NEW paradigms. It reminds me a lot of what happened when IBM first introduced the CCCA product and did as a program offering rather than a program product. This sent a message to customers (or those in management that make buying decisions) and a good product was avoided by many shops. So tell, me how much will customers pay to not hear words but to SEE that COBOL is AS strategic as C/C++ and Java? I don't know, but I do know that IBM is (intentionally or not) sending a message to their customers that COBOL just doesn't rank as highly as other languages. 2) The second question has always been, give us a real world example of a business application that canNOT be done in 31-bit COBOL, but could be in 64-bit COBOL. With XML, GLOBs, BLOBs, etc this is starting to because more of a real world issue. However, again what I have heard from customers is that *IF* we wait to show you such examples and you THEN start developing a 64-bit COBOL, it will be WAY too late before you can deliver it. Again, we will simply have to move from COBOL to other languages (and won't ever return) while your are doing that development. 3) The final issue and this is certainly MY personal big issue is the one of mixed AMODE(31) and AMODE(64) applications. This is available today for Assembler (sort-of) but not for any LE application (at least in any supported way). I am not an AIX user, but it sounds as if the 64-bit COBOL for AIX is an all or nothing environment. If that is the case (at any time in the future) for COBOL on z/OS, then I agree, don't bother. *** Primarily, this note was intended to get that first message across (again) about the ranking of COBOL as perceived by customers given the delivery of 64-bit languages but not COBOL. I do (again personally) understand about resources (in IBM), priorities, and business cases. I just wish that I heard (or heard more often) from IBM that they understand what message they are sending out with their current PUBLIC responses to the 64-bit issue. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Utility for LE Options?
OOPS, my idea won't work. It is the CEEROPT module itself that you are trying to find what options are set. I do not know of a dis-assembler for a CEEROPT load module. -Original Message- From: Bill Klein [mailto:wmkl...@ix.netcom.com] Sent: Monday, January 19, 2009 6:44 PM To: IBM-MAIN (IBM-MAIN@BAMA.UA.EDU) Subject: Fw: Utility for LE Options? I don't know if this is what you are looking for, but at LE 1.9, you can A) create a CEEROPT stand-alone module with RPTOPTS(ON) (You may or may not want to modify MSGFILE as well) See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cee a2180/1.9.2 B) place the resuliting load module in in you IMS JCL and run the MPR C) check your output. It will show you what options are set in that region and where they are set. See for example, http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cee a1180/1.1.2.1 This will NOT tell you what the options are in sources that were overriden nor will it provide output that is already in macro format - but I think it should (might?) give you want you want. Adam Johanson adam.johan...@usaa.com wrote in message news:listserv%200901191506445185.0...@bama.ua.edu... It's for an IMS MPR. We're at z/OS 1.9. What I'd really like is for the utility to take the load module, and output the CEEXOPT macro, complete with options contained in the CEEROPT module. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Utility for LE Options?
Final thought (replying to myself, replying to myself G) Code a small program that CALLs CEE3DMP, that program's output will show you the run-time options in effect. -Original Message- From: Bill Klein [mailto:wmkl...@ix.netcom.com] Sent: Monday, January 19, 2009 6:53 PM To: IBM-MAIN (IBM-MAIN@BAMA.UA.EDU) Subject: Utility for LE Options? OOPS, my idea won't work. It is the CEEROPT module itself that you are trying to find what options are set. I do not know of a dis-assembler for a CEEROPT load module. -Original Message- From: Bill Klein [mailto:wmkl...@ix.netcom.com] Sent: Monday, January 19, 2009 6:44 PM To: IBM-MAIN (IBM-MAIN@BAMA.UA.EDU) Subject: Fw: Utility for LE Options? I don't know if this is what you are looking for, but at LE 1.9, you can A) create a CEEROPT stand-alone module with RPTOPTS(ON) (You may or may not want to modify MSGFILE as well) See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cee a2180/1.9.2 B) place the resuliting load module in in you IMS JCL and run the MPR C) check your output. It will show you what options are set in that region and where they are set. See for example, http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cee a1180/1.1.2.1 This will NOT tell you what the options are in sources that were overriden nor will it provide output that is already in macro format - but I think it should (might?) give you want you want. Adam Johanson adam.johan...@usaa.com wrote in message news:listserv%200901191506445185.0...@bama.ua.edu... It's for an IMS MPR. We're at z/OS 1.9. What I'd really like is for the utility to take the load module, and output the CEEXOPT macro, complete with options contained in the CEEROPT module. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Utility for LE Options?
I don't know if this is what you are looking for, but at LE 1.9, you can A) create a CEEROPT stand-alone module with RPTOPTS(ON) (You may or may not want to modify MSGFILE as well) See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea2180/1.9.2 B) place the resuliting load module in in you IMS JCL and run the MPR C) check your output. It will show you what options are set in that region and where they are set. See for example, http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea1180/1.1.2.1 This will NOT tell you what the options are in sources that were overriden nor will it provide output that is already in macro format - but I think it should (might?) give you want you want. Adam Johanson adam.johan...@usaa.com wrote in message news:listserv%200901191506445185.0...@bama.ua.edu... It's for an IMS MPR. We're at z/OS 1.9. What I'd really like is for the utility to take the load module, and output the CEEXOPT macro, complete with options contained in the CEEROPT module. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
AIX gets 64 bit COBOL but still none for Z/os ...
I understand your desire for 64-bit COBOL. I would suggest that if you WANT 64-bit COBOL, that you have your company submit a marketing requirement and reference SHARE requirement: SSLNGC0413607 Support 64 bit and web-oriented development in COBOL Unless you want a 64-bit COBOL that can't communicate with 31-bit COBOL, you might also want to submit marketing requirements that reference all of the following 3 SHARE requirements - SSLNGC0513631 LE - Phase 1 - Mixed 64/31-bit AMODE Toleration - SSLNGC0513632 LE - Phase 2 - Mixed 64/31-bit AMODE Cooperation - SSLNGC0513633 LE - Phase 3 - Full Mixed 64/31-bit Amode Support All 4 of these requirements are currently in the recognized response area. *** However, because you mentioned 1985 COBOL standard, you should know/understand that just as the '85 Standard would ALLOW for 2G+ tables, it would also consider a COBOL compiler that only supported 32K tables (as OS/VS COBOL did) to be conforming. It simply does not get into maximum/minimum issues for things like this. (Neither does the 2002 COBOL which is the only currently official COBOL Standard, now that the '85 Standard has been superseded) Thomas David Rivers riv...@dignus.com wrote in message news:200901141813.n0eidnyi008...@dave.dignus.com... Clark Morris cfmpub...@ns.sympatico.ca wrote: Dave Rivers wrote: Just to add a quick note to that, a popular option for our users is to write a quick-n-dirty C function to handle the 64-bit data (directly callable from 31-bit COBOL). Since there is NOTHING in the 1985 COBOL standard, let alone the 2002 standard that would prohibit having a 10 gigabyte table, why should someone have to program a work around in 2009? How long has the z series had 64 bit addressing? When did C/C++ get it? When did DB2 get it? If 64 bit is good and useful for Websphere and if Websphere is strategic, then why can't COBOL routines run in the 64 bit Websphere? Very good points I was just saying that, given realities - here's a work-around some people have found helpful. Of course, if we want to rail against realities - that's a different beastie all together :-) And, I can completely understand it :-) - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Some kind of hint!!!
In comp.lang.cobol when someone first comes into the world of migrating
(converting) COBOL created files, we usually point them to Michael Mattias
EXCELLENT web page at:
http://www.talsystems.com/tsihome_html/downloads/C2IEEE.htm
The bottom-line (as others in the thread have hinted at) is that it is
difficult (not impossible) to convert both numeric and character data in
one pass. If any of the numeric data is in other than display,
sign-is-separate format (Zoned Decimal in IBM mainframe speak) it becomes
more difficult.
There are lots of tools (none that I know of that are free) that can do
this, but the reason they are complex (and cost money) is that in the case
of records with mixed numeric (packed, binary, floating-point) and character
data, the conversion routine must be able to understand every record in
the file. In cases where all records have the same layout AND the records
are fixed length, then a simple COBOL program can be created to do this.
(The COBOL can run on the mainframe, on Linux, on Windows - wherever you
have a COBOL compiler).
In cases where there are variable length records and multiple record layouts
within the same file, then INTELLIGENT conversion is required. Each record
must be matched with its correct layout and character data must be
converted (EBCDIC - ASCII) and numeric data handled correctly
(big-/little-endian, IEEE vs HFP, packed-decimal sign-nibbles, etc).
***
The simplest universal solution (which is almost never possible G) is to
get whoever creates the file to define all numeric fields with the COBOL
USAGE DISPLAY SIGN IS LEADING SEPARATE
(and of course don't use any Unicode or DBCS character data)
When this is done a simple ASCII - EBCDIC conversion of the entire file
will solve everything.
When this can't/wont be done, then you MUST get the COBOL record layout or
layouts and depending on how complex they are, either create a one time
conversion program (in COBOL) or purchase a tool that will do it for you.
John McKown joa...@swbell.net wrote in message
news:listserv%200901141239054661.0...@bama.ua.edu...
On Wed, 14 Jan 2009 15:07:10 -0200, Carlos Bodra cbo...@terra.com.br
wrote:
Hi Listers, (xposted to VSE-L and OS/390 List)
I need to read an IBM 3490 cartridge recorded by OS/390 program in a
Linux system. If this works fine in intel server, I can migrate it to
Linux under mainframe later.
I have a 3490-E01 (scsi interface) connected to an IBM x236 system.
Until here no problem.
Tape has a record type of VB (126-1295) and some fields into record are
defined as PIC 9(xxx) comp-3. I got this from mainframe cobol program,
since today
I read it in our mainframe system, using a cobol program. (read tape and
write a pds file)
Since I´m no an expert in cobol or other programm language and in Linux
plataform, my questions are:
There is any open source software or not that can read this record and
resolve comp-3 fields?
I am not aware of any package which will do that, if this is what you
mean.
COMP-3 fields are packed decimal. It is rather easy to convert these
into
an integer. The number of bytes that are taken for a PIC S9(n) COMP-3
field
is (n+2)/2 and ignore the remainder. E.g. PIC S9(1) COMP-3 is 1 byte. PIC
S9(2) COMP-3 is 2 bytes, as is PIC S9(3). And so on. Now, if there is no S
in front of the 9, then the data is forced to be positive.
Some C code which can convert from COMP-3 to int:
int toint(unsigned char* packed, int digits) {
int bytes=(digits+2)1;
int n=bytes-1;
int i,j;
int result=0;
for (i=1;in;i++) {
result=100*j+10*(*packed1)+(*packed 0x0f);
packed++; /* examine next byte */
}
result=10*result+(*packed1);
i=*packed 0x0f;
if (i==11 || i==13) result=-result; /* negative sign */
return result;
}
If no software availalble, any one has a sample how to read this record
using any linux plataform language?
I've used Java to do something similar. I must assume that you already
know
how to read the file on tape. I don't know how to do that. But assume that
the variable tape is the open()'ed FILE *. You must read every record
yourself. This will be a bit complicated because the file is variable
blocked. That means that every physical tape record consists of a BDW
(Block
Descriptor Word), followed by one or more logical records. Each logical
record is prefixed with a RDW (Record Descriptor Word). My, this is
getting
complicated. The following C code should perhaps help. But I cannot test
it
(the same as the above).
#include stdio.h
#include string.h
#include stdlib.h
static char buffer[32768];
static int buf_off=32768;
static int block_length=0;
static int record_length=0;
size_t doread(char *record, FILE *tape) {
unsigned char bdw[2];
if (buf_off = block_length) {
block_read:;
fread(bdw,2,1,tape); /* read
Fw: COBOL and Floating Point (was: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
Clark, When you bring up Java, this confuses me. Currently IBM does all the required conversion for floating point items shared between COBOL and Java in a z/OS environment. Do you have real-world evidence that this does isn't working. *** As far as SHARE requirements go, Requirement SSLNGC0413617, ISO 2002 defined floating point data types from 2004 includes the following information, Again, it is important to state that not all of these reasons are valid for all SHARE installations; some installations would find one or more of these reasons compelling; while other installations would find only a single reason their motivation in setting the priority as it is. Finally, to avoid continuing confusion about whether or not this requirement is asking for IEEE floating point support, a separate requirement (SSLNGC0413621 That requirement currently has a response of RECOGNIZED (the lowest -non-REJECT response). the requirement SSLNGC0413621, COBOL (optional) support for IEEE Floating Point also has a response of RECOGNIZED. My assumption is that IBM is treating the older requirement as against the binary format as the newer requirement SSLNGC07005 COBOL support for Hardware decimal floating point already has an ACCEPT response. As currently written, I would *think* that it would be clear to IBM that this is asking for the ONLY format of IEEE floating point data that was available IN 2004. However, there is nothing in the requirement that actually says that it needs to be old-style binary IEEE floating-point and that the requirement would NOT be met by providing decimal floating point support. Clark Morris cfmpub...@ns.sympatico.ca wrote in message news:6tkem45k95u9c18tmoutc4o98cs772i...@4ax.com... On 7 Jan 2009 15:25:56 -0800, in bit.listserv.ibm-main you wrote: Clark, Easy answer, there have been no recent changes to IBM's responses on floating point (or bit) support. Harder answer is that you keep getting confused about different terms and requirements. In the '02 Standard there are 3 new USAGEs FLOAT-SHORT FLOAT-LONG FLOAT-EXTENDED IBM (or anyone else) *COULD* implement these as any format of floating point they wanted, e.g. FLOAT-SHORT *could* equal COMP-1 and both FLOAT-LONG and FLOAT-EXTENDED *could* equal COMP-2 There is no requirement in the Standard they be implemented in any IEEE format (or any other portable format). There isn't even any requirement that float-extended take more storage than float-long (but it can't be smaller). I understand that IBM could implement these usages as hex floating point. However, this would be short-sighted and shoot self in foot implementation. IBM COBOL already has the requirement to communicate with JAVA which uses IEEE binary floating point. Thus implementing the new usages as IEEE is upward compatible with existing programs and in fact allows them to have both types of floating point in a single program. *** OK, now for the terminology IEEE floating point. I think (but won't swear to it) that you are talking about the OLD (not decimal based) floating point format. Adding support for this would certainly aid in communication with other z/OS languages and facilities that already support this - as well as in handling files created in other environment. Exactly However, before you see that in COBOL, it would be my best guess that IBM is likely to implement the IEEE *decimal* floating-point formats already available in Assembler, PL/I, DB2 and possibly other z/OS languages/facilities. Not only does this seem to be a strategic direction for IBM, but it also provides a data-type that retains COBOL's historic interest in decimal arithmetic accuracy that can be lost in both the traditional IBM hex floating point and the older IEEE binary based floating point. Why not do both at the same time. I believe JAVA now has the decimal floating point and JAVA COBOL co-existence was strategic at one point. Maybe the requirements for implementing various of the 2002 standard features should updated to point to JAVA co-existence and IBM strategic directions. While the last time I touched COBOL was late 2006, I would be willing to update any of the requirements I submitted. I certainly do not know when this latter may show up, but I would expect it sooner than later. As far as the older IEEE support, I wouldn't be surprised if that NEVER shows up in COBOL (and I am not positive that there is a requirement that explicitly asks for it). I thought that I submitted one in the 2002 - 2004 time frame. Clark Morris cfmpub...@ns.sympatico.ca wrote in message news:ht7am41ddtc4r8c3cij01vdugok96c4...@4ax.com... On 6 Jan 2009 13:09:50 -0800, in bit.listserv.ibm-main you wrote: for zcobol initial release at SHARE. It doesn't test things like EXEC CICS or Enterprise COBOL extensions such as EXTENDED-FLOAT, but it sure looks like
AIX gets 64 bit COBOL but still none for Z/os ...
Denis Gäbler denisgaeb...@netscape.net wrote in message news:8cb40acc0589804-abc-...@webmail-dx19.sysops.aol.com... For video on demand databases are too slow. You would use a streaming server, for which I don't know any available for System z OS except VM Stairs. In addition, a streaming server would serve a stream, so you need a small buffer (e.g. 128MB) and fast DASD for 1000 Users. For the 64Bit discussion, as long as LE cannot mix 64Bit and 31Bit modules, what is the benefit? There are existing SHARE requirements for a 3 phased approach to mixed 31-/64-bit LE support 1) Document what actually works today (as Assembler can shift something needs to document what happens when both sides activate LE applications 2) SUPPORT fixed 31-/-64 but with separately owned LE resources on both sides 3) Full mixed mode application support *** As we haven't even seen phase 1 implemented yet, I don't know how soon I will expect phases 2 or 3. I am, however with you that providing 64-bit COBOL support for applications that are TOTALLY 64-bit and can't communicate easily/transparently with 31-bit code is a non-starter for real world use in z/OS COBOL shops. I suppose, I wouldn't object to seeing it, but if IBM used lack of interest/use of it to delay providing MIXED 31-/64-bit support, then I would definitely NOT be happy. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
COBOL and Floating Point (was: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
Clark, Easy answer, there have been no recent changes to IBM's responses on floating point (or bit) support. Harder answer is that you keep getting confused about different terms and requirements. In the '02 Standard there are 3 new USAGEs FLOAT-SHORT FLOAT-LONG FLOAT-EXTENDED IBM (or anyone else) *COULD* implement these as any format of floating point they wanted, e.g. FLOAT-SHORT *could* equal COMP-1 and both FLOAT-LONG and FLOAT-EXTENDED *could* equal COMP-2 There is no requirement in the Standard they be implemented in any IEEE format (or any other portable format). There isn't even any requirement that float-extended take more storage than float-long (but it can't be smaller). *** OK, now for the terminology IEEE floating point. I think (but won't swear to it) that you are talking about the OLD (not decimal based) floating point format. Adding support for this would certainly aid in communication with other z/OS languages and facilities that already support this - as well as in handling files created in other environment. However, before you see that in COBOL, it would be my best guess that IBM is likely to implement the IEEE *decimal* floating-point formats already available in Assembler, PL/I, DB2 and possibly other z/OS languages/facilities. Not only does this seem to be a strategic direction for IBM, but it also provides a data-type that retains COBOL's historic interest in decimal arithmetic accuracy that can be lost in both the traditional IBM hex floating point and the older IEEE binary based floating point. I certainly do not know when this latter may show up, but I would expect it sooner than later. As far as the older IEEE support, I wouldn't be surprised if that NEVER shows up in COBOL (and I am not positive that there is a requirement that explicitly asks for it). Clark Morris cfmpub...@ns.sympatico.ca wrote in message news:ht7am41ddtc4r8c3cij01vdugok96c4...@4ax.com... On 6 Jan 2009 13:09:50 -0800, in bit.listserv.ibm-main you wrote: for zcobol initial release at SHARE. It doesn't test things like EXEC CICS or Enterprise COBOL extensions such as EXTENDED-FLOAT, but it sure looks like There is no EXTENDED-FLOAT in Enterprise COBOL. There are floating-point data types, COMP-1, COMP-2, and external floating-point. There is a FLOAT-EXTENDED that is a part of the 2002 COBOL Standard that we have not yet implemented in Enterprise COBOL, maybe you are thinking of that? So what is the status of USAGE BIT and the other usages related to the 2002 standard for which there are existing SHARE requirements? Proper implementation of the standard floating point USAGEs (IEEE floating point) would allow COBOL to cleanly communicate with JAVA while leaving any existing COMP-1 and COMP-2 data as hex floating point. And is IBM COBOL going to support the decimal floating point that has been implemented at least on the z series and that was sponsored by IBM? Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Syncsort Oddity
Do you know how the original file was created? I would be interested if it was created by a COBOL program compiled with NOAWO. If so, you may want to make AWO an shop default (and/or non-modifiable COBOL compiler option) ??? ?? ??? gad...@malam.com wrote in message news:bba5d76fb046794fa7f01f8e02bfc17101d4d...@jer-mail1.jer.ad.malam.com.. . Hi Everyone, I ran the Histogram utility on both files: On the first file, the maximum block was a bit over 16k and most were about 2k. On the second file most of the blocks were over 25k. So it seems the Syncsort did some major reblocking which caused the savings in both space and access speed. The first file has 2,630,401 blocks. Average block size 1,340 The second file has 129,629 blocks. Average block size 27,115. That's a 95% reduction in block count. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Walt Farrell Sent: Thursday, January 01, 2009 3:09 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Syncsort Oddity On Wed, 31 Dec 2008 19:16:43 +, Ted MacNEIL eamacn...@yahoo.ca wrote: When using VB, some code will write a short block if the space remaining in the current block is less than the DCB LRECL, even though the actual length of the next record is unknown. This results in a lot of short blocks, particularly when the LRECL is large, as in this case. So, SYNCSORT 'repairs' this? Any properly written application should repair it, if I remember RECFM=V processing correctly. The LRECL value in the DCB tells you the maximum logical record length. If, when you go to write a logical record, the current data in the block + DCBLRECL is greater than the DCB block size, the access method will truncate the block. As I remember you're supposed to change DCBLRECL to reflect the actual size of the logical record you're about to write, and then the access method can properly fill the block. If you don't update DCBLRECL then if DCBLRECL is close to the blocksize (as it is in the OP's case) and significantly larger than the real LRECLs in the data set, then you could end up with a significant number of unexpectedly short blocks. Presumably SYNCSORT handles all this properly, and so you get optimal blocking, and take fewer tracks than a data set written with less than optimal blocking. Note that these are very old memories... And I know nothing about SYNCSORT. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IBM Debug Tool in pure batch
I haven't seen the actual problem code - but if it follows (normal) COBOL rules, there would be a difference between: LIST ALL (on two lines with no hyphen) versus LI -ST all (on two lines with a hyphen in column 7 of the continuation line). One uses the hyphen to continue in the middle of a word - but not when there is a space between two words. The rules for continued literals are even a little more complex (but well known to COBOL programmers) Jeff Holst jeff.ho...@fiserv.com wrote in message news:listserv%200901011829055896.0...@bama.ua.edu... I don't have specific experience with this, but when I look at an example in the user manual, I noticed that there is no hyphen on the continuations. In fact, I found elsewhere that the commands are free form and can start in column 1. A command is terminated by a semicolon ';'. I suspect that if you simply remove the hyphen, you will not get the errors. On Wed, 31 Dec 2008 17:41:52 -0800, Michael Bradley mjm...@yahoo.com wrote: I'm trying to use the IBM Debug Tool to list some data names during a Batch run, with the DT commands in INSPIN, and capturing the responses in INSPLOG. All is well, until I attempt to continue a command onto a second line. Since it's a COBOL program that's running, I start the command in 8, and attempt to continue the statement onto the next line by using a hyphen '-' in column 7 of the continuing line. DT's response is an objection to the second line. Does anyone have experience continuing commands onto another line in the input? Thanks Michael -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
The last that I heard (which was quite a while ago) if you tried using that product on z/OS, it could work with line sequential (HFS) files but *NOT* with normal QSAM files (and I am not even certain about VSAM KSDS or RRDS files). Kirk Wolf k...@dovetail.com wrote in message news:b2b367b60901011611r46c53193t12c0356a33485...@mail.gmail.com... A commercial Cobol compiler that targets Java byte codes have been available for a long time: http://www.legacyj.com/lgcyj_perc1.html As far as I can tell, it runs as pure Java byte codes and on z/OS and would therefore take advantage of zAAP. But, one should contact the company for details. Kirk Wolf Dovetailed Technologies -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
FW: Syncsort Oddity
This was supposed to go to the IBM-MAIN, not assembler list. Sorry about that. -Original Message- From: IBM Mainframe Assembler List [mailto:assembler-l...@listserv.uga.edu] On Behalf Of Bill Klein Sent: Wednesday, December 31, 2008 11:33 AM To: assembler-l...@listserv.uga.edu Subject: Fw: Syncsort Oddity If, for example, the original file were created by a COBOL program that was compiled with the NOAWO option (or the older OS/VS COBOL apply write only syntax), then it is QUITE possible that there are many short blocks in a VB file. When NOAWO is in effect for a COPY program, COBOL writes a block and starts a new one when the next record to be written COULD be large enough not to fit into the same block (if it were the maximum record size). With AWO in effect, COBOL actually waits to see how large the next record is an if it can it places it in the current block. Only if the ACTUAL next record won't fit in the existing block does the current block get written and a new block gets started. FOR COBOL programs that have a few very large records (such as header records) but mostly small records, the difference between AWO and NOAWO is SIGNIFICANT. I assume, but may be mistaken, that other types of applications besides COBOL NOAWO ones may have the same issue. Ted MacNEIL eamacn...@yahoo.ca wrote in message news:2016031228-1230735623-cardhu_decombobulator_blackberry.rim.net-1494412 2...@bxe348.bisx.prod.on.blackberry... I would look at the raw input file and see how it was blocked. Perhaps the program that created the file wrote smaller blocks. The OP did say they both had the same block size. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: IBM Debug Tool in pure batch
According to: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/eqa9ug00/5.1.4 It looks like you are doing this correctly. Assuming you are current on maintenance, I would report this to the IBM support center (and reference the documentation above). Michael Bradley mjm...@yahoo.com wrote in message news:809234.24313...@web50610.mail.re2.yahoo.com... I'm trying to use the IBM Debug Tool to list some data names during a Batch run, with the DT commands in INSPIN, and capturing the responses in INSPLOG. All is well, until I attempt to continue a command onto a second line. Since it's a COBOL program that's running, I start the command in 8, and attempt to continue the statement onto the next line by using a hyphen '-' in column 7 of the continuing line. DT's response is an objection to the second line. Does anyone have experience continuing commands onto another line in the input? Thanks Michael -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
COBOL question: Why can't we use RECORD CONTAINS 0 CHARACTERS for RECFM=V files?
Hopefully, you mean RECORD VARYING IN SIZE from 0 to 32767 depending on var-name I do NOT think you can use RECORD CONTAINS with the DEPENDING onphrase. John McKown joa...@swbell.net wrote in message news:listserv%20081217160815.1...@bama.ua.edu... I've always used: RECORD CONTAINS 0 TO 32767 CHARACTERS DEPENDING ON var-name and then define var-name in WORKING-STORAGE to be a 77 level with the PICTURE of S9(9) BINARY. -- John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
COBOL question: Why can't we use RECORD CONTAINS 0 CHARACTERS for RECFM=V files?
I am not positive of this, but I think you DO need the JCL override. If the hard coded maximum LRECL in the FD does NOT match the maximum for the physical file and you don't have the JCL override, I believe you will get a file status of 39 when you OPEN the file indicating a physical file attribute conflict. As indicated elsewhere in the thread, I recommend using the RECORD VARYING IN SIZE rather than RECORD CONTAINS form for the FD of a variable length file. (Among other things, this allows you to determine the actual record length after every read - without negative subscripting to get the LLZZ information from the RDW) FYI, There is an existing SHARE requirement for getting COBOL to (better) handle SMS information without worrying about coding FD stuff. Ted MacNEIL eamacn...@yahoo.ca wrote in message news:756912698-1229553371-cardhu_decombobulator_blackberry.rim.net-61158795 8...@bxe348.bisx.prod.on.blackberry... Do you mean just define the COBOL FD as RECORD CONTAINS 0 TO 32756 CHARACTERS and then use LRECL=32760 as a JCL override for a file no matter what it's variable max length is? I don't believe you need the JCL override. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Cobol and variable record length RRDS files
Use of the RECORD VARYING SIZE in the FD phrase is valid for ALL organizations of files and does return the record length during a READ. ??? ?? ??? [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED].. . Hi One of our users is writing a program that reads a variable record length RRDS file. He asked me if there is a way determine the actual record length of a particular record. Thanks Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/OS V1R10 COBOL
previous info snipped One thing that MIGHT be causing problems/issues for some sites, is the fact that Enterprise COBOL V4 does not have a full function version - as Enterprise COBOL V3 did. With V3, the full function version included Debug Tool (as did the PL/I product) With V4 of Enterprise COBOL (and the latest V3 release of PL/I) the Debug Tool must be ordered separately. HOPEFULLY (I don't do ordering, so I don't know), the ordering process will suggest an upgrade of Enterprise COBOL *and* the Deg Tool - if you had the Full Function version of Enterprise COBOL V3. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Access STIMER(M) from COBOL program?
If you are pre-1.9 then look on line for posts that reference ILBOWAT0 It does, require AMODE(24) but you can call an interface module to switch from a main AMODE(31) program to it. Farley, Peter x23353 [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]. .. NB: This function (and CEEDLYM for delay in milliseconds) are available at v1.9 and up only. Here we are at v1.8, so I don't have it yet (: HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John McKown Sent: Wednesday, November 12, 2008 2:25 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Access STIMER(M) from COBOL program? On Wed, 12 Nov 2008 13:20:37 -0600, Chase, John [EMAIL PROTECTED] wrote: Wonderful tool, Strobe. Snipped Is there a way within COBOL to set a timer to pop a second later, and have the program just WAIT on it? Or is this a potential opportunity for me to grind the rust off my atrophied Assembler skills and cobble up a delay routine the COBOL program could call? TIA, -jc- Try this: http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/CEEA3180/2.2.5.5 That is the entry of CEE3DLY, which can delay execution 0 to 3600 seconds. -- John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
COBOL compiler versions
A couple of MINOR comments 1) The latest version/release of Enterprise COBOL is V4R1. Personally, I can't think of any reason to go to V3R4 or lower. 2) Someone else has already pointed to the Migration Guide. I would certainly review it for information on upgrading from an earlier version to a newer one. 3) There have been a FEW new reserved words added to each release of COBOL. Therefore, it is POSSIBLE that older source code will not compile with newer releases; but this is quite unusual. 4) There is one MAJOR difference between IBM COBOL for OS/390 and whatever and Enterprise COBOL. As of Enterprise COBOL V3R1, support for the CMPR2 compiler option was removed. If you were using this for any of your older programs, then you will need to do some serious research. The differences between CMPR2 and NOCMPR2 behavior can be subtle and hard to detect. These issues are still discussed in the Migration Guide, so start there. 5) If you are a CICS shop, then you need to know what release of CICS you are using. There have been some problems with the COBOL2 and COBOL3 translator options. If you are current on CICS maintenance, this shouldn't be a problem. John McKown [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On Wed, 12 Nov 2008 11:59:31 -0500, Mueller, David [EMAIL PROTECTED] wrote: We are in the transition from z/OS-1.6 to z/OS-1.8 (I know we are behind). This also involves a transition from IGY.SIGYCOMP having the PP 5648-A25 IBM COBOL for OS/390 VM 2.2.1 compiler to it having the PP 5655-G53 IBM Enterprise COBOL for z/OS 3.4.1 compiler. Are COBOL for OS/390 and COBOL for z/OS essentially different versions of the same compiler (the same language standards level)? Or are they fundamentally different compilers (as COBOL for OS/390 was fundamentally different from VS-COBOL-II)? David Mueller | Systems Programmer They are basically the same. I.e. if it compiles with COBOL for OS/390, then it should still compile with no changes to source with COBOL for z/OS, and it should produce identical output from that program. The newer compiler just has new features. -- John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Efficient conversion of GMT to/from local time from COBOL?
There have been lots of replies referencing the LE callable date routines. Depending upon what type of date you are looking for, these may well be your best answer. HOWEVER, If all you want to do is know what the offset is from GMT of where your application is running, then you can easily just use native COBOL. See the CURRENT-DATE intrinsic function at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR31/7.1.15 Positions 17-21 will give you the exact offset from GMT. Unless your application is running in one of the time zones with 15 or 30 minute offsets from GMT, then converting from/to GMT becomes trivial without resorting to an LE callable service (much less a C or Assembler subroutine). If you are working with arbitrary times (not the current time) in odd or arbitrary formats, then the LE callable services are probably better and more flexible. Farley, Peter x23353 [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]. .. Hi all, A question has been asked of me to which I think I know the answer, but not how (in)efficient it would be: Is there a z/OS-supplied function to convert GMT to local time (or back again)? Now, I don't yet know in what format the GMT is arriving for conversion, but it is very likely NOT in STCK(E) format but rather in some external character format. I know I can write a small C routine to convert character format GMT to time.h format and then use localtime(clock) to perform the conversion from GMT to local time, or gmtime(clock) to go the other way. BUT the question is, when called from COBOL will that small C routine set up and tear down the C environment every time it's called? If so, is there a way to make those calls to a C function from COBOL more efficient? Or am I barking up the wrong tree because there's another/better/simpler way to do this conversion? Obviously I could also write assembler to convert the character format GMT to STCK(E) format with CONVTOD and then use the CVT fields to convert that value to local time and then STCKCONV to go back to character format, but I am hoping there is a simpler HLL-based solution. TIA for any help/info/RTFM you can provide. Environment is Enterprise COBOL 3.4, z/OS 1.8 if it matters. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
DFSORT PARSE question
John, I don't have a solution for you (Other than, of course, how easy this would be to do in COBOL G If you need a SORT and a report, COBOL internal SORT with Report Writer would do this for you easily), but ... Are you certain you don't have any John Smith, Jr or Mary Brown, III type entries in your input? John McKown [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... I don't see a way to do this, but I'll ask. I have a field in a record which is a person's name. It is rather free format and may contain one or more names, separated by one or more blanks. By our definition, the person's last name is the last non-blank series of characters in this field. The field is a max of 20 characters (it is the Programmer Name Field in RACF). So for John McKown, I want McKown. For William S. Story, I want Story. For A. B. D. Burp, I want Burp. So far, I've gotten all my RACF reporting from the IRRDBU00 unload done using DFSORT's ICETOOL. But this one seems to be killing me. Any ideas? -- John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
copybook usage
You don't say what programming language (much less what release/version of a compiler) you are using. If you are talking about COBOL, it is entirely possible to put as much or as little as you might want - from either the Data Division *OR* the Procedure Division. If fact, if it is distinct set of logic that you want to share, you can create a NESTED PROGRAM to do the logic - and include the entire nested program as a copy member. Otherwise, you can use Paragraphs, Sections, or just multiple lines of logic as a copy member. If this isn't what you are asking about, please further explain your question. Ron Thomas [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hi, We have a requirement to create a online cics program and a batch program. The program is used to create a user account by inputting the values thru the online screen and also needs a batch program that does the same funcationality , the input is supplied in a flat file. The customer wants the core logic to be in a copybook. To my knowledge only we can use database operations to be put in the common copy book. could some one please let me know is there any other things we can incorporate in the copybbok so that the batch and online can use the same. Thanks, Rajeev V -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
C03 abend when omitting CEE.SCEERUN from JCL
previous notes snipped With all the posts, I don't know if anyone has actually posted the references for the full discussion on this topic in existing Migration Guides. If you previously used the OS/VS COBOL run-time library, please read: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3mg40/3.2.4 If you previously used the VS COBOL II run-time library, please read http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3mg40/3.3.4 As I *think* that previous notes from the OP indicated that the application had the following flow to it: Enterprise COBOL - Assembler - OS/VS COBOL and I still haven't heard whether the Assembler is LE enabled or not and exactly HOW the Assembler calls (loads? whatever?) the OS/VS COBOL program, then you should also read http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3mg40/APPENDIX1.4.2 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Cobol reference
Howard, I don't know what release you want, but I tend to keep bunches of them. Most recent - Enterprise COBOL V4R1 http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/Shelves/igy3sh40 Last Version 3 URL http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/IGY3SH33 These are BookManager versions. If you WANT PDF versions, I have some of those too and can post them as well Howard Brazee [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... I gave a new programmer my list of CoBOL reference URLS, such as http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/IGYLR205/CCONTENTS , but these no longer work. I did some searches from the page that came up. Where can I find the CoBOL language guide and user manual? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
C03 abend when omitting CEE.SCEERUN from JCL
When you say 1 VS COBOL program Do you mean VS COBOL II or OS/VS COBOL? If it is OS/VS COBOL, then this may WELL be part of the problem. However, for either VS COBOL II or OS/VS COBOL, was the program compiled with RES or NORES? (You can use COBANAL or Edge Portfolio to find this out). If you have ANY NORES program mixed in with an Enterprise COBOL application, you are into the wonderful world of MIXRES and things can get VERY funny. I can (relatively) easily imagine that this may well lead to problems with different locations for SCEERUN. If your VS COBOL (OS/VS COBOL or VS COBOL II) program is compiled with NORES, then I suggest recompiling with RES and seeing if this fixes the problem. Mürsel Ta#351;g#305;n [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hi, It is a DB2 Cobol program and make calls to other programs compiled with ASM, Enterprise Cobol and 1 VS Cobol program. We think that there is a problem with the program (ie. Not closing datasets properly etc.) But we cannot understand why does it work with CEE.SCEERUN in JOBLIB and doesn't work when it needs to call it from LNKLST. Thanks and regards. Mürsel Tasgin BT Sistem Yönetimi Yönetici Yardimcisi Akbank Genel Müdürlügü Sabanci Center 34330, Istanbul Tel: + 90 212 385 53 85 Faks: +90 212 282 62 76 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Friday, October 17, 2008 7:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: C03 abend when omitting CEE.SCEERUN from JCL On Fri, 17 Oct 2008 11:04:51 -0500, Chase, John [EMAIL PROTECTED] wrote: When we remove CEE.SCEERUN joblib statement from the JCL, the job abends with C03: IKJ56641I SYSTEM ABEND CODE C03 REASON CODE 0004 Note the message ID: It's a TSO message. Leads me to believe more needs to be known about just how the program is invoked. Seems that it's not via normal batch JCL; i.e., it's not via //STEPNAME EXEC PGM=COBOLPGM -jc- Perhaps its a DB2 COBOL program. But that shouldn't matter. It should run without the JOBLIB all things being equal. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Bu e-posta ve muhtemel eklerinde verilen bilgiler kisiye özel ve gizli olup, yalnizca mesajda belirlenen alici ile ilgilidir.Size yanlislikla ulasmissa lütfen göndericiye bilgi veriniz, mesaji siliniz ve içerigini baska bir kisiye açiklamayiniz, herhangi bir ortama kopyalamayiniz. Bu mesaj aksi sözlesme ile belirtilmedikçe herhangi bir finansal islem teklifi, alimi, satimi veya herhangi bir havalenin teyidi gibi bankacilik islemi yapilmasi amacini tasimamaktadir.Verilen tüm bilgilerin dogrulugu ve bütünlügünün garantisi verilmemekte olup, önceden bildirilmeksizin degistirilebilecektir.Bu mesajin içerigi Bankamizin resmi görüslerini yansitmayabileceginden Akbank T.A.S. hiçbir hukuki sorumlulugu kabul etmez. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
C03 abend when omiting CEE.SCEERUN from JCL
I don't know if this will help or not, but can you tell us: A) is the (dynamically called subprogram in) Assembler is LE-conforming or not? B) Do you have any other COBOL (older) run-times in the steplib or the joblib of the program? C) Does anything in the C03 output tell you which dataset was NOT closed at the time of the ABEND? D) Probably not relevant. As soneone mentioned, you are getting an IKJ message. Is this a DB2 program? Mürsel Tasgin (BT Isletim ve Teknik Destek Bölümü) [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hi, We have a problem about CEE.SCEERUN usage. This LE dataset is in LINKLIST and all users are able to use it. However a batch program, which is compiled in Enterprise Cobol (V3.2) and make dynamic calls to ASM programs needs CEE.SCEERUN dataset coded inside JCL (via joblib). When we remove CEE.SCEERUN joblib statement from the JCL, the job abends with C03: IKJ56641I SYSTEM ABEND CODE C03 REASON CODE 0004 We cannot figure out, why program cannot call modules of CEE.SCEERUN from LNKLST and needs it inside JCL(via joblib). Anyone experienced same problem? Thanks and regards. Mürsel Tasgin Akbank Bu e-posta ve muhtemel eklerinde verilen bilgiler kisiye özel ve gizli olup, yalnizca mesajda belirlenen alici ile ilgilidir.Size yanlislikla ulasmissa lütfen göndericiye bilgi veriniz, mesaji siliniz ve içerigini baska bir kisiye açiklamayiniz, herhangi bir ortama kopyalamayiniz. Bu mesaj aksi sözlesme ile belirtilmedikçe herhangi bir finansal islem teklifi, alimi, satimi veya herhangi bir havalenin teyidi gibi bankacilik islemi yapilmasi amacini tasimamaktadir.Verilen tüm bilgilerin dogrulugu ve bütünlügünün garantisi verilmemekte olup, önceden bildirilmeksizin degistirilebilecektir.Bu mesajin içerigi Bankamizin resmi görüslerini yansitmayabileceginden Akbank T.A.S. hiçbir hukuki sorumlulugu kabul etmez. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: COBOL abbreviated IF message IGYPS2048-S
I agree that this is probably a compiler error. Or at least disagrees with the documentation. According to: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/IGY3LR40/6.1.6.14 and http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/IGY3LR40/6.1.6.14.1 and http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/IGY3LR40/6.1.5 You have correctly used parentheses and done every thing needed for relational expressions (including arithmetic expressions within relational conditions). Please do let us know what IBM says P.S. The format of your expression is the correct format of: If data-name-1 = (literal-1 or Literal-2) And (arithmetic-expression-1) 0 (or if you use the changed final parenthesis it is) If data-name-1 = (literal-1 or Literal-2) And (arithmetic-expression-1 0) both are legal COBOL and should be accepted by the compiler. Greg Shirey [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Thanks for the experiment, Peter. I will open an ETR with IBM and let them settle the issue. I agree with your sentiments about maintainability, and have suggested such to our QA folks. Greg -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter x23353 Sent: Monday, October 13, 2008 2:52 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL abbreviated IF message IGYPS2048-S Greg, I have to agree with your programmer, at least about whether it used to work or not. We're at Enterprise 3.4 here, and the programmer's original version of the code compiles clean and generates the correct object code. Here's a copy of the pseudo-assembly listing of the programmer's original code as compiled by Enterprise 3.4, edited to fit email width: 27 IF 00090A 5830 912C L 3,300(0,9) BLW=0 00090E 4820 3098 LH2,152(0,3) SUB 000912 4C20 A0A4 MH2,164(0,10) PGMLIT AT +40 000916 1A23AR2,3 000918 95E7 2129 CLI 297(2),X'E7'WC-FUNC() 00091C 58B0 C020 L 11,32(0,12) PBL=1 000920 4780 B158 BC8,344(0,11) GN=6(00092C) 000924 95E9 2129 CLI 297(2),X'E9'WC-FUNC() 000928 4770 B16E BC7,366(0,11) GN=5(000942) 00092C GN=6 EQU * 00092C F8F6 D2B0 212A ZAP 688(16,13),298(7,2) TS1=0 WC-AMTUSE() 000932 FA76 D2B8 2131 AP696(8,13),305(7,2) TS1=8 WC-AMT-PENDING() 000938 F971 D2B8 C010 CP696(8,13),16(2,12) TS1=8 SYSLIT AT +16 29 GO 00093E 4740 B402 BC4,1026(0,11) G100-FIND-CREDIT-X As you can see, the 3.4 compiler interpreted that COBOL syntax just the way the programmer intended. AFAICS, there was nothing *technically* wrong with the programmer's original code, though I would not have coded it that way. He used a perfectly readable abbreviated IF, though I avoid them if I can in my own coding. For clarity and maintainability, I tend to use full parentheses for IF conditions so that my intentions are clear to future maintainers. My version of your programmer's code would have looked like this: IF (WC-FUNC (SUB) = (X OR Z)) AND ((WC-AMTUSE (SUB) + WC-AMT-PENDING (SUB)) 0) GO TO G100-FIND-CREDIT-X END-IF. Some programmers find that style annoying. I try to think of the maintainer rather than myself. HTH Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
GOBACK vs EXEC CICS RETURN
I think what you are looking for is at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dfhp3c00/1.3.4.1 I am not positive that this matches my memory but what it shows there is that BOTH EXEC CICS RETURN and GoBack are valid from a COBOL subprogram entered via EXEC CICS LINK or Dynamic CALL. However, what level they go back to depends Bartosz R [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On 13 Sie, 15:44, Kevin Wailes [EMAIL PROTECTED] wrote: On 13 Aug, 07:31, Bartosz R [EMAIL PROTECTED] wrote: Hi all, does anyone know whether or not it is allowed to GOBACK from a COBOL program that was EXEC CICS LINKed? Are there any repercussions of this? The IBM manual for the CICS TS 3.1 says: Return from subprogram LINK The linked subprogram must return using either RETURN or a native language return command such as the COBOL statement GOBACK. If I read it correctly there is no difference, whether I issue the EXEC CICS RETURN or GOBACK. Is that true? How about the CICS logical level, which is supposed to be increased by LINK and decreased by RETURN? Thanks in advance You can use either but what happens depends on how your subprogram is invoked. There's a fairly comprehensive description in the Infocentre : http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=...- Ukryj cytowany tekst - Well, that's what I though also. But the aforementioned sentence states that even when you LINK a program you can ISSUE a GOBACK instead of EXEC CICS RETURN (which IMHO is not true). The sentence I quoted comes from exactly that infocenter article. Can anyone help? Should I just experiment with this? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Enterprise COBOL v3.4.1 run time issue
As others have indicated, I (mostly) doubt that the READ (rather than READ INTO) is doing ANY manipulation of data. The one possible exception is if you have the 01-level under the FD defined as a numeric or edited field - and even then, I doubt that conversion takes place. (The other exception is READING ASCII tape files, but that doesn't sound like this case). Can you tell us/show us exactly how the FD and subsequent 01-level are defined? If you do that, we may be able to tell you what is happening (and why). If the 01-level is actually a group item or you find that the READ is NOT doing conversions but the READ INTO is, then let us know what the 01-level under the FD and the receiving (INTO) field look like). K Zafirop [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hi all, One of our most curious programmers noticed that when he uses READ or READ INTO statement to parse alphanumeric data, a translation is made. The value passed is the arithmetic truncation of the string. For example a string 'FOW123' is passed with value '666123'. As you can see X'F1' = C6D6E6F1F2F3. The truncation made before assigning the value to an element so, using DTR instead of DTR has no effect. Do you think this is a compiler or LE issue? Thank you in advance K. Zafiropoulos EFG EUROBANK z/OS junior System Programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Abend0C1 while calling an IBM-Cobol routine from OS/BS Cobol Main.
The real question/issue is whether there is any OTHER set of COBOL routines available in STEPLIB, Linklist, LPA, whatever. If *only * the LE library is available and the correct re-linking of the OS/VS COBOL NORES program was done (with the LE library), then no OC1 should occur. See: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3mg40/3.4.1 Hal Merritt [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... LE and such are not appropriate for STEPLIB. In fact, having such a concatenation opens the door for mixed levels. I believe it is strongly recommended that one and only one level of LE be available in any form in a given environment (LPAR). Reason is that IMS, COBOL, LE and such don't necessarily search the STEPLIB first, or even at all. Yes, I know what the JCL manual says. Same goes for link list: don't mix. HTH and good luck. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rich Tabor Sent: Wednesday, August 13, 2008 11:43 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Abend0C1 while calling an IBM-Cobol routine from OS/BS Cobol Main. Any chance you don't have the newer LE runtime library first in your steplib concatenation? On Wed, Aug 13, 2008 at 7:43 AM, Itschak Mugzach [EMAIL PROTECTED] wrote: I am running a n IMS MPP transaction written in OS/VS Cobol and is statically binded. The main program calls a routine compiled in Cobol for VM and MVS. The binder output marks IGZETUN and IGZEOPT as weak external references. When the Cobol routine gets control, module IGZCBSO abends with S0C1, failng to create a new Cobol environment. It look like that the CEESTART module (I think it is a kind of branch table) doesn't hold all addresses. I know that IGZETUN IGZEOPT are not supported under LE, but how come LE holds V constants to those modules? Please advise. Regards, Itschak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Cobol on Tandem platforms
I would think that posting this in comp.lang.cobol MIGHT bet a better answer than in IBM-MAIN J. Chiampi [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hello, I have several questions about Cobol programs running on the Tandem platform. - What is the difference between SCOBOL and NonStop Cobol? - Do both are compliant with the ANSI 85 standard? - What are the main characteristics of Screen Cobol? - Why using it rather than NonStop Cobol? - Is it possible to call a Cobol program from a TAL program? And my last question is: - Is there a control language like JCL on zOS platforms? Thank you in advance. Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
C/C++ malloc() memory allocation
I just did a search of the LE 2.10 bookshelf at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/CEE1BK32 for malloc csa or malloc ecsa and found no hits. Betsy, Can you point me to the (LE) manual that you think said this? (I also searched the current V1.9 manuals and they also don't have any hits). Betsy Jeffery [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... I see, the LE manual I read it in was lying. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
CEE3703I In HANC Control Block, the Eye Catcher is damaged.
It sounds like time to compile and run with SSRANGE turned on. This should (easily?) catch the problem. Schneiderwent, Craig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... You can have VS COBOL II modules linked with VS COBOL II and still run them without VS COBOL II run-time library, you can run them with LE library. We have only LE in the DFHRPL. Using ISRDDN I searched the Linklist/LPA concatenation for IGZ* modules and they are only found in hlq.CEE.SCEERUN and hlq.CEE.SCEERUN2. We appear to be in the category you describe. My thanks to those who replied here and on CICS-L, there doesn't appear to be anything (explicitly listed as that won't work) wrong with the construction of the module itself. And I see the abstract for John Monti's Orlando SHARE presentation 8209 Heaps of fun with LE Heaps says Have you seen a CEE0802C message saying your LE Heap control information was damaged? Well this session is for you. These problems are most often caused by application overlays. The speaker will guide you through the LE Heaps in a fun and interesting way to help you learn techniques and LE run-time options which can assist with finding the source of these problems. Lo, and behold, just a bit after the CEE3703I message in the subject line of this thread there is a CEE0802C Heap storage control information was damaged. message. So I now have something to read and point the apps people at. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Decimal Floating Point, was: replacing SAS for SMF reports?
Rick, yes and no ... With the current PL/I compiler and with the DECIMAL(DFP) compiler option in effect, then FLOAT DECIMAL does mean DFP. See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ibm3pg60/1.1.1.28 With earlier versions of the Pl/I compiler (or lower ARCH levels) this is NOT true. Rick Fochtman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... --snip- I see what I did, whenever people talk about 'new floating point' I always assume it is Decimal Floating Point (the one that is not available in Java yet, or COBOL for that matter. z9 and PL/I and have it) To make it more confusing both the Java binary float and the newer DFP are both IEEE floating point! ---unsnip Don't confuse PL/1's FLOAT DECIMAL specification with the hardware floating point decimal feature. They are NOT the same! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
insane request: force load module to RMODE(24) AMODE(24)
There is ABSOLUTELY no way that you will get an Enterprise COBOL CICS program to work if it is marked as AMODE(24). All the IGY and CEE routines that it will need to run will have problems. You could get an RMODE program, but that isn't what you are asking for. If the programmer wants to force RMODE(24), then use the PROCESS RMODE(24) statement as the first line of the source code. This should This should work unless your compiler was installed with NOALLOWCBL How does the COBOL program access the HLASM program (or vice versa), EXEC CICS LINK? CALL literal or CALL identifier. Depending on the type of ILC has the responsible programmer read what IBM has to say about these. McKown, John [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... We have a problem. We have a very old CICS application which is written in HLASM and OS/VS COBOL 2.4. We want to convert the COBOL to Enterprise COBOL. We have having many problems due mainly to lack of knowledge about the code base. The programmer doing this is convinced that a/the major problem is that Enterprise COBOL links as AMODE(31). He wants to force the load module to AMODE(24). The only way that I can see to do this is via the AMODE(24) parm in the Binder. However, we use CA-Endevor for our program compiles and links. This means that we need a separate Endevor processor which invokes the binder with the AMODE(24) parm. Any ideas about another way to do this which would not require a new Endevor processor? I don't know a lot about Endevor, but I don't see a way to use the Binder's MODE command. And I don't know if this would be easier to implement in Endevor than the PARM. P.S. I am not as convinced as the programmer that the problems he is encountering are due to the AMODE. But he is insistant and has the political backing to force the issue. The only way to prove otherwise to allow him to do his work in AMODE(24) and see if he still has the same problems. He has already done a lot of figure out this for me type requests to Tech Services. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: insane request: force load module to RMODE(24) AMODE(24)
If it was originally compiled with DYNAM, it wouldn't work with CICS any way. It must already be NODYNAM. NODYNAM doesn't force AMDOE(24) unless an AMDOE(24) program is statically linked-in. John P Kalinich [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... John McKown of the IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 06/17/2008 08:52:32 AM: We have a problem. We have a very old CICS application which is written in HLASM and OS/VS COBOL 2.4. We want to convert the COBOL to Enterprise COBOL. We have having many problems due mainly to lack of knowledge about the code base. The programmer doing this is convinced that a/the major problem is that Enterprise COBOL links as AMODE(31). He wants to force the load module to AMODE(24). The only way that I can see to do this is via the AMODE(24) parm in the Binder. Compile with the NODYNAM option and you will get AMODE(24). Regards, John K -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
insane request: force load module to RMODE(24) AMODE(24)
I just wanted to CORRECT the erroneous statement that I made below. If an Enterprise COBOL program is statically link-edited with an AMODE(24) program, it will of course be marked as AMODE(24) - and will work that way. It still is NOT what I would recommend in this situation, but I did want to correct what I said before others worried about it. Bill Klein [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... There is ABSOLUTELY no way that you will get an Enterprise COBOL CICS program to work if it is marked as AMODE(24). All the IGY and CEE routines that it will need to run will have problems. You could get an RMODE program, but that isn't what you are asking for. If the programmer wants to force RMODE(24), then use the PROCESS RMODE(24) statement as the first line of the source code. This should This should work unless your compiler was installed with NOALLOWCBL How does the COBOL program access the HLASM program (or vice versa), EXEC CICS LINK? CALL literal or CALL identifier. Depending on the type of ILC has the responsible programmer read what IBM has to say about these. McKown, John [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... We have a problem. We have a very old CICS application which is written in HLASM and OS/VS COBOL 2.4. We want to convert the COBOL to Enterprise COBOL. We have having many problems due mainly to lack of knowledge about the code base. The programmer doing this is convinced that a/the major problem is that Enterprise COBOL links as AMODE(31). He wants to force the load module to AMODE(24). The only way that I can see to do this is via the AMODE(24) parm in the Binder. However, we use CA-Endevor for our program compiles and links. This means that we need a separate Endevor processor which invokes the binder with the AMODE(24) parm. Any ideas about another way to do this which would not require a new Endevor processor? I don't know a lot about Endevor, but I don't see a way to use the Binder's MODE command. And I don't know if this would be easier to implement in Endevor than the PARM. P.S. I am not as convinced as the programmer that the problems he is encountering are due to the AMODE. But he is insistant and has the political backing to force the issue. The only way to prove otherwise to allow him to do his work in AMODE(24) and see if he still has the same problems. He has already done a lot of figure out this for me type requests to Tech Services. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
FW: RDz
OK, I have looked at: http://www-306.ibm.com/software/awdtools/developer/application/features/inde x.html?S_CMP=wspace What possible use or relevance does RAD have for someone trying to do COBOL/CICS development on the PC? It looks like it is totally Java oriented. It doesn't have the COBOL, PL/I, or CICS elements of RDz. It might (or might not) be of interest to some, but certainly NOT to those trying to do COBOL (or PL/I) development on a workstation - whether targeted for Windows or z/OS. Timothy Sipples [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]. .. RDz is a perfect superset of Rational Application Developer (RAD). Anything you can do in RAD you can do in RDz. So please be sure to include the RAD publications and collateral as you survey the documentation landscape. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
RDz
Both officially and unofficially, MANY people have communicated to IBM that WSED, then WDz, then RDz are VERY poorly documented or marketed to those doing mainframe (or PC) development for the mainframe (or PC) but WITHOUT a z/OS connection. NOT speaking for IBM, it appears that the IBM internal business case is for this product (line) to be for sites with mainframes and mainframe connections. Everyone (that I have ever talked to) says it CAN be used for PC stand-alone development (for PC apps) or for mainframe apps - but that simply is NOT the target audience. You need to be aware that this is NOT just a marketing documentation issue. You will find the same problem (issue?) once you get the actual product documentation. Graham Hobbs [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Brian, Will contact you offline. Thanks. But while I'm online I will put out a small plea to IBM - all the websites about RDz are totally oriented to the big guns, the monied shops, the 'HOST'. Well I don't have a HOST. I'd really like to see just one site that deals with the guy who wants to run with the likes of RDz but just on a PC - what I would get for the $800, how much like my old mainframe world can I recreate. I like that stuff, I know it, am retired and I'd sure like to pursue some ideas. The likes of VB, Java, .Net etc don't yet cut it for me, one day probably, but right now give me Cobol and CICS and I'll do stuff. Same goes for MF, and who else? Peev done. Graham - Original Message - From: Brian Westerman [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, June 09, 2008 12:47 AM Subject: Re: RDz Hi, If you send me your address off line, I'll download the RDz files for the trial and send them to you. I have a T1, so it will only take a very short amount of time to download. I can DHL them to you and you can have them the next day, or USPS Priority Mail in 2 days. The files in total appear to be about 6.98GB so they will fit on one Double layer DVD or two regular ones, whichever you prefer. Do you have access to a mainframe (or z/os under Hercules) to be able to install the operating system side of things? Also, you can access a DB/2 platform (if you have one), and you do have access via file manager to VSAM files as well, I had to look at the product specs to be sure. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
RDz
Graham, Given the recent discussions on advertizing and the fact that I *used* to (a decade ago) work for a 3rd party, what I would like to say, is hard for me to phrase politically correctly. First, let me say that from what I have heard RDz would do what you want - but DOES require an upgrade to your laptop. If you get to the stage that you either upgrade or have access to a private computer for the 60 day trial, it sure sounds worth it. Having said that, there are 3rd party solutions that I think would do what you want on your current laptop. Like RDz, they aren't cheap. However, they do have COBOL and CICS (IBM mainframe compatible) solutions - and certainly do share the same VSAM-like files. If it is needed, S/390 Assembler is also available. If you would like me to be less obscure and if no one else jumps in with web page references or product names, please feel free to contact me off-list. wmklein at ix.netcom.com (trials of 3rd party products are also often available) P.S. It is my impression that it is NOT the Eclipse IDE (alone) cause the memory needs of RDz). Graham Hobbs [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hello Brian, Again thanks for the info - you seem to be well aware of this RDz so I'll try my luck again. I don't expect RDz to create VSAM KSDS files for me. My old COBOL/CICS came with Pervasive's bTrieve into which I fed sequential files and out came emulated VSAM KSDS's and my COBOL/CICS programs successfully accessed them. Am hoping to hear that RDz does something like this . . I thought I had read (but can't find now) that there was a VSAM File Manager 'thing'. Is clear that with PC DB2 V9 such access is possible. Might you know about this? I am at my cottage for the next three months, 1000km from my home, high speed access and the retailer who sells me laptops from time to time (. . and there if troubles). So getting another laptop with the kind of capabilities you suggest is not that simple. Dialup speed at the cottage also probibits much. So a) having an appropriate computer, b) being able to download the 60 day trial are problems. The local one room library has a Vista Compaq with .5 meg of RAM - they will find your comments about RAM/Vista/speed very interesting. It has 'high-speed' capability via what I don't know yet. But when I tried to download OpenOffice the time window said it would take three hours. I called my retailer and he said it should be 3-10 minutes! So this is their 'high-speed' - am looking into it. What's crossing my mind is a) make sure RDz does what I want, b) buy the CD media pack, c) load in onto my average PC, d) plan on not using the IDE (guessing this to be the hog and not why I need RDz), e) build the permanent solution when I get home. Did I burden you or what:-))). Have you got RDz on a PC? Many thanks Graham - Original Message - From: Brian Westerman [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Friday, June 06, 2008 8:41 PM Subject: Re: RDz Hi, You can use it to build applications that access VSAM, but I don't think it generates VSAM files on your PC if that's what you are asking. There is a debugger, and it's pretty nice. I do agree that you don't want to be running this on a old Pentium 3 or 4, you should have at least a Dual Core PC (or laptop), with a minimum of 2GB of memory, (if you're running Vista, get 4GB), memory is very cheap (if you have the free slots), and places like BUY.COM and OUTPOST.COM (as well as many others) have sales almost every other week for 2GB at about $50 or less, so loading up is cheap, but if you have Win/XP then more than 2GB is just a waste. You are correct in the the $800 is for the entire catalog, (hundreds of programs), for the full year, but it's only a good deal if you can use them. I still urge you to do the 60 day trial first to make sure it's going to work for you, the Value Option upgrade option only takes a day or two to apply for and get, and if you can't tell if it will work for you in the first 30 pr 40 days then you probably don't need what it can offer anyway. Let me know if I can help you. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Rational Developer for System z
From other notes, it looks like the SCLM problem may NOT be a real problem, HOWEVER, I did want to remind any/all SHARE members who either have RDz or are evaluating it, that the LNGC project of SHARE is now accepting (and processing) SHARE requirements against RDz. Please, if you are a SHARE member and have enhancement suggestions (or even bug fixes - for things working as MIS-designed) please submit requirements in the LNGC project to bring these to IBM's attention. James Robinson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Graham: We have installed and are currently testing r/DZ. There are a couple of things that you should know: 1) The mainframe COBOL piece of r/DZ *requires* SCLM to function. If you are one of the four or five shops that actually use SCLM, this won't be a problem. It has been a major pain for us, however. SCLM is convoluted, poorly documented, difficult to set up, and counterintuitve. Not to mention, the ancillary products that make SCLM functional are quite expensive. 2) If you use CICS BMS exclusively, then r/DZ will be fine. If, however (as we do), you use SDF2 to create your CICS screens, you will have problems, because, despite SDF2 being an IBM product, there is absolutely no interface between SDF2 and r/DZ. Each SDF2 map has to be hand-corrected to BMS format before it will be accepted by r/DZ. I leave the associated programming nightmares to your imaginations. That being said, the PC tool itself is slick, and has a lot of nice features for developers. Just don't think that you are getting a bargain, because you are not. James -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Graham Hobbs Sent: Tuesday, June 03, 2008 9:54 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Rational Developer for System z Hello, Acronyms first: WDz = Websphere Developer for System z V7.0 RDz = Rational Developer for System z V7.1 According to an IBM website 'With this new release WDz has been renamed to RDz'. Have been out of the mainframe field (any field that is) for several years now, looking to 'acquire' RDz for a laptop without host connection (at least not for a while) for small development purposes - can't let go:-). Am specifically interested in the COBOL compiler, CICS (whatever it's called these days), CTG, VSAM emulator, DB2 and the current debugger. Not really sure about the IDE or other stuff that seems to go with the package (although David Crayford gave me some clues - thanks - which 10%?). So WDz 7.0 + 1 Version = RDz V7.1 BUT am not sure of the exact differences in the releases (many pages of specs, am working on it). RDz goes for about US$6500. WDz can be had (it seems) via Partnerworld under a thing called IBM Software Access for 1 Year $800 (subsequent years are the same price I think). Not only that, when one looks at the IBM Software Catalog there is tons of heavy stuff out there - all for the one price! Find it hard to understand why RDz isn't there . . or is the single WDz to RDz release upgrade that significant (noting it is a 'release' not a 'version' upgrade). My questions are: a) is there anybody in a similiar position as myself. b) anybody involved in this 'isolated' use of RDz or WDz. I am sorry about the generality of the foregoing but any comments would be appreciated. Many thanks Graham Hobbs P.S. An aside - I followed the FLEX debacle and I know I'm not talking mainframe here, but if the $800 price is true, maybe this goes partway to a pretty cheap solution - or am I off track here (not knowing what FLEX'ers were doing). P.P.S. If RDz (or WDz) comes to pass for me, am really quite scared about installing all that stuff, but will save these questions for later -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
