I posted this to cics-l but haven't gotten any response, so I figure I should post it here as well.

I'm pondering using channel containers in places where we currently use temporary storage queues. There are advantages to containers, but they are also lacking some features. I'm wondering about other peoples' thoughts on these matters.

Advantages of channel containers over temporary storge queues:
- Not limited to 32k per record.
- Not limited to 32k records.
- Not shared between separate tasks (but can be used to pass data to a new task).
- Automatically cleaned up at task termination (unless explicitly passed to a new task).

Disadvantages of channel containers over temporary storge queues:
- Byte based instead of record based.
- Cannot update part of a container without replacing all of the data within the container.
- Simulation of fixed length records in containers is slightly more complex than dealing with an actual record- based storage.
- Simulation of variable-length records in containers, while possible, is not at all straightforward.

I think most of the disadvantages are a result of designing channel containers as replacements for COMMAREA and not really designing them as a replacement for TS queues. Would I be going in the wrong direction by using containers as a replacement for TS queues. The main issue I'm running in to currently is we have "client" programs that link to "service" programs and currently use TS queues to pass back some of the results. Specifically, results that are "record based". But we're concerned about hitting the limit of the number of records in the queue. We already ran in to an issue when we hit more than 10,000 records, because the COBOL data field that held the "item number" was defined as PIC S9(4) COMP, which (as per standard COBOL behavior) rolled over from 9999 to 0 when we added 1 to it. This was fixed by changing it to a COMP-5 ("native binary"), but we're still limited by the fact that a half-word signed native binary field has a maximum value of 32767.

I can think of several enhancements that CICS should support, but who knows when or if they would be implemented.

------------------------------
Frank Swarbrick
------------------------------

Hi Frank.  I saw your message to CICS-L, but was waiting to see if anyone else would respond.

You could indeed use Channel-based Containers within a single task (regardless of how many programs are involved).  Recognize that a given Channel belongs to one task.  As you mentioned, the Channel can be passed to another task with a START command, but there's no mechanism to return that Channel to the original task.  Note also that Channels and the Containers within them are not recoverable.  That's another difference between Containers and TS Queues.  Perhaps the Asynchronous API would be a good fit for a multi-task application using Containers.

Another option would be to use BTS-based Containers.  These are designed to have longer lifetimes and to exist longer than a single task.  If you design your BTS application around the functionality provided, your Containers would be recoverable and also be available to multiple tasks (termed activities in the BTS context), as long as those tasks are part of the BTS process.  See https://www.ibm.com/docs/en/cics-ts/5.6?topic=applications-developing-bts-api 

One difference between BTS-based Containers and Channel Containers is that only Channel-based Containers support the BYTEOFFSET option on the GET CONTAINER command and APPEND option on the PUT CONTAINER command.

In terms of dealing with variable-length records, rather than packing lots of records into a single Container, consider using a separate Container for each record layout/structure.  There's quite a bit of discussion around planning your Container usage in the Channels & Containers Redbook, SG24-7277, at https://www.redbooks.ibm.com/abstracts/sg247227.html?Open

I'm not sure what your concern is when it comes to your issue with a half-word signed native binary field.  The length (size) of a Container is returned as a full-word.

------------------------------
Leigh Compton
Consulting IT Specialist - CICS and Enterprise Integration
IBM
TX
------------------------------

Original Message:
Sent: Tue December 14, 2021 05:03 PM
From: Frank Swarbrick
Subject: CICS channel containers usage

I posted this to cics-l but haven't gotten any response, so I figure I should post it here as well.

I'm pondering using channel containers in places where we currently use temporary storage queues. There are advantages to containers, but they are also lacking some features. I'm wondering about other peoples' thoughts on these matters.

Advantages of channel containers over temporary storge queues:
- Not limited to 32k per record.
- Not limited to 32k records.
- Not shared between separate tasks (but can be used to pass data to a new task).
- Automatically cleaned up at task termination (unless explicitly passed to a new task).

Disadvantages of channel containers over temporary storge queues:
- Byte based instead of record based.
- Cannot update part of a container without replacing all of the data within the container.
- Simulation of fixed length records in containers is slightly more complex than dealing with an actual record- based storage.
- Simulation of variable-length records in containers, while possible, is not at all straightforward.

