To answer several questions.
Nothing in the program modules showed any copyright information.
Programs had been written in assembler. All four programs had been last
assembled with ASSEMBLER H V2R1 in 1987.
The business unit that uses the program have no idea where the programs came
from and don't know of any source code.
The fix had to do with the OBTAIN macro. If the input dataset got allocated on
an EAV volume the program would fail. This had to do with the FORMAT-1 vs.
FORMAT-8 DSCB information. On the OBTAIN macro there is a parameter EADSCB
which affects how things are handled related to FORMAT-1 and FORMAT-8. The
default is to not support anything other than a FORMAT-1 DSCB. We got lucky
and was able to zap the parameter list for the OBTAIN to support either the
FORMAT-1 or FORMAT-8. After testing things it seems the program is working as
expected after we did the zap.
EADSCB
Specifies whether this program supports data sets with format-8 and
format-9 DSCBs. Such data sets can appear on extended address
volumes.
EADSCB=OK
Code EADSCB=NOTOK when your program does not support data
sets that have format-8 and format-9 DSCBs. The extent
descriptors in DSCBs for a data set described with these
formats may have track addresses that contain cylinder
addresses 65,520 or larger. EADSCB=OK is accepted for data
sets described by all DSCB types, including format-1 DSCBs,
regardless of the volume size where the data set resides.
Your program can also run on an older level of the system
that does not support this keyword. In these cases,
EADSCB=OK is ignored. EADSCB=OK sets byte 2 bit 4 in the
OBTAIN parameter list to on.
EADSCB=NOTOK
Code EADSCB=NOTOK when your program does not support DSCBs
that describe data sets with format-8 and format-9 DSCBs.
EADSCB=NOTOK is the default when the EADSCB keyword is not
specified.
When EADSCB=NOTOK is coded or assumed by default, OBTAIN
will set return code 24 if the target of the OBTAIN request
has a format-8 DSCB.
EADSCB=NOTOK sets byte 2 bit 4 in the OBTAIN parameter list
to zero.
So now it is on to the next issue/crisis. :)
Thanks..
Paul Feller
AGT Mainframe Technical Support
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Gibney, Dave
Sent: Monday, February 25, 2019 11:51 AM
To: [email protected]
Subject: Re: Anyone ever seen/hear about a set of programs called
SUPERCOP/SUPCOP1/SUPCOP2/SUPCOP3 [EXTERNAL]
Or what language it's written in? awe had a homegrown PL/I program called
DSCOPY. Might have source. No longer have PL/I compiler.
> -----Original Message-----
> From: IBM Mainframe Discussion List <[email protected]> On
> Behalf Of Tom Marchant
> Sent: Monday, February 25, 2019 9:47 AM
> To: [email protected]
> Subject: Re: Anyone ever seen/hear about a set of programs called
> SUPERCOP/SUPCOP1/SUPCOP2/SUPCOP3 [EXTERNAL]
>
> On Mon, 25 Feb 2019 12:10:42 -0500, Chuck Kreiter wrote:
>
> >I asked a former co-worker who is still with the insurance company.
> >He found some old JCL examples but no source code. He seemed to
> >think it came from Policy Management Systems, which also wrote the
> >policy administration software we used at the time. I think they
> >were acquired by CSC along the line.
>
> Have you browsed the load module(s) to see if there is a copyright
> notice or any other text that might indicate where it came from?
>
> --
> Tom Marchant
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
