CEE3551S DLL xxxxxxxx does not contain any C functions.

On Tuesday, 25 April 2017 21:15:57 UTC+2, Dan Kalmar wrote: > I am calling an LE assembler routine from Enterprise COBOL batch program and > receive the CEE3551S error message. > > The call made in cobol is the dynamic type. > > Not sure why LE thinks the target program is expected to contain

Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value

1. "This manual left intentionally blank". Try a DATASORT. If you have that, you probably have everything. 2. Yes, symbols are great. SyncSORT doesn't call them symbols as such, I think they are "dictionary" or something like that. I've been known to change Kolusu's inline comments to

Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value

If you don't need the physical file for anything except to extract from it, you can just establish a SEQNUM for each selection, and just use an OUTFIL (or more) with your selection by number. Saves the SORT, the creation of the new file, and the processing of the new file, just cutting straight

Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value

Also, your initial BUILD creates the extra byte which is used. You can change the subsequent BUILDs to OVERLAY which just change the one byte at column 5: (will save you one BUILD per record, you'll notice). If 220k+ were really large, you could also (since the test values are mutually

Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value

It doesn't matter where you physically locate the SORT control card, SORT will execute after INREC. You need to put anything which the SORT relies upon in INREC, and anything which relies upon the SORT in OUTREC. -- For

Re: Purchasing opportunity...

On Mon, 17 Apr 2017 17:28:11 -0500, Mike Schwab wrote: >Works just fine for me. > Thanks. Tried again, same problem. Closing and restarting Firefox got it back for me. I'm in a different country today, and I clicked OK for a bunch of security updates, I guess there's

Purchasing opportunity...

"Firefox can't find the server at www.ibm.com." Perhaps they've not paid the domain registration, and someone can snap it up? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Re: COBOL integrated pre-processor, API in general

Frank Swarbrick posted an example COBOL compiler input-exit last year, to allow the embedding of linkageeditor/binder statements. It is on IBM's COBOL Cafe. I can't provide a link because I currently get "Problem loading...".

Re: COBOL integrated pre-processor, API in general

On Mon, 17 Apr 2017 15:51:57 -0500, Paul Gilmartin wrote: [...] >If there were such a fixed API, it would need to be able to: >o Invoke external services (CALL, ATTACH, SVC, PC, ...). >o Access and update COBOL variables. >o Check syntax and validate data types. >o

Re: COBOL integrated pre-processor, API in general

John, you are after a general API to allow "something" to have a meaningful impact on code-generation by the (Enterprise COBOL) compiler? I think we've had a "non-denial denial" (or similar) that there is a single API for EXEC. Even if similar (who knows?) they are different. Each interacts

Re: COBOL integrated pre-processor, API in general

On Mon, 17 Apr 2017 14:30:10 -0500, Allan Kielstra wrote: >I wouldn't necessarily assume that there is a fixed API for EXEC CICS, EXEC >SQL, EXEC SQLIMS. It's always possible that each one of these gets some sort >of custom treatment from the compiler. > Hi Allan,

Re: Opinion: Using C "standard library" routines in COBOL.

I'm interested in how people deal with the case of the functions and what type of executables people create. Relevant is discussion of overflow. By Standard fine for COBOL, not fine for C. sprintf is fun but do I want to interpret a string 4m times to produce a report?

Re: What are mainframes

On Thu, 6 Apr 2017 19:02:23 +0800, David Crayford <dcrayf...@gmail.com> wrote: >On 6/04/2017 6:35 PM, Bill Woodger wrote: >> Just to note, the UK Weather Centre (The Meteorological Office, or Met >> Office) uses a big-boy LinuxONE and they were an early user of that. > &g

Re: Cobol and decimal overflow overhead (was: Data/hiperspaces)

On Wed, 5 Apr 2017 13:09:53 +0200, Peter Hunkeler wrote: >>Firstly, Peter, I know you didn't write the code or come up with the idea of >>the definition of Fraction. Secondly, looks like you have some progress with >>your related topics from over the last few months. > > >Yes, we

Re: What are mainframes

Just to note, the UK Weather Centre (The Meteorological Office, or Met Office) uses a big-boy LinuxONE and they were an early user of that. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Re: Cobol and decimal overflow overhead (was: Data/hiperspaces)

On Tue, 4 Apr 2017 07:43:05 +0200, Peter Hunkeler wrote: [...] > >>If unintended truncation, fix. If intended, do it in such a way as to not >>cause the overflow. > > >The last point is not always easy to achieve. The each compilers version or >release may generate different code

Re: Data/hiperspaces (was: ... 4G bar?)

On Thu, 30 Mar 2017 13:20:57 -0700, Alan Young wrote: [...] > >fread(), fwrite(), fclose(), clrmemf() etc. support it. And the routines >are callable from COBOL. > >Alan > And if calling C/C++ from COBOL programs, be aware of the 00A/S0CA issue. Since COBOL truncates

Re: [EXTERNAL] Re: IBM RFE's for z/OS - 2 to push

On Thu, 30 Mar 2017 12:02:40 -0700, Ed Jaffe wrote: >On 3/30/2017 9:33 AM, Dyck, Lionel B. (TRA) wrote: >> I have no idea as I can't get into the requirements area any longer. Perhaps >> because I haven't been to a SHARE for several years. What I do know is that

Re: How does ABO report its outcome? (was: Migrating Cobol)

thing" to merge original compile listing with ABO output listing could be useful for someone to write. On Tue, 28 Mar 2017 18:02:43 -0500, Edward Gould <edgould1...@comcast.net> wrote: >> On Mar 28, 2017, at 3:47 PM, Bill Woodger <bill.wood...@gmail.com> wrote: >> >>

Re: AW: How does ABO report its outcome? (was: Migrating Cobol)

Without any TEST option on the compile, LE gives you nothing but the offset of the failing instruction, then you find it in the compile listing. ABO gets you a new listing of the new code, a new place to consult for the offset. If you compile with TEST options, the code generated for those

Re: How does ABO report its outcome? (was: Migrating Cobol)

The output listing from the ABO process is designed to mesh with the output from the original compile. If it doesn't, or there are difficulties, problems, suggestions for improvement, let IBM know. -- For IBM-MAIN subscribe /

Re: Migrating Cobol

Danger of this becoming another ABO thread in disguise :-) The question of the testing of ABO is not entirely cultural, or not necessarily so. Nor necessarily "compliance". There can be a technical basis on which to make decisions, which cultural and compliance issues may make moot. I'm keen to