I think most of the disadvantages are a result of designing channel containers as replacements for COMMAREA and not really designing them as a replacement for TS queues. Would I be going in the wrong direction by using containers as a replacement for TS queues. The main issue I'm running in to currently is we have "client" programs that link to "service" programs and currently use TS queues to pass back some of the results. Specifically, results that are "record based". But we're concerned about hitting the limit of the number of records in the queue. We already ran in to an issue when we hit more than 10,000 records, because the COBOL data field that held the "item number" was defined as PIC S9(4) COMP, which (as per standard COBOL behavior) rolled over from 9999 to 0 when we added 1 to it. This was fixed by changing it to a COMP-5 ("native binary"), but we're still limited by the fact that a half-word signed native binary field has a maximum value of 32767.

I can think of several enhancements that CICS should support, but who knows when or if they would be implemented.

------------------------------
Frank Swarbrick
------------------------------

Hi Leigh.  Thanks for replying.

I am only, at this point, interested in "single task" channels; passing data between different programs invoked in the same task.  I've looked at BTS before (not recently), but since I'm only interested in single task channels I don't see a need to go that direction.   No need for them to be recoverable.

What I am really interested in is "record based" containers instead of just "byte based" containers.  I am currently using APPEND and BYTEOFFSET to emulate fixed-length records, but having a true record based container would be preferable.  As for variable length records, I actually can't think offhand of an actual use case needing them, but I can only imagine I might come up with one where it would be useful.  I understand your point about separate containers for each unique structure, but not all structures are fixed length.

I will take a look at that Redbook.

The issue with the half-word signed native binary field was referring to our existing use of TS queues and having the ITEM count field defined as COBOL PIC S9999 COMP (vs. PIC S9999 COMP-5) .  Not something that needs to be addressed by CICS.  Just what triggered by thoughts about replacing (some) TS queue usage with containers.

Thanks!

------------------------------
Frank Swarbrick
------------------------------

Original Message:
Sent: Tue December 14, 2021 06:24 PM
From: Leigh Compton
Subject: CICS channel containers usage

Hi Frank.  I saw your message to CICS-L, but was waiting to see if anyone else would respond.

You could indeed use Channel-based Containers within a single task (regardless of how many programs are involved).  Recognize that a given Channel belongs to one task.  As you mentioned, the Channel can be passed to another task with a START command, but there's no mechanism to return that Channel to the original task.  Note also that Channels and the Containers within them are not recoverable.  That's another difference between Containers and TS Queues.  Perhaps the Asynchronous API would be a good fit for a multi-task application using Containers.

Another option would be to use BTS-based Containers.  These are designed to have longer lifetimes and to exist longer than a single task.  If you design your BTS application around the functionality provided, your Containers would be recoverable and also be available to multiple tasks (termed activities in the BTS context), as long as those tasks are part of the BTS process.  See https://www.ibm.com/docs/en/cics-ts/5.6?topic=applications-developing-bts-api 

One difference between BTS-based Containers and Channel Containers is that only Channel-based Containers support the BYTEOFFSET option on the GET CONTAINER command and APPEND option on the PUT CONTAINER command.

In terms of dealing with variable-length records, rather than packing lots of records into a single Container, consider using a separate Container for each record layout/structure.  There's quite a bit of discussion around planning your Container usage in the Channels & Containers Redbook, SG24-7277, at https://www.redbooks.ibm.com/abstracts/sg247227.html?Open

I'm not sure what your concern is when it comes to your issue with a half-word signed native binary field.  The length (size) of a Container is returned as a full-word.

------------------------------
Leigh Compton
Consulting IT Specialist - CICS and Enterprise Integration
IBM
TX

Original Message:
Sent: Tue December 14, 2021 05:03 PM
From: Frank Swarbrick
Subject: CICS channel containers usage

I posted this to cics-l but haven't gotten any response, so I figure I should post it here as well.

I'm pondering using channel containers in places where we currently use temporary storage queues. There are advantages to containers, but they are also lacking some features. I'm wondering about other peoples' thoughts on these matters.

