IBM Mainframe Forum

@BillyBoyo: I've removed the DD statements and got similar results.

Removed from where?

What is the DD name that you are giving in your Assembler program?

Although steve-myers has shown there is no syntax-checking for it, that does not prevent the necessity of it being a valid DD name for JCL. If you have a period/fullstop in a DD name in JCL it means something completely different from what you want. Make the "DD names" in your Assembler program valid for JCL then you should get somewhere.

It is not the fact that the file is/was zipped - it is the fact that the file(s) have to be downloaded which is not possible for some people (e.g. me) at work. The data should simply be cut and pasted into the message reply box and surrounded by code tags to give that "green screen" feel that we all know and love!

Billy - I never think to use the thumbs-up button and, anyway, taking the effort to write the words out shows more appreciation. Well, from my viewpoint!

Well, it is a funny old thing, the Thanks Button. It is only a click away. I think most people don't realise what the Thumb-up does.

Curiously, our TS here knows how to use it, and thanked you without thanking those who've pointed to the exact problem for them

OK - clicked as well! And now that I can see the material posted I can see where the TS has gone wrong - he does not understand JCL and that what he is looking at are actually overrides to ddnames in step G of the procedure.

From the sysout. Note the last line... how could you possibly proceed to an S0C4 if the files were opened successfully

If you are giving an informational message based on some condition, you have to test for that condition. Messages which don't mean what they say can cause considerable confusion and time-wasting (which can cost money).

Riscciscinstset,

For some reason I looked at your code further.

It is about 10 months since you've been here, and I guess in that time you didn't have much time to apply yourself to learning.

For a small program, I don't know how to list the inconsistencies.

Are you reading 133 or 80?

Are you writing 133 or 72?

Are your input and output FBA or not?

You seem to treat CHAR as sufficient to occupy 10 bytes on output, yet it is only two bytes long.

NUM allows for seven digits.

What, other than a S0C7, do you expect to be in NUM after you get a successful GET?

You OI with byte three of NUM, yet the sign will be in byte four.

Your initialisation of the 80-byte output (currently) with a 133 byte literal of space is "wasteful" of storage, though that may not matter these days. The initialisation can be done with no extra storage defined.

To me it is very confusing to call a program COPY.

I know next to nothing about BAL but I do know that you are trying to run on z/OS or MVS and thus the data is in EBCDIC form and not ASCII as your WTO says.

Holding a post until I try something... |:-|