× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 04 Jun 2012 08:50, Stone, Joel wrote:
Here is follow-up to better describe the issue, then maybe you can
suggest a more appropriate method to accomplish a solution:

As had been noted already, deferring to a more appropriate language to perform the I/O is likely the better option. Seems that was decided upon; i.e. a COBOL program. However, as called from the CLP, the CLP would best effect the open once, and let the CBL program share that open, so as to prevent the open\close for each invocation of the CBL. Or the CBL could effect a static open and the CLP could either call for a final close or instead reclaim resources or activation group; i.e. as required, to effect the close of the static open.

We do all report distribution via email. EM_Address file exists to
lookup keys and send report to various recipients.

I have an email CL command SNDEMAIL which runs a CL pgm to roll thru
file below and send reports to various recipients.

I want to show keys of this file in the msg of the report. I wanted
to OVRDBF FILE(EM_Address) POSITION(*KEYAE 3 *N INVENTORY STATUS EOD)
and RCVF all three keys for the two matching records and show them in
the msg of the email. After this is done, repeat - ie there can be
multiple sets of email keys to print (not just the one).

When users want to add/change recipients, it is very easy to
identify which records in the EM_Address file require attention
(because the keys will show on each email).

We are on v5R4, so I was not able to find an easy way to position to
a group of records using CL - I could do one group, but not multiple
(once OVRDBF positioned the cursor and RCVF opened the file, any
additional RCVF commands would simply read the next record in key
seq).

I am able to build the list of keys and print them in the email
without doing anything. The trick was that they want to show "(key
not found)" next to any requested keys that don't have records in
the EM_Address file. RCVF would tell me if the FIRST one existed or
not, but subsequent RCVF would read the next record instead of the
keys that I needed to read.

I ended up using a small COBOL pgm to check for key existence and
return a parm if found or not.

EM_key1 EM_key2 EM_key3 seq target em_address
--------- -------- ------- --- ------ -----------------------
AR AGING EOW 1 *TO john.doe@xxxxxxxxxxx
AR AGING EOW 2 *CC sally.doe@xxxxxxxxxxxxx
INVENTORY STATUS EOD 1 *TO warehouse.manager@xxxxxxxxxxx
INVENTORY STATUS EOD 2 *FROM sysop@xxxxxx
G/L TRIALBAL EOM 1 *FROM sysop@xxxxxx
G/L TRIALBAL EOM 1 *TO FINMGR@xxxxxxxxx


The OPNQRYF could do that, but depending on how the data is stored in the CL variable, that is unlikely to be as simple as having the custom program to accept what the CL already declares.

Of course there are any number of other ways than the chosen COBOL program to defer the work to something also not /contained/ within the CL like the OPNQRYF would be. For example, a separate database file object could be created as a VIEW or a temporary output file that is read by the CLP. Again dependent on how the data is stored in the CL variables, the following SELECT as a VIEW might be an option:

with SltLst (k1, k2, k3) as
(select char('INVENTORY', 12)
, char('STATUS', 10)
, char('EOD', 3)
from qsqptabl
union all
select char('another', 12)
, char('other', 10)
, char('xxx', 3)
from qsqptabl
/* etc. or use VALUES(),() when\where available */
)
select k1 concat k2 concat k3
concat ifnull(substr(EM_key1, 1, 0), '(key not found)')
/* perhaps concat a CRLF here */
from SltLst left outer join EM_Address
on k1=EM_key1
and k2=EM_key2
and k3=EM_key3

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.