Advantages of channel containers over temporary storge queues:
- Not limited to 32k per record.
- Not limited to 32k records.
- Not shared between separate tasks (but can be used to pass data to a new task).
- Automatically cleaned up at task termination (unless explicitly passed to a new task).

Disadvantages of channel containers over temporary storge queues:
- Byte based instead of record based.
- Cannot update part of a container without replacing all of the data within the container.
- Simulation of fixed length records in containers is slightly more complex than dealing with an actual record- based storage.
- Simulation of variable-length records in containers, while possible, is not at all straightforward.

I think most of the disadvantages are a result of designing channel containers as replacements for COMMAREA and not really designing them as a replacement for TS queues. Would I be going in the wrong direction by using containers as a replacement for TS queues. The main issue I'm running in to currently is we have "client" programs that link to "service" programs and currently use TS queues to pass back some of the results. Specifically, results that are "record based". But we're concerned about hitting the limit of the number of records in the queue. We already ran in to an issue when we hit more than 10,000 records, because the COBOL data field that held the "item number" was defined as PIC S9(4) COMP, which (as per standard COBOL behavior) rolled over from 9999 to 0 when we added 1 to it. This was fixed by changing it to a COMP-5 ("native binary"), but we're still limited by the fact that a half-word signed native binary field has a maximum value of 32767.

I can think of several enhancements that CICS should support, but who knows when or if they would be implemented.

------------------------------
Frank Swarbrick
------------------------------

(Replicating what I sent to cics-l)

Hi Frank,
Channels were designed primarily to enable more than 32K of data to be passed between programs in the same general circumstances as COMMAREAs used to be the only answer (well, COMMAREAs and START/RETRIEVE data to be more accurate).

I dislike interfaces which deal in massive amounts of 'parameter data' unconditionally and in one go. You're either going to be asking for lots of data that isn't actually really needed ("I really only want the 742nd item here"), or if it is needed, there will be a loop involved to get round it all.

So patterns which put reasonable bounds on the amount of data at the expense of asking the caller to follow a paginated style ("give me up to 1000 things, let me know if there's more and I'll come back and ask for the next 1000" - I just picked 1000 for the example) are what I'd favour and I don't think they add any unwarranted complexity from a global perspective. They stop problems of trying to cope with unbounded sets of things as volumes inevitably grow over time.

Yes, containers are managed above the bar between the time they are put and when they are requested by the app so there's generally plenty space, but at some point you'll end up with 'too much'.

People will say that multiple repeated calls will cost more CPU... perhaps a bit, but (being consistent with my example) how common is the more than a 1000 case? Is the 33,000 case overwhelmingly common? What does the caller do with 33,000 things? An extra call every 1000... is that significant on the true scale of things?

So not so much of an answer for TS queues vs channels, more a question of interface design.

------------------------------
Ian Mitchell
Distinguished Engineer
IBM
-
------------------------------

Original Message:
Sent: Tue December 14, 2021 05:03 PM
From: Frank Swarbrick
Subject: CICS channel containers usage

I posted this to cics-l but haven't gotten any response, so I figure I should post it here as well.

I'm pondering using channel containers in places where we currently use temporary storage queues. There are advantages to containers, but they are also lacking some features. I'm wondering about other peoples' thoughts on these matters.

Advantages of channel containers over temporary storge queues:
- Not limited to 32k per record.
- Not limited to 32k records.
- Not shared between separate tasks (but can be used to pass data to a new task).
- Automatically cleaned up at task termination (unless explicitly passed to a new task).

Disadvantages of channel containers over temporary storge queues:
- Byte based instead of record based.
- Cannot update part of a container without replacing all of the data within the container.
- Simulation of fixed length records in containers is slightly more complex than dealing with an actual record- based storage.
- Simulation of variable-length records in containers, while possible, is not at all straightforward.

