subject:"PARMDD \-\- any one use yet\?"

Re: PARMDD -- any one use yet

2014-12-12 Thread Steve Thompson

Ok, I'm back to working on this aspect of a problem.  So, I tried something 
interesting to try to figure this one out. The following JCL does NOT expand 
the string (the JOB after this does):

//SXT7279T JOB (T,,MC),'TEST PARMDD ',CLASS=I,
//   TIME=(,05),
//*  TYPRUN=SCAN,
//   MSGCLASS=X,NOTIFY=SYSUID
//* $ACFJ219 ACF2 ACTIVE HUMANA
//*
//*
//FOCUCC   EXEC FOCUCCDUAL COMPILE
//*
//*
// SET CMB=SXT7278.CID.MBDUAL.CRDS.CID
// SET CCT=SXT7278.CMPL.CNTL(RELCID)
//*
// SET HDY='.'
//*
// SET HDT='.'
//*
// SET SQP=Y
//*
// SET RNO='.'
//*
// SET VX='.'
//*
// SET NAP=NEWAPPL(BCMP)
//*
// EXPORT SYMLIST=*
//PARMDD   EXEC PGM=IEBGENER
//*-+1+2+3+4+5+6+7+8
//SYSUT1   DD  *,SYMBOLS=(CNVTSYS,PARMLST)
ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP
/*
//SYSUT2   DD  DSN=PARMDD,DISP=(,PASS),UNIT=3390,
// DCB=(RECFM=VB,LRECL=4096,BLKSIZE=0),
// SPACE=(TRK,1)
//PARMLST  DD  SYSOUT=*
//SYSINDD  DUMMY
//SYSPRINT DD  SYSOUT=*
//*
//*
//MASSCMPL EXEC PGM=IKJEFT1B,PARMDD=PARMDD
//*PARM='ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP'
//PARMDD   DD  DSN=PARMDD,DISP=OLD
/*
//*
//***  EXECUTE BACKGROUND CLIST TO CREATE **
//*
//SYSPRINT DD  SYSOUT=*
//SYSTSIN  DD  DUMMY
//SYSTSPRT DD  SYSOUT=*
//***  DUMMY PANEL LIBRARY  **
//ISPPLIB  DD  DSN=ISPPLIB,

JES shows this in the PARMLST DD of the gener step:

SYSUT1   : RECORD 1 BEFORE SUBSTITUTION
SYSUT1   : ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP
SYSUT1   : RECORD 1 AFTER SUBSTITUTION
SYSUT1   : ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP

THIS JOB WORKS for the expansion, but not in the execution!!:

//SXT7278T JOB (T,,MC),'TEST OF PARMDD',CLASS=I,
//*TYPRUN=SCAN,
// TIME=(0,10),
// MSGCLASS=X,NOTIFY=SYSUID
//*+JTS  HOLD_UNTIL NOW
//* $ACFJ219 ACF2 ACTIVE HUMANA
//*
//*
// EXPORT SYMLIST=*
//*
//*
//*OCUCC   EXEC FOCUCC
//*
//*
// SET HDY='TODAY'
//*
// SET HDT='10:00'
//*
// SET SQP='YES'
//*
// SET RNO='.'
//*
// SET VX='.'
//*
// SET CCT=SXT7278.CMPL.CNTL(RELCID)
//*
// SET CMB=TESTAEN.CID.MBB.CRDS.CID
//*
// SET NAP=NEWAPPL(BCMP)
//*
//*
//PARMDD   EXEC PGM=IEBGENER
//*-+1+2+3+4+5+6+7+8
//SYSUT1   DD  *,SYMBOLS=(CNVTSYS,PARMLST)
ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP
/*
//SYSUT2   DD  DSN=PARMDD,DISP=(,PASS),UNIT=3390,
// DCB=(RECFM=VB,LRECL=4096,BLKSIZE=0),
// SPACE=(TRK,1)
//PARMLST  DD  SYSOUT=*
//SYSINDD  DUMMY
//SYSPRINT DD  SYSOUT=*
//*
//MASSCMPL EXEC PGM=IKJEFT1B,PARMDD=PARMLST
//*PARM='ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP'
//PARMLST  DD  DSN=PARMDD,DISP=(OLD,DELETE)
//*
//***  EXECUTE BACKGROUND CLIST TO CREATE **
//*
//SYSPRINT DD  SYSOUT=*
//SYSTSIN  DD  DUMMY
//SYSTSPRT DD  SYSOUT=*
//***  DUMMY PANEL LIBRARY  **
//ISPPLIB  DD  DSN=ISPPLIB,

JES shows this in the PARMLST DD of the Gener step:
SYSUT1   : RECORD 1 BEFORE SUBSTITUTION
SYSUT1   : ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP
SYSUT1   : RECORD 1 AFTER SUBSTITUTION (TRUNCATED AT 80)
SYSUT1   : ISPSTART CMD(%NCMPL TODAY 10:00 YES .   .   
SXT7278.CMPL.CNTL(RELCID) TESTAEN.CID.MBB.CRDS.CID) NEWAPPL(BCMP)
SYSUT1   : RECORD 1 AFTER SUBSTITUTION (TRUNCATED AT 80)
SYSUT1   : ISPSTART CMD(%NCMPL TODAY 10:00 YES .   .   
SXT7278.CMPL.CNTL(RELCID) TESTAEN.CID.MBB.CRDS.CID) NEWAPPL(BCMP)
SYSUT1   : RECORD 1 AFTER SUBSTITUTION (TRUNCATED AT 80)
SYSUT1   : ISPSTART CMD(%NCMPL TODAY 10:00 YES .   .   
SXT7278.CMPL.CNTL(RELCID) TESTAEN.CID.MBB.CRDS.CID) NEWAPPL(BCMP)
SYSUT1   : RECORD 1 AFTER SUBSTITUTION (TRUNCATED AT 80)
SYSUT1   : ISPSTART CMD(%NCMPL TODAY 10:00 YES .   .   
SXT7278.CMPL.CNTL(RELCID) TESTAEN.CID.MBB.CRDS.CID) NEWAPPL(BCMP)
SYSUT1   : RECORD 1 AFTER SUBSTITUTION (TRUNCATED AT 80)
SYSUT1   : ISPSTART CMD(%NCMPL TODAY 10:00 YES .   .   
SXT7278.CMPL.CNTL(RELCID) TESTAEN.CID.MBB.CRDS.CID) NEWAPPL(BCMP)

The next step does not work, because SYSUT2 had an I/O error. Apparently it 
doesn't like the SYSUT1 for writing to SYSUT2 for SYSOUT=*.

Well, after more testing, I found that you really can't copy or do a refer-back 
to pick it up.

Now, why does it work for the one and not the other?  It appears it is the 
special utility program that FOCUCC invokes:

U11RMS



Regards,
Steve Thompson
Tech Architect


The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PARMDD -- any one use yet

2014-12-12 Thread Tom Marchant

On Fri, 12 Dec 2014 18:36:21 +, Steve Thompson sthompso...@humana.com 
wrote:

Ok, I'm back to working on this aspect of a problem.  So, I tried something 
interesting to try to figure this one out. The following JCL does NOT expand 
the string (the JOB after this does):

//SXT7279T JOB (T,,MC),'TEST PARMDD ',CLASS=I,
//   TIME=(,05),
//*  TYPRUN=SCAN,
//   MSGCLASS=X,NOTIFY=SYSUID
//* $ACFJ219 ACF2 ACTIVE HUMANA
//*
//*
//FOCUCC   EXEC FOCUCCDUAL COMPILE
//*
//*
// SET CMB=SXT7278.CID.MBDUAL.CRDS.CID
// SET CCT=SXT7278.CMPL.CNTL(RELCID)
//*
// SET HDY='.'
//*
// SET HDT='.'
//*
// SET SQP=Y
//*
// SET RNO='.'
//*
// SET VX='.'
//*
// SET NAP=NEWAPPL(BCMP)
//*
// EXPORT SYMLIST=*

The EXPORT has to be coded BEFORE the SET statements, as documented
in the first paragraph describing the EXPORT statement.

Symbols must be set to a value subsequent to the EXPORT statement
for the symbol value to be exported.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PARMDD -- any one use yet

2014-12-12 Thread Steve Thompson


On 12/12/2014 02:35 PM, Tom Marchant wrote:

On Fri, 12 Dec 2014 18:36:21 +, Steve Thompson sthompso...@humana.com 
wrote:


SNIPPAGE

The EXPORT has to be coded BEFORE the SET statements, as documented
in the first paragraph describing the EXPORT statement.

Symbols must be set to a value subsequent to the EXPORT statement
for the symbol value to be exported.



For all -- I got interrupted a few times while writing the email 
that Tom was responding to.


My purpose was to get back and explain what I found (this morning 
my time).


To answer Tom specifically:

If that utility (U11RMS) is not executed, the symbols get 
expanded, and the REXX exec works.


And, in the JOB that worked, I had moved the EXPORT statement to 
immediately follow the JOB card and to immediately precede the 
step in question. Made no difference. When it worked, it worked.


Have that utility step execute and PARMDD does not work.

Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PARMDD -- any one use yet

2014-12-12 Thread Steve Thompson


On 12/12/2014 03:02 PM, Steve Thompson wrote:

On 12/12/2014 02:35 PM, Tom Marchant wrote:

On Fri, 12 Dec 2014 18:36:21 +, Steve Thompson
sthompso...@humana.com wrote:


SNIPPAGE

The EXPORT has to be coded BEFORE the SET statements, as
documented
in the first paragraph describing the EXPORT statement.

Symbols must be set to a value subsequent to the EXPORT statement
for the symbol value to be exported.


SNIPPAGE

To answer Tom specifically:


SNIPPAGE

And, in the JOB that worked, I had moved the EXPORT statement to
immediately follow the JOB card and to immediately precede the
step in question. Made no difference. When it worked, it worked.

snippage

Tom is correct.

I had not noticed that I did a copy and not a move when I had 
done the one test. Once I saw the two EXPORT statements, I 
realized my mistake So I re-ran my tests and proved what Tom 
said is valid.


Which also proved the manual

I am so glad it is Friday and not that far from beer-30.

Have a good weekend all,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PARMDD -- any one use yet

2014-12-09 Thread Peter Relson

It's wrong to quietly ignore an unsupported construct.  Logging-DDname
in a SYSIN data set mentioned in PARMDD should result in a JCL syntax
error and failure of the job before execution.

Your opinions are always welcome. They are not always agreed with. 

For this case, I probably agree that a JCL syntax error could have been 
better. For many other cases I do not agree that it's wrong to quietly 
ignore.

Might it be more readily be reported in JESYSMSG?  It would seem that
since allocation messages appear there that data set is writeable at the
needed time (whether it's in scope for the initiator is a different 
question)

I'll plead ignorance here. That makes sense to me (but I don't know if 
record length could be a stumbling point). If a request is submitted, it 
would be useful to mention how necessary it is to show each substituted 
line in its entirety (possibly spanning multiple messages) or whether the 
first n characters might satisfy. I have not looked at all into just 
what is logged if logging is done (for the non-PARMDD case). I suppose 
normally I'd expect to see, for any line that changed due to substitution, 
the complete old and the complete new.

quote Note that logging-DDname is ignored if it is 
specified on the DD statement which describes a data set that 
is the target on the PARMDD keyword (see PARMDD parameter). /quote

what I read from the reference url is that EXEC ...,PARMDD=MYLOGDD 
along with SYMBOLS=(...,MYLOGDD) should fail.

Ignored (usually, and in this case) means ignored. It does not mean 
rejected. Here it really means ignored. In this case it does not even mean 
not processed and we told you about that with an informational message.

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PARMDD -- any one use yet

2014-12-08 Thread Peter Relson

...ignored...!  WTF!?  Time for a Requirement?  Either 
the substitution result should be logged in logging-DDname 
or it should appear in an informative message after 
the EXEC statement.

You are always encouraged to submit requirements. Logging might well be 
rejected. It is a chicken-and-egg thing. At the time that PARMDD is (and 
has to be) processed (under the initiator task), various i/o operations 
are not supported (apparently including those needed to write to a the 
intended log). Changing that could be very costly, thus requiring 
significant justification.

I fear that I am not allowed to do that. I can only 
post snippets of it as I believe I have already done.

If you are not allowed to post the actual symbol values, can you post the 
length of each symbol values (and if there is some funky character that 
you can get in there, what such characters might be, just in case parsing 
is the issue)? 

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PARMDD -- any one use yet

2014-12-08 Thread Paul Gilmartin

On Mon, 8 Dec 2014 07:59:53 -0500, Peter Relson wrote:

... At the time that PARMDD is (and
has to be) processed (under the initiator task), various i/o operations
are not supported (apparently including those needed to write to a the
intended log). Changing that could be very costly, thus requiring
significant justification.

Might it be more readily be reported in JESYSMSG? It would seem that
since allocation messages appear there that data set is writeable at the
needed time (whether it's in scope for the initiator is a different question).

Treatment of PARMDD that refers to a SYSIN with SYMBOLS= is so
more complicated than EXEC ...,PARM= that reporting is correspondingly
more valuable.

It's wrong to quietly ignore an unsupported construct. Logging-DDname
in a SYSIN data set mentioned in PARMDD should result in a JCL syntax
error and failure of the job before execution.

And another idiosyncrasy I suspect. From:

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab600/iea3b6_parm_string_requirements_parmdd.htm
z/OS 2.1.0z/OS MVSz/OS MVS JCL ReferenceEXEC statementPARMDD
parameterParameter string requirements
z/OS MVS JCL Reference
SA23-1385-00

After concatenation, the parameter string that is passed to the job step
program is examined for double ampersand character (amp;) sequences. Double
ampersands are converted to single ampersands in the same way that double
ampersands are converted to single ampersands by PARM= processing.

I guess (I haven't tested) that if I code:

// SET TWOAMP='amp;'
// EXPORT TWOAMP
//STEP EXEC PGM=WOMBAT,PARM='TWOAMP'

... the parm passed to WOMBAT is two ampersands (there is no rescan).
However, in:

// SET TWOAMP='amp;'
// EXPORT TWOAMP
//STEP EXEC PGM=WOMBAT,PARMDD=P
//P DD *,SYMBOLS=JCLONLY
TWOAMP

... PARMDD processing converts the two ampersand to a single ampersand
which is passed to WOMBAT. Ouch! FSVO ... in the same way The
effect of passing a symbol via PARM= may differ unexpectedly from passing
it via PARMDD=.

I suspect that when the LONGPARM Requirement was submitted the
requestor expected processing consistent with that of PARM=, but with the
100-character limit relaxed (substitution of system symbols would be an
added value). What was provided was significantly different.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

32 matches

Mail list logo