Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Building a string dynamically 1
- Thread starter grill
- Start date
Hello
I may be wrong, but I think that you have to store a space for the sting that should be the size of the largest item of your table.
Then you can use " function lenght(your table item) " if you need to play with that lenght.
slade will certainly correct me.
I may be wrong, but I think that you have to store a space for the sting that should be the size of the largest item of your table.
Then you can use " function lenght(your table item) " if you need to play with that lenght.
slade will certainly correct me.
- Thread starter
- #3
Hi there.
My mind did set out in that direction, but the problem is that I may read multiple records, and I don't know how many. Perhaps I should start out by writing some routine that finds out how many records to read and then calculates the size.
I guess I have some thinking to do.
Thanks anyway.
My mind did set out in that direction, but the problem is that I may read multiple records, and I don't know how many. Perhaps I should start out by writing some routine that finds out how many records to read and then calculates the size.
I guess I have some thinking to do.
Thanks anyway.
-
1
- #4
Hi Grill,
You didn't mention what you plan to do with the string after you've built it.
The reason this is important is that there are size limitations for various operating system and compiler entities. For this same reason you should also let us know what compiler and runtime environment you are using.
An example: If you plan to write the string to a file, the size of the string is limited to 32K, the blksize limit.
Another: If you plan to build the strings into an internal table there are other size limits involved. Admittedly, these limits are much more generous.
If you have an idea of what a comfortable outside limit of your string might be, that would be helpful in designing a strategy.
There may be ways to request variable data, but that is highly environment/language dependent.
All this being said, I suspect that defining the largest variable permissible or reasonable, then using STRING with the POINTER option, or using reference modification, will give you what you want.
Regards, Jack.
P.S. Claude, did I do something to offend you?
You didn't mention what you plan to do with the string after you've built it.
The reason this is important is that there are size limitations for various operating system and compiler entities. For this same reason you should also let us know what compiler and runtime environment you are using.
An example: If you plan to write the string to a file, the size of the string is limited to 32K, the blksize limit.
Another: If you plan to build the strings into an internal table there are other size limits involved. Admittedly, these limits are much more generous.
If you have an idea of what a comfortable outside limit of your string might be, that would be helpful in designing a strategy.
There may be ways to request variable data, but that is highly environment/language dependent.
All this being said, I suspect that defining the largest variable permissible or reasonable, then using STRING with the POINTER option, or using reference modification, will give you what you want.
Regards, Jack.
P.S. Claude, did I do something to offend you?
Grill,
In addition to Jack's request for operating system and compiler information, it would also be good to know how COBOL-like the result must be. For example, some systems permit memory management from COBOL, but that requires a CALL to a system function. Some folks are not comfortable with doing something like this, and others may not be permitted to do so by their program development rules.
There are ways of doing what you want, so please help us help you. s-)
Tom Morrison
In addition to Jack's request for operating system and compiler information, it would also be good to know how COBOL-like the result must be. For example, some systems permit memory management from COBOL, but that requires a CALL to a system function. Some folks are not comfortable with doing something like this, and others may not be permitted to do so by their program development rules.
There are ways of doing what you want, so please help us help you. s-)
Tom Morrison
Not at all Slade. I was looking forward to reading your answer. It is the opposite. I like your posts and find them very helpful. I admire the fact that you take time to read and answer the questions. In french , you would say "chapeau". That could be translated as "Hat Off". but I am not sure.
- Thread starter
- #7
As long as it doesn't mean "pants off"!!!
Now we get technical and my skills get worse. I've just been working with this for 1½ weeks.
I provide you with some words and hope you can make up something of it: MVS, mainframe, OS/390, db2.
The string internally resembles an XML document, but when it's built no more work has to be done with it. It's only to be sent to a Unix system via something called MQ Series.
From what I've been told size shouldn't make any problems as long as it's UNDER 4 MB.
I appreciate your interest in this matter, Lars Grill.
Now we get technical and my skills get worse. I've just been working with this for 1½ weeks.
I provide you with some words and hope you can make up something of it: MVS, mainframe, OS/390, db2.
The string internally resembles an XML document, but when it's built no more work has to be done with it. It's only to be sent to a Unix system via something called MQ Series.
From what I've been told size shouldn't make any problems as long as it's UNDER 4 MB.
I appreciate your interest in this matter, Lars Grill.
Claude,
The POINTER option on the STRING verb indicates where to begin placement within the receiving field and, after execution of the statement, where the 'next character' is in the receiving field.
It is useful as 'memory' when you must use more than one STRING statement to assemble the contents of the receiving field, including iterations of a loop:
If POINTER is not specified, then the STRING statement assumes a value of 1.
POINTER will be useful when assembling data from several database rows.
Tom Morrison
The POINTER option on the STRING verb indicates where to begin placement within the receiving field and, after execution of the statement, where the 'next character' is in the receiving field.
It is useful as 'memory' when you must use more than one STRING statement to assemble the contents of the receiving field, including iterations of a loop:
Code:
MOVE 1 TO THE-POINTER.
PERFORM VARYING I FROM 1 BY 1 UNTIL I > 4
STRING SENDING-FIELD (I) DELIMITED BY " "
INTO RECEIVE-FIELD POINTER THE-POINTER
ON OVERFLOW
<handle error>
END-STRING
END-PERFORMIf POINTER is not specified, then the STRING statement assumes a value of 1.
POINTER will be useful when assembling data from several database rows.
Tom Morrison
Claude 1st,
When you use pointer w/string, the pointer field always points to the position after the last field that was "strung". So, if you execute another string/pointer stmt to the same receiving field, or use it in a perform as Tom did, it puts the data in the receiving field beginning at that point in the field. Slick, huh?
Glad you weren't offended, I asked because "sait on jamais". I hope I spelled that right; I might have said "the chicken sings at midnight", for all I know.
Now Lars,
If you're talking about data in the MB range using MQ Series, I assume you are running under CICS and the data has to be written to a queue. The usual limit on writing data to external disk media is 32K, so I'm assuming you'll have to write the data in chunks of that size or less.
You'll have to get more specific for us to help. For example how does the UNIX app expect to see the data (i.e., where, organized how, what size chunks, etc).
Do your specs explain all this? If so, show us.
Thanx, Jack.
When you use pointer w/string, the pointer field always points to the position after the last field that was "strung". So, if you execute another string/pointer stmt to the same receiving field, or use it in a perform as Tom did, it puts the data in the receiving field beginning at that point in the field. Slick, huh?
Glad you weren't offended, I asked because "sait on jamais". I hope I spelled that right; I might have said "the chicken sings at midnight", for all I know.
Now Lars,
If you're talking about data in the MB range using MQ Series, I assume you are running under CICS and the data has to be written to a queue. The usual limit on writing data to external disk media is 32K, so I'm assuming you'll have to write the data in chunks of that size or less.
You'll have to get more specific for us to help. For example how does the UNIX app expect to see the data (i.e., where, organized how, what size chunks, etc).
Do your specs explain all this? If so, show us.
Thanx, Jack.
- Thread starter
- #12
Hello,
I'm running in Batch, not under CICS.
The string is handed over to the MQ where it is regarded as an MQ record in itself, not a flat file.
Then the MQ sends it to a receiving MQ on the Unix system.
I've heard that as a rule of thumb 1 MB is the upper limit when it comes to MQ.
My specs don't say anything about how the receiving party will approach the string other than it is mapped to XML.
Perhaps one solution would be to allocate a large storage area for the string, eg. 2 MB, and then only send the portion which is actually being used.
That would also solve the problem about building the string dynamically where the total length is unknown. Of course I have to break down the string if it becomes too large. But breaking down a string isn't a problem.
Now I only have to find out the maximum size limit for a PIC X in Cobol2.
Best regards, Lars Grill
I'm running in Batch, not under CICS.
The string is handed over to the MQ where it is regarded as an MQ record in itself, not a flat file.
Then the MQ sends it to a receiving MQ on the Unix system.
I've heard that as a rule of thumb 1 MB is the upper limit when it comes to MQ.
My specs don't say anything about how the receiving party will approach the string other than it is mapped to XML.
Perhaps one solution would be to allocate a large storage area for the string, eg. 2 MB, and then only send the portion which is actually being used.
That would also solve the problem about building the string dynamically where the total length is unknown. Of course I have to break down the string if it becomes too large. But breaking down a string isn't a problem.
Now I only have to find out the maximum size limit for a PIC X in Cobol2.
Best regards, Lars Grill
- Thread starter
- #13
- Thread starter
- #15
- Thread starter
- #16
Jimanderin
Programmer
Hello
From an MQSeries point of view:
I believe you will be using the MQPUT API to put the message to an MQSeries queue. The syntax for this is:
CALL 'MQPUT' USING HCONN, HOBJ, MSGDESC, PUTMSGOPTS,
BUFFERLENGTH, BUFFER, COMPCODE, REASON.
The length of your string is specified in the BUFFERLENGTH parameter. There are many factors influencing the max length of the string you can use.
For example if the queue you are putting to is a local queue or resolves to one then the max length of the message you can use cannot exceed the maxmsglength parameter on the queue OR the maxmsglength parameter on the queue manager (non-OS/390 queue managers).
The default length is 4M for a queue.
There are more restrictions on the max message length, too verbose to mention here, but if you are interested they are explained in:
So a few more things to consider.
Regards
Jim
From an MQSeries point of view:
I believe you will be using the MQPUT API to put the message to an MQSeries queue. The syntax for this is:
CALL 'MQPUT' USING HCONN, HOBJ, MSGDESC, PUTMSGOPTS,
BUFFERLENGTH, BUFFER, COMPCODE, REASON.
The length of your string is specified in the BUFFERLENGTH parameter. There are many factors influencing the max length of the string you can use.
For example if the queue you are putting to is a local queue or resolves to one then the max length of the message you can use cannot exceed the maxmsglength parameter on the queue OR the maxmsglength parameter on the queue manager (non-OS/390 queue managers).
The default length is 4M for a queue.
There are more restrictions on the max message length, too verbose to mention here, but if you are interested they are explained in:
So a few more things to consider.
Regards
Jim
- Status
Similar threads
- Locked
- Question