Write work file from Natural online program

Hi all,

My requirement is to create a workfile from online Natural program. I should collect data user give me and store it somewhere and trigger a batch to use this collected data. ( I am clear about triggering batch from online)

I can use intermediate adabas files , but i dont want to , as initial attempt. you think there is a possibility to create a workfile to hold my data ? If so, how do I refer to it in my batch job?

Thanks for your time&help.

Regards,
Satya.

Hi Satya,

Natural communicates with flat files (datasets) through the CMWKFnn DD card. I am sure you are well aware of this in batch, but online access to a flat file does not translate well unless you can have your own online nucleus to build at will, but I digress.

One possible way around this is if your shop has Entire System Server. You can access flat files directly from online using the interfaces that come with that product. You may wish to explore this if your data extraction is minimal.

However, there is always more than one way to skin a cat, and the best practice would be to pass whatever parms you need to extract the data to a batch process with one or more steps. Having an online session running while extracting some large amount of data and writing out to some device is not an efficient use of the transaction processor, and could have an adverse impact on the other online users who are expecting subsecond response time.

Even though I offer one possible way to do what you wish to do, I highly recommend avoiding that approach in favor of letting batch Natural do the heavy reading and writing.

Agreed Brian!

A program would either be an online or a batch. I am really doubtful if we can code something like READ/WRITE WORK FILE in an online program. These statements are known for batch operation.

However, the way I know is to invoke Natural through TSO from where you seek for user input and then write it on to a work file (by defining it). Not sure if can be applied in real business world/logic (helpful sometimes during debugging though).

I am curious how it can be done in a pure CICS environment or few other TP monitors. Will wait experts comments :? .

Ofcourse one way (I came to know) as suggested by Brian is to use Entire System Server (not recommended though!)

Hi Satya,
If (by any chance) your environment is Z/OS with TSO and a users data volume is relatively small (I assume that), Id recommend to create some kind of CLIST procedure (very simple) which would
a) allocate a new dataset as follows

alloc dataset(input.data) file(CMWKF01) new space(10,2)
tracks release
That would create and allocate DSN=USER.input.data within TSO; this DSN would be available to your batch job (a tricky part will be to provide your JCL with the proper USER)
b) call your NATURAL/TSO interface (in order to enter into a NATURAL session)
c) collect the USER data (through your online NATURAL program), then submit the JCL (please don`t forget about that USER value in order to reference the “good” USER.input.data )
d) free your allocated dataset (to have it disconnected from TSO)
e) END OF JOB :slight_smile:

Hope that may help you.
Good luck

Thank you Brian,KVN and ATS for your quick response and wonderful explanations. I am not very good at the Entirex service suggested by you. Also, our users have a menu once they logon to mainframe from which they go to their natural online screens(its all connected!), i dont think they are related to TSO ( I dont have much knowledge on KVN`s response as well) :roll: :!:

For now, I am opting to save my data in intermediate adabas files so that my batch job picks it up. :slight_smile:

Regards,
Satya

You can execute WRITE WORK and READ WORK statements in Natural under CICS, but the datasets won’t be available to batch jobs after the on-line session ends.

If the WORK records are short and the file is relatively small (this should be so, since you’re creating the data on-line), write the records as in-stream data in your “triggered” JCL stream. If necessary, a job step can copy the data to a cataloged dataset.

//NAT  EXEC NAT 
//CMWKF01  DD * 
client1 acct1 action1 
client2 acct2 action2 
/*

You can well create ‘flat files’ in CICS as work files in NCI and close these work files upon session termination (CLOSE=FIN, see OPEN and CLOSE parameters): such a work file has to be defined in CICS as extra-partition destination. The larger concern is that all resources in CICS (as files, TD queues, etc) are common/shared resources, i.e. a file is not dedicated to a specific session, some sessions might right into this file concurrently. NATRJE could be used to start the batch job.
Another option could be to run the ‘batch’ in CICS: rather than using an extra-partition destination you could use an intra-partition destination, for which a transaction id and a triggerlevel is defined: when a certain number of records (triggerlevel) has been written to this destination, the transaction associated with this destination is started. The transaction could be associated with a Natural front-end program starting a Natural program reading/processing this TD work file until EOF. Note that this approach also has the benefit (if possible or desired), that ‘online’ and ‘batch’ run in paralllel: ‘batch’ is already processing the file, while ‘online’ is still adding records.
These are just technical possibilities in CICS and with NCI; if they fit really depends on the nature of the application.

We use the NIM TP Monitor.
NIM allows online Natural access to z/OS datasets :slight_smile:

http://www.ccasoftware.com/site/index.php?option=com_content&task=view&id=28&Itemid=41

NIM (Natural Interface Module) is a lightweight TP Monitor written specifically for Natural. It does not have these CICS limitations.

It’s a fact that there are lots of online job providers working nowadays, but I recommend you to visit www.utubeonlinejobs.org as this is a first registered company of the Pakistan. I found its setup, working environment quite elegant, friendly and smooth

This does not belong here, Zaheer. I hope this is not the sole reason for coming here asking about RPC servers.

Kuwait, then South Africa… now Pakistan. Hmmmm.