COBOL CICS co-processor listing RFEs

These look like useful suggestions. https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=93730 https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=95165 Remember you need to be logged-in with IBM ID before attempting to use the RFE site. If you don't have one

Re: remote system support (i.e. the data center is 2 states away from you).

Perhaps it's an "other side of the Pond" thing, but if it is a actual remote position for a large company, I'd expect them to provide all the hardware you need, and even ban you from any access to the company from your own devices (other than phone calls). As others have indicate, working

Re: How do you say "z/OS"?

The *letter* is pronounced "zed". The sound of the letter is zzz. Zoo, Zorro, zero. For even older UK TV, https://en.wikipedia.org/wiki/Z-Cars On Sun, 25 Sep 2016 15:15:02 -0500, Richard Pinion wrote: >I've been watching old episodes of the British TV program UFO by

Cobol 5 compile parameters

Firstly, I think you have posted this in the "google groups" for IBM-MAIN. That is not the best way to do it, as many can't see your post as it is not propagated from there to the actual LISTSERV. You need to subscribe to the IBM-MAIN list to get the most benefit. Search hear, or elsewhere, for

Re: How do you say "z/OS"?

NaN in computing is pronounced, right? My rule of thu... mouth I suppose, is if it can be pronounced, pronounce it, otherwise say the letters but with no gaps in between. Emveeess vs Em-vee-ess. 1970's training video, American guy with hairstyle which made his head look like a triangle,

Re: mathematical infinity (Was Bypassing s322)

Interesting articles. In the Principles... it is documented that there are bits set to indicate these things. These things include at least two types of NaN, but not my favourite, which is Peshwari. -- For IBM-MAIN subscribe /

Re: Bypassing s322

I had been wondering why there were not "rules of algebra" explanations for the floating-point variants of MULTIPLY. So I looked: "The sign of the product, if the product is numeric, is the exclusive or of the operand signs. This includes the sign of a zero or infinite product." In

Re: Bypassing s322

Oh, I think there's been a certain amount of "drift" in the topic. There are lots of simple ways the issue you mention could have occurred, even though we'll never know exactly. I agree, rather than trying to give a program more CPU, I'd be wondering why it is sucking up all the CPU that it

Re: Bypassing s322

Oh, we're talking about years after 1981 :-) Probably the middle-late '80 to early 90s. You don't need to assert anything, it is documented. Could look it up and make those dates a bit more accurate, but it doesn't matter, does it? Unfortunately, for the potential Herculean effort, pre-COBOL

Re: Bypassing s322

February this year, in the Archives, "COBOL Code Gened for MOVE COMP-3 S9(9) to S9(8)" Or just search for "negative zero COBOL" I guess. I would imagine it fair to say that a numeric field is tested more often than it is set.

Re: Bypassing s322

Ah. Well. Preferred signs. The thing is, preferred signs are not a problem as output from a "decimal instruction", because no matter what goes in (as long the sign is A-F, else Bang!) then only C or D can come out. No enforcing is necessary, it is just the way it happens. Calculations in

Re: Bypassing s322

It is not so much what I mean, as what the Principles of Operations means. "The sign of the product is determined by the rules of algebra from the multiplier and multiplicand signs, even if one or both operands are zeros." It is the old "two negatives make a positive, two positives make a

Re: Bypassing s322

Yes, "the rules of algebra" has lead to a minus zero... but it is still zero, the sign for zero has no significance in algebra. In two's-complement, there is no negative zero. In packed-decimal 'rithmetic, there is, as explained in the PoP. The sign of the result is according to the rules of

Re: Bypassing s322

Yes, the compiler generates additional code to ensure that a -ve zero cannot be the result of anything in COBOL. This was discussed fairly recently here. The machine instructions obey the rules of algebra, COBOL doesn't as they apply to zero. Minus five times zero is zero, and always positive

Re: Bypassing s322