Re: Migrating Cobol

If you have very large programs and you want to optimise them to Level 1 or Level 2, then Enterprise COBOL V6.1 is your best bet. The optimiszer was re-written with 64-bit addressing and is now much more comfortable with large programs (which may just fail to compile with V5.2). V6.1 is now

Re: thoughts on z/OS ftp server enhancement.

On Sat, 25 Mar 2017 11:38:50 -0500, Paul Gilmartin <paulgboul...@aim.com> wrote: >On Sat, 25 Mar 2017 03:29:33 -0500, Bill Woodger wrote: > >>Micro Focus COBOL can read "Mainframe" and write ""PC", several ways. >>Enterprise COBOL can wri

Re: thoughts on z/OS ftp server enhancement.

Micro Focus COBOL can read "Mainframe" and write ""PC", several ways. Enterprise COBOL can write the data as ASCII (that's just for information, as DASD-shortage rules that out for you). Find out what would be best, and other options, for the non-Mainframe people to receive. Other things than

Re: Read SMF using COBOL

Ah, the diagnostic is only for OUTPUT/EXTEND for an F-type with RECORD CONTAINS 0. Since it doesn't produce a diagnostic message in your case, I think you are OK going forward, but I'd not code it like that. Also, your FD: FD SMF-RECORDS-IN RECORDING MODE S LABEL RECORDS ARE STANDARD

Re: Read SMF using COBOL

