IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Convert CICS Modules to AMODE ANY


IBM Mainframe Forums -> PL/I & Assembler
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
CICSWOLF

New User


Joined: 23 Oct 2018
Posts: 4
Location: USA

PostPosted: Fri Feb 08, 2019 7:10 pm
Reply with quote

Hi Gentlemen,
With restriction in CICS TS 5.4 that defaults to program location to ANY several modules fails, so
I have the task to convert modules from AMODE 24 to AMODE 31 or ANY,
after a couple intents, decided to separate DCB module from CICS module in order the second run in AMODE 31,
the code I take as example has 3 statements to set vector table as:
DC A(SYSPRT) Vector to standard sysprint DCB
DC A(SYSIN) Vector to standard sysin DCB
DC A(0)
tried to assembly and got errors in those ADCON, decided to
include macro CVT instead and assemble ok,
can still this module to be called by the CICS Module?
I will appreciate your Feedback.

Read more: ibmmainframes.com/viewtopic.php?t=66300#ixzz5ewk9uc44
icon_redface.gif
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Fri Feb 08, 2019 7:57 pm
Reply with quote

Quote:
can still this module to be called by the CICS Module?
Try it and see. You are operating so far outside normal CICS conventions that there is no way to know if what you want to do will work. Since CICS normally controls all I/O, programs running under CICS pretty much NEVER have DCB coded and don't do any DCB-associated macros (such as OPEN, CLOSE, PUT, GET, etc -- or in COBOL no FILE SECTION, FD, SELECT, OPEN, READ, WRITE, or CLOSE statements).

One question I have is why you didn't code up a DCBE to minimize the number of changes required in your program(s)?
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Fri Feb 08, 2019 8:30 pm
Reply with quote

There are two problems here.
  • Unlike MSDOS or *nix, there are no persistent stdin or stdout (something like your "standard SYSPRINT DCB" or "standard SYSIN DCB") definitions in z/OS. I've been writing assembler for more than 50 years. Believe me.
  • As Mr. Sample says, regular CICS interactive programs should not use DCBs to access data sets or, for that matter, terminals operated by a user. You must use CICS provided APIs for this.
Altering a correctly functioning AMODE 24 program to AMODE 31 is usually very simple. Frequently no code changes are required unless you also want the program to also run RMODE ANY rather than the default RMODE 24. (RMODE ANY implies the program will run regardless of where the program is loaded in storage.) This usually requires major changes to the program. The use of DCBE macros, as Mr. Sample says, is part of the changes you must make.

In my last paragraph I conveniently forgot about a few "gotchas" in this code. Long ago I got in the habit of not using common AMODE 24 techniques just so I use AMODE 31 techniques all the time even in AMODE 24 programs. Not with the idea I'm gong to convert the program to AMODE 31 mind you, just so I use the same method in all my programs.
Back to top
View user's profile Send private message
CICSWOLF

New User


Joined: 23 Oct 2018
Posts: 4
Location: USA

PostPosted: Fri Feb 08, 2019 9:13 pm
Reply with quote

Mr Sample,
yes I am in the try and see route now, the DCB module has DCBE, the CICS module has only the OPEN, CLOSE macros now with MODE=31,
Mr Myers,
Those legacy programs had DCB inside for many years, they trigger jobs from CICS, now is the time to upgrade. forced decision to support them asis.
Thanks both for the input.
CICSWOLF
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Wed Feb 13, 2019 2:50 am
Reply with quote

We see queries like this from time to time. Always something is missing.
  • Why?
    • Access data that is already above the line
    • Move I/O buffers above the line
  • Program text to move above the line?
Then we see indications the programmer hasn't much of a clue, like CICSWOLF talking about DCBs in CICS code. CICSWOLF: Normal CICS programs do not use DCBs. CICS provides APIs to access data sets. These APIs should be used rather than DCBs. Programs attempting to use DCBs will interfere with the normal functioning of CICS. I'm not a CICS programmer, but even I know this.
Back to top
View user's profile Send private message
CICSWOLF

New User


Joined: 23 Oct 2018
Posts: 4
Location: USA

PostPosted: Wed Feb 13, 2019 2:55 am
Reply with quote

I do agree but it is what it is,
not my decision my task is to convert,
BTW
my original assembler question got unresolved
how to define the ADCON?
thanks, no need more feedback.
CICSWOLF
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Wed Feb 13, 2019 7:37 am
Reply with quote

Don't you READ? In my very first post in this thread I CLEARLY said there is no such thing as a "standard" SYSPRINT or "standard" SYSIN DCB, in the same way as C headers (like I think it's stdio.h) define a stdout. You specify a DCB for this. In most of my batch programs you will find

PRINT DCB DSORG=PS,MACRF=PM,DDNAME=SYSPRINT,RECFM=VBA,LRECL=125

Once this is done you can specify

DC A(PRINT)

By the way, many beginners are uncomfortable with RECFM=VBA, LRECL=125. I was when I first started. I generally used RECFM=FBA, LRECL=121. After 10 or 15 years I realized the practical benefits of RECFM=VBA and I've used it, nearly exclusively, since then.

Now, I guess you ask, what are the practical benefits of RECFM=VBA, LRECL=125?
  • 50 years ago it was easy to watch output roll through a line printer. It was easy to note that most output lines contained far less than 121 bytes. Rather than write 121 bytes for a line containing 30 or 40 bytes, you only need to write 30 or 40 bytes. In a program actually writing, say, 100,000 lines, that's a lot less real bytes going to the output media.

  • Many programs contain fixed message areas -

    ERR1 DC CL121' I AM A FIXED MESSAGE'

    A fixed message of the form

    ERR1 DC AL2(ERR1L,0),C' I AM A FIXED MESSAGE'
    ERR1L EQU *-ERR1

    uses much less valuable space (and addressability) than fixed length messages. Yes, it's much less convenient, but ...

    These programs will load more quickly, too.

  • Many programs build up variable messages one element at a time. If these messages are built in a common build area, you generally do not need to do something like

    MVI OUTLINE,C' '
    MVC OUTLINE+1(L'OUTLINE-1),OUTLINE

    or do the equivalent, set the unused part of the line to blanks.

  • One last bullet, Why use LRECL=121? 50 years ago the dominant line printer in the IBM world was the 1403. These printers could print either 120 characters on a line or 132 characters on a line. Most printed 132. I never encountered a 120 byte 1403, but the IBM semi standard was to assume you were really limited to 120 characters, so many programs, like mine, use RECFM=FBA, LRECL=121 (one extra byte for the carriage control character).
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> PL/I & Assembler

 


Similar Topics
Topic Forum Replies
No new posts Using API Gateway from CICS program CICS 0
No new posts Need to convert date format DFSORT/ICETOOL 20
No new posts Calling an Open C library function in... CICS 1
No new posts How to 'Ping' a CICS region in JCL CICS 2
No new posts Parallelization in CICS to reduce res... CICS 4
Search our Forums:

Back to Top