|
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 ******************************************
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
