The definition of AVAILABLE file for VSAM is a little odd (obscure?
strange?)
Check out:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg30/1.10.6
A VSAM file *must* be available to OPEN I-O.
See also the information at:
For those of you who participate in the (totally online) SHARE requirement
process, there are now 3 requirements for phased in mixed 31-/64-bit LE
(Language Environment) support. These are in the LNGC project.
If this is of interest to you now (or will be at some time in the
foreseeable future),
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
ury.com...
Mark T. said:
If someone would like to submit a requirement like this at SHARE
I will try to apply some weight to get it implemented.
Would someone who is going to SHARE please look into this?
All (well almost all)
The debug component of 5668958 was NOT the debug tool but was COBTEST
(which was a COBOL-specific debugger).
Are you REALLY still paying for that? If so, I would CERTAINLY drop it. In
fact, if you are still paying for the lib portion of that produce (and are
using LE as your run-time) you
much snippage
Concerning the COBOL compiler message:
IGYPS0157-E A shift-out was found in column 50 without a matching
shift-in in a nonnumeric or national literal. The literal was processed as
written.
The original problem has been diagnosed and hopefully solved. However,
there has been a
I don't understand your comment.
As previously indicated the FLAG(I,I) option became the default at the same
time as DBCS.
Therefore, the compiler error message WILL appear in the listing IMMEDIATELY
after the line inserted by the translator (indicating the column in that
line with the
There certainly may have been a problem earlier, but when I click on the
link
http://www.ibm.com/news/usalet/
It does redirect me to a site with today's announcements AND I can click on
any specific announcement and get to the requested announcement.
Eric Chevalier [EMAIL PROTECTED] wrote
I have previously suggested that the DFSort sessions at SHARE be
cross-listed with the LNGC (and possibly DVLG) projects.
It is MY impression that the application people who DO attend SHARE (and
they aren't the majority) do NOT look at the schedule of what is available
in the various z/OS
Perryman, Brian [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
i.com...
SNIP
snip
What is not self-describing about these is why they suddenly started
appearing when the programmer hadn't changed any of his code, that's what!
If messages start appearing after a migration of
Sorry to disagree on this one (again), but the error message tells you
exactly WHERE (what line and what column in that line) has the problem. a
VERY simple search of either the COBOL LRM or APG for the term shift-in
will tell you what this means and again, a search of the manual SHOULD take
you
So far, I haven't received any off-list or online replies to my pointing out
my work-in-progress web page at:
http://home.comcast.net/~wmklein/IBM/ErrMsg.htm
Would this type of web-page be of use to those who can't figure out the
COBOL compiler messages?
McKown, John [EMAIL PROTECTED] wrote
If you didn't upgrade your COBOL as well as z/OS, then I would be REALLY
surprised in this change occurring. The COBOL documentation talks about the
change from NODBCS to DBCS as the default compiler option - in newer
releases of Enterprise COBOL. There should ALSO be a change from FLAG(I) to
I started a project that I never finished (much less updated for the latest
compiler). If you check out my web page at:
http://home.comcast.net/~wmklein/IBM/ErrMsg.htm
It has an annotated version of the ERRMSG output - with a link to the
place in the COBOL documentation that relates to the
The COBOL2 CICS Translator option was removed from CICS TS and then
re-introduced by APAR PQ84313. It is my understanding that if you use
COBOL3, then you can use either the DBCS or NODBCS compiler option - but
that with older COBOL and COBOL2 translator options, you will have
problems with using
Steve Comstock [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
snip
And I can't figure out why they made that change,
since DBCS is, supposedly, on its eventual way
out, to be replaced by NATIONAL (Unicode). Any
idea why the default was changed? Especially since
the vast majority
of
NODBCS/DBCS
and NSYMBOL(NATIONAL)/(DBCS).
IBM, however, at roughly the same time they changed the default to
DBCS
decided (for political reasons - I believe, not syntactic reasons) NOT
to
support the combination of
NODBCS ,NSYMBOL(NATIONAL)
Clearer
--
Bill Klein
wmklein
to: IBM-MAIN
LNGC distribution list
For those who might be interested (and might have missed it), today (June
21), IBM made an announcement for:
IBM Enterprise COBOL for z/OS V3.4 continues the integration of COBOL and
Web-oriented business processes
See:
John,
*IF* you know how to do this in HLASM, (using a service) what is the
problem in doing the same in COBOL? As I don't know (understand) exactly
what you are trying to do in the program, it is hard for me to tell you how
(if possible) to do it in COBOL.
One thing that *MIGHT* be of use is
Clark Morris [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
On 6 Jun 2005 20:52:17 -0700, in bit.listserv.ibm-main you wrote:
snip
The problem has nothing to do with z/OS vs. Unix. It is a simple
IDIOTIC check that can't be disabled. It may make sense for fixed
block. The
The difference (that I know of) for Recording Mode is U - STARTED with
OS/390 2.10 - not after it. Check out:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3MG20/3.5.3
That page is worth reading for those who have made various suggestions to
the original problem relying on
The LRECL in the JCL includes the RDW. The RECORD VARYING IN SIZE does
*not* include the RDW. Therefore, it is quite true that the LRECL (in JCL)
should be 4-bytes larger than the minimum RECORD VARING FROM value.
see (among other places),
(sizes).
john gilmore [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Bill Klein wrote:
The LRECL in the JCL includes the RDW. The RECORD VARYING IN SIZE does
*not* include the RDW. Therefore, it is quite true that the LRECL (in
JCL)
should be 4-bytes larger than the minimum
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
In a recent note, john gilmore said:
snip
And on this question, I have yet no empirical evidence that, for example,
DUMMY,DCB=... behaves any differently from DSN=NULLFILE,DCB=...
I'm inclined to believe that the writers of the JCL
I haven't PERSONALLY heard of anyone using it, but this is discussed in
the LE customization guide at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea5150/2.7.3
2.7.3 Modifying the COBOL Parameter List Exit
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
In a
The most current COBOL documentation on this is actually in the LE manual.
See:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea2150/2.1.4
which has (in the sample COBOL code):
03 PARM-BYTE PIC X OCCURS 0 TO 100 DEPENDING ON STRINGLEN.
STRINGLEN is defined as:
STRINGLEN
I can get it, but the one question I do NOT see there is the
32K vs 64K
question.
Maybe it is just me, but I have YET to hear any real advantage to 64k over
32k and I can see some (potential) disadvantages).
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
In a message dated
But IBM *did* create a cross-platform unified procedure language
specification.
See:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/E04A2A01/CCONTENT
S
Oh, well,
We all know what happened to SAA, don't we? G
Craddock, Chris [EMAIL PROTECTED] wrote in message
news:[EMAIL
256 seems WAY to small to me - for such things as the LE ENVAR run-time
option.
(In fact, just trying to pass all the LE run-time options that one MIGHT
want to override - without a CEEUOPT makes me question 4096)
Ed Gould [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
on 5/13/05
Whatever is done, please remember CEE3PRM (and existing SHARE requirement
SSLNGC0313586) - and of course the fact that LE claims that this works the
same under z/OS and VM. (VSE already addressed this via the new CEE5PRML
callable service. See:
As someone has already noted, if you compile your VS COBOL II program with
TRUNC(BIN) then it will treat *all* binary items the same as COMP-5 items
(in Enterprise COBOL). This will, however, have
SIGNIFICANT PERFORMANCE impact !!!
On the other hand, the only time that a COMP-5 data item
301 - 330 of 330 matches
Mail list logo