Very old Mainframe COBOLs did allow -ve zero to exist. The test for a zero where the source may have been a negative zero should have been unproblematic, because at the time only "decimal" instructions were used for numeric comparisons in the code generated by the compiler. And zero is zero.

Re: DFSORT - ICETOOL - Search for text and replace with date

If there's only one thing to change per line (maximum, or limit) I always use DO=1 on the FINDREP. If there's a limit to where the data can start, end, or both, there's STARTPOS and ENDPOS. Use IFTHEN=(WHEN=(logicalexpression) to only allow the FINDREP to operate on the expected records.

Re: RD/z

This may be of interest: https://developer.ibm.com/mainframe/2015/08/21/how-to-run-a-productivity-benchmark-part-ii-jon-sayles-ibm/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Re: Change RC in compilation step

Jorge, It would have been good to mention the IGYPS2015-I message originally "The paragraph or section prior to paragraph or section "?" did not contain any statements." Did you check on Greg Shirey's reference to APAR PI63119? It is fairly recent (June 2016) and the multiple references to

Re: Change RC in compilation step

The message would occur with V4.2 with OPT of STD (or the not very much fuller FULL). Perhaps the message now comes from OPT(0)? You can check that. Note, the message is correct. The best way to get rid of it is to fix the code (as always) unless it is something which is supposed to be like

Re: How Does One Make a Module NOEXECute?

Did I miss where C came into it? I've assumed an exutable (since the need is to make it non-executable) and created by the assembler. Amount of code to data I'm not aware of distinction. Are you just saying C would be a bad language to do this in because it has these oddnesses?

Re: How Does One Make a Module NOEXECute?

Can you be specific about where the hll programs come in to it, and why/how marking it non-executable would help with that? If you just make it non-executable there'll be an Sx06 abend won't there? As to having a bit of diagnostic code just before your table, just pretend it is data. After

Re: How Does One Make a Module NOEXECute?

>So anyone have any ideas how to avoid the HLL programmer doing a >CALL and executing data? > What is really the issue? It's going to get picked up in program testing if someone does it. If an HLL program attempts to CALL and instead you make the table otherwise unavailable it is just going to

Re: Egypt cancels DST?

I love this from Mark's link: Changes to past and future time stamps Asia/Novokuznetsk and Asia/Novosibirsk now use numeric time zone abbreviations instead of invented ones. I'll be able to say to people, sounding knowledgeable: "Oh, I remember the days when Novokuznetsk and

Re: GMail vs. COBOL

Thanks, Bill, got to that now. Even after reading the manual, it still took time to realise that the quote possibility only emerges once you've already clicked on Reply. The thing is, having got this far, am I still breaking things (topics) in gmail? Gord, other than sounding slightly risque,

Re: GMail vs. COBOL

