JCL issue with Mainframe Express

[iTrane]

My current project validates transactions and outputs a valid report and an error report. My JCL is setup to output the Error Report right to printer (DD SYSOUT=A) while I'm required to use an IEBGENER to print out the Valid Report. The problem occurs with actually viewing the files in the SPOOL tab. The Error Report comes out fine with a print preview. The Valid Report (using IEBEGENER) only shows Column Headings and Record Numbers. When I actually double click the file (edit mode) all the records are present (just not formatted according to the COBOL). Here is the JCL for the first part of the job:

//PROJECT2  JOB 'PROJ2',CLASS=A,MSGCLASS=X
//*
//*************************************************************
//*  THIS STEP SORTS AND VALIDATES USING COBOL, SYSOUT
//*************************************************************
//STEP1     EXEC PGM=VALIDATE
//SALEDATA  DD DSN=SINPUT,DISP=SHR
//PEOPDATA  DD DSN=PINPUT,DISP=SHR
//SORTFILE  DD DCB=(LRECL=40,DSORG=PS,RECFM=F)
//PEOPSORT  DD DSN=&&PEOPSRT,DISP=(NEW,CATLG,DELETE),
//             DCB=(RECFM=F,LRECL=40,DSORG=PS),
//             SPACE=(TRK,(10,10),RLSE),UNIT=SYSDA
//ERRREP    DD SYSOUT=A
//VALREP    DD DSN=&&VOUT,DISP=(NEW,CATLG,DELETE),
//             DCB=(RECFM=F,LRECL=133,DSORG=PS),
//             SPACE=(TRK,(10,10),RLSE),UNIT=SYSDA
//*
//***********************************************************
//*  THIS STEP PRINTS A VALID REPORT
//***********************************************************
//STEP2     EXEC PGM=IEBGENER
//SYSPRINT  DD SYSOUT=A
//SYSIN     DD DUMMY
//SYSUT1    DD DSN=&&VOUT,DISP=SHR
//SYSUT2    DD SYSOUT=A
//*

What am I doing wrong with this JCL or is it a Mainframe Express problem?

Thanks for any help!!

 

[slade]

Hi i,

The one thing I see is that you use RECFM=F. It s/b FA. Actually you should make it FBA and add BLKSIZE=0. You might also look at the pgm to see what the LRECL is for the report, but it's probably OK since the job ran w/133.

If that doesn't help someone here can help you w/Mainframe Express.

HTH, Jack.

 

[iTrane]

Unfortunately, this didn't fix it. Personally, I think its the way MFE is interpretting the JCL and formatting the output. I have a couple screen shots of the differences between the two.

Thanks.

 

[razalas]

iTrane,

this sounds more like a program error issue rather than a JCL error issue. IEBGENER is not going to affect the format of the records it copies from SYSUT1 to SYSUT2 without control statements from the SYSIN file. If the report records are formatted incorrectly, you probably ought to check your program more closely.

At a minimum run a test changing VALREP in the VALIDATE pgm step to point to SYSOUT=A also and see what you get.


"Code what you mean,
and mean what you code!
But by all means post your code!"

Razalas

 

[iTrane]

razalas,

I've tried that too. I commented my code out and added the SYSOUT=A. Everything came out perfect.

Hmmmmm.

iTrane

 

[CliveC]

If your report has carriage control you need RECFM=FBA. I think the problem may be the catalog. This is not real JCL but why are you cataloging a temporary dataset.

As a real world problem the IEBGENER step is pointless as coded. The idea of that step is that if there is a problem with printing, the whole job does not need to re-run provided you have kept the input to the IEBGENER step.

Try changing the VALREP DSN to a permanent DSN and rerun it with RECFM=FBA as Jack already suggested.

Good Luck!

Clive

http://tubularity.com

 

[CliveC]

P.S Also change the disp of the PEOPSORT DD to new,delete,delete



Clive

http://tubularity.com

 

[iTrane]

