Nice, thanks.
However, "Drinking your own..." as the beginning of and expression doesn't
come, for me, with "autocomplete" for "Champagne", but something entirely
different, and which would not be generally considered a "good thing". Strange
that the original coiner apparently uses it in
Preamble, preamble, preamble. Wow. Err... EEEK! Eck, yeck, blech. Postamble.
Postamble. Postamble.
That paragraph, which you can each fill your own words in for, means "when the
man trusts me to do a SYSGEN, then let the techies loose on application
programs".
Really, guys, I have great
Not a small subject if you are talking Value Added Tax in the European Union.
There is no sensible way to store the current values of these other than a
file/database. With an "application" to allow maintenance.
There are/can be multiple VAT codes, with multiple VAT rates. They can change.
All
As I understand it, Scott's COBOL programs are all 31-bit addressing. It is the
Assembler programs which are not.
If any of the COBOL programs happened to be located outside the 24-bit range of
addresses, the thing would stop working, or certainly not work as expected, as
return-address and
Freudian Slip?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Thanks. I think you are probably "getting away with it". Since you are not
using any data from a COBOL program, that DATA(31) is not an issue. I suspect
in your bindered program, the COBOL programs are always "below the line", so
the return-address is not getting accidentally truncated. I think
As came up in a recent discussion here (Lizette's small COBOL program thing),
IBM's recommendation is to use CSI over parsing LISTCAT. LISTCAT output is, and
has been for a while, open to change, even a breaking change, and we've been
warned.
What is the value of the Language Environment option ALL31? With ALL31(OFF), an
LE run-time routine will deal with AMODE switching between CALLs.
If any of the Assembler programs are accessing data from the COBOL programs,
those COBOL programs should be DATA(24) (you claim DATA(31).
Can you be
The problem with attempting to use an LE Handler from a COBOL program, as was
covered in the previous topic, is that LE knows that COBOL doesn't "respect"
the 00A, so LE just spends some time ignoring it, rather than presenting it to
a registered handler.
So for inter-language communication to
Yes, I was not explicit. As your previous attempt with * in column one showed,
the label must have a "command" on the same line. If one-to-eight characters is
enough for you to distinguish your multiple operations, and you could live with
the gobbling of characters from your command, then a
Thanks Jim Mulder.
Perhaps you can provide guidance if I explain what I thought I was doing.
At times there's a bit of code which "runs like a dog with no legs". There will
usually be several options to deal with it, but to actually land on which is
"better" you need to know how they perform
If you only need to be able to differentiate, how about using the "label"?
Starting in column one and extending all the way to column eight if you need
it, just make a reference (more contracted than your comment may have been
intended to be) to each particular execution.
What functionality of
In my rush to exchange an Electronic Arts (EA) PS4 game (don't, anyone, ever,
mention their idiotic policy on their product for sale in Poland (the
"international version" has Polish, amongst many languages, including the two
my son would be interested in, English and Portuguese, the Polish
How to time COBOL code blocks, prompted by John McKown's "how to: convince
programmer something else is better.":
See here: http://ibmmainframes.com/viewtopic.php?p=294906
The main reason for including the link is to show the program nicely formatted.
Here's the post, in case the link-to
Sorry, by "ordinary applications" I meant "non-systems' software". Stuff wot we
write.
I'm not commenting on whether it is a good or bad policy (because in isolation
you can't tell), I'm just saying there are sites that prevent/limit its use
without specific "authorisation". I think there's
For reasons of control, some (many?) sites prevent/limit the use of INTRDR by
ordinary applications. Why? The potential for "nefarious" use. Even the
JOB-which-submits-itself and variants, by accident or design.
--
For IBM-MAIN
You mean use DFSORT? Executing ICEGENER with control cards will cause IEBGENER
to be executed (because DFSORT isn't IEBGENER) and any comments would then
behave as they do with IEBGENER.
DFSORT can have asterisk in column one, "label" in column one (which can be
used as a "one-word" comment),
If your average buffer-length is 100 (think compressed address), there's a
three-percent CPU reduction irrespective of anything else (all processing is
otherwise identical), grows with a smaller average, reduces with a larger.
Depending on what is within the IF (it may be, and I'd hope is,
It is built in to lots of places.
The idiocy arises (or only should arise) with the idea of transferring of
"non-character" data between systems - packed-decimal, binary, even, for
supreme idiocy, floating-point - so that a "field-level" translation is
required of the "character" data. Then
I use the google thing to access IBM-MAIN (for reading) and "reported abuse"
for those two posts. Happy to say that by the time I got email from the fool to
my own account it was already directed straight to my spam-folder. For good
measure I "blocked" the user as well, but since all that does
Assuming your site "bought all the bits", it *will* look like a Mainframe. See
here,
http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.eclipse.infocenter.studee60ux%2FHCOMCMCBLKS005.html,
for accessing "MVS Control Blocks" for JOB and step information.
There's even
Micro Focus COBOL can be configured to "work like Mainframe COBOL": it can be
used for "off Mainframe" development for a Mainframe target (requiring
recompile) and for "migration from Mainframe with as few changes as possible".
I'm not saying it is perfect, but with V3 it should be very good.
If I remember correctly, John, you are on an Enterprise COBOL V3 compiler,
which has a 16MB size-limit for tables (V4 upped that to 134MB, V5+ even more).
Just to check, the compression is only for DASD saving? There's a slight
possibility it also used for getting around that limit. Assuming
Note that in the future, ABO will be able to deal with V5/V6 (and onwards)
executables, and those will for sure need PDSE.
There are some PDSE requirements for PDSE, not for executables, they are
documented and have been mentioned here in recent topics on ABO.
Summary of Changes indicates no change related to PDSE.
Executable ABO output do not require, and have not previously required, PDSE.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
32760 is the maximum blocksize. You have an LRECL of 32760, which is not at
least four bytes less than the maximum blocksize.
The RC for the message goes up steps of four, and is already busted. Other RC
values have multiple items. Some are not even inclusive, and probably can't be.
I think it
Combine Lionel's and Chuck's points about "support" with "every time someone
has been looking at a problem for three days and arrived nowhere, they're going
to blame the compression/decompression/(depression), just because they can't
find out for real why something isn't working".
Why is
According to the marketing literature, it does binary.
Both Raincode and IT-COBOL are partners. If a binary doesn't work, you go to a
COBOL-IT recompile.
They have a demo-film for batch, with this stern and impressive prologue: "The
recording has not been edited or shortened. Everything you
Urban Dictionary (one of several definitions)
frig
(Term used by engineers) To make a rough-and-ready, quick-and-dirty adjustment
to something to make it work or to make it operate in a particular way. To
adjust manually for a particular purpose. Can be used of a physical device but
also of
More computing history. "Frig". No, it doesn't mean what those across the water
may think. A particular UK-computing term, not sure of the origins, and it
certainly "surprised" me when I cam across the use of the word as a 17-year-old
trainee who happened to know the "other" meaning. "I'm going
So that would be an ordinary 80-byte SYSIN, data within 80 bytes. Not what Paul
is trying.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
I never thought I'd see film of "the flick", for manual bursting of fan-fold
paper, on YouTube.
"Characters" is not a surprise. The man with the company cheque-book probably
wouldn't know a byte if it bit him.
--
For IBM-MAIN
For clarification, my comments were largely pasted from the docs :-)
As I read it, the information, whatever it is, from the hardware is
"definitive", and for the appropriate VALIDATE some Control Block(s) will be
updated. There may not be a devil in the detail, but there may be some complex
"In addition, there is one action parameter, VALIDATE" says the documentation.
That, coupled with "VALIDATE has no effect if the unit address has no physical
device attached" is a pretty strong indication that there is an actual effect
from VALIDATE.
"Use the dump selection parameters, to
Unless Sir Nose d'Voidoffunk his wielding his Snooze Gun, you mean defunct, not
"defunked". Just sayin'.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message:
The photo is a rare insight into IBM's early R on the concept which later
became the Smartphone.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO
Thinking a bit more, even though there may be parts, bits and pieces of C/C++
code to do with the COBOL program (and supporting routines) anything in the
COBOL program is of course "COBOL" and any "COBOL routines" I'd imagine would
also be treated as "COBOL" by LE.
So I think it reasonable to
Denis,
Thanks a lot, that's useful to know. A genuine moment for me to say "thank you
for sharing".
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message:
>I'm kind of alerted by the statement "Cobol V5 always uses C". That means the
>decimal overflow mask will always be set after the first (internal) call to C
>code?'
>
>Can you be more specific on it means that "Cobol V5 always uses C"?
Interesting questions. I don't have access to V5+, so
Are you running LE with TRAP(OFF)? That's the only way I know, yet, of getting
the S0CA from a COBOL program. See the discussion here:
https://www.ibm.com/developerworks/community/forums/html/topic?id=a639cb05-5604-42ab-95da-2a77dfccadbf=25.
There was an RFE raised, which is currently an
Venkat,
Can you please clarify exactly what you want to achieve, what point you are
trying to reach? By "TSO" do you mean, as Paul suspects, you need direct,
immediate, access to a TSO prompt for some long-superseded limit on some
requirement from years 'n' years ago? Or do you, by "TSO", mean
Interestingly, a recommendation form IBM (under "DFSMSdfp: Accommodate changes
in LISTCAT LEVEL output"):
"Take steps to convert any programs that rely upon LISTCAT output to use the
Catalog Search Interface (CSI) instead. CSI is a supported general-use
programming interface for the catalog,
To access the files you will need to use "dynamic allocation". There's a couple
of methods, and some search-engineing for Tom Ross COBOL Dynamic Allocation
should get you some working examples.
I'd LISTCAT to a data set, and read the data set in the COBOL program. Gives
you a fixed point, a
COBOL has had XML parsing for a while, and has generation. Of late it uses the
z/OS System Service. For JSON parsing (parsing only so far) it also uses the
existing z/OS System Service.
So Enterprise COBOL has native parsing/generation for XML and native parsing
for JSON. It has nothing native
CSV has been around a long time (I certainly used them in '91, and perhaps
earlier). It for sure would be good to have native COBOL support, but 25+ years
without it may indicate it is not much of a priority. I'd support an RFE, but
not lose any sleep about it happening any time soon.
I don't
The only real problem with delimiters is when the delimiter can occur in the
data. Often a good reason for avoiding commas. Tab can be good, as long as the
data cannot contain tab (unlikely for Mainframe data).
Delimiters in the data can be "protected" by enclosing the data of that field
in
Can you confirm that it is only the JCL being changed to fix the problem?
I'm not sure you'll find others with experience of this, because it is
difficult to envisage why it was done, or how it happened, in the first place.
People may have encountered individual problems with this, but I can't
It seems like a strange problem to affect a lot of programs (for instance,
fixed-length in program, variable-length in the JCL).
Assuming that all the OS/VS COBOL programs work, I think it would be reasonable
to expect that all the Format 1 DSCBs match the definitions in the COBOL
programs.
"(The last letter is in packed decimal x'c1' in this case.) "
Not sure what you mean by that. x'c1' isn't packed-decimal.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu
There's a NOPRINT option, which you should be able to specify, perhaps
indicated by the OPTIONS=. If there's no convenient way there, there is a SETO
function. However, if you are using the other messages in your exit (rather
than just ignoring them) this probably won't help as I think it will
Ah, I love doing that as well.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Thresh it out/Thrash it out are very similar.
The latter has some connotation of two sides and a more contested debate (more
to the subjective than the objective).
The former would be more like here. Get a lot of information, toss out what is
indigestible, and hope that the gluten-intolerant
>Why do you want a VB data set with all the records the same length?
You've answered a different question.
The reason for asking was not "that's an impossible scenario, no-one in their
right mind would ever want to do that", it was an attempt to elicit what the
requirement at hand is. The
Perhaps I could have been clearer: If, with EXEC PGM=IEBGENER, your SORT
product is used (because IEBGENER is aliased to ICEGENER), you will see ICE or
WER message prefixes (prefices?). If, instead, in that invocation of IEBGENER,
"IEBGENER" was used (because SORT could not be used), then you
If, with EXEC PGM=IEBGENER, your SORT product is used, you will see ICE or WER
message prefixes (preficies?).
You want to copy an FB to a VB, with no further changes? Why? The point of
variable-length records is that they are... variable in length? All yours are
going to have the same length,
Peter, yes, you are correct. I was thinking too narrowly, of TIME= from the
JOBCLASS being the same or longer than on the JOB, as stated in the question.
I liked your bucket analogy. A longer JOBCLASS TIME= than JOB TIME= will not
allow a step to run for longer than what is on the JOB card.
Yes.
The TIME= from the JOBCLASS only affects any EXEC which doesn't have an
explicit TIME= (all of yours). If you put TIME= on the JOB card, then this
trounces the JOBCLASS TIME=, and none of your steps, either the first step or
in total, can exceed the TIME on the JOB card.
(you've not
There's a useful description with examples here:
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieab500/iea3b5_JOB_and_EXEC_TIME_parameter.htm
I didn't know that about the EXEC of a PROC.
How it works must hark back to long ago. You booked your time to use on the
Then there's the question of "testing". If attempting this on 14m records, it
will SORT them all before the SUM fails (and you may have got unlucky with the
previous values in the "filler").
To see what the OVERLAY was doing, take out the SORT and the SUM and run on a
test file (even the full
INREC OVERLAY=(280:C'001')
Default of a column is not specified for OVERLAY is column one. Your Control
Card is saying "overlay at position one, position 280 for a length of 11,
followed by 10 zeros and a one.
--
For
Do you need to reacquire the storage, or does the LE dump routine hang around
for the second-time-through?
Would it be possible to load the LE dump routine instead of doing the initial
GETMAIN? And your own routine?
Do you have issues with something else looking for storage while you are
Are you able to change the program?
Are you able to compile with SSRANGE?
Are there any CALLs to the program, or by the program?
SSRANGE will take care of any reference-modification/subscripting in the
program in question.
Test the storage (that you know gets whacked) on arrival and
Yes, no articles in Polish.A tendency for those who have no actual exposure to
English to pronounce every letter in every word. And the entirely obtuse
proposition of pronouncing all the letter "r"s in English words.
And you think that's an "L" in Radoslav's name? In the town he works in? In
Agreed apart from "the means". The original topic: "Does anyone know if this
product, Automatic Binary Optimizer, will actually migrate Cobol V4 to V6 for
you? Our IBM reps are telling us that it will actually do the migration for
you."
100 different people contacting the "ABO Team" is also
Thanks Ed, that helps. So a typical "old style" PTF for DFSORT, which added
several new functions to the product would have been an SPE, either by name or
by fact.
And, even with the OS on a two-year release cycle, new functions (for anything)
can be provided (delivered) at any point
That sounds good, but "continuous delivery", beyond fashion-speak, means
specifically what? DFSORT used to provide new functionality through PTFs. Does
it mean that, and at a faster pace and in smaller units, or something,
specifically, different?
And whatever it is, is it across all products
Yes, let's add Literature into the pot as well...
The thing is, once a COBOL program is compiled, it is no longer a COBOL
program. It is no longer at the whim of a misplaced full-stop (period),
oblivious to whether a SECTION has been coded or a THRU has been used, the GO
TO superficially
We continue to add things to the bubbling pot that is a discussion started
through the misunderstanding of some IBM sales staff.
Tom Ross ventured close, dipped a spoon in the pot, and confirmed that there is
no "source conversion" process for migration to V5/V6. Mmmm... he's either
writing
Vigilio ,
I think you've posted to the google groups rather than the listserv itself, so
perhaps many people won't see your post.
I poked your message id into a search box, which gets to the IBM Knowledge
Centre which leads to IDC3009I, which has your code, with explanations per
reason code.
There are a number of different items within this topic.
"Just a recompile", where the object is expected to be identical,
regression-tested?
To my mind, no. It should be verified as identical. If it is not, the reason
should be identified and what follows depends on what is found out.
I
Here's Tom Ross:
https://www.ibm.com/developerworks/community/forums/html/topic?id=6d98d469-5088-41ec-8926-34e945443891=25
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu
Well, if so leaky, let's hear a few.
ABO does not know about PICtures. One of the limits to the optimisations
available to it.
Strictly, it could intuit some things, but it can't, because of REDEFINES large
or small.
--
For
Great. Now we've got PL/I and Assembler in the mix.
I do absolutely agree with Prino on "same everything throughout", at least
after program testing. There are assorted (and growing) compiler options which
should only live up to program testing (although there is not universal
agreement).
"As to re-testing after recompile, if the resulting OBJ is the same, sure, no
need. When can you expect that? Probably rarely, but that's only because there
are often dates present in the output. So ignoring changes due to compile-date,
changes in macros could affect things, so assume none of
"I believe COBOL V5 stated that recompile would work for correct programs. I
don't know if that statement is true or not, or what exactly is definitively
meant by "correct", but I think that ABO's more conservative approach is
expected to work even for programs that do not work upon recompile
Splitting up the replies.
"If by "certified" you basically mean "proved to be correct", how many
realistic programs are ever provably correct (many non-realistic programs
could be)? Surely a lot *are* correct, but could you prove it? I suspect
that most software companies "warrant" (if an error
Peter,
The RC=4 thing was not directed at you. I don't think anyone with "experience"
(being counted as just turning up for years, or "one year of experience many
times") would be contributing to this list.
I'm pointing out that "RC=4 is OK, get on with the test" is reasonably common.
And
On Thu, 13 Oct 2016 16:44:42 -0400, Tony Harminc <t...@harminc.net> wrote:
>On 13 October 2016 at 14:47, Bill Woodger <bill.wood...@gmail.com> wrote:
>>
>> No, it doesn't turn the machine-code (ESA/370) into anything intermediate.
>
>Are you quite sure?
Why ICETOOL?
It is a DFSORT COPY operation, with a BUILD on INREC.
OPTION COPY
INREC BUILD=(starta,lengtha,startb,lengthb,startc,lengthc,startd,lengthd)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send
Peter,
You started with this: "Any program change requires full regression testing,
including "just a recompile"." I'm saying that paying "lip-service" to audit
requirements, and not confirming that the programs are exactly the same, is
heading (potentially) for exactly what you don't want. If
Tony,
"But the ABO product is certainly not just translating individual old
instructions into newer ones. Rather, it is surely identifying COBOL paradigms
based on some kind of pattern matching, and then retranslating those COBOLy
things into modern machine code. Presumably it effectively
Peter,
For a recompile, where the program is not expected to have changed even one
iota, a regression-test is a very poor substitute for verification. I'd be
amazed if your tests would be extensive enough to pick that the program was
different, whereas a comparison (masking or "reconciling"
Closest to a guarantee is: "That may depend on how you take this claim: "[ABO]
... produces a functionally equivalent executable program"."
I've taken that from a post of mine in the March 10 discussion here started by
Skip.
The Stupid PERFORM broke that.
Well, it's an excellent question Tom, but needs to be directed to people at
sites that do that :-)
Pushed for an answer, I'd say "no". But, if you have and it ends up being
the same asnwer as for ABO, which is why you've posed the question.
IBM actually recommends slapping OPT on three
I'm not saying just instal the ABO and get on with it. I'm talking about
per-program, beyond an initial "proving" stage (of the procedures for working,
implementation, gauging actual improvement with actual programs, including even
detailed work on "beast" programs). I'd also expect "parallel"
The logic is that if you've already ABO'd X-number of programs, you need to
check for the stupid PERFORM.
If located, fix the damn thing, then and there, test it, regression-test it,
get it completed.
Before ABO'ing, even if the code will "work", it is still garbage code (not
ABO's fault).
Recompiling a program with no changes. Do you "regression test"? No.
You compare the object (masking the date/time). If it is the same (as in
identical) - what would a regeression-test show?
OK, compiler may have been patched. Doesn't matter. The executable code
generated is the same.
Well, I'm still going to disagree on the level of "testing" required.
You (now) need to check for the stupid out-of-order PERFORM ... THRU ... but
otherwise you are good to go.
--
For IBM-MAIN subscribe / signoff / archive
Fix list for ABO.
http://www-01.ibm.com/support/docview.wss?uid=swg27047229#28062016
Looks good... except for one thing:
http://www-01.ibm.com/support/docview.wss?uid=swg1PI68138
"
* USERS AFFECTED: Users of the IBM
I suppose the cunning thing to do would be to write it into the contract, then
you get IBM to do the migration to V6 "for free"...
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
Mmmm... I wonder why they would say that?
It takes the existing executable code of your Enterprise COBOL programs and
optimises them for new instructions available on ARCH(!0) and ARCH(11).
So if you hardware is up-to-date or so, it gives you a route for existing COBOL
executables to take
The Sharky seems to be a "column" type thing. The "fish" are the people who
provide the stories. Reality-check not required, as long as the story will be
"popular".
--
For IBM-MAIN subscribe / signoff / archive access
I think there's at best a great deal of "faulty memory" here. Something was
nagging, so I just did a bit of research. COMMAND.COM in the late 80s was way
smaller than 65K.
Remembering that a backup copy has been saved, what did the clever PC expert
do? Deleted the backup, and copied
INITIALIZE OUTPUT-RECORD
(followed by code which MOVEs values to each field in OUTPUT-RECORD)
INITIALIZE PRINT-LINE
MOVE HEADING-LINE TO PRINT-LINE
MOVE SPACE TO SAVE-INPUT-RECORD
MOVE INPUT-RECORD TO SAVE-INPUT-RECORD
INITIALIZE INPUT-RECORD-AREA
READ INPUT-FILE
I think with V5+ the optimizer
Yes, so far looks good. Need to see documentation.
Waiting for its counterpart, INITSTUPID, for where data is initialised, and
then next reference is as a target.
--
For IBM-MAIN subscribe / signoff / archive access
The reserve seems to be used as the new stack segment, and anything else can
still gobble it up. Gets a U4008 with 1004 not a 1024 apparently. A larger
reserve may help if you still have things acquiring storage.
But then you didn't get a U4008.
Does the production of an LE Dump acquire
Non-batch, I assume. Whilst your "news" are sucking up memory, almost anything
else asking for more memory could fail, couldn't it? Not just one of yours?
Do you mean CEE3DMP? CEEDUMP is just for setting the options for am LE dump.
TRACE=N?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
The use of CBL/PROCESS cards can be prevented at installation (ALOWCBL=NO).
The values of individual compile options can be fixed at installation (so can't
be overridden by PARM or CBL or anything else).
See Chapter 1 in the Customization Guide.
And I was having a problem getting to the Knowledgecentre. On seeing your last,
I checked again, and it is working :-)
Message was "Service Temporarily Unavailable". I should have taken it more
literally.
--
For IBM-MAIN
101 - 200 of 424 matches
Mail list logo
