Hello Chris Mason.
 
First thanks very much from your help.
 
Chris, Before start my JOB here, I worked with ZOS, but with CICS SUPPORT for 
nine years.
I start work here, at March of this year, but really JCL I never know very well.
For more then 30 years, I worked with VM/VSE, so, at 2001 year was working with 
CICS under ZOS.
When start work with ZOS, was not very easy for me, and for this reason, I put 
some questions here, when I dont' know.
I  want to apologize for putting this list as seemingly easy questions.
 
Regards,
 
Sergio
 
 



 
> Date: Thu, 9 Dec 2010 10:41:53 -0600
> From: chrisma...@belgacom.net
> Subject: Re: Problem when try compile a CBT036 FILE
> To: IBM-MAIN@bama.ua.edu
> 
> Sergio
> 
> What you need to change is the apparent management attitude which 
> imposes a VSE to MVS (z/OS) conversion onto you without having 
> *previously* arranged for adequate education.
> 
> If your management's attitude is for education to be provided by asking 
> questions on the IBM-MAIN and other lists, please arrange for a funding 
> stream to be set up so that payments can somehow be arranged for 
> consultancy fees to all of us attempting to provide assistance!
> 
> -
> 
> Now having dealt with the *real* problem, let's deal with what appears to be 
> the superficial problem which is very, very simple - for someone with the 
> most 
> basic training - I won't even dignify it with the word *education* in the use 
> of 
> MVS procedures and general understanding of compilation[1] and linkage 
> editing.
> 
> I strongly expect that the JCL you need is the following:
> 
> //***************************************************// 
> 
> //* INSTALL SPFPDS LOAD MODULE FOR FIXPDS *// 
> //***************************************************// 
> 
> //FPDSASM PROC M= 
> //ASM EXEC PGM=ASMA90,REGION=3500K, (IBM ASSEMBLER H) 
> // PARM='DECK,RENT,NOLOAD' 
> //SYSLIB DD DSN=SYS1.MACLIB,DISP=SHR SYSTEM MACRO LIBRARY 
> // DD DSN=SYS1.MODGEN,DISP=SHR SYSTEM MACRO LIBRARY 
> // DD DSN=IBMUSER.FILE036,DISP=SHR <== THIS LIBRARY 
> //SYSUT1 DD SPACE=(CYL,(5,5)),UNIT=SYSDA 
> //SYSUT2 DD SPACE=(CYL,(5,5)),UNIT=SYSDA 
> //SYSUT3 DD SPACE=(CYL,(5,5)),UNIT=SYSDA 
> //SYSTERM DD SYSOUT=* 
> //SYSPRINT DD SYSOUT=* 
> //SYSLIN DD DISP=SHR,DSN=IBMUSER.OBJECT 
> //SYSIN DD DISP=SHR,DSN=IBMUSER.FILE036(&M) 
> //SYSPUNCH DD DSN=IBMUSER.OBJECT(&M),DISP=OLD 
> //* 
> //PEND PEND 
> //* 
> //SPFCNTL EXEC FPDSASM,M=SPFCNTL 
> //SPFCORE EXEC FPDSASM,M=SPFCORE 
> //SPFFIX EXEC FPDSASM,M=SPFFIX 
> //SPFMAIN EXEC FPDSASM,M=SPFMAIN 
> //SPFSCAN EXEC FPDSASM,M=SPFSCAN 
> //SPFSRCH EXEC FPDSASM,M=SPFSRCH 
> //* 
> //LKED EXEC PGM=IEWL,PARM='TERM,XREF,LIST,LET,TEST', 
> // COND=(7,LT) 
> //SYSLMOD DD DSN=IBMUSER.LOAD,DISP=SHR 
> //ISPLIB DD DSN=SYS1.LINKLIB,DISP=SHR 
> //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(2,1)) 
> //SYSTERM DD SYSOUT=* 
> //SYSPRINT DD SYSOUT=* 
> //SYSLIB DD DISP=SHR,DSN=IBMUSER.OBJECT 
> //SYSLIN DD * 
> INCLUDE SYSLIB(SPFCNTL) 
> INCLUDE SYSLIB(SPFCORE) 
> INCLUDE SYSLIB(SPFFIX) 
> INCLUDE SYSLIB(SPFMAIN) 
> INCLUDE SYSLIB(SPFSCAN) 
> INCLUDE SYSLIB(SPFSRCH) 
> INCLUDE ISPLIB(ISPLINK) 
> SETCODE AC(0) 
> NAME SPFPDS(R) 
> /*
> 
> 
> The only change I have made is to replace "FILE036" in the SYSPUNCH DD-
> statement with "OBJECT".
> 
> The technical reason for this is that the repeated calls to the procedure 
> cause 
> a number of source modules to be assembled *from* the SYSIN DD-
> statement, IBMUSER.FILE036(&M), and placed as object modules in "DECK" 
> form in the SYSPUNCH DD-statement, IBMUSER.OBJECT(&M), under the 
> influence of the "DECK" parameter to the assembler H program.
> 
> The repeated calls to the assembler procedure are then followed by a linkage 
> edit - I believe the name "binder" has become a replacement for the old-
> fashioned term "linkage editor" these days - procedure which takes all the 
> object modules in "DECK" form from the PDS identified as the SYSLIB DD-
> statement - *and* - an object module in what must be "load" form from the 
> PDS identified as the ISPLIB DD-statement - which is expected to be 
> SYS1.LINKLIB - and linkage edits them into a module in "load" form with name 
> SPFPDS and stores it in the PDS identified with the SYSLMOD DD-statement, 
> IBMUSER.LOAD. 
> 
> Note, incidentally, that including IBMUSER.FILE036 as a PDS in the SYSLIB 
> concatenation to the assembler program will allow any macros specifically 
> created for this set of source modules to be found.
> 
> Note also that I haven't removed SYSUT2 and SYSUT3 from the embedded 
> procedure but I believe - as I say in a footnote - that they are unnecessary. 
> Leaving them in can't do any harm and this has nothing whatsoever to do with 
> your problem!
> 
> Looking at that procedure again, I'm not at all sure there is any role for 
> the 
> SYSLIN DD-statement.
> 
> > The SYSLIN STATEMENT before the PEND command was inserted here by 
> us, because We imagine that this parameter was missing.
> 
> What this appears to say, I don't understand but I can mention that 
> *knowledge* beats *imagination* every time - when it comes to solving this 
> sort of problem anyhow!
> 
> -
> 
> All the above was composed before checking other contributions since your 
> last was
> 
> > What We need change?
> 
> Clearly, they had not been sufficiently helpful.
> 
> Also I missed the additional point which Lizette Kohler addressed which was 
> that you need to verify which "load" module PDS contains the ISPLINK module. 
> It is clearly *not* SYS1.LINKLIB and - for all I know not having a system to 
> hand - may well be SYS1.ISP.SISPLOAD.
> 
> If it is the latter, you will need to replace 
> 
> //ISPLIB DD DSN=SYS1.LINKLIB,DISP=SHR
> 
> with
> 
> //ISPLIB DD DSN=SYS1.ISP.SISPLOAD,DISP=SHR
> 
> in the linkage editor step.
> 
> Finally, I see you have had so much help you have just become confused! 
> You - and probably also your colleagues - need to get that education I 
> mentioned initially!
> 
> -
> 
> Incidentally, I couldn't see what contribution Binyamin Dissen had made until 
> I 
> appreciated he was probably intending you to spot the final comment I believe 
> he makes on all of his posts:
> 
> >...> I very rarely bother responding to challenge/response systems, 
> especially those from irresponsible companies.
> 
> This, in a rather strong form, supports the my initial point. Clearly your 
> question is one of the rare cases!
> 
> Chris Mason
> 
> [1] Actually, this is Assembler H - is it not? - and so I wonder that the 
> person 
> who set up the original job control file didn't know that Assembler H used 
> only 
> *one* work file and not the "traditional" three - although that is a change 
> that is either ancient history now - or I have I just somehow imagined it - a 
> consequence of old age! Note I don't have a system to hand these days to 
> verify potentially false memories!
> 
> 
> On Thu, 9 Dec 2010 17:15:00 +0300, Sergio Lima <sergio...@hotmail.com> 
> wrote:
> 
> >Hello Scott,
> > 
> >What We need change?
> > 
> >Thanks,
> > 
> >Sergio
> > 
> >> Date: Wed, 8 Dec 2010 17:06:48 -0500
> >> From: scott.r...@joann.com
> >> Subject: Re: Problem when try compile a CBT036 FILE
> >> To: IBM-MAIN@bama.ua.edu
> >> 
> >> The PARMs for the ASM step specify DECK and NOLOAD, so the object 
> output is
> >> going to SYSPUNCH, not SYSLIN.
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
                                          
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to