The Language Reference says: "The RECORD CONTAINS 0 CHARACTERS clause can be specified for input QSAM files containing fixed-length records; the record size is determined at run time from the DD statement parameters or the data set label. If, at run time, the actual record is larger than the 01

Re: Read SMF using COBOL

BLOCK CONTAINS 0 makes sense, if BLOCK CONTAINS is specified in a COBOL program, it overrides everything else up the line. But, won't affect your problem. RECORD CONTAINS 0. That's for fixed-length records, where the actual length will be acquired at runtime. For a variable-length record

Re: Read SMF using COBOL

And no, I don't know why the discrepancy is not four. Perhaps there is a problem when you specify variable-length data in the FD that is longer than the maximum possible value. You should get the file open by reducing your 32760 to 32754 in the FILLER.

Re: Read SMF using COBOL

You have specified 32760 bytes of data. Remember that the LRECL does not only include data. If you have 32760 of data, your LRECL would be larger than 32760. If your LRECL is 32760, your data has to be shorter. -- For IBM-MAIN

Re: Broken VBS and ICE141A

Paul, that doesn't answer the question of whether data was written to the dataset with LRECL=X, the question I asked. Provides a way that the data is actually valid. Otherwise the data is invalid. Are you really so sure that a program, with no knowledge of the expected structure of the data,

Re: Broken VBS and ICE141A

Simple, John. You produce the message Paul wants. Can't be clearer. Radoslav, Was the data set written with LRECL=X, to get "long" records? What is the data? Why is it VBS? -- For IBM-MAIN subscribe / signoff / archive access

Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches

Martin, I doubt the US government was ever restricted, since they were effectively the source of the restrictions... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with

Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches

On Mon, 20 Mar 2017 11:33:10 -0400, George Rodriguez wrote: >Does anyone think that Computerworld is going to write a retraction? > > No. And it is not just Computerworld, a search-engine finds at least 23 similar references to the report. Maybe some

Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches

My gosh, ho-hum, what a bag of nonsense passing itself off as a contribution to research. And then there's the journalism. Tom Marchant phrased it eloque... well, bluntly. The researchers who wrote the paper, dated March 7, 2017, used a media article to come up with "It's COBOL wot dun it"

Re: Need help understanding use of CEEPIPI from non-LE assembler main programs

You have an Assembler program, and once it has called and returned from one COBOL program, it goes on to call and return from other COBOL programs (or other invocations of the same program)? You'll want to look at start_seq and end_seq.

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

On Mon, 13 Mar 2017 10:23:12 -0500, John McKown wrote: >​I took a quick look at XPLINK. And you're right, that's a whole 'nother >kettle of fish. I basically understand the why, as explained in the LE >manuals. But why COBOL decided to go with the same, other than

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

From the COBOL Cafe: https://www.ibm.com/developerworks/community/forums/html/topic?id=e055e63f-4e61-4502-b04c-db9b3d89d213 Allan Kielstra, from Markham, on a question of whether COBOL V5+ uses the FASTLINK calling convention. 'This is a bit confusing. Even I was confused while I was

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

On Mon, 13 Mar 2017 09:37:15 -0500, Tom Marchant wrote: >Unless IBM has changed their direction, 64-bit Cobol will only be useful for >new applications. It will not interact with existing code unless that code is >also converted to AMODE 64. > >The reason for that is

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

Mike, is that the top of a list of performance/usability improvements for 64-bit addressing in general and in isolation? Or for a combined 31-bit-vs-64-bit, so that the difference in paging outweighs other losses? A quote from Tom Ross, from a discussion here on 15 January 2015, which shortly

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

Decimal floating point is nothing to do with being "64-bit" or not. The compiler is prepared for 64-bit when customer need arises. V7 is coming. I don't know when, or what it contains, but it contains something to be V7 not V6.n. If it were to be 64-bit addressing, I doubt that... people...

Re: IBM Enterprise COBOL for z/OS, V6.1 supports the continuous delivery model for new features

