Hi Peter, technically, they can have as many messages in a single UOW as defined by the DEFINE MAXSMSGS command (default 10000, maximum 999999999) and sufficient logging resources, BUT.... I tend to not recommend extended UOW sizes in batch programs, especially because of log implications and restart/recovery considerations. I would chose a design the finds itself between the two that you suggested. One commit per message is as 'bad' as one per 50000, maybe even worse. MQ Channels perform best with a BATSCHSZ of about 50. In a /390 batch program, a 'batch size' of 100 to 500 is probably a good compromise. I did some testing with various batch sizes a looooong time ago and this provided a good compromise between log usage, performance and recovery time. One implementation I did (same sort of program than yours) used a control queue which contained a message with the number of records successfully processed at the time of an abend. During program startup this message was read by the batch program (only present if a previous run abended), and skipped the number of file records contained in the message. Restart logic was rather simple and very stable. You could also write this info to a file which will protect you from a dependency on MQ for restart processing, in case MQ is the reason for an abend (which of course never is the case...). :-) Or, to think completely different: Consider an abend to be the exception to the rule and make your consuming application tolerant of duplicates. But this is more complicated most of the times. Hope those 2 cents help, Stefan
>From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Batch Syncpoint - How many messages can be held back? >Date: Fri, 31 May 2002 14:31:42 -0400 > >OS/390 app with MQ 5.2 needs to put 50,000 messages that are each 50,000 >bytes long, all under syncpoint. Will they be able to commit just once, at >the end of the job, when they know everything worked? Sort of an all or >nothing approach to the job. Or will this strain the QM? > >connect >open >do until EOF ( around 50000 records) > put to queue > write to file/db >end do >close >disconnect (with implicit commit) > > > >The other option would be... > >connect >open >do until EOF ( around 50000 records) > put to queue > write to file/db > if good > commit > else > rollback > end-if >end do >close >disconnect > >Would all these commits degrade performance? Also in this design extra >logic >would need to be added to the app to know where to pick up should the job >abend the first time around, so as not to reduplicate puts, hence the >reason >we are leaning towards the first design. Comments? > > >Peter > > >This communication, including attachments, is for the exclusive use of >addressee and may contain proprietary, confidential or privileged >information. If you are not the intended recipient, any use, copying, >disclosure, dissemination or distribution is strictly prohibited. If >you are not the intended recipient, please notify the sender >immediately by return email and delete this communication and destroy all >copies. > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive _________________________________________________________________ Join the world s largest e-mail service with MSN Hotmail. http://www.hotmail.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