I'm not at my computer to test your suggestions right now but I can explain a little. The VALIDATE program must produce a Valid Report which is then used again in a DFSORT program (another issue). If I had a choice I wouldn't use the IEBGENER stuff, but it is a requirement in my problem statement.

I can't really change the System Flow or Job Steps for this JCL. VALIDATE, IEBGENER, DFSORT, IEBGENER are the steps I have to use.

Like you said this isn't real JCL, it is what MFE considers JCL. Things like TRK and SPACE aren't necessary because its writing to a spool in the program rather than tape or disk.

I will try your suggestions when I get home. Thank you so much for your ideas. Keep them coming if you can, but I'm pretty sure this is an MFE problem.

iTrane

 

[slade]

Hi i,

You might want to look at the validate pgm O/P before it gets to gener. Specifically look to see if the cntl chars are there. Is there anything else that may look peculiar?

Also check the sysmsg for any error or warning msgs. It might put you on the right track.

You can also research the relationships among RECFM, ADV/NOADV, AFTER ADVANCING and LRECL. I don't know if that would produce your problem specifically, but it's caused confusion and problems.

Regards, Jack.

 

[iTrane]

If anyone cares, you can download screenshots of what I see on screen of my output. The first page is when I right click and go to print preview. The second page is when I double click the output.

http://bluetrane.digitalrice.com/problem.doc

Thanks,

iTrane

 

[MarcLodge]

Nick,
How are you using MFE at your site? Are programs being tested in MFE, and reverting to the mainframe for execution? If so, I would suggest that you run the program on the mainframe and see if you have a problem. From what you have said, it appears that the problem exists between the mainframe and MFE, and how MFE interprets mainframe JCL. I would suggest that you take a step back and look at the overall situation as I have a feeling that you have found an anomly within MFE which is unnecessarily holding you up. Try running the whole thing on the mainframe and if all work well, report it as a problem to Microfocus.

Marc

 

[iTrane]

The actual mainframe was shutdown last week for good. The last update came circa 1970. We're now using MFE for all programs. Unfortunately, the instructor knows less about MFE than I do.

It is an anomily within MFE because my friend is experiencing the same problem writing the same IEBGENER.

Consider this not your problem...lol.

Its about to be not mine anymore either. Thanks for all your help.

Nick

 

[MarcLodge]

Hi Nick,
I've just got into MFE recently, and although I think it's a good product, I feel that it's strength is as a testing tool. Running IEBGENER's and SORT's is defintely problematical.

Good luck,

Marc

 

[3gm]

From looking at your screen shots, I'd say the problem is you're not initializing your report records with spaces. Instead, they've got low-values in the FILLER areas. The GENER seems to be treating the input records as null-terminated strings (ala C or C++). Fix the nulls and I'll bet your output looks better!

Regards.

Glenn

 

[iTrane]

Please elaborate...

Do you mean I should have something like this for each line:

DATADUMP-LINE.
05 CC1 PIC X.
05 FILLER PIC XXX.
05 REC-NUM-OUT PIC 999.
etc.

Thanks,

Nick

 

[webrabbit]

You should MOVE SPACES TO DATADUMP-LINE before moving anything to detail fields such as REC-NUM-OUT.

 

[3gm]

iTrane -

You can handle it as WebRabbit indicates, or you can do it statically:

01  DATADUMP-LINE.
    05  CC1               PIC X.
    05                    PIC XXX VALUE SPACES.
    05  REC-NUM-OUT       PIC 999.
[\CODE]
Just make sure every field in your output record has been given a value before you write the output record.  

Failure to initialize FILLER areas is a common problem.  In many situtations, WORKING-STORAGE is set to LOW-VALUES when the program is loaded.  Most mainframe printers will treat a LOW-VALUE in a print line like a space, so the programmer nevers sees that s/he has bad output.  In the PC world, LOW-VALUES get interpreted as "end of string" and you suddenly have problems where there were none before.

Regards.

Glenn

 

[iTrane]

You're right!! This fixed the problem. I moved spaces to the line before the moves. Then I added a couple more moves to get formatting back in there, like slashes.

Thanks so much!!

Nick