Norb

The problem might still be that if you put the processes in one RC system internal all the PDF files in one Email will not work.

You would get one mail with 115 attachments.

I would split it in a few managerial parts, but you need to find out how long each subprocess runs so they won't work against each other.

Here's an easy suggestion try creating thes in a compound PDF and string them together in a "master" fex.

This would look something like;

-*Procedure 1
SET COMPOUND=OPEN
-INCLUDE fex1
-RUN
-*Procedure 2
SET COMPOUND=OPEN
-INCLUDE fex2
-RUN
.
.
.
-Procedure last
SET COMPOUND=CLOSE
-INCLUDE fexlast
-RUN

in each procedure you would have ON TABLE PCHOLD FORMAT PDF

When you're done, you have one big PDF file, print it, and you're done.

I think you could accomplish something similar with a ReportCaster job so as to not have to set up 115 different schedules.

Darin

I think in theory this could work, but in fact you create one big fex and the system might be screwed-up by using the same DM and amper variables or pointers and loops, so that's why I suggested to first take a look at all the joins and other used variables.
And if you have for example an exit command in one of the subprocesses the application stops.

Duplicate DM labels could definitely be a problem, JOINS should be handled within each fex (I make it a habit to always JOIN CLEAR * before I do a join). If there's a -QUIT or -EXIT that's going to cause a problem with ReportCaster, too. All good things to be considered.

IMO, it would be far less work to got through each procedure and make sure they play nicely together and then run them all at once as opposed to running and printing 115 separate reports. That's gotta be a major time killer!

Hi All,

Here is a respresentative example of the fex that runs everything in batch mode.

-* run the Comparative Income Statements - summary and detail
-SET &REPNAME = '1-compincome_sbl_summary';
-*SET &FULLNAME = &APPFOLDER || &SUFFIX || &REPNAME || '.PDF';
-SET &FULLNAME = &APPFOLDER || &SUFFIX || &REPNAME || '.PDF';
EX GREENBOOK/5509229s01 FISCAL_YEAR='&FISCAL_YEAR', LEDGER_PER='&LEDGER_PER', FNAME='&REPNAME', FULLNAME='&FULLNAME'

-SET &REPNAME = '2-compincome_sbl_detail';
-SET &FULLNAME = &APPFOLDER || &SUFFIX || &REPNAME || '.PDF';
EX GREENBOOK/5509229d01 FISCAL_YEAR='&FISCAL_YEAR', LEDGER_PER='&LEDGER_PER', FNAME='&REPNAME', FULLNAME='&FULLNAME'

The DM vars &FISCAL_YEAR and &LEDGER_PER are retrieved from the user with a little launch page. Inside of each called fex I have this little code to setup the saved filename:

APP FI &FNAME DISK &FULLNAME
-RUN

and then this to save the file:

ON TABLE HOLD AS '&FNAME' FORMAT PDF

There are hold files contained within the fexes which have the same name across fexes but I changed the two that I tested to have unique names and the results still are not correct. Are you saying that each fex needs to have it's own unique set of DM variables as well?

If I use ReportCaster, it seems to me that I would need to create a separate task for each of the 115 fexes or they would stomp on each other again.

Isn't there a way to pause the code in the fex that drives the batch process until it can verify that the Fex1 is complete before firing off Fex2? Seems like it shouldn't be this hard to do.

Thanks,

Norb

following on with what Darin said, i suggest using a technique i got from FrankieMartini...
-SET &KOUNTER=&KOUNTER+1 ;
-TYPE now doing report &KOUNTER
EX where/NEXTFEX parms...
-RUN
-IF &FOCERRNUM NE 0 GOTO busted;
-SET &KOUNTER=&KOUNTER+1 ;
-TYPE now doing report &KOUNTER
EX where/NEXTFEX parms...
-RUN
-* now clear your joins and uses and filedefs
-* lather rinse and repeat
-SET &KOUNTER=&KOUNTER+1 ;
-TYPE now doing report &KOUNTER
EX where/NEXTFEX parms...
-RUN

-...
-busted
-TYPE busted at report &KOUNTER
-* and end your fex here.
-*----------------------------------------
keep checking the FOCERRNUM to make sure its zero. if its not, bail out .

EX syntax is different from -INCLUDE
-INCLUDE accepts parms from the workspace and return parms...but if you have GOTO label names that are the same in 2 fexes, you're so screwed.
EX syntax is safer, runs each fex in its own wee container, only takes parms from the launch line, and doesn't pass any out.
-INCLUDE means you really have to be careful to clear joins and defines, and be warry of existing &vars.
The governing fex (the container that has all 115 EX's in it) can take one set of parms from a launch page and populate the parms on each command line.
You have users that will click Submit and wait for 115 fexes to run? wow.

Hi Everyone,

At this time please don't put any more brain power into this problem as I think I may have resolved the issue. In looking over over the fexes I saw that there was this little line in each one: DEFINE FILE F0902 ADD

This would indicate something about saving the defined fields and consequently values were not being reinitialized as they would be during one by one manual execution. I added DEFINE FILE F0902 CLEAR to the end of each fex and ran the batch fex that drives the whole enchilada. To my delight, after a cursory review, the reports appear to be correct. Yahoo? Maybe. I've asked our accounting department to validate the reports and will know tomorrow if this has resolved the issue. I hope so as this would be a useful technique.

Susannah - Do you think the -RUN statement is required after an EXEC? I am not using them but am not sure either. And yes, we do have users that are happy to click a button and wait for 115 fexes to run. It currently takes over an hour of a person's time to click the correct parameters and run the reports. Then another 4 hours to print and assemble the output into bound manuals for distribution. The plan is to go paperless and place the PDF files onto the Sharepoint server for self-service.

BTW these 115 reports were written by an outside consultant so I wasn't very familiar with the code. (personal disclaimer )

Thanks everyone for their help.

Norb

You only need the -RUN if there is Dialogue Manager involved and you have to have FOCUS code executed before a DM command. The -RUN flushes and executes the current contents of FOCSTACK, i.e. any commands that don't have a dash in front of them.

So the answer is no, you really don't have to depending on your requirements.

as Ginny says,
the -RUN forces all regular focus code sitting in front of a dialog manager command to run...
If you're going to loop, or use some DM to kount things, as in my example,...then -RUN is needed.

Hi All,

Just following up to say that the code I added to the reports as per my post on Sept. 30, 2008 at 10:59pm did indeed work correctly. The 115 reports were validated by the accounting department and found to be correct! Yahoo!

Thanks again for everyone's help and support. You are all a great bunch of peeps.

Norb