Well, I was wrong about there being no "reply" from the listserv.ua.edu. If you go into an archive month, you can reply there (can't work out how to get quoted text, but I can always "reply" in the google group, copy, paste in here, type what else I want (and trim) and "Send Message" from here,

Re: How does COBOL detect a recursive call?

That, Victor, could still require "IS RECURSIVE" on the PROGRAM-ID to avoid the abend with the IGZ0064S message (because the "handler" is invoked from the same program), depending the linkedit/binder RENT/REUS values. So it doesn't make it any simpler at the level of the mechanics. Also, when

Re: GMail vs. COBOL

And now from the archive, posted as a reply to my last. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: GMail vs. COBOL

So, to test, do you see the message I posted below? On Tuesday, 16 August 2016 23:50:31 UTC+2, Bill Woodger wrote: > As I understand it, when I "reply" from the google groups display, only the > google-groups readers can see it, it doesn't go to the list itself. So you, >

Re: GMail vs. COBOL

I use google groups to view the list, and https://listserv.ua.edu/cgi-bin/wa?A0=IBM-MAIN to post to the list. I have email delivery turned off, and do not reply to (the non-existent) emails from gmail. The google groups presents everything nicely by topic, whether I include Re: at the start

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

I've never previously heard of a "loop and a half", so did some digging. Eric S Roberts, you picked an oft-referenced person, Frank :-) Here's an example of the discussion (not from Roberts, but referencing him): "The problem with using goto isn't the keyword itself-rather, it's the use of

Documentation of COBOL's EXIT SECTION/PARAGRAPH

I just thought to check that EXIT PARAGRAPH and EXIT SECTION "work" in DECLARATIVES, and came across this bunch of nonsen... err, came across this documentation: "EXIT SECTION The EXIT SECTION statement can be specified only in a section. When an EXIT SECTION statement is executed, control

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

Keeping it COBOL, there is some masterful documentation relating to the probable conceptual origin of try/catch (COBOL's DECLARATIVES) * However, there are bits of the concept which were left out: "A declarative procedure can be performed from a nondeclarative procedure. A nondeclarative

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

And now we have a 21-year-old academic paper, the author ruffled by critique of a previous published item on switching their course from using Pascal to using C and teaching an "intuitive" use of a "goto". M... "teaching an intuitive" doesn't work, does it. "Letting the students do what

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

Perhaps you can suggest a use for it beyond a file-processing loop. It may be an "across the Pond" type of thing, FILE STATUS is de rigueur (I think that means they use it in France as well)? With FILE STATUS you don't have to AT-END-set-a-flag, you have a "flag" set for you (100% accurate,

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

I use the Archive for posting, and the google groups web interface for viewing (having been informed that using the google groups for posting does not get those posts sent to the main list). Having seen some random Re: posts start a "new" topic, I have deliberately not been pre-pending a "Re:

Re: GMail vs. COBOL

Perhaps now I know what you are talking about :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

Thanks David, I only use the "google groups" access to the list, so didn't know this was happening :-) I even thought it funty (google Mr Gum and Billy William the Third) when sometimes there is a topic when some variant of re: appears in isolation. Am I the only culprit? Wow. I feel like I've

COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

I may have to reply initially with a thesis on "Not using FILE STATUS considered harmful - and AT END even without NOT AT END is a worse pain" (I'll leave the sub-tiles for later). PROCESS-MY-FILE. PERFORM UNTIL EXIT READ MY-FILE INTO MY-RECORD AT END

How does COBOL detect a recursive call?

Yes, it is documented that a contained/nested program cannot have an ENTRY, and, separately that a contained/nested program cannot be used for an LE Condition Handler. -- For IBM-MAIN subscribe / signoff / archive access

How does COBOL detect a recursive call?

Yes, I'd not suggest compiling two separate programs as a single source, except for the idea that they (the Manglerment) seem to want it done in one "program". I'd kind of hope it doesn't fit into their procedures either - even though it is as "logically equivalent" to the ENTRY idea as it is

How does COBOL detect a recursive call?

On Thursday, 11 August 2016 01:47:07 UTC+2, John McKown wrote: ...> > ​Hum, I would guess this will be a case of "20 lines of code and 200 lines > of comments (excluding cursing)"​ > > > > > Excluding cursing, and including recursing. Any IT management who chooses that route over

How does COBOL detect a recursive call?

Thanks, Chuck. Tough sitch. I think as definitive as you are going to get, in a documentary sense, is this, from the Programming Guide (doesn't matter which version): "Calling alternate entry points Static calls to alternate entry points work without restriction." I made a static CALL to an

How does COBOL detect a recursive call?

Hi Chuck, Thanks. Yes, I was able to recreate the issue after making the post with the questions in. RENT,REUS or REUS or RENT, ie any combinaton, on the linkediting/bindering causes no new executable to be loaeded in this case, so tha ALIASed ENTRY is in the same executable as the CALL.

How does COBOL detect a recursive call?

OK, it is the RENT or REUS (either will do) on the link-edit/bindering. Without RENT/REUS you get a new executable for free. With RENT/REUS you get to "share" the original program, but it is necessarily a "recursive" use, so you get the "IGZ0064S A recursive call to active program..." message.

How does COBOL detect a recursive call?

Thanks :-) Looks like your LE has about 10 levels of "depth". The handler is getting invoked, and then itself abending/raising a condition, so it gets invoked again, and does the same thing - until LE runs out of patience that was defined for it. The IGZMSG is the module which informs of a

How does COBOL detect a recursive call?

Reading your post rather than going from the title, the U4087 2 is Language Environment abend for when an registered abend-handler has been entered a subsequent time before processing of the original abend has completed - the handler written in COBOL failed, and was entered again to process the

How does COBOL detect a recursive call?

Well, the SET ... TO ENTRY ... definitely loads (with the assumption that the module is not already in memory, in which case it just gives you the entry-point address). At least ordinarily. I don't know about the ENTRY which is in the same program. An ENTRY in a different program (with an

Enterprise COBOL API for dynamic capacity tables

I used COMP with TRUNC(OPT). Aren't you one who said that COMP with > TRUNC(OPT) performs better than COMP-5? > > > Thanks, > > Frank > > ____ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of > Bill Woodger <b

How does COBOL detect a recursive call?

Conceptually, it sets a flag at the start of execution, and resets it when the GOBACK (or other way to get out of a program) is processed. Prior to setting the flag it tests to see if it is still (already) set. If so, the program has been entered recursively, either directly or by CALLing (or

Enterprise COBOL API for dynamic capacity tables

"leftmost-character-position Must be an arithmetic expression. The evaluation of leftmost-character-position must result in a positive nonzero integer that is less than or equal to the number of characters in the data item referenced by data-name-1." So, you are using undefined behaviour (and

Another COBOL question

Interesting about the NAME. All the options should apply to all of the source. Also, a loose PROCESS card like that doesn't seem to be documented (at least in the obvious place). -- For IBM-MAIN subscribe / signoff / archive

Question about the COBOL compiler

If you don't know what harmful things there are, consult the Binder/Linkage-editor manual. Like compiling this program and linking it as another, for a simple one. It is rare that IBM ask me anything (although it did happen once, if IBM can be thought of as one person who works for IBM). Even

Another COBOL question

I like Frank's example, prefer it over the ENTRY. If the ENTRY works, but it's use is not documented, I'd raise it with IBM. Once they acknowledge (or deny) that it works, you are safe against some future change (or you know you have to change it now). I think any site that doesn't allow

COBOL 2014 dynamic capacity tables

Yes, good to know. I realised when I was writing my earlier comment that there is not much downside to defining "extra" storage, it is what we do already with a static table :-) However, I'd still go horses-for-courses. Make the increment for the unboaded table a size which relates to the data

Question about the COBOL compiler

The NAME compiler option (can be used from PARM, from CBL/PROCESS source statement) does generate binder/linkage-editor control statements. I don't think that it would be at all a good idea to have "arbitrary" binder/linkage-editor inserted by a programmer. There's too much that could be done,

Another COBOL question

I've already posted that for a dynamic CALL you are supposed to CANCEL the "main" program before using the ENTRY program. If there is nothing in the ENTRY program which relies on WORKING-STORAGE or LOCAL-STORAGE in the "main" program, you may ordinarily "get away with it", even though the lack

Question about the COBOL compiler

Here's one of those teachable moments, Peter. Yes, that will do what is wanted, but what is wanted won't be what is wanted. Unless what is wanted is something else. If you CALL an ENTRY (having ALIASed it by whatever manner) having previous CALLed the "executable" that the ENTRY is an ALIAS

Question about the COBOL compiler

Gil, recipe away, the dynamic CALL to an ENTRY doesn't work (unless effectively you want the ENTRY to be a separate program, in which case why not make it a separate program) so it is irrelevant how you attempt it. -- For

Question about the COBOL compiler

From the 3.4 Programming Guide: Calling alternate entry points Static calls to alternate entry points work without restriction. Dynamic calls to alternate entry points require the following elements: v Either explicitly specified NAME or ALIAS linkage-editor or binder control statements, or

Question about the COBOL compiler

Well, static or dynamic matters. Static CALLs will work to ENTRY points in the expected way (previous state of program, whether PROGRAM-ID any other ENTRY was CALLed previously). Dynamic CALLs to ENTRY points, even once ALIASed, will not do what you probably expect. If you expect to have

Question about the COBOL compiler

Sorry, forgot the second bit. Not a list, but there is IBM's Compile Cafe forum: COBOL Cafe. A couple of the Enterprise COBOL developers drop in on it. It covers all IBM COBOLs, and gets used as a dumping-ground for someone desperate to ask a question about COBOL, and there's not much activity,

Question about the COBOL compiler

Somewhat (when you have a "batch compile - a compile of a load of separate programs in one hit). But not really, there was a bit of recent discussion of this here, a topic by Frank Swarbrick. Which compiler are you using? You want to CALL dynamically, or statically?

COBOL 2014 dynamic capacity tables

Peter, it becomes a large and wide topic, then, and the discussion of the dynamic table gets lost in it. To discuss it, best it is another topic. As you have made clear, it is not (always) possible to discern the stupid from the ignorant. For instance, there is/are the person(s) themselves,

COBOL 2014 dynamic capacity tables

The key to your code being useful *and* performant is the knowledge to allocate new "spare" slots in chunks, which are neither too small, more shifting of data, nor too large (actually, much less of a problem). If you have a native COBOL way to do that, fine. I have a table with 400,000

COBOL 2014 dynamic capacity tables

Well, Peter, there is much in what you say, but be careful of quotes. "Mmm... I smell gas in this dark cellar, has anyone got a match...?" - was the person ignorant of the rapid combustion of said gas when a flame is introduced, or just stupid? Same question for the match provider, and the

COBOL 2014 dynamic capacity tables

I think that is the correct way to do it, Frank. The chunk-size of "20" is obviously determined by whatever best fits the data use. I'd go for the old "table size you expect, and then a bit" but doing the "and then a bit" by extending it. For batch it doesn't matter, but for other usage you do

COBOL 2014 dynamic capacity tables

If you are expecting this type of table to non-contiguous in any way, then that breaks things. You couldn't REDEFINES (you could "ban" it. No you can't. REDEFINES is banned for OCCURS DEPENDING ON yet I use it a lot). OK, for SEARCH, you could have special versions of the library routines

Step-name not displayed correctly (z/os 2.2)

Something that spells a word, especially a word like BAD, which appears where a "hex" value should not, is deliberate. Something BAD happened and this is how that badness is shown to you. -- For IBM-MAIN subscribe / signoff /

S0C4-11 abend caused by BASSM to address with all X'00' bytes

HRDRFREA has had at least part of its "executable code" overwritten. That has caused a branch, directly or indirectly (through more than one branch), to somewhere close to where it abended. As soon as it branches out of the COBOL program, the information is irrelevant for problem determination

S0C4-11 abend caused by BASSM to address with all X'00' bytes

Ok, either from the Production compile listing or by browsing the member on the Production loadlibrary, can you provide the 36 bytes, in hex (even better binary :-) ) from displacement X'84' from the start of the program? These are the "signature information bytes" which the compiler includes

S0C4-11 abend caused by BASSM to address with all X'00' bytes

For a COBOL program to produce an exotic abend (removing the current record and having a clean run points a pretty big finger at the COBOL program) then it is a storage overlay. Tiny chance, tiny, tiny, of runtime/compiler problem if you are on V5+. Nice to know, just to know whether to

DFSORT DYNALLOC/DYNAPCT question

OK, but you don't have to do it for everything. Most things aren't giving you a problem. Small files aren't the same issue as larger ones. Diversion between actual amount of data and estimated amount of data affects performance, not just workspace allocation. I'd ask IBM DFSORT to look at one

DFSORT DYNALLOC/DYNAPCT question

Which is why I'm suggesting providing additional information on the DFSPARM DD. Because if DFSORT is not reading the data, it doesn't know so much. You can fill in some gaps for it. Allowing DFSORT to do the allocations better is probably an advantage over allowing DFSORT to complete

DFSORT DYNALLOC/DYNAPCT question

You could look at using DFSPARM in your SAS steps, https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.icea100/dfsparm.htm When invoked from another program, and when that other program is reading/providing the data to DFSORT, you can help DFSORT out by providing things

737 ( was RE: Upcoming Share Conference events in 2017)

3000 nanometres isn't really very far. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Interface to query length of storage allocated with CEEGTST LE service

Here's the link I failed to include, the suggested reading: http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceeam00/clsthp.htm An overview, but, for the willing reader, follow the references and go as deep as you want. LE can report on storage used, and storage (like

Interface to query length of storage allocated with CEEGTST LE service

There is some evidence that the "control information" is stored in the heap itself (see the Usage Notes for "CEEFRST—Free heap storage") and by implication associated directly with the storage allocated. However, it is not documented, and working it out through inspection would be pointless

Good use of COBOL EXIT SECTION?

A good idea, but why impose the extra paragraph-name per SECTION? procedure division. main section. mainline. perform one perform two goback . one section. [...do something...] exit section . two section. [...do

OS ENQ from COBOL

There's nothing native in COBOL to do an what you want, and I'm not aware of anything in LE as a callable service. Hybrid. Documentation. Probably the most they'll need is how to reassemble it. Unless a macro changes, why else would they ever need to touch it?

Bsam VS Qsam for VB records

I previously acknowledged that the data looks OK. No, it is not an attempt to "extend" a block. It is to write a lump of data which, once the "correction" has been done (else the data can't be read as a VB anyway) will appear to be a VB "block", but which will start with binary zeros. Someone

Bsam VS Qsam for VB records

DISP=MOD does lead to a way to accidentally (or deliberately, as an exercise) create a "zero" BDW. With RECFM=F/FB/U and some LRECL, specified on the DD, write a lump of data with two bytes of binary zeros. Then with DISP=MOD again, and the "normal" RECFM/LRECL, write a good record. Then try to

Bsam VS Qsam for VB records

If you have confirmed it is on the disk (I assume you mean the BDW and RDW look OK) then it is being clobbered in code. If something is not correct immediately after doing a correct read (so assumption you have coded that correctly) then it is something for IBM. More likely is a program error

Bsam VS Qsam for VB records

With RECFM=U, you get the entire physical record presented to you. It has no "length" as far as the system is concerned, it is just an amorphous lump of data. For VB-as-U the first four bytes are the RDW of what was the block, the next four bytes the RDW of the first record, and you can find

Considering Enterprise COBOL 5.2 "exit" enhancements

Thanks Clark. To be clear, I'm not suggesting that ALTER should appear in new programs. It is deprecated, and will soon disappear (I think in the next Standard). The point is that despite the "good" uses of ALTER, where you can only not follow what is going on if you can't follow a program

Considering Enterprise COBOL 5.2 "exit" enhancements

Here's an example of advice for performance, from COBOL (on disk) Specifications IBM 1401, 1440, and 1460, from 1964, PDF courtesy of bitsavers. "Perform and Alter Statements 1. The statement ALTER LABEL TO PROCEED TO NEXT- LABEL generates 10 characters of coding. 2. The statement PERFORM

Error in a simple COBOL program

Well, a great friend of mine has managed to reproduce the issue and has passed the details on to me. Typical. Steps to recreate: Create a JCL stream to execute the compile-and-go PROC, using the original source as input to the compiler. Type SUBMIT at a point where it will be recognised as a

Considering Enterprise COBOL 5.2 "exit" enhancements

On Friday, 15 July 2016 23:34:20 UTC+2, Edward Gould wrote: > Not to get into structured programming issue at all (I think it has its good > as well as bad points). But the idea (I thought) of readable programs, alter > goto’s (in my mind) destroy simple readability as what you read does not >

Error in a simple COBOL program

Bill, From the original post: IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was unsuccessful. The generated code is very simple (4.2) and is (subject to the locations of data and "pattern" (the PGMLIT value) and the code): 0004BE 58F0 2000 L

Considering Enterprise COBOL 5.2 "exit" enhancements

One thing I really dislike about functions... and Ed will appreciate this... You can use them (like this example) in a condition. See! How horrible is that? Oh-oh-darlk-30 is I believe a suitable expression. 30 lines before the S0C7 is "IF FUNCTION NUMVAL-C(WSVAR97)=4" and you need to know the

Considering Enterprise COBOL 5.2 "exit" enhancements

y fixing a program that uses alter at 0300. Nothing is clear through > gritty eyes at that time of the AM. > A company I worked at a while ago. I put in the standards manual never use > ALTER and every team leader wanted it emblazened across every programmer > forehead. > >

Considering Enterprise COBOL 5.2 "exit" enhancements

Well, "way to stay on-topic". :-) I should have left the discussion in the "now impossible to determine (so more interesting) S0C1 in COBOL" topic. I was going to wait for Frank's comment, then realised he'd already posted the same code. I thought we'd agreed "always check the file status".

Considering Enterprise COBOL 5.2 "exit" enhancements

Why has ALTER always been bad? Because of the potential scope of things that you can do with it, or because COBOL programmers will ignore or be unaware of any "best practice" for using it, or something else? If either of the first two, then away goes "EXIT PARAGRAPH/SECTION" into the

Error in a simple COBOL program

"IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was unsuccessful." Program outside of TSO then gets an LE User Abend (U4038). No S0C1. Sure, it is not ideal that under TSO there is a S0C1 instead, but its not that we are so used to S0C1s from COBOL that we didn't

64-bit XPLINK LE assembler program initialisation error U4093 reason X'218' (536)

There is a new CALLINTERFACE compiler directive. At the moment it supports DLL, STATIC and DYNAMIC, but it could be made available for other uses if that was thought to be a useful thing. However, there's another potential nightmare in the waiting. CALLINTERFACE affects all CALLs which appear

Considering Enterprise COBOL 5.2 "exit" enhancements

Frank, there are not often more than two of us at the COBOL Cafe. Sorry for hijacking (didn't realise I was) but... I have no problem in contributing to "best practice". Oh, I do, because I still see no genuine need for them. I have no problem contributing to "2nd-best practice". I don't

Considering Enterprise COBOL 5.2 "exit" enhancements

So, given that ALTER was (ab)used (it is really simple to use it in a controlled manner, even to confirm in a dump where the paragraph is going, but try telling that to people at parties, they just slowly move across the room away from you), why would the assumption be that various forms of

Considering Enterprise COBOL 5.2 "exit" enhancements

Please list from all those languages in which of them the logic flow changes by adding a label. There is nothing intrinsic with ALTER ... TO PROCEED TO ... or GO TO ... DEPENDING ON ... or GO TO itself which makes it "bad", it is the way that they were (ab)used. "My program is 'Structured'

Error in a simple COBOL program

I can't directly use the link to look at the RFE, but COBOL V5+ already uses DFP instructions (I don't know if that should be "at least some") with OPT 1 or 2 and ARCH(10) or higher. Their uses is mentioned in the COBOL tuning guides, which are PDFs which can be linked from the presentation of

Error in a simple COBOL program

Andy, The S0C1 with that exact set-up does not "normally" happen in COBOL (by which I mean, by COBOL running in batch). COBOL programs are not "normally" run under TSO. There is an explicit run-time message which explains the issue. The S0C1 is unexpected. It is some artefact of running that

Error in a simple COBOL program

Steve, I'm not sure what was difficult about the question. The intent behind it is "if when next I see reference to a non-COBOL PIC, if it happens to be 11, I know whether it means 11 or 17". Is it somehow a question which can only be asked when the answer is needed? "Hey, it's 0-9, who gives a

<    1   2   3   4   5   >