Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

OPC/Tivoli OCL failure (line 1560)

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> IBM Tools
View previous topic :: :: View next topic  
Author Message
JPVRoff

New User


Joined: 06 Oct 2009
Posts: 24
Location: Melbourne, Australia

PostPosted: Mon Dec 01, 2014 7:13 am    Post subject: OPC/Tivoli OCL failure (line 1560)
Reply with quote

Hi all,

I've been struggling with the EQQOCL (compiled Rexx) program, trying to get it to load our fairly complex GROUP (or what we call 'schedule'). The end result is that we're getting this failure in the Rexx:
Code:

  1560 +++   totentry = totentry + table.za.0                                   
  8640 +++  result = ADDCHECK(oclline)                    /* ADDCHECK routine */
   409 +++ retc = CALLROUTINES(in.vvv)                                         
EAGREX4100E Error 41 running compiled EQQOCL1, line 1560: Bad arithmetic conversion

Normally, I'd have a look at the source and be able to work out where this is coming from, but being a compiled Rexx, I have no access to the source. There are a couple of other messages produced prior to the abend (the former is in SYSTSPRT and the latter in EQQMLOG - and there are equal numbers of these messages in both output DD's, so I'm assuming they are related), but neither is specific regarding what application(s) are in error:
Code:
EQQCL4LW Operation XOPNUM not found: APPL() IA(1412011201)
12/01 12.01.22 EQQY708E A SELECT REQUEST WITH MORE THAN ONE RECORD SELECTED, RESOURCE IS AD
Is anyone able to offer any advice on this? My immediate thought is to use my own Rexx to read the database and work out the correct order in which to load the applications - and to then do so app by app (rather than trying to load the whole group). This is a little frustrating, as the group loads perfectly well when done via the ISPF Tivoli tools - it's only when trying to do it via batch that I have this problem.

P.S. Why am I doing this - I forgot to mention that? Basically, our test batches can run in a whole series of ways (stand-alone, sending/receiving files, removing or adding applications) but are based around the production schedule of jobs. At present, this is handled (badly) by manual loading and then a series of 'screen scraper' scripts to modify the 'schedule' as is needed. Of course, as with any manual process, it's only as good as the last missed keystroke.
The simplest solution would be to have the schedule loaded based on information from a simple ISPF screen - but this is where we hit our hurdle (above). I don't like reinventing the wheel, so if I can use the GROUP parameter of the ADD OCL command, then I'd like to do that.
N.B. I tried using the GDEPRES(N) parameter and got all (200+) applications in the GROUP starting at once. NOT the solution I was hoping for... icon_eek.gif
Back to top
View user's profile Send private message

expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8593
Location: Back in jolly old England

PostPosted: Mon Dec 01, 2014 3:02 pm    Post subject:
Reply with quote

Can you not run a dummy little REXX before your compiled EXEC
Code:
/* REXX */
TRACE I
EXIT

Hopefully to switch on tracing.

Only ever worked with compiled REXX once so not sure if it might help or not
Back to top
View user's profile Send private message
JPVRoff

New User


Joined: 06 Oct 2009
Posts: 24
Location: Melbourne, Australia

PostPosted: Tue Dec 02, 2014 11:28 am    Post subject:
Reply with quote

I've never seen this work before - but then I've never tried it. I'll see how we got, but I'm not sure that the trace would pass on. But you'll never never know, if you never never go!
Back to top
View user's profile Send private message
JPVRoff

New User


Joined: 06 Oct 2009
Posts: 24
Location: Melbourne, Australia

PostPosted: Wed Dec 03, 2014 8:41 am    Post subject:
Reply with quote

expat wrote:
Can you not run a dummy little REXX before your compiled EXEC
Code:
/* REXX */
TRACE I
EXIT

Hopefully to switch on tracing.

Only ever worked with compiled REXX once so not sure if it might help or not


Doesn't work in any way I try it (whether calling the compiled Rexx from within the 'dummy' Rexx or having it ran afterwards). No response from IBM either - so I expect I'll have to rewrite the processing and load all the applications in order myself. Unfortunate...
Back to top
View user's profile Send private message
David Robinson

Active User


Joined: 21 Dec 2011
Posts: 175
Location: UK

PostPosted: Wed Dec 03, 2014 1:06 pm    Post subject:
Reply with quote

Probably not quite the answer you're looking for, but perhaps your company would be interested in TWSeasy from APS Enterprise.

It may be another way to achieve what you're after.
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Wed Dec 03, 2014 1:41 pm    Post subject: Reply to: OPC/Tivoli OCL failure (line 1560)
Reply with quote

No samples for what you want in the SEQQSAMP library?

Maybe the batch loader could help?
Back to top
View user's profile Send private message
JPVRoff

New User


Joined: 06 Oct 2009
Posts: 24
Location: Melbourne, Australia

PostPosted: Thu Dec 04, 2014 6:57 am    Post subject: Re: Reply to: OPC/Tivoli OCL failure (line 1560)
Reply with quote

