|
View previous topic :: View next topic
|
| Author |
Message |
Susanta
Active User
Joined: 17 Nov 2009
Posts: 129
Location: India
|
|
|
|
Hi
When i submit following job with below sort it works fine in test region.
But it fails in qa, and gives jcl error "IEFC601I INVALID JCL STATEMENT "
Please help..
| Code: |
//PS1 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=XYZ.IN,DISP=SHR
//SORTOUT DD DSN=XYZ.SORTED,
// DISP=(NEW,CATLG,DELETE),SPACE=(CYL,(20,5),RLSE)
//SYSIN DD *
SORT FIELDS=COPY
ALTSEQ CODE=(0D40)
OUTREC FIELDS=(1,27,TRAN=ALTSEQ,28,12,TRAN=ALTSEQ,40,160)
/* |
Thanks |
|
| Back to top |
|
 |
kratos86
Active User
Joined: 17 Mar 2008
Posts: 148
Location: Anna NGR
|
|
|
|
| Code: |
| //SORTWK01 DD UNIT=SYSUT,SPACE=(CYL,(20,20),RLSE) |
I believe there is no unit available in the name SYSUT. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
Susanta
It is the OUTPUT from the run that tells us the important information |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
| What is flagged in JESMSGLG? |
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2454
Location: Hampshire, UK
|
|
|
|
| Which JCL statement is the message referring to? Posting half a message and half your JCL and none of the output (apart from the message) is no good. Also it is a JCL error so why post in the DFSORT section? |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
just curious ...
| Code: |
2 //IEF1 EXEC PGM=IEFBR14
3 //DD1 DD DISP=SHR,DSN=ENRICO.TEST.NONCE,
// UNIT=NONCE,VOL=SER=NONCEV
ICH70001I ENRICO LAST ACCESS AT 16:58:55 ON FRIDAY, NOVEMBER 18, 2011
IEF210I ENRICO0Z IEF1 DD1 - UNIT FIELD SPECIFIES INCORRECT DEVICE NAME
|
how nice if the TS had posted a bit more info...
or had replied to the requests for more info
in case of a noshow the topic will be mercilessly ethered 
edited to add ...
| Code: |
| //SORTWK01 DD UNIT=SYSUT,SPACE=(CYL,(20,20),RLSE) |
probably the original post has been reworked, the SORTWK01 DD isn' t there any longer
anyway an invalid unit name will yield a different message as shown by my test |
|
| Back to top |
|
|
Susanta
Active User
Joined: 17 Nov 2009
Posts: 129
Location: India
|
|
|
|
This issue is resolved now. In our qa environment there is restriction to use instream data. When I kept the sort card in a pds member then it worked.
sorry i could not reply fast enough.
Thanks All |
|
| Back to top |
|
|
parsesource
New User
Joined: 06 Feb 2006
Posts: 97
|
|
|
|
| Susanta wrote: |
This issue is resolved now. In our qa environment there is restriction to use instream data.
|
what do they achieve by forbidding instream data? |
|
| Back to top |
|
|
Susanta
Active User
Joined: 17 Nov 2009
Posts: 129
Location: India
|
|
|
|
| Its a safety measure to protect case sensitive data from unwanted modifications. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
Thank you for having the courtesy by letting us know it has been resolved and what the problem was.
It is appreciated  |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
| Quote: |
This issue is resolved now. In our qa environment there is restriction to use instream data. When I kept the sort card in a pds member then it worked.
|
horse manure
| Quote: |
| Its a safety measure to protect case sensitive data from unwanted modifications. |
double horse manure
jcls should be protected anyway
in test most probably the jcl was an <inline> jcl ( no proc )
under qa it was transformed in a fouled up proc with inline data ( SYSIN DD *)
and thats the message received
( just tested )
instream data is not a restriction of the qa environment,
it is a restriction of zOS up to 1.12, zOS 1.13 supports/tolerates inline data in procs
unless.... QA is 1.12 or less and the test environment is 1.13
job
| Code: |
****** ***************************** Top of Data ******************************
000001 //ENRICO0Z JOB (ACCT#),'ZZ1',NOTIFY=ENRICO,
000002 // CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1)
000003 //* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
000004 // JCLLIB ORDER=(ENRICO.TEST.PROCLIB)
000005 //* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
000006 //*
000007 //P01 EXEC ZZ1
****** **************************** Bottom of Data **************************** |
proc
| Code: |
****** ***************************** Top of Data ******************************
000001 //ZZ1 PROC
000002 //S1 EXEC PGM=IEFBR14
000003 //SYSPRINT DD SYSOUT=*
000004 //SYSIN DD *
000005 DUMMY
****** **************************** Bottom of Data ****************************
|
output
| Code: |
********************************* TOP OF DATA **********************************
J E S 2 J O B L O G -- S Y S T E M S Y S 1 -- N
09.58.18 JOB05676 ---- THURSDAY, 05 JAN 2012 ----
09.58.18 JOB05676 IRR010I USERID ENRICO IS ASSIGNED TO THIS JOB.
09.58.18 JOB05676 IEFC452I ENRICO0Z - JOB NOT RUN - JCL ERROR 682
------ JES2 JOB STATISTICS ------
7 CARDS READ
28 SYSOUT PRINT RECORDS
0 SYSOUT PUNCH RECORDS
1 SYSOUT SPOOL KBYTES
0.00 MINUTES EXECUTION TIME
1 //ENRICO0Z JOB (ACCT#),'ZZ1',NOTIFY=ENRICO,
// CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1)
//* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2 // JCLLIB ORDER=(ENRICO.TEST.PROCLIB)
//* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
//*
3 //P01 EXEC ZZ1
4 XXZZ1 PROC
5 XXS1 EXEC PGM=IEFBR14
6 XXSYSPRINT DD SYSOUT=*
7 XXSYSIN DD *
8 DUMMY
STMT NO. MESSAGE
3 IEFC001I PROCEDURE ZZ1 WAS EXPANDED USING PRIVATE LIBRARY ENRICO.TEST.
7 IEFC601I INVALID JCL STATEMENT
8 IEFC601I INVALID JCL STATEMENT
******************************** BOTTOM OF DATA ******************************** |
as usual if the TS had posted a bit more info to start with,
the help would have been more timely and useful
what I posted is what anybody with the desire of getting good replies should post
but naturally we cannot expect it |
|
| Back to top |
|
|
Susanta
Active User
Joined: 17 Nov 2009
Posts: 129
Location: India
|
|
|
|
Hi
I agrre that there may be some problem with versions as you described.
But how to protect case sensitive data in jcl ?
Is there any option available in ISPF to restrict lower case data to stay as it is?
Say if some one opens a dataset and do some little change(little change like creator or jobname change) and press enter then lower case data tends to convert.
Is there any way by which we can protect lower case data from conversion to uppercase in a dataset.
This issue arises because in db2 tables here mixed characters data is in use.
Thanks[/quote] |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
| Quote: |
Say if some one opens a dataset and do some little change(little change like creator or jobname change) and press enter then lower case data tends to convert.
Is there any way by which we can protect lower case data from conversion to uppercase in a dataset. |
if a person is authorized to make changes, then it can
You cannot prevent him/her from making errors.
and anyway ISPF provides lots of messages when the profile changes ( CAPS ON/OFF )
if Your colleagues are just plain dumb, nothing will prevent them from fouling up things
| Code: |
****** ***************************** Top of Data ******************************
==MSG> -CAUTION- Profile changed to CAPS OFF (from CAPS ON) because data
==MSG> contains lower case characters.
|
| Code: |
****** ***************************** Top of Data ******************************
==MSG> -CAUTION- Profile changed to CAPS ON (from CAPS OFF) because the
==MSG> data does not contain any lower case characters. |
|
|
| Back to top |
|
|
Susanta
Active User
Joined: 17 Nov 2009
Posts: 129
Location: India
|
|
|
|
Who remembers to issue caps off each time.
Too old concepts...making life hell . |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
| Quote: |
| too old concepts...making life hell . |
plain bullshit and ignorance
the only moment that You have to enter caps off is when You start using lower case chars
after that the profile behaves accordingly, and data will not be fouled up
that' s the meaning of the two messages I posted
| Quote: |
| I agrre that there may be some problem with versions as you described. |
but You din not post anything helpful to resolve the issue  |
|
| Back to top |
|
|
Susanta
Active User
Joined: 17 Nov 2009
Posts: 129
Location: India
|
|
|
|
Do you issue a caps off each time you open a dataset ??
Please say truthfully.
If you say yes too i will say i don't believe. .. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
| Quote: |
Do you issue a caps off each time you open a dataset ??
Please say truthfully.
|
do You understand the difference between NEW and OLD/existing ?
You have to issue the CAPS OFF only on a NEW/empty dataset member
after that ISPF will tell/warn
if You do not believe it is You problem not mine
it would be wiser for You to get a better grasp of ISPF behavior and PROFILE processing! |
|
| Back to top |
|
|
Susanta
Active User
Joined: 17 Nov 2009
Posts: 129
Location: India
|
|
|
|
But on a same dataset sometime more then one person worksuopn.
So ISPF is...smart enough???
I know you will say yes. |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL
|
|
|
|
| Susanta wrote: |
| But on a same dataset sometime more then one person worksuopn. |
Wrong in so many ways.
No one should be modifying code, let alone data, in any data set to which more than one person has WRITE access; they should copy it to their own sandbox libraries and play with it there (code merging is a whole nother topic). I've reprimanded my analysts for making changes directly to the staging libraries.
And -- how shall I make this clear without either profanity or physical violence -- you pay attention to what you are supposed to be doing!  Not to the cricket match playing in the break room, not to that hot chick that keeps wafting past your desk in a cloud of sandalwood, but to your bloody workstation!
I have JCL data sets with lower-case comments and programmer names in them. That means that ISPF sets the profile to CAPS OFF when I edit them. And -- guess what? -- I remember to change the profile and/or use CAPS LOCK appropriately.
If you can't, I don't want you working in the same shop as me. And I'll do my best to see that you don't. |
|
| Back to top |
|
|
|
|
