Mainframe, MVS and zOS Discussion

Hi all,

For past few days I am facing an issue like my sortcard failing:
This has been executing everyday fine in production until this week when I checked the version the successful run happened with SYNCSORT v 1.4.2.0 where as failure executed with SYNCSORT 2.1.3.0.

WER425A => The error I get is this 'Convert feature cannot be used with overlay or ifthen'
Is it possible to dynamically change the version?

Or anyone of you had a similar experience

Also I am not sure if outfile is same as outfil

Is it possible to dynamically change the version?

Also I am not sure if outfile is same as outfil

RTFM

when upgrading systems components Your organisation should provide the pointers to the updated doc/manuals

and ...
any well behaved software support group should have made available a short/long memo
describing the changes and the relevant gotcha' s

Yes the confusion prevails because aftersome time

I change the code to
and It works as expected for the same input file but At this moment I did not any convincing answers from Admin and Environment team and Syncsort version changes from 2.1.3 to 1.4.2.0

My billion$ question is how was the code working before in production how is the SYSOUT keeps changing the SYNCSORT version in a span of 2 hours.

Could you please also show the DCB parameters on the SORTOUT? If they are coded there, execute job after removing the LRECL from the DCB and see if works.

OTOH and just a guess, if the output needs to be of LRECL 80, try:
One can but one must not do a version change "dynamically" unless someone specifically uses a library in the JCL to refer binaries from new version - and as such it's not done dynamically someone has done it manually. Such an act is most unlikely in a production environment and can, anyway, be verified easily from the SYSOUT of failed job, just in case.

OUTFILE can be used as an alias for OUTFIL.

zprogrammer wrote: ...and Syncsort version changes from 2.1.3 to 1.4.2.0

How do you verify this?

See

Anuj Dhawan wrote:[How do you verify this?

My understanding that SYSOUT of the sort step mentions which version of SYNCSORT has been used in second line like

Syncsort x.x.x.x

So at 12 PM I saw 2.1.3.0 is used and after couple of hours 1.4.2.0 is used, In the mean time the job fails

That's very unusual behavior. Hopefully, it does not happen in PROD, does it?

Can you verify the library name from where the SyncSort is being picked up for different runs? That should help to verify what's happening.

It is indeed happening in PROD

It is indeed happening in PROD

good luck

That's strange- time to raise a flag through proper channel.

Though AFAIK "WER425A Convert feature cannot be used with overlay or ifthen" exist since so long; even before SyncSort 2.x.x.x.

Hi,

Was just curious to know about the progress. Anything new and positive?

Hi

Yeah I convinced the Syncsort support team there is some problem and on further deep down analysis it was found that when the system is A the job is failing but when system is B it is not failing.

They wanted to convert this using OUTREC I am trying to figure out a way for the same.

You are just... counting the records, right?
What's the point of the CONVERT?

Although you can CONVERT in OUTREC (with SyncSORT), it is a stupid suggestion to be made to you. They want you to go through making records variable-length just so you can count them?

Why not just use the COUNT operator in SyncTOOL and foget about making to V (or do that in a separate step).

Why do you just want to count records anyway? It is an amazingly inefficient way of doing things.

Looks like a bug which didn't exist in 1.4, but it's not exactly going to impact many people.

Wierd thing is different environment has different releases for some unknown reason

Wierd thing is different environment has different releases for some unknown reason

Sites with multiple LPARs rarely install system updates into every LPAR at the same time -- usually it goes into one and runs for a period of time to ensure there are no major issues (such as system crash) caused by the software.

Robert Sample wrote:

Wierd thing is different environment has different releases for some unknown reason

Sites with multiple LPARs rarely install system updates into every LPAR at the same time -- usually it goes into one and runs for a period of time to ensure there are no major issues (such as system crash) caused by the software.

So the kind of scenario zprogrammer describes - would it be correct to assume that they have parallel sysplex which can share the load and a job (say, JOB1) was supposed to execute on LPAR1 with CPC1, however per the "load balancing rules" JOB1 today executed on LPAR2/CPC2 having a different version of the concerned software (SyncSort 2.x in this case) and caused the problem?

PS.: I can't sound more rookie but then Friday came little early this week.