Reading a dynamically-named flat file in CICS

Question

Suppose I've a batch job which has previously run and created a flat output file of fixed record length. (The output file name will vary for each run of the job.)

I've a CICS program running in a server environment which will receive a request from a web browser for the job results, and I want to read the file and return the content. (Assume the specific file name to use will be included in the text.)

I'm trying to work out how to actually access the file in CICS.

I'd managed to dynamically specify the filename using CEEENV, but then discovered that I can't use the native OPEN/READ commands. I know there are CICS read and browse commands, but they all seem to require having the file defined to CICS beforehand? I've also seen references to using transient data queues to access sequential files, but again, the queue needs to be pre-defined.

The file won't have any particular structure or suitable key, so it looks like I should use the BDAM file commands. Which seems to require a FCT entry. But I can't find any decent examples of how to create that.

Obviously, the web service could be called frequently and concurrently, so I need some way of temporarily associating the file with a means of accessing it, which I can free as soon as I'm done with it.

Obviously, I'm not that familiar with the CICS environment. I feel like I'm either missing something simple, or there's a fundamental reason why this can't be done. Pointers towards either would be welcome!

Answer 1

As the file is a flat file rather than a VSAM cluster of some sort, I'd suggest you read it as an input Extra Partition Transient Data Queue (Extra TDQ).

The data set name can be included in the resource definition but because the data set name cannot be changed using the System Programming Interface, changing to a new data set could be achieved using the CICS ADYN tool but I'd recommend closing and disabling the queue with a SET TDQUEUE command and then replacing it with a CREATE command from within your program.

Alternatively, you could create a new queue for each request using some mechanism to ensure the name is unique within the CICS region, read the queue and then discard the queue again.

Answer 2

You can use the CICS SPI to dynamically do the resource definition for the file, but it isn't a good idea, really more of a pain in the ass, there are just too many considerations -- high availability, which file owning region, the headaches abound.

Anything CAN be done, it is just a computer after all, but you will be violating all of the assumptions that went into building the framework of CICS/TS for the last half century or so. It manages the resources to get maximum concurrency of all tasks running for maximum efficiency of all machine resources. Doing what you suggest could put the entire region into an OS wait state and lock everything up unless you massage it all just right.

If it is just a simple flat file, copy it into a predefined ESDS at the end of the job that creates it and trigger your CICS task read it from there, your debugging life will be much easier and your CICS SysProgs will not hate you and curse your name forever. Or you could use a KSDS keyed with the unique file name and a record sequence number, and process using STARTBROWSE/READNEXT/ENDBROWSE for just those records.

Answer 3

I've done this with Unix Systems Services files via calls to C runtime routines from COBOL. FOPEN, et. al. are available to you.

It is vital that your program execute on an open TCB and that it be thread safe.

If you're running CICS TS 4.2 or later you must define your program as CONCURRENCY(REQUIRED) so you know it's on an open TCB and not on the QR TCB. Doing I/O on the QR TCB is bad for performance and throughput and potentially your continued employment. If your program doing the I/O is not the first program in the transaction, you must LINK to it and not dynamically CALL it in order for the TCB switch to take place automatically.

If you're running CICS TS 4.1 or earlier you must jump through some hoops to force your transaction onto an open TCB. Hopefully you're on a more current version.

Explain this to your CICS Systems Programmer, that you're going to do QSAM I/O but you're going to ensure you're on an open TCB to avoid performance issues.

If you don't know what the different TCBs are about, please consult the documentation. There's a redbook on the topic of thread safety that covers the TCBs. It's well worth your time.

Another way to accomplish this would be to load the data into a DB2 table (if your shop has DB2) at the end of the batch job.