I think most of the disadvantages are a result of designing channel containers as replacements for COMMAREA and not really designing them as a replacement for TS queues. Would I be going in the wrong direction by using containers as a replacement for TS queues. The main issue I'm running in to currently is we have "client" programs that link to "service" programs and currently use TS queues to pass back some of the results. Specifically, results that are "record based". But we're concerned about hitting the limit of the number of records in the queue. We already ran in to an issue when we hit more than 10,000 records, because the COBOL data field that held the "item number" was defined as PIC S9(4) COMP, which (as per standard COBOL behavior) rolled over from 9999 to 0 when we added 1 to it. This was fixed by changing it to a COMP-5 ("native binary"), but we're still limited by the fact that a half-word signed native binary field has a maximum value of 32767.

I can think of several enhancements that CICS should support, but who knows when or if they would be implemented.

------------------------------
Frank Swarbrick
------------------------------

Thanks Ian.  I've replied back on cics-l.

------------------------------
Frank Swarbrick
------------------------------

Original Message:
Sent: Wed December 15, 2021 05:46 AM
From: Ian Mitchell
Subject: CICS channel containers usage

(Replicating what I sent to cics-l)

Hi Frank,
Channels were designed primarily to enable more than 32K of data to be passed between programs in the same general circumstances as COMMAREAs used to be the only answer (well, COMMAREAs and START/RETRIEVE data to be more accurate).

I dislike interfaces which deal in massive amounts of 'parameter data' unconditionally and in one go. You're either going to be asking for lots of data that isn't actually really needed ("I really only want the 742nd item here"), or if it is needed, there will be a loop involved to get round it all.

So patterns which put reasonable bounds on the amount of data at the expense of asking the caller to follow a paginated style ("give me up to 1000 things, let me know if there's more and I'll come back and ask for the next 1000" - I just picked 1000 for the example) are what I'd favour and I don't think they add any unwarranted complexity from a global perspective. They stop problems of trying to cope with unbounded sets of things as volumes inevitably grow over time.

Yes, containers are managed above the bar between the time they are put and when they are requested by the app so there's generally plenty space, but at some point you'll end up with 'too much'.

People will say that multiple repeated calls will cost more CPU... perhaps a bit, but (being consistent with my example) how common is the more than a 1000 case? Is the 33,000 case overwhelmingly common? What does the caller do with 33,000 things? An extra call every 1000... is that significant on the true scale of things?

So not so much of an answer for TS queues vs channels, more a question of interface design.

------------------------------
Ian Mitchell
Distinguished Engineer
IBM
-

Original Message:
Sent: Tue December 14, 2021 05:03 PM
From: Frank Swarbrick
Subject: CICS channel containers usage

I posted this to cics-l but haven't gotten any response, so I figure I should post it here as well.

I'm pondering using channel containers in places where we currently use temporary storage queues. There are advantages to containers, but they are also lacking some features. I'm wondering about other peoples' thoughts on these matters.

Advantages of channel containers over temporary storge queues:
- Not limited to 32k per record.
- Not limited to 32k records.
- Not shared between separate tasks (but can be used to pass data to a new task).
- Automatically cleaned up at task termination (unless explicitly passed to a new task).

Disadvantages of channel containers over temporary storge queues:
- Byte based instead of record based.
- Cannot update part of a container without replacing all of the data within the container.
- Simulation of fixed length records in containers is slightly more complex than dealing with an actual record- based storage.
- Simulation of variable-length records in containers, while possible, is not at all straightforward.

I think most of the disadvantages are a result of designing channel containers as replacements for COMMAREA and not really designing them as a replacement for TS queues. Would I be going in the wrong direction by using containers as a replacement for TS queues. The main issue I'm running in to currently is we have "client" programs that link to "service" programs and currently use TS queues to pass back some of the results. Specifically, results that are "record based". But we're concerned about hitting the limit of the number of records in the queue. We already ran in to an issue when we hit more than 10,000 records, because the COBOL data field that held the "item number" was defined as PIC S9(4) COMP, which (as per standard COBOL behavior) rolled over from 9999 to 0 when we added 1 to it. This was fixed by changing it to a COMP-5 ("native binary"), but we're still limited by the fact that a half-word signed native binary field has a maximum value of 32767.

I can think of several enhancements that CICS should support, but who knows when or if they would be implemented.

------------------------------
Frank Swarbrick
------------------------------