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.
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
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)?
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
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.
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
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
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.
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
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
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
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
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).
