|
View previous topic :: View next topic
|
| Author |
Message |
JPVRoff
New User
Joined: 06 Oct 2009
Posts: 41
Location: Melbourne, Australia
|
|
|
|
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...  |
|
| Back to top |
|
 |
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
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 |
|
|
JPVRoff
New User
Joined: 06 Oct 2009
Posts: 41
Location: Melbourne, Australia
|
|
|
|
| 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 |
|
|
JPVRoff
New User
Joined: 06 Oct 2009
Posts: 41
Location: Melbourne, Australia
|
|
|
|
| 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 |
|
|
David Robinson
Active User
Joined: 21 Dec 2011
Posts: 199
Location: UK
|
|
|
|
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 |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
No samples for what you want in the SEQQSAMP library?
Maybe the batch loader could help? |
|
| Back to top |
|
|
JPVRoff
New User
Joined: 06 Oct 2009
Posts: 41
Location: Melbourne, Australia
|
|
|
|
| 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 |
|
|
JPVRoff
New User
Joined: 06 Oct 2009
Posts: 41
Location: Melbourne, Australia
|
|
|
|
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 |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
| Back to top |
|
|
JPVRoff
New User
Joined: 06 Oct 2009
Posts: 41
Location: Melbourne, Australia
|
|
|
|
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 |
|
|
David Robinson
Active User
Joined: 21 Dec 2011
Posts: 199
Location: UK
|
|
|
|
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 |
|
|
JPVRoff
New User
Joined: 06 Oct 2009
Posts: 41
Location: Melbourne, Australia
|
|
|
|
| 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 |
|
|
David Robinson
Active User
Joined: 21 Dec 2011
Posts: 199
Location: UK
|
|
|
|
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 |
|
|
JPVRoff
New User
Joined: 06 Oct 2009
Posts: 41
Location: Melbourne, Australia
|
|
|
|
| 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 |
|
|
David Robinson
Active User
Joined: 21 Dec 2011
Posts: 199
Location: UK
|
|
|
|
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 |
|
|
|
|