PeterHolland wrote:
No samples for what you want in the SEQQSAMP library?

Maybe the batch loader could help?

Hi Peter,

There appears to be two versions of the batch loader. The one I was having trouble with (running EQQOCL to run and OCL 'ADD' instruction) and the other one (using a different procedure and the ACTION=INSERT,RESOURCE=CPOP instruction).
When you're using either of these two methods to load a complete 'GROUP' of applications, all of the external dependencies of the individual applications are ignored. This results in (in our case) 200 out of 206 applications all starting at once. And there appears to be no way around this - except to load all the applications individually and in the right order.
This is a pity, as I can do the same operation via 5.1 in Tivoli and it works fine!
So it looks like I'm going to have to develop my own method of doing this, probably by reading the unloaded parmeters and workling out what order to load them in.

And David, I'm fairly sure that IBM, the company that runs this particular site, won't want to move away from Tivoli to another (non-IBM) product. As we're a third party anyway, I'm not even going to try to go down that path.
Back to top
View user's profile Send private message
JPVRoff

New User


Joined: 06 Oct 2009
Posts: 24
Location: Melbourne, Australia

PostPosted: Thu Dec 04, 2014 7:48 am    Post subject:
Reply with quote

Hmmm. It's even worse than I had hoped. Loading in the 'first' of the GROUP applications and then loading in the subsequent ones - there is no correlation between the applications already in the current plan and those being loaded. So they simply start - same as if I try to load the whole group.
What a pain in the 'proverbial'.
Looks like I'm going to have to do this semi-manually; unless there's some set of commands for doing stuff in OPC via a batch interface that I have missed.

OPC has gone another step doen in my estimation; and it was already pretty low!!!
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Thu Dec 04, 2014 1:54 pm    Post subject: Reply to: OPC/Tivoli OCL failure (line 1560)
Reply with quote

Did you follow all the rules for setting up your applications/groups, see :

https://publib.boulder.ibm.com/tividd/td/TWS/SC32-1263-00/en_US/HTML/EQQR1MST168.htm
Back to top
View user's profile Send private message
JPVRoff

New User


Joined: 06 Oct 2009
Posts: 24
Location: Melbourne, Australia

PostPosted: Fri Dec 05, 2014 2:51 am    Post subject: Re: Reply to: OPC/Tivoli OCL failure (line 1560)
Reply with quote

PeterHolland wrote:
Did you follow all the rules for setting up your applications/groups, see :

https://publib.boulder.ibm.com/tividd/td/TWS/SC32-1263-00/en_US/HTML/EQQR1MST168.htm

Uh oh! Peter, I may have fallen into the hubris trap (again).

Unfortunately these are 'copies' of 'most' of the production schedule(s) and have been copied down and stripped (a little) and are loaded manually rather than scheduled. This is due to the test batches being adhoc and not all the jobs will run properly in the testing regions.

