Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Checking back on your compile shown outside Xpediter, then I can see you did have APOST (which is the "double quotes"). I believe the "default" if not changed at installation is QUOTE (single quotes).
Are you using "non-standard" (to your site) compile JCL? It seems unlikely that everyone at your site changes the definition of their literals to use Xpediter.
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
Bill Woodger wrote:
Checking back on your compile shown outside Xpediter, then I can see you did have APOST (which is the "double quotes"). I believe the "default" if not changed at installation is QUOTE (single quotes).
Are you using "non-standard" (to your site) compile JCL? It seems unlikely that everyone at your site changes the definition of their literals to use Xpediter.
APOST means single quotes ('), QUOTE means double quotes ("). It does at our shop, at any rate.
Joined: 25 Nov 2010 Posts: 70 Location: Sivakasi, India
The problem was not with the QUOTES or Apostrophe...
I have chosen a wrong LANGUAGE OPTION in the COMPILER.
This should be
Code:
LANGUAGE(COBOL/MVS)
But i had used as -
Code:
LANGUAGE(VSCOBOL)
That caused this issue. Now i could able to get the return codes 0 to both COMPILE and LINKEDIT. But now i get new message during XPED.
Code:
SOURCE LISTING TIME STAMP DOES NOT MATCH LOAD MODULE
Code:
XPED TSO SPF
TEST COBOL1
*** COBOL1 FROM XX9331.K194689.PGMLIB LINK 02/03/12
XPD2214 ADSRA221 LANGUAGE ENVIRONMENT SUPPORT INITIATED (RC=0)
XPD6070 ADSRA194 SOURCE COBOL1 HAS CONFLICTING DATE - TIME STAMP
XPD6071 ADSRA194 *** SOURCE MEMBER 02/03/12 09:07:56 ***
XPD6072 ADSRA194 *** LOAD MODULE 02/02/12 12.16.27 ***
XPD6073 ADSRA194 ANY SOURCE REFERENCE TO MODULE COBOL1 WILL BE REJECTED
XPD6074 ADSRA194 NOTE: CHECK MESSAGES AND CODES FOR FURTHER ACTION
Same issue was discussed many times in different sites. Suggestions are to recompile this program. But even after recompiling i am getting this message again. I am unable to solve this...
This is telling you the program was compiled with Xpediter at 9:07 AM on February 3rd. However, the load module was updated February 2nd at 12:16 PM. Therefore the load library you compiled into at 9:07 on February 3rd is NOT the load library used in the JCL executing the program. You need to change either (1) the compile JCL to use the same load library as the run JCL, or (2) the run JCL to use the same load library as the compile JCL.
APOST, QUOTE currently are only for the value of the figurative constant QUOTE/QUOTES. However, I'm pretty sure this used not to be the case.
Back to the original thing then.
Having a look for the message prefix, is it possible it is from a very old compiler, as the only reference I can find is to running on Hercules under MVS? Plus this.
Whilst putting this together (and other things) I see now that things have moved on. Now to find confirmation that APOST/QUOTE changed...
So, changing to single quotes, or changing APOST to QUOTE on Xpediter would have got you clean with the wrong compiler. As it turns out, in the wrong load library.
XPD2214 ADSRA221 LANGUAGE ENVIRONMENT SUPPORT INITIATED (RC=0)
XPD6070 ADSRA194 SOURCE COBOL1 HAS CONFLICTING DATE - TIME STAMP
XPD6071 ADSRA194 *** SOURCE MEMBER 02/03/12 09:07:56 ***
XPD6072 ADSRA194 *** LOAD MODULE 02/03/12 10.13.05 ***
XPD6073 ADSRA194 ANY SOURCE REFERENCE TO MODULE COBOL1 WILL BE REJECTED
XPD6074 ADSRA194 NOTE: CHECK MESSAGES AND CODES FOR FURTHER ACTION
Now i observe there is a small variation in the timestamp and i understand one represent the SOURCE file compilation time and the other one is the LOAD updated time. Is there any way to modify the above JCL to produce the same timestamp to both ?
Thanks in advance.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
That means you still don't have the "same" module in the load and in Xpediter (where it is using, I imagine, its own copy of the compiler output listing).
The "delay" is not between the compile and the link, because from the loadmodule (output from the linkedit/bind) the compile time is extracted, and it should be identical to the smallest unit to the complie-listing timestamp.
Compile, produces Object, with timestamp, plus listing with same timesamp. Linker/binder takes object (and other objects/loads) and make loadmodule, compile timestamp unaffected, completely different information for date of link/bind.
Yes there is a way. Slow down and actually read what people are telling you, then it will work.
The exped meessages are from another job/run that you are doing after the compile/link. Think about what they are telling you.
They are saying, "Hey, you know that source code you want to step through? That load module you're pointing to didn't come from there."
What they are really trying to tell you is "HEY, SLOW DOWN AND DO IT RIGHT! Get your DDIO built and get a load module built in the same compile job, then make sure I know where they both are, then get back to me."
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
After taking a closer look at your JCL, I have no idea what you think you are accomplishing. Program CWPCMAIN is the Compuware COBOL language preprocessor module (CWPCDRVR is the Compuware COBOL postprocessor module -- one of these needs to be invoked to prepare the program for use with Xpediter). IGYWCL is one of the IBM standard compile procedures for COBOL. As an IBM product, programs compiled with IGYWCL will not be able -- in any way -- to use Xpediter unless you have a postprocessor step in your job.
From the Compuware Enterprise Common Components (ECC) Installation and Customization Guide manual:
Quote:
| There are two methods by which the language processor can be run:
| • preprocessor
| • postprocessor
| You must determine the type of processing that is best for your site,
| and you should run only one type of processor.
| The Compuware language preprocessor invokes both the compiler and the
| postprocessor. The preprocessor, in addition to gathering information
| from the compiler listing, gathers information from SYSIN and SYSLIB.
| The postprocessor is executed as a separate step after the compile step.
| It reads in the listing created from the compiler. Information is
| gathered from the source listing, XREF, data maps, and object code
| sections of the listing.
So what it looks like you've done is taken an Xpediter compile job, removed the Xpediter compile processing, and now question why the date / time stamp of the load module doesn't match the source. It doesn't matter if you use the preprocessor or postprocessor as long as the Compuware language processor generates a member of the DDIO that contains the source. Without that source in the DDIO, your Xpediter session cannot access the source when debugging.
So, basically, you need two jobs: one to compile the program and one to execute the program. Both jobs need to point to the same DDIO and load library (SYSLMOD in the linkage editor / binder step of the compile and STEPLIB / JOBLIB of the execution job). If the compile job is set up correctly, the date / time stamps match and the error messages you see will NOT be generated.
Joined: 25 Nov 2010 Posts: 70 Location: Sivakasi, India
Thanks everyone. Finally i am done with the EXPED using the XPEDITOR COMPILE JCL generated from the options
1 PREPARE in the XPED home screen
1 CONVERT COMPILE JCL in the subsequent screen.
It is working now. For the sake of future users i have given the code generated from the above options.