On Sat, 11 Mar 2017 09:46:30 -0600, Paul Gilmartin wrote: >>> >>> IBMR Enterprise COBOL for z/OSR is a leading-edge, >>> >(except for 64-bit) > Leading Edge is just sales waffle, no content. Why, specifically, would "64-bit" (whatever you mean by that) make COBOL

Re: curious: why S/360 & decendants are "big endian".

Four-and-twenty is not poetic, it is archaic, with continuing regional use in the UK. Although probably originally more thorough, I've only heard it used with 20. I grew up with five-and-20-past and five-and-20-to for the time. I didn't pick it up myself. Also for non-time things, but only with

Re: GSE UK - Large Systems Meeting

>http://www.gse.org.uk/mainsite/content/content_events.php >And a link to the news page which has more of a description. > >Clement Clarke, Author of Jol, JCL+ >http://www.oscar-jol.com/ > >Bill Woodger wrote: >> Well, it could be just me but I get 366k of something which pr

Re: GSE UK - Large Systems Meeting

Well, it could be just me but I get 366k of something which provides links to local files which don't exist. Anyway, I doubt they'll let me attend. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Re: GSE UK - Large Systems Meeting

The link doesn't work very well for me. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Check out Massive Amazon cloud service outage disrupts sites

On Fri, 3 Mar 2017 09:30:11 -0600, Elardus Engelbrecht wrote: >Vernooij, Kees (ITOPT1) - KLM wrote: > ... > >...giving a link to this [honest] post mortem by the AWS: > >https://aws.amazon.com/message/41926/ > >Just a simple lame typo... ;-) > >Groete /

Re: DFHSORT - Date Display of Previous Month

Kolusu works for IBM's DFSORT. He is not going to comment on the particular competing product that you use. What does it say in the manual? Can you show what you tried, how it failed, and more exactly what you want to do, with some sample input, expected output., amd output you receive?

Re: Question about PARMDD

Sorry, Allan, one of those occasions when reading all of the words prior to jumping is good... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO

Re: Question about PARMDD

On Monday, 27 February 2017 15:00:03 UTC+1, Allan Staller wrote: > No. IBM chose not to break thousands upon thousands of programs that were > perfectly happy with 100 byte parm fields, provided via JCL. > They added a new mechanism for those program, where 100 bytes was not > sufficient. >

Re: Question about PARMDD

The exact possibilities for the content of a PARM in a JCL deck depend on an interaction between "JCL" and the data the parm represents, (as David W Noon was keen to impress in the other thread on this). What happens for PARM-in-JCL need not happen for PARM-in-PARMDD. PARMDD did not exist

Re: Question about PARMDD

I don't think so either. There is documentation of the possibility of symbol substitution, but nothing about placement of commas, nothing about continuation symbols, and a piece about embedded blanks being possible. Particularly this latter could be affected by the embedding of comments in such

Re: Fujitsu Mainframe Vs IBM mainframe

Also note that if you see a current job-ad for Fujitsu Mainframe skills in the UK, it will be for an ICL Mainframe, running VME, and being distinctly different from... anything from IBM. The COBOL is to the 1974 Standard (with Extensions, including COMP-5 which allows the definition of "bits").

Re: z390 (Corrected Typo)

"Define one or more directories for source MAC files. If the option starts with + the directories listed will be concatenated with current list. Multiple directories are always separated by +. This option may also override suffix by adding *.sfx." The way I read that, the first character

Re: 31 vs 24 QSAM

Yes, don't just write using LBI from a program and expect to validate old vs new with ISRSUPC in batch. I know that a PMR has been raised about whether ISRSUPC supports LBI, the IEC141I 013-E1 message it produces hints at not. From what I've heard, using LBI, where it is possible to use it,

Re: QSAM using DCBE macro

"The large block interface (LBI) lets your program handle much larger blocks with BSAM or QSAM. On the current level of the system you can use LBI with BSAM, BPAM, and QSAM for any kind of data set except unit record or a TSO/E terminal. Currently blocks of more than 32 760 bytes are

