all previous snipped
Because there have been all sorts of notes on COBOL and setting the COND
CODE (if RETURN-CODE) hasn't been cleared, I thought I would post a
reference to:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg31/4.2.4.1
Now, I will admit that I could be
As far as I know, all currently available z/OS releases (that include LE)
support object code created by all IBM PL/I compilers. For some
information, check out:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea2170/1.1.1
for those compilers that REQUIRE an LE run-time.
For
Check out the chapter,
Communicating between C and COBOL
at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA4150/4.0
cnps [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Hi,
I am trying to call a C routine from COBOL pgm.
I have few questions.
Is it
If they have 24-bit COBOL under CICS programs, there is a really GOOD
chance (but bad results) that the source code was compiled with OS/VS COBOL.
(I can't think of ANY reason to have 24-bit VS COBOL II or LE-conforming
COBOL under CICS).
If so, then there are SIGNIFICANT changes to the syntax
all snipped
John,
Did ;you ever reply to my suggestion of calling CEE3DMP (with STORAGE set
- NOSTORAGE is the default) from within your Java program? It would seem to
me to be the best/easiest way to get a storage report - even if you are
having problems getting your application to terminate
(all previous snipped)
While researching something else today, I cam across the following in the
CICS (not LE) documentation,
Using DFHJVMRO to modify the Language Environment enclave for a JVM
at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dfha3b01/3.17.2
Although it is
John,
Can you modify your program (or create a test one). If so, you might want
to try calling CEE3DMP from it - and it will show you the STORAGE settings
in effect - under JVM. See:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea1170/1.3.2.4
for both the sample source code
I know that someone has already given one of these references, but the two
places that I would start (given the information you have provided in the
thread) are:
The Performance tuning paper (which application programmers can EASILY read
and understand) at:
Sent to various distribution lists (sorry about any duplications)
If you are interested in IEEE's draft standard for decimal floating point
(and related topics), please note that they have extended their deadline to
try and get an even broader audience for the upcoming ballot.
-Original
Discussion List On Behalf Of john gilmore
Bill Klein provided the necessary reference, to wit
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3c130/3.4
If you consult it, you will discover that the [COBOL]
compiler needs to be authorized iff it is to occupy shared
Neither Frank, nor IBM, nor anyone from Syncsort is likely to say this, but
my PERCEPTION is (and has been for the last couple of DECADES) that as far
as functionality goes, the two products tend to play leap-frog, that is,
that whatever one introduces, the other provides a comparable feature
I don't think the compiler needs to be authorized - but you may want to
check out
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3c130/3.4
for relevant information
Ted MacNEIL [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
00.bisx.prod.on.blackberry...
Why does the
I think you are a bit confused. I don't think that those are EVER LE
options. They look (to me) as if they are a combination of compiler
(possibly COBOL) and Binder options. Also, I haven't ever heard of any shops
(in the last decade or so) that are concerned about compile or bind-time
Neither COBOL nor IBM's COBOL *guarantee* a S0C7 (or other abnormal
termination) when you reference incompatible data - all they promise is
results are undefined.
Having said that, try your sample with both ZWB and NOZWB. See:
For some reason (that I have never understood), IBM treats this as for
internal use only. If you look at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea1170/2.2.3.4.
3
It says,
The FCB, FIB, and GMAREA are control blocks used for COBOL file
processing. These control blocks
To IBM-MAIN and (old) LNGC distribution lists
IEEE has been working on a new (draft) floating-point specification that
includes DECIMAL floating-point. IBM has been involved in this and I would
expect either software and/or hardware support in the OS (and eventually
some compilers) sooner than
As someone who usually (almost always) only tells people to use documented
and supported interfaces, I almost hesitate to mention this. HOWEVER,
There is a currently TOTALLY unsupported and undocumented (it was documented
in VS COBOL II, R1.0 - but never since then) feature that MIGHT give you
So many responses, so many misconceptions:
1) On NUMERIC moves, alignment is along the decimal point (implicit or
explicit) and padding is with zeroes not spaces.
2) COBOL does *not* initialize COMP-3 fields to binary zeroes when no VALUE
clause is specified. However, the STORAGE LE run-time
I am curious if anyone can help me track down WHY so many sites are getting
the wrong information about z/OS LE V1R7 (or any release) NOT supporting
OS/VS COBOL and VS COBOL II compiled object code.
Is this some presentation somewhere? Some IBM or other document? Something
being said by some
TRUNC(BIN) *definitely* has performance implications.
If you compile with TRUNC(OPT) have USAGE POINTER fields redefined or have
other reasons that you want binary fields with the MAXIMUM available size
per the storage, not the PICTURE, then define the fields as COMP-5. This
avoids the overhead
The answer (as I understand it) is that if the information is NOT published
- then it is not a general use interface and you shouldn't be using it.
IBM does accept requirements for providing interfaces to information that
THEY think will be stable across releases AND that users (vendors,
whomever)
I got confused earlier in this thread. I thought the original report was
that running the original PL/I program on you PC caused performance
problems. I now think the report was that using COBOL caused the problem.
If it is COBOL having the problem, then check the following compiler
options:
If this was supposed to be an answer to the can you run VS COBOL II
programs, this is just plain WRONG. You absolutely should NOT use a
STEPLIB. Use ONLY the LE run-time modules built in to LE.
(Sorry if this was in answer to something else, but too much was snipped)
Brian Westerman [EMAIL
yes, someone can.
The Enterprise COBOL Migration Guide will tell you which programs need
re-linking (if any); what restrictions exist, etc. see:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3MG31/CCONTENT
S
Rahul Balachandran, ISDC Chennai [EMAIL PROTECTED] wrote
in message
Hopefully, someone else will either confirm or correct me, but it is (was)
my understanding that the TZ environment variable *ONLY* impacts C/C++
application code. It does *NOT* impact the LE callable services for
obtaining (or impacted by) the timezone. I *know* that it doesn't impact
the COBOL
I don't want to get into either the:
Does IBM need to provide a 64-bit COBOL (for z/OS) compiler
- because of business needs of programmers
or
- because of what it says to their customers about COBOL
Nor
What is the current need for and what is the future of COBOL
/cgi-bin/bookmgr_OS390/BOOKS/IGY3MG31/5.4
NOTE WELL (for SysProgs)
As far as I can tell, there is no COBOL or LE ++HOLD information on
the
relevant APARs. I would be happy to be corrected on this perception -
if I am
in error.
--
Bill Klein
wmklein at ix.netcom.com
Just to clarify (and explain my earlier confusion).
I have now been told that the PTFs for both
PK15432 (LE)
and
PK16765 (Enterprise COBOL V3R4)
*do* have correct ++HOLD information. If you are interested in these PTFs
(and APARs) check out (long URL):
If you are using an (unsupported) pre-Enterprise COBOL compiler, then I
think the answer is pretty simple (and relatively well documented). See
(for example),
http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igypg205/3.4
You cannot run your COBOL program in more than one thread. If you
In COBOL terms there is a WORLD of difference between the 2 types of files,
but some comments (in general).
1) You really should start using the RECORD VARYING IN SIZE rather than the
RECORD CONTAINS n TO m - phrase in your FD. The former is guaranteed to be
a variable format file (all
How is the 01-level defined under
FD INFILE ...
If it is something like:
01 INREC PIC X(1500)
then you WILL have problems. If, however, it is defined somethink like
01 INREC.
05 INRE-BYTE Occurs 59 to 1500
Depeing on WS-REC-LENGTH
Pic X.
The the
Concerning READ vs READ INTO
From:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg30/1.9.1.1.
3
When you specify a READ INTO statement for a format-V file, the record size
read for that file is used in the MOVE statement generated by the compiler.
Consequently, you might not
I was hoping someone else would answer this. I am *not* an Assembler
programmer and I am not totally clear on exactly what you are doing.
HOWEVER, I can tell you the normal way of using Assembler subprograms to
play with file DCBs. (This does NOT work for VSAM and ACB's).
In your COBOL program,
(all previous posts snipped)
Until the original poster gets back to us with:
1) How the 01 under the FD is defined
2) Whether he is doing a READ or READ INTO (and if INTO how that defined)
3) What makes him THINK he is getting more than the single record)
I think it is useless for us to guess
Changing that stuff works very well if you use the technique that I
described. You put in an arbitrary Record Contains and/or Block Contains
in the COBOL FD - and then modify the DCB info in the Assembler program
that you call - passing it the DCB.
[EMAIL PROTECTED] wrote in message
news:[EMAIL
is NOT something
that I would ever recommend)
Steve Comstock [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Bill Klein wrote:
Changing that stuff works very well if you use the technique that I
described. You put in an arbitrary Record Contains and/or Block
Contains
in the COBOL FD
For clarification,
Bruce McKnight [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Now
we have Level 2000 (IBM calls it OS/390 COBOL and now Enterprise
COBOL). This specification expands the functionality into object
orientation. Most books that cover OO-COBOL (some call it
the stand-alone product
before Sept
5.
--
Bill Klein
wmklein at ix.netcom.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives
I know that others have pointed you to the place in the documentation that
explicitly states that OVR/NOOVR is not supported via PARMLIB.
HOWEVER, I thought that I would mention that it is my understand that not
only is this intentional, but that IBM has an undocumented statement of
direction
will be forced to
consider
in July if no one volunteers to serve as chairman of J4 before than will
most
likely result in the disbandment of J4.
For those interested in reading 06-0030, see:
http://www.cobolportal.com/j4/files/06-0030.doc
--
Bill Klein
wmklein at ix.netcom.com
Separate FMID - yes
Separate license - NO
Clark Morris [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
On 3 May 2006 13:32:02 -0700, in bit.listserv.ibm-main
[EMAIL PROTECTED] (Bill Klein) wrote:
I don't fully understand your question, but if you have the LE run-time
A couple things to say,
1) I think it MAY be impossible to tell if a VS COBOL II program is called
from an Enterprise COBOL main.
2) Looking at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3mg20/3.4.1
checking for IGZCBSN, IGZCBSO, IGZEBST *might* help, but I am not
Assuming you aren't porting the COBOL created object code to a z/OS.e
system, (and you are going to a system licensed with LE - which is part of
z/OS), then there are no restrictions.
If you are going to a z/OS.e system, then there are some (easy to get
around) restrictions, i.e. you need to use
I don't fully understand your question, but if you have the LE run-time,
that means you will be able to run OS/VS COBOL, VS COBOL II, *and*
LE-conforming COBOL.
If you have the VS COBOL II run-time, you will NOT be able to run Enterprise
COBOL compiled programs.
IBM (fairly clearly) documents
Sorry for the delay in responding. It has taken me a little time to get an
official response from my usually reliable source. I have now received
the following:
***
Yes as part of our Micro Focus 5.0 release of our migration technology
it features a JES engine so that JCL can be kept
This SOUNDS like a school project. If so, what does your text book show?
If not, exactly WHY do you want this type of thing? There are bunches of
teach yourself COBOL programs which have sample code. Check any of them
out. (Make certain that you get one that includes '85 Standard code, not
As others have pointed out, you really haven't provided NEARLY enough
information for us to help, but given what you have provided, I would
suggest:
1) Check your original (VS COBOL II) vs new (Enterprise COBOL) compiler
options. Particularly:
- RES/NORES (Enterprise COBOL only supports RES
. Unfortunately
I see
the only doc update requested was for the Data Areas manuals! I've made
a note
to improve the documentation about this.
Hope that helps,
--
Bill Klein
wmklein at ix.netcom.com
Steamroller [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi. The question
VisualAge PL/I for
WHAT PLATFORM ???
- If zOS, then it is Enterprise PL/I
- If Windows, then it is Websphere Developer for zSeries
- If OS/2, then no-where, no-how
Barry Schwarz [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Does anyone know where I can get information about an
Just a couple of COBOL sequential file issues that MIGHT impact this.
1) If the file is a variable length file, then make certain that you have
the AWO compiler options specified.
2) If you have any internal SORT statments, make certain that you have
specified FASTSRT compiler option.
***
Of you IBM COBOL types, do you have any opinions on any that I have
missed -
or that I have included that you think do NOT impact run-time behavior?
--
Bill Klein
wmklein at ix.netcom.com
--
For IBM-MAIN subscribe / signoff
See comments below for some of my responses. I thought I was clear that I
was NOT talking about performance or storage impacts. I think most of
those types of impacts are cases where you and I disagree.
Steve Comstock [EMAIL PROTECTED] wrote in message
news:442C6C2B.7020105
snip
-
I don't know what you wanted to hear from IBM. However, if your question
is whether differences between these options will change run-time behavior,
the answer is DEFINITELY yes.
1) TRUNC - is a compile-time option. Do you do compiles on both LPARs? If
not, a change won't impact anything. If
I made TWO errors talking about INTDATE
It is a compile-time, not a run-time, option. (So again, if you don't
compile on both LPARs, then it won't impact you).
Also, it impacts only COBOL intrinsic functions - not LE callable services
(but setting it to LILLIAN will make the intrinsic functions
Jim,
Not certain that it is releavant, but have you read the information at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3mg30/APPENDIX
1.4.13
also
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea4140/14.2.1
Jim McAlpine [EMAIL PROTECTED] wrote in
This is a follow up on an earlier thread in IBM-MAIN and a current thread in
comp.lang.cobol.
Has anyone TRIED using the built-in conversion facility of COBOL-to-Java
or vice versa for IBM Hex to/from IEEE floating point and had any
problems with it? If so what were the problems and what (if
Jim,
What IBM COBOL compiler do you have? What release of LE are you using?
The reason that I ask, is you are pointing to (and reference) the
IBM COBOL for OS/390 and ...
documentation which talks about the SOM based OO support in COBOL.
With Enterprise COBOL, there is a TOTALLY new (and
Jim,
Just to follow up (and as it took me a while to find this), the drop of
SOM based run-time support WAS in LE for z/OS V1.2. See announcement
Software Announcement 201-248
September 11, 2001
IBM z/OS Version 1 Release 2: Enabling and Protecting Your e-business and
Preview: z/OS Version
I thought that some in IBM-MAIN (who aren't participants in the SHARE DVLG
project requirement process) might be interested in the following note that
I just sent out.
P.S. For those of you who DO participate in SHARE and are interested in the
Binder - please make certain that you work with the
I assume you saw the paragraph,
Under questioning from Senator Fielding, Mr Farr agreed the local project
was based on old technology, but it is still very widely used for large
mainframe applications.
Any guess about what the author of this article things about THAT platform
(he asked
As far as (batch) COBOL goes, if this is an issue for your installation,
have your marketing branch submit a REQUEST for IBM to implement the (well
defined, but processor dependent) feature from the ANSI/ISO 2002 Standard.
In the REQUEST reference the SHARE requirement
SSLNGC0313596 RC 2002 ISO
I haven't seen any post yet pointing IBM-MAIN people (who may have missed
it) to:
_ 906027 Software Service Discontinuance: Selected IBM eServer zSeries
and S/390 products -- Some replacements available
http://www.ibm.com/isource/cgi-bin/goto?it=usa_annredon=906-027
and in
I would try the doing ALL of the following (at the same time)
- do the SQL preprocessor in a separate step (if the program actually HAS
EXEC SQL statements in it - otherwise use NOSQL)
- Change to SIZE(MAX)
- Change to NOSSRANGE
If - with those 3 changes - the compile still fails, I would
I just thought of something else (see below)
Alan C. Field [EMAIL PROTECTED] wrote in message
news:OF798E9B96.C165DDCC-ON8625710A.004C9571-8625710A.004CDEF
[EMAIL PROTECTED]...
Thanks for all the responses.
snip
* STATISTICS FOR COBOL PROGRAM xx:
*SOURCE RECORDS = 376159
*
First, I agree with you that a 140,000 line program is NOT a good thing -
but it certainly does occur in the real world.
If this is a CICS (or possibly DB2) program, make certain that you are NOT
using the
SIZE(MAX)
compiler option (as there needs to be room for the coprocessors).
As
The information that I have from a usually reliable source is that if
A) the program is not compiled with OS/VS COBOL
OR
B) if compiled with OS/VS COBOL but without STATE, COUNT, SYMDMP
then such a call is a NO-OP and can safely be removed.
If you still have an OS/VS COBOL compiled
A couple of responses to this (and to other responses to it).
1) As someone who was part of the original development team adding support
for OPT with Xpediter, I can assure you that ANY vendor who claims
predictable support for debugging OPT code, simply has NOT seriously
looked at the LIST
Kittendorf, Craig [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
The only COBOL compiler we have is: PP 5655-G53 IBM Enterprise COBOL for
z/OS 3.4.0.
Then you can safely remove all CALLs to ILBOSPI0 (as it is a no-op).
There are historical reasons why the situation reported by 97 couldn't
start with a 0. HOWEVER, if this is of importance to you, then submit a
request via your IBM marketing team G and reference the existing SHARE
requirement:
SSLNGC0413615 Optional (ISO 2002) 0x file-status code for current 97
For further information on (conforming) what Rich states, see:
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dfsaptg1/2.4.2.10
Specifically,
If the output MOD name parameter is not specified, IMS formats the message
using the MOD named in the MESSAGE OUTPUT DESCRIPTOR NAME field of
Just to clarify (and explain different answers already given),
to answer this question we need to know what you mean by HEX input and
DECIMAL output. If you want to convert binary stored data (often
displayed by its hex values) to packed-decimal output, then the approach
listed below is the
My *GUESS* is that you are running into a problem with the z/OS (or
OS/390) vs. VM issue.
IBM COBOL for OS?390 VM was the *last* release that was documented as
supported for VM *and* it is still in service (with no discontinuance - of
service or marketing) date
*FOR VM*
customers.
For z/OS
I *strongly* recommend using COMP-5 - just in case IBM ever allows for LARGE
parms (and this would work with any setting of the TRUNC compiler option).
However, COMP, BINARY, and COMP-5 should all work exactly the same as long
as MVS only allows for a 100 character maximum (and as long as you are
The last post mentioned CBLOPTS which does determine whether or not the
user data should come before or after the /. However, there is another
interesting (and new to me) comment at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea5160/2.2.2.8.
1
In the case of
/31-bit Amode Support
--
Bill Klein
wmklein at ix.netcom.com
--
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
I am confused. Is this still the case of where you are referencing data
that was NOT passed to the subprogram's Linkage Section? If so, I can
*guarantee* that there has NEVER been any documented support for Passing a
3-byte field and having the subprogram be able to get binary zeroes, spaces,
or
Victor,
You don't state what type of internal SORT you are using, but if using
COBOL, the following referenced (and pointed to pages) MIGHT be useful (for
DFSort).
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg30/1.12.15.
1
Victor Gil [EMAIL PROTECTED] wrote in message
You haven't told us FROM what release of LE you are upgrading. Am I correct
that you are JUST moving from one maintenance level of LE 1.6 to another
maintenance level? If this is true, then the following SHOULDN'T be the
issue, but just in case, have you looked at the favor 31-bit information
Exactly what conversion are you doing? (LE? COBOL? z/OS? hardware?
other?)
If the conversion is for COBOL, then there really is almost NO conversion
necessary (depending on your exact environment). See:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3MG30/3.2.2
You might also
Sounds like it is time for you to read both the COBOL and LE Migration
Guides.
Short Answer(s):
1) OS/VS COBOL code runs fine under LE and, in fact, migrating to LE for
your run-time and link-edit libraries SHOULD be your first step. (There are
some gotchas - but I won't go into these in a
How about the always popular, answer a question with a question,
Do you care if the JCL gets a JCL error or not?
Jon Brock [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
My answer would be, Why do you want to know?
Jon
snip
Here in my office there is a crazy DB2 admin
If anyone DOES create a SHARE (or similar) IBM requirement to
automagically convert PL/X to HLASM, COBOL, etc, you might want to
reference the EXISTING (so far going nowhere) SHARE requirement:
SSLNGC0313582 Assembler DSECTS to COBOL utility
Schiradin,Roland HG-Dir itb-db/dc [EMAIL
According to:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea9160/1.162
Sounds like you have multiple (unhandled) SOC4's in:
_cinit
__zerrh
Are these yours or IBM's?
John Donnelly [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Dear List...we installed
NOS is a valid abbreviation for NOSOURCE. See:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG30/2.4.46
(You probably should do an RCF against the Fault Analyzer documentation)
Lynne Karson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Hello List,
I am
Form a usually reliable source (at IBM) (exact quotation),
IBM has stated that it will be putting support for decimal floating-point
in hardware in future processors. That hardware will implement the
decimal formats and arithmetic that were agreed by the 754r committee in
2003 and which are
I *know* this isn't the correct answer (as it applies to COBOL programs),
but if you look at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea5160/2.7.3
Does this look like it MIGHT provide any clues for what you want?
P.S. Have you looked at:
unrounded multiplication, it
is inherently mis-matched to the nature of decimal data and
applications.
***
Similarly, you can look for my PERSONNEL comments by looking for the section
beginning:
From: Bill Klein
Date: Sun, 24 Jul 2005 11:52:38 -0500
I want to record a NO vote on the proposal
To the best of *MY* knowledge almost NONE of the GUIDE COBOL requirements
made it to LNGC. (Neither did the LE ones). As a former GUIDE requirement
coordinator and current SHARE LNGC requirement coordinator, I haven't seen
ANY of the old requirements in the SHARE database. I was not, however,
Too bad you aren't running on VSE, there is one there already, BUT the SHARE
LGNC project has submitted a requirement for one on z/OS.
If this is important to your shop, contact your IBM marketing branch and
submit a REQUEST (or whatever it is called this week) and reference SHARE
requirement:
A) As someone who uses a threaded newsreader, I personally HATE internal
comments/replies and always use top-posting (unless I am responding to a
very small portion of an original note. IN that case, I usually change the
subject line too.
B) I freely admit that I misunderstood the original
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
As the missing source code problem is popping up now and then, I'm
thinking that maybe it would be a good idea to include the source code
(compressed) in the load module, like you could do when compiling REXX
programs. This would
Just remember that when calling ILBOWAT0, you
A) want to do a dynamic CALL
B) need to use DATA(24)
I know that some shops have actually created their own interface module
(to be called by DATA(31) programs) to copy the time below the line and then
to call ILBOWAT0.
P.S. ILBOABN0 *has* been
be recompiled and retested ... but if you have the
RESOURCES, then go ahead and do it (but I do think you are in a very small
minority doing so)
Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
In [EMAIL PROTECTED], on
08/27/2005
at 03:14 PM, Bill Klein [EMAIL
R.S. [EMAIL PROTECTED]
wrote in message news:[EMAIL PROTECTED]...
Ted MacNEIL wrote:
snip
Regarding bodies for testing: do you have any for testing new
OS/database/CICS/others releases ? Maybe it's not obvious, but all the
compilation work is done by computer
Just to clarify, if you have an Output Procedure but no Input Procedure,
FASTSRT *will* impact input I/O. The only time it has no impact is if you
have BOTH an Input and Output procedure.
FYI,
I certainly (absolutely) would NOT recommend, it but you *might* be able
to ZAP the load module based
I thought that sending this note to IBM-MAIN *might* reach at least some
software vendors (or even users of such vendors) with LE related products.
The appendix in the current LE for z/OS V1.7 manual related to 3rd party
products is so INCREDIBLY out-of-date, that I think that as many vendors as
Sounds to me as if you should do an RCF against:
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/ibm3pg30/1.4.2.2
I certainly can't find the required information here (or anywhere else in
the Enterprise Pl/I V3R4 documentation)
Charles Mills [EMAIL PROTECTED] wrote in message
Others may have given you the answer already, but I am not certain they gave
you the REFERENCE. See:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR30/6.2.31.4
6.2.31.4 Sequential files
...
The number of character positions in record-name-1 must equal the number of
The best place (in my opinion) to find solutions to *all* CMPR2 to NOCMPR2
migration issues is the (pre-enterprise) COBOL Migration Guide. Without
further details, my best guess is that the problem you are having is the one
described at:
It won't help you in the SHORT-term, but if you are running in an
LE-conforming environment (HLL or LE-conforming Assembler), you might want
to go thru your IBM marketing rep (G) and ask for a REQUEST to be entered
referencing SHARE requirement:
SSLNGC0313587 New LE Callable Service to get
201 - 300 of 330 matches
Mail list logo
