• Variable length message fields

    From Jonathan Ball@21:1/5 to All on Tue Oct 30 23:00:33 2018
    We have a COBOL program that writes to a data queue. In testing an
    expansion of the database, we get a condition in which the COBOL program
    writes too many entries to the data queue, resulting in escape message
    CPF950A to the job - "Storage limit exceeded for data queue XXXXXXXX in
    *LIBL" - and inquiry message LNR7200 to the operator message queue:
    "Message 'CPF950A' in program object 'XXXXXXXX' in library 'YYYYYYYY' (C
    D F G).".

    I want to add a system reply list entry, but I want it to be specific to
    the program that threw the error. The problem is that the message field
    values for LNR7200 are all specified as *VARY for length. The CMPDTA
    parameter of the ADDRPYLE command requires a fixed position in the
    message data. The problem is the second parameter, which specifies the statement statement number in the COBOL program that received the error.
    It is specified as *CHAR *VARY. That means I can't specify a fixed
    position for the start position of the comparison data parameter
    (CMPDTA) for the reply list entry, because the statement number in the
    program may (will) vary.

    Any suggestions?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Bailey@21:1/5 to Jonathan Ball on Wed Oct 31 06:13:45 2018
    My cobol is poor and non existent on IBM i. I dont even remember how you would call the API to add the queue entry. Cant the cobol program catch this error and handle it or does it not return until the message is replied?

    If not you would have to be pro-active and use QMHQRDQD to return the state of the queue, comparing the max number to the current number (allocated?) before deciding whether to write a message or something else. Use queue number 2?

    If there are more than 1 writers then possibly leave a margin in case of new messages inserted between the test and the send.

    Another dodgy suggestion: Maybe you could just change the state of parm 2 to fixed. I'm guessing it inserte the source code line number into it? Just make it big enough. That would need re-doing on every OS upgrade/new machine implementation, so maybe a
    CL command to make the change on every invocation of the program.

    HTH
    Jonathan


    On Wednesday, 31 October 2018 06:00:36 UTC, Jonathan Ball wrote:
    We have a COBOL program that writes to a data queue. In testing an expansion of the database, we get a condition in which the COBOL program writes too many entries to the data queue, resulting in escape message CPF950A to the job - "Storage limit exceeded for data queue XXXXXXXX in *LIBL" - and inquiry message LNR7200 to the operator message queue:
    "Message 'CPF950A' in program object 'XXXXXXXX' in library 'YYYYYYYY' (C
    D F G).".

    I want to add a system reply list entry, but I want it to be specific to
    the program that threw the error. The problem is that the message field values for LNR7200 are all specified as *VARY for length. The CMPDTA parameter of the ADDRPYLE command requires a fixed position in the
    message data. The problem is the second parameter, which specifies the statement statement number in the COBOL program that received the error.
    It is specified as *CHAR *VARY. That means I can't specify a fixed position for the start position of the comparison data parameter
    (CMPDTA) for the reply list entry, because the statement number in the program may (will) vary.

    Any suggestions?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jon Paris@21:1/5 to Jon Paris on Wed Oct 31 08:14:11 2018
    On Wednesday, October 31, 2018 at 9:54:53 AM UTC-5, Jon Paris wrote:
    <snip>
    Simple answer since this is program specific is don't use the replay list.

    COBOL has the ability to programatically catch and respond to such messages. You don't say if you are using COBOL/400 or ILE COBOL.

    In ILE COBOL you will find the basic information in the section of the manual "Using Error Handling Bindable Application Programming Interfaces (APIs)" - for me that is on page 3-186 of the Programmers Guide.

    Basically you register an error handler using QlnSetCobolErrorHandler and it will get control when an error occurs. Your routine decides how to respond to the message or chooses not to handle it depending on the message. If you handle it, by telling
    it to use "G" or "D" or whatever - if you don't handle it then the normal green screen of death will appear.

    There is an equivalent for COBOL/400 but I can't remember the names as it is too many years since I used that compiler.

    Just a suggestion - but you'll get far more help fo COBOL on the COBOL list on midrange.com. There's really very little activity of any kind on this list and next to zero COBOL.

    You can find a sample of the COBOL/400 version here https://archive.midrange.com/cobol400-l/201002/msg00001.html

    The ILE COBOL works almost exactly the same way.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jon Paris@21:1/5 to Jonathan Ball on Wed Oct 31 07:54:50 2018
    On Wednesday, October 31, 2018 at 1:00:36 AM UTC-5, Jonathan Ball wrote:
    We have a COBOL program that writes to a data queue. In testing an expansion of the database, we get a condition in which the COBOL program writes too many entries to the data queue, resulting in escape message CPF950A to the job - "Storage limit exceeded for data queue XXXXXXXX in *LIBL" - and inquiry message LNR7200 to the operator message queue:
    "Message 'CPF950A' in program object 'XXXXXXXX' in library 'YYYYYYYY' (C
    D F G).".

    I want to add a system reply list entry, but I want it to be specific to
    the program that threw the error. The problem is that the message field values for LNR7200 are all specified as *VARY for length. The CMPDTA parameter of the ADDRPYLE command requires a fixed position in the
    message data. The problem is the second parameter, which specifies the statement statement number in the COBOL program that received the error.
    It is specified as *CHAR *VARY. That means I can't specify a fixed position for the start position of the comparison data parameter
    (CMPDTA) for the reply list entry, because the statement number in the program may (will) vary.

    Any suggestions?

    Simple answer since this is program specific is don't use the replay list.

    COBOL has the ability to programatically catch and respond to such messages. You don't say if you are using COBOL/400 or ILE COBOL.

    In ILE COBOL you will find the basic information in the section of the manual "Using Error Handling Bindable Application Programming Interfaces (APIs)" - for me that is on page 3-186 of the Programmers Guide.

    Basically you register an error handler using QlnSetCobolErrorHandler and it will get control when an error occurs. Your routine decides how to respond to the message or chooses not to handle it depending on the message. If you handle it, by telling it
    to use "G" or "D" or whatever - if you don't handle it then the normal green screen of death will appear.

    There is an equivalent for COBOL/400 but I can't remember the names as it is too many years since I used that compiler.

    Just a suggestion - but you'll get far more help fo COBOL on the COBOL list on midrange.com. There's really very little activity of any kind on this list and next to zero COBOL.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Ball@21:1/5 to Jon Paris on Wed Oct 31 18:34:54 2018
    On 10/31/2018 7:54 AM, Jon Paris wrote:
    On Wednesday, October 31, 2018 at 1:00:36 AM UTC-5, Jonathan Ball wrote:
    We have a COBOL program that writes to a data queue. In testing an
    expansion of the database, we get a condition in which the COBOL program
    writes too many entries to the data queue, resulting in escape message
    CPF950A to the job - "Storage limit exceeded for data queue XXXXXXXX in
    *LIBL" - and inquiry message LNR7200 to the operator message queue:
    "Message 'CPF950A' in program object 'XXXXXXXX' in library 'YYYYYYYY' (C
    D F G).".

    I want to add a system reply list entry, but I want it to be specific to
    the program that threw the error. The problem is that the message field
    values for LNR7200 are all specified as *VARY for length. The CMPDTA
    parameter of the ADDRPYLE command requires a fixed position in the
    message data. The problem is the second parameter, which specifies the
    statement statement number in the COBOL program that received the error.
    It is specified as *CHAR *VARY. That means I can't specify a fixed
    position for the start position of the comparison data parameter
    (CMPDTA) for the reply list entry, because the statement number in the
    program may (will) vary.

    Any suggestions?

    Simple answer since this is program specific is don't use the replay list.

    COBOL has the ability to programatically catch and respond to such messages. You don't say if you are using COBOL/400 or ILE COBOL.

    It's ILE.

    Thanks for the rest of your reply. I stumbled upon that myself earlier
    today. The error handler registration looks a little daunting, but I
    think I can handle it; I may come back with more questions. Writing the
    error handling program itself looks pretty easy; it's the registration
    that looks tricky.

    The reply list entry definitely is not going to work. Here is what I
    was thinking with respect to calling QSNDDTAQ in the ILE COBOL program:

    call "QSNDDTAQ" using
    Dtaq-name
    Dtaq-lib
    Dtaq-fld-len
    Data-queue-entry
    on exception
    [do some stuff]
    not on exception
    [do some other stuff]
    end-call

    When the data queue is full, the CPF950A error is returned from QSNDDTAQ
    to my program, which then generates the LNR7200 inquiry message. For
    some reason, the ON EXCEPTION code is never invoked. What I had hoped
    to do was to have the reply list entry issue a 'C' to LNR7200; then the
    ON EXCEPTION code would delay the job for a short while until the multi-threaded jobs could read enough entries off the data queue to
    allow the driver program to resume writing entries to the data queue.
    It doesn't work.

    Thanks for the reply. Thanks also to Jonathan Bailey for his reply.
    Crikey - he's a Jonathan, I'm a Jonathan, and I presume your 'Jon' is
    short for Jonathan. I guess every IBM i developer with COBOL expertise
    must be named Jonathan, eh? :-)


    In ILE COBOL you will find the basic information in the section of the manual "Using Error Handling Bindable Application Programming Interfaces (APIs)" - for me that is on page 3-186 of the Programmers Guide.

    Basically you register an error handler using QlnSetCobolErrorHandler and it will get control when an error occurs. Your routine decides how to respond to the message or chooses not to handle it depending on the message. If you handle it, by telling
    it to use "G" or "D" or whatever - if you don't handle it then the normal green screen of death will appear.

    There is an equivalent for COBOL/400 but I can't remember the names as it is too many years since I used that compiler.

    Just a suggestion - but you'll get far more help fo COBOL on the COBOL list on midrange.com. There's really very little activity of any kind on this list and next to zero COBOL.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jon Paris@21:1/5 to Jonathan Ball on Thu Nov 1 07:15:03 2018
    On Wednesday, October 31, 2018 at 9:34:56 PM UTC-4, Jonathan Ball wrote:

    It's ILE.

    Thanks for the rest of your reply. I stumbled upon that myself earlier today. The error handler registration looks a little daunting, but I
    think I can handle it; I may come back with more questions. Writing the error handling program itself looks pretty easy; it's the registration
    that looks tricky.

    It is really very easy - if it isn't then my design failed! The only thing that may appear complex is the notion of retrieving the current handler and re-registering it on exit. From a compiler architecture point of view we had to do that in order to
    allow for each program to have its own handler. But if you know this is the only program that uses the capability then you really don't have to worry about it.

    The reply list entry definitely is not going to work. Here is what I
    was thinking with respect to calling QSNDDTAQ in the ILE COBOL program:

    call "QSNDDTAQ" using
    Dtaq-name
    Dtaq-lib
    Dtaq-fld-len
    Data-queue-entry
    on exception
    [do some stuff]
    not on exception
    [do some other stuff]
    end-call

    When the data queue is full, the CPF950A error is returned from QSNDDTAQ
    to my program, which then generates the LNR7200 inquiry message. For
    some reason, the ON EXCEPTION code is never invoked. What I had hoped
    to do was to have the reply list entry issue a 'C' to LNR7200; then the
    ON EXCEPTION code would delay the job for a short while until the multi-threaded jobs could read enough entries off the data queue to
    allow the driver program to resume writing entries to the data queue.
    It doesn't work.

    Basically COBOL's ON-EXCEPTION is one of those "seemed like a good idea at the time" kind of features and it never really works in all cases. I've done COBOL on abut 6 different platforms and nobody uses it.

    If I recall directly it will only trigger if there is an error on the call (i.e. program not found) not if there is an exception _in_ the called program. I could try to explain this but it would probably confuse both of us <grin>.

    Thanks for the reply. Thanks also to Jonathan Bailey for his reply.
    Crikey - he's a Jonathan, I'm a Jonathan, and I presume your 'Jon' is
    short for Jonathan. I guess every IBM i developer with COBOL expertise
    must be named Jonathan, eh? :-)

    Actually no - I was named "John" which - for reasons I won't bore you with - became "Jon" during a teenage rebellion period!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)