Re: New HMC user issue (z12BC)

"Moral: I never had to tell the boss..." That's until now, right? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBDSACB control block

As far as I can tell, the only thing would be to get LE or IPCS to format it in an appropriate dump, look at it, look at the COBOL program, and then tell us... It does seem to be a documentary deficiency. On Mon, 13 Feb 2017 16:45:17 +0200, Steff Gladstone wrote:

Re: SORT - How can I put accumulated value on each output record

The Smart DFSORT Tricks doesn't have anything especially close. Search-engineing *will* provide something very close. But, as the obvious post itself suggests, understanding the code allows the same or similar techniques to be known and therefore available for other circumstances. Gives me a

Re: SORT - How can I put accumulated value on each output record

Yes, you can make this type of output with DFSORT. DFSORT has "reporting features" on OUTFIL. This provides SUBTOT/SUBTOTAL, which is to provide running-totals. SUBTOTAL is available on TRAILER1, TRAILER2 and TRAILER3. None of which do exactly what you want. If you look at what each does

Re: Where's my dump?

For the PARM, the setting of Language Environment option CBLOPTS determines whether parm information on the left or the right of the / goes to the COBOL program. The CEEOPTS DD is a very convenient way to do it. Having said that, if it is a simple exercise program, you may be able to bust it

Re: Program now working, but why?

"Thank Steve, I only mentioned it because Bill had discounted the idea and I was pleased with your confirmation it was possible. :) " "Discounted" for a reason. The AMBLIST outputs were compared. AMODE is in the heading. I'd be more than mildly surprised if the OS/VS COBOL program with an

Re: Program now working, but why?

On Wed, 8 Feb 2017 10:34:28 -0600, Peter Ten Eyck wrote: >At this point I am thinking the coding change is required due a difference in >how the COBOL compilers work. I was attempting to identify what that >difference may be or find something in the

Re: The "Cobol and 00A Program Check" Story - Some insight gained

Good progress Peter. The debugger turning the bit on seems to be... wrong. Interestingly wrong ("oh, we're in the debugger, let's do something different...") :-) The bit is only ever set (to zero or one, as appropriate) once by LE per "environment that needs to be established" (my wording). If

Re: Program now working, but why?

And Abend-Aid shows R4 as zero? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Program now working, but why?

Ah, but we enjoy it. Please don't take it away from us... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Program now working, but why?

Thanks Peter. Can you provide the COBOL compile options, the linkedit map for the EXEC PGM= program and the AMBLIST output for the original program? Did you discover why someone suspected the header? Any code (including whether it is PERFORMed) which CALLs the Assembler program.

Re: Program now working, but why?

"Rather than trying to infer the cause by tweaking everything in sight, how about this: Set a SLIP PER trap to catch an SVC dump for the first abend of any kind, S0C4 or otherwise. That dump may tell you the exact cause far more quickly than trial-and-error with

Re: Program now working, but why?

Remember, the AMBLIST Module Summary has been checked and confirmed. Even if NORENT is not used, dynamic CALLs, multiple load modules, how would they look the same, and yet have such a difference? On Tue, 7 Feb 2017 16:27:14 -0500, Farley, Peter x23353 wrote:

Re: Program now working, but why?

To get the S0C4, something has to reference something outside the buffer maintained by QSAM. I know no details of the internals of QSAM, but it seems reasonable to believe that it allocates storage for buffers which are equal in size to the BLKSIZE. Although it would be possible to construct a

Re: Program now working, but why?