And I have to admit that OPC is not my first language:(

The GROUPs, as unloaded, seem to be fairly simple, just a bunch of ADSTARTs (just over 200) and ADOPs (~1550) with a few resourses in there as well (~140). It all looks very similar to the example you posted the link to. The 'problem' that I am having is that I cannot seem to get the equivalent of the last ADDEP (in the example) to take effect. So, despite there being a dependency such as
Code:
ADDEP    PREWSID(CPU1) PREOP(020) PREADID(PAYDAILY)
         DESC('WAIT FOR PAYDAILY')
the job still starts as soon as the app is loaded - when I use the batch loader.

When I go into 5.1 in Tivoli and pick an application from the relevant group and 'G' select it, I have no trouble in loading the 'batch', as it were. When I tried to load a whole GROUP via EQQOCL (as mentioned in the first post), I get from 2 to 150 (depending on the GROUP I'm loading) of those errors I mentioned. Unfortunately, there does not seem to be a way to link the errors back to any defined operation in the GROUP.

Would it matter in what order the applications/operations are defined when you load up the group into the database? The batch load operations (whether EQQYCAIN or EQQOCL) both seem to do it in alphabetical order.

Anyway, I'm going to go back to loading manually for the present and maybe have another look after Christmas - as the number of runs is very few during this period.
Back to top
View user's profile Send private message
David Robinson

Active User


Joined: 21 Dec 2011
Posts: 175
Location: UK

PostPosted: Fri Dec 05, 2014 2:51 pm    Post subject:
Reply with quote

I might be missing something here, but rather than loading the applications in to the current plan with your batch job, couldn't you build them in the database and then add them in as usual via 5.1? That way there shouldn't be any issue having dependencies resolved between groups as you mention.

It doesn't matter what order they are loaded in to the database. External dependencies are not resolved until they are added to the current plan.

TWSeasy is an add-on to TWS by the way, not a replacement.
Back to top
View user's profile Send private message
JPVRoff

New User


Joined: 06 Oct 2009
Posts: 24
Location: Melbourne, Australia

PostPosted: Mon Dec 08, 2014 4:16 am    Post subject:
Reply with quote

David Robinson wrote:
I might be missing something here, but rather than loading the applications in to the current plan with your batch job, couldn't you build them in the database and then add them in as usual via 5.1? That way there shouldn't be any issue having dependencies resolved between groups as you mention.

It doesn't matter what order they are loaded in to the database. External dependencies are not resolved until they are added to the current plan.

TWSeasy is an add-on to TWS by the way, not a replacement.

David, you're not missing anything. That's the way I'll do it for now (and in future unless I can work something out). What my plan was...
    Unload the group applications
    Modify, delete and reload
    Submit the group
    Delete and restore the original group

...and to do it all in the one hit. This is just a little more long-winded, but should work the same.

This is resolved unless I find out something else (or work out how to fix the 'errors' in the original group set-up).
Back to top
View user's profile Send private message
David Robinson

Active User


Joined: 21 Dec 2011
Posts: 175
Location: UK

PostPosted: Mon Dec 08, 2014 3:53 pm    Post subject:
Reply with quote

If you use the Program Interface (EQQYCAIN) to add the applications to the current plan it seems to work. I'm not sure about OCL, I haven't used that much.

When you add the applications to the CP with the PIF, shoudn't you use RESOURCE=CPOC? RESOURCE=CPOP is for individual operations isn't it, not applications?

The other point is that you must tell TWS that the external dependencies should be resolved. So specify this before your INSERT statements -

ACTION=OPTIONS,CPDEPR=Y;

That seems to work for me.
Back to top
View user's profile Send private message
JPVRoff

New User


Joined: 06 Oct 2009
Posts: 24
Location: Melbourne, Australia

PostPosted: Tue Dec 09, 2014 8:09 am    Post subject:
Reply with quote

David Robinson wrote:
If you use the Program Interface (EQQYCAIN) to add the applications to the current plan it seems to work. I'm not sure about OCL, I haven't used that much.

When you add the applications to the CP with the PIF, shoudn't you use RESOURCE=CPOC? RESOURCE=CPOP is for individual operations isn't it, not applications?

The other point is that you must tell TWS that the external dependencies should be resolved. So specify this before your INSERT statements -

ACTION=OPTIONS,CPDEPR=Y;

That seems to work for me.

Thank you, David,

I was using CPOC, not CPOP, my apologies for the mistake in my post. But I did not have the dependency parameter set. Thank you for that. I tried it immediately...
Unfortunately I now get the message(s):
Code:
EQQYCICC:NUMBER OF APPLICATION RECORDS SELECTED            = 200
EQQYCICC:CROSS DEPENDENCIES NOT HANDLED,RC=8                   
EQQYCAIN:INSERT    CPOC                RC=0008                 
This seems to indicate either that OPC (or EQQYCAIN) isn't set-up to handle cross dependencies, or that the applications in our group are too complex. I cannot seem to locate these messages in any of our manuals - indeed, they don't seem to have the same format as the message in the M&C manual. I tried a web search and it came up with nothing either.
It looks as though EQQYCICC is a subroutine of EQQYCAIN, as I've seen a couple of APAR descriptions that refer to it.
When I split the GROUP up into separate ADIDs, it loads all those that do not have cross dependencies on any jobs already loaded, but fails to load any that do (and produces the same message).
Back to top
View user's profile Send private message
David Robinson

Active User


Joined: 21 Dec 2011
Posts: 175
Location: UK

PostPosted: Tue Dec 09, 2014 3:00 pm    Post subject:
Reply with quote

It would seem that the method of adding programs via the PIF is not quite the same functionally as using option 5.1 in the panels, which seems odd. In particular, cross dependencies are not handled, that is, cases where a particular application has both predecessors and succesors in another particular application.

I have tried this with a simple set of two applications. Using 5.1 they are added fine and dependencies are resolved. Using the PIF I get the same message as you. I found this in the manual -

Cross dependencies are not supported. That is, if APPL1 contains an
external dependency on an operation of APPL2 and APPL2 contains an
external dependency on an operation of APPL1, this will be detected and
the BCIT job will terminate with RC=8 (in this case, the INSERT will not
be performed).

This almost seems like a bug, but since it's documented in the manual it must be a "feature". Seems like a bit of a flaw though. At least you know what the problem is, and you will have to find some other way around it.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> IBM Tools All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Insert Lines in JCL with Rexx after a... Willy Jensen CLIST & REXX 3 Tue Aug 30, 2016 4:18 pm
No new posts ISREDIT - Position Cursor on the Comm... Tarique Anwer TSO/ISPF 5 Wed Feb 03, 2016 12:44 pm
No new posts Use Edit Line Command Table with ISPF... Mickeydusaor TSO/ISPF 5 Thu Jan 28, 2016 4:52 pm
No new posts ISPF 3.4, SF line command does not su... Pedro TSO/ISPF 0 Fri Jan 15, 2016 11:09 pm
No new posts Can someone explain me this JCL line ... PeterHolland JCL & VSAM 9 Sat Dec 12, 2015 7:22 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us