COBOL for VSE and UPSI Switch
Kevin Corkery
Have tried converting an old COBOL program to COBOL for VSE that uses UPSI
switches. Well, the problem is that it doesn't seem ever to detect the UPSI
as being set on. I tried using this in a brand new program also to see if
it works, and it doesn't. Yes, I did have // UPSI 11111111 in the JCL so
that every swith was set on. The old FCOBOL routine handled this correctly.
The real rub to this is that I scanned the library and there are quit a few
as yet converted programs that use the UPSI facility. I'd sure wouldn't
like to convert all of these to a different method. So the question is ...
has anyone encountered this before and if so, is there a fix available.
TIA.
Kevin Corkery
Independent Consultant
Voorhees, New Jersey
Dan Askew
pgm,parm='upsi xxxxxx" or "// exec pgm,parm="/upsi 0101010"
Tony Thigpen
routines that fixes that. Others may have better/slicker routines.
*================== START OF COPYBOOK VOLWUPSI ==================*
* CODING REQUIREMENTS: *
*01 VOLUPSI-AREA. *
* COPY VOLWUSPI. *
*================================================================*
*01 VOLUPSI-AREA.
03 FILLER PIC X(08) VALUE 'VOLWUPSI'.
03 VOLUPSI-VER PIC X(08) VALUE '00.00.00'.
03 VOLUPSI-FLAGS.
05 VOLUPSI-UPSI-0 PIC X(01).
05 VOLUPSI-UPSI-1 PIC X(01).
05 VOLUPSI-UPSI-2 PIC X(01).
05 VOLUPSI-UPSI-3 PIC X(01).
05 VOLUPSI-UPSI-4 PIC X(01).
05 VOLUPSI-UPSI-5 PIC X(01).
05 VOLUPSI-UPSI-6 PIC X(01).
05 VOLUPSI-UPSI-7 PIC X(01).
03 FILLER PIC X(08) VALUE 'THEENDOF'.
03 FILLER PIC X(08) VALUE 'VOLWUPSI'.
*==================== END OF COPYBOOK VOLWUPSI ==================*
*================== START OF COPYBOOK VOLPUPSI =================*
* CODING REQUIREMENTS: *
*VOLUPSI SECTION. *
* COPY VOLPUPSI. *
*----------------------------------------------------------------*
* REFFERENCED COPYBOOKS: *
* VOLWUSPI *
*----------------------------------------------------------------*
* CALLING SEQUENCE: *
* 1. PERFORM VOLUPSI. *
* 2. THE COBOL UPSI FLAGS WILL BE SET BASED ON THE JCL *
* UPSI SETTINGS. *
*----------------------------------------------------------------*
* ADDITIONAL CODING REQUIREMENTS: *
* 1. CODE ALL UPSI FLAGS IN THE CONFIGURATION SECTION. *
* - - - - -** SAMPLE START **- - - - - - - - - - - - - - - - - - *
*ENVIRONMENT DIVISION. *
*CONFIGURATION SECTION. *
*SPECIAL-NAMES. *
* UPSI-0 IS UPSI0 *
* ON IS INPUT-DATABASE <- CHANGE FLAG NAME *
* UPSI-1 IS UPSI1 *
* ON IS INPUT-TAPE <- CHANGE FLAG NAME OR DELETE *
* UPSI-2 IS UPSI2 *
* ON IS XXXX <- CHANGE FLAG NAME OR DELETE *
* UPSI-3 IS UPSI3 *
* ON IS XXXX <- CHANGE FLAG NAME OR DELETE *
* UPSI-4 IS UPSI4 *
* ON IS XXXX <- CHANGE FLAG NAME OR DELETE *
* UPSI-5 IS UPSI5 *
* ON IS XXXX <- CHANGE FLAG NAME OR DELETE *
* UPSI-6 IS UPSI6 *
* ON IS XXXX <- CHANGE FLAG NAME OR DELETE *
* UPSI-7 IS UPSI7 *
* ON IS XXXX. <- CHANGE FLAG NAME OR DELETE *
* - - - - -** SAMPLE END **- - - - - - - - - - - - - - - - - - - *
*================================================================*
VOLPUPSI-START.
CALL 'VOLXUPSI' USING
VOLUPSI-FLAGS.
SET UPSI0 TO OFF.
IF VOLUPSI-UPSI-0 IS EQUAL TO '1'
SET UPSI0 TO ON.
SET UPSI1 TO OFF.
IF VOLUPSI-UPSI-1 IS EQUAL TO '1'
SET UPSI1 TO ON.
SET UPSI2 TO OFF.
IF VOLUPSI-UPSI-2 IS EQUAL TO '1'
SET UPSI2 TO ON.
SET UPSI3 TO OFF.
IF VOLUPSI-UPSI-3 IS EQUAL TO '1'
SET UPSI3 TO ON.
SET UPSI4 TO OFF.
IF VOLUPSI-UPSI-4 IS EQUAL TO '1'
SET UPSI4 TO ON.
SET UPSI5 TO OFF.
IF VOLUPSI-UPSI-5 IS EQUAL TO '1'
SET UPSI5 TO ON.
SET UPSI6 TO OFF.
IF VOLUPSI-UPSI-6 IS EQUAL TO '1'
SET UPSI6 TO ON.
SET UPSI7 TO OFF.
IF VOLUPSI-UPSI-7 IS EQUAL TO '1'
SET UPSI7 TO ON.
VOLPUPSI-EXIT.
EXIT.
*==================== END OF COPYBOOK VOLPUPSI =================*
++IMBED VOLMREQU
REQU
VOLXUPSI RMODE ANY
VOLXUPSI CSECT ENTRY POINT
USING VOLXUPSI,R11 PROVIDE A BASE REGISTER
STM R14,R12,12(R13) SAVE CALLERS REGISTERS
LR R11,R15 LOAD THE BASE REGISTER
L R8,0(R1) POINT TO PARM AREA
LA R8,0(R8) CLEAN ADDRESS
USING PARMS,R8
MVC UPSI,=C'00000000'
COMRG REG=(R1) GET ADDRESS TO UPSI BITS
TESTU0 TM 23(R1),MASK80
BZ TESTU1
MVI UPSI0,C'1'
TESTU1 TM 23(R1),MASK40
BZ TESTU2
MVI UPSI1,C'1'
TESTU2 TM 23(R1),MASK20
BZ TESTU3
MVI UPSI2,C'1'
TESTU3 TM 23(R1),MASK10
BZ TESTU4
MVI UPSI3,C'1'
TESTU4 TM 23(R1),MASK08
BZ TESTU5
MVI UPSI4,C'1'
TESTU5 TM 23(R1),MASK04
BZ TESTU6
MVI UPSI5,C'1'
TESTU6 TM 23(R1),MASK02
BZ TESTU7
MVI UPSI6,C'1'
TESTU7 TM 23(R1),MASK01
BZ RETURN
MVI UPSI7,C'1'
RETURN EQU * RETURN
LM R14,R12,12(R13) RESTORE REGISTERS
LA R15,0 SET RETURN CODE TO 0
BR R14 GO BACK
LTORG
MYSAVE DC 18F'0' SAVE AREA
DC C'END OF VOLXUPSI'
PARMS DSECT DSECT FOR PARM AREA
UPSI DS 0CL8 ALL UPSI FLAGS
UPSI0 DS CL1 UPSI 0 FLAG
UPSI1 DS CL1 UPSI 1 FLAG
UPSI2 DS CL1 UPSI 2 FLAG
UPSI3 DS CL1 UPSI 3 FLAG
UPSI4 DS CL1 UPSI 4 FLAG
UPSI5 DS CL1 UPSI 5 FLAG
UPSI6 DS CL1 UPSI 6 FLAG
UPSI7 DS CL1 UPSI 7 FLAG
END
Tony Thigpen.
Thigpen Enterprises, Inc.
Developers of VSE2PDF
http://www.vse2pdf.com
-----Original Message-----
From: owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU]On Behalf Of
Kevin Corkery
Sent: Tuesday, November 20, 2001 9:47 AM
To: VSE Discussion List
Subject: COBOL for VSE and UPSI Switch
Garry Hasler
Hi Kevin,
Just follow this link and you will get source code for an exit that allows
COBOL/VSE
to "see" JCL UPSI settings. It replaces the LE UPSI runtime option for you at
runtime so that the COBOL/VSE program "sees" the UPSI bits in COMREG.
http://www-1.ibm.com/servers/eserver/zseries/os/vse/le/topics/ceebxita.txt
Regards,
Garry Hasler
VM/VSE Systems Programmer
APC - Perth
marti...@freenet.de
As Tony stated UPSI is something in the COMREG and to complicate the process LE-COBOL gives you the UPSI as specified in LE-options (or overwritten in PARM).
I have seen (I seam to recall it is from Gary H) a program that sets at invocation of the LE-COBOL the LE-UPSI to the UPSI in COMREG (from VSE UPSI-stmt).
Do you want me to look for it - or does that already help?
Martin
Whatever follwos behind ---- was not typed by my but appended by some §$%&mail-program
----
--
Lust auf Ferien?
Bei uns koennen Sie planen und buchen: Laenderinfo, City-Guide,
Routenplaner, Stauprognose, Hotelsuche Last Minute und mehr.
http://reisen.freenet.de
freenet.de - normal ist das nicht!
HPI...@aol.com
// EXEC pgmname,SIZE=AUTO,PARM='/UPSI(11000000)'
Kevin Corkery
documentation (something that I always recommend where IBM is concerned
since it is generally "in there") and UPSI is implemented via the inclusion
on the PARM statement at runtime. This isn't a big problem although not
transparent. Thanks to everyone who replied to my post. I remember years
ago a shop that had converted to OS/VS1 from DOS/VS and this was a big issue
for them ... it was resolved by using PARM and a subroutine that fetched the
PARM and populated a working storage area. In the past application
portability between DOS and OS ususally required the use of input control
cards since DOS never really handled PARM while OS did. In any event, for
this site preference is to use real meaningful PARM data instead of UPSI
switches but thats way beyond the scope of "on the fly" conversions of
older programs, so passing the UPSI differently at run time will be
acceptable..
Kevin Corkery
Independent Consultant
Voorhees, New Jersey
----- Original Message -----
From: Kevin Corkery <kevin....@home.com>
To: VSE Discussion List <vs...@Lehigh.EDU>
Sent: Tuesday, November 20, 2001 6:46 AM
Subject: COBOL for VSE and UPSI Switch
Gilbert Saint-Flour
>... I remember years ago a shop that had converted to OS/VS1 from DOS/VS
>and this was a big issue for them ... it was resolved by using PARM and
>a subroutine that fetched the PARM and populated a working storage area.
The VS COBOL for OS/VS compiler, which was the standard COBOL compiler in OS/VS1 and OS/VS2 (MVS) starting in 1977, supported UPSI(nnnnnnn) in the PARM, just like the COBOL for VSE and COBOL for OS/390 compilers do today. So, perhaps, writing a sub-routine was not necessary.
Gilbert Saint-flour
ConvTek
http://members.home.net/gsf/
Kevin Corkery
may have been the older compiler.
Kevin Corkery
Independent Consultant
Voorhees, New Jersey
----- Original Message -----
From: Gilbert Saint-Flour <g...@home.net>
To: VSE Discussion List <vs...@Lehigh.EDU>
gary....@escape.net.au
I did post something last nite (Perth time) but it didnt seem to make it for
some reason. Anyway, if you follow this link you will get the JCL and
source code for an exit that will present the JCL // UPSI bit settings to
LE for use. Replacing the LE UPSI runtime option settings. This will allow
COBOL/VSE programs to "see" the JCL // UPSI settings.
http://www-1.ibm.com/servers/eserver/zseries/os/vse/le/topics/ceebxita.txt
Hope this helps.
Regards,
Garry Hasler
VM/VSE Systems Programmer
APC - Perth.
> Sorry for the false alarm and posting my own reply. I read the
> documentation (something that I always recommend where IBM is concerned
> since it is generally "in there") and UPSI is implemented via the
inclusion
> on the PARM statement at runtime. This isn't a big problem although not
> transparent. Thanks to everyone who replied to my post. I remember years
> ago a shop that had converted to OS/VS1 from DOS/VS and this was a big
issue
> for them ... it was resolved by using PARM and a subroutine that fetched
the
> PARM and populated a working storage area. In the past application
> portability between DOS and OS ususally required the use of input control
> cards since DOS never really handled PARM while OS did. In any event, for
> this site preference is to use real meaningful PARM data instead of UPSI
> switches but thats way beyond the scope of "on the fly" conversions of
> older programs, so passing the UPSI differently at run time will be
> acceptable..
>
> Kevin Corkery
> Independent Consultant
> Voorhees, New Jersey
>
> ----- Original Message -----
> From: Kevin Corkery <kevin....@home.com>
> To: VSE Discussion List <vs...@Lehigh.EDU>
> Sent: Tuesday, November 20, 2001 6:46 AM
> Subject: COBOL for VSE and UPSI Switch
>
>
> > Hi All ...
> >
> > Have tried converting an old COBOL program to COBOL for VSE that uses
UPSI
> > switches. Well, the problem is that it doesn't seem ever to detect the
> UPSI
> > as being set on. I tried using this in a brand new program also to see
if
> > it works, and it doesn't. Yes, I did have // UPSI 11111111 in the JCL
so
> > that every swith was set on. The old FCOBOL routine handled this
> correctly.
> > The real rub to this is that I scanned the library and there are quit a
> few
> > as yet converted programs that use the UPSI facility. I'd sure wouldn't
> > like to convert all of these to a different method. So the question is
> ...
> > has anyone encountered this before and if so, is there a fix available.
> > TIA.
> >
Kevin P Corkery
response ... basically right on target ...Thanks.
Kevin P Corkery
Independent Consultant
Voorhees, New Jersey
> -----Original Message-----
> From: owner...@Lehigh.EDU
> [mailto:owner...@Lehigh.EDU]On Behalf Of
> gary....@escape.net.au
> Sent: Tuesday, November 20, 2001 8:36 PM
> To: VSE Discussion List
Max Singley
Ok, so it is something that is probably very obvious to anyone else who
looks at it, but I'm missing it. We have a program that is cancelling with
CEE3204S THE SYSTEM DETECTED A PROTECTION EXCEPTION message. When we turn on
the DEBUG parameter it works and we determined the failing statement is when
we are moving spaces to the parameter area because we normally run without
the parameter specified. Here's the relevant statments:
01 PARM-AREA.
05 PARM-LENGTH COMP PIC S9(04).
05 PARM-DEBUG PIC X(05).
05 FILLER PIC X(75).
IF PARM-LENGTH = 0
MOVE SPACES TO PARM-AREA
END-IF
What are we doing wrong?
Thanks in advance,
Max E. Singley
Technical Services Project Leader
Alex Lee, Inc.
Email: max.s...@alexlee.com Tel: 828-485-4894
----- Original Message -----
From: "Dan Askew" <Da...@dowlingassoc.com>
To: "VSE Discussion List" <vs...@Lehigh.EDU>
Kevin P Corkery
think the result is that you're trying to move spaces to address X'00000000'
thus that ka-booommm.
Kenneth Meyer
Where is the parm area defined? Is it storage or mapping of
another area?
Ken Meyer
BIM
snip..
> When we turn on
> the DEBUG parameter it works and we determined the failing
> statement is when
> we are moving spaces to the parameter area because we
> normally run without
> the parameter specified. Here's the relevant statments:
>
> 01 PARM-AREA.
> 05 PARM-LENGTH COMP PIC S9(04).
> 05 PARM-DEBUG PIC X(05).
> 05 FILLER PIC X(75).
>
> IF PARM-LENGTH = 0
> MOVE SPACES TO PARM-AREA
> END-IF
>
> What are we doing wrong?
snip..
Max Singley
----- Original Message -----
From: "Kenneth Meyer" <KMe...@bimoyle.com>
To: "VSE Discussion List" <vs...@Lehigh.EDU>
Dwa...@aol.com
Dumb question, but did you issue a PROCEDURE DIVISION USING for the parm area?
David Wakser
Mnemotech
Max Singley
PROCEDURE DIVISION USING PARM-AREA.
Thanks,
Max E. Singley
Technical Services Project Leader
Alex Lee, Inc.
Email: max.s...@alexlee.com Tel: 828-485-4894
Kenneth Meyer
Ken Meyer
BIM
> -----Original Message-----
> From: Max Singley [mailto:msin...@alexlee.com]
> Sent: Tuesday, November 27, 2001 11:11 AM
> To: VSE Discussion List
> Subject: Re: Cobol/VSE problem with CEE3204S protection exception
>
>
> Here's where it is.
>
> PROCEDURE DIVISION USING PARM-AREA.
>
> Thanks,
snip..
Gary Weinhold
a parameter, either on the EXEC statement or in a programmed CALL
statement. IBM standards are that R1 point to the first of a list of
addresses of parameters. If no parameter is specified, R1 would, even if
it is initialized, point to an address which was not initialized. As
someone else said, R1 may not even be initialized with a valid address.
In the COBOl Language Reference, it specifically states: only specify
the PROCEDURE DIVISION USING ... phrase if the program is invoked by a
CALL statement with the USING phrase. But it also mentions that the
CALL statment can be from another language or a PARM passed on execution
JCL.
Gary Weinhold
Rbo...@aol.com
<<What are we doing wrong?>>
I'm betting that when there is/was no PARM passed there is no addressibility,
hence the abend. It's sorta like trying to move spaces to a 01 level record
area and ya haven't opened up the file yet using COBOL/VSE. Some programmers
got burned on this one at my previous employer.
Max Singley
1.1.0 and now it won't work under VSE 2.5.1, LE/COB 1.4.1, and COBOL 1.1.0.
I opened a PMR with IBM to find out what the difference is. Thanks for all
the reponses.
Sincerely,
Max E. Singley
Technical Services Project Leader
Alex Lee, Inc.
Email: max.s...@alexlee.com Tel: 828-485-4894
----- Original Message -----
From: <Rbo...@aol.com>
To: "VSE Discussion List" <vs...@Lehigh.EDU>
Sent: Tuesday, November 27, 2001 6:49 PM
Subject: Re: Cobol/VSE problem with CEE3204S protection exception
Martin
>> to find out what the difference is. <<
Dirt/leftover stuff that constituted a valid adress (and did not destroy
anything vital)
The method (and that is the only method that was and is valid as some
that used other methods can tell) is to do as the books say: compare R1
and and R15 if they are equal there is no parm else there is one. Cobol
has to stick to that rule as well.
I have no idea what cobol moved to the BLL (because of naming it in the
PROCEDURE DIVISION USING..). Apparently it did make sense in the working
scenario.
To blindly use whatever comes in via R1 is okay if you can make sure
that there is always a parm (+of the length defined in the linkage
section). COBOL does apparently blindly use what comes in-
Wonder if your PMR will end up as docu-change or works as designed.
--
Martin Truebner
mail: Mar...@pi-sysprog.de homepage: www.pi-sysprog.de
TRAPPER + LE-FLOW two unique solutions for VSE or OS/390
Max Singley
not fail with a protection exception under VSE 2.3, it was still overwriting
82 bytes of storage. Here's the summary if anyone is interested. Thanks for
all the reponses.
"The program should be corrected (also for VSE/ESA 2.3 - you don't get a
protection exception there, but because
the length is 00 when you run through this part of the program, you
overwrite 82 bytes in storage...)
The below LE trace-back shows that the MVI 0(3),X'40' causes a
Protection Exception. GPR13 points to the stack frame used by the program.
GPR13 + 308 (x'6B5038' + x'134' = x'6B516C') points to the storage area
where the Parameter is passed to the application as a halfword prefixed
string. This means the first two bytes include the length of the following
string (which is checked by the "IF PARM-LENGTH = 0" statement).
But when the length is 0 the COBOL program tries to copy 82 spaces to the
length field and the 80 following bytes. This forced a protection exception,
since the application is not allowed to
write into this storage. The COBOL program shoud copy the PARM-AREA to a
working storage area if
there is a need to overwrite it with spaces. But even then it might not be
correct to overwrite the length with spaces."