In this case, because it is the behaviour of the header record (which for one I'm assuming is the first record), these would only be potential issues if the file only consisted of the header, no other records. Of course, the header record can be a coincidence. In changing the code, the size

Re: IBM SR process -- brilliant

If it is any help, I know of another ICN from IBM that probably doesn't have anything to do with what you are talking about. I guess even though extensive, the store of TLAs runs out, and they have to be reused, and reused again.

Re: Program now working, but why?

"My guess is that the call for the header record passed the record from the FD buffer. And subsequent calls pass the record after it's moved to WORKING STORAGE". If the AMBLIST output looks good (comparison of new to Production), then I'm pretty sure there is no direct problem with

Re: Program now working, but why?

Let's guess that the program is statically binderered/linkedited. Firstly, it is entirely possible that even 100% identical programs in Production and Test "work" and "fail". After all, that's how we get Production failures. So, same data, or not? You seem just ever-so-slightly guarded about

Re: DFSORT Extract records

Changing the data to match the condition, rather than changing the condition to match the data, is... unusual. Was the request to "also change any lowercase in the data to uppercase"? If not, it is easier, and less resources are used, to just change the search value, as suggested a couple of

Re: COBOL/LE question

The IGZ0268W is a warning message (no kidding). If your are using up to Enterprise COBOL V4.2 (which you are), it is just a warning that some time in the future (going to V5+, or perhaps with some future LE) you *will* have a problem. If you are using V5+ (which you are not) it is a problem

Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0=

On Mon, 30 Jan 2017 09:27:36 -0800, Tom Ross wrote: > )? (Msg IGYOS4021-W) > >>We are beginning the transition to COBOL V5.2 from V4.2 and exploring the n= >>ew options available for debugging. > >>We just discovered that the INITCHECK option is incompatible with

Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)

"Actually, Tom Ross in his migration presentation recommends this procedure:..." Yes, unfortunately that was May 2016, and INITCHECK appeared in September 2016. The reference I was making was to the V6.1 Migration Guide. The advice seems not to be in the MG for V5.2, although INITCHECK is

Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)

On Thu, 26 Jan 2017 20:56:27 -0600, Mike Schwab wrote: >Initially, the numeric / zero checks would not work like before. I >know there is an parm to make it work like before in 6.1. Not sure if >they applied it to 5.2. > >IBM Cobol Documentation page. Click on Version

Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)

Although I can't see it documented, I suspect that INITCHECK can only be offered as a side-effect of the complex analysis which is already done for the higher levels of optimisation, and which is not done at the lowest level of optimisation (OPT(0)). The message is probably correct, but the

Re: Cobol and PreCompile for CICS and DB2

I'm not quite sure what you are asking. Do you mean, which release of COBOL first included the integrated CICS translator within the compiler itself? Or are you asking something else? -- For IBM-MAIN subscribe / signoff /

Re: VSAM: Why MAXLRECL?

With the paucity of information in your original post it definitely seemed an... odd... idea. I hate being "near" limits. To give an example, you have found something that says your can have 32761 for your data in VSAM (before extending yourself), and yet you can't have that amount of data for

Re: "task level" TIOT & XTIOT? A crazy thought?

And what would you want in data-name-1? A DDNAME,like the PL/I? A data set name? A partial data set name (with some magic for full expansion)? Something else? What do you feel, with your selected option for data-name-1, would be some example uses for this? Again, for me, just because

Re: COBOL5 and ceedump

Yes, a deliberate area left specifically to catch any overflow and for no other purpose, similar to a patch-area. Technique arises before SSRANGE exists. If SSRANGE were subsequently used, it would/could catch the problem, but it is not as simple as the APAR text makes out (from memory of the

Re: AW: Re: COBOL5 and ceedump

There is a conflation of two issues, with the first being in two parts. Issue 1) Part a) Can't define enough storage for a table due to COBOL limits. This is only an issue for "old" programs, where limits for table-size were imposed by the compiler. The "expedient" approach was to define

Re: AW: Re: COBOL5 and ceedump

See also here, where a policy-shift was revealed (towards the end of the thread) to consider replicating V4 results where reasonable. https://www.ibm.com/developerworks/community/forums/html/topic?id=0f54483b-6f83-441d-a5fc-22a3d333dddf=25 Ironically this has included deliberate replication of

Re: AW: Re: COBOL5 and ceedump

