Upgraded to v6.1 and the call to this program no longer works. The program is used to print a bar code on IPDS printer from Cobol. If it’s a matter a parameter list change, I wanted to know how to call it.

error msg is

Pointer not set for location referenced.
Function check. MCH3601 unmonitored by QWPPSUBR at statement *N,
instruction X’00DF’.

…QWPPSUBR…

That makes me think that someone created a S/36 “subroutine” function at some point in the past. It could have been IBM-supplied or it could have been created in-house or by a consultant. I’d think first that a program named PRTBAR is calling some S/36 “subroutine” incorrectly (for the new environment).

Do you still have the S/36 environment installed after the upgrade? Is it in known good working condition? Have appropriate PTFs been applied?

I recall something about S/36 subroutines changing recently, and it seems like it was for i 6.1. But I never used the S/36 environment for anything of significance, so I don’t have a good memory about it. I created a replacement of a S/36 subroutine for someone maybe a year ago to replace an original one that no longer worked after an upgrade. That’s as much as I recall about possible upgrade problems at the moment — and my basic thought might not be valid.

Tom

The application software is not running in a system 36 environment. PRTBAR had been copied from the QSSP library. The original PRTBAR program would not convert for v6.1 so. I recopied the pgm from the current QSSP library.. Is there a different advanced printing function program that I can call to print this barcode from Cobol. I’m not a Cobol programmer.

PRTBAR had been copied from the QSSP library. The original PRTBAR program would not convert for v6.1 so. I recopied the pgm from the current QSSP library.

In that case, you can forget PRTBAR. If it won’t convert, it can’t be called successfully. And if it was originally a QSSP program, it possibly wouldn’t work (without recompile and possible code changes) outside of a S/36 environment.

Is there a different advanced printing function program that I can call to print this barcode from Cobol.

Generally, printing bar codes should be irrelevant to the language being used. It should be part of the DDS for the printer file.

Is there something unusual about the design of the printed output?

And why is “COBOL” important? Is it simply because the existing procedure that calls PRTBAR is a COBOL program?

Tom

In the original application, PRTBAR (licensed IBM pgm) existed in the application library. I can only assume that it was copied from QSSP. This version would not convert. After the upgrade, I copied the new licensed IBM pgm to the application libray. It tries to run but gets the pointer exception error. I’ve tried to create a program dump, but only get the dump of the calling program.

The application is written in Cobol (1996). I am not a Cobol programmer. I don’t understand the printfile associated with the program. It doesn’t have any fields. Maybe it’s internal. I can make adjustments to call my RPG program for the barcode, but that’s a separate printfile with just the barcode. If I could get the call to prtbar to work, I wouldn’t have to struggle to rewrite a program that I don’t understand.

Thanks for you help!

I’m changing the cobol program to have an external print file and omit the call to prtbar.

I don’t understand the printfile associated with the program. It doesn’t have any fields.

It sounds like a QSYSPRT or QPRINT printer file or one created as a duplicate of those. That would make sense if the bar codes are created by the program inserting instructions into the records (or by calling a program to do that, e.g., PRTBAR).

That kind of programming made sense on a S/36 when externally-described printer files couldn’t be used. On an AS/400, it makes as much sense as generating screens by program instructions instead of using a formatted display file or operating on database files created as CRTPF RCDLEN(100).

But for the moment, that’s what you have.

Can you show the original CALL to PRTBAR and describe (1) the parameter values and (2) the result of the CALL? That is, exactly what did PRTBAR accomplish? Did it actually do printing? Or did it return a value that COBOL put into an output record? If you don’t understand the COBOL that called it, that might not be possible; but even a general description might allow the creation of a replacement.

Tom

PRBAR is called with four parameters. It’s called multiple times to pass different key pieces of information like height, position, data, etc. The bar code prints on the open document of the callling program.
Parameters:
1. printfile name 10a
2 key word such as “position” 10a
3 information pertaining to keyword 10a or 80a I forget
4. 2 position code. blanks 2a

I can call it from a command line with the 4 parameters and get the same error msg.

I resolved the issue. The program did have an internally described printfile like qsysprt. I referred to the cobol manuals and changed the code to use an externally defined printfile. Once you told me it was s/36, I understood and I decided to get away from that type of programming.
Thanks again for your response.

I referred to the cobol manuals and changed the code to use an externally defined printfile.

For everything in the foreseeable future, that’s by far the best direction. Post back if you have problems.

Tom