Re: Problem with duplicating spooled file -- COBOL400-L

Marge,

We have for a long time had a system to print a second copy of a report on a different printer. Written 10 years ago, and we have not visited it since. Still runs today. We have the print file save itself after printing. It has a unique user data or formtype (can't remember which) and a program looks at the outq's every day at 10:00. It scans for any of the uniquely identified spool files, then moves them based on the code in the (user data or formtype) part of the code indicates where the spool file will go, and how many copies, etc. It also loops if there is a spool file to be processed, but is not done printing the original copy. I believe that it was done all in cl, but it has bee a long time since I had someone write it. There were no APIs to get the outq contents, etc. If you would like more info on what and how it works, contact me off line. I would like to share. How ever, with the current changes happening at work, it could be a week or more before I could get great details back to you. I will do the best I can.

When I first answered, I was not sure what you were doing.

Jim Essinger
Senior Programmer/Analyst
SLFI
208-452-4058 (call me!)
esinger@xxxxxxxx (write me!)

At 02:47 PM 4/24/2003 -0400, you wrote:

Mark, thanks for the sndnetsplf suggestion. I will try it again after I determine what my net user id/address is.

Joe, the copies parameter would work, except that I'm trying to send the second copy to a different printer. Thanks for the suggestion.

Marge

cobol400-l-request@xxxxxxxxxxxx wrote:
Send COBOL400-L mailing list submissions to
        cobol400-l@xxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.midrange.com/mailman/listinfo.cgi/cobol400-l
or, via email, send a message with subject or body 'help' to
        cobol400-l-request@xxxxxxxxxxxx
You can reach the person managing the list at
        cobol400-l-owner@xxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of COBOL400-L digest..."
Today's Topics:
  1. Problem with duplicating spooled file (Margaret Rozmarynowycz)
  2. RE: Problem with duplicating spooled file (Mark Villa)
  3. RE: Problem with duplicating spooled file (jim essinger)
  4. RE: ACCEPT and the INFDS (Joe Pluta)
  5. RE: ACCEPT and the INFDS (Joe Pluta)
  6. RE: ACCEPT and the INFDS (Jon Paris)
----------------------------------------------------------------------
Message: 1
Date: Wed, 23 Apr 2003 15:00:29 -0700
From: Margaret Rozmarynowycz <mrozmary@xxxxxxxxxxxxx>
Subject: Problem with duplicating spooled file
We have a COBOL program that uses the QSPCRTSP API to create a duplicate spooled file. This program was in use until 1998. Now it aborts on the QSPCRTSP API. The abort message is:
ERROR IN ROUTINE: QSPCRTSP
EXCEPTION ID: CPF33E0
According to the documentation on the iSeries web site http://as400bks.rochester.ibm.com/iseries/v5r1/ic2924/index.htm?info/apis/alpha.htm

this error message represents: incomplete set of attributes provided.

The number of attributes provide by the Cobol program is 198. The length of the attributes area is set at 3446. The program successfully executes the QSPOPNSP (open spooled file), QUSRSPLA (retrieve spooled file attributes), QUSCRTUS (create user spaces), QSPGETSP (get spooled file data) and QSPCLOSP (close spooled file) APIs before attempting to run the QSPCRTSP API.

I started checking each of the 198 parameters against the program list to see which ones might be missing. Near the end, the documentation listed a field called "S36 CONTINUE-YES", along with numerous other fields, through "Offset to Internet print protocol spooled file attributes", which in our Cobol program is defined as a 294-character "reserved" field. After that, beginning with "Front margin offset down" we have all of the fields defined, with no user-defined fields.

Before spending any more time on this effort, I was wondering if there is an easier way to duplicate a spooled file (besides rerunning the report), or at least, an easier way of determining which parameters I need.

Marge Rpzmarynowycz

------------------------------
Message: 2
Date: Wed, 23 Apr 2003 15:54:44 -0400
From: "Mark Villa" <markvilla@xxxxxxxxxxx>
Subject: RE: Problem with duplicating spooled file
~~~ ~~~Before spending any more time on this effort, I was ~~~wondering if there ~~~is an easier way to duplicate a spooled file (besides rerunning the

SNDNETSPLF to your self is a method.
Mark Villa in Charleston SC
------------------------------
Message: 3
Date: Wed, 23 Apr 2003 16:31:37 -0600 (MDT)
From: "jim essinger" <esinger@xxxxxxxx>
Subject: RE: Problem with duplicating spooled file
This may be too simple, but

change the printer file or override to 2 copies?

Jim
~~~
~~~Before spending any more time on this effort, I was
~~~wondering if there
~~~is an easier way to duplicate a spooled file (besides rerunning the
SNDNETSPLF to your self is a method.
Mark Villa in Charleston SC
_______________________________________________
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing
list To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo.cgi/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.
------------------------------
Message: 4
Date: Wed, 23 Apr 2003 23:52:50 -0500
From: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
Subject: RE: ACCEPT and the INFDS
From: Joe Pluta
I think it's actually
going to be relatively easy to implement my modifications;
I have GOT to learn to keep my mouth shut.  As it turns out, there's not
one, but TWO interfaces to worry about.  FILE STATUS gives you the INFDS,
but CONTROL-AREA is an alternate location to get the function key, display
file name and record name.
How bloody lovely.  And it seems that unlike the INFDS, which requires an
ACCEPT to get updated, the CONTROL-AREA is updated magically upon certain
kinds of I/O (hopefully a READ).  So now I have to add conditional code to
my READ emulation routine to see if CONTROL-AREA was specified in the
flipping FILE-CONTROL paragraph, and if it was, to add a call to an API that
fills the control data structure.
I am happy, joyous and free. Really I am.

Joe

------------------------------
Message: 5
Date: Thu, 24 Apr 2003 09:01:39 -0500
From: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
Subject: RE: ACCEPT and the INFDS
THANK YOU one and all.
We've just gotten our second COBOL prospect converted (prospect one has
become a customer and is moving towards deployment).  This client used both
the FILE STATUS and CONTROL-AREA keywords, and with the kind input from you
folks, their system is now conversing happily via a browser.
COBOL is a WAY different animal than RPG, but a good architecture can be
beaten into submission <grin>.
Joe

------------------------------
Message: 6
Date: Thu, 24 Apr 2003 11:06:25 -0400
From: "Jon Paris" <Jon.Paris@xxxxxxxxxxxxxx>
Subject: RE: ACCEPT and the INFDS
>> I am happy, joyous and free. Really I am.

Welcome to the joys of standards driven languages Joe <grin>
One of the biggest problems with languages like COBOL are the huge
"implementer defined" areas.  The standard dictates that CONTROL-AREA is
available, but that is not sufficient for an iSeries shop where there is a
lot more information available about the actual file in use, etc.  COBOL
allows for those extensions, but if you want to stick in the standard, you
have to use the implementer extension areas such as ACCEPT DISPLAY.  You
can't just opt to have an addition structure "just there" like RPG does.
Of course the fact that COBOL doesn't copy a bunch of data around with every
IO is one of the reasons it tends to outperform RPG particularly in batch
type operations.
Just wait 'til you have to implement the new V5R2 RPG I/O options - I
suspect that will give you almost as much fun!  Of course some of them
(LIKEREC for example) would have made your life a lot easier a year or two
back.
Keep smiling oh joyous one!
Jon Paris
Partner400
www.Partner400.com
------------------------------
_______________________________________________
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) digest list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo.cgi/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.
End of COBOL400-L Digest, Vol 1, Issue 224
******************************************
_______________________________________________
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo.cgi/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.