Unfortunately an old technique was still in use, and hit many clients. See here for some detail: https://www.ibm.com/developerworks/community/forums/html/topic?id=c476d2c9-0d4e-4073-97c5-6384d8f381c0=25 -- For IBM-MAIN

Re: COBOL5 and ceedump

The full "Fix list for Enterprise COBOL for z/OS" for V5+ is here: http://www-01.ibm.com/support/docview.wss?uid=swg27041164 This is segregated by compiler release/version and also includes the runtime (Language Environment).

Re: COBOL5 and ceedump

On Sun, 8 Jan 2017 18:51:14 +0200, Steff Gladstone wrote: "In a COBOL5 CEEDUMP, how do I locate the *index* of an array (i.e., an array that is defined with "indexed by") in >the dump?" If you consult the "* * * * * S T A T I C M A P * * * * *" in the

Re: Fwd: Apache Spark on z listserver or forum?

StackOverflow and other StackExchange sites (like SuperUser) are Question and Answer sites. That doesn't mean they don't work, it means they are different. They are not a Forum, nor a Mailing List. On SO you'd ask about programming. On SU about setting up software. You'd get answers. Which are

Re: IEC141I 013-A8: how to read VS data sets?

le" (file mark). Something like that. I could be wrong, having made the assumption (which seemed to be borne out by the experimentation), I didn't research it. On Fri, 6 Jan 2017 15:41:53 +, J R <jayare...@hotmail.com> wrote: >Sent from my iPhone > >> On Jan 6, 2017, at

Re: IEC141I 013-A8: how to read VS data sets?

omething but did not diagnose but coded-around, and probably other scenarios, will be down to the actual data and program. For ordinary sequential reads, nothing with DISP=MOD is problematic (assuming that RECFM/LRECL are consistent with how later used). On Fri, 6 Jan 2017 14:55:22 +, J

Re: IEC141I 013-A8: how to read VS data sets?

All the documentation I read suggested that a latest incomplete track, when present, is not written to with DISP=MOD. My experiments bore this out. It is possible that I misread everything and borked all the experiments. I can perhaps re-check at some point if this (MOD backfills empty space on

Re: IEC141I 013-A8: how to read VS data sets?

On Fri, 6 Jan 2017 07:12:52 -0600, Tom Marchant wrote: [...] > >>As far as I know, it is simply that guarantee that is the difference, >>so it can be acted upon. S meaning "this data set has not been >>MODded > >Are you sure? I'm not sure, but I thought that MOD

Re: IEC141I 013-A8: how to read VS data sets?

The S in FS is the same "standard" as the S in FBS. With an F which has been MODded there will, mostly, be an unfilled track (last record on from the previous output, empty remainder of track unless the record happens to be the last one which would fit on a track). FS guarantees (by the person

Re: IEC141I 013-A8: how to read VS data sets?

Yet in modern times the S for F has its uses. If a C/C++ program is going to use a "seek" for a file, if the file is F/FB, then the file will be read from the start to satisfy the seek (because there may be those embedded short blocks), but if the file is FS/FBS (guarantee, by the person who

Re: IEC141I 013-A8: how to read VS data sets?

Paul, For QSAM, there's F/FS/FB/FBS, U, V/VB, VS/VBS that you may see used in a business system (and business systems, in the main, are the reasons for having a Mainframe). All have their specific "it's better in this case to do this". Of these, VS/VBS is the slowest way to read or write

Re: Addressing Question

ALL31(ON) is only relevant for dynamic CALLs, and it is as Frank has described - no switching, and if you CALL an AMODE(24), dynamically, you'll likely break. Your resultant loadmodule is less than 16MB, and, when loaded, fits within the available memory below the line. How close you are to

Re: Addressing Question

No. Your CALLs are static. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Interested in portable mainframes?

"Eating your own dogfood" is apparently consuming (only) your own, poor-quality (in relation to other things available) software. "Drinking your own Champagne" is a proud counter, that you use your own products because they are the best. IBM used the phrase, coined in 2007 apparently, in page

  1   2   3   4   5   >