JCL problem-OC4

[cobp]

Hi,

This is purely a JCL problem. Hope any COBOL programmers would help me.

I got a SOC4 abend in an IEBCOPY step. But it's O.k for one IBM machine, but it caused the problem for another IBM machine.
In the job step contains a DD statement that allocates temporary dataset - SPACE
=(CYL,(1500,500,50).

Does this cause the problem, then why didn't I get the problem on first machine. If any fruther info required, pls. drop me note.

Thankx and Regards,
cobp.

 

[Crox]

Hi,

better place this on

http://mvshelp.com/cgi-bin/ubbcgi/f...forum=d)+JCL&number=4&DaysPrune=10&LastLogin=

Regards,

Crox

 

[NinaToo]

SOC 4, as I recall, is a "protection exception" abend. Which means that some quantity is out of bounds, usually a table which has gone over its max.

I would look at the programs involved to see if anywhere, there is a table being loaded which exceeds the number of OCCURS.

Also, I wonder if the space that you have allocated for your temporary file is too small. Though I don't think that this generates a SOC 4, but maybe in your system it does.

Hope this helps, Nina Too

 

[Crox]

IEBCOPY is a IBM utility....
so not the program of cobp
'purely a jcl problem'
jcl=job control language on the mainframe
CYL,(1500,500,50) is very very much... I guess too much!
Good JCL specialists are on MVSHELP.

Regards,

Crox

 

[NinaToo]

Sometimes JCL problems, such as SOC 4 and SOC 7 abends, can be a result of faulty coding in a program. Such as having a table which doesn't have enough OCCURS for the actual file, or else trying to put in an alpha character into a PIC 9 COMP field.

So sometimes these definitely are programming problems.

Nina Too

 

[Crox]

Ok NinaToo, Sorry, I thought that you have no access to the source of IEBCOPY, but if you have and can also help IBM out of trouble, I will be silent. Sorry again! :~/

With Warm Regards,

Crox

 

[NinaToo]

In an IEBCOPY step, a SOC 4 wouldn't likely be a result of a programming problem in IEBCOPY. It's probably some sort of system thing.

Though I wonder still if it's possible that a programming problem could occur in an earlier step of a job using IEBCOPY, and somehow doesn't become apparent until the IEBCOPY step.

Nina Too

 

[StephenJSpiro]

Your 3 different cylinder allocations means that your file is either ISAM or PDF. Is that correct? Give us the complete JCL, please...
Unless you just copied it wrong, you are also missing a closing parenthesis.

Stephen J Spiro

 

[winzip]

One IBM machine does not necessarily equate to another IBM machine. JCL that works with one IBM machine may not work with another IBM machine for a variety of reasons... think operating system.

I understand IEBCOPY is an IBM utility but if you peek into IBM's Technical Manuals that discuss IEBCOPY you will likely find descriptions of how this utility works are delineated by what kind of environment they are used in.

Another issue to consider: what types of DASDs are we talking about here? Are they the same for both machines? 1500 cylinders in one medium may be alright but may not necessarily be in another.

Finally I would agree with Mr. Spiro: we'd need to see your entire JCL to be of any help.

 

[winzip]

I hate to prolong this but I'm new here so I hope you will forgive me...

Crox and Nina are BOTH right:

S0C4 is usually a 'protection exception'
IEBCOPY is an IBM utility

But like I mentioned before 1500 cyclinders may be quite OK in certain environments - I have jobs that normally have that amount for primary allocations...

which caused me to think again---

I mentioned operating system and media type; but I seem to remember that you can have a S0C4 abend when you try to run something that is not in your environment - so maybe you should check if you have IEBCOPY at all; check your defaults in SYSLIB. But of course I could be way off base on this.

It will also help if you check your SYSOUT, your SYSMSGS for additional explanation on the abend.

Now I will shut up.

 

[Crox]

Yeah!

Suppose you don't have a SYSOUT defined, that can be the cause of a 0C4.....



Regards,

Crox

 

[StephenJSpiro]

Just noticed a typo in my last post :~/ : 3 space allocations are used for ISAM files and for PDS's (NOT PDF's!). For ISAM, the third allocation is the number of index tracks; for Partitioned Data Sets (or PDS(E), Extended Partitioned Data Sets), the third allocation is the number of 64 byte directory blocks.

Stephen J Spiro

 

[cobp]

Hi,

Problem was occured to the wrong data file as reproted by the user. This file should be uploaded to OS/390 as RECFM=F, but in one machine it was uploaded by specifying RECFM=V.

I am not sure this, because this problem was reported by person using the different OS/390 machine. I provided him the JCL, and a datafile. He claimed that he used same datafile( and File uploading procedure was correct) and same jcl.

So sorry for reporting this wrong problem here.

Thanks and regards,
CobP